アジャイルは何も解決していない
この記事はアジャイル型開発を否定する記事ではない。
逆にウォーターフォール型開発を勧める記事でもない。
アジャイル型開発は、少なくとも自社開発においては非常に有用だ。簡易的なストーリーポイントによる見積もり、プロダクトバックログによる仕様とタスクの整理、短いスプリントを繰り返して品質を高める。素晴らしいことだと思う。
ここで話したいのは、ユーザー企業がベンダーへ開発を外注する場合——いわゆる受託開発において——ウォーターフォール型開発の課題をアジャイル型開発で解決できるというのは嘘である、ということだ。
結論から言えば、確かにウォーターフォールの課題の一部を解決することはできる。しかし、新しい課題を生む。問題が消えるのではなく、形を変えるだけなのだ。
ウォーターフォールの振り返り
ウォーターフォール型開発の課題は主に二点ある。
ひとつめは、最初に正確な要件がわからないので、誤った要件で開発が進み、後で仕様が変更されるということだ。
これは散々言われてきたことだと思う。ある程度完成してから分かる仕様変更が発生し、有償無償問わずベンダーが後から対応する。よくある流れだ。
しかし、ここで立ち止まって考えてみてほしい。後から変更が加わることは、お互いに（暗黙的に）わかった上で契約は結ばれている。ユーザー企業としては完成が約束されている請負契約で契約を結びたい。だから苦肉の策として、信頼と実績のあるベンダーを選定する。
つまり、この問題は「ウォーターフォールだから」というより、「請負契約だから」発生している側面が大きい。
工数最小化ゲーム
ふたつめの課題は、決まった要件を極力ベンダー側が最小の工数で実装しようとすることだ。
詳しくない人は「それでいいじゃないか。効率的で当たり前じゃないか」と思うかもしれない。
しかし、実際は問題だらけだ。
というのも、要件定義フェーズでは本当に細かいところの仕様は定義されない。画面のパディングの値などの細かいUI要素や、非機能要件の多くは実装側の都合に委ねられる。
たとえば、シームレスに実行しなければユーザーが離脱してしまう機能があったとしよう。購入ボタンや問い合わせフォームだ。実装の指定がなければ、ベンダーにとっての最適解は「最も簡単な実装方法」になる。
具体例を挙げよう。
検索機能なら「全件取得してフロントでフィルタリング」。動くが、データが増えればパフォーマンスは破綻する。
エラーハンドリングなら「例外メッセージをそのまま表示」。動くが、ユーザーには意味不明だ。
レスポンシブ対応なら「指定がないのでPCのみ」。動くが、スマホで見ると崩れる。
そして、動かしてからトラブルになることも少なくない。
これが「工数最小化ゲーム」だ。ベンダーは悪意でやっているわけではない。請負契約において、これは合理的な行動なのだ。
アジャイルはウォーターフォールの課題を解決できる。しかし——
後から仕様の変更を受け入れられるような契約にすることで、ウォーターフォールの課題を解決したい。
そこで注目されたのが、準委任契約でアジャイル型開発を採用することだ。
アジャイルの話をする前に、準委任契約についておさらいをしよう。
準委任契約とは
一言で言えば、納品する成果物ではなく稼働する期間を約束する契約だ。
もちろんその契約期間は誠実に働くことが前提となるが、成果物が完成しようとしまいと、ユーザー企業はベンダーへ費用を支払う必要がある。
主にシステム保守やコンサルティングなど、成果物の完成を約束しない業務に適しており、幅広く使われている。
請負契約との違いを表にまとめる。
| 項目 | 請負契約 | 準委任契約 |
|---|---|---|
| 契約目的 | 成果物の「完成」 | 業務の「実施」 |
| 責任範囲 | 成果保証義務 | 善管注意義務（民法644条） |
| リスク所在 | 受注側（ベンダー） | 委任者側（ユーザー企業） |
| 主な適用例 | 建築工事・ソフト開発 | システム監視・診療行為 |
準委任契約を結ぶことで、後からベンダー側へ自由に修正を提案できるようになる。これは良いことだ。
要件が固まっていなくても開発を始められる。スプリントごとに方向性を修正できる。ユーザーのフィードバックを反映しやすい。
ウォーターフォールの「最初に全て決めなければならない」という課題は、確かに解決できる。
しかし、新しい問題が発生する。
準委任契約は工数が長引くほどベンダーが得をする
それは、契約上ベンダー側に早く終わらせるインセンティブがないということだ。
準委任契約では、月額×期間で報酬が決まる。ということは、早く終わると売上が減る。品質を上げても報酬は変わらない。
極端なことを言えば、「適度に長引かせる」のが最適戦略になりうる。
実際に起きる問題を挙げてみよう。
「まだ調査中です」が続く。技術選定に時間をかけすぎる。過剰な設計・ドキュメント作成。本来不要な機能の提案。
もちろん、これは極端な話だ。多くのベンダーは誠実に仕事をしている。
しかし、インセンティブ構造が歪んでいる限り、問題は残る。「良い人」であっても「合理的に行動」すれば、自然とそうなりうる。
ウォーターフォールでは「工数最小化ゲーム」が問題だった。
アジャイル（準委任）では「工数最大化ゲーム」のリスクがある。
問題が消えたのではない。形を変えただけなのだ。
システムが未完成のまま契約期間が終わる。これは十分にありえるシナリオだ。
「信頼できるベンダーを選べばいい」のか
ここで、読者からの反論が聞こえてきそうだ。
「信頼できるベンダーを選べばいいのでは？」
確かに、信頼関係は重要だ。実績のあるベンダーを選ぶことは大切だ。
しかし、それは属人的な解決策だ。インセンティブ構造が歪んでいる限り、問題は残る。担当者が変わったら？会社の方針が変わったら？
属人的な解決策は、仕組みとして脆弱だ。
「スプリントレビューで進捗を確認すればいい」という意見もあるだろう。
しかし、進捗確認はできても、それが「最速かどうか」は判断できない。ユーザー企業側に技術的知見がなければ、「必要な作業」と「不要な作業」の区別がつかない。
ベンダーが「この技術調査に2週間かかります」と言ったとき、それが妥当かどうか、判断できるだろうか。
ではどうすればいいのか
では、どうすればいいのか。
正直に言えば、完全な解決策はない。しかし、ぼくがベターだと考える方向性がある。
要件定義までを準委任、それ以降を請負
ハイブリッド型の契約だ。
考えてみてほしい。要件定義フェーズと実装フェーズでは、不確実性の度合いが全く違う。
要件定義フェーズは不確実性が高い。何を作るべきか、まだわかっていない。ここで請負契約を結ぶと、「決まっていないことを決まったことにする」という無理が生じる。だから準委任が適している。
一方、実装フェーズは要件が固まっている。何を作るかは決まった。あとは作るだけだ。ここでは請負契約が適している。成果物の完成を約束させることで、ベンダーに「終わらせる」インセンティブが生まれる。
つまり、各フェーズの特性に合った契約形態を選択する。これがハイブリッド型の考え方だ。
要件定義でROIベースの優先順位をつける
ただし、ハイブリッド型を成功させるには、要件定義フェーズでの仕事の質が問われる。
ここで重要なのが、ROIベースで要件を絞り込むことだ。
「あったらいいな」という機能を全て入れてはいけない。使われる機能だけを要件に含める。予算内で最高のシステムを作ることを目指す。
80:20の法則を思い出してほしい。システムの20%の機能が、80%の価値を生む。逆に言えば、80%の機能は、20%の価値しか生まない。
要件定義フェーズで「この機能は本当にROIが見合うか？」と問い続けることが重要だ。
たとえば「管理画面に高度な検索機能がほしい」という要望があったとする。しかし、その機能を使うのは月に1回かもしれない。それに100万円かけるのは適切だろうか。
要件定義フェーズで徹底的に優先順位をつける。そして、本当に必要な機能だけを請負フェーズに持ち込む。
こうすることで、請負フェーズでの「工数最小化ゲーム」のリスクも軽減できる。要件が明確で絞り込まれていれば、ベンダーが「最小工数で逃げる」余地が減るからだ。
その他の選択肢
もちろん、他の選択肢もある。
マイルストーン型準委任: 期間ではなく成果物単位で契約する。小さな単位で区切り、その都度精算する。
ゲインシェアリング: コスト削減分を分配するインセンティブ設計。早く終われば、その分をベンダーにも還元する。
ユーザー企業側のPM参加: 技術的知見を持つ人材をユーザー企業側に配置する。内製化への第一歩としても機能する。
ラボ型契約: チームを固定し、長期的な信頼関係を構築する。
どれも一長一短がある。しかし、ぼくは「要件定義までを準委任、それ以降を請負」というハイブリッド型が、多くのケースでベターな選択だと考えている。
まとめ
アジャイル型開発は素晴らしい手法だ。自社開発では非常に有用だ。
しかし、受託開発においては、ウォーターフォールの課題を解決すると同時に、新しい課題を生む。
請負契約の問題は「工数最小化ゲーム」。
準委任契約の問題は「工数最大化ゲーム」のリスク。
どちらもインセンティブ構造の問題だ。契約形態を変えても、インセンティブの歪みが消えるわけではない。歪みの方向が変わるだけだ。
銀の弾丸はない。
しかし、ベターな選択肢はある。
要件定義までを準委任で行い、それ以降を請負で行う。そして、要件定義フェーズでROIベースの優先順位をつけ、本当に必要な機能だけを請負フェーズに持ち込む。
予算内で最高のシステムを作る。そのために、「あったらいいな」ではなく「なければならない」機能に集中する。
「アジャイルにすれば大丈夫」という単純な話を、ぼくは信じない。
しかし、フェーズごとに適切な契約形態を選び、要件を徹底的に絞り込むことで、受託開発の成功確率を上げることはできる。
読者の皆さんも、安易な解決策に飛びつく前に、一度立ち止まって考えてみてほしい。