Hub & Spoke & Hub

私たちがこのやり方で働く理由

• AI 時代のツールに適用される AI 以前のガバナンス。 AI 関連の仕事の量とスピードは、従来の機能向けに設計されたレビューの頻度を上回っています。解決策はガバナンスを減らすことではなく、スケールするガバナンスです。それは、全社にわたってレビュアーごとに対応するのではなく、CorpSec、Legal、Privacy のための中央インターフェイスを通じて提供されます。

• 機能間で不均一な AI ケイパビリティ。 一部の機能が先行する一方で、他の機能は遅れをとっており、その差は毎週広がっています。連携がなければ、より深い機会、つまり既存のフローに単に AI を注入するのではなく、仕事の進め方そのものを再構想する機会を逃してしまいます。

• ビジネスのコンテキストから遠すぎる中央集権チーム。 中央集権的な AI デリバリーは、孤立して解釈されると的外れなソリューションを生み出し、しかもそれが依頼から数か月後になることがよくあります。仕事のすぐそばに位置する埋め込み型のデリバリーは、より速く、より良い答えを生み出します。

• 明確な裁定者のないサイロ化した個人実験。 チームメンバーが独立して AI ツールを構築すると、作業の重複、一貫性のないアプローチ、そして優先順位付けの単一の窓口がないまま競合する P1 リクエストにつながります。エネルギーの向きは正しいのですが、それを流すチャネルが欠けているのです。

モデルを 1 段落で

スポークでつながれた 2 つの hub。プラットフォーム Hub（Enterprise AI）が AI ケイパビリティ（プラットフォーム、エンジニアリング、ガバナンス、標準）を所有します。各機能には埋め込み型のスポークである AI Transformation Owner（ATO）があり、Enterprise AI の AI Engineer とペアを組みます。機能内の Hub は Champion コミュニティ、つまり機能内の実務者によるピアネットワークです。ATO は、プラットフォーム Hub と機能内 Hub をつなぐ結合組織です。

モデルを 1 枚の図で

中央に 1 つのプラットフォーム Hub、機能ごとに 1 つの ATO スポーク、各機能内に 1 つの Champion コミュニティ。

3 つの役割

Enterprise AI（プラットフォーム Hub）

AI プラットフォーム、エンジニアリングのキャパシティ、ガバナンス、セキュリティレビュー、機能横断の標準を所有します。どの機能でも利用できるスキル、エージェント、インテグレーションを構築します。単一の機能の中のユースケースは所有しません。ただし、どのように（how） は所有します。つまり、最終的にどのチームが構築するかにかかわらず、ATO とパートナーを組んで、各ソリューションが従うべき技術的アプローチとベストプラクティスを形作ります。

ATO、AI Transformation Owner（スポーク）

機能内に埋め込まれたシニアな役割です。その機能の AI ロードマップを所有し、ユースケースを精査し、割り当てられた AI Engineer とパートナーを組んでそれらを提供し、機能のエグゼクティブスポンサーに価値を報告します。ATO は、Enterprise AI と機能をつなぐ、単一の説明責任を負う橋渡し役です。役割分担は右手／左手の関係です。ATO は 何を（what） と なぜ（why）（どの問題を、どの順序で解決するか）を所有し、それらの問題提起を Enterprise AI に持ち込みます。Enterprise AI は どのように（how） を所有します。ATO はまた、機能内で Champion や個々のコントリビューターによって構築される仕事のゲートとなり、それを中央集権的な戦略と標準に沿った状態に保ちます。役割の全体像は AI Transformation Owner ページをご覧ください。

Champion（機能内 Hub）

機能内のピアコミュニティで、サブチームごとに 1 名、時間の 5 〜 10% を充てます。Champion は最前線からユースケースを浮かび上がらせ、自分のチームでソリューションをパイロットし、チームメイトをコーチし、摩擦を ATO にフィードバックします。彼らは ATO の直属の部下ではなく、実践のコミュニティです。

仕事の流れ方

1. 提起（Raise）。 チームメンバーは独立して構築するのではなく、自分の機能を通じてアイデアを浮かび上がらせます。
2. トリアージ（Triage）。 ATO がビジネス成果とエグゼクティブの指針に照らして優先順位を付けます。
3. 探索（Scout）。 埋め込み型の AI Engineer が探索し、プロトタイプを作り、何が機能するかを実証します。
4. 提供（Deliver）。 小規模で焦点の定まったチームが、実証されたコンセプトを本番環境へと運びます。複雑さと必要とされる専門性に応じて、ビルドは割り当てられた AI Engineer、機能自身のエンジニアリングキャパシティ、または機能内の Champion やビルダーを通じて行われます。Enterprise AI は終始 どのように（how） を所有し、ATO は整合性のために機能内のビルドのゲートとなります。
5. 共有（Share）。 成功したソリューション、パターン、教訓は、他の機能で再利用できるよう Hub を通じてフィードバックされます。

構築の前に消費する。 何か新しいものを構築する前に、ATO と彼らが引き入れたビルダーは、Enterprise AI や他の ATO、他のチームがすでにリリース済みのものを確認し、何も合致しないか、既存のものがそのユースケースには本当に適さない場合にのみ新しく構築します。フェデレーテッドモデルにおける最大のリスクは、すべての機能がひそかに同じケイパビリティを再構築することです。まず既存のパターンに手を伸ばすことが、共有ライブラリを断片化させるのではなく積み上げていくことにつながります。

具体例

ある機能の Champion が、チームメイトが顧客向けの同種のメールを、異なるブリーフ向けに異なるフォーマットへと作り直すのに毎週おおよそ 6 時間を費やしていることに気づきます。摩擦の一部は彼女に直接持ち込まれ、一部は仕事のそばにいることで彼女が拾い上げます。彼女はそれを次の Champion 同期ミーティングで機能の ATO に提起します。

ATO は、今四半期に重要となる優先順位についてすでに機能のエグゼクティブスポンサーと足並みを揃えているため、このユースケースが戦略に沿っていることをすぐに見て取れます。このような小規模で明確に整合した依頼については、別途の承認ミーティングは必要ありません。彼女は仕事の優先順位を付け、次の定例同期でエグゼクティブスポンサーに共有します。より大規模、あるいは機能横断的な依頼は、リソースをコミットする前にエグゼクティブスポンサーに上げます。

ATO は機能の AI Engineer を早い段階で引き入れます。彼らの最初の仕事は構築を始めることではなく、ソリューションの形について合意することです。このケースでは、境界の定まったプロンプト駆動の Claude スキルで、機能のロールベースプラグインの中で配布し、インストール手順なしにすべてのチームメンバーが利用できるようにします。ATO が最初のパスをリードし、入力／出力のコントラクトとプロンプトの最初の草案を作成します。次に AI Engineer が洗練させ、より難しいプロンプトエンジニアリングを施し、評価用のハーネスをセットアップし、エッジケース向けにチューニングします。Champion が実際のフローで検証し、トーンの問題を見つけ、AI Engineer が再びチューニングします。1 週間で 2 回のイテレーション。

スキルはロールベースプラグインに組み込まれて配布されます。機能内のすべてのチームメンバーが翌朝にはそれを手にします。スキルが、機能全体に散らばった 200 個の個人プロンプトではなくプラグインの中に存在するため、次のイテレーションは安価です。1 回更新すれば、その日のうちに全員が恩恵を受けます。1 人の Champion の慢性的な悩みが、四半期ごとに改善する機能全体のケイパビリティになるのです。

意思決定権の一覧

機能 vs 部門

明確なサブ組織を持つ大規模で複雑な機能は、サブ機能レベルでスポークを必要とする場合があります。複数のサブ組織を持つ機能をまたぐ単一の ATO では、それぞれの領域のビジネスコンテキストから遠すぎて、信頼に足る優先順位付けの判断ができません。そして ATO は、本来意図された結合組織ではなく、すぐにもう 1 つの抽象化の層になってしまうでしょう。

より小規模、あるいはより一体的な機能は、機能レベルの単一のスポークでうまく機能できます。パイロットフェーズでは両方のアプローチをテストし、組織図ではなくデータが、適切なレベルがどこにあるかを決めます。原則はどちらの場合でも同じです。ATO は、信頼に足る形でユースケースを精査できるほど仕事のそばにいなければなりません。

より大きな視点

AI は、1 人あたりのアウトプット比率を根本的に変えました。AI ツールと明確なオーナーシップを備えた、小規模で適切に構成されたチームは、以前は 1 つの部門を要した仕事を今や提供できます。Hub and Spoke モデルは、単に AI ソリューションをより効率的に提供することだけが目的ではありません。それは、すべての機能が、すでに抱える人員のままで劇的に高い目標を狙えるようにすること、しかもそれを、ガバナンスが効き、連携が取れ、時間とともにサイロへと断片化するのではなく積み上がっていくケイパビリティを築く形で実現することが目的です。

関連

• Guiding Principles: 私たちが運営するすべての AI イニシアチブを形作る 5 つの原則。
• Operating Rhythm: チャネル、ケイデンス、意思決定権、エスカレーション。
• Prompts are Process: すべてのエージェントにオーナーが必要な理由。

ページのソースコードを見る - ページの編集 - please contribute.