動いて使えるAIを作る方法 〜AI Value Architectの仕事
序章：動いて使えるAIを作る
「どうすればAIを上手く活用できるのか？」実務家の皆様が日々悩まれている問いではないでしょうか。新たにDX担当や新規事業担当に任命されてAI活用を丸投げされ途方に暮れている方もいると思います。
私は新卒から14年間外資コンサルティングファームに在籍していましたが、様々なクライアントでその様な場面を目の当たりにしてきました。
デジタル/AIの重要性には誰からも異論が出ず「AIをレバレッジする」「AI中心のアーキテクチャの実現」「AIと人間の協働」・・・という類のコンセプトはたくさん上がるが具体化が一向に進まない、というケースです。
私は最後は戦略部門に所属していましたが過去にIT部門と業務部門の経験もあったためか「何を作って、どうやって使えば、戦略目的を達成できそうだ」というビジネスとテクノロジーの一気通貫の全体構造が比較的くっきり見えている感覚がありました。
しかし、いくら「そういう感覚があります」と主張したところで誰も信用しないでしょうし、当時の立場では構想のみで実装には関わらない役割であったので実証のしようがありませんでした。
そのうちにどうしても試してみたい気持ちが高まってきて、長年勤めた愛着あるファームを辞めてAI実装の現場があるAIベンチャーのHEROZに転職しました。そして転職して半年後から開発部の副部長として主にビジネスチームをリードしています。
自分でやってみた結果として、感覚の解像度が粗かった・甘かった箇所もあるので日々継続学習中ではあるものの、ビジネスとテクノロジーの一気通貫の全体構造の「設計力」がAI社会実装の肝であるという仮説は大筋では外れていない感触を得ています。
そして、その様な一気通貫の設計力を有する副題のAI Value Architectという人材がAIエンジニアと同様にAIプロジェクトの成功率を向上する肝であると考えています。
AI界隈に様々な優秀な方々が集まっていますが「実際に動いて役に立つAI」を実装できている強みには自負はがあります。
守秘義務により詳細は書けませんが、年間数十以上のクライアントとAI実装について協議し、いくつかのプロジェクトは実運用に到達しています（詳細はHEROZのホームページ等をご参照ください）。
それら「実際に動き役立つ」社会実装経験を通じて上手く成果を出せるPJT・ケースの共通点も見えています。また、同じような感覚を持ってAI産業界隈で色々と試している方々とも情報交換しながら仮説の精度を高めています。これを整理して言語化し、多くの方々と一緒にAIの普及を推進する一助にすることが本コラムのねらいです。
１章：AIを社会実装するとは何か？
1-1:AIにやらせることを具体的に決める
AIがプログラムである、というのは誰でも知っている当たり前の事です。しかし、プログラムは書いた通りにしか動作しないというもうひとつの当たり前の事はしばしば忘れられます。
AI = プログラム、プログラム = 書いた動作しかしない、よって、AI = 書いた動作しかしない、という三段論法の例題の様な明快な理屈です。
AIは様々なうれしい効果を期待できるテクノロジーではありますが、魔法やSFではありません。他テクノロジーと同様に、AIに何をさせてどうやって価値を創出するのか、もっと言えばAIが何をすれば価値があると言えるのか、を定義するのはやはり人間です。
よってAIを上手く活用するには「AIに何をさせるのか」を明確に定義する必要があります。
1-2:価値設計：AIが価値を創出するメカニズムを設計する
「AIに何をさせるのか」を明確に定義する必要がある、は当たり前のことですがその実践は容易ではありません。
価値を出すために「AIに何をさせるのか」という問いは戦略妥当性と実現可能性に分解されます。すなわち「やって価値があることは何か？」と「AIがそれを上手くやれるのか？」の二つの問いへの答えの質が高く、かつ相互に整合して初めて価値を創出できます。
前者が欠けていると「労多くして功少なし」に陥りますし、後者が欠けていると「SF（サイエンスフィクション）」になります。
そして、実際に考え始めてみると分かりますがこの二つの問いは相互に往き来します。つまり「AIが何ができるの教えてくれないと、どうやって価値を出せるのか分からない」という主張と「何をやりたいのか明確にしてくれないとAIがそれをできるのかを判断しようがない」という所謂「ニワトリと卵」の循環構造になっています。しかし、これをきちんと言語化して「価値設計」する事がAIプロジェクトの肝であり、他プロジェクトに比べても殊更重要な要素です。
ではどのくらいの具体性があれば「価値設計」として妥当なのでしょうか。もちろん具体的であればあるほどよいですが、目安としては「価値創出のメカニズム全体像が少なくとも論理的に成立している事」です。
例えば、AIの典型的なユースケースである「需要予測」の場合には、次のような論理的な全体像が示される必要があります。もちろん、実プロジェクトではこの程度の粒度では甘いですが、この程度であってもAIで「やって価値がある事」と「やれそうな事」の設計図仮説を示しチーム内で共通認識化すべきです。
1-3:価値設計が不十分だとPoC地獄になる
AIプロジェクトで「価値設計」が殊更重要になる理由はAI、特に機械学習はその技術特性上どうしても「やってみなければ分からない」部分が残るからです。
昨今のベンチャーブームや新規事業の必要性から「やってみなければ分からないこと」を試しながら進める実証的なプロジェクトの進め方が受け入れられています。
しかし、なるべく短い時間で成果に到達する事が本質的に重要なビジネスでは「やってみなければ分からないこと」は仕方なく受け入れることであり、やらないでも分かることは実証などせずに所与として設計した方が無駄がないことは明白です。
そして先述の様にAIは「やってみないと分からない」事が構造上不可避であるのだから、それ以外の要素については可能な限り設計しておくべきです。そうしておく事で試す事への時間の浪費を減らせるのに加え、仮に試した結果が誤りだった場合にどこまで遡って再検討すれば良いのかが明確になります。
実際に、年間数十のAIプロジェクトを見ていますが、初期設計の巧拙とプロジェクトの成功率の間には相関がありそうだ、という感覚があります。
彼のピーターティール氏も著書「Zero To One」の中で「出来の悪い計画でも、ないよりはいい」と計画・設計の重要性に言及しています。実証が必要な箇所は可能な限り明確化・最小化するというのが不確実性の高い取り組みのセオリーだと思います。
こうした設計をろくにせず「分からないことだらけ」で見切り発車すると、PoCの目的である「何を検証すべきか？」すら不明瞭になり、陥るべくしてPoC地獄に陥ります。
どうでも良い余談ですが、新価値創出のバイブル的な書物として「リーンスタートアップ」と「ゼロトゥワン」が有名です。どちらも深く読み込むと、本質的には似た様な事が書いてありますが、その見え方は表面上はかなり違います。両方の著者に敬意を持っていますが、私がしっくりきたのは断然「ゼロトゥワン」です。
1-4:AI Value Architectという役割
この「価値設計」を上手くやる役割を担うのがAI Value Architectです。
ビジネス課題や目的を解釈して、その目的するAIを適用した価値創出のメカニズム及びその運用を設計し、検証すべきポイントを厳選して、AIエンジニアやITエンジニアと連携しながらAIの実装を推進します。
この役割は世の中でまだ明確に認知されていないですがこれから普及していくでしょう。なのでAI Value Architectというのも勝手につけた仮称で、同じ様な問題意識を持ってこの役割を違う名称で設定している他社さんもいらっしゃいます。
後段の章でAI Value Architectに必要なスキルについて考察していますが、先述の図1の「やって価値のあるとことは何か？」と「AIがそれを上手くやれるのか？」について迅速かつ高品質な仮説立案をできる必要があり、そのカバー範囲はかなり広くなります。
先述の通り知名度不足から現状の採用ではAIビジネスコンサルタントという名前で募集をしていますが、その役割はコンサルタントの様な構想やアドバイスではなく、価値創出を設計し実装まで並走して見届けるアーキテクトやデザイナーに近いです。AIの社会実装を普及させるにはこの役割を担える人材を増やすことが必須です。
なお、普及してきたら募集名もAI Value Architectに変えてやろうと目論んでいます。
Column01：プラクティカルの過小評価
「大きい話や難しい話で話題になる割に成果出たり役に立っている実感がないよね」というのがAIに対する多くの方々の率直な印象だと思います。
私の印象でも、ビジネスサイドでは例えばAI社会での倫理とか格差への影響とか視座が高い論点ばかりが目立っていると感じています。
同じ様に、技術サイドでは基礎研究への偏重、応用の軽視がある様に感じます。こちらは例えば、MIT Technology Reviewの2020年8月24日の特別寄稿「特別寄稿：応用軽視のAI研究界、現実の問題に向き合うべきだ」という記事の中でも問題提起されています。
視座の高い論点も基礎研究ももちろん重要です。しかし、使える技術を組み合わせ、きちんと社会実装を設計するプラクティカルな面にも目を向けるべきだと感じています。
「総論」はその名の通り、総じて多くの人に受け入れられがちです。例えば「労務条件は絶対に遵守されるべき」は総論は異論が出る余地はほぼないです。しかし現実には人数が全然集まらない中、別の規制からは高い水準の品質を求められ板挟みになるケースはよく起きます。
こういった板挟みの環境下でも優先順位と妥協点を見出し、過度な変革圧力で現場が壊れない様に段階的に理想に近づけるプラクティカルな仕事の重要性・難易度が、スポットライトを浴びがちなビジョンや構想に劣後するとは私はまったく思いません。
少し余談になりますが、この様な管理側の都合による「傍若無人なべき論の押し付け」が様々な産業の現場の生産性を著しく劣後させているのは個人的には非常に残念に思います。組織固有の問題だけでなく前提となる法整備・規制の不備によるケースも多いと感じます。
２章：AIを社会実装するためのチームは？
2-1:発射台の高さと学習の加速度を獲得する
AIの成功には「価値設計」が重要だと述べました。もちろん最初から完璧な価値設計ができるはずはなく初期仮説を検証・修正を繰り返し価値設計の精度を上げていきます。そして実ビジネスでは求められる期間内に求められる水準の価値設計の精度に到達しなければ失敗です。
限られた時間の中で期待する水準に到達するには「発射台の高さ」と「学習の加速度」が重要になります。発射台の高さとは初期仮説の筋の良さの事です。学習の加速度とは単位時間での学習量（例えば検証対象から外せるパターンの量）であり、学習の加速度を向上するには検証すべき内容を厳選し、かつ想定される検証結果パターン毎に応じた具体的な結論・次の手を決めておく事が有用です。
つまるところAIプロジェクトの成否は「質が良く具体的な初期仮説」に掛かっているという事です。
2-2:イメージトレーニングで仮説を磨き込む
ではその「質が良く具体的な初期仮説」をどう作るのかについてです。特にこれが唯一の正解だというつもりもないですが有用な方法はあります。それは次の様な内容です。
これを全部頭の中でやります。頭の中なのでいつでも何回でも繰り返せるし、コードを書かないでも瞬時にプロセス変更のシミュレーションができるので高速に仮説検証を回せます。
また、この思考を繰り返す事自体が頭の中に明確なイメージを持つことに繋がる=言語化しやすくなり、他の関係者とイメージを共有しやすくなります。
よくトップアスリートの方がイメトレ（イメージトレーニング）を大事にしていると言われますが、頭の中で高速に試行・失敗を重ねる事で学習を加速できるAIプロジェクトでも有用な方法です。
まだ検証中・実験中なのですが、先に実稼働状況を踏まえて逆算するアプローチは所謂TDD（テスト駆動型開発）にも通じており、相性が良いのではないかと推測しています。
この初期仮説を構築する際に最終的には言語化する必要がありますが、発想時に文字、音声、絵（ビジュアル）のいずれかで考えやすいのかは人によって思考の癖が異なる様です。
余談ですが、この様に初期仮説から得られる誤差を実証的に是正して精度を上げるプロセスはAIの学習プロセスそのものですね。
2-3:なるべく”分業”をしない少数精鋭チームで実装する
次に、その様にして構築・磨き込んだ「価値設計」を如何に実装していくかについてです。
まず理想はビジネス、AI、ITをひとりの人間が全カバーし、全体像を俯瞰しながら設計（作業ではなく設計）できる事が望ましいです。
その目的はコミュニケーションコストの省力化です。やはり、いくら「価値設計」の精度を上げて様々なパターンを想定しても、実装時には想定外の事象による設計変更が生じます。その際に、事象発生の要因箇所と是正方法の迅速な決定が高生産性の肝です。
これに分業体制で対応しようとすると、知識の共有やすり合わせのコストが大きくなります。特に分業者間の知識・スキルレベルの差があると大きくなります。コストの大きさは知識・スキルレベルが低い方に引っ張られます。
しかし、現実的には全領域をカバーできる人間はほぼいないので、次点としてなるべく”分業”をしない少数精鋭型のチームを構成してコミュニケーションコストを極小化をねらいます。
この少数精鋭のチームを組成する際に特に重要なコツがあります。それは各メンバーの知識ドメイン（専門性）が相互に重なってグラデーションを作るチームを組成する事です。
例えば、図7の「ビジネス設計者」（これが先述のValue Architectに該当します）は価値設計や業務設計を専門ドメインとしていますが、AI設計についても、何をインプットにどういう手順でAIを構築するかという基礎的な知識・経験は有しています。
このことにより、専門知識ドメインである価値設計や業務設計がどのようにAI設計に影響をするのか、もしくは逆にAI設計に変更があった場合にどう価値設計や業務設計にどう影響するのかを想像しながらのAIエンジニアと会話が可能になります。
逆も同じで、AIエンジニアもAIの設計変更や限界が、業務的に実現したいことにどの様に、どの程度影響する中を提示しながら検討を推進できます。
「ビジネス設計者」に求められる技術素養のイメージはオープンソースのAIライブラリを自分で動かせるくらいのレベルです。例えば、私の同僚のビジネス職の何人かは簡単なデータの概観把握や基礎分析であればドメイン知識の有利さからエンジニアよりも早く適切な分析示唆を導出できます。もちろんその後のアルゴリズムの設計や構想などはエンジニアの方が遥かに優秀で速いです。
この様に自分が担当ドメインの専門性 + 関連ドメインの知識を重ねる事によって「専門性の有機的な繋がり」が実現でき、コミュニケーションの円滑化に加え、価値設計が実装時に劣化することの回避にも繋がります。不確実性の高いプロジェクトに臨むチームはこの様な柔軟性を備える事が必須です。
なお、完全に余談ですが、いつも思うのですが「有機的なつながり」って分かる様で分からない曖昧なワードですよね（笑）
2-4:少数精鋭チームが活躍する組織体制とは？
少数精鋭チームのメンバーは階層型の権限やルールによる統制を鬱陶しいと感じ、目的を達成するために自由に考えて振る舞いたいと考えます。少数精鋭チームを運営するには旧来型の階層型のチーム・組織は向いていません。
ではそれに代わるものとして、これだという決定打はないのですが現時点で少数精鋭チームを活かせる理想の組織体制は次のようなものと考えます。
ある意味で、目的を達成するための「互助」を基底とした原始的な組織形態とも言えるかもしれません。個人的には、専門スキルを融通し合うフラットな関係性が肝だと思っています。
一般的なチームの類型であれば「階層型」ではなく「プロジェクト型」のフラットなチームが向いています。
また、プロジェクト型のチーム組成なので、案件毎にメンバーが集められチームが組成されますが、そのチームの管理は昨今の話題の区分で表現すると「メンバーシップ型」ではなく「ジョブ型」が望ましいです。
組織である以上、ガバナンスの観点からはある程度の階層化が止むを得ないですが、その際に専門家から構成されるメンバーは同じ専門性を有する上長にスーパーバイズされる必要があります。エンジニアはもちろんですがAI Value Architectも同じ専門性を有する上長の下に就くのが望ましいと考えています。
後に人材像について述べますが、私はAI Value Architectをゼネラリストと捉えていません。AIを用いてビジネス価値を設計する専門家だと捉えるべきです。言い換えればゼネラリストではAI Value Architectの役割が果たせません。しかし、多くの組織ではゼネラリストにその役割を担わせようとしている様に見受けられます。
Column02：ジョブ型組織の要件：学習し続ける組織設計
本章で少数精鋭チームの効用について述べましたが、企画から実装までの価値連鎖（バリューチェン）を極端に短縮できるデジタル社会においては、この体制が基本型かつ理想型になっていくと思われます。
それにも関連して「ジョブ型」へのシフトも進んでいく事と思われます。ジョブ型になると各メンバーには「専門性 + 基礎体力」が求められます。基礎体力はビジネスに共通して必要な論理的思考やアウトプット力などです。
究極的には各々「専門性 + 基礎体力」を持ったメンバーが自律して動く事が望ましいですが、スケールする際には経験の浅いメンバーを育成しなければ組織が成立しません。
この時に、ジョブ型組織は特定の目的に下に信頼と相互尊敬によって関係性を成立させるので、組織の長たる人材はその組織の目的に関する知識・スキルに精通している必要があります。然もなくばチームメンバーの求心力を得る事は困難です。
故に、ジョブ型組織に所属する人材は一生涯学習し続ける事が必要になります。ジョブ型組織は「学習し続ける力学を作用させる」設計であるとも言えます。
私は新卒で外資コンサルティング会社に入り14年間在籍していましたが、職位が上がるほど難しい事にチャレンジし、たくさんの価値創出を求められる、その代わりに高い報酬を得るという組織設計はフェアだと感じてまいした。幼少期から各種メディアから「若い頃は必死に働き、偉くなったら人に働かせて楽をする」という価値観を押し付けられて違和感しかなかったのでまさに「我が意を得たり」の思いでした。
別の観点では、ジョブ型の組織が求められるということは、理不尽なルールや権限の押し付けでは組織は成立しなくなっており、真摯に学習し続ける事が求められる社会に変容するという事だと理解しています。
3章：AIの社会実装を担う人材とは？
3-1:少数精鋭チームで活躍する人材の要件
先の章でAIプロジェクトでは専門知識ドメインが重なった少数精鋭のチームが望ましいと述べました。ではその少数精鋭のチームにはどの様な人材が向いているのか。特に冒頭にも記述したAI Value Architectとして活躍する人物像について、私自身も採用・育成で現在進行形で試行錯誤していますが活躍人材の傾向も見え始めているので考察してみます。
人材要件を記述される際に用いられる「スキル・知識・マインド」の枠組みで記述してみます。
まず「スキル」についてです。ど真ん中のスキルは安宅氏の著書である「Issueからはじめよ」の内容を理解し、実践できる人材です。それだとあまりに名著に丸投げなのでもう少しきちんと書くと、本質的には論点設定と仮説思考の習慣が染み付いている事です。
AIプロジェクトは不確実性が高い状態から検討が始まる事が多いので、ラフに仮説を描きつつ高速に詳細を詰めていく基本動作は必須です。また、産業のドメイン知識の理解も重要なのでキャッチアップの速さも重要です。なので、元も子もない話ですが所謂「地頭」が良い人が活躍しやすい傾向はあります。
続いて「知識」です。エンジニアとの会話が重要になるので技術的な知識や経験はある方がやはり有利です。社会実装を踏まえるとAIの知識のみならず、DBやサーバ・インフラ周りもある程度知っている事が望ましいです。加えて、スキルの節でも言及しましたがドメイン知識を有していると産業の構造課題やトレードオフに紐づくゲームチェンジにつながる変革の仮説を出せる可能性が高くなります。
最後に「マインド」です。これは、「客観的である事」かつ「達成コミットメントが高い事」になるかと思います。AIは技術なので根性論が入り込む余地はないですが、一方で、不確実も多いからこそ「こうだからできない」ではなく「こうすればできる」を考え続ける姿勢がはかなり重要です。
マインドについてもう一件、AI産業にいると「社会貢献をしたい」というマインドが最前面に出ている応募者にお会いすることがあります。もちろんその視点も大事なのですが、私が想定するAI Value Architectの素養とは異なります。
AI Value Architectに向いているのはもっと内面的なモチベーションがある人物です。自分には世に問うてみたい具体的な仮説があってそれを優秀なエンジニアと一緒にビジネスとして実装・検証して証明したいタイプが該当します。その仮説が社会にフィットすれば社会で広く価値を生むことなります。そういう意味ではマインドとしては「功名心に近い好奇心」という表現が適切です。・・・単に私の好みの問題な気もしますが（笑）。
自分で書いててもハードル高い感はありますが、先進的な技術を社会実装が楽なはずもなく、そういう事なのだと思っています。
なお、私の経歴が地頭が良さそうに見えないのはご愛嬌ということで。。。
3-2:スーパーエンジニアとのコラボこそが価値
AI領域にはヘンタ・・・もといスーパーエンジニアがいます。言い間違えたのも褒め言葉です。Kaggle等の競技プログラミングで上位に入賞したり、何かしらの領域で世界一になる様なエンジニア達です。これらのエンジニアはテクノロジーの理解が深すぎて、普通の人からすると何を言っているのかほぼ分かりません。
一方、ビジネスである程度の効果を創出できるレベルのAIは実はそこまでの技術力がなくても達成できる場合も結構あります。特に、アドホックに示唆を得るための「データ分析」はそれなりに結果が出た様に見える事が多いです。
しかし、逆にいうとそのレベルのデータ活用は誰でもできるので何の差別化にもなりません。そうではなく、スーパーエンジニアしか解けない規模の問題や、出せない精度を基軸にした自動化の実現こそが競争優位につながります。
その実現のためには、スーパーエンジニア達に能力をフルに発揮してもらい、それを上手く翻訳してビジネス価値に変換できる能力がAI Value Architectに求められます。それを実現するにはより一層、これまでの様な組織構造と権限に基づく管理職の能力に依るのではなく、双方のエキスパティズムに立脚した信頼関係に依るべきです。
また、スーパーエンジニアに限らず、天才系は一般的な事務や管理業務が苦手だったりすることも多いです。先に少数精鋭チームが階層型の権限やルールによる統制を鬱陶しいと感じると記述しましたが、これらの天才は鬱陶しさを感じるまでもなく平気でそのルールを無視する傾向があります（笑）。
彼ら彼女らの力を最大限活用すべくその価値を正しく認識して「天才とはそういうものなのであろう」というある程度の寛容さが必要なのも事実だと思います。
Column03：エンジニアだけではダメなのか？
ここまでAI Value Architectの話を散々してきましたが、そもそもとして技術の話なんだからエンジニアだけではダメなのか？という疑問について考察します。
結論から言うと、これまでに書いた機能をひとりでカバーするエンジニアがいればダメではないです。しかし、そんなエンジニアはほぼいないです。
にも関わらず、適当なコンセプトと甘い課題設計で仕事を取ってきてエンジニアに丸投げし、設計が曖昧なまま「何かしらの分析結果」を実行・提示して商売にしている組織もあると聞いています。
しかし、上品に申し上げると私はこの様なやり方は好みません（下品な言い方はご想像にお任せします）。社会全体で希少なAIエンジニアリソースの無駄遣いになるし疲弊させる割に投資をした側にも価値を埋めないからです。新しいテクノロジーを適用するためにロジカルシンキングを駆使するタスクには二種類あります。何を解くべきなのか？を定義する課題設定と、どの様に解くべきなのか？の課題解決です。そして多くのエンジニアが得意なのは課題解決です。
しかしながら、課題解決は課題設計の後段に来るので、課題設計が曖昧であっても課題解決側に押し込む事が構造的に可能です。逆は構造的に不可能です。
だからこそ、課題設定する際にもエンジニアが力を最大限発揮できる様に真摯に実施すべきです。なので私のチームではビジネス職も必ずデリバリーに参加させ、仕事を取ってきたら「あとはよろしく」というスタンスは許容しません。
4章：何故、AIを社会実装すべきなのか？
4章は何故、AIを社会実装すべきなのかについてです。本来であれば、これは最初の章に書かれるべきです。しかし、ビジョン的な話は私よりもよっぽど頭が良い人が多くを語っています。一方、AI社会実装に必要なのはその様な気宇壮大な話ではなく、実践的なHowなのでそちらを先に書いた結果この様な構成になりました。
AIを社会実装したい理由はとてもシンプルで、この技術を広く普及させ活用できれば社会全体の生産性が上がり、社会全体の生産性が上がれば多くの人がもっと自由になれるからです。
そして、現代において価値を広く世の中に普及させるのに最も有用な手段はビジネスなので、ビジネスでの活用を戦略的に計画できればAIの社会実装は浸透していくはずです。
という事でAIをビジネスで活用する際の本質について考えを述べたいと思います。
4-1:より幅広い機能を自動化できる
まずAIの新価値創出のメカニズムについてです。少し過小評価ですが、実用性という面では効果創出のメカニズムの中核はこれまでのITと大きくは変わらないです。すなわち、自動化され、複製・スケール可能になり、24時間365日稼働できるなどです。
ではこれまでと異なる部分はどこかと言うと、非構造化データ（画像や音声、自然言語など）を利用できる事と、単純業務ではない「判断業務」の一部に適用可能である事です。
4-2: 既存ビジネスへのレトロフィットによる価値向上
この事は、既に市場が形成されており、生産性が勝負の決め手となる既存ビジネスでは非常に有用な競争優位の要素になり得ます。
また、AIのシステムはプログラム的には相対的に軽い実装で済むことも多いのでAPI連携で既存システムにレトロフィットする形でアドオンする方式で実装できれば既存の資産を活かしたバリューアップが可能になります。
そのポイントを見極めるのは簡単ではなく、故に、先述の様なビジネス〜実装までカバーする少数精鋭チームで深く検討する必要がありますが、取り組むだけの価値がありますし、私が実プロジェクトで取り組む場合も重視している観点のひとつです。
AIレトロフィットには図11に示す様に大きく「自社サービスのバリューアップ」と「業界標準プラットフォームへの自社戦略アドオン」のふたつの基本戦略があると考えています。
ひとつ目の「自社サービスのバリューアップ」とは自社システムで既にデータや中央集権的に制御可能な仕組みが整っている場合に、その制御や実証部分にAIをアドオンする事により、人間にはできない規模や粒度の制御を実現し新しい価値を生み出す作戦です。
この作戦は既存システムを利用するので保有する有形/無形資産を活用可能な事、実装までのリードタイムが短い事などで有利です。また、大企業の意思決定の仕組み・構造においてもROIが見込みやすく意思決定しやすいのも特筆すべき特徴です。
具体的な適用例としては例えば、空調や照明などの建物設備制御システムの制御部分をAIアドオンで強化してそのシステム自体をバリューアップするなどがあります。
先述のAIの価値創出のメカニズムのフレームワークに沿って記述すれば、設備制御という「判断業務」をAIを用いて365/24化、スケール化、高速化（リアルタイム化・高頻度化）する事で新たな価値を創出します。
続いて、ふたつ目の「業界標準プラットフォームへの自社戦略アドオン」です。分けて記載しましたが本質的な作戦は「自社サービスのバリューアップ」と変わらないです。大きな違いはひとつだけで基盤となるデータやプロセスが自社のものではない業界デファクトスタンダードのプラットーフォームを利用している事業・業務に適用する事です。
具体例では、予約・価格管理システムの管理業務部分はプラットフォームの機能を使いながらも、自社の顧客戦略部分はAIで制御し、それに即したコミュニケーションを制御・実現するなどです。
この作戦のメリットは業界デファクトスタンダードのプラットフォームを用いる事でデータの蓄積必要な仕組みなどを自社で構築する必要ないこと、場合によってはプラットフォームで共通に提供される外部データすら利用できる可能性がある事です。
また、業界デファクトスタンダードは重要な要素であるもの、他社も使っているので差別化には繋がりにくい「なかりせば負ける投資」であると言えます。ここに、自社独自の戦略を反映するAIをアドオンする事で「差別化要素構築の投資」に昇華できる事も重要なポイントです。
適合しそうなテーマが見つかったらチャレンジする価値があります。
4-3:No.1の強みをAIで「拡張 + 個別UX化」する
もうひとつAIの活用で狙いたい事は新ビジネス創出です。旧来のビジネスが成熟し新しいビジネス確立が求められる環境下ではAIはその肝となる有力候補です。
新ビジネスのテーマも様々なクライアントと意見交換をしていますが、その経験を踏まえて筋の良さそうなアプローチは自社のNo.1の強みをAIで「拡張 + 個別UX化」するアプローチです。
例えば、私の所属組織では将棋のアプリを提供しています。これは創業者がもともと将棋のアマチュアチャンピオンであったという「強み」を将棋AIによって「拡張」しており、各々の棋士の盤面において「個別に指導を受けるUX」を実現しています。
このアプローチが有用な理由はふたつあります。
ひとつめは価値のあるAIを構築するには「ドメイン知識」が必須であるからです。価値創出メカニズムや産業構造のトレードオフを深く理解していて初めてAIを適用すべき対象を厳選できます。そして、No.1の強みがある領域であればAIによる拡張に資するドメイン知識を有している可能性が高いからです。
ふたつめは「ドメイン知識」を総動員して何とかAIによる強みの拡張ができた場合に、既存の資産を活用できる可能性が高いからです。
世界的な戦略ファームであるベイン・アンド・カンパニー社が著書「企業価値４倍のマネジメント」の中で新規事業の成功率は既存の強み・資産との重なりが大きい事業の方が成功率が高いという調査結果を紹介していますが、同じ理屈です。
5章：より多くの人が自由な人生を送れる社会基盤
「何故、AIを社会実装すべきなのか？」の章にも書きましたが、私がAIを社会実装するモチベーションの根底は「生産性向上を通じより多くの人がより自由な人生を送れるようになる事」です。
とはいえ社会全体の生産性の向上には時間が掛かり、私が生きているうちには実現しないと思われるので、生きている間は「自分の人生も組織に縛られずもっと自由に過ごしたい」という願望もあります。
そのための生産性向上を大きくふたつの方向性で捉えています。ひとつ目はAIをはじめとしたテクノジーを社会の様々なユースケースで適用し社会全体の生産性が上がる事です。
これが実現すれば上手くいくと人類は必要以上に過重な労働に縛らなくなり、それぞれが得意な事で活躍できる社会に近づくと思っています。まぁ、そうなればなったでどうせ人類は別の問題や悩みを発明するのでしょうが。
ふたつ目が少数精鋭チームについて記載した様な、デジタルを活用して少ない人数で広範に価値を提供できるという環境を梃子にした「個人の生産性向上」です。
これまでも芸術・エンタメなど一部の産業・領域では個人の力のレバレッジが効いていましたが、同様の作用が他の様々な産業でも働く様になります。
COVID-19の影響によるジョブ型への働き方のシフトや複業の解禁、社会問題である労働人口の減少もこの動きを後押しするメガトレンドになるでしょう。
これら変化を上手く活用できれば「自分の人生も組織に縛られずもっと自由にしたい」は実現可能な目標であると思います。
「同じような事を考えているんだろうなー」と感じる方々にも仕事を通じてお会いする事も結構あり、そのような方々には一方的に組織を超えた仲間意識を持っています。
私の一方的な仲間意識の是非はともかく、組織を超えて同志で勝手に変えていっちゃおうぜ、という動きは過去に比べて格段にやりやすい環境になっているので、是非とも相互に助け合いながらやっちゃいましょう。
この記事が気に入ったらサポートをしてみませんか？