他部署に期待するな：ビジネスサイド連携の防御的アプローチ

エンジニアリング組織を率いていると、自チーム内のマネジメントと同じくらい、セールスやPdMといった他部署（ビジネスサイド）とのコミュニケーションに時間を使うことになります。

ここでも、厄介なトラブルの温床になるのが「相手への無自覚な期待」です。

結論から言います。他部署とのやり取りにおいて、相手に何かしらの「配慮」や「察し」を期待することは明確な間違いです。

他部署は、自分たちとは全く異なる目的と評価基準で動いている「別のシステム」のようなものです。外部のシステムに対して「空気を読んで都合のいいデータを返してくれるだろう」と期待して連携部分を作る人はいませんよね。他部署との連携もそれと全く同じです。

今回は、他部署に対して「期待をかけてはいけないもの」と、その際のスタンスについて整理します。

期待をかけてはいけないもの

ビジネスサイドとのやり取りでストレスを抱える原因のほとんどは、エンジニア側が勝手に以下の要素を期待し、それが裏切られて感情的なトラブルを起こしていることに起因します。

1. 技術的な難易度や工数の「察し」

「これくらいの実装の重さや影響範囲は、言わなくてもある程度察してくれるだろう」という期待は、完全に間違っています。

なぜ期待してはいけないのか？ ビジネスサイドはシステムの内部構造を知りません。彼らには裏側にあるデータの構造変更や、既存の仕組みへの影響が見えていないだけです。察しに依存するのではなく、なぜ時間がかかるのかを相手の言葉（売上やスケジュールへの影響）に翻訳して明示的に伝えるのが正しいコミュニケーションです。

2. 無茶な要望に対する「ガード」

「開発側が忙しいのだから、顧客からの無茶な要望はセールス側で上手く断ってくれるだろう」という期待もしてはいけません。

なぜ期待してはいけないのか？ セールスの目標は「売上を作ること」や「顧客を満足させること」であり、開発チームの安定稼働ではありません。セールスがどんな要望を持ち込んできても開発が破綻しないように、「仕様変更を受け入れるための明確なルール」や「これをやるなら、別の機能は削りますという条件提示」といった、開発側でのしっかりとした防波堤を築いておく必要があります。

3. ドキュメントを渡しただけの「内容の確認」

「開発した内容やリリースの詳細について、丁寧な資料を作って渡したのだから、しっかり読んで意図を理解してくれるだろう」という期待も捨てるべきです。

なぜ期待してはいけないのか？ ビジネスサイドのメンバーは、それぞれの役割に応じた「自分の関心事」にフォーカスして資料を読むため、開発側が本当に確認してほしいポイントとはズレた部分を確認してしまうことがよくあります。 資料を渡しただけで確認が完了したと期待するのではなく、たとえ資料の内容をそのままなぞるだけであっても、対面（あるいはオンラインミーティング）での説明会を開くのが確実です。ドキュメントはあくまで補助であり、最終的な認識のすり合わせは直接のコミュニケーションで行うという前提に立つ必要があります。

期待を捨て、明確な合意を結ぶ

他部署とのコミュニケーションにおいて、「相手の配慮に期待する」というのは、希望的観測に基づく危険な仕事の進め方です。

他部署との連携で身を守るための基本は、「トラブルを前提とした防御的なアプローチ」です。 相手が悪意を持っているわけではなくても、予期せぬ要望やスケジュールの遅延、認識のズレは必ず発生します。それらを「期待外れだ」と非難するのではなく、最初から開発側がパニックにならないように責任の境界線を引くことが求められます。

「期待」という曖昧なものに頼るのをやめ、システムの仕様書のように「いつまでに、何を、どのような形式で渡すか」、そして「それに違反した場合はどういう対応になるか」という明確な合意（ルール）を結ぶ。

他部署との連携で生じる摩擦は、相手に期待することをやめ、ルールを厳格に定義することで、その大半を冷静に処理可能な状態へと落とし込むことができます。