マイク・ハイジー氏、CGIのAI戦略・製品開発担当バイスプレジデント。
企業のAIに関するほぼすべての議論において、会話は必然的に馴染みのある分岐点に達する：これを社内で開発すべきか、それとも既存のソリューションを購入すべきか？チームはしばしば技術比較、コスト分析、ベンダー評価に没頭する。しかし、そうすることで、彼らは完全に間違った問いに対して最適化するリスクを冒している。
自社開発か購入かの議論は、実際に何を開発または購入するのかについての明確な理解を前提としている。現実には、ほとんどの組織がこの重要なステップを飛ばし、「AIが必要だ」から直接「どのAIソリューションを選ぶべきか？」へと飛躍している。本質的な作業はソリューションの選択ではなく、対処すべき本当の問題を明らかにすることにある。
ソリューション先行の罠
一貫したパターンになりつつある：組織は問題を明確に表現する前に、ソリューションの好みを持って現れる。カスタムソリューションの構築を望む組織もあれば、ベンダーからの購入を好む組織もある。多くはハイブリッドアプローチを想定している：APIをライセンス供与しながら独自のラッパーを構築するというものだ。
クライアントはしばしばAIがすべてを解決できると思い込み、より単純なアプローチの方が良い結果をもたらす場合でも、過度に複雑なソリューションを導入してしまう。ある政府機関は、異なるシステムからのデータセットを照合するためにAIを望んでいた。実際のソリューションは？2つのSQLクエリだった。機械学習は必要なかった。別のクライアントは、レポートから情報を抽出するために大規模なビジョンモデルを追求した。従来のOCRツールは、AIの複雑さなしに優れた精度を提供した。
これらは例外ではない。ソリューションへの熱意が問題の明確さを上回るケースの大多数を代表している。研究によれば、AIプロジェクトの失敗率は最大80%に達する可能性があり、不十分な問題定義が主な原因として特定されている。
このパターンはより深い問題を示している：人間として、私たちは自然と問題定義の曖昧さと格闘するよりも、具体的なソリューションの評価に引き寄せられる傾向がある。ソリューションに焦点を当てることは生産的に感じられるが、問題を定義することは望ましくない遅延のように思える。しかし、このバイアスはしばしば何ヶ月もの無駄な努力と逃した機会につながる。
問題定義に実際に必要なこと
問題を効果的に定義することは、要件文書やユーザーストーリーの作成をはるかに超えている。それは明確さと精度をもって3つの基本的な質問に答えることを要求する：
1. 私たちに欠けている具体的な能力は何か？
願望的なビジョンや競争上の不安ではなく、現在の業務における具体的な制限。今日できないが明日必要なことは何か？摩擦はどこで測定可能なコストを生み出しているか？
2. どのような制約が実行可能なソリューションを形作るか？
予算は重要だが、技術的能力、規制要件、データの可用性、組織の変化への対応能力も同様に重要である。これらを障害として見るのではなく、正しい前進の道を知らせる本質的な設計パラメータとして扱う。
3. 成功はどのように測定されるか？
「効率を改善する」や「顧客体験を向上させる」といった曖昧な目標は、情報に基づいた意思決定に必要な具体性を欠いている。効果的な評価には、明確で定量化可能な基準の確立が必要である。
仮説的には、測定可能な成果には、6ヶ月間で保険ワークフロー内のクレーム処理時間を30%削減すること、または文書分類の精度を85%から95%に向上させ、標準化されたテストデータセットで検証し、週平均10時間の手作業のやり直しを削減することが含まれる可能性がある。
AIシステムは、事前に定義された問題に対処するために作成された明示的な指示を通じて動作するため、正確な問題定義が成功の鍵となる。
ハイブリッドの現実
問題を明確に定義すると、自社開発か購入かという問いは、しばしばあなたの状況に合わせたより微妙なハイブリッドアプローチに解決される。
現代のAI実装は純粋な戦略に従うことはほとんどない。組織は基盤モデルをライセンス供与するが、独自のデータでファインチューニングを行う。プラットフォームを購入するが、カスタム統合を構築する。既製のAPIを使用しながら、特殊な前処理を開発する。
イノベーションは単純に「自社開発か購入か」では語れない。どのコンポーネントを自社開発し、どれを購入し、それらをどう組み合わせるかが重要だ。その答えは、実際の問題定義を行った後にのみ見えてくる。
実践的な意思決定フレームワーク
問題を定義した後、自社開発・購入・ハイブリッドの決定にどうアプローチするか：
1. 既存のソリューションから始める。
既製で利用可能なものを調査する。多くの問題には確立されたソリューションがある。カスタマイズを必要とする特定の要件がない限り、実行可能な代替案が存在する場合にカスタム開発をすることはリソースの無駄である。
最近の分析によると、AIプロジェクトの40%以上がキャンセルされるのは、組織が能力が測定可能なビジネス価値を生み出すユースケースに焦点を当てるのではなく、ソリューション自体のために追求する場合である。
2. 戦略的差別化を評価する。
この能力があなたのビジネスに独自の競争優位をもたらすなら、自社開発は理にかなっている。すべての競合他社にとって最低限必要なものであれば、購入する方が理にかなっている可能性が高い。カスタム開発は、差別化が重要な分野に焦点を当てるべきである。
3. 技術能力を正直に評価する。
AIソリューションの構築には、継続的なメンテナンス、モニタリング、反復が必要である。長期的にこれをサポートするチームはあるか？必要な人材を引き付け、維持できるか？そうでなければ、購入することでこの負担を専用リソースを持つベンダーに移すことができる。
4. データの機密性と制御を考慮する。
競争優位をもたらす独自データは、データを社内に保持するカスタムソリューションを正当化する可能性がある。一般的なデータ処理は外部サービスを活用できる。データの機密性は実装アプローチに影響を与えるべきである。
5. 価値実現までの時間を考慮する。
カスタム構築には時間がかかるが、正確なフィットを提供する。購入したソリューションはより速く展開できるが、適応が必要である。あなたの競争状況によって、どのタイムラインがより重要かが決まる。
6. 進化を計画する。
AI機能は急速に進歩する。今日最先端に見えるソリューションは、明日には標準になる。進化が必要だという前提で構築する。ベンダーのロードマップが変化するという期待で購入する。どちらの戦略も柔軟性が必要である。
本当の競争優位
重要なポイントは、ソリューションを評価する前に問題を定義することに焦点を当てる組織は、この基礎的なステップをスキップする組織よりも、より速く、よりコスト効率が高く、より適応性のある結果を達成するということである。
彼らは間違ったものを構築することによる誤ったスタートを避ける。マーケティングではなく適合性に基づいてベンダーを選択する。彼らは、一般的な機能を再発明するのではなく、本物の優位性を生み出す分野にカスタム開発を割り当てる。
「何を構築すべきか？」の前に「私たちはどんな問題を解決しているのか？」と問うチームは、あらゆる面でより良い決断を下す。
自社開発か購入かの議論は、問題定義という困難な作業を終えれば自然と解決する。しかし、そこから始めなければならない。ほとんどの組織はそうしない。それがあなたの競争優位になる。
