「要件はすべて固めてから契約したはずだった」。ある製造業の専務は、システム開発の打ち合わせでそう漏らした。半年かけて要件定義書を作り込み、ハンコを押し、ようやく開発が始まった。ところが現場が実際に触れる画面ができてくると、次々と声が上がった。「この入力項目、実際の伝票の並びと違う」「現場では月末だけ特別な締め処理があるんです」「これ、営業が外出先からスマホで見られないと意味がない」。その都度、開発会社からは追加見積りと納期延長の連絡が届いた。当初300万円だった見積りは、最終的に480万円に膨らみ、稼働予定は3か月遅れた。専務は疲れた顔でこう続けた。「悪いのは現場でも開発会社でもない気がするんです。でも、どこで間違えたのかが分からない」。
この専務が踏んでしまった落とし穴は、実はとても多くの中小企業が同じ形で踏んでいる。原因の多くは、開発手法の選び方にある。アジャイル開発とウォーターフォール開発という、聞いたことはあっても中身をきちんと理解しないまま契約書にサインしてしまう二つの進め方。その違いを知らないまま発注することは、登山ルートを決めずに山に登り始めるようなものだ。どちらのルートにも良さがあるが、自社の体力や目的地に合わないルートを選べば、遭難に近い状態に陥る。この記事では、専門用語をできる限り削ぎ落として、中小企業の発注担当者が自社に合った選択をするための判断軸を届けたい。壁にぶつかりながらもシステムを形にしようとしているすべての担当者に向けて書く。
アジャイル開発とは何か
アジャイル開発を一言で表すなら「小さく作って、動かして、直しながら育てる」進め方だ。最初から完璧な設計図を用意するのではなく、まず本当に必要な機能だけを2週間から1か月程度の短い期間で作り、実際に触ってもらい、フィードバックをもらって次の期間でまた直す。これを何度も繰り返しながら、システムを少しずつ育てていく。
たとえば在庫管理システムを作るなら、最初のサイクルでは「在庫数を見る画面」だけを作って現場に触ってもらう。使ってみると「発注点を下回ったら色を変えてほしい」という要望が出る。次のサイクルでそれを反映する。さらに使い込むと「バーコードで入出庫したい」という声が出て、また次のサイクルで作り込む。料理に例えるなら、レシピを完全に固めてから一気に仕上げるのではなく、味見をしながら塩加減を調整していくやり方に近い。
この進め方の本質は、開発会社と発注企業が「一度きりの取引先」ではなく「一緒にものを作るチーム」になる点にある。現場の担当者が定期的に画面を見て意見を出す関与が前提になっている進め方であり、逆に言えば、その関与がなければアジャイルは機能しない。
ウォーターフォール開発とは何か
ウォーターフォール開発は、その名の通り水が上から下へ流れ落ちるように、決められた順番通りに工程を進める方式だ。要件定義、設計、開発、テスト、納品という工程を、前の工程が完全に終わってから次の工程に進む。滝が下流に戻らないのと同じで、後戻りを前提としない。
これは家を建てる工程に近い。まず何部屋の家にするか、どんな間取りにするかを図面ですべて決め、承認してから基礎工事に入る。基礎ができてから「やっぱりリビングをもう1畳広げたい」と言い出せば、大きな手戻りと追加費用が発生する。だからこそ、着工前の設計段階で徹底的に詰めることが求められる。
ウォーターフォールの強みは、最初にすべての要件と費用と納期が固まるため、経営者にとって予算と計画の見通しが立てやすい点にある。会計システムや法律に基づく届出処理のように、仕様が明確でルールが変わりにくい業務には特に相性が良い。逆に言えば、最初の要件定義でどれだけ現場の声を拾い切れるかが、プロジェクトの成否をほぼ決めてしまう進め方でもある。
発注者目線で見るメリットとデメリット
専門用語の説明だけでは、自社にとってどちらが得かは見えてこない。発注する側の目線で、それぞれの利点と負担を整理する。
アジャイル開発のメリット
- 作りながら方向修正できるため、要件を100パーセント固めきれていなくても始められる
- 早い段階で動くものに触れられるため、完成してから「思っていたのと違う」という致命的なズレが起きにくい
- 優先度の高い機能から先に使い始められるので、投資回収が早い場合がある
アジャイル開発のデメリット
- 総額と最終的な完成イメージが最初の時点では見えにくく、経営者としては不安を感じやすい
- 発注側が定期的に打ち合わせや画面確認に時間を割く必要があり、丸投げができない
- 担当者が「次はこう直したい」と言い続けられる状態でなければ、いつまでも完成しない恐れがある
ウォーターフォール開発のメリット
- 契約時点で総額と納期がほぼ確定するため、社内稟議や資金計画が立てやすい
- 発注後は開発会社に任せやすく、日常業務の合間でも進められる
- 仕様が固まっている業務領域では、無駄なやり直しが少なく効率的
ウォーターフォール開発のデメリット
- 要件定義の段階で見落としがあると、完成後にしか気づけないことが多い
- 途中で状況や制度が変わっても、契約範囲内での修正は難しく、追加費用が発生しやすい
- 現場が実際に触れるのは最後のテスト段階になるため、使い勝手の違和感に気づくのが遅れる
冒頭の専務のケースを思い出してほしい。要件定義に半年をかけたにもかかわらず、現場の声が反映されなかったのは、ウォーターフォールという進め方そのものが悪かったのではない。要件定義の段階で現場を巻き込みきれなかったこと、そして途中で仕様変更が起きる可能性を織り込まずに契約してしまったことが、遠因だった。
自社はどちらを選ぶべきか、3つの判断軸
比較表を眺めるだけでは決められない。実際に自社にあてはめるための判断軸を3つ挙げる。
判断軸1、要件がどれだけ固まっているか
「作りたいものの8割以上が、担当者の頭の中で明確に言語化できている」なら、ウォーターフォールに向いている。逆に「なんとなくこういう課題は感じているが、具体的にどんな画面や機能が必要かはこれから詰めていく段階」であれば、アジャイルの方が現実的だ。要件定義に3か月以上かかりそうな複雑な業務フローを扱う場合、最初から完璧に固めようとするより、動くものを見ながら固めていく方が結果的に早いことも多い。
判断軸2、開発の途中で仕様が変わる可能性
法改正への対応、補助金の申請要件、社内の人事制度など、外部要因によって仕様が変わりやすい業務を扱うなら、変更に強いアジャイルが向く。一方、経理の締め処理や在庫の計算ロジックのように、一度決めたら数年単位でほぼ変わらない業務であれば、ウォーターフォールで固めてしまう方が効率的だ。自社の業務が「変わりやすい部分」と「変わりにくい部分」のどちらに近いかを、発注前に棚卸ししておくとよい。
判断軸3、社内にどれだけ関与できる体制があるか
アジャイル開発は、発注企業側の継続的な関与が前提になっている。2週間に1度、1時間程度でも画面を確認しフィードバックを返せる担当者を確保できるか。これができない体制でアジャイルを選ぶと、開発会社に判断を丸投げすることになり、結局は行き当たりばったりの開発になってしまう。逆に、日常業務が忙しく担当者を専任で置けない企業は、要件定義さえしっかりやり切れば、あとは任せられるウォーターフォールの方が現実的なことが多い。
この3つの軸で自社を採点してみてほしい。要件が固まっていて、仕様変更の可能性が低く、専任の担当者を置く余裕がないなら、ウォーターフォールに分がある。要件が流動的で、途中で変わる可能性が高く、担当者が継続的に関与できるなら、アジャイルが力を発揮する。多くの中小企業では、基幹となる部分はウォーターフォール的に固め、現場の使い勝手に関わる部分だけアジャイル的に柔軟に進めるという、いいとこ取りの進め方を採用するケースも増えている。
よくある失敗パターン
手法の名前を知っているだけでは失敗を防げない。実際に中小企業の現場で起きがちな失敗を2つ紹介する。
失敗パターン1、名ばかりアジャイル
「アジャイルで進めましょう」と言われて契約したものの、実態は明確な計画も優先順位もないまま、思いつきで機能を足したり消したりするだけの行き当たりばったり開発だった、というケースは少なくない。ある小売業の担当者は、毎週の打ち合わせで「これも欲しい、あれも欲しい」と要望を出し続けた結果、1年経っても完成の見通しが立たず、開発費だけが積み上がっていった。アジャイルは自由に何でも追加できる進め方ではない。優先順位を都度きちんと見直し、今回のサイクルで本当に必要なものだけに絞り込む規律があって初めて機能する。発注側も「なんでも言えばやってもらえる」と誤解せず、優先順位づけに責任を持つ姿勢が求められる。
失敗パターン2、現場の声を置き去りにしたウォーターフォール
もう一つの典型は、経営層と情報システム部門だけで要件を決め、実際にシステムを毎日使う現場の声を反映せずに完成させてしまうパターンだ。ある建設会社では、経理と管理部門の意見だけで工程管理システムを作り上げたが、現場監督が現場で使うには操作が複雑すぎ、結局、紙の帳票と表計算ソフトでの管理が併存する二重運用に逆戻りした。数百万円をかけたシステムが、現場では「使われないシステム」になってしまった。ウォーターフォールを選ぶ場合こそ、要件定義の段階でどれだけ現場の声を拾えるかに全力を注ぐ必要がある。着工前の設計図に、実際に住む人の声が反映されていなければ、住みにくい家が建ってしまうのと同じだ。
まとめ
アジャイルとウォーターフォールは、優劣を競う技術ではない。登る山によって適したルートが違うように、自社が置かれた状況によって適した進め方が違うだけだ。要件がどれだけ固まっているか、途中で仕様が変わる可能性がどれくらいあるか、社内にどれだけ関与できる体制があるか。この3つの軸で自社を見つめ直せば、選ぶべき道はおのずと見えてくる。
そして、どちらの進め方を選んだとしても、システム開発というのは発注企業と開発会社が一緒に壁を越えていく共同作業だ。冒頭の専務のように、要件をきっちり固めても現場の声を拾い切れず苦労する担当者もいれば、走りながら試行錯誤を重ねて理想のシステムにたどり着く担当者もいる。どちらの道を歩む担当者にも共通しているのは、分からないなりに手法を学び、自社に合う形を模索し続けているという事実だ。開発手法という馴染みのない言葉と向き合い、自社の言葉に翻訳しようとする担当者の奮闘こそが、良いシステムを生み出す一番の原動力になる。まずは自社がどちらの山を登ろうとしているのか、その輪郭を見極めることから始めてほしい。