#チームの特徴
- 全員男（わざわざ言う必要ないが、＾_＾）
- 定型業務はほとんどなく、サービス・システム機能の企画や問題解決をメインにする突発的なユーザーサポート案件がほとんど
- 基本はPJ単位や案件（大小問わず）単位で動く
- 案件の担当にアサインされたら、最初（企画）から最後（リリース、ユーザーサポート）までオーナシップを持つ
- 他チーム・他PJと横連携しながら、案件をこなす必要があるので、人の巻き込みが常に伴う業務内容。なので、案件をこなすには、もちろん個の能力が大事だが、KNOW WHO KNOWS WHATも大事
- 裁量は大きいである一方、説明責任を求める
- 半部以上のメンバーはスクラムPO（プロダクトオーナー）経験済み、アジャイルの思想、キーワード、プロセスを一通り理解できている
#チームビルディングの取組み
##業務のSprint化
-
課題＆導入経緯
- 案件が多く、すべてこなせることは不可能、絞り・集中が必要、時間・リソース制約の中、価値最大化が永遠の宿題
- 業務だけではなく、各自自己成長の学び時間を確保してもらいたい
- 上記の目的を達成するために、スクラムという「型」を思い出した
- だったら、開発ではなくても、企画とユーザーサポートの業務をSprint形式でタイムボックスを切って、優先順位づけてスクラム形式でこなせるサイクルをつくれないかと、9月から１週間Sprintを試してみることをチーム全員でサムアップで決定
-
Y（やったこと）
- スクラムに参考しながら、独自のSprintルールを策定したうえ、チームのTrelloボードを作った
- 重要ルール１
案件をValue Backlog（ここではProduct Backlogではなく、あえてValue Backlogと呼ぶ）に登録、SprintのTODO LISTに移動する前に、必ず１週間以内終わらせるタスクへ分割 - 重要ルール２
分割されたタスクには必ず目的、目標＆OUTPUTを明記（User Storyの受け入れ基準に相当）、OUTPUT不明のものはタスクとして認めない。これを考えるさせることで、HOWだけではなく、「WHY」と「WHAT」を意識させること - 毎週の金曜日午後1時間程度、チーム全員のSprint Meetingを実施、そこで振り返り、次の週のやることを各自制限時間内説明、全員フリーディスカッション
- 振り返りは最初「Y/W/T」使ったが、12月以降、「Learn/Fun/Done」を実施
- 記録として、メンバーたちが自ら各タスクこなした後学んだこと、気づいたことをTrelloのコメントに記載
-
W（わかったこと）
-
**ルールを作るだけでは不十分、こういった取り組みの定着は運用側の魂が必要、**大きなサイクルの「型」を出来上がったものの、細かい部分は各自にお任せ、且つ自分のフォローが不十分のため、細部の定着が良いとは言えない
-
本来のスクラムでは許さない割り込み作業が多く発生、優先順位の都度調整と割り込み作業の対応に追われている
-
開発ではないチーム・業務にSprintを適用するには、状況に合わせて活動内容の随時調整など、それなりの工夫が必要
-
チームのSprintより、実質上個人単位のSprintとなってしまった
-
タスクの見える化によって、各自の負荷状況、困ったときの支援・アドバイスがやりやすくなった
-
Sprintの効果はまだ不明
-
T（次に試したいこと）
- 週次Sprintに対して、チーム全員の振り返りを実施。その中で今後の運用方向性を一緒に決めていく
##学びの活動
-
課題＆導入経緯
-
業務内容的には、システム、業務、マーケティング、商品知識、業界、顧客など、ほぼ事業に関わる全ての知識が求められる
-
事業を拡大させると共に、チームとして知的生産性の向上が不可欠
-
プロダクト志向、ユーザー志向の強いチームを目指したい
-
Y(やったこと)
-
随時振り返り、業務課題を解決後、その場で当事者と15分程度YWTで実施
-
Connecting Dotsで知識を「点」から「線」にして、さらに「面」にすること。
具体的には、大小に問わず業務課題をトピックにして、担当がそのテーマにまつわる学んだことを自らホワイトボードに書きながら説明（マインドマップ形式等）、ほかのメンバーは説明された内容を自分の経験・知識に照り合わせて、「〇〇の場合はどうしますか？」、「〇〇は具体的には何でしょう？」とか、突っ込んだ考えさせる質問をする。すべての質問及び回答は全部ホワイトボードに記録、しかも、各ポイント同士の間線で繋げ、関係性を示す。 -
**書籍や雑誌からそのままぱくっても、自分で独創してもいいので、物事をシンプルに説明できるフレームワークを持ちよせて、チームメンバーに説明して、一緒にフリーディスカッションすること。**今まで、狩野モデル、技術継承フレームワーク、システム障害対応時使う運転教習所教えてくれたOPDE（Observe,Predict,Decisions,Excute）等、チーム内共有して深堀した
-
1-5-10：
「１」は、なんでもよいので、毎週必ず１点の深い反省・気づきをまとめること。
「５」は、毎月読んだウェブ記事のうち、自分のコメントを加えた５個をチーム内共有すること。
「１０」は、毎月営業レポートを10個目を通すこと。
知を広く探索させるため、上記を半強制的なルールとして運用を始めた
-
W(わかったこと)
-
個の学びをチーム内の共有＆深堀することで、本人が「教えること」を通じて、その学びを自分自身の中でさらに定着させるには一定の効果がある
-
リーダーとして自分の根性が足りない
年末に多忙のため、振り返りだけを実施、1-5-10以外の学びの活動は実質上中断 -
1－5－10の「5」と「10」は自分としては簡単だと思ったが、メンバーには意外と難易度が高いと運用始めた当初分かった。
どんな記事にどんなコメントを加えたほうがよいのか、やり方に戸惑っている様子。
幸い、特に難易度の高い「5」部分は、一部のメンバーが自ら楽しく積極的に発信するなど、習慣化始めた兆候。 -
学びのテーマはいつも直前で決まったため、各自の事前の準備が足りない、その故、その場で議論があるものの、深堀が足りない感じ
-
学びがあるものの、その学びはすぐ業務と紐づけられるかどうかは微妙
-
T(次に試したいこと)
- 効果的に学びができるように、**テーマと「型」**を再度計画すること
##心理的安全性を確保活動
-
課題&導入経緯
- チームの生産性は心理的安全性と深く関係すると理解
- 自分の意見を言えない、助けを求めしないチームは絶対したくない
- 心理的安全性の確保はまずメンバー同士会話させ、自己オープンさせる仕掛けが必要 -
Y(やったこと)
-
月１回の1 on 1
最近の業務、プライベートの状況に加え、12月から2年後のキャリア目標、直近3カ月、6カ月達成したい目標も、1 on 1の内容にも入れました。 -
感情曲線のワークショップ
19年1月～10月の各自の感情曲線を全員で一緒に描いた。 -
チームチャットで分報チャネルを作った
下記の記事を参考にして、自チームに適用しました↓
分報で各自の作業を可視化したら、メンバー間の協力が加速された話 -
デリゲーションポーカーのチーム内共通言語化
タスクを依頼する際、いちいちどこまでしてもらうかを説明せず、デリゲーションポーカーの番号で権限移譲のレベルをメンバーと合意すること。
「〇〇のタスクをお願いしたいですけど、ポーカー6番良い？」
「5番お願いします」
↑といった感じの会話はチームの中で多く発生 -
W（わかったこと）
-
リーダーとメンバー、メンバー同士頻繁に会話したり、自分が自由に発信できる分報チャネルを提供することで、チーム中の心理的安全性が比較的に高いと思われる
-
一方、一階層上の組織範囲では、心理的安全性が高いとは言えない。チーム中で簡単に話せる内容は、事業部範囲では話すことに躊躇している場面ばしばしば見えている
-
1 on 1では自分が喋り過ぎと反省、しかも、月１回の頻度はもう少し増えてもよいではないかと
-
ポーカーの共通言語化は手応えを感じる。意思疎通の効率化効果に加え、権限移譲についてメンバーたちの自分の言いたい事を言いやすくなる。
-
T（次に試したこと）
-
チームの心理的安全性状態は自分の思い込みがないかをメンバーたちと会話して確認する
-
まだノーアイディアですが、デリゲーションポーカーに加え、共通言語化の取組を１～２個実施したい
#まとめ
「成功の循環＋情報の透明性＋心理的安全性」を意識してチームのビルディングを行ってきました。能力や根性不足のため、中途半端の活動が多いが、方向性としては間違っていないと確信。2020年は引き続き振り返りしながら頑張っていきたいと思います。
ついでに、
下記は自分のチームビルディングする際大事に使っているフレームワーク：
自分なりのチームにおけるリーダーとしての役割定義：
