【アジャイルFAQだけど大きく途を踏み外した編】私が「私設・日本式アジャイルを撲滅する会」の会長である理由

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。
 最初に、自己紹介をやり直させてください。私は長らく「私設・日本式アジャイルを撲滅する会」の会長を務めています。会員数は非公開（というより、数えたことがありません）。会費はなく、会則と設立の経緯は、本稿の最後に載せます。
 表向きはおふざけです。でも、中身は大真面目です。そして実際に良く訊かれます。
 今回は、豆蔵のアルバイトとしてではなく、この怪しげな会の会長として、なぜこれを撲滅したいのかを書いておきます。

 取引先から「日本式アジャイル（ハイブリッドアジャイル）」という進め方を提案されました。要件定義まではしっかり固めて予算を確定し、開発は2週間ごとの反復で進め、最後にまとめて総合テストをするそうです。予算が確定するので社内の稟議も通しやすく、うちの会社に合っていると思うのですが、何か問題はあるでしょうか？

 進め方そのものは、過渡期の形としてはありえます。問題は名前です。要件と予算を先に確定するなら、その後に変更できる量は、ウォーターフォールの変更管理とほとんど変わりません。それを「アジャイル」と呼ぶと、発注側は手に入らない柔軟性を期待してしまいます。アジャイルの自由度が得られないなら、「ハイブリッドウォーターフォール」と呼ぶほうが誠実です。
 そして、総予算を先に知りたいという要望は、実はアジャイルと矛盾しません。確定させるべきは、要件の一覧ではなく、予算と目的です。

 まず、何を撲滅したいのかをはっきりさせておきます。
 要件定義までをウォーターフォールで進め、構築だけを反復し、最後にテストをまとめて行う。この形には「ウォータースクラムフォール」という名前があります。調査会社ForresterのDave Westが、多くの組織におけるアジャイルの現実の姿として名付けたものだと言われています。前の工程（要件と予算の承認）と後ろの工程（テストとリリース）が従来のまま残り、真ん中だけが反復になる。アジャイルへの移行の途中で、多くの組織が一度は通る姿です。
 だから、この段階にいること自体を責めるつもりはありません。番外編「正論が通らないとき」で書いたとおり、組織の前提が動かないなかで、できるところから始めるのは正しい戦い方です。
 当会が撲滅したいのは、この過渡期の姿を「日本の組織に合ったアジャイル」と呼び、到達点として売る言説のほうです。到達点として売られると、移行（この移行とは言い換えれば進化です）はそこで止まります。

 この売り方が一定の訴求力を持つ理由は、よく分かります。
 発注側は、総予算を早く知りたい。稟議を通すには金額が要ります。受注側は、金額を出せなければ受注できない。かといって、いい加減な数字で契約するわけにもいかない。だから、要件定義をしっかりやって、予算を確定させようとする。ここまでは、どちらの立場から見ても合理的です。誰も悪いことはしていません。
 問題は、その次です。

 要件を確定して予算を確定するということは、その後の変更は「予算の枠の中での変更」になる、ということです。枠を超える変更は、変更依頼を出し、影響を見積り、承認を取る。これはウォーターフォールの変更管理プロセスそのものです。反復の単位が2週間になっても、総量で見ると変更できる量はほとんど変わりません。
 それなのに、「アジャイル」という言葉には「柔軟に変更できる」というイメージがついています。発注者はそのイメージで契約し、後になって「アジャイルなのに、なぜ変更のたびに見積りが出てくるのか」と首をかしげる。
 当会ではこれを、親しみを込めて看板詐欺と呼んでいます。
 ……と言うと角が立つので、本文ではもう少し正確に書きます。売る側が意図して騙しているとは限りません。むしろ多くの場合、売る側も、自分たちはアジャイルをやっていると信じています。ただ結果として、発注者は手に入らない柔軟性を期待させられている。
 看板と中身が一致していない、ということです。

 名前の問題だけなら、目くじらを立てるほどではないかもしれません。しかし、このずれは実害を生みます。連載で扱ってきた問題の多くが、この形では構造として組み込まれてしまうからです。

• 学習が成果物に届かない: 要件が確定しているので、スプリントレビューで「こうではなかった」と分かっても、作るものは変えられません。第8回で見た、誰の意思決定にも影響しないレビューが、例外ではなく標準になります。
• 間違いに気づくのが最後になる: テストを最後にまとめるので、スプリントで「完成」したものは、実際には未検証です。第11回のテスト先送り型が、公式の工程になります。早く間違いに気づくというアジャイルの最大の効能が、そこで消えます。
• 手間は両方の合計になる: ウォーターフォールの文書と承認はそのまま残り、そこにスクラムのイベントが加わります。現場には「アジャイルにしたら会議が増えた」という記憶だけが残ります。
• 足腰を鍛える理由がなくなる: 最後に人手でまとめてテストするなら、テスト自動化もCIも要りません。業務系の現場で長年見送られてきたこの投資は、この形では永久に正当化されません。
• POが検収係に戻る: 要件が先に確定しているので、POは方向を決める人ではなく、仕様どおりかを確かめる人になります。第8回で見た「社内外注」の構図が、そのまま温存されます。

 そして、いちばん大きい害は、これらの結果として組織に残る結論です。コストは増え、品質も納期も変わらず、学習も起きない。それが「アジャイル」の名前で行われるので、組織には「アジャイルを試したが、うちには合わなかった」という経験則が残ります。次に本物を試そうとする人の前に立ちはだかるのは、前例主義が多い中でこの失敗の記憶です。番外編「正論」で、過去にカタカナの流行りもので痛い目を見た組織は看板を見ただけで身構える、と書きました。その種を撒いているのが、この売り方なのです。

 では、発注側の「総予算を早く知りたい」にどう応えればいいのか。実は、アジャイルはこの要望と矛盾しません。
 期間とチームの規模を決めれば、総額は先に確定できます。そのかわり、中身は固定しません。優先順位の高いものから作り、届けて、結果を見て、残りの順番を入れ替える。予算と目的を固定し、スコープを動かす。第4回で扱った、全機能を確定せずに見積りを出す話も、この考え方の上にあります。
 つまり、発注側が本当に知りたいのは総額であって、全要件の確定ではありません。日本式アジャイルは、総額を出すという名目で要件まで確定し、そのうえで「アジャイルだから柔軟です」と言っている。ずれているのは、ここです。
 自分の案件がどちらなのかを見分けるには、一つの問いで足ります。

契約で確定しているのは、要件の一覧か。それとも、予算と目的か。

 要件の一覧が確定しているなら、反復をしていても、中身はウォーターフォールです。予算と目的が確定していて、中身が優先順位付きの候補一覧として扱われているなら、アジャイルの自由度は実際に手に入っています。変更依頼の書類を出さずに、項目の入れ替えができるかどうか。実地の判定は、それで十分です。
 もちろん、契約の形を変えるのは簡単ではありません。一括請負、社内の開発標準、監査の要件——動かせない前提はいくらでもあります。だからこそ、動かせないうちは、正直な名前で呼んでください。ハイブリッドウォーターフォール。この名前なら、発注者は正しい期待値を持てますし、受注側も約束していない柔軟性で責められずに済みます。
 番外編「正論」の第三原則は「中身があるなら、看板にこだわるな」でした。今回はその裏返しで、中身がないなら、看板を掲げるなです。

 ついでに、これから現れそうな新しい看板にも、会長として注意報を出しておきます。
 生成AIを開発の中心に据える「AI駆動開発」や、仕様を先に書いてAIにコードを生成させる「仕様駆動開発（SDD: Spec-Driven Development）」が注目されています。表面だけ見ると、どちらも「先に仕様をきちんと書き、構築はAIで速く回す」形をしています。日本式アジャイルの「要件定義をしっかり固め、構築だけ反復する」と、驚くほどよく似ています。「AI時代こそ上流が大事。やはり要件定義を固めてから作るやり方は正しかった」——そんな売り文句が出てくるのは、時間の問題だと思っています（いや、すでにもう出ているかも…）。

 しかし、論理は逆を向いています。SDDの肝は、仕様が先にあることではありません。仕様を直して作り直すコストが、ほとんどゼロになることです。仕様は機能や増分の単位で小さく書き、動くものを見て学んだら、仕様を直して作り直す。仕様は契約書の付属書ではなく、リポジトリの中のファイルとして生き続けます。
 かつて、前工程で大きく設計しておく根拠は「後で変えると高くつく」でした。XPがテストとリファクタリングで崩そうとしたこの前提を、AIはさらに崩します。後で変えるのが安く済むなら、前で全部を確定しておく理由は、むしろ弱くなるのです。

 危ないのは、SDDの形だけを借りて、システム全体の仕様を前工程で確定し、契約で凍結する組み合わせです。それは「AIで速く打鍵するウォーターフォール」であり、間違った仕様から、間違ったものを、今までより速く大量に作る仕組みです（そして人はおそらくそれをレビューしきれない）。
 第1回で書いたAIいいなり開発の組織ぐるみ版の完成と言ってもいいでしょう。

 公平のために付け加えると、AIによって「意図を先に、はっきり言葉にする」ことの価値が上がったのは事実です。先に書くこと自体は、アジャイルと矛盾しません。アジャイル宣言が言っているのは「よりも」であって、「書くな」ではありません。アジャイルに反するのは、先に書くことではなく、大きな単位で書いて凍結することです。
 だから、先ほどの問いは、AI時代にはこう言い換えられます。

その仕様書は、契約の付属書か。それとも、リポジトリの中のファイルか。

 直すたびに変更依頼書が要るなら、AIが何を生成しようと、それはハイブリッドウォーターフォールです。

 最後に、会長として、どうしても言っておきたいことがあります。「日本式」という名前のことです。
 「スクラム」の出どころを辿ると、竹内弘高・野中郁次郎の両氏が1986年に発表した論文「The New New Product Development Game」に行き着くことは、多くの方がご存知の通りです。この論文は、工程を順番に引き継いでいく開発をリレー競走に、工程を重ねて全員で一緒に前進する開発をラグビーにたとえ、日本の優れたメーカーの強みは後者にあると論じました。スクラムという名前は、ここから来ています。
 ウォータースクラムフォールは、リレー競走の真ん中に、スクラムを一つ挟んだ形です。日本の現場の強みとして世界に紹介されたものの、ちょうど逆をやって「日本式」と名乗っている。
 本当の日本式は、とっくに海を渡り、スクラムという名前で逆輸入されているのです。

 というわけで、当会の会則を参考までに載せておきます。入会も退会も自由です（←冗談だからね。募集してないよ）。

第一条: 看板に偽りなし
 アジャイルの自由度が得られない進め方を、アジャイルと呼ばない。要件と予算を先に確定するなら、ハイブリッドウォーターフォールと呼ぶ。中身がないなら看板を掲げるな

第二条: 過渡期は歓迎、到達点にはしない
 ウォータースクラムフォールにいることは恥ではない。ただし、次にどこを崩すかを決めておく。テストを前に寄せる、要件を確定する範囲を小さくする、途中でリリースを挟む。どれか一つでいい。

第三条: 契約を確かめる
 「アジャイルで進めます」と言われたら、契約で確定しているのが要件の一覧か、予算と目的かを確かめる。

第四条: 変更は、入れ替えで
 変更を歓迎するなら、入れ替えのルールを先に合意しておく。何かを入れるときは、何かを外す。その判断を誰がするかも決めておく。

 会長を名乗るようになったのは、同じ看板の下で、正反対の二つの混乱を何度も見てきたからです。

 一つ目は、柔軟性がまったくない現場です。要件定義で決めた機能リストを、スプリントごとに順番に消化していく。私はこれを、分割払いと呼んでいます。買うものも総額も、契約の時点で決まっている。スプリントは、その支払いを何回に分けるかを決めているだけです。途中で「やっぱりこれは要らなかった」と分かっても、残債は払い続けるしかない。スプリントレビューで利用者の反応を見ても、次のスプリントで作るものは、もう決まっています。反復はしているのに、学習が入り込む隙間がないのです。

 二つ目は、その逆です。発注側が「アジャイルだから変更は自由」という看板を真に受けて、変更をどんどん出してくる。ところが予算と要件は確定済みなので、受注側には、その変更を吸収する枠がありません。最初は無理をして受け入れ、残業と品質の低下で吸収し、限界が来たところで変更管理が復活する。発注側からは「アジャイルと言ったじゃないか」、受注側からは「予算の中でと言ったじゃないか」。どちらも、嘘はついていません。

 この二つは、同じ看板の表と裏です。一つ目は、受注側が中身をウォーターフォールのまま守った結果。二つ目は、発注側が看板のほうを信じた結果。そして、どちらの現場にも欠けていたものは同じでした。本来のアジャイルで変更が歓迎されるのは、予算と期間という枠の中で、新しく入れるものの代わりに、優先順位の低いものを外すからです。変更とは追加ではなく、入れ替えのことです。この入れ替えのルールを、誰も契約にも合意にも書いていなかった。分割払いの現場では入れ替えが許されず、変更が殺到した現場では入れ替えが求められなかった。
 日本式アジャイルという看板は、このいちばん大事な一行を、どちらの側からも見えなくしてしまうのです。

 撲滅と言いながら、当会の目標は会の解散です。「日本式アジャイル」という言葉が使われなくなり、過渡期が過渡期として、正直な名前で呼ばれるようになったら、その時晴れがましい心持ちで当会は解散する事ができるでしょう。

本編の連載一覧は第1回をご覧ください。