# カイゼン・ジャーニー
市谷聡啓
新井剛　共著
## 第1部　一人から始める
### 登場人物
江島：主人公。２０代半ばのプログラマー。問題提起に積極的だが、周りとの温度差があり、生意気な印象を持たれることが多い。（AnP社所属）
石神：江島にアジャイル開発を教えてくれた先達。
片瀬：中途採用の江島と同い年のプログラマー。江島のタスクボードに興味を持ち、アジャイル開発の仲間に加わる。

### ストーリー概略
（第1話）
石神は自分の話をしている時はすごく楽しそうだった。
石神「あなたは何をしている人なんですか？」
江島「…」

（第2,3話）
江島は1人でアジャイル開発の一歩を踏み出した。
1人振り返り→主観に陥る。チームの振り返りの重要性を痛感。

（第4話）
要件定義の粒度が大きい→曖昧さ→認識にズレ
分割して統治せよ。

（第5,6話）
朝会はタスクマネジメントの整理の場。
他人に依頼していたタスクの管理が杜撰
→自他のタスクと進捗状況を明確にしたタスクボードを作成。
★タスクボードに興味を持った片瀬はアジャイル開発の仲間になった。

（第7,8話）
石神の教えを聞いて、社内に訴えかけていかなければと思う。
片瀬と2人で社内勉強会を行い、石神に江島は1話の「アンサー」をぶつけた。勉強会は成功に終わり、二人は越境した。

### 学び
* 普段の職場から外に出て、刺激を得よう。
* 外部から得た知見をそのまま適用しても失敗する。状況や制約を踏まえて捉えなおす必要がある。
* 仕事のカイゼンは、見える化から始まる。（スプリントプランニング、カンバン、朝会、レトロスペクティブ）
* 許可を求めるな。謝罪せよ。
* 過去、現在、未来から、現在を変える→時間を味方につける。
* 振り返り手段：KPT(Keep,Problem,Try)や、事実、意見、対策に分ける方法など。
* タスクの粒度が大きすぎると、顧客やチームメンバー同士で認識のズレが生じやすい。大きなタスクはできるだけ小さくし、何をすればタスク完了なのかをはっきりさせることが大切である。
* いつだって始めるのは自分ひとりからだ。だが、君はいつまでも一人というわけではない。

## 第2部　チームで強くなる
### 登場人物
＜プロダクト開発チーム＞
＜プログラマー＞
江島：主人公。AnP社のプロダクト開発チームに異動した。蔵屋敷にプロダクト開発チームのリーダーを任命される。
七里：江島にとって年上だが、社歴は若い。めんどくさがりで生意気。
ウラット：新卒入社のタイ人プログラマー。日本語は流ちょうに話す。まじめな頑張り屋。
土橋：チーム最年長プログラマー。プロダクトオーナーを務める。以前は品質管理部に所属しており、テストが得意。
浜須賀：プロダクト終盤で加入した、2年目のプログラマー。真面目でテキパキとコードを書く。
＜チームをサポートする先輩方＞
蔵屋敷：1部ではかつてお世話になった先輩。2部以降は社内のテスト開発支援ツール作成の責任者として江島をリーダーに任命する。
西方：スクラムの事なら何でも知っているスクラムマスター。個人事業主で、様々な現場を渡り歩く。

### ストーリー概略
（第9話）
8話の社内勉強会から1年が経過した。片瀬は会社を去った。
蔵屋敷からの提案で、テスト管理支援ツールを作成するプロジェクトへ。

（第10話）
どうなったら完成といえる？
完成の定義を決め、何を行っているべきで、どんな状態なのかを明確に。

（第11話）
手いっぱいで余裕がない。なぜ急ごうとしているのか。全部やるべきなのか。
西方「このチームは何のために仕事をしているの？」
AgileはWhyから始まる。まずはWhyとHowを明らかにせよ。

（第12話）
仕事の流儀がそれぞれ違う。意見対立から悪循環へ。
Working Agreementを定めて、チームのルールを設定する。

（第13話）
メンバーに対する価値観がバラバラだと、期待値のずれから対立を生む。
メンバーの事をもっと知る機会を設けることで、得意分野や価値観を共有できる。

（第14話）
チームが能動的に仕事をこなし始めていた一方で、朝会の「問題ありません」が淡々と続くことに違和感。
プロダクトバックログアイテム単位で縦割りが起きており、各単位内での問題が共有されていなかった。
結果、ウラットさんの疲弊を見抜けなかった。→ファイブフィンガー等を活用して、チームの問題管理を。

（第15話）
終盤に差し掛かり、プロダクトオーナーの完成判断が難しくなってきた。
スプリントレビューで、本当に価値あるプロダクトで、作成する必要があるのかを全員で判定する。

（第16話）
最終盤で、機能が足りていないことが発覚。全機能の搭載は困難だった。
進むべき先をとらえて現在を正すべく、むきなおり合宿を決行した。
チーム全体で現状を見つめなおし、あるべき姿に向け何ができるのかを整理しバックログに。
バックログの重要度・効果の高さを設定し、達成期限も明確にする。
合宿は、むきなおりによる予定の整理ができるほか、普段とは違う雰囲気で仕事に集中する場所が用意できたり、ネガティブな気持ちをリフレッシュし、高揚感を得たりするのにうってつけの場となった。

（第17話）
残り2スプリントで、突如2年目の浜須賀が加入。今更教育をするわけにもいかず困った。
そこで、星取表（スキルマップ）で全員の現在のスキルを確認した。
また、モブプログラミングを取り入れ、全員で1つの課題に取り組み手戻りを防いだ。

（第18話）
最終スプリントで蔵屋敷は、今のスクラムをやめると決めた。西方さんと対立し、西方さんはチームを去ってしまう。
江島達は、バリューストームマッピングを用いて、これまでの全体の開発の流れを振り返り、手戻りが多い箇所やボトルネックとなっている場所等を突き止め、適切なカイゼン手法（TDDなど）を導入した。
そして、タスクボードはカンバンに進化した。全体のワークフローを図で追いながら、どのバックログが今どの部分に位置しているのかが明確になった。
カイゼンを繰り返した結果、晴れてリリースとなった。カンバンはその後の運用保守でも役立った。

（第19話）
プロジェクトが終わると、チームも解散となった。解散の際はチームメンバーにこれまでの感謝を伝えるとともに、チームの活動を振り返り、教訓を次の仕事に生かせるよう全体振り返りを行った。そして次のジャーニーへ…

### 学び
* スクラムは、振り返りながらカイゼンする経験主義。
* Fail Fast（早く失敗する）
* 完成の条件→メンバーが共通認識で持つ完成の定義のこと。
* 受け入れ条件→要求を満たしていると判断できるリストのこと。
* インセプションデッキでWhyとHowでチームのあり方や目標を明確にする。
* 成功の循環モデル：結果の質→①関係の質→②思考の質→③行動の質→④結果の質…
* ドラッガー風エクササイズ：何が得意か、どうやって貢献するか、大切な価値は何か、メンバーは自分に何を期待しているか、の4つの観点でメンバー同士で共有する。心理的安全性が高いほうが良い。+その期待はあっているか。の5つの質問があると尚良い。
* トラックナンバー：チームメンバーのうち、トラックに轢かれたら（機能しなくなったら）プロジェクトの進行に支障をきたす人数。
* ファイブフィンガー：５本の指を用いて、現段階の進捗を５段階評価し、自分の考えを説明する。少ない本数のメンバーから順に話し、チームで問題をサポートする場を持つ。
* 0-100ルール：成果物レビューに対し、0か100の二択で判断すること。たとえ進捗度が99％でも、ユーザが使えない限り価値は生まれない。
* クネビンフレームワーク：プラクティスの質を表す。シンプルなものはベストプラクティス、煩雑なものはグッドプラクティス、複雑なものは出現するプラクティス、カオスなものは新規プラクティス、と分かれる。
* リファインメント：プロダクトバックログをメンテナンスし、変更する。社会の情勢などで絶えず変わり続ける仕事に対応する。
* 狩野モデル：顧客の感じる品質の性質をまとめたモデル。
* 当たり前品質　実装評価-　未実装評価×
* 一元的品質　実装人気高+　実装人気高△
* 魅力的品質　実装評価+　未実装評価-
* 振り返りと向き直り
* 振り返り　過去を顧みて現在を正す。
* 向き直り　進むべき先（未来）を捉えて現在を正す。
* モブプログラミング：全員で1つの課題に取り組むプログラミング手法。操作は10分程度で適宜交代し、全員がブレインとなる。圧倒的に手戻りが減り効率的になるほか、チームコミュニケーションによる学習効果や達成感が得られるメリットがある。
* TWI（Training Within Industry）→JI（Job Instruction）：職場教育の手法の一つ。中でも「仕事の教え方」は、準備→説明→実施→指導の４プロセスで、効果的な仕事の取り組みを教えることができる。
* バリューストームマッピング：一番後ろの工程から全体プロセスを追って見える化し、手戻りやボトルネック、不安の多い箇所を見つけ、改善していく。
* リードタイムとプロセスタイム：プロセスタイムはプロセスが行われている実質時間で、リードタイムは、次のプロセスに進むまでの所要時間を表す。
* ECRS：Eliminate（排除）、Combine（結合）、Rearrange（交換）、Symplify（簡素化）　業務改善の方法論の一つ。
* ポストモーテム（事後検証）：プロジェクト終了後にプロジェクト全体を振り返り、チームメンバーに感謝を伝えるとともに、課題や教訓をあぶりだす時間を設ける。

## 第3部　みんなを巻き込む
### 登場人物
＜AnP社＞
江島：主人公。AnP社のプロダクト開発チームからSI部門に帰還。蔵屋敷が抜け、リーダー代理を務める。
由比：新リーダーに着任した中途入社の社員。経験豊富で要件定義やモデリングも得意。話し方は手厳しい。

浜須賀：駆け出しプログラマー。コードにはなにかとうるさい。
＜MIH社（顧客：インテリアメーカー）＞
砂子：新プロジェクトでプロダクトオーナーを務める。明るく励ますタイプだが、言葉はやや乱暴。

### ストーリー概略
（第20話）
江島はSI部門に戻り、新たにMIH社のBtoBのECサイトの構築のプロジェクトに着任した。
半月も経たずにリーダーの蔵屋敷が大型炎上案件に駆り出され、江島がリーダー代理を務める。
そこへ、新たなリーダーとして由比がやってきた。ウォーターフォール型で経験豊富な由比との対立が深まった。
さらに悪いことに、クライアントのMIH社がコンセプトをBtoCに変更するといい、チーム全体に危機が生じた。
江島はチームをまとめるため、インセプションデッキやドラッガー風エクササイズ、リーダーズインテグレーションを実行。
江島はリーダー、由比は設計・アーキテクチャ検討責任者と、チームメンバーへの期待と責任、及びチームが向かっていく方向性をはっきりとさせた。

（第21話）
チームメンバーの半数が例の大型案件に駆り出され、人手が足りず外部委託することに。
かつて共に働いた七里の紹介で、フリーランスの万福寺とマイが加入。
見積もりで意見が割れたが、プランニングポーカーによって、全員で最適な見積もりが出来上がった。

（第22話）
例の大型案件は未だに炎上が収まらず、由比さんまで駆り出されてしまう。
そんな中、API側を開発する在庫管理チームとのコミュニケーションがとれておらず、MIH社側との決定事項が両チームで共有できていなかった。
両チームはむきなおりを行い、スクラム・オブ・スクラムで、チーム代表による共有の時間を設けた。

（第23話）
今度はデザイナーチームと機能開発部門のすれ違いが生じ、議論が紛糾した。
そこで、合宿という形でユーザーストーリーの作成を行い、ユーザーの価値を両チームで共有した。Whyから始めることで、大幅に開発工数は少なくなった。

（第24話）
炎上案件以降、顧客重視をうたうAnP社は、江島を営業に駆り出す。そこでプロダクトオーナーの袖ヶ浦から、無理難題なプロジェクトを押し付けられる。
江島は、前プロダクトオーナーの矢沢を呼び、仮説キャンバスを作り上げた。そこで江島は顧客が求める目的に立ち返り、仕様変更を行いリリースまでに間に合う計画を立てた。結局プロジェクトは見送られ、袖ヶ浦の暴挙に矢沢の苦境を思い知ることになった。

（第25話）
開発が残り3スプリントなり、チームに余裕ができ始めていた。しかし、ここにきて3か月はかかるスプリントバックログを再び袖ヶ浦が押し付けてきた。
袖ヶ浦は請負契約を持ち出し、完成させなければ契約でないと脅す。
江島はユーザーストーリーマッピングを行い、価値のある必要最小限のプロダクト(MVP)を見極めてリリースし、ローンチ前に不要なものを作らないようにした。
しかし、対象とした顧客は想像に過ぎないと袖ヶ浦に一蹴されてしまう。

（第26話）
袖ヶ浦に一蹴され無力感と焦りが募る中、江島は実際に対象顧客にインタビューすることを提案する。限られた時間の中でメンバーやかつての協力者の力を借りて、20人のインタビューをこなし、再度袖ヶ浦に挑む。
相変わらずそっぽを向く袖ヶ浦に、「あなたは何をする人ですか」と問いかける。ようやく江島達を認めたのか、袖ヶ浦はチームの意見に賛同した。
こうして、めでたくデプロイを終えた。
（第27話）
無事に大団円を迎えたが、社内にはまだまだアジャイル開発の「境界」があった。
袖ヶ浦はAnP社時代に開発手法の改革を求めてMIH社へ「越境」したが、会社を変えることはできなかった。江島は仲間と共に「越境」し、勉強会を通じて会社全体を変えていく雰囲気を作り上げるようになった。初めは1人でも、2人目、チーム、そして組織と広げていける！

### 学び
* インセプションデッキやドラッガー風エクササイズは、チームが変わった時などに適宜アップデートを！
* リーダーズインテグレーション：メンバーがリーダーへの期待や知りたいこと、知っておいてほしいことなどを出し合い、リーダーと共有する。
* 上記3つは、心理的安全性を高めて行うことが重要である！（モダンアジャイルの基本原則の一つ：安全を必須条件にする）
* プランニングポーカー：見積もりを行うための技法。フィボナッチ数列が書かれたカードのうち、ユーザーストーリー（クライアントの要件）に対しての見積もり数値をチーム全員で出し合い、その後話し合ってチーム見積もりを決定する。
* リリースプランニング：スケジューリングの際に、期日やコストなどを考慮して、リリース日を見通すこと。
* 計画よりも計画づくりを！
* 計画はたいてい上振れするため、期日よりも前に終わり、バッファ（予備日）を設けることが多い。
* CCPMは、バッファを個別のスプリントでは取らず、最後にまとめて取ることで、開発日数を削減できる。
* スクラム・オブ・スクラム：複数のスクラムチーム同士で、状況を共有する時間を設ける。
* 仮説キャンバス：ユーザーとサプライヤー、2視点からプロジェクトの意義を問うキャンバス。ユーザーはなぜその製品を必要としているのか、お金を払ってまで得たい利点とは何かを捉えることが重要である。
* ユーザーストーリー：ユーザーが得る価値とは何で、なぜその価値が必要なのかを共通理解としてまとめる。
* ユーザーストーリーマッピング：ユーザーストーリーに即してユーザーの行動を分析し、理想と現実の差を埋めるために不足している部分を洗い出す。洗い出した項目のうち、優先順位が最も高い項目群をMVPとして定義する。
* ユーザーインタビュー：実際に顧客となる層の人物にインタビューし、必要な事実を捉える取り組み。
* ハンガーフライト：組織を変えていく中で必要な、経験と知恵をつなぐ機会のこと。開発の当事者をはじめ、アジャイル開発に興味がある人間に参加してもらい、取り組みを伝える貴重な場となる。
###### tags: `読書`