Clean Agile読書感想文

PySpa統合思念体です。Clean Agileという書籍が出版されたので、その読書感想文です。PySpaアドベントカレンダー2020の最終日のエントリーです。

本書の立ち位置と内容

エクストリームプログラミングについて、ケント・ベックとは別の平易な説明を試みた本です。XP自身もいろいろ変化があり、XPのプラクティスは12→13→24(11+13)→19と時代によって変わっていっています。ウェブサイトに残っている情報も、どの時代を参照しているのかによって説明がバラバラだったりしますが、この本は13で、多くの人が「原典」と考えるほとんど初期のシンプルな昔の構成にほぼ戻っているので理解しやすいと思います。12時代と13時代の間では「適切なペース」が増えました。本書では、「コーディング規約」がなくなったのと、「スタンドアップミーティング」が追加されています。

1章がアジャイル宣言を含む歴史の話、2章はXPのプラクティスの概要、3, 4, 5章がレイヤーごとのプラクティスの細かい説明。6章がアジャイル導入（および導入失敗）の話、7章がスクラムが捨て去ったテクニック部分（クラフトマンシップ）に関する話です。XPの書籍を読み込んだ人には、2-5章は懐かしさすら感じる内容だと思いますが、6章と7章が現代の話で新鮮に映るでしょう。

なお、本書は「アジャイル」を銘打っていますが、アジャイルプロセスの中で、XPこそが至高で、スクラムは燃えないゴミ、ぐらいに思っている極端な本です。スクラムが研修ビジネスのような方向に突き進んでいることに違和感を覚える、2000年初頭のXPブームに沸いた人たちにとっては拍手喝采な内容です。

XP前後

現代的なソフトウェア開発にはすでに当たり前と受け入れられている「実践的な開発手法」の多くが、エクストリームプログラミングとともにもたらされました。今XPの本を読んでも、ピンと来ない若者も多いと思います。歴史を変えたものを後からみても、それが「当たり前」の価値観に塗り替えられた後なので、存在が空気になってしまうのはどの分野でもあります。これらは直接XPが発明したものではないものも多いのですが、XPが「効果があるから最大限活用しよう」として取り上げて脚光を浴びました。これらがなかった原始時代に光をもたらしたというのを考慮にいれつつ読むと、当時の熱狂の一端を感じとることができるのではないでしょうか？

• ユニットテスト（テスト駆動開発）・受け入れテスト
  XP本で紹介されたJUnitが大きなブームになり、各プログラミング言語が標準ライブラリで備えるまでになった（一応以前からテスト用ライブラリはあったが、JUnitスタイルはXP後)。BDDスタイルのフレームワークはRubyやJSで広まった。受け入れテストも自動化が試みられ、だいぶ先になってSeleniumなどが開発されたりした（当時はデスクトップアプリ全盛）
• リファクタリング
  これもXP本で紹介されたテクニック。言葉としては一般化したし、IDEがリファクタリング機能を搭載したりしている。書籍もあるが、XP白本とは同時期に執筆され、相互に参考文献にあげられている
• チケット管理
  Bugzillaなどの不具合報告のバグトラッカーは当時もあったが、XPやスクラムのタスク管理を電子化し、開発に活用するブームが生まれた。次にあげるようなバージョン管理とセットになったものが広く使われた。Trac、Redmine、JIRAなど。カンバンや、バーンダウンチャートなどを備えるものもある。なお、本書でも白本でもカード利用を推奨していて電子ツールは推奨はしていない。
• バージョン管理
  Subversionなど（Trac、Redmineとセットで導入）。それまでもバージョン管理はあったが、XPでは「必須」になった。
• 継続的インテグレーション
  本書でも説明されている通り。Cruise Controlに始まり、Jenkinsなど。GitHub Actionsの先祖。
• コーディング規約
  コードのスタイルを統一する、というのがXPの本だったが、その後Eclipseに搭載されたフォーマッターなどで自動フォーマットが普及した
• スタンドアップミーティング（朝会）/振り返り

権利章典とアンチパターン

本書の一番の核を挙げるとしたら、2章の権利章典だと思います。XPが単なるプロセスではなく、儀式でもなく、ビジネスと開発がお互いに全力を出し合うための必要条件を述べています。つまり、ここを一部妨害すると、アジャイルを失敗させることができるということです。

単に本のダイジェストを書くだけの感想文なんて面白くもなんともないので、この権利章典を元に、アジャイルのアンチパターンを考えてみます。なお、これらはフィクションです。事実を元にしていたりなどはしません。妙にリアリティがあっても気のせいです。なお、アジャイルのアンチパターンではありますが、アジャイルじゃない開発でも失敗の原因としてありえるでしょう。

事例1: 顧客側の代表がいちいち業務部門にヒアリングしないと要件がわからない

ソフトウェア開発チームのカウンターとしてIT部門の人が立っています。しかし、開発チームからの質問を受けたら、業務チームの人との会議を設定して、問い合わせをしてから回答します。業務チームは会社を支える本業で大忙しですし、会社の中の序列も上です。回答には1−2週間を要します。

一般に、外注で受けてソフトウェア開発をする人たちの人件費は高コストです（各種マージンもあって）。待たせることはお金がもったいないです。

事例2: アジャイルなので何をするかは決めない

アジャイルは計画しないので、とりあえず手ぶらでミーティングをして、ブレインストーミングをしてカードにして、トキメキを覚えたものから実装したいです。

いくら変更に強いからといって、無秩序に行ったり来たりをすれば開発速度は落ちます。顧客が質の高いタスクリストを全力で作るのがアジャイル開発の成功には不可欠です。見えてない不確定部分以外はなるべく確定させるのに全力をつくし、それでも不確定な場合に、計画に柔軟性を持たせて結果を吸収できるようにします。「絶対にやりとりが必要な外部システム」の類は最初からぜんぶリストアップしましょう。

事例3: 開発項目確定の稟議では、普段プロジェクトにいない偉い人がやってきてOK/NGを出す

顧客代表のIT部門と開発チームが一体となって、次のイテレーションの項目を決めました。これから上司に説明します。上司に対して、開発したい機能を全て説明します。星取表も完備して、質疑応答に備えて想定問答集も作ります。場合によっては、相見積もりが必要になって、購買部と話をしなければなりません。購買部は公平を期するために顧客代表とは話をしません。

要件決定と開発開始の間に時間が必要であればあるほど、アジャイルの機敏さが失われます。当然ですよね。

事例4: 現行踏襲

魔法の言葉「現行踏襲」によって、要件定義が大幅ショートカットされます。そして現在の要件にちょびっと新機能を追加したら、効率良く新システムが完成できますね！

・・・とはなりません。新システムとして実装側は、現行機能をきちんとバラして再度組み立てなければならないため、現行機能を小さく還元しつくす必要があります。また、現行のシステムで実現できないことがあるから新機能を開発するし、その機能が全体の設計に影響を与える可能性もあります。例えば、複数のブランドを扱えるようにする、それぞれのブランドの担当者は相手のブランドのデータが見れないように可視性をいれる、みたいな変更は裏から表から大きく変わる可能性もあります。桁が変わるぐらいの過少評価になる可能性があります。

流行っている他社システムを真似る、というのも類似例です。

事例5: すべて最優先

現在の機能と同じものを維持するために、最低限必要な機能を整理してリストアップしました。これらはすべてファーストリリースに必要です。なので、優先度はすべて高です。あ、ユーザー部門から要望が上がってきました。これも最初のリリースに忘れずに入れてくださいね。

すべて大事というのはすべて大事じゃない、というのと同義です。イテレーションの期間を守るには、タスクの見込みの作業量は維持しなければなりません。タイムリーに要件変更ができるといっても、「機能の差し替え」「プライオリティの変更」しか許されていません。何かを足したら、引く必要があります。

事例6: とりあえず作ってみた機能がニーズに合わなかった時に捨てられない

「なぜあの時に、この機能が必要だと言ったのか？当時の決定は精査されたものだったのか？再発防止策をこうじてください。二度と無駄な機能を作らないことを証明してください」

「前例が絶対」で、「反省」ができない組織でありがちな問題です。以前討論して結論を出したことが、その後の学習で合わなくなったことがわかっても、以前の決定を訂正するにはその以前の決定が「間違っていた」「謝罪と反省を求める」みたいな組織の場合、試しに作ってみることの心理的な敷居が極めて高くなります。「非常食が使われなかったら無駄だったと騒ぎ立てる」タイプですね。「これは観測衛星だ」ということを明確にして挑む必要があります。

なお、このタイプの人は顧客側でなくても、開発側にいてもうまくいきません。ソフトウェア開発じゃなくてもういまくいかないし、アジャイルじゃなくてもうまくいかないでしょう。

事例7: 絶対死守のリリース時期と機能が決まっている。なお、リリース時期は2ヶ月後

さあ、デスマーチの始まりです。

事例8: アジャイルでスピード重視。ドキュメントは作らないし、何を作るかを仕様書にすると時間がかかるのでリリースは遅れます

通常のアジャイル開発では発生しない問題ですが、日本特有の、受ける側が要件の整理をして開発項目を決めるケースで、開発側がこれを言い出すと、システム開発のガバナンスがまったくきかなくなります。顧客側はいつ完成するのかもわからず、何が手に入るかもわかりません。

事例9: とりあえず納期優先で作りますので、運用のための機能は後回しです

早くリリースしなければなりません。運用時のデータ更新については後で考えます。最初は直接SQL叩けばいいんじゃないですかね。

システムは中心となるソフトウェアだけではなく、運用時に必要なあらゆるものが「システム」です。アジャイルは重要な機能を先に作りますが、イテレーションとリリースはイコールではありません。開発はイテレーションごとにサイクルを刻みますが、実際にビジネス要件に合うかどうか判断してリリースするのはビジネス側です。だいたい大きなプロジェクトは構築時に開発者が多く、リリースされると減っていくものです。運用に必要なツールを後から作るとその後の新規開発と運用改善でリソースを奪い合い、リリース後のすばやいフィードバックループが回せなくなります。

事例10: リリースまで日がないので、最初のイテレーションでまず動くアプリケーションをいきなり作りましょう

コードフォーマッターとか、なくてもなんとかなりますし、テストもまずはそんなコード量ないからいいですよね？CIも後回しで。

XPではこれらは最初のイテレーションの前の「イテレーションゼロ」でやるべきこと、となっています。コードフォーマッターやLinterは後から導入すると、コード全体にdiffを発生させ、派手なコンフリクトを発生させます。後からの導入はタイミングが大切になり、調整のコストが大幅に増加しますし、それなりにプロジェクトの中でシニアなメンバーの人手が取られます。きちんとしたCIの導入など、できる投資はなるべく早く行わないと、後から入れるのは大変です。

事例11: ユーザーがあまりシステムについて詳しくないので、開発チーム側がストーリーの細かいところを検討します

他のシステム連携で、情報の変換が必要になりますが、詳細がわからないので、開発チーム側が詳しく調べて仕様化してください。

開発チームがコーディングに関係しない調査業務を引き受けてしまうと、イテレーションの半分は次のイテレーションの調査、半分で実装、と効率は確実に下がります。場合によっては他部署の人と時間を合わせてミーティングをして調査したりすると、リードタイムもかなり長くなります。もはやベロシティどころではありません。

日本のアジャイルの問題点

本書を改めてみてみて、日本におけるソフトウェア開発とのギャップを考えると、なぜストレートな導入が難しいのかが見えてきます。

日本のソフトウェア開発は、ソフトウェアプロジェクトに全部の権限を一任する、というのがあまりないように見えます。事例3のようなケースの場合、開発チームが稟議書の手伝いをしたり、事例11だと仕様書の細かい部分まで詰めたりします。

一方、XPの本やスクラムの本などを読むと、「顧客はビジネスに精通していて一瞬で回答を返す存在」となっています。しかし、ソフトウェアが相手にするドメイン知識は膨大です。例えば、要件の中でセキュリティに関する要件があったとしても、ソフトウェアのセキュリティは専門技能です。法律的な制約があるかもしれません。本書でもちょびっとチームである、的なことは示唆されています。

この文脈で「顧客」という語は、一般的にビジネス側の人たちのことを指す。そこに含まれるのは、実際の顧客、マネージャー、経営陣、プロジェクトリーダーなど、納期や予算の責任を負うことになる人や、システムを投入することで利益を得るために費用を支払う人である。

Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,角谷 信太郎. Clean Agile　基本に立ち戻れ (Japanese Edition) (Kindle の位置No.1210-1213). Kindle 版.

しかし、用語としては単数系の「Customer」ですし、スクラムでも単数系の「Product Owner」です。アジャイルを導入するにあたっては、「製作委員会」の構築が必要で、ITがある程度わかる担当者、セキュリティ専門家、法律専門家、お金を持っている人、他の関連システムの担当者、データアナリストなどの構成チーム、あるいは何かあったときに即座にエスカレーションする仕組みを構築し、要件の質問に即答できる体制作りが必要だと思われます。しかし、そのようなことを説明している本はみたことがなかった気がします（アジャイルの本を読んだのはだいぶ昔なので勘違いかもしれない）。

現在の日本のよくあるソフトウェア開発だと、一次受けベンダーが要件整理などをしてドキュメント化します。そうなると、アジャイルにおける顧客と開発の間の境界線は、お客さんと一次受けベンダーと、二次受けの間にある、というのが実情ではないでしょうか？

XPもスクラムも、ずるい点としては、「何を作るのか」の責任を、この万能な「顧客ロール」に押し付けている点です。それは一種の理想的な状態であり、その状態になれば開発チームのパフォーマンス（要するに開発の費用対効果）が最大化される、というのをきちんと説明しているという点では、アジャイルの本がもたらした知見は偉大です。しかし、全体のスループットはボトルネックのスループットにひきづられます（制約理論）。アジャイルを導入することによって、ボトルネックはビジネス側に移動します。

すでに基幹システムを持っている（メインフレームだったりするかもしれませんが）場合、ドメイン知識はそのすでに構築されたシステムの中にあります。ユーザーがどのように使っているか、というのはユーザーストーリーのインプットにはなりますが、ドメイン知識を明確にするためにはシステム考古学者が今後ますます必要になっていきます。既存のシステムの理解なくして、うわっつらの画面ばかり設計していても、システム開発は進捗しません。

顧客が「アジャイルによってビジネスニーズに機敏に対応できるシステム開発」のメリットを享受したいのであれば、一次受けが行っている仕事をある程度こなす必要があるといえます。もちろん、それができている会社もあります。

本書をおすすめする人

• XPが好きな人。XPの本です。おめでとうございます。

• スクラムな人。「スクラムマスターはたまにきて、責任を追わずに綺麗事を残して帰っていくムカつくやつ」という評価がされることもあり、スクラムガイド2020ではよりXPに近づいていっている感じがあります。しかし油断してはいけません。スクラム嫌いのXP原理主義者があなたの首を狙っています。本書はXP派の教義を知れるので、敵を知れば百戦危うからずです。スクラムにないXPのレイヤーをコンパクトに知ることができます。

• ソフトウェアを発注する顧客企業の人。権利章典の説を理解することが正しいソフトウェア開発案件を進める第一歩です。開発側の権利を満たせない場合、それを政治に解決するコストを開発側が追う、結果的に開発速度が落ちて請求が大きくなる、ということです。ここで説明されている顧客の権利を得るためにも、開発に対して行わなければならない義務を知っておくのは良いことです。アジャイルじゃない開発においても役立ちます。