はじめに
情シス部門やIT推進部門に配属されると、「自分はエンジニアとしての技術力が足りないのではないか」という不安を持つ方が少なくありません。周囲にエンジニア出身者やSIerからの転職者がいると、なおさらこの不安は強くなります。しかし、発注側の担当者として本当に求められる能力は、プログラミングやインフラ構築といった技術力そのものではありません。
発注側に求められるのは「翻訳する力」
発注側の担当者の仕事は、自らシステムを作ることではなく、現場の業務課題をベンダーが理解できる形に翻訳し、ベンダーからの提案を現場が判断できる形に翻訳し直すことです。現場の言葉（業務用語、暗黙の前提）とベンダーの言葉（技術用語、実装上の制約）の間に立ち、両者が噛み合う形に変換する、いわば通訳の役割です。
例えば現場から「もっと早く処理が終わるようにしてほしい」という要望が出たとき、これをそのままベンダーに伝えても、ベンダーは何を基準に「早い」と判断すればいいかわかりません。発注側の担当者が「現状何秒かかっていて、何秒以内に収まれば業務上支障がないのか」という具体的な基準に翻訳して初めて、ベンダー側も実現可能な提案を組み立てられます。
この役割に必要なのは、コードが書けることではなく、現場の業務を深く理解していること、そしてITプロジェクトがどのような型で進むのかという共通言語を知っていることです。
技術力より重要な3つの力
発注側として実務で特に重要になるのは、次の3つの力です。
- **業務理解力**：自社の業務がどう回っているか、現場に深く入り込んで理解する力
- **構造化力**：曖昧な要望を「何を・なぜ・いつまでに」という形に整理し、ベンダーに伝えられる要件に変換する力
- **判断力**：ベンダーからの提案や見積もりが、自社の目的・予算に照らして妥当かどうかを判断する力
これらはいずれも、プログラミングスキルとは異なる種類の能力です。もちろん技術の基礎知識はあるに越したことはありませんが、「技術がわからないから発注側は務まらない」というのは誤解です。むしろ技術的な細部にこだわりすぎると、ベンダーの専門領域に過度に踏み込んでしまい、本来発注側が果たすべき役割がおろそかになることもあります。
技術知識は「最低限の地図」で十分
発注側に必要な技術知識は、専門家レベルの深さではなく、プロジェクト全体の地図を把握できる程度の広さです。「このシステムはどういう構成要素でできているのか」「この作業はどのくらいの工数がかかるものなのか」という感覚を持っていれば、ベンダーの説明についていけますし、明らかにおかしい提案にも気づけます。
具体的には、サーバー・データベース・ネットワークといった基本構成の役割、要件定義から本番稼働までの大まかな工程、見積もりの一般的な相場観——この3つを押さえておけば、実務上はほとんど困りません。細部の実装方法まで理解する必要はなく、そこはベンダーの専門領域であり、発注側が踏み込みすぎると、かえって役割分担が崩れてしまいます。
まとめ
発注側担当者に求められるのは、エンジニアとしての技術力ではなく、現場とベンダーの間を橋渡しする翻訳力、曖昧な要望を構造化する力、提案を判断する力です。技術知識は専門家レベルではなく、プロジェクト全体を把握できる地図程度で十分です。「技術がわからないから」と委縮する必要はなく、むしろ業務理解と構造化の力を磨くことに時間を使う方が、発注側としての価値を高めることにつながります。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント