「そろそろシステムを新しくしないと」「この業務、外に頼んだ方が早いのでは」——そう感じて外注を検討し始めたものの、いざ動こうとすると何から手をつければよいのか分からない。開発会社に問い合わせるにしても、何を伝えれば見積もりが出るのか見当がつかない。社内で「予算はいくらかかるのか」と聞かれても答えられない。そんな状態でこのページにたどり着いた方は多いのではないでしょうか。
結論から言うと、外注を成功させる分かれ目は「発注後」ではなく「発注前」にあります。開発会社に連絡する前の社内準備が甘いまま話を進めると、見積もりの桁が想定と違う、要望が正しく伝わらない、後から「言った・言わない」でもめる、といったトラブルにつながりやすくなります。逆に言えば、社内でやるべき準備を一通り押さえておけば、外注は決して怖いものではありません。
この記事では、システム開発の外注を初めて検討する担当者に向けて、社内で準備すべきことと、問い合わせから納品までの全体の流れを順番に解説します。この記事は「外注のはじめかた」カテゴリの入口となる総論記事です。個別のテーマ（要件のまとめ方、契約形態の違い、見積もりの読み方など）は、それぞれ専門のコラムで詳しく扱いますので、この記事では「全体像を一通り把握する」ことを目的にします。
この記事で分かること
この記事を読むと、外注を検討し始めた段階から実際に開発会社に発注するまでの全体の流れが分かります。具体的には、社内で最初に決めるべきこと、開発会社を探す前に準備すべき資料、問い合わせから契約までの標準的なステップ、そして外注が向いているケースと必ずしも向いていないケースの見分け方を扱います。
読み終えたときに「次に何をすればよいか」が具体的に分かる状態を目指しています。すでに個別の論点（見積もりの読み方や契約形態など）で悩んでいる方は、記事の後半にある関連記事の案内から該当するページに進んでください。
なぜ「発注前の準備」が重要なのか
システム開発の外注でよくあるトラブルの多くは、実は開発会社側の技術力の問題ではなく、発注前の準備不足に起因します。よくあるパターンを整理すると、次のようなものがあります。
- 「いい感じのシステムを作ってほしい」としか伝えられず、開発会社側も何を作ればよいか分からないまま見積もりを出し、後から「思っていたものと違う」となる
- 社内の決裁者（経営者や上長）が費用対効果を理解できず、稟議が通らない、あるいは通った後に「そんなに高いとは思わなかった」と揉める
- 相見積もりを取ったが、会社によって前提条件が違いすぎて金額の比較ができない
- 契約書を交わさず口頭やメールのやり取りだけで進めてしまい、追加費用の発生条件や納品物の範囲があいまいなまま着手してしまう
これらはすべて、開発会社に連絡する前の社内準備で防げる、あるいは大幅にリスクを減らせるものです。逆に言えば、外注先の技術力を見極めることよりも先に、自社側の「準備」を整えることの方が、初めて外注する担当者にとっては優先度が高いといえます。
開発会社を探し始める前に、まず「何を」「なぜ」「いくらまでなら」作りたいのかを自分の言葉で説明できる状態にしておくこと。これが外注準備の最初の一歩です。
社内でやるべき準備1: 課題と目的を言語化する
最初にやるべきことは、システムそのものの仕様を考えることではなく、「なぜシステムが必要なのか」という課題と目的を言語化することです。ここが曖昧なまま開発会社に相談すると、開発会社側も的確な提案ができません。
課題の言語化では、次の3点を最低限整理しておくと後の工程がスムーズになります。
- 現状、何に困っているか（例: Excelでの在庫管理が属人化し、担当者が休むと発注ミスが起きる）
- その課題によって、具体的にどんな損失・非効率が生じているか（例: 発注ミスによる欠品が月に数回発生している、確認作業に毎日1時間かかっている)
- システム化によって、どんな状態になれば成功と言えるか（例: 誰が担当しても同じ手順で在庫確認ができる状態にしたい）
ここで重要なのは、最初から「こういう機能が欲しい」という手段（How）ではなく、「何に困っていて、どうなりたいか」という課題と目的（Why・What）から整理することです。手段から入ってしまうと、実はもっとシンプルな方法で解決できる課題を、無理に大掛かりなシステムで解決しようとしてしまうことがあります。
社内でやるべき準備2: 決裁者を早い段階で巻き込む
中小企業の場合、システム開発の予算は経営者や役員の判断が必要になることがほとんどです。ところが、現場の担当者だけで要件を固めてから決裁者に相談すると、「なぜそんなに費用がかかるのか」「本当に必要なのか」と一から説明し直すことになり、時間をロスしてしまいます。
できれば、課題の言語化と並行して、決裁者に「こういう課題があり、外注を検討している」という事実を早めに共有しておくことをおすすめします。この段階では詳細な見積もりまでは不要です。まずは「検討していること」と「おおよその課題感」を共有し、決裁者の関心事（費用なのか、期間なのか、リスクなのか）を把握しておくと、後の稟議がスムーズになります。
決裁者への説明では、システムの機能の詳細よりも「この課題を放置するとどうなるか」「解決すると何が変わるか」を中心に伝える方が伝わりやすい傾向があります。IT分野に詳しくない決裁者であるほど、技術的な話よりも費用対効果の話を重視する点は意識しておくとよいでしょう。
社内でやるべき準備3: 要望を書き出し、優先順位をつける
課題と目的が固まったら、次は「システムに求める要望」を書き出していきます。この段階でいきなり厳密な仕様書を作る必要はありません。まずは箇条書きで、思いつく限りの要望を洗い出すことから始めます。
要望が出そろったら、次のように優先順位を分類します。
| 分類 | 内容 | 例 |
|---|---|---|
| 必須（Must） | これがないと導入する意味がない機能 | 在庫データをリアルタイムで複数人が確認できる |
| あるとよい（Want） | あれば便利だが、なくても運用でカバーできる機能 | 発注書の自動作成 |
| 将来的に（Future） | 今回は見送るが、将来追加したい機能 | AIによる需要予測 |
この優先順位付けが重要なのは、開発会社に見積もりを依頼する際、すべてを「必須」として伝えてしまうと、見積もり金額が想定以上に膨らみやすいためです。「まずは必須の機能だけで小さく始めて、様子を見ながら追加する」という進め方も選択肢に入れられるよう、優先順位を整理しておくと、開発会社側からも段階的な提案を受けやすくなります。
この「要望を整理して開発会社に伝える」という工程は、後の段階で要件定義としてより厳密に詰めていくことになりますが、発注前の自社側の準備としては、ここまで整理できていれば十分です。なお、要件定義を含むシステム開発の標準的な工程は、IPA（情報処理推進機構）が「共通フレーム2013」として公開しており、開発会社との会話で工程の呼び方に迷ったときの参考になります。要件定義の打ち合わせで開発会社からどんな質問をされるか具体的にイメージしておきたい場合は、要件定義でつまずかないヒアリングのコツも参考になります。
社内でやるべき準備4: 予算感とスケジュールの制約を整理する
要望と並行して、予算とスケジュールの制約も整理しておきます。ここでの目的は「正確な金額を算出すること」ではなく、「開発会社に伝えられる材料をそろえること」です。
予算については、次のような情報があると開発会社側も提案しやすくなります。
- 想定している予算の上限（幅があってもよい）
- 一括での支払いか、分割や月額での支払いを希望するか
- IT導入補助金など、活用を検討している制度があるか
なお、IT導入補助金のような公的な補助金制度は、対象となるツールや申請要件が年度ごとに変わります。活用を検討する場合は、外注の検討と並行して、その年度の最新の公募要領を必ず確認してください。
スケジュールについては、「いつまでに使い始めたいか」という希望と、その理由（例: 来期の新体制に合わせたい、既存システムのサポート終了に間に合わせたいなど）をセットで伝えられるようにしておきます。理由まで伝わると、開発会社側も「その期日を守るために、どこを削るべきか」といった現実的な提案をしやすくなります。
開発会社に問い合わせる前に用意しておきたい資料
ここまでの準備が整ったら、実際に開発会社への問い合わせに進みます。問い合わせの際、次のような情報がまとまっていると、初回の打ち合わせが格段にスムーズになります。
- 課題と目的（なぜシステムが必要か）
- 要望リストと優先順位（Must / Want / Future）
- 予算のおおよその幅
- 希望するスケジュールとその理由
- 現在使用しているシステムやツール（あれば）、それとの連携要否
これらを1〜2枚程度の資料、あるいは箇条書きのメモにまとめておくと、複数の開発会社に同じ情報を過不足なく伝えられます。厳密な様式で作られた提案依頼書である必要はなく、RFP（提案依頼書）と呼ばれる文書の簡易版のようなものだと考えてください。この資料があるかないかで、各社から返ってくる見積もりの精度や、比較のしやすさが大きく変わります。簡易版RFPに何をどこまで書けばよいかは、RFP(提案依頼書)は中小企業に必要かで具体的に整理しています。
逆に、この資料を用意せず口頭だけで「こんな感じのものを」と伝えてしまうと、開発会社ごとに解釈が異なり、見積もり金額の前提条件がバラバラになって比較そのものが難しくなります。相見積もりを取る予定がある場合は特に、この資料の準備を省略しないことをおすすめします。
発注までの全体の流れ
社内準備が整ったら、実際に発注に至るまでの標準的な流れを見ていきます。会社によって多少の違いはありますが、おおむね次のようなステップで進みます。
- 情報収集・問い合わせ: Webサイトや紹介などで候補となる開発会社をいくつか探し、準備した資料をもとに問い合わせる
- 初回打ち合わせ・ヒアリング: 開発会社の担当者と課題・要望をすり合わせる。この段階で開発会社側の対応の丁寧さや質問の的確さも見極めのポイントになる
- 概算見積もりの提示: 詳細な仕様が固まる前の、幅のある概算見積もりが提示されることが多い
- 要件のすり合わせ・詳細見積もり: 必要に応じて要件定義の工程に進み、より精緻な見積もりが提示される
- 契約形態・条件の確認: 請負契約や準委任契約といった契約形態、SOW（作業範囲記述書）の内容、支払い条件などを確認する
- 契約締結・発注: 条件に合意し、契約書を交わして正式に発注する
- 開発・進行管理: 開発が始まり、定期的な進捗報告や仕様確認が行われる
- 納品・検収: 完成したシステムが契約内容を満たしているか確認し、受け入れる
この一連の流れの中で、社内準備が特に効いてくるのはステップ1〜4です。課題・要望・予算・スケジュールの整理ができていれば、この段階のやり取りが大幅に短縮されます。逆にここが曖昧だと、何度もヒアリングをやり直すことになり、発注までに数ヶ月単位で時間がかかることも珍しくありません。
ステップ5以降の契約形態や検収の詳細、ステップ7の進行管理については、発注後のテーマとして別カテゴリ「開発会社とのつきあいかた」で扱っています。この記事では、あくまで「発注前の準備と、発注までの流れ」に絞って解説しています。
見積もり依頼時に複数社へ同じ条件を伝える重要性
相見積もりを取る際、特に注意したいのが「各社に同じ前提条件を伝える」ことです。当たり前のようですが、実際には打ち合わせを重ねるうちに、会社ごとに伝える情報の粒度が変わってしまい、結果として見積もり金額を単純比較できなくなるケースがよくあります。
たとえば、A社には「必須要件」だけを伝え、B社には「あるとよい要件」まで詳しく話してしまうと、B社の見積もりの方が高くなるのは当然です。しかし、これを「B社は割高だ」と誤解してしまうと、正しい比較ができません。前述の資料（課題・要望リスト・優先順位・予算感・スケジュール）を先に作っておく最大のメリットは、この「伝える情報のブレ」を防げることにあります。
また、見積もりを比較する際は、金額の総額だけでなく、次の点も併せて確認することをおすすめします。
- 見積もりに含まれる作業範囲（設計・開発・テスト・納品後のサポートまで含むか）
- 追加費用が発生する条件（要望が後から増えた場合の扱い）
- 支払いのタイミング（着手時・中間・納品後など）
これらが見積もり書に明記されていない場合は、契約前に必ず確認するようにしてください。金額の安さだけで判断すると、後から「これは別料金です」という追加費用が次々に発生し、結果的に想定より高くつくことがあります。
開発会社をどう探し、どう比較するか
社内準備が整ったら、次に候補となる開発会社を探すことになります。探し方にはいくつかの手段があり、それぞれ一長一短があるため、複数の手段を組み合わせることをおすすめします。
- 知人・取引先からの紹介: 実際に発注した会社からの評判を聞けるため、対応の質や相性を事前にある程度把握できます。ただし紹介の場合、他社と比較しにくい、断りづらいといった側面もあります
- Web検索・開発会社のサイト: 得意領域（業種特化、特定の技術に強いなど）を確認しやすい一方、実際の対応力はサイトの情報だけでは分かりません
- マッチングサービス・比較サイト: 複数社にまとめて問い合わせできる利便性がありますが、掲載されている会社が必ずしも自社の要件に強いとは限りません
候補が出そろったら、比較の軸を決めておくと選定がぶれません。金額の安さだけで選ぶと、実績や体制が不十分な会社を選んでしまうリスクがあります。逆に、知名度や規模だけで選ぶと、必要以上に高額な提案になりがちです。最低限、次の観点は比較しておくとよいでしょう。
- 自社と近い業種・規模の開発実績があるか
- 見積もりの内訳が具体的に説明されているか（一式いくら、ではなく機能ごとの内訳があるか）
- 開発後の保守・サポート体制について明確な説明があるか
- 質問への回答が具体的で、こちらの課題を理解した上での提案になっているか
複数社とやり取りする中で、金額だけでなく「この担当者・この会社となら、発注後も長く付き合えそうか」という相性の見極めも重要です。システム開発は納品して終わりではなく、その後の保守・改修を含めた長い付き合いになることが一般的なためです。
いきなり大きく発注する前に検討したい選択肢
社内準備が整い、いざ発注という段階になっても、最初から大規模なシステムを一括で発注することが常に最適とは限りません。特に初めて外注する場合は、次のような段階的なアプローチも検討する価値があります。
まず、本当にフルスクラッチでの開発が必要かどうかを見極めることです。フルスクラッチ開発は自社の業務に合わせた柔軟な開発ができる一方、既製のパッケージソフトやクラウドサービス、ノーコード・ローコードと比べて期間・費用がかかる傾向があります。業務の独自性が高くなく、既製品やノーコードツールのカスタマイズで要件を満たせるのであれば、それらを選択肢に含めて比較検討する方が、結果的に低コスト・短期間で課題を解決できる場合があります。
システム開発を外注する立場としては、フルスクラッチでの開発を提案したくなる面もあるかもしれませんが、既製品やノーコードで十分に解決できる課題であれば、無理にフルスクラッチを選ぶ必要はありません。この判断は、開発会社に相談する前に一度、自社内で「本当に独自開発が必要な業務か」を検討しておくことをおすすめします。開発会社によっては、相談した時点で自社の受注につながる提案に偏る場合もあるため、判断材料は複数の情報源から集めるとよいでしょう。
もう一つの選択肢が、最初から本番システムを作り切るのではなく、小さく試してから広げる進め方です。次のような段階的な発注の形があります。
- PoC（概念実証）（概念実証）: 本格開発の前に、アイデアが実際に機能するか・効果が見込めるかを小規模・低コストで検証する
- MVP（実用最小限の製品）（実用最小限の製品）: すべての機能を作り込む前に、核となる価値だけを備えた初期バージョンをリリースし、実際の需要を確かめる
いきなり要望リストの「Must」をすべて盛り込んだ大規模なシステムを発注するのではなく、まずは最小限の範囲で試してから、効果を確認しつつ機能を追加していく進め方は、初めての外注ではリスクを抑える有効な選択肢になります。予算やスケジュールに余裕がない場合ほど、この段階的なアプローチを検討する価値があります。
外注が向いているケース・向いていないケース
外注はあらゆる課題の解決策になるわけではありません。準備を進める中で、そもそも外注という手段自体が今の課題に合っているかを一度立ち止まって考えることも重要です。
外注が向いているケースとしては、次のようなものが挙げられます。
- 業務が自社独自のフローで、既製品やノーコードツールでは対応しきれない
- 継続的に発生する業務で、システム化による効果（時間削減・ミス削減）が明確に見込める
- 社内に開発できる人材がおらず、今後も内製する予定がない
一方で、外注よりも先に検討した方がよいケースもあります。
- 課題がまだ曖昧で、何を作ればよいか自分たちでも説明できない段階（この場合は、まず業務の棚卸しや課題整理を先に行う方が結果的に近道になることが多い）
- 既製のSaaSやノーコードツールの標準機能で、実は十分に解決できる可能性がある
- 一時的・単発の業務で、システム化するほどの頻度・規模がない
これらの見極めも、社内でやるべき準備の一部です。「システムを外注する」という手段が先に決まってしまっている場合は、一度その前提を疑い、課題の言語化からやり直すことをおすすめします。
発注準備にどれくらいの期間を見込むべきか
初めて外注を検討する担当者からよく聞かれるのが、「社内準備から発注まで、どれくらいの期間を見ておけばよいか」という質問です。これは会社の規模や課題の複雑さ、決裁のスピードによって大きく変わるため、一概に「何週間」と言い切ることはできません。ただし、準備が進む順番と、それぞれの工程で何に時間がかかりやすいかを知っておくと、大まかな見通しは立てやすくなります。
時間がかかりやすいのは、多くの場合システムの技術的な検討そのものよりも、社内の合意形成です。担当者ひとりで課題や要望を整理する作業は数日〜1週間程度で終えられることが多い一方、決裁者への説明や関係部署へのヒアリング、稟議の承認には、社内の意思決定フローによって数週間から、場合によっては1ヶ月以上かかることもあります。
また、複数社に問い合わせて相見積もりを取る場合、各社からの提案が出そろうまでにも時間がかかります。開発会社側もヒアリングから見積もり作成までに一定の期間を要するため、問い合わせから提案が出そろうまでを急ぎすぎず、余裕を持ったスケジュールで動く方が、結果的に比較検討の質が上がります。
急いでいる場合ほど、準備を省略して早く発注しようとしてしまいがちですが、準備不足のまま発注すると、要件の認識違いによる手戻りでかえって時間を失うことになりかねません。「急がば回れ」という言葉通り、社内準備にかける時間は、後工程のトラブルを防ぐための投資と捉えることをおすすめします。
社内での役割分担を決めておく
ひとり情シスや総務兼任の担当者が外注の窓口になる場合、すべてをひとりで抱え込んでしまいがちですが、可能な範囲で社内の役割分担を整理しておくと、準備がスムーズに進みます。
典型的な役割分担の例を整理すると、次のようになります。
- 窓口担当: 開発会社とのやり取りの一次窓口。この記事の読者に多い立場
- 決裁者: 予算の承認、最終的な発注可否の判断を行う経営者・役員
- 業務の実務者: 実際にシステムを使う現場の担当者。要望や現状の業務フローを最もよく知っている
- 情報システムの管理者: 既存システムとの連携やセキュリティ要件について判断できる立場（専任がいない場合は窓口担当が兼ねることも多い）
小規模な会社では、これらの役割を1〜2人が兼任することも珍しくありません。それでも、「誰が何を判断するか」を意識的に整理しておくと、要望の聞き取り漏れや、決裁段階での手戻りを防ぎやすくなります。特に、実務者へのヒアリングを省略して窓口担当の想像だけで要望をまとめてしまうと、現場の実態と離れた要件になり、後から「これでは使えない」という事態を招きやすい点には注意してください。
準備段階でよくあるつまずき
準備を進める中で、初めて外注する担当者がつまずきやすいポイントをいくつか紹介します。
つまずき1: 完璧な仕様書を作ろうとして時間がかかりすぎる
社内だけで詳細な仕様まで固めようとすると、専門知識がないために時間がかかりすぎたり、かえって現実的でない要望になってしまったりすることがあります。詳細な仕様の詰めは、多くの場合、開発会社との打ち合わせの中で要件定義として一緒に進めるものです。社内での準備は「課題・要望・優先順位・予算感」を伝えられる状態までで十分で、厳密な仕様書の完成を目指す必要はありません。
つまずき2: 1社だけに相談して決めてしまう
初めての外注では、最初に相談した1社の提案をそのまま受け入れてしまいがちです。しかし、会社によって得意領域や価格帯、提案の切り口は異なります。可能であれば複数社に同じ資料をもとに相談し、比較検討することをおすすめします。
つまずき3: 決裁者への説明を後回しにする
要件がほぼ固まってから初めて決裁者に相談し、「そんな金額は聞いていない」「もっと早く言ってほしかった」という反応を受けるケースは少なくありません。前述の通り、決裁者への共有はできるだけ早い段階から始めることが、後々のトラブルを避けるコツです。
つまずき4: 口頭でのやり取りだけで話を進めてしまう
準備段階から発注直前まで、メールや対面でのやり取りだけで進めてしまい、決まったはずの内容が記録に残らないことがあります。打ち合わせのたびに、決まったことを簡単なメモやメールで書き残し、認識を確認し合う習慣をつけておくと、後の契約書作成や作業範囲記述書の確認もスムーズになります。
この記事の位置づけと、次に読むべき記事
この記事は「外注のはじめかた」カテゴリの総論として、社内準備から発注までの全体像を扱いました。個別のテーマについては、今後このカテゴリ内で順次公開していく専門記事で詳しく解説していく予定です。たとえば、要望を開発会社に伝わる形で整理する方法、請負契約と準委任契約の違い、見積もりの内訳の読み方、契約不適合責任を含めた契約書のチェックポイントといったテーマです。
自社の状況に応じて、次のような優先順位で読み進めることをおすすめします。
- 課題や要望の整理そのものに悩んでいる方は、要望を開発会社に伝わる形でまとめる方法を扱う記事へ
- すでに複数社から見積もりを受け取り、比較で迷っている方は、見積もりの読み方を扱う記事へ
- 契約直前で、契約形態や条項の確認に不安がある方は、契約書のチェックポイントを扱う記事へ
いずれの記事も、この記事と同様に「自社に不利な情報も含めて中立に判断材料を示す」という方針で執筆しています。外注は目的ではなく、あくまで課題を解決するための手段のひとつです。この記事が、外注を検討し始めたばかりの担当者にとって、次の一歩を具体的に描くための助けになれば幸いです。
発注方式の選択肢についても記事を用意しています。ノーコード・ローコード外注の落とし穴、IT導入補助金でシステム開発はできるか、個人開発者・フリーランスに頼むのはあり？リスクと向き不向きも、発注方式を比較検討する際の参考にしてください。
フルスクラッチとパッケージのどちらを選ぶか迷っている方はフルスクラッチとパッケージ、どちらを選ぶ？、見積もり後にスケジュールの遅れが不安な方はなぜ開発は遅れるのか。納期・スケジュールの見方もあわせてご覧ください。
情報開示
うちシスなびは、Next.jsフルスクラッチ開発やAI駆動開発を手がける開発会社である株式会社ゼットリンカーが運営しています。「外注のはじめかた」カテゴリは、当社自身の受託開発事業と関わりが深い領域であるため、既製品やノーコードツールで十分に解決できるケースがあることなど、当社にとって必ずしも有利ではない情報も含めて中立的に記載するよう努めています。運営者情報・広告方針の詳細は、サイト内の運営者情報ページをご確認ください。
