開発の進め方を決める前に押さえたい基本
システム開発を外部に依頼しようとしたとき、「ウォーターフォールとアジャイル、どちらにしますか」と聞かれて戸惑う方は少なくありません。専門用語が並ぶ資料を見ても、自社に合う進め方を判断するのは簡単ではないものです。
この記事では、計画を固めてから進める方法と、小さく作りながら見直す方法という2つの進め方について、技術的な違いよりも実務での選び方に重点を置いて解説します。開発会社に相談する前の整理材料として、参考にしてください。
2つの進め方は何が違うのか
大きな違いは、最初に全体を決めてから作るか、作りながら決めていくかにあります。
計画を固めて進める方法では、開発を始める前に要件（システムに必要な機能や条件）を整理し、その内容をもとに設計・開発・テストへと順に進めます。一方で、変化に合わせて進める方法では、まず小さな単位で機能を作り、実際に動かしながら見直しを重ねて完成形に近づけていきます。
どちらか一方が常に優れているわけではなく、プロジェクトの内容や社内体制によって適した選択は変わります。
中小企業が選ぶときに見落としやすい点
中小企業の担当者が開発会社から提案を受けるときは、「どちらの進め方か」だけでなく、「自社の体制で無理なく対応できるか」を確認することが重要です。
たとえば、変化に合わせて進める方法では、担当者が開発途中で何度も確認や判断に関わる必要があります。総務や他業務と兼務している場合、その対応が想像以上に負担になることがあります。反対に、計画を固めて進める方法でも、要件定義（最初に行う詳細な打ち合わせ）に時間と労力がかかるため、初期準備が不十分だと後からの修正が難しくなります。進め方を選ぶ前に、自社がどちらの負担を受け入れやすいかを見極めることが、失敗を防ぐ第一歩です。
計画を固めて進める方法の特徴
はじめに全体像を決めて進める流れ
計画を固めて進める方法では、プロジェクトの初期段階で「何を作るか」を細かく決め、その内容に沿って進行します。一般的な流れは、要件定義→設計→開発→テスト→リリースです。原則として、前の工程が完了してから次の工程へ進みます。
この方法の特徴は、開発範囲、費用、納期が初期の段階で見えやすいことです。契約時点で「何を、いつまでに、いくらで作るか」を整理しやすいため、予算管理や社内説明を進めやすいという利点があります。
向いているケース（計画固定型）
計画を固めて進める方法が向いているのは、開発の目的や必要な機能が最初から明確な場合です。たとえば、既存の紙台帳をそのままシステム化する、法令対応のために決まった帳票を出力できるようにする、といった仕様変更が起きにくい案件に適しています。金融機関や行政との連携が必要なシステムのように、後から仕様を変えにくい開発にも向いています。
気をつけたい点（計画固定型）
最も注意したいのは、途中で要件が変わると対応に時間と費用がかかりやすい点です。開発が進んだあとで「この機能は不要だった」「画面の使い勝手を変えたい」となっても、設計から見直しになることがあります。追加費用が発生することも珍しくないため、初期の要件定義をどれだけ丁寧に行えるかが、プロジェクト全体の成否を左右します。
変化に合わせて進める方法の特徴
小さく作って見直しながら進める流れ
変化に合わせて進める方法では、最初から完成形を決め切るのではなく、短い期間ごとに小さな機能を作り、確認しながら次に進む流れを繰り返します。一般的には1〜4週間程度の単位で進めることが多く、試作、確認、改善を重ねながら全体を作っていくイメージです。
この方法では、リリース前の段階でも実際の操作感を確認しやすいため、「使ってみたら想定と違った」というずれを早い段階で修正できる点が強みです。
向いているケース（柔軟対応型）
変化に合わせて進める方法が向いているのは、要件が最初から固まっていない場合や、事業の変化に応じて機能を追加・修正していきたい場合です。たとえば、新サービスを試験的に立ち上げるためのシステム、社内業務フローがまだ定まっていない段階の管理ツール、利用状況を見ながら改善を続けるWebアプリケーションなどが当てはまります。
気をつけたい点（柔軟対応型）
この方法では、開発開始後も担当者が継続的に確認や判断に関わる必要があります。開発会社から「次に何を優先するか」「この仕様で問題ないか」といった相談が頻繁に来ることもあり、兼務の担当者には負担になる場合があります。また、最終的な費用や完成時期が初期段階では確定しにくいため、予算管理が難しくなる側面もあります。
中小企業が比較したい3つの判断軸
社内の体制に合うのはどちらか
まず確認したいのは、担当者がどの程度の頻度でプロジェクトに関われるかという点です。変化に合わせて進める方法では、週に1〜2回ほど確認や判断を求められることがあります。一方、計画を固めて進める方法では、初期の要件定義に集中的に時間を使えば、開発中の関与は比較的少なく済むことがあります。兼務が前提であれば、体制に合った進め方を選ぶことが現実的です。
予算の立てやすさに違いはあるか
計画を固めて進める方法は、開発開始前に総費用の見積もりを出しやすいため、稟議（上司や経営層への予算承認申請）を進めやすいというメリットがあります。一方で、変化に合わせて進める方法は、開発期間や追加対応に応じて費用が変動しやすく、予算の見通しを立てにくい場合があります。そのため、予算上限を決めた契約形態について、事前に開発会社と相談しておくことが重要です。
中小企業の開発予算の目安としては、小規模なシステムで300〜800万円程度、中規模になると1,000万円を超えることもあります。いずれの進め方であっても、あらかじめ予算の上限を明確にしたうえで相談することをおすすめします。
進行中の手戻りや失敗の起こりやすさ
計画を固めて進める方法では、要件定義が不十分だった場合、後半で大きな手戻りが起こるリスクがあります。対して、変化に合わせて進める方法は、早い段階で問題に気づいて修正しやすい反面、方向性が定まらないまま進むと長期化しやすくなります。どちらの方法でも、最初に何を決めておくかが重要であり、その準備の質が結果に直結します。
要件がまだ固まっていないときの進め方
まずは小さく試して方向性を確かめる
「作りたいものの方向性はあるが、細かい仕様はまだ決まっていない」という状況は珍しくありません。そのような場合は、まず画面イメージや試作品を作って確認するところから始めるのが有効です。簡単な試作品であれば、30〜100万円程度で対応する開発会社もあります。本格的な開発に入る前に方向性を確認しておくことで、大きな手戻りを防ぎやすくなります。
段階的に導入して負担を抑える
最初からすべての機能を開発するのではなく、まず最低限必要な機能だけを作って公開し、その後に機能を追加していく方法も有効です。初回の範囲を絞ることで、初期費用と開発期間を抑えやすくなります。機能を絞った初期リリースであれば、構築期間は2〜4か月程度を見込むのが現実的です。
開発会社と決めておきたい確認事項
要件が固まりきっていない段階で開発会社と話すときは、途中の認識違いを防ぐためにも、最低限の確認事項を事前にそろえておくことが重要です。特に、仕様変更が発生した場合の費用や手続き、開発期間中に担当者へ求められる確認の頻度と方法、要件定義の整理をどこまで支援してもらえるかは、早い段階で確認しておきたいポイントです。
どちらか一方に決めない進め方もある
最初に全体計画を立てて一部を柔軟に進める
実際のプロジェクトでは、計画を固めて進める方法と、変化に合わせて進める方法を組み合わせることもあります。たとえば、全体方針や予算の目安は最初に整理しつつ、画面の使い勝手や細かな機能仕様は開発しながら調整していく進め方です。中小企業では、経営層には予算説明が必要でありながら、現場の意見も反映したい場面が多いため、この組み合わせは現実的な選択肢になりやすいといえます。
基幹業務と周辺機能で進め方を分ける
社内の基幹業務、たとえば受注管理や在庫管理のように止まると影響が大きい領域は、計画を固めて慎重に進めるのが適しています。一方で、レポート出力や通知機能のような周辺機能は、作りながら改善する進め方のほうが適していることがあります。リスクの高い部分は慎重に、改善余地の大きい部分は柔軟に進めることで、全体のバランスを取りやすくなります。
中小企業で取り入れやすい組み合わせ方
たとえば、最初の3か月で要件定義と基本設計をしっかり固め、その後の実装フェーズの一部を2週間単位で確認しながら進める方法は、中小企業でも取り入れやすい進め方です。開発会社によっては、このような方式を別の名称で提案することもあるため、相談時に「全体は計画的に、細部は柔軟に進められるか」という観点で確認してみるとよいでしょう。
自社に合う進め方を見極めるチェックポイント
開発会社に相談する前に、自社の状況をいくつかの観点で整理しておくと、提案内容を比較しやすくなります。
目的と優先順位が明確になっているか
何のためにシステムを作るのか、最優先で解決したい課題は何かが言葉になっていると、要件定義は進めやすくなります。まずはこの点を社内で整理しておくことが大切です。
社内で判断や確認に関わる人を決められるか
開発が始まると、仕様確認や変更承認が必要になる場面が出てきます。担当者だけでなく、最終的に判断する人が誰かを決めておくと、意思決定が滞りにくくなります。
納期と予算のどちらを優先するか
「何月までに必ずリリースしたい」のか、「費用をできるだけ抑えたい」のかによって、選ぶべき進め方は変わります。両方を最優先にするのは現実的に難しいため、どちらをより重視するかを事前に決めておきましょう。
将来の変更や機能追加をどこまで見込むか
リリース後に機能追加を予定しているか、それとも当面は現状維持でよいかによって、最初の設計方針は変わります。将来の拡張を見据えた設計は初期費用が上がる一方で、後から追加しやすくなるという利点があります。
開発会社に相談する前に整理しておきたいこと
自社の課題と実現したいことを言葉にする
「何となく業務が非効率だから」という状態で相談するよりも、「月次集計に毎月20時間かかっている」「入力ミスが月に5件以上発生している」といった形で具体的に整理しておくほうが、開発会社からの提案は的確になりやすくなります。完璧にまとめる必要はありませんが、A4用紙1〜2枚程度に課題と実現したいことを整理しておくと、相談が進めやすくなります。
比較の際に確認したい質問項目
複数の開発会社を比較する場合は、提案する進め方とその理由、中小企業向けの開発実績、要件変更時の対応方針、担当者に求められる確認頻度、開発完了後の保守・サポート体制などを確認しておくと判断しやすくなります。単に費用だけで比較するのではなく、進め方や支援体制まで含めて見比べることが重要です。
選定で迷ったときの考え方
複数社から提案を受けて迷った場合は、技術力の高さだけでなく、自社の状況を理解したうえで一緒に整理してくれるかを重視することをおすすめします。中小企業のシステム開発では、担当者が技術に詳しくなくても進められる体制があるかどうかが、成功に大きく影響します。初回の打ち合わせで、難しい内容をわかりやすく説明してくれるか、質問に丁寧に答えてくれるかも大切な判断材料です。
よくある質問
Q1. 要件がまだはっきりしていないのに、相談してもいいですか？
問題ありません。要件が固まり切っていない段階での相談を歓迎する開発会社は多くあります。要件整理から支援してくれる会社であれば、困りごとや実現したいことの大枠があるだけでも相談を始められます。
Q2. 小規模な会社でも柔軟対応型は使えますか？
利用できます。ただし、担当者の関与頻度が高くなりやすいため、週に一度程度の打ち合わせや確認に対応できる体制を整えられるかを事前に確認しておくことが重要です。
Q3. 計画固定型で進めたのに途中で要件が変わった場合、どうなりますか？
多くの場合、変更内容の大きさに応じて追加費用や納期延長が発生します。軽微な修正であれば対応可能なこともありますが、変更時の扱いは契約内容によって異なるため、契約前に確認しておく必要があります。
Q4. 開発会社が「アジャイルで進めましょう」と言ってきたら、どう判断すればいいですか？
まずは、その進め方を提案する理由を確認してください。そのうえで、自社に必要な関与頻度、費用の見通し、意思決定の進め方を具体的に聞き、自社の体制で対応できるかを見極めることが大切です。
Q5. システム開発の経験がなくても、スムーズに進められますか？
可能です。初めての発注を前提に支援している開発会社も多くあります。社内に詳しい人がいないことや、開発経験がないことは最初に率直に伝えたほうが、実情に合った進め方を提案してもらいやすくなります。
まとめと行動喚起
計画を固めて進める方法と、変化に合わせて進める方法には、それぞれ適した場面があります。重要なのは、どちらが優れているかではなく、自社の体制、予算、要件の固まり具合に合っているかを見極めることです。
開発会社から提案を受けたときに、「なぜこの進め方なのか」を自社として判断できる状態にしておくことが、納得のいく発注につながります。この記事で紹介した判断軸や確認ポイントを、事前整理に役立てていただければ幸いです。
システム開発の進め方について、自社ではどの方法が適しているのか、何から相談すればよいのかわからない場合は、まず現状の課題整理からご相談ください。要件が固まっていない段階でも、状況に応じた進め方の整理をご支援します。お問い合わせフォームからお気軽にご連絡ください。
