本書の扱いとして、ソフトウェア開発におけるアジャイル方式をスクラムに限定することなく解説しておく、というのが本筋だったので、ソフトウェア開発そのものではなくマネジメント（スクラムマスターとかプロジェクトリーダーとか）に焦点が当たっています。昨今のアジャイル開発本がスクラムを中心にしていたので、元々の「アジャイル憲章」からスタートして、スクラム以外のアジャイル開発（XP、チケット駆動）を用いるのと、アジャイル開発自体は決して非PMBOKではない、ことを取り入れたかったので、PMBOK 用語を使っているという事情があります。
まあ、端的に言えばスクラム開発については、「ケン・シェーバー著のアジャイルソフトウェア開発スクラム一冊で十分じゃないですかね？」ってところからスタートしたので、こんな感じになっています。
端的に言えば、Software Development 以外を記述した本（教科書的な）なので、ソフトウェア開発については SWBOK あたりを読め、という形になります。これをスタートラインとしているので、本書の範囲としては、右中央の「アジャイル開発型マネジメント」に絞っています。
中央にある、PMBOKや実装ノウハウはソフトウェア開発において基本知識としてあるものとして、実際にプロジェクトを動かす場合に、計画駆動型にするかアジャイル型にするかという判断があります。これはアジャイル憲章にも書いてある通り、ドキュメントを包括するのか動くソフトウェアを優先するのかという “選択” になります。実は、ドキュメントのほうを優先する場合もあります。宇宙開発や原子力開発、航空機関係のシステムなどの人命が掛かるものは「ドキュメント」に基づいて合意を取る等の厳しいルールが課せられます。そういう場合は、到底アジャイル開発という訳にはいきません。もっと厳密な形でプロジェクトを走らせることが求められます。逆に言えば、人命に関わらないものに関しては随時動きを確認するようなアジャイル形式でよいのです。スピードが要求される広告サイトや商品販売、あるいは一時期的なイベントで集客を見込むようなWEBサイトなどはリリースまでの期間は短期であるほうが優れていると言えるでしょう。なんせ、WEBサイトの動きがちょっとおかしかったとしても人命が失われることはありません。更に言えばほぼリアルタイムに修正が可能です。
このように、マネジメント自体を計画駆動にするのか、アジャイル開発にするのかという選択肢は、エコシステムとして（まさしく、「アジャイルソフトウェア開発エコシステム」に書かれていることになりますが）どちらがより金銭的に有利なのかという話になります。
ソフトウェア開発そのものに結び付ける道筋
実際のところ、コードの実装者から見れば、それが計画駆動であるかアジャイル開発であるかの違いはありません。端的に、コードを書く、単体テストをこなす、を繰り返します。コード書く前に紙のドキュメントの有無であったり、詳細設計 “書” に基づくべきなのか、チケット駆動のようにざっとした箇条書きによってコーディングを行うかの違いはありますが、少なくとも現代においては「コードを書く」「単体テストを行う」という XP のノウハウを利用したほうがよいです。さすがに、いまどき、コンパイルが通らない状態でコードを書くことはないでしょう。昔は、コンパイル自体が長かった、あるいは大型計算機の使用時間待ちであったこともあり、コンパイルなしでコードを書く時期もありました。しかし、今、そんなことはしないでしょう。そういう意味で、XP のテストコードを書くといのは実装工程においては必須になってきます（テストコードを先に書くか、後に書くかという違いはありますが）。
対象読者ですが「コードが一定の品質以上で書ける」ことが前提となっています。マネジメント層（スクラムマスター、プロジェクトマネージャー、オーナーなど）はコード自体はまあいいのですが、開発者が読む場合はこれが必要条件になります。
本書の章をピックアップして具体的なソフトウェア開発（主に実装工程）に結びつけると、こんな感じになります。
第2章 スクラムとXP
先に書いた通り、単体テストが必須です。単体テストサイクルは各 xUnit のツールに従います。継続的なコード改善やコードの共有化においても、単体テストが有効に働きます。これは計画駆動、アジャイル開発に限りません。最近ならば GitHub Action などを利用して、コミット前にビルドやテストコードの実行を強要すればよいでしょう。
ペアプロについては、リモートでのペアプロが可能になっています。VSCode などでコードを共有してもよいし、Teams で通話を繋ぎっぱなしでペアプロをすることも可能です。実際、新人教育などでは2,3時間繋ぎっぱなしで、相手のエディタを表示してもらって操作することもやります。
第3章 チケット駆動、第4章 バックログ、チケット
「チケット駆動」ということになっていますが、実際はチケットの扱い方です。
作業を分割する方法として、WBS/チケット/タスク/プロセスなどの様々な呼び方があります。これらのタスクについては、スケジュールを確定させたい計画駆動と、途中で顧客の要望を取り入れたい＝チケットが増加する可能性が大であるアジャイル開発との違いがあります。
また、スクラムではスプリントという期間を決めるのに対して、チケット駆動ではそれほど期間を区切りません。
また、チケットを共有する手段として、Backlog（という製品）や GitHub の issue の利用があります。以前ならば、Excel で課題管理をしていたところですが、昨今では Web アプリを使って複数名で共有するのが当たり前になってきています。
コーディングをする上でのチケットの扱いは、完了を明確にすることです。これは本書でも書いてある通り「単体テストが通った」ことを明確にするとよいです。客観的に完成したことがわかる目安を作っておくことが重要です。
第5章 自動テスト
いわゆる再帰テスト（繰り返しテスト）のやり方です。
モックの作り方などの具体例がでていないのはプログラム言語や動作環境によって異なるためで、割愛しています。
ざっと言えば、Web システムでの単体テストを Controller, Service, Web API 経由という分割した形にする。Servcie 単位が望ましいのですが、外部から curl などを利用した Web API 経由でもよいでしょう。ただし、データベースの中身のチェックがちょっと面倒になります。
デスクトップアプリでは、ユーザーが操作する部分でテストするのは人力となってしまうので、これもロジック部分を切り出して自動テストが可能な状態にします。場合によってはモックが必要になりますが、コツとしては「モックを必要としない単体テスト」と「モックを必要とする結合テスト」に分割するとよいです。
ちなみにモックを必要とする結合テストであっても xUnit のノウハウが使えます。
組み込み系はモックが必須になる（I/Oを叩く、タイミング調節など）ので、これはロジックを分離する形で単体テストができるようにします。これは必須条件ですし、単体テストを利用すれば、少なくとも実装期間が半分になるのでお薦めです。
第6章 スタンドアップミーティング
アジャイル開発で、朝会などが有効となっていますが、新型コロナの影響や海外チームを組むことは “同じ場所に集まることはできない” ので、別な方法をとります、ということです。
最近は、出社が強制する世の中に戻りつつありますが、要は遅延したコミュニケーションをどこまで考慮するのか？ということです。逆に言えば、本当に即対応（命に係わる現象）以外は、遅延を許容したほうがうまくいきます。
アジャイル開発スクラムで「スクラムミーティング」が強調されるため、同じ時間に同じ場所にいるということが重要そうに見えます。しかし、それはスクラムを採用したときの話であって、XPやチケット駆動、あるいは計画駆動の場合には必須条件ではありません。そのあたりを間違えると、無闇な “朝会” を開発者に強要することになってしまいます。というか、最近なっていますが。
第7章 タイムボックス
第6章のコミュニケーションに関わるものとして、締め切りを明確にした「タイムボックス」制を使います。つまり、いつまで作ればよいか？を明確にして、その間にあれこれと言わないということです。皆さん、プログラマはプロなんですから、途中でサボったりしませんよね、ということとサボっても締め切りには間に合わせてね、ってことです。途中経過は問わないのです。結果が重要です、という話ですね。
逆に言えば、未知なる要素が多いとこきはタイムボックスが有効に働きません。経験上、とあるコードが何時間、何日で作れるのかというのは「勘」を働かせることもありますが、過去の経験との比較をするのがベターです。あと、自分の実力を知るために PSP をしておくとよいです。うまくいかなそうなときは、いったんタイムボックスを外して、調査時間を決めて（時間は無限ではないので）、どのくらいで調べられそうかをチェックします。これは AI エージェントを使ったコーディングでも同じことが言えます。途中で迷路に入ってしまった AI エージェントを “時間” を区切って引き戻します。前回のプロンプトを無しにして、もう一度やり直しをすれば ok です。
第8,9章は割愛。主にマネジメントよりなので。
第10章 継続的リリース
DevOps が入れたかったのと、ソフトウェア開発者はどのように休日過ごすべきだろうか？というのを書くために入れています。
いまとなっては Google がやめてしまった 20% ルールですが、日々の仕事の中でなんらかの学習や実験をしておくとは非常に有効です。それも、最新情報を常に追うのではなく、仕事をしながら、つまりは仕事が8割で、未来への投資が2割ということです。未来の投資がなければ、成長がありませんよね。自分への2割の投資をしてください。
執筆時、「プログラマは休日、どうやて過ごせばいいだろうか？最新技術の勉強でしょ」という雰囲気があったので、それの反動です。最新技術を追う時間は業務時間にやったほうがいいです。休日はもっと自由な技術の追い方（休憩も含めて）をしてみてください。仕事とはいえ楽しくやりたいし、ましてプログラマという仕事は好奇心を突き詰めることもできるので “楽しい” 仕事です。そのための、ちょっとばかし辛い勉強や作業があっても全然大丈夫ですよね。ってことです。
このあたりの開発者寄りの部分は、また機会を見つけて書いていきましょう。なお、実際にどうすればよいのかというのを、https://openccpm.com で準備中です。
