書籍「今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント」レビュー

監訳者の長沢さんから献本いただきました。ありがとうございます。ようやく一通り読みましたのでご紹介します。

今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント

「カンバン」は、価値あるサービスや製品をすばやく提供することが求められる今日のIT現場にマッチする、シンプルなプロジェクトマネジメント手法です。現状どのような開発手法を行なっていたとしても、最小限の変更で移行でき、透明性あるプロジェクト運用と、流れるようなすばやい価値の提供が実現できます。

本書は、全体で約150ページと少ないページ数で、以下を説明しています。

• カンバンの全体像
• 導入と実践の方法（ウォーターフォール型のプロジェクトからの移行方法、スクラムからの移行方法を含んでいます）
• 保守運用との両立の方法
• 大規模プロジェクトへの適用方法
• カンバンをさらに進化させていく方法
• 背景となっている理論立て

語り口は平易でリズムもよく、図や画像も随所に用いられており読みやすいです。各章に配置されたMicrosoft社のXboxプロジェクトでの実践事例コラムも理解を助けてくれます。前述しましたが、ウォーターフォール型プロジェクトおよびスクラムからの移行方法を手厚く説明していますので、新たにカンバンを導入することを考えている読者には大いに役にたつことでしょう。

私が本書を読んで得た最大の収穫は、カンバンにおける見積りの方法です。本書の12ページにさらりと説明されている計算式がその答えです。どうしてこんな簡単な計算でよいのでしょう？それは、ふたつの理由によるものかと思います。ひとつは、見積りはその時点での予測であり、それ以上でもそれ以下でもないからです。見積りは方向を示すコンパスであり、探検者は歩を進めながら何度もそれを眺め、目的地に近づいて行きます。一歩も歩かないで正確な答えを得ることはできません。見積りに対するこのスタンスは、書籍「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」に通じています。そしてもうひとつの理由は、カンバンがプロジェクトの流れに着目しており、仕掛り中の仕事を極力減らすことに関連しています。このために、複雑（なわりに正確でない）な見積りに依存する必要がないのだと考えられます。「アジャイルプロジェクトはいつ完了するのかはっきりしない」というよくあるイメージに対しても、本書は「納期を守る」として一章を割いて説明し答えています。

カンバンは、チームが今どこにいるのかをあからさまなほど見える化します。もしかしたら、カンバンを始めたばかりのチームは、カンバンが突きつける現実に困惑し、以前の計画主義的なやり方（バッファが多いので問題が隠れやすい）に戻りたいと思うかもしれません。しかし、それこそがカンバンのねらいだということを忘れないでください。カンバンはチームやメンバーを辱めようとしているわけではなく、現状を見える化し、問題にひとつひとつ対処していくことを促しているのです。チームには、改善と学習のマインドを持って柔軟かつ積極的に現実に対処していくことが求められるのです。最小限の変更で始められるカンバンですが、このような体質改善も徐々に行なっていくことになるでしょう。カンバンがもたらす見える化はそれを促進してくれます。また、ファシリテーションやサーバントリーダーシップの考え方やテクニックが活きるでしょう。書籍「カンバン仕事術」の第10章あたりも参考になると思います。

カンバンは、プロダクトの開発、保守、運用に「流れ」を作ります。瞬間最大風速や、最終的な成果だけに着目するのではありません。滞りなく流れるように価値を届けられるようになるために、カンバンは継続的な改善と学び・成長を支援してくれます。本書をガイドに、価値あるサービスや製品を、やりがいを持って提供できるように、進んでいきましょう。

以下は各章の概要と、山本の感想です。

• 第1章 経営陣の同意を得る
  • カンバンへの取り組みを開始するための前提条件
    • 組織に新しいやり方を導入する正攻法として、経営陣への提案書の提出というフォーマットを用いている。経営者（＝カンバンについて全く未知）に対する説明という体で、読者に対しても同時に説明しているのはうまい。
• 第2章 カンバンのクイックスタートガイド
  • カンバンの基本的な手順の解説
    • これまでのやり方を一個流しにするだけですよと言っているが、同時にそれによって浮き彫りになるボトルネックにリソースを投入して、全体の流れをよくする、プロセスを改善する、ということも求めている。これはなかなか高度。まあ、いきなり初日からできるとは思えないし、できなくても、順次取り組めばいい。
• 第3章 納期を守る
  • バックログの準備と優先順位の設定、時間とリソースの見積り
    • 「顧客に対して、効率よく、高い品質の価値を提供する」ためのアクティビティとツール、考え方。本章はなぜか訳がこなれていないので戸惑うが、内容的にはとても重要なところなのでがんばって読みましょう。

• 第4章 ウォーターフォールからの適応
  • ウォーターフォールからカンバンへの適応の手引き
    • バッチサイズを小さくすることに戸惑う人がいるかもしれない。緊急のバグ修正のやり方を常に行っているような感じと理解すればいいかもしれない。
    • カンバンはスモールバッチのメリットを活かす。スモールバッチのウィークポイントは作業フローの調整が必要なこと。各ステップが個別最適で作業してはだめ。WIP制限によって調節され、ボトルネック工程を作業中のメンバー以外は、ボトルネック工程を支援する。
• 第5章 スクラムからの進化
  • スクラムからカンバンへの進化の手引き
    • スクラムからカンバンへの移行はそれほど大変ではないかもしれない。スプリント計画ミーティングがないことや、スプリントレビューが（顧客が求めない限り）ないことに戸惑いがあるかもしれない。これらについても、まとめてはやらない、ジャストインタイムでやる、ということだろう。
• 第6章 コンポーネント、アプリケーション、サービスのデプロイメント
  • 生み出した価値を顧客に提供すること
    • リリースあるいはデプロイについて。アジャイルプラクティスとして普及している継続的XXXと、カンバンは自然に整合するという話。まあ、そうだろう。この章に欠けているものがあるとすれば、継続的XXXなんていっさいやっていなかった組織はどのようにカンバンに移行するのかということ。その回答は、改善すべき課題として認識して、徐々に取り入れていきましょうということに尽きる。さいわい継続的XXXに関するツールやノウハウは比較的容易に手に入るので、いいでしょう。
• 第7章 大規模な組織でカンバンを使用する
  • 大規模なプロジェクトにはビジョン、目標、計画が必要不可欠である。その構築の仕方は本書の範囲外である。本書では、計画がある前提で、個々のチームがカンバンによってマネジメントしプロジェクトに貢献する方法を示す。
    • 重要なフィーチャーから作る、モックを利用する、全体のスループットに着目し、遅れているコンポーネントチームを支援する、など、ここまでに語られたことと本質的に同じ考え方でよい。
• 第8章 サステインドエンジニアリング
  • リリース後のソフトウェアの保守にカンバンを応用する。どのような体制、運用がよいか。
    • インシデントも開発要求項目と同様にカンバンで管理できる。割り込み、優先順位の入れ替えが頻発するので、そこは覚悟しておこう。本章は構成が若干洗練不足感があるが、最後まで読めば分からないことはない。
• 第9章 さらなる方策とカンバンを超えて
  • カンバンの理論付けと、さらなる改善を図るための方法
    • トヨタ/リーン生産方式や制約理論への言及、それらを踏まえた、より大きなプロセス改善に関する考察。カンバンは改善のプラットフォームなので、導入したままずっと使い続けることもできるだろうが、さらなる変化向上を図るのにも役に立つだろう。