アジャイル開発は「速くて安い開発」ではない—発注側の経営者が、決める役・予算の上限・止める条件を先に決めて進める

1｜結論—今すぐ取るべき経営判断

アジャイル開発を選ぶなら、「速くて安い開発」として発注しないでください。作りながら要求を固める方式として、発注側から優先順位を決める人を出します。そのうえで、予算の上限・期間・途中で止める条件の3つを先に決めてから始めます。固定するのはこの3つで、作る範囲は毎回の成果を見て見直します。

仕様を固めて一括で発注するか、小さく作って直しながら進めるかは、三つの条件で選びます。第一に、要求がどこまで固まっているか。第二に、後から変更したときの費用がどれだけ大きいか。第三に、発注側から決める人を出せるか。要求が固まらず、変更の費用が小さく、決める人を出せるなら、小さく作って直す進め方が向きます。どれかが欠けるなら、仕様を固めて一括で発注します。

決める人を出せないままアジャイル開発を始めると、優先順位が決まらず、開発は止まるか膨らみます。進め方を選ぶ前に、誰が毎回の成果を見て決めるのかを社内で決めてください。

2｜なぜ「速くて安い」と考えると失敗するのか—決める回数が増える方式

日経コンピュータは2018年に、1,745件のプロジェクトについて回答を集めました。スケジュール・コスト・満足度の3つすべてを満たした「成功」は、判定できた1,238件のうち52.8%でした（出典：日経クロステック、2018年2月）。約半数のプロジェクトが、どれか1つ以上で計画どおりに終わっていないことになります。同誌は別の記事で、失敗の理由には「要件定義の甘さ」など昔から変わらない内容が並ぶと指摘しています（出典：日経クロステック、2018年11月）。最初にすべての要求を書き出すことは、それほど難しいのです。

アジャイル開発は、この難しさを、作りながら確かめることで補う方式です。代表的な進め方にスクラムがあります。スクラムでは、スプリントと呼ぶ「1か月以内の決まった長さ」の期間ごとに、動くものを作って確かめます（出典：『スクラムガイド』日本語版、2020年11月）。作る機能の優先順位の一覧を管理し、何から作るかを決める役は、プロダクトオーナーと呼ばれます。

ここで見落とされやすいのは、確かめて決めるのが誰かという点です。毎回の成果を見て、次に何を作るか、何をやめるかを決めるのは、そのシステムを使う発注側です。決める回数は、一括で発注する場合より多くなります。ベンダーに任せれば速く安くなる、と考えて決める人を出さないと、決めるべきことが積み残され、開発は止まるか、作るものが膨らみます。

3｜どちらで発注するか—開発の種類と契約の形で選ぶ

開発の種類によって、向く進め方は分かれます。下の表の区切りと止める条件の例は、本稿の目安です。

ERP（会計・販売・在庫などの基幹業務をまとめて扱うシステム）の導入では、業務の型があらかじめ決まっています。後から変更する費用も大きいため、仕様を固める進め方が向きます。

契約の形は、受注側が何に責任を負うかで分かれます。民法では、請負は「仕事を完成すること」を約束する契約です（632条）。準委任（委任の規定が当てはめられる契約）では、受注側は「善良な管理者の注意」をもって事務を処理する義務を負います。完成の義務はありません（644条・656条）。成果に対して報酬を払う取り決めもできますが（648条の2）、それで完成の義務が生まれるわけではありません（出典：e-Gov法令検索「民法」）。IPA（情報処理推進機構）は、準委任契約を前提にしたアジャイル開発向けのモデル契約を公開しています（出典：IPA「情報システム・モデル取引・契約書（アジャイル開発版）」、2020年3月）。

4｜発注側が進める4つのステップ

STEP1　決める人を出し、時間を確保する

社内から、優先順位を決める人を1人出します。スプリントのたびに成果を確かめる会議に出られるよう、予定を先に押さえます。決める人が会議に出られない状態で始めないでください。

STEP2　予算の上限・期間・止める条件を先に決める

経営会議で承認するのは、作る範囲ではなく、予算の上限、期間、途中で止める条件です。例えば「上限は○○万円、期間は6か月、3回のスプリントで目標に届かなければ止める」と決めます。作る範囲は、スプリントごとに見直します。

STEP3　契約と指示の経路を決める

準委任でも請負でも、発注側が受注側の開発者に直接指示を出すと、偽装請負と判断されることがあります。厚生労働省の疑義応答集は、次の場合を偽装請負と判断するとしています。発注者側の開発責任者などが、受注者側の開発担当者に直接、業務の遂行方法や労働時間などを指示し、指揮命令があると認められる場合です。一方で、作る機能の優先順位の一覧（プロダクトバックログ）の内容を詳しく説明したり、情報を提供したりするだけでは、直ちに偽装請負と判断されるわけではないとも示しています（出典：厚生労働省「37号告示関係疑義応答集（第3集）」）。要望は受注側の責任者に伝える、という経路を契約に書いておきます。

STEP4　スプリントごとに受け入れ、続けるか止めるかを決める

スプリントの終わりに、動くものを見て、受け入れるか、直すか、次に何を作るかを決めます。STEP2の止める条件に当たれば、その時点で止めます。生成AIを使えば、試作は以前より速く作れるようになりました。それでも、できたものが自社の業務に合うかを確かめて受け入れるのは発注側です。公的な指針で示されたことではありませんが、作る速さが上がるほど、確かめて決める回数は増えると考えるべきです。

5｜よくある誤解—アジャイル開発を「任せる開発」にしない

誤解①　「アジャイル開発なら、仕様を決めなくてよい」

仕様をまとめて最初に決めない代わりに、スプリントのたびに少しずつ決めます。決める回数はむしろ増えます。決める役は発注側です。

誤解②　「ベンダーに任せれば、速く安くなる」

優先順位を決める人が発注側にいなければ、受注側は何を先に作るかを決められません。その結果、確認待ちで開発が止まるか、念のための機能が増えて費用が膨らみます。速さと費用を決めるのは、発注側が決める速さです。

誤解③　「予算と納期を固定できない方式は、経営会議で承認できない」

最も強い反論はこれです。「結局、請負で金額を固定して発注するしかない」という言い分には理があります。ただ、固定できないのは作る範囲であって、予算の上限・期間・止める条件は固定できます。経営会議では、この3つを承認してください。作るものが最初から固まっている開発なら、請負で固定する進め方が向いています（3章の表）。

6｜経営判断チェックリスト—今やるべきか否かの判断軸

アジャイル開発を選ぶべき企業の条件

• 作りたいものの要求が、使ってみないと固まらない
• 後から変更しても、費用が大きく膨らまない
• 優先順位を決める人を、社内から出せる
• その人が、スプリントごとの確認の場に出られる
• 予算の上限と止める条件を、経営会議で決められる

今やるべきかの判断軸

5項目のうち、3つ目と4つ目が当てはまらない場合は、まだアジャイル開発で始める時期ではありません。仕様を固めて一括で発注するか、決める人を出せるようになるまで待ちます。5項目がそろっていれば、対象を1つのサービスか1つの業務に絞り、小さく始めてください。

やらない場合のリスク

第一に、決める人がいないまま始めると、確認待ちで開発が止まり、期間と費用が延びます。第二に、予算の上限と止める条件がないと、成果が出ないまま支払いが続きます。第三に、受注側の開発者に直接指示を出す運用が続くと、偽装請負と判断されるおそれがあります。

7｜経営者への一言

開発の速さは、ベンダーの腕より、発注側が決める速さで決まります。発注する前に、決める人の予定表を空けてください。

参考文献

• 日経クロステック「システム開発プロジェクトの5割が失敗、1700件を独自分析」（2018年2月） https://xtech.nikkei.com/atcl/nxt/column/18/00177/022100001/
• 日経クロステック「IT業界が失敗プロジェクトを繰り返してしまう理由」（2018年11月） https://xtech.nikkei.com/atcl/nxt/column/18/00476/101100002/
• Ken Schwaber, Jeff Sutherland『スクラムガイド』日本語版（2020年11月） https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
• e-Gov法令検索「民法」 https://laws.e-gov.go.jp/law/129AC0000000089
• IPA（情報処理推進機構）「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年3月） https://www.ipa.go.jp/digital/model/agile20200331.html
• 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集（第3集）」 https://www.mhlw.go.jp/content/001704257.pdf