書籍「チームジャーニー」を読んだので"超ざっくり"でまとめてみた
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
購入リンク
前提
プロダクトバックログ・・・今後やることリスト
PBI・・・プロダクトバックログアイテム、リストのうちの一つを指す
ミッション・・・理想の状態
PM・・・製品の品質や開発コストや、リリーススケジュールの管理など・・・プロダクト単位寄り
PO・・・開発プロセスを管理、開発メンバーを牽引など・・・メンバー単位寄り
PDM・・・ロードマップの作成（目標や目的の作成等）、ビジネスケースの作成（ビジネスモデルやKPIの作成等）、新商品の立案、開発（実務の仕切り）など・・・ビジネス単位寄り
第一部
基本編
1章
チームとグループの違い
チーム・・・一人では不可能な成果をあげ、ミッションが共有されており、相互作用に与える影響に注意を払いながら、ルールは自分たちで決める集団
グループ・・・人の集合を外部から見分けやすくラベルを貼られた、相互連絡をしながら決められたルールの中で行動する集団
チームになるための条件
いきなりチームにはなれないから少しづつ成長していこうよ
- チームの目的を揃える・・・「我々はなぜここにいるのか？」、自分たちでミッションを決めて言語化する
- 共通の目標を認識する・・・ミッションを複数の目標に細分化、目標を達成することでミッションの達成に近づけ、思考や行動の基礎になるよう全員で共有する
- お互いの持ち味を把握する・・・何に興味があって、何にを重要視し、やる気を見出すのかを知る
- 共同で仕事するためのやり方を整える・・・まず共通理解を得やすいフレームワークを使い、そこからやり方を少しづつ変えていく、その他に前提として具体的な内容のルールも取り付けるが、最小限にする
このセクションで出たワーク「星取表」「ドラッカー風エクササイズ」
2章
問題提唱とリーダーシップ
理想と現状のギャップが問題になる、その問題を提唱するのは決められた役職の人間でなく、「気づいた人」
「リーダーとは目標を定め、優先順位を決め、基準を定め、それを維持する者」byピータードラッカー
何「ファースト」かを決めることでチームの意思決定の基準を言語化する👈リーダーの独断で決めない
ワークショップをすることによって得られる効果は大きいが、ワークショップが目的にならないようにし、現実に合わせた場の設定（ワークショップと思わせない）が重要
出発のための3つの問い
ゴールデンサークルというフレームワークが元
- 自分はなぜここにいるのか？（個人のwhy）
- 私たちは何をする者たちなのか？(チームとしてのwhy)
- そのために何を大事にするのか？(チームとしてのhow)
3章
段階の設計
初期の理想イメージでは正確性に欠けるため、状況に応じて段階を組み直すことが必要
- 理想とする状態をイメージして最初の目的地とする
- 目的地に至るために必要な前段階を逆算し、段階を構想する
- 各段階で理想とする状態を言語化し、そうなるために何に取り組むべきかを見立てる
👉段階を経ていく過程で方向性自体を見直す必要もある
チーム・ジャーニー
タックマンモデルと成功循環モデルを掛け合わせたフレームを使用
- チーム形成期に自分は何が不得意、苦手でどんな仕事をしてしまうのかの共有をする
- チーム混乱期には小さな仕事を短期間で一巡させ、正すべきことを早く明らかにし、できる限り早く最初の結果を出し、結果をチームで分かち合うことが必要、成功循環を初めは小さく始めていく
具体的にはタスクをモブプログラミングなどで行い、初めは１日単位でタスクを一巡させる - 統一期には次に目指すべき状態を見定め、役割の再定義、ルールの見直しなども行う
4章
チームの構造と状態
チームは４つの要素で成り立つ
- 共有ミッション・・・ミッション定義+チームのファースト設定
- 役割・・・役職定義とリードの設定
リードとはその領域の意思決定やコミュニケーションを先導する役 - コミュニケーションの場・・・レトロやデイリースクラムなど状況共有や改善目的のためのもの
- ルール・・・お互いの活動を制約する取り決め
上記４つのうち何かが一つが欠けている場合
共有ミッションが欠けている・・・個人商店状態、個々人が責任を果たすだけの状態
役割が欠けている・・・仲良しこよし状態、成果を出すことよりもお互いの期待する動きになっているかを重視してしまう状態
コミュニケーションの場が欠けている・・・塹壕状態、状況の同期はリーダーが握っておけば良いという状態
ルールが欠けている・・・烏合の衆状態、お互いの活動が噛み合わず成果が上がらない状態
ゴールデンサークルとミッション・ジャーニー
ゴールデンサークル
- why・・・ファーストに基づくミッション定義
- how・・・whyを実現する作戦
- what・・・作戦に基づく具体的なタスク
- when・・・達成に必要な期間、タイムボックスの設定（元々のゴールデンサークルにはない）
ミッションジャーニーとは3章の段階のこと
ジャーニーの達成期間をタイムボックスといい、その中にスプリントがいくつもあるというイメージ
スプリントの期間は固定だが、ジャーニー（タイムボックス）は可変、ミッションによって変わるため
着地の予測が重要になる、いつまでに終わるのか何スプリントあれば終わるのか
あくまで予測、スプリントが終了する際にこのままでは終わる終わらないが見立てられるようになってくる
終わらないようなら状況の理解を関係者とすり合わせたり、スプリントを増やしたりして応じる
基本編まとめ
- 目的地を定める・・・「３つの問い」に向き合う
- ジャーニー（段階）を設計する
- ジャーニーのミッションの定義・・・ゴールデンサークル
- チームのファーストを選択・・・リーダーシップ
- チームのフォーメーションを変更・・・6章にて説明
- ジャーニーの遂行
- ジャーニーのふりかえり・・・状況によって1、２、３に戻る
応用編
5章
現状のチームとDIFF
DIFFの種類
- 前方とのDIFF・・・チームの理想的な状態を描き、それとのDIFFをとる、大きな変更点がないと描きにくい
- 後方とのDIFF・・・過去の自分達に比べてできるようになったことから次の方向性を決める、安易で意義の低いものになる可能性
- 平行とのDIFF・・・他のチームとのDIFFをとる、チームによって状況が違うので慎重にDIFFを測り、チームそれぞれの前提と背景を捉える
DIFFを撮る際の観点・・・DIFFの種類と組み合わせてDIFFをとる
- ユーザーへの価値提供
- ビジネスの成果
- プロセスや技術、コミュニケーションの練度
- 新たな領域の学習
DIFFをとった後に自分達が具体的な行動を起こせる内容にするために必要
その内容をもとにジャーニーを切り替える
6章
コミュニケーションの分断による６つの問題
フレックスやリモートワーク、技術経験の差からなる
- 稼働時間帯が合わない・・・同期できない
- 稼働時間に偏りがある・・・PBI開発へのコミュニケーションコストが高い
- メンバーに経験の幅がある・・・やり方がバラバラ
- 非言語コミュニケーションがない・・・伝わる内容分量が少ない
- 相手の様子がわからない・・・異常検知がしにくい
- 背景が見えずタスク志向になる・・・whyがないため、間違いに気づかない
雁行陣開発
フォーメーション・パターンの一つ
プロダクトリード・・・中核の機能、背骨のPBIを先行して開発する役割、方針は決め切る前にメンバーからFBをもらう
チームリード・・・チームの運営、プロダクトリードの代わりにチーム内情報共有、相互作用が十分に行き渡るよう働きかける役割
メンバー・・・適宜PBIを開発、背骨に対してのお肉のPBIの実装
チームリードは負担があるので適宜交代するべきで、ジャーニーごとにどのようなフォーメーションで挑むのかはチームで確認するべき
7章
チームでの分断
- 開発チーム内部の分断・・・バックエンドとフロントエンド、デザイナーと開発者など
- 開発チームとPO間での分断・・・技術に関するリテラシーの差があり、認識齟齬が発生しやすい
- プロダクトチーム（開発チーム×PO）と外側との分断
共通理解を深める
チームがどういう状況なのか安易に把握できるように透明性を高める、3つの原則
- 見える化・・・情報を得られやすいように情報や状況の整理を行う
- 場づくり・・・情報を伝え合うようにするために定期的に時間を設ける
- 一緒にやる・・・一つのタスクに全員で取り掛かり、互いの理解を深める
自分達が何を知っていて何を知らないのかを知ることが重要
このセクションで出たワーク「仮設キャンバス」
8章
再・出発のための3つの問い
同調圧力を生みやすいので、チームビルドが進んだ段階で使用
- 私たちは何をする者たちなのか？(チームとしてのwhy)
- そのために何を大事にするのか？(チームとしてのhow)
- 自分はなぜここにいるのか？（個人のwhy）
開発チームとPOの境界にPO代行を置く
両者のリテラシーの差を埋めるために、つなぎ合わせる役割がPO代行で２種類の代理を行う
翻訳の代理・・・開発チームとPOそれぞれの説明する状況が相互に理解できるよう知識補完する
コミュニケーションの代理・・・時間や場所のずれを吸収する
プロダクトとしてどうあるべきかという基準をPOと常時すり合わせる
応用編まとめ
仮説検証とアジャイル開発を組み合わせた一人の人間のようなチームづくりをして、速度をあげよう
頭・・・何を作るか整理する
目・・・観察する
口・・・質問する、言語化する
耳・・・インタビューする
手・・・つくる
足・・・コミュニケーション
血液・・・情報
チームのあり方に完璧はない、何回もミッションの再定義をしよう
第二部
基本編
9章
チーム間の情報流通の不全
経路設計の複雑性・・・複数チームになると情報の伝わる頻度が足らなくなる
解釈の多様性・・・情報の解釈にばらつきがある
プロダクトづくりにおける３つの価値・・・情報を価値のあるものに加工する
- ユーザーにとっての価値・・・ある状況を解決するためにプロダクトがあり、このある状況に置かれている人が理想的な状況に変わることが価値
- ビジネスにとっての価値・・・事業の持続可能性、ビジネス的成果が求められる
- プロダクトにとっての価値・・・変更可能性が必要な取り組みとなる
情報流通のための境界
- ミッション・・・プロダクトチーム全体で到達したい目標
- 戦略・・・ミッションを実現するためのプロダクトチーム全体での方針
- チーム・ミッション・・・チームれべるのミッション
- 作戦・・・チームミッションを達成するためのジャーニー
10章
チーム別で見るコミュニケーション
一つの開発チームと一人のPO・・・「自分は何をする人なのか？」に向き合うことで分断の境界に気づき、乗り越える
複数の開発チームと一人のPO・・・POの練度が試される、「越境のデザイン」が求められる
複数の開発チームと各チームのPO・・・より分断を生む、「越境のデザイン」が求められる
越境のデザイン
- リードというある状況において全身を先導する役割をチームに持ち込み、これをチーム内で交代制にすることでリードのスペア化を目指し、できるだけ全体のスキル向上を求める
- コミュニケーションの構造化、チーム同期のコミュニケーションから始まり、リード別の同期コミュニケーションへ、最後に代表者の同期コミュニケーションへ、ただし代表者の同期コミュニケーションを意思決定機関しないことを気をつける
- カンバンの運用、それぞれの上記構造によってレイヤーを合わせる必要がある
11章
他チームの境界
WIP制限・・・チームが捌けるタスクの限界
WIP制限はカンバンで見える化し管理する
チーム感依存度が高い・・・チーム単体の生産性は低いが、チーム同士の意思疎通は撮りやすい
チーム感依存度が低い・・・チーム単体の生産性は高いが、チーム同士の意思疎通は取りにくい
状況によって依存度を変える
5つの作戦
- リソース配分に意思を込める・・・チームが何に対して時間を使うのかをあらかじめ決め、状況をみて割合を調整する
- 番頭の輪番化・・・外部の依頼を受け取り処理する番頭を交代で行う
- 順序付の基準を合わせる・・・ミッションの到達に遅れを出さないようにタスクの順序付けを行う
- チーム外部への表明・・・チームが外部にどういったスタンスで動いているのかを発信する
- チーム間のふりかえり・・・チーム間の問題や改善に対してできるだけ関係してるメンバーを集めて話し合う
12章
横断チーム
専門性の不足やこぼれ球が山積みの状態が発生した際に構築を検討
専門特化型チーム・・・専門性に特化したチーム（アーキテクチャ設計、SREなど）
状況特化型チーム・・・状況に特化したチーム（共通機能開発、以降チームなど）
2つの問題
- 開発チームと横断チームの確執が発生しうる可能性
- 他チームからメンバーを引き抜いて結成、稼動できるかの問題
適宜ミッションが片付いたらチームを解散するか永続化する判断をする必要がある
チームで対立したら「我々はなぜここにいるのか」を両チームで応える機会を設ける
ミッションの主管が既存チームにある場合・・・チーム一体となるためゴールデンサークル、スクラムイベント、プロダクトバックログを完全同期
ミッションの主管が横断チームにある場合・・・チームを独立させ、必要に応じて同期のコミュニケーションを行う
応用編
13章
対象を1ユーザーに絞る
チームそれぞれが別々のユーザーに対してプロダクトを提供していたらペルソナが固まっておらず、意味がない
ユーザー行動フローを描くための方法
-
プロダクトがまだなく、ユーザーに関する共通理解を作りたい
1.ユーザーの大まかな行動か状況を書き出す
2.対応する行動を細かく書き出し、書き出せないところは行動の観察余地が残ってるということになる
3.ユーザー行動に伴い発生する問題、不都合を書き出す（そもそも〇〇しないなど）
4.問題や不都合を解消する解決策を挙げる
5.現状の行動フローを踏まえ、理想的なフローを描く -
既にプロダクトがあり、ユーザー体験の最適化を進めたい
- そのプロダクトを利用する際のユーザーの状況をざっとあげる
- 状況に対応する行動を細かく書き出し、流れをきちんと把握する
- それぞれの行動に伴い発生している障害を書き出す（ユーザー調査、ログ調査などを行う）
- 障害に対する解決策を挙げていく
チームの足並みを揃えるために共同のカンバンを使用し、状況を把握する
スループット・・・ある一定の機関あたりに創出できた価値（プロダクトやバグ改善など）の数
スループットまでのリードタイムを計測し、データをとっておくことで、ボトルネック発見の大事なヒントになる
14章
マネジメントリード
チーム内の情報の流れ、問題予測、障害の始末を継続的に追いかける役割
- 自分の目の前から自分がやらなければならないタスクを一掃する
- チームの目の前からやらなければならないタスクを片付ける
意思決定を決める際に選択肢と前提と時間軸（過去、現在、未来）を意識する
蜘蛛型チームからヒトデ型チームへ
蜘蛛型・・・リーダーを中心として、チームを運営する・・・まとめやすいが、意思決定に時間がかかり、速度に限界がある
ヒトデ型・・・チームが個別に動き、必要に応じて会議する・・・各チームのリード練度、自立性がある程度必要、速度が出る
各チームの標準化から各チームの課題解決共同化へ
- 時間と場所を共にする、一日限定の同席開発や合宿などが有効
- 仕事を共にする、モブワークなど理解を深めるために他人に説明したりする
最終的にミッションを共有し、お互い協力し合える相互作用、協働化へ
15章
チームが持つべき視点
考え、決め、動く、を状況に応じて適したものにするには"どこから""どこまで"を見るかで変わる
- 視座（どこから）・・・目的、自分の立ち位置をどこにおくかで変わる（ジャーニーの視座、事業の視座など）
- 視野（どこまで）・・・対象、何を捉えるかは状況とテーマによって変わる（ユーザー、チーム、経営者など）
例："プロダクト"に置き、"ユーザー"を捉える・・・プロダクトの機能について現状利用している人たちのフィードバックを集め、何を価値と置くのかを整理する
同じ範囲を見ていても視座変われば見えるものが変わることを理解する
視座と視野の移動を難しくする要因
- （自分たちにとっての）現状の最適化・・・自分たちが現状に合わせた思考、行為をとってしまうため、視座と視野の偏りがおこってしまう、「この仕事で何を実現し、なんのために必要なのか」を問う
- 役割による固定化・・・役割によって視座と視野の偏りがおこってしまう、リードの概念を取り入れて動的ににリードを動かし、解決する
プロダクトオーナーの民主化・・・プロダクトとして何を作っていくべきなのかという観点をメンバー全員が持つ、その代わり専門性が求められるリードが必要になる
多次元からの捉え
一人でものごとを捉えるに限界があるため、チームで臨むことが必要、チーム総体としてあらゆる観点から物事を捉え考えられるようにする
自分たちに問う・・・チームの思考や行動に問いをぶつけ、現状の最適化による思考の停止や安易な好悪によって選択肢を絞ってないかに向き合う
わかりきっているということでも頑固にならず、もう一度頭の中に通してみることが重要
自分たちが気づいていないことに気づくために、今一度「正しいものを正しく作れているか」という問いにも向き合う
容易なことではないし、答えはない
16章
仮説、検証
プロダクトで何をもたらすのかという仮説を立てることが必要👉仮説キャンバスを使う
- 調査、分析、観察
- 仮説立案
- 検証・・・ユーザーインタビューやアンケート、MVP検証など
検証活動で重要なのは"いかに時間をかけず"に"利用者から濃い反応を得れる"か、活動にできるだけ多くのメンバーの関わりが必要
MVPを用いいたユーザーテストには、ユーザーにもできるだけふりかえりに参加してもらう
Discussion