部署間連携の失敗から学ぶシステム思考 - 「決められない」問題を組織設計で解決する

はじめに

チームや部署を跨ぐプロジェクトで、技術的には正しい提案をしているのに、なぜか話が前に進まない。

このような経験は、多くのエンジニアが持っているのではないでしょうか。

私も最近、部署間連携プロジェクトで大きな失敗を経験しました。その振り返りを通じて見えてきたのは、「コミュニケーション問題」と思われがちな課題の多くが、実はシステムや組織設計の問題だということです。

この記事では、実際の失敗事例を通じて、部署間連携を成功させるための3つの原則と、問題を「個人のスキル不足」ではなく「システムの設計課題」として捉える視点を共有します。

失敗したプロジェクトの背景

ある日、マーケティングチームから緊急の相談を受けました。

「海外拠点のメンバーが、新しいシステムにログインできません。業務が完全に止まってしまいそうです」

調査すると、海外拠点は認証システム上で別組織扱いされており、セキュリティポリシーの壁を越えられないことが判明しました。加えて、旧システムのクローズ予定日までわずか2週間という状況でした。

この問題の本質は以下のようなものでした：

• 影響範囲: 海外拠点全体の業務停止リスク
• 技術的複雑さ: 全社セキュリティポリシーに関わる認証・権限の根幹課題
• 組織的複雑さ: 複数部署での合意が必要な大規模改修
• 時間的制約: 残り2週間という猶予のなさ

私が犯した2つの致命的ミス

ミス1：確度の低い見積もりで軽率にコミット

状況を聞いた私は、深く調査せずに「今週中に方針を出します！何とかなると思います！」と軽率にコミットしてしまいました。

しかし調査を進めると、2週間では到底終わらないことが判明。「認証・権限」という全社共通ポリシーに関わる問題の複雑さを完全に読み違えていました。

ミス2：信頼回復を後回しにした課題解決志向

見積もりミスが判明した時、私は慌ててプロジェクト責任者に相談を申し込みました。「状況認識を揃えて、対応方針を擦り合わせたい」と切り出しましたが、**「この場では何も決められない。上司同席で後日相談させてほしい」**と断られてしまいました。

ところが数日後、シニアマネージャーが同席した場では、全く同じ提案内容が驚くほどスムーズに合意されたのです。

なぜ同じ提案で結果が180度変わったのか？

同じ内容なのに、なぜ片方は拒絶され、片方は受け入れられたのか。この疑問が、今回最も重要な学びにつながりました。

シニアマネージャーの対応を詳細に観察し比較分析した結果、3つの決定的な違いが見えてきました。

違い1：関係性の回復 vs いきなり課題解決

私の失敗したアプローチ

• 見積もりミスの事実を伝え、すぐに対応方針を立てようとした
• 「状況認識を揃えて対応方針を決めたい」と課題解決に直行
• 相手の感情面（困惑、不安、失望）への配慮が皆無

シニアマネージャーの成功アプローチ

• 最初の数分間を完全に信頼回復に集中
• 「我々の不手際で皆さんにご迷惑をおかけして大変申し訳ありません」（明確な謝罪）
• 「対応がドタバタしてしまい、不安にさせてしまったことも申し訳ありませんでした」（コミュニケーション面の反省）

なぜこの違いが生まれるのか

• 信頼の前提条件: 既に見積もりミスで信頼が低下している状況では、論理的な情報や解決策を先に出すと「本当に大丈夫？」という疑念を深めるだけ
• 相手の心理状態: 信頼感や安心感がない状況では、どんなに良い提案でも受け入れが困難
• 意思決定の心理的ハードル: 関係性が回復すると、同じ提案でも「一緒に解決できそう」という前向きな気持ちに変化

違い2：判断枠組みの提供 vs 選択肢の丸投げ

私の問題あるアプローチ

• 各対応案のメリット・デメリットを並べて「どうしますか？」
• 相手の制約を十分に確認せずに選択肢を提示
• 技術的観点からの「できない理由」の詳細説明に集中

シニアマネージャーの効果的なアプローチ

• 構造化された選択肢: 画面共有で「1番が元の計画、2-4が代替案」と視覚的に整理
• 明確な評価軸: 「セキュリティ面で最も安全」「工数・コストを考慮すると非現実的」「時間制約を前提とした判断」
• 相手の制約確認: 「現地採用のメンバーが増えている状況」などの実情を確認してから現実的な提案

効果の差が生まれる理由

• 決定の枠組み: メリデメの羅列ではなく、「安全性」「現実性」「時間制約」という判断軸を設定
• 段階的合意: まず前提条件の合意を取ってから具体的選択肢を議論
• 協働的姿勢: 「こうしてください」ではなく「この選択肢について議論したい」

違い3：建設的な制約の伝え方 vs 技術詳細の説明

私の非効果的な伝え方

• 技術的詳細から「できない理由」を丁寧に説明
• 「認証・権限という全社共通ポリシーに抵触する...」と専門用語中心
• 再検討条件や代替案の提示が不十分

シニアマネージャーの建設的な伝え方

• 結論ファースト: 「技術検証の結果、そもそも実現が困難と判明しました」
• 相手目線の比喩: 「全く別の会社が、うちの資産に安全にアクセスする問題と同じです」
• 再検討条件の明示: 「セキュリティ要件、脆弱性診断、工数・コストを考慮すると非現実的」
• 即座の代替案: 「それで、別の代替案を用意してきました」

部署間連携を成功させる3つの原則

これらの失敗と成功例の対比から、部署間連携を成功させるための3つの原則が見えてきました。

原則1：関係性を回復してから課題解決に向かう

問題が発生した時こそ、関係性の回復を最優先にする

• ❌ 悪い例：事実情報や解決策をいきなり提示する
• ✅ 良い例：まず謝罪・共感・安心感の提供で信頼を回復する

実践のポイント

• 技術的な問題の前に、コミュニケーション面での不備を認める
• 相手の感情面（困惑、不安、失望）への配慮を最初に示す
• 「責任を持って解決します」という安心感を与える

信頼が低下している状況では、どんなに優れた提案でも「本当に大丈夫？」という疑念を深めるだけです。関係性が回復すれば、同じ提案でも「一緒に解決できそう」という前向きな気持ちに変わります。

原則2：相手の制約を組み込んだ判断枠組みを提供する

メリット・デメリットの羅列ではなく、明確な判断軸と現実的な選択肢を提示する

• ❌ 悪い例：各選択肢のメリデメを並べて「どうしますか？」と委ねる
• ✅ 良い例：評価軸を設定し、相手の制約を確認した上で現実的な提案をする

実践のポイント

• 選択肢を構造化して視覚的に整理する
• 「安全性」「現実性」「時間制約」など具体的な判断軸を明示する
• 相手の実情を確認してから提案する
• 「この選択肢について議論したい」という協働的な姿勢を示す

決定の枠組みを提供することで、相手は判断しやすくなり、段階的な合意形成が可能になります。

原則3：「できない」を建設的に伝える

制約を明確にし、代替案とセットで伝える

• ❌ 悪い例：技術的な詳細から「できない理由」を丁寧に説明する
• ✅ 良い例：結論ファーストで制約を明示し、代替案を即座に提示する

実践のポイント

• 結論を最初に明確に伝える（技術的詳細の前に）
• 専門用語を避け、相手が理解できる比喩や状況説明を使う
• 再検討条件（工数・コスト・セキュリティなど）を具体的に提示する
• 代替案を事前に用意し、「行き詰まり感」を与えない

「できない理由」で終わらず、「では、どうするか」への移行を迅速に行うことで、建設的な議論に転換できます。

システム思考で捉える「決められない」問題

今回の経験で最も重要な気づきは、「コミュニケーションの問題」と思われがちな課題が、実はシステムや組織設計の問題だということでした。

なぜこの問題は放置されていたのか？

「海外拠点のログイン問題」が事前に発見・解決されなかった理由を、システム設計の観点で分析すると：

• 権限の境界があいまい: 誰がこの問題を解決する責任を持つのか不明確
• 意思決定プロセスが未定義: 複数部署にまたがる問題をどう決めるかのルールがない
• エスカレーションパスが不在: 部署間で解決できない問題をどこに上げるかが不明
• 結果として「間に落ちる」: いずれの部署もオーナーシップを持ちづらい

根本原因：組織設計の問題

この状況を整理すると、組織設計において**「責任を持ちづらい領域」**が存在していました：

• マーケティングチーム：認証システムの技術的判断ができない
• エンジニアリングチーム：マーケティング業務の要件や制約を十分理解していない
• 両者の間：この種の問題を調整する明確なプロセスがない

システム設計としての解決アプローチ

重要な学び：問題が放置されている時や決めづらい時は、「組織設計や仕組みの問題」として捉えて解決する

今回のケースでは、以下の改善が必要です：

1. 責任境界の明確化：部署間にまたがる問題のオーナーシップ定義
2. 意思決定プロセスの体系化：クロスファンクショナルな課題のエスカレーション手順
3. 早期発見の仕組み：システム変更時の影響範囲チェックリスト
4. コミュニケーションプロトコル：緊急時の連絡・合意形成の標準化

エンジニアが陥りがちなコミュニケーションの罠

エンジニア組織の常識（論理的思考、技術的正確性、効率重視）で他部署とコミュニケーションを取ると、意図せず相手を困惑させてしまいます。

重要なのは「何を伝えるか」ではなく「どう伝えるか」

同じ提案内容でも、接し方ひとつで合意の難易度は天地の差。相手の立場や制約、感情面への配慮があって初めて、技術的な正確性が活かされます。

なぜ理論を知っているのに実践できないのか？

多くのエンジニアが「相手の立場に立つ」「感情面への配慮が重要」といったコミュニケーション理論を知っているにも関わらず、実践できない理由は3つあります：

1. 知識の「点在化」と血肉化の不足

• 理論を「情報」として蓄積しているだけで、「判断基準」として内在化されていない
• 実際のプレッシャーがかかる場面での訓練が不足

2. 自分の思考の癖への無自覚

• 無意識に「論理的正確性 > 感情的配慮」という価値観で行動
• 自分の価値観が「文脈依存」であることを認識していない

3. 状況判断のフレームワークの欠如

• 「いつ、どの理論を使うべきか」の判断基準がない
• 実際の場面での適用経験が少なく、パターン認識ができていない

まとめ：システム思考でコミュニケーション問題を解決する

部署間連携の課題は、個人のコミュニケーションスキルの問題として捉えられがちです。しかし、多くの場合、その根本原因は組織設計やシステムの問題にあります。

今回の最も重要な学び：問題が放置されたり、意思決定が困難になったりする時は、「システムや組織設計に問題がないか？」と問いを立てること

実践のための3つのアクション

1. 関係性ファーストの意識: 技術的な正しさよりも、まず信頼関係の構築・回復を優先する
2. 判断支援の姿勢: 選択肢を丸投げするのではなく、判断のための枠組みを提供する
3. システム視点の獲得: コミュニケーション問題を個人の問題ではなく、組織設計の問題として捉える

部署間連携は技術力だけでなく、相手の文脈に合わせたコミュニケーション力とシステム思考が成功の鍵を握っています。

エンジニアリング組織で培った論理的思考力を活かしながら、相手の立場や感情面への配慮、そして組織全体の設計視点を統合することで、真に価値のある部署間連携が実現できるはずです。

私自身、この失敗経験を通じて、技術的な課題解決だけでなく、人と人、組織と組織をつなぐ「システム」を設計する重要性を深く学ぶことができました。同じような課題に直面している方々の参考になれば幸いです。