ウォーターフォールの反省とアジャイルの成功に必要なもの

この記事では、「アジャイルはウォーターフォール時代の何を反省するのか」「アジャイルで何が改善するのか」について、個人的な考えを説明します
極端なことを言っている部分はあるので、誤解している箇所や異論があれば、やさしくコメントで教えていただければ幸いです

言いたいこと

• 「ウォーターフォール＝諸悪の根源」というのは誤解で、問題は請負契約にある
• 請負契約で「顧客の真の要望が実現されない」のは当然、インセンティブ設計がおかしい
• 日本版のアジャイルソフトウェア開発宣言には「外注よりも内製を」と書くべき
• 競争に勝つためには内製化は進む(でも内製化はとても難しい)
• ベンダーへ「君はアジャイルをやるか迷える立場じゃないよ」

---

目次

1. 用語
2. ウォーターフォールは本当に諸悪の根源か？
   • 「ウォーターフォール＝諸悪の根源」という誤解
   • 問題の原因は請負契約
3. なぜ請負契約は失敗しやすいのか？
   • ベンダーは「システム開発だけ」で利益をだす必要がある
   • ベンダーが要望の取り込みやリリース回数を減らしたがる理由
   • ユーザ企業がシステム開発に失敗してもベンダーは利益がでる!?
4. 外注に依存する日本企業の現状
5. システム開発成功のための変革
   • 変革１内製化
     • 日本版のアジャイルソフトウェア開発宣言には「外注よりも内製を」と書くべき
     • 内製化は正のループにつながる
     • 競争に勝つために内製化は進む
   • 変革２：ユーザ企業のマインドチェンジ
   • 変革３：組織改革
6. 内製化のその先
   • ベンダーへ「アジャイルをやろうか迷える立場じゃないよ」
   • 内製化の流行でベンダーは単なる人貸しになるのか？
   • 内製／外注の使い分け
   • 請負契約でスクラムは成り立たない
7. 想定QA
8. おわりに

---

用語

ユーザ企業

ベンダーにシステム開発を委託する側の会社のこと。発注元。本記事では、特にシステムによる自社サービスを持つ事業会社を指す。

ベンダー

システム開発を請け負う会社のこと。受託開発。本記事ではSIer、ITベンダー、ソフトハウスなどを指す。

アジャイル

ソフトウェア開発などのプロジェクトを柔軟かつ迅速に進めるための手法や考え方

スクラム

アジャイル開発の代表的なフレームワーク

ウォーターフォール

ソフトウェアの開発手法の１つ。開発工程を上流工程から下流工程へ順番に進めていく

請負契約

請負人が仕事を完成することを約束し、依頼者がこれに対して報酬を支払うことを内容とする契約形態。成果物の完成責任がある

準委任契約

受託者の作業の遂行に対して報酬を支払う契約形態。SESは準委任契約の１つ。成果物の完成責任がない

アジャイル／スクラムに関する参考：
あらためて、アジャイル開発とは｜その概要から進め方、メリット・デメリット、開発手法について

注意

• 本記事は、日本のソフトウェア開発で約4割を占めている¹「ベンダーへの外注による請負開発（受託、請負契約）」を主題にしています
  既に自社サービス開発をしている場合やWEB業界には当てはまらない部分がありますので、注意ください
• 本記事のベンダー像は実際のベンダーとは大きく異なります
  本記事ではインセンティブ設計について語るため、ベンダーが「合理的経済人」、つまり「自社の利益を最優先する」存在であるとしています
  

ウォーターフォールは本当に諸悪の根源か？

巷では「これまでのシステム開発失敗の原因はウォーターフォールで進めていたから、アジャイルに変えれば解決する」といった言説をよく耳にしますが、果たして本当でしょうか？

アジャイルに移行することで解決すると言われている問題には、次のようなものがあります

• ①変化に対応できない
• ②リリースが遅い、リリース間隔が長い
• ③大量のドキュメントを作成しなければならない
• ④顧客が本当に求める機能が実現されない

「ウォーターフォール＝諸悪の根源」という誤解

結論から述べると、開発失敗の原因は、ウォーターフォールではなく 「請負契約」 ²にあり、その背景には請負契約を選択するユーザ企業のマインドがあります（下図参照）
図の内容について以降で詳しく説明します

問題の原因は請負契約

請負契約とは、ユーザ企業が発注した要件にもとづいてベンダーが開発を行い、契約時に定められた納期までに成果物を納品する開発形態のことです
契約額は基本的に契約時に決まります
先の①～④の問題の直接の原因が請負契約にあることを説明します

①変化に対応できない

請負契約では、発注時点で要件が固まっている契約(建前上)なので、変化に対応できないのは当然です
言い換えると、最初に決まった要件どおりに作ればいいで、「変化に対応する必要がない」とも言えます
しかし、もし要件が決まっていないのに請負契約をスタートしていたとしたら、それは何を作るか決まっていないのに価格と期日だけ決まっているという不合理な契約になり、そんな守れるかわからない契約をしたベンダーにも責任があります

②リリースが遅い

請負契約では瑕疵担保責任があるため、ベンダーには「不具合を出したくない」という強いインセンティブが働き、リリース前に厳重な試験を行うため、リリースが遅くなります
また、契約時に納期が決まっているので、ベンダーにリリースを早める理由がありません

③大量のドキュメント

たいていの請負契約では、そもそも納入品としてドキュメントが指定されるため、作成する必要があります
それとは別に「製造プロセスは正しかったか」や「納入品は要求された品質を満たしてるか」を記録に残す必要があるため、大量のドキュメントを作る必要があります

④顧客が本当に求める機能が実現されない

請負契約では「発注時にユーザ企業が自分達の本当の要望を要件仕様書に書く」ことが求められますが、そんなことができるユーザ企業はいません
そのため、請負契約では、要件仕様書どおりのシステムが納品されてから、必要な機能がないとなりがちです

私が伝えたいのは、問題の原因は請負契約にあるため、契約が請負契約のまま別の開発手法(プロトタイプ開発やスクラムなど)に変えても問題は解決しないということです

「請負契約だけどスクラム」をやろうとしても、ベンダーが利益を優先する限り、リリース回数は減らそうとしますし、不具合発生を恐れて複雑な修正を避ける、などが起きます

なぜ請負契約は失敗しやすいのか？

ベンダーは「システム開発だけ」で利益をだす必要がある

まず理想的なシステム開発の収益モデルを考えると、「顧客の本当のニーズを実現する優れたシステムを開発する」⇒「その影響でビジネスが拡大し、売上が向上する」⇒「いいシステムを開発したチームが報酬を得る」という流れです

しかし請負契約では、ベンダーは「システム開発だけ」で利益をだすことが求められます
そうなると、利益優先のベンダーの場合、「開発コストをできるだけ抑えること」が最優先になりがちです
その結果、「顧客の本当のニーズを満たしているか」や「システムが実際に役立つか」といった重要な要素が軽視されることになります

ベンダーが要望の取り込みやリリース回数を減らしたがる理由

請負契約による開発中は、ベンダーとユーザ企業は利益相反します
予算は既に決まっているため、開発中にユーザが気づいた新しい要望を取り入れると、仕様変更にかかった分だけ利益が減るためです

追加の作業はすべて利益を圧迫するため、ベンダーにとっては、「顧客の要望を聞きたくないしリリース回数もなるだけ減らしたい」となります

アジャイルで頻繁なリリースが推奨される理由は「仮説の誤りに早く気づくため、早く変更するため」ですが、請負による開発中はそのどちらも望まれていないのです
ベンダーにとっては「顧客が要件の誤りに気付くのは納入後でいいし、仕様変更はないほうがいい」となります

ユーザ企業がシステム開発に失敗してもベンダーは利益がでる!?

これは結構闇が深いのですが・・・実は、ユーザ企業がシステム開発にどれだけ失敗しても、ベンダーには利益がでていることがあります
むしろ逆に、失敗したほうがベンダーの利益が増えるケースも珍しくありません

よくニュースで「〇〇企業が、システム開発の難航で開発費が〇〇億円に高騰」という話を耳にします
この「高騰した開発費」というのは、実はベンダーの売り上げです

請負契約では、利益優先のベンダー企業は、ユーザ企業のビジネス成功やシステムが役に立つかよりも、 「いかに開発費を抑えて要求仕様を満たすシステムを作るか」 に注力します
これにより、ユーザ企業にとっては実用性に欠けるシステムが提供され、開発費が肥大化し、結果的にビジネスの失敗につながることも多いです

このような状況は、明らかにインセンティブの設計が誤っていると言えるでしょう

小話：ユーザー重視のA君と計画重視のB君

インセンティブの設計の誤りが人の行動にどのような影響を与えるか、具体例で示します
A君とB君は同じベンダーに所属する同期で、それぞれ別の請負契約プロジェクトを任されています
それぞれの仕事の進め方と成果はこのような感じでした

• A君：
  • ユーザからの評判を重視。計画外でも要望を積極的に取り入れる。利益は計画どおりか若干悪い。システムの使い勝手の評判はとてもよい。開発中に積極的に要望を取り込むため、追加開発の依頼は少なめ。
• B君：
  • 契約や計画を重視。計画外の要望は拒否して、追加費用を請求。利益はとても良い。システムの使い勝手の評判はいまいち。ＵＩが使いにくく足りない機能が多いため追加開発の依頼は多め。

上司からの評価としては、開発したシステムが使いにくくても、部門の利益への貢献度が高いB君のほうが高評価です
上司はA君に「B君の仕事の進め方からよく学ぶように」というありがたいお言葉をかけました

外注に依存する日本企業の現状

外注(請負契約)は、特に発注時に要件が固まっていない場合には、多くの構造的な問題があります

ではなぜ、ユーザ企業はシステム開発を外注するのでしょうか？
それは主に次のようなマインドがあるためだと考えます

開発失敗リスクを負いたくない

システム開発は、失敗したときに大きな損害が発生します
自社開発で数十億円かけたのに、何も成果がでなかったなんて話は珍しくありません
そういった開発失敗リスクを回避するために、多くの企業で外注が選ばれ、ベンダーに開発失敗リスクごと引き受けてもらっています

有識者不在、雇用もしたくない

もしシステムを内製する場合、当然、自社に有識者が必要になりますが、いくつかの問題が発生します
「給与水準が高い」「必要な期間が短い」「採用すべき専門家の選択ができない」
これらの問題を回避するために、ユーザ企業は有識者の直接雇用を避け、外注を選ぶ傾向がありました

予算・納期だけが先に決まる

多くのユーザ企業では、システムはビジネスゴールを達成するための手段という意識があり、そうするとビジネスゴールから逆算したシステム開発の予算・納期だけが先に決まることが多いです
具体的な要件や技術よりも、「予算内で納期までに」成果を出すことが優先されるため、予算と納期が先に決まる外注は都合がいいのです
ユーザ企業の中でのビジネスの進め方が、最初にすべての計画してしまうウォーターフォール的なので相性がいい、とも言えるかもしれません

システム開発成功のための変革

過去の開発失敗を招いた要因に「請負契約」があります

では、「アジャイル開発」に移行すればすべて解決するのでしょうか？
スクラムを導入して、バックログを用意して、毎日デイリースクラムをすればすべてがうまくいくのでしょうか？

話はそう簡単ではありません
前述のとおり、これまでの開発失敗の原因が「上流工程から下流工程へと順番に開発が進められていく」ことにあったわけではないからです

問題の根本はインセンティブ設計の誤りであり、システム開発の成功には、ユーザ企業の中で大きく３つの変革が必要だと考えます
内製化、マインドチェンジ、組織改革です

この３つは別々の施策ではなく 「内製化を成功させようとすると、結果的にやらざるをえないもの」 です

変革１：内製化

日本版のアジャイルソフトウェア開発宣言には「外注よりも内製を」と書くべき

アジャイル開発といえば『アジャイルソフトウェア開発宣言』ですね
2001年にアメリカのユタ州で発表されました

私は、もし日本版のアジャイルソフトウェア開発宣言を作成するのであれば、「外注よりも内製を」 と追記したほうがいいと考えます
「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供」するためには外注では無理で、効率を追い求めるといずれ内製化せざるを得ないからです

なぜ元々のアジャイルソフトウェア開発宣言には、外注や内製の話がないのでしょうか？
想像ですが、アメリカでは元々内製が中心だから、おそらく書く必要がなかったんでしょうね

内製化は「正のループ」につながる

内製化によって改善が期待できることの１つは、「開発チームがよいシステムが作れたら報酬が増える」という「正のループ」構造への転換です
請負契約の場合は、システム開発領域とビジネス領域で収益構造が独立してしまっていました
内製することで、開発チームもビジネスチームも、会社のビジネスゴールという共通の目標に向かって進むことができます³

よい機能が素早くリリースされ、ビジネス的な価値を生み出すことで、開発チームに報酬がフィードバックされるのが理想です

競争に勝つために内製化は進む

ベンダー視点だと、「これまで丸投げ体質だったユーザ企業で本当に内製化が進むのか」というのは疑問に思うところだと思います
しかし、私は遅かれ早かれ内製化は確実に進むと予想しています

なぜなら、「ビジネス的に価値あるシステムをどれだけ早くリリースできるか」が企業の競争力を決める時代 になっているからです
今や企業が持つシステムや開発チームの良し悪しは、ビジネスの競争力に直結しています

また近年、システムの使いやすさに対するユーザーの目は一層厳しくなっています
例えば、利用するサービスを比較して選ぶ際に、 「UIの使いやすさ」 が重視されています
よいＵＩのシステムを作ろうとすれば、外注では難しく、内製化して改善サイクルを素早く回していく必要があるでしょう

もちろん内製化の実現は簡単ではないので、「内製にチャレンジしたけど失敗して倒産する」 企業もでてくると思います
ただ、現状のままずっと外注に頼っていてもいずれ競争に負けるのは明らかなので、どこかで転換が必要なのは間違いないと思います
「変革か死か」 ということです

変革２：ユーザ企業のマインドチェンジ

システム開発を外注する背景として、これまでのユーザ企業には次のようなマインドがあったこと説明しました

• 有識者不在、雇用もしたくない
• 開発失敗リスクは負いたくない
• 予算・納期だけが決まる

内製化を進めるにあたってはこれらのマインドを変える必要があります

• アジャイルを進めるコアメンバーとして、エンジニアの直接雇用
• 開発失敗リスクを認識した上で、自社でシステム開発を行う。勤務場所や開発環境のコストも自社で負担する
• 予算・納期をあらかじめ計画して決めるのではなく、変化に対応して柔軟に進める意識

変革３：組織改革

内製化を進めるためには、エンジニアの直接雇用が必要です
つまり、組織の中にエンジニアのポストを用意しなければならないのです
既存社員から不満がでない、でも新しいエンジニアが満足するようなポストを

そして直接雇用するということは、エンジニアの評価制度、教育環境、キャリアパスなど、付随して色々なものを整備する必要があります、まさしく組織改革ですね
（この辺の面倒を避けるためなのか、最近、システム子会社の設立が多いですね）

エンジニアを雇用するだけで、ポストやキャリアパスの整備を怠った会社からは、エンジニアは離れていくでしょう
そして内製化の失敗にも繋がります

「アジャイルは開発手法の話だけじゃないよ」 ということです
アジャイルを進めるとどこかの段階で内製化が必要になり、内製化のためにはエンジニアの雇用が必要で、エンジニアを雇用し続けるためには組織改革が必須です
アジャイルとはすべてを焼き尽くす変革の炎なのです

内製化のその先

ユーザ企業による内製化は、ユーザ企業だけでなく、業界構造を変える可能性があります

ベンダーへ「アジャイルをやろうか迷える立場じゃないよ」

アジャイルのコアは「顧客に素早く価値あるソフトウェアを提供」することです
そのためには製品が自社サービスである必要があります
製品に関する責任を自社で負っているから、素早く意思決定を行えるのです

当たり前ですが、自社サービスを持っていない企業はアジャイル開発を主導することはできません

もちろんベンダーが準委任で開発者を提供したり、開発の一部を請け負ったりすることはあると思います
しかし、そのときアジャイル開発を主体的に行っているのはあくまでユーザ企業です

製品に関する意思決定を行って改善サイクルを回しているのはユーザ企業だからです
ベンダーはただ人を提供しているだけで、開発失敗リスクも負っていません

内製化の流行でベンダーは単なる人貸しになるのか？

アジャイルによる内製化が進むと、これまでのベンダーを頂点とする多重請負構造も変わります

ユーザ企業は外注するのではなく、自社で開発者を抱えてシステムを開発します
そのとき開発者全員をプロパー社員で用意することはできないので、SES(準委任)や派遣も活用することになります
これまでベンダーや開発会社で開発を行っていた人が、今度はユーザ企業で開発を行います

ベンダーは準委任で人を提供しますが、それではこれまでどおりの売り上げを維持することはできないでしょう
ベンダーの経営悪化につながります

長期的には、経営悪化してベンダーの待遇が悪くなると、ユーザ企業へ転職する人も増えるでしょう

内製／外注の使い分け

内製化を果たしたユーザ企業でも、すべて内製化するわけではなく、開発するシステムの特性によって内製／外注を使い分けを行います
「要件が固まっているか」と「内製か外注か」の2軸で開発手法を整理しました

また、より長期的な視点での意思決定としては、「自社で開発失敗リスクを負えるか」という視点で整理することもできます

「請負契約でスクラム」は成り立たない

最後に、たまに言い出す人がいる「請負契約でスクラム」について、成り立たない理由を説明します

納期と成果物を固定化するので変化に対応できない

請負契約は予算・納期・品質を固定するので、スクラムの利点である変化への対応が難しいです

自己組織化しない

請負契約では発注元が決めた納品物を作ることが目的となるので、スクラムが求める自己組織化が達成されにくいです

プロダクトオーナーとのコミュニケーションが困難

スクラムではプロダクトオーナーと開発チームの対等な立場の対話が重要ですが、請負契約では発注元・発注先というヒエラルキーが生まれるため難しいです

想定 QA

ユーザ企業視点

Q.アジャイルやるなら組織改革やキャリアパス整備をしろ？たかがシステムの開発に大げさすぎる

A.そういう認識の方は、アジャイルは向いてないと考えます
アジャイルをやるには自走力のあるエンジニアを集める必要があり、そういった優秀な人を採用するには組織改革が必要です

Q.外注(請負契約)だけど、開発途中で動くもの確認して、必要なら仕様変更したい

A.求める条件で請負契約を出して、ベンダーが合意すれば可能でしょう（スパイラル開発やインクリメント開発があります）
ただ結局、ベンダーが単発プロジェクト内で利益を最大化しようとすると、「仕様変更が少なくなるようにする」ことにインセンティブが働くので、どこまで効果があるのかは疑問です

Q.外注(請負契約)だけど、スクラムみたいに変更要望をいつでも受け付けてほしいんだけど

A.「発注金額がバカ高くなる」や「変更要望を出すほどリリースも遅れる」のどちらかを受け入れれば、仕事を受けてくれるベンダーもいるかもしれないですね

Q.hogeシステムはウォーターフォール(外注)で開発してるからだめなんだ。アジャイルで開発すればうまくいくのに。そう思いませんか？

A.システム開発の形態というのは、開発失敗リスクを誰が取るかがポイントになります
「アジャイルで開発しろ」と言うのは「開発会社ではなくお前の会社が(内製して)開発失敗リスクを負え」と言ってるのと同じです
内製か外注かというのは、システムの将来像や経営戦略を含む複雑な問題であり、外野が簡単に判断できるものではないと考えます

Q.官公庁系ですが、アジャイル開発できますか？

A.個人的には、以下の理由からアジャイルによる内製化は難しいと考えます
・官公庁のリスク回避指向や官僚制とアジャイルが相性悪い
・システムがどれだけ改善しても収益が上がらない
・プロジェクト成否と給与/報酬が連動しない
・「アジャイル開発を推進できるレベルの担当者」と公務員の給与にギャップがある
・担当者が開発スキルを身に着けても数年で異動する
・「〇人が〇ヶ月頑張って開発します。何ができるかはできてからのお楽しみ」では予算が確保できない
・失敗を許容しない文化

Q.「外注なら開発失敗リスクを他社に移転できる」といいますが、実際はできないのでは？
開発に失敗したら、結局自社の事業がうまくいかないですよね

A.その通りです。それを「リスク回避できますよ」と言って請け負うのがベンダーです
実際、大手ベンダーは業界内での評判をとても気にするので、開発失敗を避けるために最大限努力してくれます
あとは内製で開発に失敗しても何も保証されないですが、外注で開発に失敗したときは違約金が払われる場合があるので、リスクが多少軽減されます

ベンダー視点

Q.ベンダーに所属していると、アジャイルな開発には参画できないんでしょうか？

A.そんなことはなく、色々と工夫した取り組みを行っている会社も多いです
具体例を挙げると、ソニックガーデンさんの納品のない受託開発やラジコードさんの定額制開発などがあります

Q.ユーザー企業で内製化が流行り、受託(請負開発)がなくなると困る。今抱えているプロパー社員はマネジメントやテストばかりで開発能力はない。どうすればいい

A.知りません、自分で考えてください
とりあえず部門目標資料に雑に「アジャイルを～」みたいなのを書くのやめてください

Q.ベンダーがすべて利益優先なわけではない。請負契約でも、きちんと「ユーザの真の要求」を分析して、いいシステムを開発しようとするベンダーもたくさんある

A.そのとおりで、私もそういう会社がたくさんあることは知っています
ただ、（インセンティブ設計に反して）開発会社がきちんと要求分析していいシステムを導入してくれたのは、スケジュールや予算に余裕があったからだともいえると思います
例えば、予算が少ない、開発期間が短い、担当者が急に辞めたなどで、開発会社に余裕がない場合、要求を最低限を満たすシステムになっていた可能性は高いのではないでしょうか

Q.ウォーターフォールは無駄なドキュメント多すぎ。スクラムは必要なドキュメントしか作らないから効率的！

A.ドキュメントが多い原因は、（ウォーターフォールだからではなく）請負契約だからです
請負契約では、品質保証のためのドキュメントを作成する必要があります

そしてスクラムというか内製開発のドキュメントが最小限でいいのは「品質リスクを自分で負っている」からです
「ドキュメントをどれぐらい書くかはお前自身が決めなさい。ドキュメントがなくて困るのはお前だから」 ということです

Q.請負のウォーターフォール型の開発でも、スクラムのいい所を取り入れたいです

A.素晴らしい心がけですね、とてもいいと思います
ただ気をつけてほしいのは、請負型の契約で利益の最大化を求めると、「最初に要件をきっちりもれなく固める」「一気に製造」というウォーターフォール型が効率がいいことです
これはやり方の話ではなくて、契約時に契約額とリリース日が固定されることに起因します

これまで請負契約で、スクラムのような動的な要望取り込みを行わなかった理由：
　✖「スクラムのようなやり方を知らなかった」
　〇「要望を取り込まない(仕様変更を避ける)と利益が増えるというインセンティブが働く」

おわりに

ここまで読んでいただきありがとうございました
軽い気持ちで書き始めたのに、積年の恨みつらみがでてきて、意図せず長文になってしまいました

私がずっと気になっていたのは、一部の人の「これまでの開発ベンダーは効率的なやりかた(アジャイル)を知らなかったから失敗した、新しい手法が見つかったからこれからはうまくいく」という勘違いです

外注のソフトウェア開発が失敗するのは構造的な問題です
私が普段接するベンダーの方は、不勉強なわけでも、効率が悪いわけでもありません
むしろ効率をおいもとめて、会社や契約に忠実だから、(ユーザ企業から見ると)開発が失敗しているように見えるのではないかと考えていました

そして内製化というのは、「注文住宅は高いから自分で設計して建てる」という話だと思っています
家の建築だと誰でも難しいとわかると思うんですが、ソフトウェアになると自分でできると思ってしまうのはなぜでしょうか

今後、日本もアメリカのようにどんどん内製化が進んでいくのか、デカい顔してたＩＴベンダーはどうなるのか、注目しています

1. IPA DX 動向2024の「2.4. システム開発等の内製化の状況」より ↩

2. ウォーターフォールで開発するのは請負開発だけだろうという前提です。もし自社サービス開発でウォーターフォールやってる所があったらごめんなさい。 ↩

3. 共通のゴールに”進めるようになる”と言ってるだけで進むとは言ってません ↩