「システム開発を検討してほしい」と経営層から指示を受けて2〜4週間。社内で議論を重ねても要件が固まらず、開発会社の「お問い合わせ」フォームの前で手が止まってしまう。そんな経験はありませんか。
多くの発注検討者が「仕様書を書き上げてから連絡するべき」「ふんわりした状態で問い合わせたら失礼にあたるのでは」と考え、相談を先送りにしてしまいます。しかし社内検討だけでは開発知見が不足しているため要件は永遠に固まりません。先送りすればするほどプロジェクトの始動も遅れます。
実は、開発会社の多くは「構想段階」「アイデア段階」からの相談を歓迎しています。要件定義は開発会社と一緒に進めるのが一般的であり、最初から完成された仕様書を期待しているわけではありません。
本記事では、仕様が決まっていない段階でも安心して開発会社に相談するために、必要な「最低限の準備項目」と「相談していい状態の判定基準」を解説します。読み終えた後には、今の準備度合いで自信を持って問い合わせフォームを送信できる状態になっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
「仕様が決まってから相談」は誤解です
「システム開発の相談は仕様が決まってから」というイメージは、多くの場合、発注者側の誤解です。実態を整理します。
なぜ「仕様が決まってから相談」と思い込んでしまうのか
ひとつは、建設業界などのウォーターフォール型プロジェクトのイメージとの混同です。建物は「設計図完成後に施工」が一般的ですが、ソフトウェア開発は「作りながら仕様を詰める」ことが許容され、最初から完全な設計図は求められません。
もうひとつは「見積もり依頼＝仕様確定済み」という思い込みです。構想段階の相談は「概算見積もり」「ヒアリングからの提案」が目的であり、確定見積もりを最初から求められるわけではありません。「お問い合わせ」と「正式発注」の間には複数のステップがあるため、構想段階での相談は失礼にあたりません。
実際は構想段階からの相談を歓迎する開発会社が多い
現代のシステム開発では「要件定義そのものを開発会社と一緒に進める」ケースが多くを占めます。アジャイル開発が広がった現在、最初から完成された要件よりも、対話を通じて一緒に作る方が品質の高いシステムが生まれるという認識が広がっています。
特に近年は「準委任契約」での要件定義フェーズを切り出して提供する開発会社が増えており、「まだ何も決まっていないが、何ができるか一緒に考えてほしい」というオーダーにも対応できる体制が整っています。
相談を先送りするデメリット
「もう少し詰めてから連絡しよう」という判断は一見慎重ですが、次のデメリットを生みます。
- 社内検討の堂々巡り: 開発知見のないメンバーだけで議論しても、技術的な実現可能性や工数感覚が分からないため決着しません
- 競合への先行を許す: 業務効率化や新規事業のためのシステム化であれば、開発着手の遅れがそのまま事業競争力の差につながります
- 予算策定の機会損失: 期初予算の確保には早期の概算見積もりが必要で、相談が遅れると次年度送りになります
つまり、相談を先送りすること自体が、プロジェクトを停滞させる主因になりかねません。
開発会社に相談する前に決めておくべき最低限の5項目
とはいえ無準備で連絡するのも非効率です。最低限整理しておきたい5項目をご紹介します。各項目とも「ざっくりとした方向性」レベルで構いません。
1. 解決したい課題・実現したいこと（WhatではなくWhyから）
最も重要なのは「なぜシステム化が必要なのか」という背景です。「何を作りたいか（What）」ではなく「何を解決したいか（Why）」から整理してください。
例えば「在庫管理システムを作りたい」よりも、「Excel在庫管理で複数拠点同時更新時にデータが壊れ、原因特定と再発防止に毎月20時間かかる」の方がはるかに有益です。Whyが共有できれば「実はSaaS導入だけで解決します」といった代替案を含む提案が可能になります。
2. 関係者・利用者（誰のためのシステムか）
「誰が使うシステムか」を次の観点で整理してください。
- 日常的に操作するユーザー（社内スタッフ・顧客・取引先など）
- 想定される同時利用人数の規模感（10人未満 / 100人規模 / 1,000人以上）
- 関わるステークホルダー（経理部門・営業部門・外部委託先など）
詳細なペルソナ設定は不要で、「業務歴2〜3年の中堅スタッフが使う」程度の解像度で十分です。
3. 予算の「レンジ」（金額そのものではなく許容幅）
予算は確定金額ではなくレンジ（許容幅）で十分です。「100万円〜500万円」「500万円〜1,000万円」のような幅で構いません。
レンジが共有されていないと、開発会社は「フルスペックか最低限構成か」を判断できず的外れな見積もりになります。「上限は〇〇万円までで」と伝えるだけで、その範囲で最大価値を出す提案が返ってきやすくなります。予算が未定の場合は「予算策定の参考にしたい」と素直に伝えれば問題ありません。
4. いつ頃使い始めたいかの「希望」（確定スケジュールでなくてOK）
リリース時期も「希望」レベルで構いません。「半年後にβ版」「来年度の繁忙期前には本番運用」といった粒度で十分です。
希望時期が共有されると「半年で間に合わせるなら機能Aは第二期に」といった現実的なロードマップを一緒に描けます。
5. 社内の意思決定者と進め方（誰が承認権を持つか）
「誰が最終承認するか」「相談者は承認権を持つのか、上司の判断を仰ぐ立場か」も初期相談で共有しておくとやり取りがスムーズです。意思決定構造が見えれば「役員向け提案書も用意しましょうか」「次回は意思決定者の同席を」といった提案が可能になります。
逆に決めなくてよいこと
次のような項目は「開発会社と一緒に決めるもの」であり、事前に準備する必要はありません。
- 具体的な機能仕様: 画面表示やボタン配置などの詳細
- 画面イメージ・デザイン案: ワイヤーフレームは相談後で十分
- 技術選定: 「ReactとVueどちらか」「クラウドはAWSか」は開発会社の専門領域
- 詳細な納期スケジュール: マスタースケジュールは要件定義フェーズで一緒に作成
- 正式な仕様書: 仕様書は要件定義の成果物として段階的に作るもの
仕様書の書き方を後の段階で詳しく知りたい方は仕様書 サンプル｜開発会社に伝わる書き方とテンプレ活用ガイドも参考にしてみてください。相談前に完成させる必要はありません。
相談段階でOKな状態・NGな状態
「自分の今の状態で相談していいのか」の判断軸として、OK/NGの典型例を整理します。多くの方が想像しているよりも、OKのハードルは低いものです。
相談OKな状態
以下のような状態であれば、いずれも相談OKです。
状態 | 補足 |
|---|---|
業務効率化したい領域は分かっているが、具体策は未検討 | Whyが言語化できていれば十分 |
アイデアレベルで、社内合意もまだ取れていない | 「役員提案の材料集めとして相談したい」と伝えればOK |
既存SaaSはあるが自社業務に合わない | 既存サービスとのギャップ自体が立派な相談材料 |
経営層から「DXを進めよ」と指示されたが、何から手を付けるべきか分からない | 「壁打ち相手として」と明示すれば歓迎されます |
過去の見積額が高すぎて判断に迷っている | セカンドオピニオン目的でも問題ありません |
内製を試みたがリソース不足で外部委託を検討し始めた | 自社の制約を率直に伝えればOK |
「やりたいことリスト」はあるが優先順位が決まっていない | 一緒に優先順位を整理するところから始められます |
共通するのは「検討意欲は明確だが具体策が固まっていない」状態です。検討意欲さえあれば相談OKと考えてください。
相談NGな状態
一方、次のような状態では相談しても双方にメリットが少ない可能性があります。
状態 | 理由 |
|---|---|
課題そのものが曖昧で、相談の目的が定まっていない | 「何を聞きたいか」が見えず対話が成立しません |
予算ゼロ・採用予定もなく純粋な情報収集目的のみ | 受注見込みが立たないため対応優先度が下がります |
競合の発注先を探る業界スパイ的な調査 | 倫理的に問題があり誠実な対話になりません |
別の開発会社と契約済みで相見積もりの当て馬として使う | 相見積もり自体は問題ないが意図を隠すのは関係性を損ねます |
NG例に共通するのは「誠実な検討・発注意思がない」状態です。逆に、誠実な検討意欲がある限り、ほとんどのケースはOKに該当します。「課題は明確で、いずれ発注したい意思はある。ただし時期や予算は未確定」というレベルであれば、迷わず相談に進んで問題ありません。
構想段階から相談するメリット
構想段階から相談することには、積極的なメリットがあります。費用・品質・期間の3観点から整理します。
費用面のメリット
第一に、要件定義段階の手戻りを防げる点です。社内で要件を固めた後に依頼すると「技術的に困難」「想定の3倍の工数」といった指摘で大幅な手戻りが発生しますが、早期対話で未然に防げます。
第二に、代替案による大幅なコスト削減が見込めます。フルスクラッチと思い込んでいた案件が「既存SaaSのカスタマイズ＋連携APIで済む」と判明し、当初予算の3分の1で実現できるケースは珍しくありません。
第三に、段階的な見積もりが可能になります。構想段階で「概算」、要件定義後に「詳細」と段階的にコストを把握でき、社内の予算策定・稟議に余裕を持って対応できます。
要件定義そのものの進め方を深掘りしたい方はAI開発の要件定義｜失敗しないための進め方と書き方ガイドも参考になります。AI開発を例にした記事ですが、要件定義の本質は通常のシステム開発にも応用できます。
品質面のメリット
開発会社は多くのプロジェクトで業界別の知見・成功/失敗パターンを蓄積しています。早期対話で、自社業界の類似事例や避けるべき落とし穴を踏まえた要件定義ができます。「同業他社ではこの機能が好評」「この機能は使われず保守コストだけかかった」といった生きた情報を要件に反映できます。
また、実装難易度を踏まえた要件設計も可能です。「この機能はライブラリで簡単に実装できるので追加要件として組み込めます」といった、実装側の視点を最初から取り入れた要件が組み立てられます。
期間面のメリット
開発会社と並走しながら要件定義を進めれば、社内検討と要件詰めを並列で進められます。「議論 → 結論を持って相談 → 持ち帰り検討」というシリアルなフローではなく、「相談しながら社内整理を進める」並行フローによって、プロジェクトの始動が数週間〜数ヶ月単位で前倒しできます。
加えて、優良な開発会社ほどリソースが埋まりやすく「相談してから3ヶ月待ち」も珍しくありません。早期相談で希望時期に合わせたリソース確保の調整がしやすくなります。
初回相談で聞かれる典型的な質問
「何を話せばいいのか分からない」という不安を解消するため、初回相談でよく聞かれる質問をご紹介します。すべてに答えられなくても問題ありません。「分からない」「これから決める」と答えるだけでも、開発会社は次のステップを提案してくれます。
質問 | 答えられるとなお良い度合い |
|---|---|
どんな業務をシステム化したいですか？ | ◎（Whyを言語化しておくと話が早い） |
現在その業務はどう運用していますか？ | ◎（現状の運用フローを大まかに説明できると◎） |
そのシステム化で何を達成できれば成功と言えますか？ | ○（数値目標がなくても定性的な状態でOK） |
いつ頃から使いたい希望はありますか？ | ○（「半年後」「来年度」程度でOK） |
予算感のイメージはありますか？ | △（レンジで答えればOK・未定でも可） |
想定される利用者は誰で、何人くらいですか？ | ○（おおよその規模感でOK） |
既存システムとの連携は必要ですか？ | △（「あるかもしれない」程度でOK） |
社内で他に検討に関わる方はいますか？ | ○（意思決定者・キーパーソンの存在を伝える） |
技術的な制約やご要望はありますか？ | △（「特になし」でも問題ありません） |
他社にも相談していますか？ | △（正直に答えればOK） |
「◎」は答えられると相談がスムーズに進む質問、「○」は分かる範囲で答えれば十分な質問、「△」は答えられなくても問題ない質問です。
「◎」と「○」、すなわち先述の最低限の5項目で整理した内容を答えられれば、初回相談は十分に成立します。一度頭の中でシミュレーションしておけば、当日の心理的負担は大きく下がります。
構想段階から伴走してくれる開発会社の選び方
「相談してよい」と分かったら、次は会社選びです。構想段階からの相談を本当に歓迎する会社を見極めるには、次の5観点を確認してみてください。
なお、「どんな会社なら要件定義前から相談できるのか」をより具体的に知りたい方は要件定義前から相談できる開発会社の特徴と選び方で詳しく解説しています。本記事では概要のみご紹介します。
- 初回相談が無料・気軽に申し込めるか: 「壁打ち相談歓迎」と明記している会社は構想段階の相談に慣れています。「正式な見積もり依頼のみ受付」とハードルが高い会社は、決まりきった案件を好む傾向があります
- エンジニアが相談に同席するか: 営業担当のみだと技術的な実現可能性を踏まえた対話ができません。技術的な質問にその場で答えられる会社の方が、構想段階の発注者には心強い相手になります
- 要件定義段階から伴走するメニューがあるか: 「準委任契約での要件定義フェーズ」「PoC支援」「コンサルティング」など、開発前フェーズを切り出して提供している会社は構想段階の伴走を主軸に据えています
- アジャイル開発に対応しているか: ウォーターフォール一辺倒の会社は「最初に全要件を確定」というスタンスになりがちです。アジャイル対応の会社は要件が固まりきっていない状態を許容する文化を持っています
- 構想段階からの伴走実績があるか: 事例ページに「アイデア段階から一緒に作りました」「企画フェーズから関わりました」といった記述がある会社は、実際にその経験を積んでいます
参考までに、秋霜堂株式会社が提供する開発支援サービス「TechBand」も、構想段階からの伴走を強みのひとつとしています。クライアントの社内に開発部門が増設されたかのように、企画から要件定義・開発・運用までを一気通貫でサポートします。こうしたタイプの会社もあると知っておくと選択肢が広がります。
まとめ：早めの相談が成功の鍵
ここまでの内容を振り返ります。
- 「仕様が決まってから相談」は誤解: 開発会社の多くは構想段階からの相談を歓迎しており、社内検討だけでは要件は永遠に固まりません
- 相談前に整理すべきは5項目だけ: 「Why（解決したい課題）」「利用者」「予算レンジ」「希望時期」「意思決定者」が言語化できていれば十分です。機能仕様や技術選定は会社と一緒に決めるものです
- 構想段階から相談する積極的メリット: 費用面（手戻り防止・代替案・段階見積もり）、品質面（業界知見の反映）、期間面（並走によるプロジェクト前倒し）の3つの恩恵があります
「もう少し詰めてから連絡しよう」という慎重さは、多くの場合プロジェクト停滞を招きます。本記事の5項目を手元に書き出し、それぞれにざっくりとした答えを書ければ、もう相談する準備は十分整っています。
仕様書の書き方を後の段階で学びたい方は仕様書 サンプル｜開発会社に伝わる書き方とテンプレ活用ガイドを、要件定義の進め方を深掘りしたい方はAI開発の要件定義｜失敗しないための進め方と書き方ガイドを参考にしてみてください。これらは相談後の段階で活用するもので、今すぐ揃える必要はありません。
無理に何かを決めてから連絡する必要はありません。「まだ何も決まっていない」状態こそ、開発会社にとって最も貢献しがいのあるタイミングです。気になっていた開発会社の問い合わせフォームを開いてみてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
