発注前に社内で決めておくべき5つのこと｜目的・予算・体制・期限・優先順位

システム開発の発注前の準備で、社内で決めておくべきことは「目的・予算・体制・期限・優先順位」の5つです。この5つが決まらないまま開発会社に相談すると、提案や見積がぶれ、比較も判断もできなくなります。この記事では、5項目それぞれの決め方と、短時間で整理する進め方を解説します。

システム開発の発注前の準備で決める5つの項目

最初に全体像を示します。5項目すべてを完璧に決める必要はありません。「決まっていること」と「まだ決まっていないこと」を分けて伝えられれば十分です。

以下、順に説明します。

開発の目的と解決したい業務課題を言葉にする

目的は「システムを作ること」ではありません。「どの業務の、何を、どう変えたいか」です。たとえば次のように書きます。

• 紙で受けている申込を、月の処理時間が半分になる形にしたい
• 担当者が異動しても、社内の別の部門が保守できる仕組みにしたい
• 既存の顧客に定期的に接点を持ち、再来店を増やしたい

ここで役立つのが、アイデアを「課題」「アプローチ（解決の範囲と方法）」「機能」の3つに分けて書く方法です。「会員アプリを作りたい」は機能の話です。その手前に「既存顧客との接点が切れている」という課題があり、「アプリかLINEか会員サイトか」というアプローチの選択があります。課題から書けば、開発会社はアプローチから提案できます。

あわせて、成功の基準も決めます。会員数、処理時間、問い合わせ件数など、測れるものを1つか2つ選びます。基準があれば、完成後に「作ってよかったか」を社内で評価でき、次の投資の判断材料にもなります。

予算の上限と、開発費・運用費の分け方

予算は「いくらかかるか教えてほしい」という状態のまま相談しないことが大切です。上限が分からないと、開発会社は最大構成と最小構成のどちらで提案すべきか判断できません。

決めておくべきは次の3点です。

1. 今期に出せる上限額: 稟議や年度予算の制約を含めて決める
2. 初期費用と月額費用の分け方: 開発費とは別に、サーバーなどのインフラ費、保守費、外部サービスの利用料が毎月かかる
3. 段階ごとの予算: 最初は小さく始め、効果を見てから次の予算を出す、という分け方も選べる

月額費用は見落とされがちです。見積をとるときは、初期費用と月額費用を分けて出してもらうよう依頼してください。費用の全体像はシステム開発の費用相場で解説しています。

社内の担当者と意思決定者の決め方

体制で決めるのは、少なくとも次の3つの役割です。

担当者が兼務の場合でも、定例の時間枠は先に押さえておきます。開発会社からの質問に数日答えられないだけで、工程は止まります。また、意思決定者が打合せに一度も出ないまま進むと、終盤で「そもそも違う」と覆されることがあります。重要な節目には同席してもらいましょう。

期限と、Must／Wantの優先順位づけ

期限は理由とセットで決める

期限には「なぜその時期なのか」を添えます。繁忙期の前、年度の切り替え、補助金の事業期間など、理由が分かれば開発会社は範囲を調整する提案ができます。導入したい月から逆算し、稟議と開発の期間を差し引いて、いつまでに発注すべきかを確認してください。

優先順位はMustとWantに分ける

機能は「Must（初回リリースに必須）」と「Want（あると良い、後から追加できる）」に分けます。判断に迷ったら「この機能がないと業務が回らないか」を問います。回るならWantです。

Wantを初回から外せば、費用と期間を抑えられます。外したWantは「第2期の候補」として一覧に残しておけば、捨てたことにはなりません。

5項目を短時間で整理する進め方

5項目の整理に、長い会議は必要ありません。次の順番で進めれば、短い打合せを数回重ねるだけで形になります。

1. 担当者が下書きを作る: 先の表の5行を埋める。分からない欄は「未定」と書いてよい
2. 意思決定者とすり合わせる: 目的と予算の上限だけは、この場で決めてもらう
3. 現場の代表者に機能を聞く: 「ないと業務が回らない機能」を挙げてもらい、Mustの候補にする
4. 未定の項目を一覧にする: 誰が、いつまでに決めるかを書いておく

未定の項目が残っていても、相談は始められます。むしろ「何が決まっていないか」を開発会社に伝えれば、決め方の提案を受けられます。5項目を1枚にまとめた資料は、そのまま相見積の共通資料にも使えます。

受託開発の現場から

受託開発の現場では、発注前の整理を手伝う場面が多くあります。提案の場で実際に行われている進め方を紹介します。

最初に「今回の目的」を一文で確認する

打合せの冒頭で、システム化の目的を発注者に一文で確認する進め方が有効です。ある企業では、目的は機能追加ではなく「担当者が離れた後も、引き継ぐ部門が扱えるように仕組み化すること」でした。目的がこう定まると、技術の選び方や資料の残し方まで変わります。

「必要な機能」と「欲しい機能」を分けて答えてもらう

ある受託開発会社の提案では、ヒアリング結果を「目的／ゴール／現状の課題／必要な機能／欲しい機能／予算（初期・月額）／スケジュール」の表に整理します。必要な機能は初回必須、欲しい機能は段階追加に回し、優先度の高・中・低は発注者の回答で確定させます。

顧客データのマスターをどこに置くかを先に決める

新しいアプリやツールを足すたびに顧客情報が分散する例は少なくありません。既存のどのシステムを顧客情報のマスター（正となるデータの置き場所）にするかを先に決め、新しいアプリはそこを参照する構成にするのが有効です。

次回までの宿題に「何が決まるか」を書き添える

発注者に依頼する準備事項（月間の業務件数、現物の帳票、既存システムのデータ出力仕様など）には、それぞれ「これが分かると何が決まるか」を併記しておくと効果的です。社内で資料を集める人が、目的を理解して動けるようにするためです。

まとめ

• 発注前に決めるのは、目的・予算・体制・期限・優先順位の5つ
• 目的は「課題」「アプローチ」「機能」に分けて書くと、提案の幅が広がる
• 予算は上限額を決め、初期費用と月額費用を分けて考える
• 担当者・意思決定者・現場の代表者の3役を決め、定例の時間枠を確保する
• 機能はMustとWantに分け、Wantは第2期の候補として残す

5つのうちいくつかが決まっていない段階でも相談はできます。FastProposal の無料AI相談では、質問に答えるだけで案件の整理と費用の目安を数分で確認できます。決まっていない項目がどこかを把握するところから始めてみてください。