「リーン開発の現場 カンバンによる大規模プロジェクトの運営」を読んでみた

最近はアジャイルに関する本を読んでいました。
その中で「リーン開発の現場 カンバンによる大規模プロジェクトの運営」という本が目に留まり、カンバンを基にした実際のプロジェクトの様子について解説されているということで、参考になりそうな気がしたので読んでみました。
全てについて書くと長くなってしまうため、今回は第一部「僕らのやり方を伝えよう」についてまとめてみようと思います。

感想

実際にどのようにプロジェクトを進めたかについて、分かりやすく書かれており、大変参考になる内容でした。本書に記載されている通り、自分たちの現場での答えは自分たちで出すしかないため、あくまで参考程度に、自分たちに適したやり方は何なのか考えながら、開発に取り組んでいきたいと思いました。
アナログなカンバンボードについては、最近では様々なツールも登場し、便利になってきているので、必ずしもアナログである必要はないようにも感じました。

巨大な像を分割せよ

• 大きなプロジェクトにおいてリスクを最小化する方法は「巨大な像を分割する方法」を見つけること。
• システムを何回もリリースするインクリメンタルリリースを考える。
• 理想を言えば、それぞれの機能はそれ自体がユーザーに価値を届けるもので、届けた後にユーザーからのフィードバックがもたらされるものであるべき。

顧客を巻き込む

本書では警察組織内部のプロジェクトが紹介されており、以下のようにやり取りしていた。

• ある1人が顧客として振る舞い、抽象度の高い機能一覧（エピック）を管理。
• オンサイトユーザーが開発チームと同じ建物にいて、フィードバックしたり、質問に回答。
• 受入テストユーザーグループにリリース候補版を試してもらい、フィードバックを得る。
• 最初のリリース後、パイロットユーザーに利用してもらい、フィードバックを得る。

チーム編成

プロジェクトでは、以下のようなチーム編成となっている。

1. 要求分析チーム（何人かは機能開発チームに所属しサポート）
2. 3つの機能開発チーム（職能横断型）
3. テストチーム（何人かは機能開発チームに所属しサポート）
4. その他（プロジェクト管理者、コーチなど）

当初は作業単位でチームを分けていたが、責任を押し付け合い、自分の仕事だけを完了しようと考えがちになっていた。しかし、職能横断型チームにすることで、コラボレーションの質が改善された。

デイリーカクテルパーティー

プロジェクトでは、以下のように3段階に分けてミーティングを行うことで、プロジェクト内のコミュニケーションの経路を「つなぐ」ようにしていた。

1. 機能開発チームのスタンドアップミーティング
   • デイリースクラムと似たような内容
2. スペシャリティ同期ミーティング
   • テスター、アナリスト、開発リーダーがそれぞれで集まって状況共有
3. プロジェクト同期ミーティング
   • 各チームのリーダーやPMなどが参加して、プロジェクト全体の課題などについて議論

プロジェクトボード

プロジェクトでは、以下のようなカンバンシステムのプロジェクトボードを利用している。

アイデア	要求分析	機能	次の10機能	開発中	システムテスト準備OK	システムテスト中	受け入れテスト準備OK	受け入れテスト中	本番リリース準備OK	本番
～	～	～	～	～	～	～	～	～	～	～

1. 概要レベルの機能（エピック）が「アイデア」に入る（エピックカード）。
2. エピックカードは「要求分析」に移動し、機能レベルでユーザーストーリーに分割。ユーザーストーリーは機能カードに書いて、「機能」に移す（機能カード）。
3. 「機能」の中から優先して開発するべきトップ10の機能を選択し、「次の10機能」に移す（隔週で開催するミーティングで実施）
4. 機能開発チームは準備ができたら、「開発中」に機能カードを移し、開発作業を進める。機能を開発し、機能レベルのテストが完了出来たら、「システムテスト準備OK」に移す。
5. テストチームは「システムテスト準備OK」にあるカードを「システムテスト中」に移して、テストを開始する。テストが完了すると、受け入れテスト環境にリリースして、「受け入れテスト準備OK」にカードを移す。
6. カードを「受け入れテスト中」に移し、実際にシステムを利用するユーザーに受け入れテストを行ってもらう。
7. 受け入れテストによるバグの修正が完了したら、「本番リリース準備OK」にカードを移し、リリースを行う。

僕たちのリズム

• 振り返りと計画ミーティングは隔週開催
• デモとシステムテストは随時実施
• リリースは2か月ごと

緊急の課題に立ち向かう

• カンバンボードを交通システムで例えると、車（機能カード）の流れをスムーズにしたいので、ボード（道路）を車で一杯にしようとは思わない。流れを速くするためにスペースやゆとりが必要になる。
• 緊急度が高く、早急に処理する必要があるカードにはパトカーのマグネットをつけるようにしている。
• 車の進む道を塞いでしまう障害にはピンク色の付箋を使い、カンバンボードの右端にある「トップ3の障害」ステージに貼り付ける。
  • プロジェクト同期ミーティングでは、こういったブロッカーを取り除くことに注力する。

カンバンボードをスケールさせる

• プロジェクトボードに加え、3つの機能開発チームがそれぞれのチームボードを持つ。
• プロジェクトボードの「開発」ステージは3つの水平なレーンに分割されている。
  • 開発する機能は「次の10機能」ステージから3つの機能開発チームのそれぞれのレーンに流れていく。
• 機能開発チームは機能カードを作業に分割し、付箋に書いていく。この分割作業は要求分析ミーティング（アナリスト、テスター、開発者が洗い出し）で実施される。
• チームボードにも同じ機能カードが存在し、分割した作業の付箋も貼り付けている。

プロジェクトのゴールを追え

• プロジェクト全体のゴールをカンバンボードの右側に貼り付けている。ゴール達成後、新たなゴールを書く。
• プロジェクト同期ミーティングで「ゴールを達成できるか？」と聞き、全員が1~5で答える。
• 1や2が出るたびにゴールを再評価して、何をやるべきか議論する。

準備OKを定義する

• プロジェクトボードでは各ステージの上にそのステージの完了の定義を書いている。
• 開発準備OKとは
  • IDが振られている
  • 連絡窓口になるアナリストが決まっている
  • チームによって見積もられている
  • 機能カードの裏に受け入れテストのシナリオが書かれている
• システムテスト準備OKとは
  • 受け入れテストがエンドツーエンドで自動化されている
  • リグレッションテストが通る
  • 開発者以外のデモが完了している
  • コミットのコメントを分かりやすく残している
  • チームのテスト環境でテストされている
  • トランク（メインブランチ）にマージされている

技術課題をさばく

• ボードの「次の10機能」ステージの真下に「次の5つの技術課題」ステージを設ける。
• 次に開発する10の機能と5つの技術課題を継続的に決めていく。
• 機能カードと区別できるように緑色のシールを貼る。

直ぐにバグをつぶせ

• バグを見つけても、開発者とテスターはその場でバグを直してしまう。後で修正するより、その場で対面のコミュニケーションで修正する方が効果的。
• すぐに直すほど重要ではないバグはバグトラッキングシステムに記録する（バグ一覧が一杯ではない or 一覧にあるバグより重大な場合のみ）。
• バグ一覧の登録数を30に制限することで、長くなった一覧を管理するための退屈な変更管理ミーティングは不要になった。

バグを可視化する

• トップ30のバグの中で、さらにトップ5のバグを選び、ボードの「次の5つの技術課題」ステージの真下に「次の5つのバグ」ステージを設ける。

繰り返し発生するバグを防ぐ

• 何度も発生する類のバグは、テスターのボードの中にある「繰り返し発生するバグ」というステージに貼り付けている。このステージに貼られるバグは厄介なものに限られている。
• 機能開発チームは欠陥防止ミーティングを開き、「どうやってバグが入り込んでしまったのか」という根本原因の分析を行う。手強い問題の場合は因果関係図を描くようにしている。
• バグの根本原因を分析すれば、そのバグが本当の問題ではないことに気づくはず。それらはプロセスのバグから生み出される症状である。

継続的プロセス改善

• 僕らのプロセスは設計したというよりも発見したもの。まず僕（著者）がやったのはプロセス改善エンジンの導入だ。
  • 明確さ
    • プロジェクトの状況が誰にでも伝わるように、目出す場所にアナログボードを置く。そして、誰もが理解できる明確なゴールを持つ。
  • コミュニケーション
    • 機能開発チーム、クロスチームの両方で定期的にプロセス改善ワークショップを開催する。
  • データ
    • シンプルなメトリクスを使って動向を追跡する。

チームの振り返り

• 1～2週間に一回行い、その長さは30分から2時間とさまざま。
• 重要な機能として、エスカレーションポイントを見つける、という点もある。エスカレーションポイントとは、チームを超えて影響をもたらしたり、他のチームと一緒に解決しなければならない問題や改善点のこと。

プロセス改善ワークショップ

• プロセス改善ワークショップとは、それぞれのチームから一人ずつ代表者が集まるスクラムオブスクラムの形式で実施する振り返り。
• 初めは週一回のペースで行っていたが、隔週開催へと減らした。
• 振り返りの全体像
  1. 場を設定する
     • テーマを設定して、それに集中する
  2. データを収集する
     • 前回から現在までの成果や難題について細かく調べる
  3. アイデアを出す
     • 得られた情報について、どういう意味があるか議論する。辛いポイントを軽減する選択肢を特定する
  4. 何をすべきか決定する
     • どの変更を実施するか決定する
  5. 振り返りを終了する
     • 次のワークショップまでに誰が何をするか決定し、何が起きるか推測する

プロセス改善の度合いを調整する

• 毎週実施していたプロセス改善ワークショップが突然の変化による混乱のもととなっていた。前回の変更から騒ぎが収まっていないのに、新しい変更を伝えられた結果、メンバーが混乱し、ストレスとなっていた。
• 変化の速度を緩めるために、チームを超えた影響をもたらす変更を行いたい場合は、プロセス改善提案書を書いてもらうようにしている。
• テンプレートは、以下のようになぜ変更したいのかについて考えさせる形になっている。
  • 「あなたが解決したいと考えている問題は何か」
  • 「この変更によって誰が影響を受けるのか」
  • 「この変更を実施する上でどのように進めていくのか」
• もしプロセス改善の数を制限しなかったら、混乱を生み、その混乱がプロセス改善がもたらす利益を相殺してしまう。

WIPを制限する

• ボード上の各ステージの一番上には赤くWIP制限（仕掛り作業の制限）を表す数字が書かれている。
• WIP制限の目的は、過剰なマルチタスクを避けるためと、後続のプロセスに負荷を掛けすぎないため。
• もしテスターが大量の作業を抱えていたなら、新しい機能を開発し続けて、テスターの仕事を増やすのは避けたい。代わりに、開発者はテストチームの支援やテストチームの負荷を下げるためにあらゆる作業をするべき。

機能開発だけWIP制限する

• 技術課題とバグ修正には制限を適用していない。
• バグの多くは本当に対処しなければならなくて、とても小さいため。
• 技術課題は、それらを解決することで、後続のプロセスにあるボトルネックを解消する場合がある。自動化されたテストを沢山作ったり、テスト基盤を改善したりなど、システムテストを手助けするような技術課題もあるため、WIP制限には含めていない。
• また、メトリクスに利用しているサイクルタイムとベロシティの計算には、機能だけを含めているため、その一貫性を保つためにも機能開発のみに制限を適用している。

ベロシティ

• いくつの機能が「受け入れテスト準備OK」に辿り着いたかを数えたのがベロシティ。
• ボードの下にベロシティを記録として書き出し、計測したカードを「受け入れテスト準備OK（先週分）」に移動する。
• ベロシティを使って、バーンアップチャートを作ることで、リリース計画が現実的か確認するのに役立つ。また、問題を目立たせ、プロジェクトに緊迫感を持たせることや、プロセス改善を可視化することにも繋がる。

ストーリーポイントを使わない理由

• 完了した機能の数を数えるだけで、どうしてベロシティを測定できていると言えるのか。
• 機能の数をベロシティにした場合、小さい見積もりの機能を沢山開発すると、ベロシティは増える。しかし、実際のデータを見てみると、機能のサイズは期間で均等に分散していた。サイズが均等に分散するのであれば、ベロシティの計算のために、ポイント付けする必要はない。完了の数を数えるだけで良い。

サイクルタイム

• ある機能が「次の10機能」ステージから「受け入れテスト準備OK」ステージに到着するまでの時間を計測している。
• 機能の大きさとサイクルタイムの間に相関関係は無かった。いくつかの小さな機能の開発に7週間掛かった一方で、いくつかの大きな機能の開発には2週間しか掛かっていない。機能の大きさがサイクルタイムに影響を及ぼす主な原因ではないことが分かる。

プロセスサイクル効率

• プロジェクトでは計測していないが、できれば計測したかったメトリクスのひとつ。以下のように計算する。

$$プロセスサイクル効率（％） = \frac{\text{作業日数}}{\text{経過日数}}$$

• 経過日数：機能がボードを左から右へ横切っていくのにかかった日数
• 作業日数：実際に開発にかかった日数
• 例えば、ある機能の作業日数は2日だったが、ボードを横切るのに20日もかかっていた場合、プロセスサイクル効率は10%になる。

スプリントとリリースの計画

• スプリント計画ミーティングでは、「次の10機能」ステージにどの機能カードを移動させるかを決める。
• スプリント計画ミーティングは2部構成になっており、前半はバックログの手入れ、後半は次の10機能の選択。

バックログの手入れ

• バックログの手入れでは、機能を「開発準備OK」な状態にする。
• 参加者たちを職能横断型チームになるように、小さなグループに分ける。それぞれのグループは機能カードを選び、プランニングポーカーを利用して見積もる。また、受け入れテストにふさわしい内容を議論し、合意を取り、カードの裏側に記載する。

次の10機能の選択

• 「次の10機能」ステージにどの機能を入れるべきか、どの機能を入れないべきか、以前の機能も含めて議論する。
• 評価するときは次のような観点で考える。
  • ビジネス価値：どの機能が顧客を最も幸せにするか
  • 知識：どの機能が知識を生み出し、リスクを減らせるか
  • 資源の活用：各チームの作業量に偏りが出ないようにする
  • 依存性：まとめて開発したほうがよい機能はどれか
  • テストのしやすさ：一緒にテストするのが合理的な機能がどれか

アナログなカンバンボードを使う理由

1. 進化
   • ボードは何回もレイアウトを変えているが、ほとんどのデジタルツールでは全ての変更に対応できない。
   • ルールを増やしたときに一切のトレーニングを必要とせず、15分以内にボードを変更できるほうがいい。これを実現するのに、紙のカードに優るものはない。
2. コラボレーション
   • アナログなカンバンボードでなければ、デイリーカクテルパーティーを開催するのは難しい。メンバーが壁からカードを取ったり、取ったカードをヒラヒラさせながら話したりはできない。
   • デジタルツールなら、自席に座っている間もボードを更新できるが、ボードを通じたコラボレーションの機会が減ってしまう。

実験しよう

優れたプロセスは進化の結果として表れる。現在行っているプロセスが重要なのではない。プロセスを改善するためのプロセスこそが重要。