共有リソースが共有されなくなったとき。

背景

急成長中のテクノロジー企業では、複数の事業部門と共有機能チームを組み合わせたマトリクス組織が採用されていた。

表面に現れた課題

個別の事業部門に配分されたエンジニアリング資源は、次第に組織横断で動かしにくくなり、事業部門は希少な専門人材を取り合っていた。

兆候

事業および機能のリーダーへのインタビューと、組織摩擦がキャパシティを消費している箇所のマッピングにより、共有リソースの事実上の私有化、リソースの所有と利用の分断、機能別KPIと事業デリバリーの不十分な連動が確認された。

問いの捉え直し

コミュニケーションの問題に見えた事象は、リソース・ガバナンスの問題であった。

診断

プロジェクト管理はスケジュールを追跡できても、事業横断のリソース競合を解決できず、組織の成長に伴い、経営層からの可視性がパフォーマンス評価に与える影響も大きくなっていた。診断は、マトリクス自体が誤ったモデルということではなく、機能させるために必要な仕組みが欠けているというものであった。

設計

提案では、既存の事業部門構造を維持したまま、共通のエンジニアリングおよびオペレーション資源のための共有能力層を加えた。小規模な事業フロントエンド、共有能力プラットフォーム、標準化されたコーポレート機能という3つの役割を分け、プロジェクト価値のスコアリング、リソース調停、二重のパフォーマンス責任、リソースの可視化という4つのガバナンス機構を提案した。さらに、プロジェクト貢献と機能上のパフォーマンスを分け、実運用データの蓄積に応じて再調整するための定期レビューも含めた。

二次的な論点

提案ではその限界も明示した。中央集約された共有能力層は別の政治的なリソースセンターになり得ること、定量係数にはなお判断が含まれること、時間記録は歪められ得ること、そしてパフォーマンス評価が完全に客観的になることはないことを記録した。

振り返り

設計の前提は、理論上完璧な組織を最適化することではなく、実際に実装可能な最善の組織を目指すことであった。