要件定義

システム調達でつまずく原因の多くは、何を作るかを曖昧にしたまま事業者に発注し、納品後に「思っていたものと違う」と分かることにある。要件定義は、開発・調達の前に、業務で必要な機能、処理する量、応答性能、セキュリティ、他システムとの連携といった要求を漏れなく整理し、要件定義書として文書化する工程である。ここで定めた内容が提案依頼書（RFP）や契約仕様の土台となり、後工程での手戻りや追加費用の発生を左右する。発注者である自治体が要件をどこまで具体化できるかが調達の成否を分け、事業者任せにすると業務に合わないシステムを掴まされる。担当者にとっては、要件定義は技術者の作業ではなく、業務を最も知る担当課が主体的に関わるべき発注者の責務である点が要点となる。

発注者の責務

要件は業務の中身を知る担当課でなければ正確に書けない。どの帳票が要るか、例外処理がどれだけあるか、他システムとどう連携するかは、日々その業務を回している現場にしか分からない。事業者やコンサルタントの支援を受けてもよいが、最終的に何が必要かを決める責任は発注者にある。ここを事業者へ丸投げすると、業務の実態に合わないシステムや、使いもしない機能を盛り込んだ過大な仕様を招き、後で作り直しや追加費用が生じる。逆に必要な機能を書き落とせば、稼働後に手作業の穴埋めが残る。要件定義は発注者が主体的に関与すべき工程であり、外注できない判断がここに集中する。

後工程への影響

要件定義の精度は、提案依頼書・契約仕様・検収基準といった後工程すべてに連なる。要件は調達の前提となり、契約で約束する仕様の土台となり、最後に検収で「約束どおり作られたか」を確かめる物差しにもなる。要件があいまいだと、提案も評価も焦点が定まらず、開発の途中で「言った・言わない」の認識違いから仕様変更や追加費用が発生し、検収時には完成の合否をめぐる紛争の温床になる。逆に要件が明確であれば、後工程の判断はそこに照らして機械的に下せる。前工程での手間の惜しみが、後工程で何倍もの手戻りとなって返ってくる。