システム発注の評価軸が変わる中で、Web担当者が発注側として持つべき仕様設計力

AIによるコード生成の活用が進むことで、Webシステム開発の発注では、工数だけで費用や価値を判断しにくい場面が増えています。成果を基準に評価する場面では、発注側が業務課題や期待する成果を仕様として整理する力が重要になります。

本記事では、Web担当者が発注側として押さえておきたい仕様設計力の考え方を解説します。

Webシステムの開発を外部に発注する場合、従来は「何人のエンジニアが何ヶ月かかるか（人月）」を基準に費用を見積もる方法が一般的でした。この構造は、開発工数と費用が直接対応するため、発注側にとって費用の根拠を把握しやすいという側面があります。

しかし、AIによるコード生成が実務に組み込まれることで、同じ機能を実装するために必要な工数は変わりつつあります。開発会社がAIを活用して実装工数を削減できる場合、工数ベースの費用設定では実態とずれが生じることがあります。

この変化を受けて、「何人月かかったか」ではなく「どのような成果が出たか」を基準に費用を評価する方向へ、契約・評価の形が移行しつつあります。この傾向は、受注側（開発会社）だけでなく、発注側（Web担当者）の役割にも影響します。

工数ベースの発注では、発注側は「要件を伝える」ことが主な役割でした。「何人月かかるか」という見積もりを受け取り、承認するプロセスが中心でした。

成果ベースの評価に移行すると、「どのような成果を期待するか」を発注側が明確に定義する必要があります。成果の定義が曖昧な状態で発注すると、受注側が提示した成果が発注側の期待と異なる場合に、評価の基準がなく判断しにくくなります。

この状況において発注側に求められるのは、「仕様をこちらから提案・整理して発注できる力」です。ベンダーから提案された仕様を承認するだけでなく、「この業務ではどのような機能が必要か」「どのような条件を満たしていれば成果といえるか」という定義を、発注側が持っておく必要があります。

仕様を提案できる発注者とは、業務上の課題・目的・条件を、システムや機能の要件として言語化できる担当者です。具体的には、以下のような整理ができている状態を指します。

• 現在の業務フローのどの部分に、どのような問題があるかを把握している
• その問題をシステムで解決した場合、何がどのように変わるかを定義している
• 解決策として考えられる機能の条件・制約を明示している

この整理がある状態で発注すると、受注側はより精度の高い提案をしやすくなります。また、受け取った提案に対して「自社の要件に合っているか」を判断できるため、手戻りを減らせます。

仕様を整理する力は、業界・業務の経験と、システム開発の基本的な理解の組み合わせで高まります。

業務経験が長い担当者は「現場で何が起きているか」を把握していますが、それをシステムの要件として言語化する経験が少ない場合があります。一方、システム経験が豊富でも、業務の細かい例外や優先順位を把握していないと、要件が抽象的になることがあります。

両方の視点を持つ担当者が要件整理を担うか、業務担当者とシステム担当者が協力して要件整理を行う体制があると、仕様の精度が高まります。

AIの活用が進む開発環境では、工数ベースの評価から成果ベースの評価への移行が進みつつあります。この変化は、発注側のWeb担当者が「仕様を整理・提案できる力」を持つことの重要度を高めます。

仕様を整理できる状態であることは、開発会社に対して精度の高い発注ができるだけでなく、社内での承認プロセスや、完成したシステムの評価においても判断基準になります。

「仕様を整理しなければならないのはわかっているが、社内にそれができる担当者がいない」「何をどこまで決めれば発注できる状態になるのか判断できない」という状況の場合は、ぜひLYZONへご相談ください。
ヒアリングを通じて、課題と要件のアウトラインを整理するところからご支援可能です。