開発会社から「アジャイルで進めましょう」と提案されて、それを飲んでいいのか判断できずに調べている方は多いと思います。システム開発手法を検索すると6つや8つの手法が並んだ一覧が出てきますが、発注側が実際に選ぶ場面では、ウォーターフォールかアジャイルかの2択にほぼ集約されます。
そして手法の選択は、進め方が変わるだけの話では終わりません。請負契約になるか準委任契約になるか、見積もりが総額で出るか期間単位で出るかまで、この時点で決まってしまいます。後から変えようとすると契約を巻き直すことになるので、発注前に決めておきたい部分です。
この記事では手法の解説は必要な分にとどめて、自社がどちらで頼むべきかを決める判断軸と、その選択が契約と見積もりにどう跳ね返るかを、発注側の目線で整理します。
この記事のポイント
- 発注側が実際に選ぶのはウォーターフォールかアジャイルかの2択に集約される
- 要件が固まっているか、予算を先に確定したいか、自社の担当者を出せるかで決まる
- 手法を選んだ時点で請負契約か準委任契約かがほぼ決まる
- アジャイルは総額を先に固定できないので社内稟議の通し方が変わる
目次
システム開発手法の種類と選び方の判断軸
手法の一覧を眺めても、自社がどれを選ぶべきかは決まりません。発注側にとって必要なのは、種類を覚えることではなく、自社の状況を3つの軸に当てはめて答えを出すことです。まず選択肢を2つに絞ってから、その3軸を順番に見ていきます。
ウォーターフォールとアジャイルの違い
ウォーターフォールは、要件定義から設計、製造、テストまでを順番に進めて、前の工程が終わってから次に進む方式です。最初に作るものを全部決めてから着手するので、総額と納期を先に固定できます。その代わり、途中で「やっぱりこの機能も」となると、追加見積もりと工程の巻き戻しが発生します。
アジャイルは、2週間から1か月程度の短い期間を繰り返しながら、動くものを少しずつ増やしていく方式です。優先順位の高い機能から作るので、途中で方針を変えても手戻りが小さく済みます。その代わり、着手時点では総額と完成時期を確定できません。
一覧記事に出てくるプロトタイピングやスパイラル、DevOpsも気になるかもしれませんが、これらは発注側が最初に選ぶ層の選択肢ではありません。位置づけを整理すると次のようになります。
| 手法 | 進め方 | 発注側の選択肢か |
|---|---|---|
| ウォーターフォール | 工程を順番に進め、後戻りしない前提で組む | 選ぶ対象 |
| アジャイル | 短い期間を繰り返して動くものを増やす | 選ぶ対象 |
| プロトタイピング | 試作品を先に作って認識を合わせる | どちらの手法にも組み込める進め方 |
| スパイラル | 設計と試作を繰り返しながら精度を上げる | 実務ではアジャイルに近い扱い |
| DevOps | 開発と運用を連携させて改善を回す | 稼働後の体制づくりの話 |
つまり発注側が決めるのは「工程を順番に進めるか、繰り返しながら作るか」の1点です。ここが決まれば残りは開発会社が現場のやり方として組み立てます。アジャイルとスクラムの言葉の使い分けが気になる場合は、MVP・アジャイル・スクラム開発の違いと関係で整理しています。
要件が固まっているかで手法は決まる
1つ目の判断軸は、作りたいものがどこまで言葉になっているかです。ここが最も効きます。要件が固まっているならウォーターフォール、固まっていないならアジャイルというのが原則です。
「固まっている」の目安は、社内の別の人が読んでも同じものを思い浮かべられる状態かどうかです。私の感覚では、次の3つに全部答えられるなら固まっていると考えて差し支えありません。
- 今の業務のどの作業が、システム導入後にどう変わるかを説明できる
- 誰が使うのか、その人が1日に何回使うのかを言える
- 今回作らないものを名指しで挙げられる
3つ目に詰まる会社が多い印象です。作りたい機能はいくらでも出てくるのに、今回やらないことを決めていない。この状態でウォーターフォールを選ぶと、要件定義の途中で追加が止まらなくなり、結局スケジュールが崩れます。
逆に、既存システムの置き換えのように「今と同じことができればいい」というケースは、要件が固まっている側です。この場合にアジャイルを選ぶと、決まっている答えを毎回確認する会議が増えるだけで、費用も期間も無駄にかかります。
予算を先に確定したいときの選び方
2つ目の軸は、社内の予算の通し方です。総額を確定してから稟議に出す必要があるなら、選べるのはウォーターフォールです。
アジャイルは、着手時点で総額を確定できません。開発会社が出せるのは「1か月あたりいくらの体制で、何か月分」という形の見積もりで、その期間で完成するかどうかは進めてみないと分からない、という前提に立ちます。誠実な開発会社ほどここを曖昧にしません。
これは社内説明の難易度に直結します。「総額3,000万円で3月納品」と書ける稟議書と、「月額400万円の体制で、まず6か月」と書く稟議書では、通し方がまったく違います。後者を通すには、期間の途中で判断を見直す前提そのものを、決裁者に先に理解してもらう必要があります。
ここで無理をして、アジャイルで進めたいのに総額固定を開発会社に求めるケースがありますが、これはあまりうまくいきません。開発会社はリスク分を上乗せして高めの総額を出すか、範囲を厳しく縛るかのどちらかになり、結局アジャイルの利点が消えます。金額はあくまで一般的な目安なので、実際の判断は個別の見積もりで確認してください。
現場を巻き込めるかを先に確かめる
3つ目の軸は、自社側の体制です。アジャイルは、発注側の担当者が毎週のように判断を求められる進め方です。ここを見落としたまま選ぶと失敗します。
具体的には、2週間ごとに動くものを確認して、優先順位を決め直し、仕様の細部を即決する役が必要になります。この役を、業務の片手間ではなく、ある程度の時間を確保して担当できる人が社内にいるかどうか。いなければ、アジャイルの反復は「確認待ちで止まる」だけの仕組みになります。
ウォーターフォールなら発注側の稼働が要らない、という意味ではありません。要件定義と受入テストの時期には集中的に時間が要ります。ただ、負荷のかかる時期が前と後ろに寄るので、通常業務との調整はしやすくなります。
アジャイルを選んだ場合につまずきやすい点は、アジャイル開発が失敗する原因とデメリット・向き不向きで具体的に触れています。提案を受けている段階なら、先に目を通しておくと判断しやすくなります。
システム開発手法で変わる契約と見積もり
ここからが、手法の一覧記事にはあまり書かれていない部分です。手法は進め方の話にとどまらず、契約と支払いの形を決めます。ここを知らずに手法だけ合意すると、契約書の段階で話が食い違います。
請負契約と準委任契約の分かれ目
ウォーターフォールは請負契約と組み合わされるのが基本です。請負は「完成したものを納める」ことを約束する契約なので、作るものが先に決まっている方式と噛み合います。完成しなければ開発会社の責任になりますし、納品物に不具合があれば直す義務も生じます。
アジャイルは準委任契約になるのが一般的です。準委任は「決めた期間、決めた体制で作業する」ことを約束する契約で、特定の完成物を保証しません。何を作るかを進めながら決める方式なので、完成物を先に約束できないという理屈です。
発注側からすると、準委任は不安に見えるかもしれません。ただ、作るものが決まっていない状態で請負を結ぶほうが、実は危険です。範囲が曖昧なまま完成義務だけが存在すると、どこまでやれば完成なのかで揉めます。契約形態ごとの責任範囲の違いは、受託開発と請負開発の違いと契約形態・責任の範囲にまとめています。
手法によって見積もりの出方が変わる
契約形態が変われば、見積書の形も変わります。同じ「システム開発の見積もり」でも、比べ方が違うということです。
| 項目 | ウォーターフォール | アジャイル |
|---|---|---|
| 契約形態 | 請負が基本 | 準委任が基本 |
| 見積もりの単位 | 全工程の総額 | 期間あたりの体制費用 |
| 金額の確定時期 | 要件定義の完了時点 | 期間ごとに更新 |
| 比較で見る箇所 | 工程別の内訳と前提条件 | 体制の人数と単価、期間の区切り方 |
| 追加費用の出方 | 範囲外の要望は追加見積もり | 期間を延ばすかどうかの判断 |
相見積もりを取るときに気をつけたいのは、手法の違う提案を金額だけで並べないことです。総額3,000万円の請負と、月額400万円の準委任は、そもそも約束している内容が違うので、数字を横に並べても比較になりません。手法をこちらから指定して条件を揃えるか、揃えられないなら評価の軸を分けて記録しておく必要があります。
複数社の提案を同じ基準で並べ直したいときは、ベンダー選定比較表テンプレート（10カテゴリ100項目で4段階自動判定）で、見積の透明性や体制、契約条件といった価格以外の軸まで含めて採点できます。
提案された手法を鵜呑みにしない
もう一点だけ。開発会社が提案してくる手法は、案件に最適だから選ばれているとは限りません。その会社が普段やっているやり方が、そのまま提案に出てくることのほうが多いです。
これは悪意の話ではなく、単に得意なやり方で見積もったほうが精度が上がるからです。ただ、発注側としては、自社の3軸と合っているかを確かめる責任があります。提案を受けたら次を聞いてみてください。
- この手法を選んだ理由を、うちの状況に照らして説明してもらえますか
- もう一方の手法で進めた場合、何が変わりますか
- この進め方だと、うちの担当者はどのタイミングで何時間くらい必要ですか
- 途中で範囲を変えたくなったとき、費用と契約はどう扱われますか
4つ目に対して「柔軟に対応します」としか返ってこない場合は、もう一段踏み込んで聞いたほうがいいです。柔軟に対応する、の中身が追加見積もりなのか、期間延長なのか、範囲の入れ替えなのかで、後の話がまったく変わります。
- Q. システム開発手法にはどんな種類がありますか？
- A. 一般にはウォーターフォール、アジャイル、プロトタイピング、スパイラル、DevOpsなどが挙げられます。ただし発注側が選ぶ層の選択肢はウォーターフォールとアジャイルの2つで、残りはどちらかの中に組み込まれる進め方や、稼働後の体制の話です。種類を網羅するより、この2つのどちらで頼むかを決めるほうが実務では役立ちます。
- Q. ウォーターフォールとアジャイルはどちらが優れていますか？
- A. 優劣ではなく向き不向きです。要件が固まっていて総額を先に確定したいならウォーターフォール、作りながら決めたい部分が残っていて自社側の担当者を出せるならアジャイルが向きます。新しいから良い、古いから悪いという判断で選ぶと、社内の予算の通し方と合わなくなります。
- Q. アジャイルとスパイラルの違いは何ですか？
- A. どちらも繰り返しながら作る点は同じですが、スパイラルは設計と試作を繰り返してリスクを減らすことに重心があり、アジャイルは動く機能を優先順位順に届けることに重心があります。発注する立場では、実務上ほぼ同じ枠として扱って差し支えありません。
- Q. 小規模な開発でも手法を意識する必要はありますか？
- A. あります。規模が小さいほど契約形態と支払い方の影響が相対的に大きくなるためです。数百万円規模でも、請負で総額を固定するのか、準委任で月ごとに払うのかで、途中で仕様を変えたくなったときの扱いが変わります。
