社内コミュニケーション不足が要件定義を壊す

要件定義の失敗は、ベンダーとの認識のズレだけが原因ではありません。社内の関係者間での情報共有不足が、リリース直前に大量の追加要望を生み出します。社内でやっておくべきことを整理します。

よくある「社内バラバラ」の構図

システム開発のプロジェクトでは、社内のさまざまな立場の人が関わります。

問題は、この3者が要件定義の初期段階でしっかりコミュニケーションを取れていないケースがあることです。

IT担当者がベンダーと一緒に要件定義を進め、ある程度固まってきた頃に現場に見せると「こんな仕様は聞いていない」「この機能がないと使えない」という声が出てきます。さらにリリース直前に経営者が初めて内容を確認して「方向性が違う」となることもあります。

リリース直前の大量追加要望：現場担当者が完成間近のシステムを初めて見て、「やっぱりこれも必要」という追加要望が一気に出てきます。この時点での追加は、納期遅延や追加費用の原因になります。

受け入れ拒否：完成したシステムを現場が使い始めようとしても「使いにくい」「業務フローと合っていない」という理由で受け入れが進まないことがあります。極端なケースでは、現場がシステムを使わず以前のやり方に戻ってしまいます。

責任のなすりつけ：「そんな要件は聞いていない」「あのとき承認したはずだ」という水掛け論が発生し、社内の関係修復にエネルギーが取られます。

社内ヒアリングでは、立場によって引き出すべき情報が異なります。

経営者・管理職から聞くこと

経営者は業務の細部より「このシステムが会社にどう貢献するか」に関心があります。その期待値を早めに確認しておかないと、完成後のギャップが大きくなります。

現場担当者から聞くこと

現場担当者は日常業務の感覚を持っています。「当たり前すぎて言わなかった」情報の中に、重要な要件が隠れていることが多くあります。掘り起こすには、実際の業務を一緒に見ながら話を聞く「現場ヒアリング」が有効です。

IT担当者・管理部門が整理すること

社内コミュニケーションを機能させるために重要なのは、「いつ・誰に・何を確認するか」を計画に組み込むことです。

ヒアリング段階：要件定義の初期に、関係する全部門から話を聞く時間を取ります。「忙しいから後で」と後回しにするほど、後から出てくる要望が増えます。

中間確認：要件定義がある程度まとまった段階で、経営者・IT担当・現場担当が揃って内容を確認する場を作ります。この段階での認識ズレ修正は、まだコストが低い状態です。

最終承認：要件定義書が完成したら、関係者全員が内容を確認して署名（または明示的な承認）を行います。「見た・了解した」を記録に残しておくことで、後からの「聞いていない」を防ぐことができます。

一方で、すべての関係者に全情報を共有すればいいわけでもありません。

経営者に業務の細かい画面仕様を全部見せても判断できませんし、現場担当者にサーバー構成の話をしても混乱するだけです。「誰に何を確認してもらうか」を設計することが重要です。

社内コミュニケーション不足は、リリース直前の追加要望・現場の受け入れ拒否・社内の責任問題という形で表れます。経営者・現場担当者・IT担当者それぞれから必要な情報を引き出し、中間確認と最終承認の場を計画に組み込んでおくことが、社内起因のトラブルを防ぐ最も現実的な方法です。

要件定義は「ベンダーとの合意」だけでなく、「社内での合意」でもあります。