システム開発を発注する前に決めておく10のこと — 社内準備チェックリスト

システム開発の発注は、開発会社を選ぶ前の段階で決まる部分が非常に多いといわれます。どれだけ実績のある開発会社に依頼しても、発注側の社内で目的や体制が固まっていなければ、要件の後戻りや追加費用、稼働時期の遅れといった問題が起きやすくなります。ここでは、発注に着手する前に社内で決めておきたい10の項目を、チェックリスト形式で整理します。発注全体の流れについてはシステム開発の発注ガイドも参考にしてください。

開発会社に相談してから決めればいい、と考える経営者も少なくありません。しかし開発会社は魔法使いではなく、発注側が示した情報の範囲でしか提案や見積もりを組み立てられません。目的や体制が曖昧なまま発注プロセスが進むと、開発の途中で「実はこういう要望もあった」という追加要件が次々に出てきたり、社内の誰が最終判断を下すのかが定まらず意思決定が滞ったりします。こうした状態は、いわゆる丸投げに近い進め方になりやすく、結果として費用や納期に大きな影響を及ぼします。

社内準備が不十分なまま発注すると、代表的には次のような問題が起こりやすくなります。まず、目的があいまいなために開発会社ごとの提案の方向性がばらばらになり、比較検討が難しくなること。次に、現場の実際の業務がヒアリングされないまま仕様が固まり、リリース後に「これでは使えない」という声が上がること。さらに、予算レンジを伝えていなかったために、想定より大幅に高い見積もりが出て発注自体が白紙に戻ること、などです。こうしたパターンの詳細はシステム開発の失敗あるあるでも取り上げています。

10項目の中でも、予算レンジ・保守の体制・効果の測り方の3つは、発注段階で見落とされがちです。予算レンジについては、正確な金額でなくても「上限としてこのくらい」という感覚を社内で共有しておくだけで、開発会社との対話が格段にスムーズになります。予算を明かさないまま進めると、見積書を受け取ってから初めて金額の妥当性を判断することになり、比較や交渉の材料が乏しくなります。

保守の体制も、開発が完了した後の話として後回しにされがちですが、実際にはシステムが稼働してからの方が長い期間続く重要な要素です。不具合対応や軽微な改修を誰が担当するのか、開発会社に保守契約として依頼するのか、社内で対応できる範囲を決めておくのかを、発注前の段階である程度想定しておくと、稼働後の混乱を避けやすくなります。

効果の測り方を決めていないと、システムを導入した後に「結局、投資として良かったのか」を検証できません。作業時間の削減、入力ミスの減少、問い合わせ対応件数の変化など、自社の状況に合った指標を事前に1〜2個決めておくことで、導入後の振り返りや次の投資判断がしやすくなります。

- 社内キックオフを行う: 責任者・現場担当を集め、目的とスケジュール感を共有する
- 現状業務を洗い出す: 業務フロー図や困りごとリストを簡単でよいので作成する
- 10項目をシートに整理する: 本記事のチェックリストをたたき台に、社内資料としてまとめる
- RFPや依頼内容として文書化する: RFP・要件定義入門を参考に、A4 1〜2枚程度にまとめる
- 複数社に相談・見積もり依頼を行う: 整理した内容をもとに、条件をそろえて比較する

システム開発の発注は、開発会社選びよりも前の「社内準備」の質によって、その後の進みやすさが大きく左右されます。今回紹介した10項目——目的の言語化、現状業務の棚卸し、責任者と現場担当の任命、予算レンジ、優先順位、既存データの所在、セキュリティ要件、稼働希望時期、保守の体制、効果の測り方——を一通り確認し、社内で言語化しておくことが、スムーズな発注への近道になります。発注全体の流れはシステム開発の発注ガイド、要望を伝える文書の作り方はRFP・要件定義入門もあわせてご覧ください。