DX推進を成功に導く組織体制とは？

はじめまして。AWS エンタープライズストラテジストのジョン クラークです。私が所属する エンタープライズストラテジーチームは、メンバーのほぼ全員が多種多様なエンドユーザー企業における CIO、CTO という経験を持っている特殊なチームで、IT ベンダーである我々 AWS とお客様（特に経営や意思決定に関わる役職の方）が共通のゴール、マインドセットで会話、コラボレーションすることを実現するためのいわば通訳のような役割をしています。ほぼ全員が元 CIO / CTOと申し上げましたが、唯一の例外が実は私です。私は Global トップ 500 にランクインしているトヨタグループ　アイシン精機、日産グループ会社など 20 年以上にわたり自動車業界で日系企業の米国社長を務め、経営に携わってきました。

その経験をもとに日々、日本そしてグローバルの CXO のみなさまとお話しをさせていただいていますが、今後このブログでは特にお客様が高い関心を持たれているテーマやよくいただくご質問、リクエストなどをみなさまにもご紹介していこうと思います。また、ご不明点、ご質問等ございましたらこちらよりお問合せ下さい。

今回ご紹介する記事は、「IT と事業部門との“コラボレーション”をどう推進すべきか？」について UK 在住の私の同僚で元マクドナルドの CIO である Phil Le-Brun が執筆した Organising for Data を翻訳したものです。

ネタバレになってしまいますが、実は“コラボレーション”という考えそのものを変える必要があります。IT と事業部門という別々の部門が必要に応じて手をつなぎ“コラボ”する、ということではなく、そもそも“全く同じ組織になる”必要がある、というのが我々からの提言です。

それでは、お楽しみください。

——————————————————————————————————————————————

「ベストプラクティスは大抵の場合、ベストではない」

―ピーター・ティール、起業家

私は一般的にベストプラクティスというフレーズが嫌いです。これ以上改善できない一つの真理が発見されたことを意味しているからです。それは自己満足を生み出し、思考と革新が止まる可能性があります。このことは組織モデルにも当てはまります。「世界トップクラスのベストプラクティスなチーム」を標榜する事例はよく拝見しますが、記述されている予算があまりにも少額なことに苦笑してしまいます。特定の問題やドメインについて、他人の組織モデルをコピーしようとするのは簡単ですが、文化と同じように、組織は会社特有のコンテキスト(事情や背景)に適合させる必要があるという現実を無視しているからです。

これに当てはまる顕著な例は、企業がデータを整理する方法です。その目的はシンプルです。データを実行可能な洞察や気づきに変換し、迅速かつコスト効率よくアクションを起こすにはどうすればよいのでしょうか。ここで紹介したいのは、あなたの組織のために考慮すべき3つの検証モデルです。（詳細はセンター・オブ・エクセレンスのブログに掲載）これらのモデルは、テクノロジーだけでなく、データサイエンティストが取り扱うような領域の側面にも適用されます。これらの検証モデルは、組織内で実際にどのように意思決定が行われるかに基づいており、一貫性と標準化よりも、データインサイトに基づいて行動を起こすことが優先される傾向にあることは予めご了承ください。

これらのモデルはすべて”hub-and-spoke”モデルのバリエーションです。 hub とは、一元化されたチームと一連の機能を指し、spoke は基幹業務 (LOB) または機能チーム内の機能です。多国籍企業の場合、hub は本社であり、spoke は個々の事業部門または国になる可能性が高い。hub は通常、データテクノロジーを標準化し、さらには利用率を標準化することで、規模とスキルの経済性を追求しています。spoke は機能を分散化して、顧客により近く、データを意味のあるアクションに変えることができる場所に近づけます。意思決定が主に LOB から推進される組織や、LOB が多様なニーズやビジネスを抱えている組織では、より多くの活動が spoke に押し込まれていきます。言い換えれば、これらのモデルは現実における組織内の意思決定力と共有事項を反映したものでなければなりません。

また、広範な一般化を行うのではなく、エンドツーエンドのデータプロセスの各側面をこのモデルにマッピングする必要があります。インサイトの生成、ガバナンス、データラングリング、データスチュワードシップ、価値実現などの側面は、”データ”を一元化するか分散化する必要があるかを判断するのではなく、それぞれ個別に検討する必要があります。

中央集権型モデル

このモデルでは、hub には大量のデータと分析リソースと、一元管理されたデータテクノロジーが含まれています。データ使用の優先順位と戦略は、一元的に決定されます。このモデルは、使用する共有サービスを持つ LOB または関数間で大きな共通性があり、LOB 間での差別化がほとんどない場合に最も適しています。LOB の機能は、通常、基本的なレポート作成に集中しています。データジャーニーを取り組み始めた企業は、LOBが独自のディープアナリティクスを推進するのに十分なデータリテラシーが得られるまで、データサイエンティストなどの専門的で希少なリソースの使用を最適化するために、このモデルを使用することがよくあります。

分散型モデル

このモデルでは、力の均衡は LOB 内にあります。LOB の組織は通常、それぞれ独自の分析能力を持ち、高度な自律性と原点に近い行動の実施を支援します。理想的に言うと、このような LOB が独自の分析に基づき必要な行動を行っている分散型組織であっても、データ技術プラットフォームは LOB に限定せずに会社全体として投資、確立、維持していくことが必要です。この場合、hub の役割は限られているため、hub 間のナレッジ共有を促進し、セルフサービス機能を提供するケースが多いです。

真の”hub-and-spoke”モデル

組織の大半は、私が説明した両極端の真ん中のどこかに合致する。中央集権型が許すスキルと規模の経済性、分散型機能がもたらす俊敏性を兼ね備えています。過度な集権化は、中央管理側が需要に対応できず、ボトルネックや不満が生じます。逆に過度の分散化は、支出の重複を招き、利用可能なデータや学習の非効率的な使用につながり、結果も遅くなります。これは時間とともに変化するバランスでもあり、定期的に評価する必要があります。

ここで話はグレーゾーンに入ります。通常、hubはセンターオブエクセレンス (COE) となり、LOB spokeが可能になります。モデルは、小規模な LOB チームによる大規模な意思決定 COE から、小規模なテクノロジー COE や大規模な LOB チームまで多岐にわたります。このようなモデルは、限られた分析人員や LOB の違いなど、組織の制約や複雑さに実用的に対処できます。

ここで重要なのは、hub と spoke の機能の適切なバランスを見いだし、環境とデータの成熟度の変化に合わせて調整することです。最初は、集権型モデルの場合と同様に、限られたスペシャリストリソースが hub に配置されている可能性があります。spoke にはレポート機能と分析機能が制限され、hub のデマンド管理プロセスによってより高度なリクエストが管理されることがあります。能力と理解が深まるにつれて、一部のスペシャリストリソースは spoke に移動し、恒久的にまたは一定期間、アクションに近づきます。いずれにせよ、これは hubと spoke 間の共感と知識の共有を確保するのに役立ちます。目標は、データドリブンなインサイトの数を増やし、そのインサイトを行動へと転換させることです。

何が問題なのか？

これらのモデルを振り返ると、それらが不十分に実装されているのを見るのは珍しいことではありません。私がここで観察する3つの典型的な失敗パターンは、組織的な目隠し、テクノロジー偏重指向、固定された考え方です。

組織的な目隠しとは、企業が意思決定文化の現実を無視し、意思決定が一元化されているとか、逆に当てはまるときにすべてのLOBに固有のニーズがあると信じる（または望む）ことを指します。多国籍企業における私の力の均衡で説明したように、失敗の典型例です。バーチャルチームをビジネスユニットや中央組織の代表者と連携させて、組織モデルの正しいバランスを管理することは強力なコンセプトであり、今後のブログ記事でさらに詳しく説明する予定です。

テクノロジー偏重指向では、テクノロジーに近視的に焦点を当てしまうことで結果、重要なデータを見逃してアクションを起こせない事態が起こります。トレーニングや変更管理に十分重点を置いていないツールは、必然的にアクションの欠如、不満、無数の競合する活動の発生につながります。テクノロジーは重要な役割を果たしますが、これで終わりではありません。

最後に、リーダーシップ、市場、顧客、外部からの圧力の変化により、組織は時間とともに変化します。会社を実体として表示することはできません。今日機能している組織モデルは、明日は適切ではないかもしれません。これらの変更や関係者からのフィードバックに基づいて、何が機能しているのか、何を微調整する必要があるのかを把握しておくと、これに対処できます。たとえば、どのタイプのリソースプロファイルが必要かを発見する必要があるデータへの最初の進出は、一元的に行うのが最善かもしれませんが、データリテラシーが普及するにつれて、機能は分散化されて高速化されます。

アプローチにかかわらず、データから価値を引き出し、テクノロジーや構造に関係なくデータの使用が支持されていることを確認するために、組織的に説明責任を負うシングルスレッドのリーダーを持つことは、強力なステップです。このリーダーはデータを所有する必要はありません。むしろ、データを使用して行動に移す文化を推進することに注力すべきです。結局のところ、組織における“データ問題”の大部分は、実際には文化的および組織的な問題です。

—Phil