# チーム・ジャーニー　（第1部）
# 第1部　僕らが開発チームになるまで　-1チームのジャーニー-
## 登場人物
☆はカイゼン・ジャーニーにも登場
＜アップストン社＞
＜タスク管理ツール（フォース）チーム＞
太秦：主人公。中途採用で、スクラムの経験を買われチームリーダーに任命される。
嵐山：通称「皇帝」。チームの絶対権力を持つ開発チームのドン。
天神川：嵐山と並んでチームの顔。早口で自分の意見をまくしたてる。
三条：チームメンバー。リーダーの2人に聞こえないようぼそぼそと話す。
鹿王院：チームメンバー。やりとりが面倒くさいので基本無言。
有栖：チームメンバー。デザイナー。唯一の女性で、物静か。
＜その他チームに関わるメンバー＞
☆砂子：プロダクトオーナー。太秦をリーダーに任命する。
☆蔵屋敷：アジャイルコーチ。チームをカイゼンに導く。
＜その他のメンバー＞
御室、宇多野：太秦の同期。
（鉄道駅名→嵐電：太秦広隆寺、嵐山、嵐電天神川、西大路三条、鹿王院、有栖川）
## 第1話　グループでしかないチーム
### ストーリー
太秦は中途採用で入社し、4度目の入社となった。1社目は良い環境で3年以上勤めたが、自身の成長を期すため退社。2,3社目では合わず、1年で退社した。
アップストン社では、社内で2番目に大きいプロダクトのタスク管理チームでリーダーを勤めることになった。
しかし、チームは嵐山と天神川の2人以外にモノをいう人はおらず、覆しようがない上下関係で固定されていた。リーダーは既に4人も退いたという。
このようなチームのリーダーとなり太秦は困惑するが…蔵屋敷が一言「**君が知っていることは何だ？**」そして「**君はまだ、チームとは何かを知らない。**」
### チームとグループでは意味が異なる
* **グループ**:意味上でまとめられた人の寄せ集めで、メンバーの相互作用は無く仕事のワークフローのみがある。
* **チーム**：一人では不可能な成果を上げるべく、共通して持つミッションに向かって一人一人が自律的に動き、お互いに協力し合う集団である。
* チームもプロダクトのように成長する。成長は段階的。
#### チームになるための4つの条件
* チームの**目的**をそろえる。「**なぜ私はここにいるのか**」（インセプションデッキ等）
* **共通の目標を認識する。** ミッションの粒度を細かくしていく。
* **お互いの持ち味を把握する。**　達成の条件を明確にして、どのような作戦が適しているかを図る。（ドラッガー風エクササイズ・星取表など）
* 協働で仕事をするためのやり方を整える。人と人が共に動き、まとまった成果を上げていくためには「条件」が必要となる。（ワーキングアグリーメント）
* ※その他にも様々な問題と対処法がある。それぞれの対応法については2話以降開設する。

## 第2話　一人ひとりに向き合う
### ストーリー
相変わらずプロダクトは嵐山と天神川の一方的地位が確立していた。プロダクトバックログは皆きっちり倒しきるが、上が配分した仕事をただ終わらせるだけであった。
* こうした状況を変えられるのは、**変える必要性に気づいている太秦以外いない。理想が描けていなければ問題にならない。自分のハンドルは自分で握ること！**
* ぼっち曲線のように、重要度が高くても1人や少数だと問題にならない。**多数が問題に気づいてこそみんなで取り組めるのである。**
そこで、チームでチームの何が知りたいのか検証すべく、太秦はレビューとプランニングの終わりに、チームでの振り返りを提案。有栖が声を挙げたこともあり、
嵐山も渋々受け入れた。
### リーダーシップパターンとワークショップ症候群
* **リーダーシップ・パターン**：それぞれが持っているリーダーシップの価値観と長所・短所をまとめたもの。そしてどのパターンを最優先（○○ファースト）にするべきかを決定する。
* **ワークショップ症候群**：ワークショップはチームの雰囲気醸成に必要不可欠であるが、やればやるほど結果を出せるわけではない。ワークショップの本質である「知りたいことを知る・共有する」目的から離れないように。
### 出発のための3つの問い
ゴールデンサークルのフレームワークに基づく。
* **自分はなぜここにいるのか。（個人としてのWhy）**
* **私達は何をする者たちなのか。（チームとしてのWhy）**
* **そのために何を大事にするのか。（チームとしてのHow）**
### 振り返りと向き直り
* 振り返り　過去を顧みて現在を正す。
* **向き直り　進むべき先（未来）を捉えて現在を正す。**

## 第3話　少しずつチームになる
### ストーリー
チーム開発がはじまり早速スクラムを試みるが、あらゆるものが空回りしてしまう。メンバーのうち三条は過剰なタスクを背負いこみ倒れ、鹿王院は課題リストを紛失し、デモもままならずバグだらけのレビューとなり、散々であった。嵐山がリーダーとして課題リストの管理やテストをきちんと行っていた頃の安定感は微塵もなかった。
「このグループで“いきなりスクラム”は早い。」「**チームのジャーニーをイメージしよう。**」
### 段階的なチーム設計
* チームの機能性とお互いの理解の深まりは、どちらも一気に仕上がることは無いため、段階で捉えていく。
* 段階設計の方針としては、短く小さい一巡のサイクルを繰り返し、段階を徐々に高めていく。→問題に早期に出会える。
#### 段階設計の具体例
1. まず理想的な到達状態をイメージしておく。「我々がたどり着きたい場所はどこか」
2. 思い描いた目的地から逆算して、段階を置いていく。その後、各段階での到達目標を決定する。
3. 段階は状況に応じて適宜組みなおしたり、向き直りを行ったりして修正していく。
### チームの成長戦略「チーム・ジャーニー」
* **タッグマンモデル**：チームを成熟度に応じて4段階に分け、チームの生産性との移り変わりを表したもの。
* **形成期**：チーム結成から間もない頃。生産性は低いが徐々に上向きに。
* **混乱期**：チームで様々な問題や対立が起こりやすい頃。生産性は緩やかに右肩下がりとなる。
* **統一期**：混乱期を乗り越え、チームとしての結束が高まった時期。生産性は右肩上がりで急上昇する。
* **機能期**：チームとして円熟し、最も一体感のある時期。生産性は最高レベルで安定する。
* **成功循環モデル**：質を4パターンに分けて循環させる。
* **関係の質**：チームやメンバーとの関係。関係の質が良いほど、良質の成果物となる。
* **思考の質**：考え方の質。考え方は人を取り巻く関係で左右される。
* **行動の質**：実際の行動の質。必要なことをきちんと考えているか、思考の質で良いかが決まる。
* **結果の質**：成果物の質。高めるべき質の最終目標。行動の質が良いかで決まる。
* 各状態で取るべき戦略
* 形成期
　　* チームの基本的な関係づくりを行う。ワークショップやワーキングアグリーメントを設定し、価値観の差を理解する。
　　* 不得意なことや過去の失敗談等は、ドラッガー風エクササイズB面として用意する。

* 混乱期
　　* 短く、小さい、一巡のサイクルを繰り返す。そこからチームとして正すべきことを明らかにする。
　　* できる限り早く最初の結果を出すようにする。この結果をチームで分かち合い、「俺たちはやれる！」感を演出する。
　　* 最短で1日からサイクルを回し、短く早く終えるようにする。
* 統一期
　　* 新たな目的地を見出す向き直りを行う。
* コルブの経験学習モデル　以下の4段階を繰り返す。
* 具体的経験
* 内省的考察
* 抽象的概念化
* 能動的実験
## 第4話　チームのファーストを変える
### ストーリー
太秦は合宿を行い、チームの士気を高めようとした。ワークショップを通じてチームの問題点を改めて見つめ直し、状態や活動の見える化に取り組んだ。
しかし、皇帝と言われた嵐山が退職し、彼が残していった大量のタスクやコードの独自実装の解釈等に時間がかかり、後回しにされた。また、ミーティング時間が増えたことで、タスクを行う時間を圧迫していた。チームの意思決定も乱れ、砂子からチームごっこと呆れられた。
### ミッション・ジャーニーの設計
* チームファーストとプロダクトファーストは、しばし対立し、チームの在り方が揺れ動く。状況に応じて、リーダーが第一主義を適宜切替えて適応できるのが良いチームである。
* チームの構造をデザインする。
* **共有ミッション**：ミッション定義とチームファーストの設定を行う
* **役割**：専門領域に基づく役割定義に加えて、「リード」という特定領域での先導役を設ける。
* **コミュニケーションの場**：チーム内での同期タイミングや頻度、目的、場所、手段を決定する。（デイリースクラムやプランニング、レトロスペクティブ等）
* **ルール**：ワーキングアグリーメントや「完成」の定義、透明性などの原則の取り入れを決定する。
### 誤った民主主義の状態
* 個人商店状態：共有ミッションが足りない状態。個々人がそれぞれの責任を果たすだけの「個人商店」状態となってしまうこと。
* 塹壕状態：コミュニケーションの場が足りない状態。同期はリーダー任せになり、回数が圧倒的に減り問題を見つけにくくなる。
* 烏合の衆状態：ルールが足りない状態。個々人が勝手に完成の定義を設定したり、同期の時間を守らない等が起き、成果が上がらなくなる。
* 仲良しこよし状態：役割の定義が足りない状態。責務があいまいとなり、なれ合いによってカバーしてしまう。

### ゴールデンサークルに基づく定義づけ
* **Why部分**　共有ミッションの定義を行う。
* **How部分**　役割の再定義や、機能の絞り込みを行う。
* **What部分**　スクラムマスター廃止やリードの設定などを行う。
* **When部分**　上記の基本3つから追加。タイムボックスの設定を行う。
太秦達はチームファーストから一旦プロダクトファーストに戻し、機能を絞り込んで開発することにした。また、天神川をスクラムマスターからバックエンド側のリード担当として任命した。メンバーは戸惑いながらも受け入れ、太秦が初めてリーダーとして機能した自覚を得た。

### ミッション・ジャーニーとは
* ミッション達成までのタイムボックスのことを指す。スクラムのスプリントよりも長めに設定される。
* 期間が見限れる場合はその期間で、期間が見限られない時は、向き直りの間隔を決める。（1か月を基本とする）
* スプリントは固定だが、ミッション・ジャーニーは可変。何スプリントかかるかの着地点の見積もりが重要である。

### 第5話　チームをアップデートする
### ストーリー
プロダクトファーストへの転換は一定の成功をおさめ、効率よくチームが回り始めた。しかし、チーム結成から3か月が経った頃であった。振り返りで問題が上がらず、鹿王院は影響はほぼないからとバグを報告していなかった。多方面から今の進め方に限界が見えていた。
そこで、蔵屋敷がメインで回っているチャットツール開発チームを訪れた。同チームのリーダーは同期の御室で、エースプログラマーの仁和と共にスクラムを進めていた。上から目線の2人に苛立ちを感じる太秦と三条に対し、鹿王院は「教えてほしい」と懇願。誰よりもチームが機能してほしいという熱い思いを胸に秘めていた鹿王院は、どんな相手にでも教えを乞うことができた。こうして御室のチームを目の当たりにした太秦は、チームの方向性を見直し、再スクラムに取り組むことを決意する。
### 他チームとのDiffを取る
チームの方向性を見直すときは、**Diff（違い）を見つける**ことが重要である。そのDiffは、自分たちが具体的な行動を起こせる内容でありたい。
1. **未来の自チームとのDiff**
チームとしての理想像を描き、そこに至るまでのDiffを見つける。そのDiffを埋めていけるようなミッションを置く。
但し、理想像が描けていなければならない。
2. **過去の自チームとのDiff**
過去と比べてできるようになったことから、次の方向性を見定める。
過去の振り返り結果や、タイムボックスをさかのぼるタイムライン振り返りで成長を捉え、その延長線上にミッションを置く。
但し、視座や視野を広げにくく、安易な着地になりかねない。
3. **並行（他チーム）とのDiff**
他チームの動きを観察しDiffを見つけ、そのDiffを埋めていけるようなミッションを置く。
**自分たちが想像できてないような可能性**に気づくことができる。
但し、**他チームのやり方をそのまま真似すると失敗する**可能性が高まる。あくまで参考程度とし、自チームに合わせた応用方法を考える。
### Diffを取る視点
1. ユーザへの価値提供
2. ビジネスの成果
3. プロセスや技術、コミュニケーションの練度
4. 新たな領域の学習

### チーム・ジャーニーの見直し
ミッションが再設定されたら、チーム・ジャーニーも再設定し直す必要がある。必要に応じてメンバーの役割を再編成したり、チーム内の活動、情報、知識の透明性を高めたりする必要がある。

## 第6話　分散チームへの適応
### ストーリー
スクラムへの再挑戦を徐々に実行していった。これまでの問題点は、次のスプリントでバックログに挙げることで、問題点を挙げる意味がないという問題を解決した。
そんな中、チームに新たな試練が舞い込む。バーンダウンチャートをはじめとしたグラフによる見える化の機能が要件に追加された。新たなアーキテクチャが必要となる一方、新メンバーを2名招集。リモートで働く嵯峨と、フリーランスの壬生がチームに加わり、「同じ時間・同じ空間で働く」条件が崩れた。
スクラムは目に見えて崩れ始めた。最初は夜のミーティングで対応しようとしたが、先の要件追加もあり様々な場面でメンバー間のズレが頻発。三条が再びダウンする事態となった。
こうした事態に蔵屋敷は「状況の見方が甘い」と一蹴。スクラムイベントは昼の部と夜の部で分け、場をつなぐ工夫を行う。また、チームの型と役割を一新し、新フォーメーションで臨むことになった。
### 分断による6つの問題
* **時間の分断**
* 稼働時間帯が合わない。→スクラムイベントが難しい。
* 稼働時間に偏りがある。→1つのPBIあたりのコミュニケーションコストが高い。
* **経験の分断**
* 経験の幅が広くなる。→人によって仕事のやり方がバラバラ。
* **場所の分断**
* 非言語コミュニケーションが難しい。→伝わる分量が少ない。
* 相手の様子が分からない。→異常を検知できない。
* 背景が見えずタスク志向になりがち。→Whyが弱く間違いに気づきにくい。
こうしたコミュニケーションの分断が、複雑性を増していく。
### 雁行陣開発
チームのフォーメーションの一つ。個々人の特性を存分に発揮しつつ、チームバランスを取る戦法である。以下役割を記す。
* **プロダクトリード**（鹿王院）：プロダクトバックログのうち、**核となる背骨バックログ作成する役割。** プロダクトバックログと最初に向き合い、開発方針をリードする。コミュニケーションを必要としないメンバーに適する。
* **チームメンバー**（天神川・嵯峨・壬生）：**背骨バックログを前提とした、お肉バックログを作り上げるメンバー。** 追加メンバーには背骨バックログという「制約」の中での開発を行い、迷いなく開発できるようにする。時間の分断がされているメンバーに適する。
* **チームリード**（三条）：**プロダクトリードとチームメンバーを媒介し、互いに会話して齟齬を無くしていく役割。** 積極的なコミュニケーションで、突き進むプロダクトリードと他のメンバーとの調和を保ち、チームバランスを取る。働く時間に偏りが少ないメンバーに適する。
### チームのフォーメーション・パターン
雁行陣開発はあくまでチームのフォーメーション・パターンの一つであり、状況に応じて適宜変更していく。
フォーメーション・パターンの変更タイミングは、ミッションや状況を変更する際に、チームジャーニーの変更と共に行われる。
すなわち、ミッションやチームの状況が変わった時は、フォーメーションやチームジャーニーを見直し、新たな状態に適応すべきである。
また、リーダーなどの固定的な職務に縛られず、役割を置くと良い。

## 第7話 チームの共通理解を深める
### ストーリー
順調な他のチームに対して迷走が続く自チーム。砂子の焦りは機能を押し付ける形で開発チームに及んでいき、開発チーム側は「経営陣の意向」には逆らえない。そんな中で、蔵屋敷がチャット開発チームに正式に移ることになり、別れを告げにきた。蔵屋敷は「見えないことを見えるようにしなければ、それ以上先には行けない」と言い残し、一枚の紙を渡して去っていった。
ここで経営陣からボットを作るよう言われ、チームの困惑は頂点に。数スプリント経ってもまともなアウトプットが出ないチームに砂子は「スプリント中止」を言い渡す。
その後、プロダクトオーナーと開発チームが合同で、チームの現状を見つめなおした。過去のルールに縛られ、チーム外からの透明性が低い状態のため、信頼醸成が厳しい現実が浮き彫りとなった。そこで透明性を高めるべく、プロダクトオーナー向けのバックログを作成した他、作るべきものの共通理解を深めるべく仮説キャンバスを用いた。
だが、いざやってみるとまともな仮説すら立てられず、逆効果に。チームは崩壊寸前に陥った。
### プロダクトチームに生まれる分断
* **開発チーム内分断**：担当する役割の違いから分断が生まれる。特にデザイナーは扱う分野が異なるため分断が生じやすい。
* **開発チームVSプロダクトオーナー**：顧客側のプロダクトオーナーと制作側の開発チームでは、期待の違いをはじめとした様々な対立が生じやすい。
* **プロダクトチームVSチーム外**：いわゆる経営陣の意向との対立。経営側は現場の状況を知らないことが多く、一方的な介入が突然生じやすい。
### 透明性を高めるために
1. **見える化**：**チーム開発に必要な情報を誰でも得られるようにする。** チーム状況を説明する根拠となる。一方で情報への感度が低い人には見える化だけではなびかない。
2. **場づくり**：**お互いに働きかけを行う場を作る。** タイムボックスの中で定期的に情報に直面することで、チーム状況が定期的に共有される。一方、これだけではチーム内外の立場の違いは超えられない。
3. **一緒にやる**：**立場によらず、タスクに必要なメンバーやチーム全員で取り組む。** チームの境界を超えて情報の生成自体に参画でき、直接的にチーム状況が感じられる。
### 状況別の具体的な作戦
#### 開発チーム内の透明性向上
1. INPUT：プロダクトバックログ
2. **見える化**：カンバン、タスクボード、バーンダウンチャート等
3. **場づくり**：デイリースクラム、ワーキングアグリーメントやチームジャーニー等
4. **一緒にやる**：ペアプログラミング、モブプログラミング、モブワーク等
5. OUTPUT：プロダクトコード、動作環境
#### プロダクトチームの透明性向上
1. INPUT：仮説キャンバス
2. **見える化**：バリューストリームマッピング（価値の流れの見える化）
3. **場づくり**：スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブ等
4. **一緒にやる**：モブプログラミング（プロダクトオーナーも参加）
5. OUTPUT： **MMF（Minimum Marcketable Feature）** 市場に出せる最低限のフィーチャー
### 情報の解像度
情報の解像度とは、情報の粒度、すなわちニュアンスの細かさである。相手に合わせた解像度で情報をやり取りしなければ、認識がかみ合わなくなる恐れがある。
この問題の改善策には、一緒にやる範囲を広げていくことが挙げられる。大切なのは、**自分たちが何を知っていて、何を知らないかを知る**ことである。

## 第8話 一人の人間のようなチーム
### ストーリー
崩壊寸前のチームは、線表や管理ツールも使い物にならない状態となっていた。結局のところ「私たちは何をする者たちなのか？」自分たちのハンドルを自分たちで握るために、今一度原点に立ち返り、自分たちの声を自分たちで聞くことにした。
まともに使えなかった仮説キャンバスは、製品自体の対象ユーザが自分たちのような開発チームであったことが幸いし、自分たちがユーザとなって仮説検証を行うことができた。また、チーム結成当初の「出発のための3つの問い」を問い直した。私たちは「チーム開発の面倒くさいを無くす」ためにいる。この目的を基に、チームの・個人の目標をアップデートした。
こうして再出発したチームは一気に生産性を上げた。仮説検証で根拠のある仮説を提示していくことで、徐々に開発チームが優位となっていった。そして、新たなボトルネックとなった「皇帝」時代の厄介なコードを一掃する「新たなる希望」作戦を立ち上げたのであった。
### 出発のための3つの問いに再度向き合う。
結成時とは異なり、チームとしてのWhyが問える場合は、順番を変更する。
チームとしてのWhyに沿ったチームの、あるいは個人の在り方がハッキリする。
1. **私達は何をする者たちなのか。（チームとしてのWhy）**
2. **そのために何を大事にするのか。（チームとしてのHow）**
3. **自分はなぜここにいるのか。（個人としてのWhy）**
### 開発チームとプロダクトオーナーの境界に、プロダクトオーナー代行を置く
プロダクトオーナー代行は、両者のリテラシーや関心の差を埋め、「わかりあえなさ」を無くす役割を果たす。プロダクトオーナーとの分断が生じている際に用いる戦法である。
また、プロダクトオーナー代行は、**プロダクトとしてどうあるべきかの「基準」** を持たねばならない。この基準は、**仮説検証**によって形作られる。
#### プロダクトオーナー代行の仕事
* 翻訳の代理：開発チームとプロダクトオーナー双方が、相互に理解できるよう知識補完を行う。
* コミュニケーションの代理：物理的な時間や場所のズレを吸収する。
### 一人の人間のようなチームを目指す
プロダクトオーナー代行は、プロダクトチーム全体が十分に「一緒にやる」ことができ、一体感のある運営が行われるようになれば不要となる。
こうしたプロダクトチームは、「一人の人間」のように一体感のある開発を進めることができる。

###### tags: `読書`