なぜベンダーは「アジャイル」を勧めるのか？現場視点で本音解説
- Yukaringo
- 2025年12月1日
- 読了時間: 8分
更新日：2025年12月4日
なぜベンダーは「アジャイル」を勧めるのか？現場視点で本音解説
※本記事は、アビココ株式会社が提供するサービスに関連する内容を含みますが、読者の皆さまに有益な情報をお届けすることを目的として執筆しています。
ベンダーから「アジャイルで」と提案されたけど...
開発ベンダーとの打ち合わせで「今回はアジャイル開発がおすすめです」って言われたこと、ありませんか？正直、「ウォーターフォールと何が違うの？本当にうちに合ってるの？」って思いますよね。
情シスとして上司や事業部門に説明しなきゃいけないのに、ふわっとした理解だと困る。この記事では、実務で使える知識を現場目線でお伝えします。
2つの開発手法の違い：実務視点で整理
項目 | ウォーターフォール | アジャイル |
契約 | 一括請負 | 準委任 |
コミュニケーション頻度 | 低 | 高 |
予算の確定 | 前半 | 後半 |
柔軟性 | 低 | 高 |
ウォーターフォール開発の実態
要件定義→設計→開発→テスト→リリースと、工程を順番に進めていく手法です。
実務での特徴:
契約は一括請負が多い（総額○○万円で全部やります）
成果物ベースで進捗管理（設計書、テスト仕様書など）
要件定義書が分厚くなりがち
変更管理が厳格（変更はCR票で管理、追加費用発生）
ベンダーとの定例MTGは月1〜2回程度
要は、最初にガッチリ決めて、その通りに作ってもらうスタイルです。
アジャイル開発の実態
1〜4週間の短期サイクル（スプリント）で、動くソフトウェアを少しずつ作っていく手法です。
実務での特徴:
契約は準委任契約が多い（月○○万円×人月）
動くソフトで進捗確認（ドキュメントより実物）
仕様は必要最小限から始めて、育てていく
変更は比較的柔軟（スコープ調整で対応）
ベンダーとの打ち合わせは週1〜2回、密なコミュニケーション
要は、大枠だけ決めて、作りながら詰めていくスタイルですね。
なお、IPAのモデル契約書によれば、アジャイル開発では成果物の完成に対価を払う請負契約ではなく、ベンダーが専門家として業務を遂行すること自体に対価を払う準委任契約が前提とされています。
情シス目線で見た、実際の違い
プロジェクト管理の負荷
ウォーターフォール: 最初の要件定義が勝負。ここで詰めが甘いと後で地獄を見ます。ユーザー部門から「全部」要件を引き出すのが大変。でも、開発が始まったら基本的に待つだけ。進捗会議の準備はラク。
アジャイル: 最初はサクッと始められる。でも、継続的に関わる必要あり。スプリントレビューは毎回参加必須。ユーザー部門との調整も継続的に発生。プロジェクト管理の総工数は、実は結構かかります。
予算管理の違い
ウォーターフォール: 予算は最初に確定。「総額3,000万円」って決まるので、予算説明しやすい。ただし、要件追加は別途予算が必要。「想定外の追加費用」でもめることも。
アジャイル: 「月200万円×12ヶ月」みたいな見積もりになりがち。トータルいくらかかるか不透明で、予算承認取りづらい。ただし、途中で「もうここまででいいか」と判断して打ち切れる柔軟性はある。
ユーザー部門との関係
ウォーターフォール: 要件定義時にガッツリ巻き込む必要あり。「後で変更できないので今決めてください」というプレッシャー。開発中はあまり呼ばれない。納品時に「イメージと違う」と言われるリスク。
アジャイル: 継続的に巻き込む必要あり。「毎週1時間もらえますか？」って依頼すると嫌な顔されることも。でも、都度確認できるので「イメージと違う」は起きにくい。ユーザー部門が協力的なら最高、そうじゃないと辛い。
どっちを選ぶべき？判断基準
ウォーターフォールを選ぶべきケース
システムの性質:
基幹システムのリプレイス（会計、人事給与など）
他システムとの連携が複雑
法改正対応など、要件が外部要因で固定されている
セキュリティ要件が厳しい
組織の状況:
ユーザー部門が多忙で、開発期間中に頻繁に時間を取れない
稟議文化が強く、最初に全部決めないと予算が通らない
情シスのリソースが限られていて、密な進行管理ができない
要は、「変わりようがない」「変えたくない」ケースですね。
アジャイルを選ぶべきケース
システムの性質:
新規事業向けのシステム
UI/UXが重要なユーザー向けアプリ
市場の変化に合わせて機能追加していきたい
まだ要件が固まりきっていない
組織の状況:
ユーザー部門が積極的で、開発に時間を割ける
経営層が「まず作ってみて、改善していく」スタイルに理解がある
情シスに開発プロセスに関わる余裕がある
要は、「やってみないとわからない」「柔軟に変えたい」ケースです。
実務で起きる「困ったこと」と対処法
ウォーターフォールあるある
困ったこと1：要件定義が終わらない ユーザー部門が「まだ決められない」と言い続けて、要件定義が3ヶ月→6ヶ月→...
対処法： 締め切りを明確に。「○月○日までに決まらなかった要件は次フェーズ」とルール化しましょう。
困ったこと2：納品時に「思ってたのと違う」 完成したシステムを見たユーザー部門が「こんなはずじゃなかった」
対処法： 開発途中でもモックアップやプロトタイプを見せる機会を設ける。契約上は変更できなくても、確認のタイミングは作れます。
アジャイルあるある
困ったこと1：スコープクリープ 「ついでにこれも」が積み重なって、終わりが見えない。
対処法： プロダクトバックログ（やりたいことリスト）をちゃんと管理。優先順位を明確にして、「今やること」と「後回し」を区別。
困ったこと2：ユーザー部門が疲弊 毎週のレビューに疲れて「もういいです、任せます」モードに。
対処法： スプリントの長さを調整（2週間→4週間に変更など）。全機能のレビューじゃなく、重要機能に絞る。
困ったこと3：予算説明ができない 「結局いくらかかるんですか？」と上司や経理に詰められる。
対処法： MVP（最小限の機能）の範囲と予算を決めておく。「まずここまでで○○万円。その後は効果を見て判断」というストーリーで説明。
ハイブリッド型という現実解
正直、現場では「完全なウォーターフォール」も「完全なアジャイル」も少ないです。多くはいいとこどりのハイブリッド。
よくあるパターン:
パターン1：要件定義はウォーターフォール、開発はアジャイル
大枠の要件と予算は最初に確定
詳細仕様は開発しながら詰める
契約は「要件定義：一括請負」「開発：準委任」の組み合わせ
パターン2：基盤部分はウォーターフォール、機能部分はアジャイル
インフラ、認証、データベース設計などは最初にガッチリ
画面や業務ロジックはアジャイルで柔軟に
システムの安定性と柔軟性の両立
パターン3：大規模PJをフェーズ分割
フェーズ1：MVP（最小限の機能）をアジャイルで作る
フェーズ2：追加機能をウォーターフォールで計画的に
状況に応じて手法を使い分け
教科書通りじゃなくて、プロジェクトの制約条件に合わせてカスタマイズするのが賢いやり方です。
ベンダー選定で見るべきポイント
ウォーターフォールで選ぶなら
要件定義の実績と手法（どうやって要件を引き出すか）
変更管理プロセスの明確さ
ドキュメントのサンプル（設計書の質）
大規模PJの実績
アジャイルで選ぶなら
チームの継続性（メンバーがコロコロ変わらないか）
コミュニケーションスタイル（週次MTGに誰が出るか）
過去のスプリント実績（ベロシティの安定性）
技術的負債への考え方
どちらにせよ、「うちはアジャイルです」「ウォーターフォールです」と決めつけず、プロジェクトに合わせて柔軟に対応できるベンダーが理想です。
まとめ：情シスとしてどう判断するか
結局のところ、「どっちがいい」じゃなくて「うちのプロジェクトに何が合ってるか」です。IPAの資料でも、高信頼性が求められる基幹システムなどではウォーターフォール開発に実績があり、一方で市場へ早く提供することに価値がある分野ではアジャイル開発が向いていると整理されています。
判断のチェックリスト:
□ 要件は固まっている？（Yes→ウォーターフォール寄り）
□ ユーザー部門は協力的？（Yes→アジャイル寄り）
□ 情シスに余裕ある？（No→ウォーターフォール寄り）
□ 予算は柔軟に確保できる？（Yes→アジャイル寄り）
□ 失敗のリスクは高い？（Yes→ウォーターフォール寄り）
□ 市場の変化に対応したい？（Yes→アジャイル寄り）
これらを総合的に判断して、場合によってはハイブリッドで。
開発手法の選択で悩んだら、相談してみませんか？
ここまで読んでくださって、ありがとうございます。でも正直、「理屈はわかったけど、うちの場合はどうすれば...」って思いますよね。
そんな時は、アビココに相談してみてください。
アビココは、情報システム部門の立場や制約を理解した上で、最適な開発手法とプロジェクト体制を提案してくれます。
「予算承認の都合でウォーターフォールにしたいけど、柔軟性も欲しい」
「ユーザー部門を巻き込む体制作りから相談したい」
「ハイブリッド型でやりたいけど、契約形態はどうすれば？」
こういった、教科書には載っていない実務の悩みにも対応できます。
記事を読んで迷った方は気軽にご相談ください。
開発手法の選択は、プロジェクトの成否を左右する重要な判断です。一人で抱え込まず、経験豊富なパートナーと一緒に、最適な答えを見つけましょう。
参考資料
本記事は以下の公的機関の資料を参考にしています：
「結局どの順番で何を決めて進めればいいの？」と感じた方は、流れを体系立てて理解できるこちらの解説がおすすめです👇
コメント