システム開発の外注前に整理すべき要件と確認ポイント

システム化したい業務はあるものの、専門用語や仕様書に落とし込めず、システム開発会社への相談を止めてしまうことがあります。しかし、初回相談の前に完成した仕様書を作る必要はありません。発注側がまず整理するのは、何の業務を、誰が、どの場面で使い、何に困っているのかです。

相談前に必要なのは、完璧な答えではなく、現在の業務と実現したいことを同じ資料で共有できる状態です。決まっていない項目は未決定と書き、技術的な判断をシステム開発会社へ提案してほしい項目と分けます。これにより、相談の入口で無理に断定せず、会話を進められます。

相談準備が難しくなる原因は、業務上の目的と、システムに必要な機能を同じ段階で決めようとすることです。要求定義は、どの業務をどう改善したいかという大きな目的を整理する段階です。要件定義は、その目的をシステムで実現するために必要な機能や条件を具体化する段階です。

発注側はまず業務の目的と現状を整理し、具体的な実現方法はシステム開発会社と確認しながら詰めます。

既存システムの刷新が関係する場合は、現行の資料と、業務を知る担当者の情報も確認します。資料が古い、担当者が限られている、例外処理が口頭でしか伝わらない場合、その状態自体が重要な前提です。分からないことを隠さず、調査が必要な項目として記録します。

相談前は、次の5つに分けてメモを作ります。

1. 業務の目的と現在の困りごと
2. 利用者、利用場面、関係する部門
3. 最初に解決する範囲と後回しにする範囲
4. 決裁者、業務責任者、現場確認者、相談窓口
5. データ、権限、許容できる停止時間などの条件

優先順位は、必須、重要だが後回しにできるもの、提案を求めるものに分けると、提案内容を比較しやすくなります。すべてを同じ優先度にすると、何を守るべきかが伝わりません。社内で決められない技術項目は「提案を求める」と明記します。

相談前のメモには、現状の業務フロー、既存システムやExcel、紙の情報源、困りごとが起きる頻度も添えます。

発注側の目的や優先順位が曖昧なまま相談すると、システム開発会社ごとに異なる前提で提案することになります。比較の基準がないため、説明の違いが良い提案の違いなのか、前提条件の違いなのか判断できません。

開発が始まってから現場の要望が追加されると、仕様変更として扱うべきものと、当初から必要だったものの区別も難しくなります。 また、社内の判断者が決まっていなければ、確認のたびに議論が振り出しに戻ります。

たとえば、現場は入力項目を増やしたい一方、管理部門は入力負担を減らしたいという場合、誰が業務上の優先順位を決めるかが必要です。判断者が不明なまま提案を受けると、システム開発会社へ伝える内容も毎回変わります。

失敗を防ぐには、相談前にすべてを決めるのではなく、決まっていること、検討中のこと、提案を求めることを分けて記録することが重要です。未決定事項には、誰がいつまでに決めるかも添えます。さらに、現場の例外処理や繁忙期の運用、既存帳票の保存方法も確認します。

通常時だけを前提にすると、導入後に「このケースはどうするのか」という追加要望が続きます。業務の流れを担当者へ聞き、判断が分かれる場面と、止められない業務を先に書き出すことで、要件整理の抜けを減らせます。

まず、業務の目的、困りごと、利用者、優先順位、判断者、既存システム、データ条件を一枚にまとめます。項目ごとに「決定」「検討中」「提案を求める」「調査が必要」と印を付けると、システム開発会社との初回相談で確認したいことが明確になります。社内で意見が分かれている場合は、意見の違いそのものを記録します。

相談前の整理が難しい場合は、要求整理サポートサービスを利用できます。相談の段階では、すべての専門用語を理解することより、自社の業務と判断条件を伝えられることが重要です。