どのようにして、どんなチームサイズにも適したデータサイエンスの戦略を構築するか

どんなチームサイズでも適したデータサイエンス戦略の構築方法

変化に対して迅速かつ柔軟な文化と実践を作り出す

変化に対して迅速かつ柔軟な文化と実践を作り出す

もし、あなたが「データサイエンス戦略を作り上げる」という自由度の高い指示を受けたデータサイエンスのリーダーであり、具体的な指示が少ない場合、この記事はあなたの助けになるでしょう。以下の内容をカバーします：

• 戦略とは具体的に何を意味するのか：単なる計画か、ロードマップか、それともそれ以上、それ以下なのか？このセクションでは、戦略を構築するときに何を構築しているのかを具体的に説明します。
• この概念が実際の組織的なコンテキストにおけるデータサイエンスチームにどのように適用されるのか？ここでは、戦略の概念がデータサイエンスにどのように適用され、戦略が適用される具体的な内容について詳しく調べます。
• 実際にその戦略を作成する方法。

途中で、R&Dにおける戦略のアプローチから多くのアイデアを借りることになります。それはデータサイエンスと同様の重要な課題を抱えているからです：革新の使命と、探求を求める際に増加する不確実性。最後にまとめると、明確な戦略の定義と、どんな規模の組織に対しても戦略を作成するための役立つプロセスが得られるでしょう。

戦略とは何か？

もしあなたが私と同様で、素敵なMBAを持っておらず、ビジネス戦略のセミナーを受けたことがない場合、”データサイエンス戦略を開発してください”と誰かに頼まれたときに具体的に何を求められているのかに戸惑うかもしれません。そして初めの検索ではあまり役立つ情報が得られないかもしれません。Three C’sモデル（顧客、競合他社、会社）のような古典的で強力なフレームワークは、企業がどこで競争すべきかを決定する際には完全に理解できるものですが、機能やチームに適用すると、概念を無理に引き伸ばしているような感じがします。

もしあなたが私と同じような場合、Lords of StrategyやThe McKinsey Wayといった本を読むことでかなり深い読書の旅に出ることになるかもしれません。（アフィリエイトリンク）前者は魅力的なビジネス史の著作であり、後者は名門ファームの成功したコンサルタントの経験から抽出された技術の役立つコレクションです。しかし、この質問に対する即答は得られません。戦略の定義の混乱は私の経験でも現れており、何度か戦略の要求が「次の数ヶ月の計画は何ですか？」という形で簡略化されていました。

• テキストと画像の検索を行うNodeJS AIアプリを構築する
• 「人工知能を用いたIoTセキュリティの強化に向けた包括的アプローチ」
• 「AIデータ統合とコンテンツベースのマッピングによる未来のナビゲーション」

戦略の非常に役立つ定義の一つは、Gary Pisano氏のR&D戦略に関するワーキングペーパーによるものです。「戦略とは、競争に勝つための行動パターンへのコミットメントに過ぎない」というものです。この定義の美しさは、組織のあらゆるレベルと目的に適用できることです。あらゆる種類や規模のチームが、競争の努力に貢献し、それらの努力に焦点を当てるために使用する行動パターンを定義し、宣言することができます。

「戦略とは、競争に勝つための行動パターンへのコミットメントに過ぎない。」

―Gary Pisano

Pisano氏は、良い戦略の3つの要件を挙げています：一貫性、一体性、および整合性です。戦略は、望ましい目標に寄与する一貫した意思決定を行うのを助けるべきであり、組織のあらゆる隅々において遠隔地に分散した戦術的な意思決定を統合するのに役立つべきであり、また、ローカルな行動をより大きな集団の努力に合わせるべきです。

最後に、それらはすべて、競争において優位性を提供するという仮説に基づいています。Pisano氏の有益な例として挙げられているのが、Appleです。「消費者のデジタルワールドにおいてシームレスに統合された使いやすく美しい製品を開発する」という戦略は、「これらの特徴を持つ製品に顧客が大幅に高い価格を支払ってくれる」という仮説に基づいています。

本質的には、この定義の下では、すべての戦略は意思決定の論理を包括した賭けです。それらはすべての関係者に集合的な取り組みを支援する行動を特定する手段を提供します。

私たちはこの戦略の定義を採用し、データサイエンスが私たちの組織に価値を付加する方法と、その価値を追求する際のパターンについて、私たち自身の核戦略的仮説を定義しようと努めます。さらに、親組織が独自の戦略を持っていることを前提とし、この入力はアライメントの第三のテストを適用する際に重要となります。最終的な戦略の形式を定義した後、その範囲を限定することに注力します。

データサイエンスとは何か、そしてこの戦略の概念はどのように適用されるのか？

私の友人に私がどれだけ楽しいかを思い出させるために、同じテキストメッセージ「データサイエンス戦略を聞いたときに何を思い浮かべますか？」をいくつか送りました。回答は、データインフラストラクチャやMLOpsに関する非常に熟考されたポイントから、質問の曖昧さに対する健康な反応（私は見られていると感じます）、カラフルな「無意味」と「理想の仕事」までさまざまでした。

小さなサンプルですが、経験豊富なプロダクトマネージャーやスタートアップと大企業の両方で働くデータサイエンスリードやコンサルタントなど、さまざまな応答があったことは、この用語の定義がどれだけ混乱することがあるかを示しています。さらに悪いことに、データサイエンティストは二重の混乱に苦しんでいます。実際には、「データサイエンス」と謳われているものは、しばしば企業が採用したいスキルセットに応じて続くものであり、流行のタイトルで飾り立てられているものです。

分析の自由度の一つを修正するために、この記事の残りの部分にはデータサイエンスの共通の定義を採用します。それは、組織の利用可能なデータをモデリングして価値と競争力を生み出すために専念される機能です。それにはいくつかの典型的な形式があります：

• 顧客に関連する意思決定を最適化する機械学習モデルの構築
• 顧客と人間を介したアプリケーションを含む、すべてのレベルのスタッフが業務を遂行するのを支援するモデルの構築
• ビジネスの意思決定を支援する推論のための解釈可能なモデルの構築

BIや分析は除外していることに注意してください。それは焦点を絞るためであり、モデリング作業よりも価値が低いからではありません。あなたの分析チームとデータサイエンスチームはスムーズに連携するべきです。（私はここでそのことについて書いています。）

GoogleのPMである私の友人であるCarol Skordas Walport氏のような人々は、「データサイエンス戦略には、分析や機械学習を行うためのデータとインフラストラクチャを適切な状態にする方法が含まれる」と提案しています。私は、「チームがすべての作業を完了するためにどのように能力を向上させるか」と言います。私たちは意図的にこれらの広いデータ戦略に関連する項目を範囲外にします。（ごめんなさい、Carol。）ただし、データとインフラストラクチャの制約に対処し、データサイエンス戦略の開発がより広いデータ戦略を積極的に導く方法については議論します。

これで範囲が決まりました：自己の定義された戦略や目標を持つ組織に、機械学習やAIが最大の価値を付加できる核戦略的仮説のセットを構築していきます。では、どのように始めるのでしょうか？

戦略的な核となる仮説の構築：AIで勝つマインドセットから始める

経験豊富な機械学習プロダクトマネージャーやエンジニア、データサイエンティストは、機械学習製品は従来のソフトウェアとは異なるとしばしば指摘します。モデルのエラーリスク、データのドリフト、モデルの監視と再適合のリスクを考慮に入れる必要があります。したがって、現代のMLOpsの登場です。また、MLアプリケーションを技術的な負債の沼に引きずり込むエンジニアリングの罪を犯すのも非常に簡単です。（このトピックについては、「機械学習：技術的負債の高利子クレジットカード」を読むことをおすすめします。）では、この費用がかかる以上、なぜ私たちはそれを行うのでしょうか？

結局のところ、私たちはAIソリューションを考えるのは、洗練されたモデルが価値のあるパターンを検出できるという実績があるからです。これは、新しいセグメンテーションを示唆する顧客の好みのクラスタから、予測を最適化するためにニューラルネットワークが見つける潜在的な表現まで、何でもあります。ある機械学習プロジェクトは、プロセスの改善、実行可能な発見の発見、または有益な予測の改善ができるパターンを検出することができるというケースや期待に依存しています。

データサイエンスチームの核戦略的仮説を定義する際には、AIを活用した企業が異なる考え方を持っているという、McKinseyの例の説明から始めることができます。「AIによる勝利は心の状態です」というものです：

適切なユースケースを選び、適切に実施すれば、顧客とそのニーズについてますます学び、彼らにどのようにサービスを提供するかを継続的に改善できるようになります。

これはデータサイエンス戦略を構築するために非常に役立つレンズです。それは私たちに最大の学習に焦点を当て、私たちの組織の「正しい」定義に到達するだけです。しかし、私たちにとって「正しい」ユースケースは何でしょうか？

ここでは、Pisanoが再び役立ち、データサイエンスにうまく適用できるR&D戦略の4つの要素を定義しています。

• アーキテクチャ：データサイエンス機能の組織的な（集中型、分散型）および地理的な構造。
• プロセス：業務の形式と非形式の管理方法。
• 人材：求めるスキルの組み合わせや才能への価値提案など、あらゆる要素。
• ポートフォリオ：プロジェクトタイプへのリソースの割り当て方法、「プロジェクトのソート、優先順位付け、選択に使用する基準」。

最初の概念から始めて、組織に最も価値をもたらすと確信できるプロジェクトの理想的なポートフォリオを定義することに焦点を当てます。組織間の大きな違いがあるため、まずはすべての組織が直面する課題の1つから始めましょう：リスク。

目標ポートフォリオを定義する：戦略に合わせてリスクレベルと管理方法を決定する

モデリング作業には不確実な結果があります。「MLはより良い結果をもたらす」というのは、私たちが歴史と直感に基づいてよく言う議論であり、しばしば真実となります。しかし、MLが問題を解決できるかどうかは最初からわかりません。必要なリソースレベルやコストも、ユースケースごとに異なる場合があります。この質問の答えを知るための不確実性も、モデルが適用された範囲やデータの理解度によって異なる場合があります。

友人でありヘルスケアアナリティクス製品リーダーであるJohn Menardは、リスクをデータサイエンス戦略の明示的な一部として定義し、「データが期待通りにならない場合、プロジェクトを中止する戦略はどうですか？要件を満たさない場合に成果物を変更する戦略はどうですか？」と述べています。

組織がリソースをどれだけの期間提供できるか、そしてどれだけのリソースを提供できるかを明確にすることは賢明です。以下は、個々のモデリングプロジェクトに対して行ういくつかの有用な質問です。

• 成功の見込み：このモデルのユースケースが実現する確率はどれくらいですか？
• リターンの予想範囲：成功した場合、このプロジェクトはスケールで巨大なリターンを生み出すプロセスの微小な改善をもたらしますか？ブレイクスルーは競合他社との差別化につながりますか？
• 失敗を発見するまでの予想時間：このプロジェクトの仮説の価値提案が実現するまでにどれくらい時間がかかりますか？このプロジェクトがうまくいかないことがわかるまでに最小限のリソースを使うことはできますか？

これらの原則は直感的であり、すべてが合意された良いことです。理想的なプロジェクトは、成功する可能性が高く、巨大な投資利益があり、失敗した場合は早期に失敗します。しかし、この理想的な三位一体は現実には存在しません。適切なトレードオフを行うことが重要です。

AIによる特定の領域の破壊を目指す早期ステージのスタートアップは、特定のアプローチへの一つの大きな賭けとして企業を受け入れる投資家、リーダーシップ、スタッフを持つかもしれません。または、プロダクションにすばやく進むことができ、迅速なピボットが可能な小規模プロジェクトを選択するかもしれません。逆に、MLに懐疑的な利害関係者を持つ大規模な確立された企業や規制のある業界の場合、ポートフォリオを低LOEプロジェクトに偏らせ、徐々に価値を提供し、早期に失敗する可能性のあるアプローチを選択するかもしれません。これにより、初期の信頼を築き、DSプロジェクトに内在する不確実性を利害関係者に調整し、より野心的なプロジェクトにチームを結集させることができます。早期の小規模プロジェクトの成功は、同じ問題領域の大規模なプロジェクトの根拠を強化することもできます。

以下は、プロジェクトの範囲、期間、および予想リターンに基づいて目標ポートフォリオを定義するいくつかの例です:

• 「私たちはデータサイエンスの旅がまだ始まったばかりなので、スタッフの時間を大量にリスクにさらすことなく、機会を見つけるための小規模で低LOEで早期失敗するユースケースに焦点を当てています。」
• 「私たちは3つの大規模な機械学習の賭けを特定しました。それぞれが莫大な価値を生み出す可能性があります。」
• 「小規模プロジェクト、VoAGI、高コストのプロジェクトをバランス良く組み合わせ、対応するレベルのリターンを目指します。これにより、頻繁な成功を達成しながら、ゲームチェンジングな潜在的な破壊を追求することができます。」

最後に、完全なポートフォリオに適用する最終的な原則として、相関のない成功を持つプロジェクトのコレクションを目指します。つまり、ポートフォリオを見て、プロジェクトが独立して成功または失敗すると感じることができるようにしたいのです。複数のプロジェクトが共通の前提に基づいている場合、それらが密接に関連し、一緒に成功または失敗する可能性があると感じる場合は、選択を見直す必要があります。

このステージは、次のことが完了した時点で終了します：

• データサイエンスと機械学習の機会を調査しました
• それらを投資、リターン、成功の可能性に基づいてプロットしました
• 目的とリスク許容度に一致する大まかな優先順位リストを選択しました

今、ターゲットポートフォリオを決定したので、プロセスが迅速に価値のあるプロジェクトを特定、範囲化、提供できるようにするために取り組みます。

チームが独自に解決できるものにポートフォリオを集中させる

ビルドするか購入するかの問題は、永遠のテーマであり、しばしば複雑な組織のダイナミクスに関与します。AIソリューションを提供するベンダーやスタートアップはたくさんあります。その中にはスネークオイルのようなものもありますが、働くものもあります。多くの内部テックチームやデータサイエンティストチームは、前者を冗談と見なし、後者を競合他社と見なし、その2つを分離するために費やす時間は無駄だと考えています。これには一定の理由があります。ベンダーをチェックする時間は、モデラーのスキル向上には役立たず、組織がその努力を報いない場合、データサイエンティストがキャリア上の報酬なしに負担するコストとなります。そして、この人間関係の複雑さは、すでに複雑なビジネスケースをさらに複雑にしています。典型的なソフトウェアソリューションの懸念が消えるわけではありません。ベンダーロックインやクラウド統合などの問題について心配する必要があります。それにもかかわらず、私たちは高いROIを提供するベンダープロダクトを購入する意思があるはずであり、内部チームのユニークな利点を考慮すれば、そういった邪魔を排除することができます。

特に、内部チームは、一般的には組織の独占的なデータへのガバナンスアクセスを持っています。これは、内部チームがおそらくより深く理解し、他のソースと容易に結びつけ、強化することができることを意味します。単一の目的のベンダーソリューションよりも、十分な時間と計算リソースがあれば、有能な社内チームはおそらく優れた結果を出せるでしょう。（この中にはPAC理論のジョークが隠れているはずです。）しかし、それはそれに値するでしょうか？

ここでは、通常のROIと代替分析が重要です。内部市場への所要時間に重点を置いて、広告配置の最適化を行っているとします。ベンダーリストを1つの有力な候補に絞り込みました。この候補は、この執筆時点で主要なマーケティング最適化ベンダーの間で一般的な手法であるマルチアームバンディットを使用しています。ベンダーとの統合にかかる時間を1か月と見積もりました。または、独自のMABを作成し、それには6か月かかると見積もりました。私たちは、私たちが作成するMABがベンダーのものを上回り、遅延を正当化するほど十分に優れた結果を出すことを期待するでしょうか？

それは状況によります。MABにThompsonサンプリングを使用すると、期待リグレットに対して対数的な上界を得ることができます。これは、社内チームが実装した場合でもベンダーが実装した場合でも、証明可能な真実です。逆に、社内チームはデータに近く、このようなユースケースを社内で扱うことは、ベンダーが持っていないドメイン知識を注入することで、価値のあるエッジを提供するという賭けです。最後に、社内チームの機会費用を考慮してください。彼らが代わりに取り組むことができる他の高い価値のあるアイテムがある場合はどうでしょうか？その場合、ベンダーをテストし、他のアイテムに取り組み、ベンダーの結果を測定した後で再評価するという選択肢があります。

このステージは、次のことが完了した時点で終了します：

• 前のステップで機会を見直し、「これを購入できるか？」という質問に答えました
• 購入可能なソリューションごとに、内部に既知または仮説上の優位性があるかどうかに答えました
• 本当にトレードオフを考慮する必要がある領域ごとに、トレードオフ分析を行いました

内部チームの戦略的な競争上の優位性を定義したので、内部プロセス、ツール、データの能力を考慮します。

ナレッジファクトリーツーリングとデータサプライチェーンを中心にプロセスを構築する

私は多くの経験豊富なデータサイエンティストとタスクに費やされる時間について話し合ったことがありますが、彼らのほとんどは、データの発見、処理、クリーニング、移動（適切な計算環境に）が仕事の大部分を占めると指摘しています。別のグループのMcKinseyの著者たちもAutoMLとAIの人材戦略について書いており、「多くの組織が、データサイエンティストの時間の60〜80％がモデリングのためのデータの準備に費やされることを発見しました。初期のモデルが構築された後、彼または彼女の時間のほんの一部（一部の分析によると4％）がコードのテストと調整に費やされます。これは、私たちのほとんどがこのゲームに魅了される理由ではありません。ほとんどの場合、これは影響力のあるモデルを構築するために支払うコストです。そのため、私たちはしばしばデータサイエンティストが成功するために必要な「基盤」という話をするのですが、私の経験では、このフレームワークはすぐに私たちの邪魔になることがあります。私たちはツーリングと複雑なデータサプライチェーンの制約に従うモデル工場として自分自身を考えるように挑戦しましょう。

告白：私はプラットフォームの議論が行われる際に、「基盤」という話題にはあまり賛同していません。

「データと機械学習プラットフォームは、成功した機械学習の基盤です」と、無数のスライドデッキやホワイトペーパーで太字で述べられています。そして、「そして、強い基盤がなければ、すべてが崩壊します」と、あるコンサルタントが親切心を持って結論付けます。

しかし、ここが問題です：機械学習がなければ、ほとんどのことは「崩壊」しません。家を悪い基盤で建てれば、ガレージは自分自身と一緒に崩壊するかもしれません。データと機械学習のプラットフォームを開発せずに機械学習プロジェクトを開始すると、モデルの構築に時間がかかるでしょう。そして、その素晴らしい新しい機械学習モデルがない場合、おそらくビジネスは以前と同じように続くでしょうが、MLが提供する競争上の優位性はないかもしれません。しかし、凡庸な状態で継続することは終末ではありません。

これが私がこの常套句に同意しない理由です。それは幹部たちにプラットフォームの取り組みに資金を提供させるために、世界が彼らなしでは終わるのかと脅かすようなものですが、実際にはそうではありません。私たちは空が降ってくると叫び、ステークホルダーがいつもの雨に遭遇したときに、信用を失います。

それにもかかわらず、強力な機械学習の能力を持つ企業は、そうでない競合他社よりも優れた成績を収めるでしょう。私のモデリングリードとしてのキャリアがまさにそのような賭けであることに気付いています。また、現代のデータとMLOpsの能力は、AIの市場投入までの時間を大幅に短縮することができます。以下は、マッキンゼーの論文「テックナティブのようにAIをスケーリングする：CEOの役割」からの抜粋です（強調は私のものです）：

幹部たちからよく聞くのは、AIソリューションをアイデアから実装まで移行するには、9ヶ月から1年以上かかり、変動する市場動向に追いつくのが難しいということです。多くの投資を行っても、リーダーたちは自分たちの組織が速く動いていないとよく言います。一方、MLOpsを適用する企業は、増員や技術的な負債を増やさずに、アイデアから実際のソリューションまで2週間から12週間で進むことができます。これにより、価値の実現までの時間が短縮され、チームはより速くAIをスケールすることができます。

データサイエンスの戦略は、組織の制約とツールに対応し、その制約内で実施可能なモデルや知識の単位を生み出すパターンを採用する必要があります。つまり、モデリングプロジェクトには常に以下が必要です：

1. 最小限のモデリングデータへの明確な視線。データサイエンスチームは、ソースデータがどこにあるかを知り、どのように変換する必要があるかの大まかな概要を持っているべきです。
2. 実現価値への明快で現実的な経路。十分な性能を持つモデルを実際に稼働させるためには、どのようにすればよいですか？

初期段階の企業や完全なグリーンフィールドの自由なアーキテクチャとツールを持つチームは、現実世界でモデルのプロトタイプを迅速に作成、展開、モニタリングし、その影響を評価することが容易になるModern MLOpsプラクティスを採用することができます。従来のレガシーテクノロジーの横で働くチームは、MLの統合を考慮に入れずに構築されたことに気づき、展開が大きくて重い作業であることがわかるかもしれません。厳格に規制された業界の企業は、多くのアプリケーションが高い説明可能性とリスク制御を必要とすることが多いでしょう。

これらの課題は乗り越えられるものです。ただし、タイムラインの影響について原則を持ち、知恵を持って意思決定に組み込む必要があります。

我々は以下の状態に達したときに終了します：

• 計画されたユースケースを調査し、それぞれのデータへのパスを決定して開始する
• 各ユースケースが成功した場合の実現価値へのパスを決定する
• これを最初のステップから予想される投資に反映させ、調整する
• 見つけた変更に基づいて優先順位を洗練する

データサイエンスを展開する場所のアイデアを洗練した後、アライメントを確保するためにワーキングモデルを検討します。

アーキテクチャと組織：持続的な成功のために組織を構築する

Pisanoはアーキテクチャを「R&Dが組織的および地理的にどのように構造化されるかに関する意思決定のセット」と定義しています。これには、データサイエンティストをビジネスユニットにどのように統合するかについての考え深い意思決定が含まれます。彼らは完全に中央集権化され、公式の受け入れ体制を持っていますか？さまざまなビジネスユニットに報告していますか？中央集権化されて埋め込まれていますか？報告体制と意思決定権は、特に定義された報告ラインを持つユニットの戦略を構築するために課せられるかもしれません。ただし、これらのポイントが議論の対象となっている場合、DSの出力の価値を最大化するために考慮すべきいくつかの要素があります。

データサイエンティストは適切にサポートされ、適切に評価されるでしょうか？ ジュニアデータサイエンスのパイプラインを考えてみてください。データサイエンティストは、一般的に量的なバックグラウンドのさまざまな組み合わせを持つ、理論的なスキルと実践的なスキルを持ってこの分野に参入します。典型的な修士課程の卒業生は、これらの形成期間にスキルと理解を築き、それを専門家に理解してもらうために証明してきました。これには、非専門家に対して技術的な発見を伝えるためのトレーニングが豊富に含まれていることは一般的ではありません。

これに対して、彼らがビジネスの現場で経験することとは対照的に、彼らはおそらくドメイン知識が少なく、メソッド知識を持つ数少ない人物の1人になるでしょう。彼らは、彼らの機能の外で理解する人物がほとんどいない技術を適用するよう求められるでしょう。彼らのプロジェクトには、通常のソフトウェアビルドよりも不確実性が含まれる必要があります。彼らの成功は、データサイエンティストの制御外の多くの要素にかかっており、要件を最大限に成功する可能性を高めるために要求を明確にする経験が非常に少ないでしょう。これらすべてをまとめると、私たちは深い水の中に投げ込まれる状況が浮かび上がってくることがわかります。

これは、データサイエンスチームを初めてリードする他の機能リーダーにとって課題をもたらすことがあります。マッキンゼーの「現代の時代のR&D戦略の構築」からのこの教訓は、私たちの分野にも当てはまります。

組織は、既存の市場シェアを維持するだけでなく、ほとんどの場合は新たな顧客の要求から生まれる「安全な」プロジェクトに優先順位を付ける傾向があります。たとえば、ある消費財企業は、ビジネスユニットごとにR&D予算を分割し、その資金を長期的な差別化と成長目標ではなく、短期目標を達成するために使用しました。

私たちの分野では、これは非技術的な上司によって初心者のデータサイエンティストに対して、その日の質問に答えるために必要なSQLクエリを書くように求められるという形で表れる傾向があります。これは通常役に立ちますが、通常は企業が採用することで追求している価値の種類ではありません。

この問題は、以前にDSまたはMLプロジェクトを管理したリーダーがいる場合にははるかに簡単に解決できます。機能に関係なく、成功は問題を聞き、それらを解決するための分析とモデリングのアプローチの範囲を聞くことができる人物を持っていることにかかっており、リスクと不確実性を管理することです。初期のキャリアを持つデータサイエンティストの多くは、これらの状況で成功しています。私の経験では、彼らはコミュニケーションと不確実性の扱いの両方に才能を持つ異常事例です。私は偶然にもいくつかを採用する機会に恵まれました。あなたの能力を頼りにして、これらの才能をスクリーニングし、競争に挑みましょう。

これらすべては、データサイエンス機能を中央集権化することを主張しているように思えます。これは一つのアプローチですが、次の重要な問題につながります。

データサイエンティストはビジネスに十分接近して、正しい問題に集中できますか？中央のデータサイエンス機能グループは、ビジネスの問題に対して望む解決策に比べて、より少ない露出を得る可能性があります。ビジネスチームに直接報告するハイパーローカルチームに比べて、大規模で一体的な機能チームは、必要なビジネスの入力を得るのに苦労することがあります。これは、多くの利害関係者が何を求めるかを本当によくわからないためです。もし「誰も頼んでいない科学のプロジェクト」をデータサイエンスチームが提供するという恐ろしい話を聞いたことがあれば、これがしばしば根本的な原因です。そして、偏見を持つことを避けてください：これはほとんどデータサイエンスチームが学問的な心構えを持ちすぎているからではなく、2つの異なる機能が共有の言語で対話する方法を知らないからです。

この状況ではどのようなオプションが残されているのでしょうか？これは私の経験では埋め込みモデルが機能している理由の一つです。このモデルでは、データサイエンスチームは通常ビジネスの問題を議論するフォーラムへのアクセスを提供されます。彼らは、ビジネスチームが解決したい問題を理解するためのこの機会を活用し、価値を追加できるアプローチを提案する責任があります。彼らはデータサイエンスのリーダーに報告し、方法論的に正確な仕事を行うことを確認し、プロジェクトが成功するために必要なものを取得するためのサポートを受け、成長のためのメンターとコーチを提供します。

データサイエンスのプロジェクトが失敗するのは、しばしば手抜きの方法論のせいです。予測機能が十分に役立たないために失敗することがよくあります。量的な機能外の人物にとってはその違いを理解するのは非常に困難です。

私たちは、次のステップを終えるときには：

• データサイエンティストまたはチームのスコープを明確に伝える方法を定義する
• エンゲージメントパターンを定義する

実用的な決定と同様に、どこにでもトレードオフがあり、銀の弾丸はありません。完全に自律したローカルチームは、異なるローカルな成果に焦点を当てることができます。集中機能は、実用的で影響力のある成果からの逸脱のリスクを最小限に抑えますが、重複を最小限に抑えます。

ステップバック、コミュニケーション、ホリスティックな反復

これまでに私たちは何を達成しましたか：

1. 戦略的な仮説を定義し、データサイエンスと機械学習でどのように価値を追加するかに関する大きな賭けを行いました。
2. 組織のリスクアペタイトに合わせたターゲットポートフォリオを定義し、プロセスとテクノロジの制約を考慮し、チームを私たちが買うことができない問題に集中させました。
3. データアクセスとそれらがどのように価値を生み出すかに基づいてユースケースをフィルタリングしました。
4. おそらく、データサイエンティストをサポートし、彼らの才能を彼らの独自の優位性に集中させるためのプロジェクトソーシング方法の報告構造を開発しました。

より明確に言えば、私たちは適切なユースケースを見つけるための基準を示し、ユースケースの機会をフィルタリングして最初の適切なセットを見つけました。

次に行うべきことは以下の通りです：

1. 一歩引いて全体を見る。全体として統一的なものとして理解できますか？
2. この戦略とそれから生まれた初期計画を伝える。
3. 関係者が機能チームに参加する方法を伝える。
4. 反復する：前提条件やそれに基づく状況が変わった場合には戦略を見直し、状況がどのように変わったかを定期的に見直すことを確約する。

結論として、このプロセスは多大な努力を必要としますが、素晴らしい成果ももたらします。この戦略により、リスクを明確に示し、それをどのように管理し、それが成果をもたらす場合にどのように目標の結果を支援するかが明確になります。目的の明確な一致と、その目的と一致した活動の容易さは、機能チームにとって非常に力強いものです。それを提供し、結果は必然的についてきます。

参考文献

• Brenna et al、「現代の時代に合ったR&D戦略の構築」
• Corbo et al、「テックネイティブのようにAIをスケーリングする：CEOの役割」
• Kiechel, Walter. The Lords of Strategy: The Secret Intellectual History of the New Corporate World（アフィリエイトリンク）
• Meakin, et al、「AIで勝つことは考え方の状態です」
• Pisano, Gary P.「R&D戦略の作成」
• Rasiel, Ethan. The McKinsey Way（アフィリエイトリンク）
• Scully et al、「機械学習：技術的負債の高利子クレジットカード」

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!