システム開発の失敗は、開発が始まってからではなく、発注する前の準備不足で決まっていることが少なくありません。目的があいまいなまま依頼する、社内で意見が割れたまま進める、予算の見通しがないまま見積もりを取る——こうした状態では、どんなに優秀な開発会社でも、期待に応えるのは難しくなります。本記事では、発注前に確認しておきたい項目を、テーマ別のチェックリストでまとめました。費用面はシステム開発の見積もり相場感：何にいくらかかるのか、内製と外注の判断は内製化と外注、コストで比較すると本当はどちらが得かもあわせてご覧ください。
チェック1：目的とゴール
システムを作ること自体は、目的ではありません。「何を解決したいのか」「どうなれば成功といえるのか」を、言葉にしておく必要があります。たとえば、「月末の集計作業を、5日から1日に減らす」のように、できるだけ具体的な状態で書くと、後から効果を測りやすくなります。
- 解決したい課題が、1〜3つに絞って言葉になっている
- 成功したかどうかを判断する基準（作業時間、ミスの件数、売上など）がある
- 「システムを作らない」選択肢（業務の見直し、既存ツールの活用）も検討した
チェック2：現状の業務の整理
今の業務の流れを把握していないと、システムのあるべき姿を描けません。誰が、どの順番で、どのツールを使って、どんな作業をしているかを、書き出してみましょう。とくに、例外的な対応（特別な取引先だけ別ルール、など）は、見落とされやすく、後から追加の費用につながります。
- 業務の流れを図や箇条書きで説明できる
- 現在使っているシステム・エクセル・紙の帳票の一覧がある
- 例外的な処理や、特定の担当者しか知らないルールを洗い出した
チェック3：社内の体制と合意
開発プロジェクトでは、発注者側にも、一定の時間と判断が求められます。要件を伝える、画面を確認する、テストをする、判断を下す、といった作業です。担当者が忙しすぎて対応できないと、スケジュールが遅れます。また、関係部署の合意が取れていないまま進めると、後から大幅な変更が発生します。
- プロジェクトの責任者と、日常的な窓口担当者が決まっている
- 関係部署の意見を集め、方向性の合意が取れている
- 決裁者に予算と目的の承認を得ている
- 担当者が、開発期間中に確保できる時間の目安がある
チェック4：予算と費用の考え方
予算は、開発費だけでなく、リリース後の運用・保守費用、サーバーなどのインフラ費用、社内の工数も含めて考えます。予算に余裕がない場合は、機能を絞って段階的に開発する方法もあります。
- 初期の開発費の上限の目安がある
- 保守・運用費用（月額や年額）も含めて、総額で検討している
- 補助金・助成金が使えるかを、確認した
- 追加の機能が必要になった場合の予備費を考えている
チェック5：要件の整理
すべてを細かく決める必要はありませんが、「必須の機能」と「あれば望ましい機能」の区別は、つけておきましょう。また、機能以外の条件（利用人数、セキュリティ、対応するスマートフォンなど）も、見積もりに影響します。
- 必須の機能と、希望の機能が区別されている
- 同時に使う人数、データの量、スマートフォン対応などの条件が分かる
- 既存システムとの連携や、データ移行の有無が整理されている
- セキュリティ・個人情報の取り扱い上の要件を確認した
チェック6：スケジュール
いつまでに稼働させたいのか、その理由は何か。繁忙期や決算期、法改正の施行日などは、変えられない期限になります。一方で、無理に短い期間を設定すると、品質の低下や費用の増加につながります。
- 稼働希望時期と、その理由が明確になっている
- テストや現場への展開（教育・移行）の期間も、見込んでいる
- 繁忙期とリリース時期が、重なっていない
チェック7：開発会社の選び方
複数の会社に、同じ条件で見積もりを依頼し、比較しましょう。金額だけでなく、提案の内容、類似の実績、担当者との相性、保守の体制なども、判断材料にします。極端に安い見積もりは、対応範囲が限定されていないか、確認してください。
- 2〜3社に、同じ条件で見積もりを依頼する予定である
- 評価の基準（価格、実績、提案内容、保守体制など）を決めている
- 類似の業種・規模での実績や、紹介を確認できる
- 要件の相談を、親身に受けてくれる担当者がいる
チェック8：契約と権利関係
契約書の内容は、後から変更しにくい部分です。成果物の著作権の帰属、検収の条件、納品後の不具合への対応（契約不適合責任）、追加開発の費用の扱い、秘密保持などを、事前に確認しましょう。
- 契約形態（請負・準委任）と、それぞれの責任範囲を理解している
- ソースコード・設計書の権利と、納品物の範囲を確認した
- 検収の基準と、期間が明記されている
- 仕様変更が生じた場合の、費用・期間の取り扱いが決まっている
チェック9：リリース後の運用・保守
システムは、リリースしてからが本番です。不具合が起きたときの対応窓口、定期的なアップデート、機能の追加など、運用の体制と費用を、発注の段階で確認しておきましょう。担当者の異動や退職に備えて、ドキュメントの納品も依頼しておくと安心です。
- 保守の範囲・対応時間・費用が、見積もりに含まれている
- 障害時の連絡先と、対応の流れが決まっている
- 設計書・操作マニュアルなどのドキュメントが、納品物に含まれる
- 運用を担当する社内の担当者が決まっている
発注準備を、いつまでに終えるべきか
発注の準備にかける時間は、プロジェクトの規模によって異なります。小規模なシステムでも、目的の整理や社内の合意形成に、数週間はかかるのが一般的です。開発会社への相談は、準備が整うのを待たず、早めに始めて構いません。たとえば、目的と課題が整理できた段階で相談し、要件の固め方や、進め方について助言をもらうと、無駄な手戻りを減らせます。逆に、準備不足のまま、スケジュールだけを先に決めてしまうと、後から無理が出ます。稼働の希望時期から逆算して、準備・選定・開発・テスト・展開の各段階に、必要な期間を見積もっておきましょう。
チェックリストの使い方
上のチェックリストは、すべてにチェックが入らなくても問題ありません。むしろ、チェックが入らなかった項目を、「これから決める事項」として一覧にし、開発会社との打ち合わせの議題にすることが、有効な使い方です。複数の担当者で、それぞれ項目を確認し、認識のズレを話し合うのもおすすめです。
よくある質問
Q. 準備をすべて整えてからでないと、相談してはいけませんか？
A. そんなことはありません。要件が固まっていない段階で、相談を持ちかけると、課題の整理から一緒に取り組んでくれる開発会社もあります。ただし、目的と現状の課題は、できるだけ言葉にしておくと、話が早く進みます。
Q. チェックの項目が、半分も埋まりません。
A. 初めて発注する場合は、そうなるのが普通です。埋まらない項目は、「開発会社と一緒に決めていくこと」として整理しておけば十分です。
まとめ
発注前の準備は、目的、現状業務、社内体制、予算、要件、スケジュール、会社選び、契約、運用保守の9つの観点で確認できます。すべてを完璧にそろえる必要はありませんが、未確定の項目を把握しておくだけでも、開発会社との話し合いが、格段に進めやすくなります。
