ウォーターフォールは変化に対応できないと聞いて、アジャイルに変えた。スプリントを回し、こまめに確認しながら進めた。それでも完成したものは「思っていたものと違った」。
手法の問題だったのか、開発会社の問題だったのか——そう考えながら次のプロジェクトでは別の会社を選んだ。今度はAI駆動開発で効率化すると言われた。うなずいたものの、また同じ結末になった。
この繰り返しには、理由があります。問題は手法ではありません。手法がどう変わっても、解決されていない構造的な問題が、発注者と開発会社の間に存在しているのです。
ウォーターフォール・アジャイル・AI駆動開発と手法を変えても失敗が繰り返される本当の理由、発注者が持つべきたったひとつの判断基準、そして「課題が解決されているか」を常に確認できる状態をどう作るかがわかります。
ウォーターフォール、アジャイル、AI駆動開発——これらは全て、開発会社が「どう作るか」を改善するために生み出したフレームワークです。発注者の「思っていたものと違う」を解決するために生まれたわけではありません。
開発会社が提案書や打ち合わせで使う言葉を並べてみると、ほぼ全てが開発会社側の言語です。
これらは全く別の言語です。開発会社は自分たちの言語で丁寧に説明しているつもりでも、発注者には届いていない。説明が詳しければ詳しいほど、発注者は置いていかれる感覚になります。
これは発注者の理解力の問題ではありません。そもそも伝えるべき言語が違うのです。
「ウォーターフォールは変化に対応できない」と言われてアジャイルに変えた。「アジャイルは発注者がついていけない」と言われてAI駆動開発に変えた。手法が変わるたびに「今度こそ」と期待したが、「思っていたものと違う」という結末だけは変わらなかった。
手法の進化は、開発会社側の問題を解決してきた歴史です。ウォーターフォールの硬直性、アジャイルの属人性、それぞれの弱点を補う形で次の手法が生まれてきました。しかし、それらはあくまで「どう作るか」の改善であり、発注者が抱える「何が解決されるのか」という問いへの答えではありません。
だから手法が変わっても、発注者が直面する問題は変わらないのです。
「AIを使えば何でも速く安くなる」は誤解です。課題が不明確なままAIを導入すると、単に「精度の低い、使い勝手の悪い機能」が高速で量産されるだけです。開発スピードが上がることは、同時に「ズレたまま進む速度」も上がることを意味します。
開発手法を理解する必要はありません。技術スタックを把握する必要もありません。発注者として持つべき判断基準はひとつです。
逆に言えば、この問いに答えてくれない開発会社、あるいはこの問いに答える前に技術の話を始める開発会社は、発注者の言語で話せていないということです。
「この機能はどう動きますか？」ではなく「この機能はどの課題を解決しますか？」。「スプリントは2週間です」ではなく「2週間後にどの課題がどの程度解決されていますか？」。発注者はこの問いを持ち続けるだけでいいのです。
「この提案によって、私たちのどの課題がどう解決されますか？」——この一文を商談の場で聞いてみてください。明確に答えられる開発会社かどうかが、最初の見極めポイントになります。
発注者が常に「課題が解決されているか」を確認できるようにするには、課題と機能が常に紐づいて見える状態が必要です。
多くの開発現場では「機能一覧」が管理されています。しかしその機能が「何のためにあるか」が明示されていないと、発注者は機能の良し悪しを判断できません。技術的に正しく動いていても、課題が解決されているかどうかが見えないのです。
課題と機能が紐づくと、こういう構造になります。
この構造があると、発注者は常に「課題Aはどこまで解決されていますか？」という自分の言語で確認できます。機能の詳細を理解していなくても、判断できるのです。
また、優先順位の議論も変わります。「機能1と機能2、どちらを先に作りますか？」ではなく「課題Aと課題B、どちらを先に解決しますか？」という問いになる。これは発注者が答えられる問いです。
優先順位は「機能ベース」ではなく「課題ベース」で決める。機能の優先順位は、課題の優先順位が決まった結果として導かれるものです。
STVテックでは、開発に入る前に必ず「課題一覧」を発注者と一緒に作ります。課題一覧とは、「何が問題か」を発注者の言葉で書き出したものです。技術的な言語は使いません。
たとえば、こんな違いです。
右側の言葉なら、誰が困っていて、何が解決されれば良いかが具体的にわかります。この粒度で課題を書き出すことが、「何のための開発か」を揃える出発点です。
「誰が・どこで・何に困っているか」を発注者の言葉で書き出します。「AIで効率化したい」という言葉の裏にある本当の課題を、一緒に言語化するプロセスです。ここが曖昧なまま進めないことが、最初の約束です。
課題が出揃ったら、どの課題を先に解決するかを発注者と決めます。この段階では機能の話はしません。「今の事業にとって最も痛い課題はどれか」という問いに、発注者が答えます。
要件定義の各項目が、どの課題を解決するために存在するかを明示します。「この機能はなぜあるのか」が常に追跡できる状態を作ります。課題に紐づかない機能は、原則として作りません。
定例報告では「機能Aの実装が完了しました」ではなく「課題Aに対してここまで対応できました」という形で報告します。発注者が自分の言語で進捗を確認できる状態を維持します。
この進め方は、開発会社にとって楽ではありません。課題の言語化には時間がかかり、「作らない選択」を提案することもあります。しかし、現場で使われないシステムを作ることが最も非効率だと考えています。
ウォーターフォール、アジャイル、AI駆動開発——手法を変えても「思っていたものと違う」が繰り返されるのは、手法の問題ではありません。「何のための開発か」が発注者と開発会社の間で揃っていないまま、開発だけが進んでいることが原因です。
| 開発会社の言語 | 発注者の言語 |
|---|---|
| ウォーターフォール／アジャイル | あの課題、解決できますか？ |
| 機能一覧・技術スタック | 何のための機能ですか？ |
| 機能の優先順位 | どの課題を先に解決しますか？ |
| 機能Aの実装が完了しました | 課題Aはどこまで解決されましたか？ |
発注者が理解すべきは手法や技術ではありません。「自分たちの課題が、これによって解決されるか」を常に確認できる状態になっているかどうか——これだけが、発注者として持つべき唯一の判断基準です。
その状態を作るために、課題一覧と要件定義を紐づけ、優先順位を課題ベースで決め、進捗を課題の解決度で報告する。開発会社に求めるべきはこの構造です。
技術より、コミュニケーション。
STVテックが発注側に立つ理由
開発失敗の根本原因から、発注者として取るべき姿勢まで。このテーマをさらに深く解説した15分のガイドです。
ガイドを読む →