「来週までに開発会社を何社かピックアップして問い合わせておいて」——上長からそう指示されたものの、問い合わせフォームを開いたまま手が止まっていませんか。自由記述欄に何を書けばよいか分からず、「専門用語を間違えて使ったら相手にされなくなるのでは」「ふんわりした内容で連絡したら馬鹿にされるかもしれない」と画面の前で固まってしまう。はじめての発注では、こうした状況は珍しくありません。
率直に言うと、その不安はかなり大きな誤解を含んでいます。開発会社の窓口担当者は、毎週のように「何から相談すればいいかも分からない」状態のお客様と話しています。むしろ専門用語が完璧に並んだ問い合わせほど、後で「実は意味を勘違いしていた」と発覚して手戻りが大きくなることがあります。最初の連絡は、上手な言葉を選ぶ場面ではなく、お互いに事情を共有する場面だと考えてみてください。
とはいえ「何でもいいから書けばいい」と言われても困ってしまうのが本音だと思います。そこで本記事では、開発会社に最初の連絡を入れる前に整理しておきたい項目を「3つだけ」に絞り、それ以外は意識的に手放してよい、というスタンスで解説します。目的・予算感・時期。この3軸が決まっていれば、初回の連絡と打ち合わせは十分に成立します。
加えて、本記事の後半では「決めなくてよいこと」のリスト、初回問い合わせ文の穴埋めテンプレート、初心者がやってしまいがちなNGフレーズと言い換え例まで紹介します。これらは「準備不足が露呈して恥をかきたくない」という、誰もが口に出しにくい不安に応えるためのものです。
読み終えたあとには、問い合わせフォームの自由記述欄を埋め、送信ボタンを押せる状態になっているはずです。完璧な準備を目指す必要はありません。「最初の打ち合わせができる状態」に到達することを、まず一緒に目指していきましょう。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
「はじめての発注で何も分からない」あなたへ
最初に、いちばん大事なことをお伝えします。発注経験がなく、技術的な用語にも自信がないという状態は、開発会社にとって「想定外」ではありません。むしろ標準的なお客様の姿に近いです。
開発会社は「分からないことが分からない」状態の相談にも慣れています
業務システムを発注する企業の多くは、社内に専任のエンジニアを抱えていません。経営企画の方、事業部のマネージャー、総務や経理を兼務している情シス窓口の方など、開発の経験がない方が窓口になることがほとんどです。開発会社の営業・窓口担当者は、そうした方々と日常的にやり取りしています。
実務的にも、初回の打ち合わせは「ヒアリング」と呼ばれることが多く、お客様が完成形を語る場ではなく、お客様の課題を開発会社が引き出していく場として設計されています。つまり「全部きれいに言語化できていなくて当然」が前提です。問い合わせフォームに「現状こういう業務をExcelで回していて、属人化に困っている」と書くだけでも、十分に話は始まります。
それでも不安が残るのは、「丁寧に相手をしてくれるとは限らない」「もっと大きな案件のほうが優先されるのでは」という心配があるからかもしれません。これは半分は当たっており、半分は外れています。後ほど「初回連絡時にやりがちなNG質問・NGフレーズと対処法」で扱いますが、優先度を下げられるのは「準備不足」が原因ではなく、「本気度が伝わらない聞き方」をしてしまう場合がほとんどです。本気度は、専門用語の量ではなく、目的・予算感・時期の3点で伝わります。
この記事のゴール
本記事のゴールはシンプルです。「開発会社への初回連絡を、迷わず送信できる状態」に到達することです。具体的には、次の2点を持ち帰っていただきたいと考えています。
- 連絡前に整理すべき3つの軸（目的・予算感・時期）について、最低ラインの考え方を理解する
- 逆に「決めなくてよいこと」と「打ち合わせで一緒に決めていくこと」の境界線を知る
要件定義の細部、技術選定、UIデザイン、契約条件、運用体制——こうした論点は、初回連絡の段階では必要ありません。むしろ、最初から細かく決め込んで連絡すると、開発会社側からの提案の幅が狭まり、結果的に最適でない構成になることもあります。「決めすぎない」こともまた、はじめての発注で意識しておきたい姿勢です。
それでは、3つの軸を順番に見ていきましょう。
開発会社に連絡する前に決めておきたい3つのこと
世の中の「システム開発の発注準備」の解説では、5項目から多いものでは8〜10項目を列挙しているものが少なくありません。網羅的という意味では正しいのですが、はじめての方にとっては「準備しなければならないことが多すぎる」と感じ、かえって着手のハードルを上げてしまいます。
ここでは、思い切って3つに絞ります。目的・予算感・時期。この3つさえ整理できていれば、初回連絡と最初の打ち合わせは確実に成立します。残りの項目は、打ち合わせの中で開発会社と一緒に決めていけば十分です。
1. 目的——「何のために作るのか」を一文で言えるようにする
目的は、最も重要で、かつ最も省略されがちな軸です。「業務システムを作りたい」「Webサイトを作りたい」だけでは、目的ではなく「手段」しか伝わっていません。開発会社が知りたいのは、その手段によって「何を実現したいのか」です。
目的を整理するときは、次の文型で一文にまとめてみてください。
「（誰の／何の）（どんな課題）を解決するために、（どのような状態）にしたい」
例えば次のような形になります。
- 「営業部の見積もり作成業務に毎月50時間かかっている状況を、半分以下にしたい」
- 「複数拠点の在庫情報を月次の手作業で集計しているため、リアルタイムで把握できるようにしたい」
- 「お客様からの問い合わせ対応が属人化しており、誰でも一定品質で応対できる状態にしたい」
「何時間かかっているか」「どれくらい属人化しているか」といった数字や程度感は、正確でなくて構いません。「だいたい月50時間くらい」「特定の社員1人に依存している」レベルの肌感覚で十分です。むしろ、最初から精緻な数値を出そうとすると、それだけで何週間も足止めされてしまいます。
ここで言語化に苦戦する場合のアプローチは、次の「『何が作りたいか』をうまく言葉にできないときの整理術」で詳しく扱います。
2. 予算感——「上限」と「相場感の有無」だけ整理する
予算は、開発会社にとっても最大の関心事ですが、はじめての発注者にとっては最も伝えにくい項目でもあります。「予算を先に言うと足元を見られるのでは」「相場が分からないので答えようがない」と感じる方が多いと思います。
連絡前に整理しておきたいのは、次の2点だけです。
- 上限はあるか: 「これ以上は絶対に出せない」というラインがあるか
- 相場感はあるか: 似た規模の開発に通常どれくらいかかるか、感覚があるか
両方が「ない」場合は、その通り正直に伝えて構いません。「予算は未確定ですが、まず相場感を知りたい段階です」と書くだけでも、開発会社は提案の方向性を組み立てやすくなります。むしろ、相場感がないまま無理に金額を捻り出して伝えると、その金額に縛られて適切な提案を受けられなくなることがあります。
詳しい伝え方は「予算感の整理——相場感がなくても伝え方はあります」で例文付きで紹介します。
3. 時期——「絶対にこの日までに必要」があるかを確認する
時期は、3軸の中で最もシンプルです。判定すべきは1点だけ、「動かせない日付があるかどうか」です。
法令対応の期限、業務の繁忙期、既存システムのサポート切れ、組織変更のタイミング——こうした「ずらせない日付」がある場合は、最初の連絡の時点で伝えておくのが安全です。これがあるかないかで、開発会社の提案する開発手法やスケジュール感が大きく変わります。
逆に、特に動かせない日付がない場合は「半年〜1年を目安に考えている」「急いではいない」と伝えれば十分です。後ほど「スケジュールの整理——『いつまでに必要か』を明確にする」で、必達日のパターン分けと、期限なし時の伝え方を具体的に紹介します。
ここまでが、連絡前に決めておきたい3軸の概要です。次のセクションから、各軸の整理方法を順番に深掘りしていきます。
「何が作りたいか」をうまく言葉にできないときの整理術
目的を一文にまとめようとして手が止まる方の多くは、「機能」から考えようとしています。「在庫管理機能と、発注機能と、レポート出力機能と……」と列挙し始めて、結局何が中心なのか分からなくなる、というパターンです。
ここでは、機能から考えるのではなく、現状の困りごとから逆算する整理方法を紹介します。要件定義（システムに必要な機能・条件を文書化する工程）の専門家でなくても進められる、実務的なアプローチです。
「機能」ではなく「困りごと」から書き出す
まずは、機能名を一切使わず、現在の業務で困っていることを箇条書きで書き出してみてください。日本語で、業務の言葉で構いません。
例えば次のような形です。
- Excelの在庫表が複数拠点ごとに分かれており、本社で合算するのに毎月3日かかる
- 営業担当ごとに見積もりフォーマットが違い、決裁者が比較しづらい
- 問い合わせ対応のノウハウがベテラン社員に集中していて、その人が休むと止まる
- 受発注の管理がメール中心で、過去のやり取りを探すのに時間がかかる
ここでのコツは、「だからこういう機能がほしい」をいったん書かないことです。困りごとを並べる段階で機能を混ぜると、特定の機能ありきの発想に固定されてしまいます。困りごとを並べきった後で、開発会社と一緒に「どの機能で解決するか」を考えるほうが、より良い提案を引き出せます。
Before→After で整理するシンプルなテンプレート
困りごとが書き出せたら、それぞれについて「Before（現状）」と「After（理想）」を簡単な表にまとめてみてください。形式は問いません。
Before（現状） | After（理想） | |
|---|---|---|
例1 | 拠点ごとのExcel在庫表を本社で合算、月3日かかる | 全拠点の在庫がリアルタイムで集計され、即時に確認できる |
例2 | 営業担当ごとに見積もりフォーマットが違う | 統一フォーマットで作成し、決裁者が一覧比較できる |
例3 | 問い合わせ対応がベテランに集中、属人化 | 過去対応の検索ができ、新人でも一定品質で対応できる |
このBefore→After表を、開発会社への問い合わせフォームに添付（またはコピペで貼り付け）するだけでも、最初の打ち合わせの質は大きく上がります。機能の議論ではなく、解決したい状態の議論から始められるからです。
なお、すべての困りごとに対してAfterを書ききる必要はありません。3〜5項目もあれば十分です。むしろ多すぎると、優先順位が曖昧になり、開発の方向性が定まりません。
「これは要件定義の段階で決まれば十分」と割り切ってよいこと
困りごとの整理と並行して、よく頭に浮かぶのが「画面はどう作るのか」「ボタンはどこに置くのか」「権限管理はどうするのか」といった細かい論点です。結論から言うと、これらは初回連絡では一切考えなくて構いません。
これらは要件定義の工程で、開発会社と一緒に決めていく領域です。要件定義は通常、契約後に2〜4週間程度かけて行われ、専門家（要件定義担当・PM）が伴走しながら詰めていきます。発注前に決め込もうとすると、知識不足のまま判断することになり、後で「やはり違った」と手戻りが発生しやすくなります。
「最低限、業務の困りごとが整理できていれば要件定義は始められる」——この感覚を持っていただければ十分です。発注プロセス全体の流れを把握しておきたい方は、後述のWebシステム開発の発注プロセス全体ガイドもあわせてご覧ください。
予算感の整理——相場感がなくても伝え方はあります
予算は、はじめての発注者にとって最大のハードルです。「金額を言うと足元を見られそう」「相場が分からないので答えようがない」「先に予算を言って、それより安い見積もりを出されたら損するのでは」——こうした不安はすべて、よく聞かれるものです。
結論からお伝えすると、予算は隠すよりも、状況を正直に伝えるほうが結果的に得になります。
「予算を言わない」より「相場感がないと正直に言う」方が建設的です
予算情報をまったく出さずに見積もり依頼をすると、開発会社は「お客様がどの水準の提案を求めているか」が分からず、自社の標準的な構成で見積もりを出すしかなくなります。これが結果的に、お客様の想定と大きく乖離する原因になります。
逆に「相場感がないので、概算でいいので教えてほしい」と正直に伝えると、開発会社側は「予算アタリを取りに来ている段階だな」と理解し、複数のパターン（小さく作る／標準的に作る／しっかり作る）を提示してくれることが多くなります。これが結果的に、お客様にとっても比較材料が増える形になります。
足元を見られるかどうかは、予算の伝え方ではなく、開発会社の誠実さで決まる部分が大きいです。複数社に同時に問い合わせをし、相見積もりを取れば、相場から大きく外れた金額は自然と気付けます。
上限／概算／相場確認段階——3つの伝え方
予算の伝え方は、自社の状況に応じて次の3パターンから選ぶのが実務的です。
(a) 上限が確定している場合
「予算上限は500万円を想定しています。この範囲で実現できる構成のご提案をいただけますと幸いです。」
上限が経営判断として確定しているなら、明示するのがいちばん早道です。隠しても結局は調整が入るので、最初から伝えることで提案の精度が上がります。
(b) 概算しかない場合
「予算は数百万円規模を想定していますが、まだ正式に確定はしていません。規模感のすり合わせから相談させてください。」
「数百万円」「1,000万円前後」のようなレンジで伝えれば十分です。確定していないことを明示しておけば、後で調整が必要になっても話がスムーズです。
(c) 相場感を聞きたい段階
「予算は未確定で、まずは相場感を知りたい段階です。類似事例の規模感と費用感を教えていただけますと、社内検討の材料にできます。」
これが、本記事の読者にいちばん多いケースかもしれません。正直に「相場確認段階」と伝えるのは、まったく失礼にあたりません。むしろ、開発会社にとっても「無理に金額を引き出されることがない」と分かるため、安心して対応してくれます。
費用対効果は「これくらい節約できそう」レベルで十分
予算と並べて聞かれることが多いのが、「投資対効果はどう考えていますか？」という問いです。ここで完璧なROI（投資収益率）計算を持っていく必要はありません。
「現在月50時間かかっている業務が、半分の25時間になれば、年間で300時間の削減になる。人件費換算でおよそ◯◯万円程度の効果を見込んでいる」——この程度の肌感覚で十分です。精緻な計算は、要件定義以降のフェーズで開発会社と一緒に詰めていけます。
なお、システム開発の費用相場感をもう少し具体的に知りたい場合は、ご相談時に「類似事例の費用感を教えてほしい」と一言添えていただくと、規模別の参考事例を提示してくれる開発会社が多いです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
スケジュールの整理——「いつまでに必要か」を明確にする
「時期」の軸は、3つのうち最もシンプルです。判定すべきは「ずらせない日付があるかどうか」だけです。ただし、ここを曖昧にしたまま連絡すると、開発会社の提案が「とりあえず標準的なスケジュール」になってしまい、自社の事情に合わない構成になることがあります。
「希望日」と「必達日」を分けて整理する
スケジュールを伝えるときは、次の2つを意識的に分けてください。
- 希望日（あったらいいな日）: 「できれば10月くらいまでに使い始めたい」程度の希望
- 必達日（ずらせない日）: 「11月の法令改正までに絶対に対応が必要」のような、外部要因で動かせない期日
希望日だけしかない場合は、後ほど触れるように「半年〜1年を目安」と伝えれば十分です。問題は必達日のほうで、これがある場合は最初の連絡時点で必ず伝えてください。必達日の存在によって、開発手法（一括開発か分割リリースか）、契約形態、体制規模が大きく変わります。
動かせない日付があるなら必ず最初に伝える
「動かせない日付」の代表例は次のようなものです。
- 法令対応の期限: インボイス制度・電子帳簿保存法・改正個人情報保護法など、施行日に間に合わせる必要があるもの
- 業務の繁忙期回避: 「3月末は決算で動けないので2月末までに導入したい」「12月の繁忙期前にリリースしたい」など
- 既存システムのサポート切れ: 利用中のソフトウェアのサポート終了日までに切り替える必要があるケース（例: Windows Server の EOL）
- 組織変更のタイミング: 「4月の組織改編に合わせて新システムを稼働させたい」など、業務移管と連動するケース
- 取引先側の対応期限: 親会社や主要取引先からのシステム連携要求の期限
これらは、開発会社にとって「優先度の高い案件」として扱われやすい情報でもあります。「11月の法令改正に間に合わせたい」と伝えれば、開発会社は逆算してスケジュールを組み、必要に応じて開発手法（最小機能から段階的にリリースする方法など）を提案してきます。
逆に、必達日があるのに伝えずに進めてしまうと、契約直前になって「実は11月までに必要なんです」と判明し、スケジュールが組み直しになるか、最悪の場合は契約が成立しないこともあります。「動かせない日付があるかどうか」は、連絡前にいちど社内で確認しておくのが安全です。
期限が決まっていない場合の伝え方
特に必達日がない場合は、無理に期日を作る必要はありません。次のように伝えれば十分です。
「特に厳密な期日はなく、半年〜1年を目安に検討しています。」
「リリース時期は柔軟に考えています。まずは提案内容を見て社内で検討したいです。」
「期日が決まっていない＝本気度が低い」と思われるのでは、と心配する必要はありません。それよりも、無理に「3ヶ月以内に」などと書いてしまうと、開発会社側はその期日に向けた急ぎの提案を組まざるを得なくなり、結果的にコストが膨らんだり、選択肢が狭まったりします。
「いつまでに必要か」を正直に伝えること——これがスケジュール軸の整理のすべてです。
連絡前に「決めなくてよいこと」
ここまで「決めておきたい3つのこと」を見てきました。同じくらい大事なのが、「決めなくてよいこと」を意識的に手放すことです。準備項目を増やすほど「準備が整っていない自分」を感じてしまい、連絡が遅れていく——この悪循環を断ち切るために、初回連絡時には不要な論点を明示します。
機能の詳細・画面のデザインは決めなくて大丈夫
「画面のレイアウトはどうしよう」「ボタンはどこに配置すべきか」「色は何色がいいか」——こうしたUI・UXの詳細は、初回連絡の段階では一切考える必要がありません。
UI/UXは、開発会社のデザイナーやUXディレクターが、業務フローをヒアリングしながら提案・設計していく領域です。発注者側があらかじめ画面イメージを固めてしまうと、業務に最適化されたデザインの可能性を狭めることになります。「使いやすい画面にしたい」という気持ちだけ持っていれば十分で、それをどう実現するかは専門家に任せて問題ありません。
同様に、「どの機能を、どの画面に、どういう順番で配置するか」といった機能の詳細仕様も、要件定義の段階で詰めていく内容です。初回連絡では「こういう業務の課題を解決したい」までで十分です。
「どんな技術で作るか」は開発会社の専門領域
「Pythonで作ってもらえますか？」「データベースはMySQLでお願いします」——技術選定について、発注者側から指定する必要は基本的にありません。
技術選定（プログラミング言語・フレームワーク・データベース・クラウド基盤など）は、開発会社が「業務要件・規模・将来の拡張性・保守性・運用コスト」などを総合的に判断して決める領域です。指定すべきケースは、「既存システムと連携する必要があり、技術的制約が確定している」「社内の保守エンジニアが特定の言語しか扱えない」など、明確な制約がある場合に限ります。
技術指定で起きがちな失敗は、「流行している技術」「名前を聞いたことがある技術」を指定してしまうことです。技術の流行は短く、業務システムの寿命（5〜10年以上）と合わないこともあります。「うちの業務に合う技術を提案してください」と伝えれば十分です。
運用・保守の体制は契約直前まで決めなくてよい
「運用は誰がやるのか」「保守は月いくらかかるのか」「障害対応はどうするのか」——こうした運用フェーズの論点は、初回連絡では考えなくて構いません。
運用・保守の体制は、開発内容が固まった後（要件定義〜設計フェーズの後半）に、提案内容と合わせて議論する領域です。先に「24時間365日サポートで」「障害対応は1時間以内で」などと固めてしまうと、過剰な体制（＝過剰なコスト）を発注することになります。
「運用についてもまとめてご提案ください」と一言添えれば、開発会社側が必要十分な選択肢を提示してくれます。
ここまで挙げた「機能詳細・画面デザイン・技術選定・運用保守」は、いずれも初回連絡の段階では決めなくてよい論点です。「自分が決めなくていい」と認識するだけで、準備の負荷は大きく下がります。
初回連絡時に使える問い合わせ文テンプレート
ここからは、いよいよ実際の問い合わせ文を作成します。これまで整理してきた「目的・予算感・時期」と「Before→After」を、開発会社に伝わる形にまとめていきます。
形式は2パターン用意しました。お取引先からの紹介経由や、自社で開発会社をリストアップしてメールで連絡するケースは、テンプレート1（メール用）を使ってください。Webサイトの問い合わせフォーム経由で連絡する場合は、テンプレート2（フォーム用）が便利です。
【テンプレート1】メール用（取引先紹介経由・フォーマル）
メールで連絡する場合は、相手側で記録に残しやすく、社内共有もしやすいという利点があります。少し丁寧めの文章にしておくと安心です。
件名: システム開発のご相談（株式会社○○）
○○株式会社
○○様
突然のご連絡で失礼いたします。
株式会社○○の○○と申します。
○○様にご紹介いただき、ご連絡させていただきました。
現在、社内で利用するシステムの開発を検討しており、
ご相談に乗っていただけないかとお問い合わせいたしました。
■ 検討中の概要
（目的を一文で：例「営業部の見積もり作成業務にかかる時間を半分にしたい」）
■ 現状の課題
- （Before→Afterの「Before」を3〜5項目）
- ……
- ……
■ 実現したい状態
- （Before→Afterの「After」を3〜5項目）
- ……
- ……
■ 予算感
（a/b/cから1つを選んで記載）
a. 上限は◯◯万円を想定しています。
b. 概算で◯◯万円規模を想定していますが、確定はしていません。
c. 予算は未確定で、まずは相場感を知りたい段階です。
■ 希望時期
（必達日がある場合：例「◯月の法令対応に間に合わせたく、◯月までの稼働を希望しています」）
（必達日がない場合：例「特に厳密な期日はなく、半年〜1年を目安に検討しています」）
■ 希望する打ち合わせ形式
オンライン／対面どちらでも構いません。
まずは1時間程度、現状のヒアリングを兼ねたお打ち合わせをいただけますと幸いです。
ご検討のほど、よろしくお願いいたします。
（署名）
「件名」に「システム開発のご相談」と明示しておくと、相手側で営業メールと区別しやすく、開封率が上がります。
【テンプレート2】Web問い合わせフォーム用（簡潔）
Webサイトの問い合わせフォームは、自由記述欄の文字数に制限がある場合や、何度も問い合わせを送る場合に向いています。要点を短くまとめたバージョンです。
業務システムの開発を検討中です。
社内に開発担当者がおらず、はじめての発注になります。
【目的】
（一文：例「営業部の見積もり作成業務を効率化したい」）
【主な課題】
- （Beforeを2〜3項目）
- ……
【予算感】
（a/b/cから1つ：例「予算は未確定で、相場感を知りたい段階です」）
【希望時期】
（例「半年〜1年を目安に検討中」「◯月までに導入が必要」）
【希望】
まずはオンラインでお打ち合わせをお願いしたいです。
直近1〜2週間でご都合のよい日時をお知らせください。
フォーム用は、目的・課題・予算・時期の4点を要点だけ示し、詳細は打ち合わせで話すスタンスでまとめます。「はじめての発注になります」と最初に一言添えておくと、相手側も対応の前提を理解しやすくなります。
添付資料・参考URLを送るかどうかの判断基準
問い合わせと一緒に、社内資料や参考URLを送るかどうか迷うかもしれません。判断基準は次の通りです。
- 送ったほうがよいもの: 現状の業務フローを示すExcel・ホワイトボード写真・既存システムのスクリーンショット（業務理解に直結する資料）
- 送らなくてよいもの: 「こんなシステムが作りたい」というイメージで集めた他社製品のスクリーンショット（先入観を与え、独自の提案を引き出しにくくなる）
迷ったときは、初回連絡では送らず、打ち合わせで提示するほうが安全です。問い合わせフォーム経由で機密情報を送るのは、セキュリティ面でも避けたほうがよい場面です。
これでテンプレートの紹介は終わりです。最後に、「これは言わないほうがいい」というNGパターンと、その言い換え例を見ていきます。
初回連絡時にやりがちなNG質問・NGフレーズと対処法
ここまで読み進めていただいた方であれば、もう問い合わせ文を送れる準備はほぼ整っています。最後のステップとして、初回連絡時に開発会社から距離を取られがちなフレーズと、その言い換え方を紹介します。これらは「失礼にあたる言い方」というよりも、結果的に優先度を下げられてしまう言い方だとお考えください。
「全部おまかせで」が嫌われる理由と言い換え方
「とにかく全部おまかせで、いい感じに作ってください。」
このフレーズは、丸投げに見えてしまい、開発会社側が「責任を取らされやすい案件」と感じる原因になります。「全部おまかせ」と言われると、要件確認の責任が開発会社に偏り、後で「思っていたのと違う」と言われるリスクが高まるからです。
言い換え例:
「現状の業務課題はお伝えできますが、解決方法のご提案はお任せしたいと考えています。一緒に整理いただけますと幸いです。」
「課題は伝える、解決策は一緒に考える」というスタンスが伝わると、開発会社側は前向きに取り組みやすくなります。
「ざっくり見積もりだけ」と言うと優先度を下げられる
「ざっくりでいいので見積もりだけ送ってください。」
このフレーズは「契約意思が低い」と判断され、優先度が下がりやすい代表例です。見積もり作成は開発会社にとってもコストがかかる業務（事前のヒアリング・概算設計・体制見積もりなど）であり、「ざっくりだけ」と言われると、本気度が伝わりません。
言い換え例:
「まずは規模感のすり合わせから相談させてください。本格的な見積もりは打ち合わせ後でかまいません。」
「規模感のすり合わせ」「相場感を知りたい」という言い方であれば、開発会社側は「初期検討フェーズの正当な問い合わせ」として対応しやすくなります。
競合製品名・他社見積もり額の出し方
「ChatGPTみたいなやつを作りたいんですけど、おいくらですか？」
「他社さんは300万円って言ってたんですけど、御社はいくらでできますか？」
これらも、初心者がやりがちなNGパターンです。前者は「具体的に何を実現したいのか」が伝わらず、後者は「価格競争に巻き込まれる案件」として警戒されます。
ChatGPT・Slack・kintone・Salesforceなど、有名製品の名前を出すこと自体は問題ありません。問題なのは「『◯◯みたい』だけで具体的な要件が示されていない」ことです。
言い換え例:
「ChatGPTのように自然な対話で社内資料を検索できる仕組みを作りたいと考えています。社内ナレッジは現在◯件あり、検索は週に◯回程度発生しています。」
このように、「製品名 + 具体的な業務状況」をセットで伝えれば、開発会社側は実現可能性を判断しやすくなります。
他社見積もりについても、出し方次第で建設的に使えます。
言い換え例:
「複数社で並行してご相談しており、規模感の参考までに、他社からは300万円前後とのご回答をいただいています。御社からも同じ規模感を前提に、ご提案の方向性をお聞かせいただけますと幸いです。」
「価格を下げてほしい」ではなく「規模感のすり合わせ」として伝えれば、開発会社側も自社の提案の特徴（価格と内容のバランス）を説明しやすくなります。
これらのNGフレーズを避けるコツは、「結論だけを短く言わない」ことです。短い問いかけは、相手に解釈の負担を強いるため、誤解や警戒を生みます。少し長くなっても、状況・課題・希望をセットで伝えるほうが、結果的にスムーズに進みます。
連絡後の流れと、次に読むべき記事
初回連絡を送った後、開発会社からの返信はおおむね1〜3営業日以内に届きます。連絡後の流れを簡単に把握しておくと、その後の対応がスムーズです。
連絡後の典型フロー
- 返信受領（1〜3営業日）: 開発会社から打ち合わせ日程の調整連絡が届きます
- 事前アンケート（任意）: 開発会社によっては、打ち合わせ前に簡単なヒアリングシートを送付してくる場合があります。記入できる範囲で構いません
- 初回打ち合わせ（30分〜1時間）: 現状ヒアリングと、想定される進め方の説明。具体的な見積もりはまだ出ません
- 提案・見積もり（打ち合わせ後1〜3週間）: 開発会社が打ち合わせ内容をもとに提案書・見積もりを作成
- 契約検討: 提案内容を社内で検討し、契約に向けた条件調整に進みます
初回打ち合わせの場では、「全部きれいに答えなければならない」と気負う必要はありません。むしろ「これはまだ決まっていません」「社内で確認します」と素直に伝えるほうが、後の手戻りが減ります。
全体プロセスを知りたい方へ
ここから先のフェーズ（要件定義、設計、開発、テスト、リリース、運用）は、本記事のスコープ外です。発注プロセス全体を一望したい方は、Webシステム開発の発注プロセス全体ガイドをご覧ください。発注の全工程と、各フェーズで発注者側が判断すべき論点が整理されています。
まとめ——完璧な準備より「最初の一歩」を踏み出すことが大事
本記事のキーメッセージを、最後にもう一度まとめます。
- 開発会社への初回連絡は、目的・予算感・時期の3軸さえ整理できていれば成立する
- 「機能の詳細・画面デザイン・技術選定・運用保守」は決めなくてよい。これらは打ち合わせと要件定義で一緒に詰めていく領域
- 予算感がなければ「相場感を知りたい段階」と正直に伝えるほうが建設的
- 動かせない日付（必達日）があるなら最初に伝える。なければ「半年〜1年目安」で十分
- NGフレーズ（全部おまかせで／ざっくり見積もりだけ／製品名だけ）は、状況・課題・希望をセットにすれば建設的な言い方に変えられる
- 添付資料は「現状業務の資料」のみ。先入観を与える資料は送らない
そして、何より大切なのは——「準備が足りない」と感じている時点で、必要十分な準備をしようとしている証拠だということです。完璧主義で動けなくなっている方ほど、本記事の3軸さえ整理して連絡してしまえば、最初の打ち合わせは必ず成立します。
問い合わせフォームを開いたら、本記事のテンプレートに沿って5〜10分で文章を作り、送信ボタンを押してみてください。最初の一歩を踏み出した瞬間から、「分からないこと」は一気に減っていきます。開発会社はそのために存在しています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
