チーム・ジャーニーを読んだので感想とかまとめとか
チーム・ジャーニーを読みました
カフェ行って読み切って、しばらく経ったので読み返しながら書いていこうと思う
チーム・ジャーニー
カイゼン・ジャーニーを書いた市谷さんが書いた3作目？
カイゼン・ジャーニーはすごく好きで何回も読み返したり、辞書のように使っている
チーム・ジャーニーも読む前からかなり楽しみだった
Prologue
最初はふーんという感じで読んだのだが、あとがきに「もう一度 Prologue を読んでみてください」と書いてあり、読み直してみた
太秦と江島、2人の Prologue というのに気づいたときはエモかった・・・
こういうの弱い
1話 グループでしかないチーム
ストーリー
1社目でスクラムを経験しチーム開発に自信を持った太秦が、何社か転職するが理想的なチームではなくすぐ転職をしてしまう
そんな中4社目に転職をした会社のタスク管理ツールプロジェクトでリーダーに任命される（リーダーとはどのような役割か明確に定義されてないのは少なくない
黙々と淡々と仕事をこなすチームに不安を覚える太秦に蔵屋敷が「君はチームを知らない」と告げる
解説
チームとグループの違い
| チーム | グループ | |
|---|---|---|
| 存在意義 | 1人では不可能な成果を上げる（必要があれば学習する） | 人の集合を外部から見分けやすくする（内側より外側基準） |
| 主語 | わたしたち | わたし、あなた |
| ミッション | 存在意義に直結する＆共有されている | 個々の行動レベルまで落とし込まれていない |
| 役割 | ミッション遂行に必要な役割を定義し、補完し合う | 相互作用が乏しいため役割分担を必要としない |
| コミュニケーション | 関係性や考え方が相互作用に与える影響に注意を払う | 相互作用ではなく相互連絡 |
| プロセス | 最適化を自分たちで進める | 仕事を受け渡すワークフローがある |
| ルール | 自分たちで決める | 外部から決められる |
グループは自分たちが自ら集まり形成されるのではなく、外側から見分けられるようにという意図が強い（組織で言う開発グループなど）
グループからチームになるためには段階的に変化をさせていく必要がある
チーム作りは難しいが、我々はプロダクト作りという似たような難しい活動をしている
プロダクトでアジャイルな志向なら、チームもアジャイルになっていく
プロダクト作りと同様に、チームも適当に作っていいものはできない
チームになるための4条件
- チームの目的を揃える
- 共通の目標を認識する
- お互いの持ち味を把握する
- 協働で仕事するためのやり方を整える
チームの目的を揃える
「我々はなぜここにいるのか？」
与えられた言葉ではなく、自分たちでミッションを捉え、自分たちで言語化する（チーム結成をオーダーした人にすりあわせする
ミッションを表した文書は目にする場所に掲示し、定期的に方向性を違えてないか確認する
共通の目標を認識する
ミッションを大きなままではなく、ブレイクダウンする（スプリントゴールのように
ミッション達成の条件を明確にし小さく分割することで現実感も出てくる
マネージャーだけが把握するのではなく、ミッションと同じく全員が把握する
お互いの持ち味を把握する
上2つはチームの Why
How のためにチームメンバーを知ること
ドラッカー風エクササイズや星取表で知る
協働で仕事するためのやり方を整える
チームメンバーが完全に自由で結果が出ることもあるが、それは成熟したチーム
チームとして練度を上げるために前提・やり方・約束を整える
最初は仕事の進め方を決め（スクラムなど）、活動を繰り返してやり方を見出していく
ある程度やってはいけないことなどを縛ってカオスになりすぎないようにする
定例の時間や、レビューをしてもらうなどといった具体的な内容にする
決まり事は定期的に見直して増やしたり減らしたりする
感想
チームとグループの違いは自分もよく考えていて、チームは 5(人) × 1 = 5(人) だが、グループは 5 × 1(人) = 5(人) のように考えている
人が集まって仕事してもチームではなく、ベルトコンベアーのように仕事が人の手を渡り歩いているような感じ
2話 一人ひとりに向き合う
ストーリー
皇帝がタスクを淡々とアサインしていく。なかなかユーザーに使われてないサービスに対して次から次へと機能を追加していく（慎重に考えたほうが良い）
タスクが積み上げられるので各々淡々とタスクをこなす。相談もできず定例で初めてできているか、できていないかわかる
どのように取り組み、どんな問題にぶつかり、どうやって解決したか誰も知る由もない（一人で仕事をしているのと変わらない）
到達感のない開発で、モチベ・関心事はばらばらになってしまう
どうにかしないといけないと気づいた太秦は最初の一手を悩む（ワークショップ症候群になるのを避ける）
最初の一手はチームでチームの何を知りたいか、何がわからないか
チームの行動の質を高めるために、わかっていないことのうち何がわかればいいかを知る必要があり、何をわかればいいかは自分たちがどうなりたいかに基づく
チームになっていないのにチームとしてどうなりたいかは、わからない
まずは、個人が何のためにここにいるか知る。必要な会話をするためには、適した状況が必要である（今回は振り返りを設定
解説
チームのスタートラインの「出発のための3つの問い」は誰が始めるべきか？
役割で考えてしまうと、責任転嫁させやすくなってしまう。やるべき人は「気づいた人」
現状を問題と認識するためには理想と差分を取る必要がある（現状に最適化して気づけないことも多い
リーダーの役割は「目標を定め、優先順位を決め、基準を定め、それを維持するもの」とドラッカーは定義している
ミッションを捉える際、何を重視するかでリーダーに求められる能力などが変わってくる
状況突破ファースト
問題・膠着の突破のために自分自身が一歩目を踏む。これまでの前提や役割、やり方などを踏み越えることを躊躇しない
長所
それまでの視座では解決できない問題を突破する
短所
メンバーが巻き込まれたくない場合孤立してしまう
プロダクトファースト
プロダクトの作り込みやプロダクトがどうあるべきかに強いこだわりがある
長所
プロダクト作りのスピード感が高まり、短期的に成果が上がる
短所
理想的なプロダクトを作り上げるため、メンバーを振り切ってしまいがち
カリスマ化しやすく、メンバーが指示待ちになる
チーム成長ファースト
チームの中では黒子にまわり、時には試練をあたえたりする。リーダーというよりコーチに近い
答えより問いかけを重視して、チームに思考を促す
長所
チームで考え乗り越える力がつく
メンバー1人ひとりのリーダーシップが求められる
短所
練度の低いチームの場合は段階を設計しないと崩壊する
初期の開発の進みが遅い（外部の期待と合わない可能性がある
タスクファースト
タスクをこなすのに最適化する
長所
短期的にタスクの消化が高い
短所
メンバーの俯瞰する力が伸びず、仕事をする動機づけや、目の前に最適化しすぎてしまう
チームファースト
民主的なあり方を重視する
サーヴァント（奉仕）的な立ち位置になる
長所
チームプレー
短所
多様性が失われる可能性があり、成果が上がらない状況への対処が難しい
柔軟にファーストを選択し、複数を使い分けるのが大事
足りない能力や経験はチームで補完し合う（ファーストはチームで合意してチームで背負う
ワークショップは参考書のようなもので、行って（読んで）実践で使って上達する
ワークショップは現実に合わせた名前で行ったほうがいい場合もある（ふりかえりなど馴染みのある名前など）
ゴールデン・サークル（Why -> How -> What）が参考になる
しかし、チームがビルドできていないときに、チームの Why を問いても難しいので、まずは個人に向き合う
出発のための3つの問い
- 自分はなぜここにいるのか？（個人の Why ）
- 私達は何をする者たちなのか？（チームの Why ）
- そのために何を大事にするのか？（チームの How ）
自分自身がいる理由を思い出してから、チームのミッションに向き合う
積み上がったタスクをこなすのがミッションなのか、プロダクトの向こう側に体験を届けるのがミッションなのか
同じタスクでも視座の置き方によってミッションが異なる
チームの活動が個人の自己実現につながり、個人の目的充足がチームの成果を押し上げる
振り返り
過去の活動を棚卸しして、気づきを得て、次の行動の仮設を立てる
むきなおり
未来に向けて進む方向を変化させる
感想
現状を問題と認識するためには理想と差分を取る必要がある
チームに対して、もやっと今の状態はあまり良くないと感じることがあるがうまく言語化ができない、というのがよくある
たぶん理想がふんわりしているから、言語化できないんだなと思った
ただ、前に理想を言語化しようとしたけどこれも難しく糸口がなかなか見つからなかった・・・
以前インセプションデッキを作ったことがあるが今思うと、個人を知ってからやるべきだなと思った
3話 少しずつチームになる
ストーリー
「自分はなぜここにいるのか？」という問いには「コードを書く」「UIデザイン」「進捗」「チームプレー」になったが目の前のタスクによりがちになってしまった
「私たちは何をする者たちなのか？」という問いには満場一致で「ツールを作り上げること」になったが、違和感がありワクワクはしない
「そのために何を大事にするのか？」という問いには「計画づくり」「コードを書く」「チーム開発」などになり、結果として「チーム開発」を掲げることになり、スクラムを導入したが、アウトプット量は以前と比べて激減した
アサインではなく、タスクを取るスタイルになった結果、誰もやりたくないタスクが三条に集中してしまい体調を壊してしまう（以前は皇帝がタスクをアサインしていたので偏りが生まれることはなかった
以前まで皇帝1人が課題リストを管理していたため大きなバグ等は発生しなかったが、各々が管理をした結果「あれどうなった？」という減少が多発しバグが発生したり、個々の状態がわからなくなった（皇帝が管理していてもわからなかったが
アウトプットの品質も皇帝が全て最終確認をしていたが、各々になったため品質が下がった
チームの進め方の相談をリーダーの太秦か、スクラムマスターの天神川か、皇帝なのか迷ったり
そこで、蔵屋敷が「いきなりスクラムは早い」「一度にすべての問題に取り掛かろうとしても問題は減っていかない」と伝える
- タスクにサインアップしすぎる問題
- 毎週のプランニングでタスクのボリュームをチームで見立ててキャパシティを超えないか調整する
- 個々の課題が見えない問題
- 課題リストは個人ではなくチームで1つ持ち、運用する
- アウトプットの品質が低い（完成の定義が会っていない）問題
- 完成の定義をチームで合わせる（実装が終われば・テストが終われば・STG に配置できれば）
- 役割がかぶってしまう問題
- 役割とはその人への期待にラベルをしたもの。定義するのではなく互いにどういった期待をしているか確認し合う
- ドラッカー風エクササイズなど
ワークショップ1発で状況を変えると思ってはいけない（日常での実践と非日常での取り組みの使い分け）
互いの理解を深めることと、チームが機能することを分けて（段階で）考える
チームの改善も短く、小さい、一定のサイクルで繰り返して問題に早期に出会えるようにする
スクラムをスタートして解決を目指すのではなく小さく進むべきだった（課題やタスクの見える化や、更にその前にチームビルディングなど）
皇帝も自分のタスクマネジメントがなくなったら崩壊するのは知っていたが、リーダー・チームの決定を尊重した
皇帝はチームマネジメントなど得意ではなく、進捗を出すためには自分が背負い込むくらいしかできなかった・・・
解説
チームの成長戦略「チームジャーニー」の根底には段階の設計という考え方がある
いきなり辿り着きたい「目的地」に全力で進むのではなく、途中の段階を意識しながら、段階の設計を組み直しつつ進む
1. 理想とする到達状態をイメージして、最初の目的地としておく
あいまいなイメージでしかないことも多いので、段階を進む中で明確にしていく
2. 目的地に至るために必要な状態を段階として分ける
- 目的地に至った場合どのような状況・状態か？
- その前段階の状況・状態は？
と逆算して段階を構想する（無理がないか、ワクワクするかなども込めながら）
最初は計画性に欠けることも多いので、進めながら調整をする
3. 各段階において何を取り組むべきかを見立てる
取り組む内容は、できているできていないを客観的に判断できるものにする
到達度合いはふりかえりなどで判断して、延長や段階の追加や削除などを都度判断していく
有名なフレームワークとして、チームの成長モデルとして有名な「タックマンモデル」やチームの状態構造を表すモデルとして「成功循環モデル」がある
タックマンモデル
チームを形成していくプロセスには段階がある
- 形成期
- お互いのことを知らない段階。目的も不明瞭
- 混乱期
- お互いの役割・考え方で意見が生まれて対立する
- 形成期を乗り越えて互いのことを知っているので対立が起きる
- 統一期
- 行動規範や役割が確立し、他人の考え方が受容できる
- 機能期
- 一体感が生まれ、目標達成に向かう状態
成功循環モデル
仕事や活動の「結果の質」を高めるためには、メンバー間の「関係の質」を高めるべきという考え方
関係性が良くなれば「思考の質」があがり、思考の質が高まれば「行動の質」も良くなる
という循環する考え方
チームジャーニーでの取り組み
形成期では関係の質を高めて、思考の質を高める（関係の質はワークショップなどを活用して高める
この段階では、互いの考え方の差を理解することである（多様性を認める
必要に応じて Working Agreement を設けてチーム活動を進める
星取表でスキルを理解して、ドラッカー風エクササイズで得意なことなどを理解して、インセプションデッキでチームを理解して、ドラッカー風エクササイズB面（以下4つの質問）で不得意なことを理解する
- 自分は何が不得意なのか？
- どういう風に仕事をしてしまうか？（他人からも言われること）
- 自分の地雷はなにか？
- 以前メンバーの期待に応えられなかったことは？
混乱期では短く、小さく、一定のサイクルを繰り返していく
早めに問題を検出しておくことが大切（一度に多くの問題に取り組むと破綻することがあるので選択と集中を）
また、できる限り最初の結果を早くすることが大切（最初の行動の質は低いかもだが循環を回すことが大切）
成功循環モデルの関係の質を高める最良の手段は、結果をチームで分かち合い、俺達はやれる感を演出すること
統一期では新たな目的地をむきなおりで決めて、再び混乱期を乗り越えていく
コルブの経験学習モデル
「具体的経験」から学びの対象となるインプットを得るために「内省的観察」を行う（ふりかえりなど）
「内省的観察」を経て、次に取り組むべきことを決める際には「抽象的概念化」をする（インプットから理解したことを知識や仮設などに整理して実行可能な状態にする）
「抽象的概念化」をしたものを「能動的実験」をすることで、「具体的経験」を得る
例えばプロダクトの品質を高めるために「テストを先に書いてから開発する」を決めたときにいきなり全員で全部やるのではなく、1スプリントで誰か1人がやってみたりして知見を貯めて全体反映をするといったように、経験学習モデルを高速に回すことを意識する
感想
3つの質問のようなことを答えてもいまいちピンとこない（なにか変わった？）、というのはすごくわかる（ワークショップ症候群）
日常の業務で反映できていない（いくつかのモデルもそうだが）んだろうなと感じた
プログラムとかを勉強するときに、参考書など読んで、実際に書いてみて、バグったりうまく行ったらまた学んで、の繰り返しができているが、チーム関連になるととたんにできないのはなぜだろうと思う
仕事関係ないが、スト5 をやっていて思ったのは、上達するために練習方法がわからなくなる（次の段階に行くためには何が必要なのかわからない）
たぶんこれは同じような現象なのでは？と思っている
プログラミングの勉強でできているんだから、チームでもスト5でも段階を設計できれば、上達すると思っている
この段階を設計するのが難しい・・・
チームもスト5も両方現状の分析をして、段階を設計してほしい（いわゆるコーチ的な役割の人が必要）と感じた
4話 チームのファーストを変える
ストーリー
皇帝は太秦が育つまでといるという約束だったためチームを離脱
チームで合宿をして、ドラッカー風エクササイズ・ふりかえりでのKPTを実施
二日目は「短く、小さい、一巡のサイクル」を意識して短いプランニングとモブプロを行った
テストを先に書く人もいれば、後でしっかり書く人もいれば、こまめに書く人もいる
良い悪いではなく、一緒に開発していたのにやり方の差に気づいてこなかったのが発見
スクラムの理解度もバラバラだったので、最初の段階として状態の見える化を進める
朝回・タスクボード・ふりかえりを定期化・１ヶ月のタイムボックスを置く
何かあっても全員で話し合う時間が増えたが、パファーマンスが落ちている
皇帝の分のタスク量が減り、皇帝の開発の引き継ぎができておらず毎回触る度に調査する時間がかかる
ふりかえりで出しても「チームプレーを高めるべき」と優先度が下げれられる
これ以上踏み込むと関係性が壊れてしまうのではないかと、誰も動けない（全員厄介な問題から目を背けている状態が続く
全員で話すことが多いので時間がかかる（朝会について、タスクボードについて
太秦は個々の自主性が出ていると感じているので強引に介入して、止めたり判断するのを躊躇ってしまう（次の皇帝になってしまう恐れ
そうした結果「チームごっこ」と砂子（PO)に言われてしまう
チームは合宿以降小さな結果を出していないのでまずはそこにこだわるようにする
「プロダクトファーストでアウトプットを出す」をWhyにする
負債返却より機能を優先するのは、いつ経営サイドに止められてもおかしくない状態のため
そのため機能を絞ってもらいそこに集中する
皇帝のコードを全般を追い回すのはやめて、勝負機能のみにする
「勝負機能に絞り込む」「コードのキャッチアップを限定にする」「役割を再定義する」をHowにする
スクラムをやめ、フロントとバックのリード役を定義する（スクラムを取り組めるほどチームが熟していない
すべてを全員で決める方針から、それぞれの分野はリード役が意思決定をする（それ以外は太秦が意思決定をする
解説
チームファースト・プロダクトファーストはプロダクトの文脈によって変えていく
安定の運用が求められるのであればチームファーストで、新規サービスのときはプロダクトファーストで
チームの構造
共有ミッション
チームが達成すべき目標のミッションの定義とチームのファースを設定する
役割
プログラマーやデザイナーなどの専門領域を決めたり、ある領域の先導役としてリードを必要に応じて設定する
その領域のコミュニケーションの活性化と意思決定の促進（場合によっては自分で）を担う
コミュニケーションの場
場、同期目的、場所・手段、タイミングなどを決める
スクラムであれば、計画づくりの「プランニング」、結果を吟味する「スプリントレビュー」、プロセス改善の場としての「レトロスペクティブ」
ルール
制約がないと、活動は集中せず結果への結びつきが弱くなる。Working Agreement や完成の定義など
このチームの構造をデザインすることが大事
ミッションが変わったり、チームの練度が変わったときに、構造を見直したりするべき
アンチパターン
個人商店状態
共有ミッションがない状態だと、それぞれがタスクをこなすだけの個人商店状態になる
塹壕状態
コミュニケーションの場がないと、目の前の仕事をするだけで、状況の同期は誰か１人がやればいいとなる
烏合の衆状態
ルールがないと、それぞれ思い思いに動き、成果が上がらないという状態になりがち
仲良しこよし状態
役割がないと、責務もあいまいになり、結果を出すより共同活動を守りだす
ゴールデン・サークル
構造を決めるときに一緒にチームのゴールデン・サークルを作ろう
Why として何をファーストにするか、ミッションなどを具体的にする
How では、チームの構造設計をしたり、作戦を決める
What では、How に基づいてタスクを決める
一気通貫で整合性をもたせることが大切
さらに、When を足してタイムボックスを意識する
期間が決めれないときは、状況を見直すタイミングの間隔を決める
人は無限に集中ができないので、期間を決めることで集中のしどころを意識的に作り出す
基本的にスクラムのスプリントより長くなるのでこの期間を「ミッション・ジャーニー」と定義する
ミッション・ジャーニー
このミッション・ジャーニーはチームの段階のことで、チームとプロダクトが段階的に成長していく
スプリントは固定だが、ミッション・ジャーニーは可変である
ミッション・ジャーニーは着地の予測が重要になり、想定よりスプリントが必要であれば延長する必要がある
このプラン変更には関係者への説明が伴うため、あらかじめ期待マネジメントをしておく
5スプリントで見積もっていたものを、スプリントごとに見直してわかりしだい即調整を行う
PDCA
Plan, Do, Check, Action
計画に時間をかけすぎたり、計画に現実を合わせることが問題ではある
OODA
Observe, Orient, Decide, Act
空軍パイロットが空中戦闘中に取る意識決定モデルとして定義されており、予測のつきにくい状況に適している
感想
チーム全員による意思決定やMTGはすごい心当たりがある（とても
小さいチームだから、ギリギリワークしているのか（ワークしていないのか）
これも観測できていない・・・
チームのワークをするときは結果を観測できるようにするか、判断する指標をやる前に決めておくべきだなと
何をすべきかわからないときに、進む方向としてのフレームワーク（今回でいるゴールデン・サークルとか）は便利だなと思うし、知識は大切だなと読みながら思う
ゴールデン・サークルやチームの構成もこれが確実な正解というわけではなく、タイムボックスで振り返るようにできているのがチーム・ジャーニーの良いところだなと感じた
ただ人が集まって仕事をしている集団を、フレームワークを元にチームにしていくという知識はエンジニアやデザインナーやPOだけが集まってもできないので、学ぶ意欲が高い
