AI研究開発の成果はどう評価する？悩みに悩んだKPI設計を全部話します

みなさま、こんにちは。安藤(@anpyan)と申します。株式会社ACESでプロダクトマネージャーをしています。

私の所属するR&D部門では、東大松尾研究室出身メンバー達を中心とした専門家集団が最先端のAI技術研究を行っています。私たちの成果は、DXパートナーサービスの事業部や、ACES MeetをはじめとするAIソフトウェアサービスの事業部など、複数の事業部にAIモジュールとして提供され、実際のプロダクトやプロジェクトで活用されます。ざっくりと図にすると下記のような流れになります。

今回は、そんなR&D部門のKPIについてのお話です。
この記事では以下を説明します。
・R&D部門特有のKPIの難しさ
・KPIの具体的な設計（アウトプット量・質・アウトカム）
・KPI導入後に得られた効果と残課題

KPIとは

KPI（Key Performance Indicator）とは、目標の達成度を測るための指標です。つまり「どれだけうまくいっているか」を客観的/定量的に評価するためのものと言えます。プロダクトマネジメントにおいてKPIの設定と運用は非常に重要です。

R&D部門におけるKPIの難しさ

一般的なプロダクトの場合、例えばユーザー数やMRR(月間の収益)やチャーンレート(解約率)などがKPIとしてよく使われます。多くのユーザーに利用されれば成功、そうでなければ失敗とシンプルで分かりやすいです。また特定のプロジェクトの場合は業務改善効果やコスト削減効果などを計測することもできます。

しかし、R&D部門が作るAIモジュールにおいては、成果がすぐに数値として現れにくかったり、直接的に売上やユーザー数や業務改善効果に結びつかないケースも多く、KPIの設計は本質的に難しい課題です。

KPIを通じて知りたいことを整理する

私たちACESのミッションは「アルゴリズムで、人の働き方に余白をつくる。」です。このミッションのもと、R&D部門では最先端のアルゴリズムを独自モジュールとして開発し、技術的な探求と実際のビジネス価値創出の両立を目指しています。

私たちが取り組むべき技術課題はまだまだたくさんありますが、一方で、単に技術の数や量を追求しすぎるとリリース自体が目的になってしまい、顧客課題やビジネス価値が置き去りになってしまう、いわゆる「ビルドトラップ（作ることが目的になってしまう罠）」に陥ってしまうことがあります。

そうならないためにも、アウトプットの量だけでなく、アウトプットの質や、アウトカム（効果や結果）も併せて計測する必要があります。

ここまでの話を踏まえると、我々R&D部門のKPIには以下の要件が求められます。

R&D部門の努力や取り組みが直接的に影響できる指標であること
アウトプットの「量」を計測できること
アウトプットの「質」を計測できること
アウトカム(効果)を計測できること

さらに、管理すること自体が目的にならないよう、以下の要件も必須です。

できるだけ簡単に計測可能であること

これらを満たすKPI設計と運用が、私たちのような最先端技術の研究開発とビジネス価値創出の両立を目指すチームにとって、大切な鍵となります。

KPI1: アウトプットの量

まずはアウトプットの量、すなわち開発生産性についてです。

私たちのR&D部門では、新技術の調査や実験を繰り返すことも重要ですが、生み出した技術を事業部やお客さまに届けることも重視しています。新技術やプロトタイプをいかに速くフィードバックループに乗せられるかが研究開発の生産性に大きく影響するため、アウトプットの量を測る指標として、Googleが提唱したDevOps指標「Four Keys」の一つであるデプロイ頻度に着目しました。

具体的には「d/d/d (deploys/day/developer)：開発者1人1日あたりどれだけ頻繁にデプロイ（リリース）しているか」を計測しています。

これにより、チームがスピーディかつ継続的にビジネス価値を届けられているかを確認できます。

KPI2: アウトプットの質

次にアウトプットの質です。

R&D部門が生み出すアルゴリズムやAIモジュールに求められる質とは「正確さ」や「汎用性」の高さだけではありません。私たちが特に重要視しているのは、顧客が直面する具体的な課題や業務に特化して価値を提供できる「エキスパートAI」であることです。

エキスパートAIとは、一般的な汎用AIをベースに、特定の業務領域の専門知識や課題解決力を強化したAIモジュールを指します。エキスパートAIは汎用的なAIでは対応しきれない、より実践的な課題解決力を持ちます。

質の評価には他にも「処理速度」「スケーラビリティ」「メンテナンス性」などなど多くの要素が考えられますが、これらを個別に計測すると複雑化しやすいため、私たちは汎用AIがエキスパートAIへと専門特化していく手法やプロセスを Expertization(エキスパタイゼーション) と呼び、その成熟度をシンプルかつ実務的に評価する指標として、以下のような5段階の Expertizationレベル を設定しています。

Expertization レベル	内容
レベル1	汎用的な基盤技術をベースとしたAIモジュールです。特定領域への専門特化はこれから進めていく段階です
レベル2	特定の業界や業務に関する専門知識を組み込み、専門性を持ったAIへの第一歩を踏み出したAIモジュールです。汎用AIでは難しい領域特化型の処理が可能になります。
レベル3	専門性をさらに高めるための独自機構や改善プロセスを内蔵したAIモジュールです。単なる専門知識の導入を超え、継続的に特定分野への適応度を高めるための仕組みが組み込まれています。
レベル4	特定業界や業務の具体的課題に対し徹底的に最適化されたAIモジュールです。顧客の業務プロセスや固有の要件を深く理解し、高い適応力を持ちます。
レベル5	業界トップレベルの性能を持ち、顧客にとって「なくてはならない」存在となったAIモジュールです。競合製品や他の手段と比較して強力な優位性を持ち、顧客の意思決定において第一選択となります。

これによって、多数あるAIモジュールの価値、特に「エキスパートAIを軸にどのような成熟度にあるのか」が可視化されました。

KPI3: アウトカム

最後にアウトカムです。

私たちのR&D部門の最終的な目的は、単にAIモジュールを開発するだけではなく、社内で認知され、販売され、事業部を通じてお客さまに届けられ、最終的にはお客さまの環境で稼働し価値を生み出すことです。

そのため、アウトカムの計測では次のような観点を設定しています。

AIモジュールが販売されているか
- AIモジュールが社内で認知され、事業部のプロダクトやプロジェクトで採用・販売されている数を計測します。
AIモジュールが開発活用されているか
- AIモジュールが事業部のプロダクトやプロジェクトにおいて開発活用されている数を計測します。
AIモジュールが稼働しているか
- お客さまの業務環境において実際に稼働しているAIモジュールの数を計測します。

これらはそれぞれ、DXパートナーサービスでの 販売 → 開発活用 → 稼働という順番で進むプロセスに対応しているため、前段階の指標が次の段階の先行指標として機能します。例えば、販売数が多いソフトウェアは、その後の開発活用数や稼働数が伸びることを予測できます。また、販売数に対して開発活用数や稼働数が伸びていない場合は、導入や活用に何らかの課題があることを早期に把握できます。

また、アウトカムの観点を持つことで「なぜ作るのか」を考える必要が出てきます。技術的に優れたエキスパートAIであっても、実際に顧客価値として届けられなければ本来の目的を果たせません。どんな顧客のどんな課題を解決しようとしているのか？その顧客は今その課題をどうしているのか？どうやって顧客に届けるのか？などを考えることでビジネス価値をより意識した開発を行うことが可能になります。

KPIを設計/計測して分かったこと

これまで「アウトプットの量」（KPI1）の計測は行っていたのですが、ここに「アウトプットの質」（KPI2）と「アウトカム」（KPI3）を追加したことで、以前は曖昧だったAIモジュールの成熟度や活用状況が明確になり、チームとしての意思決定がスムーズになりました。

具体的には、次のような判断や議論が可能になっています。

「このAIモジュールはまだ完成したばかりで成熟度は高くない（レベル2）けど、想定以上に販売が伸びている。もっと積極的にリソースを投入し、成熟度を高めることでさらに大きな価値を提供しよう」
「こちらのAIモジュールは成熟度が高く（レベル4）、多くのお客さま環境で実際に稼働している。しかし最近新規の販売が伸び悩んでいる。何らかの課題が潜んでいるはずなので、詳細な分析をして次のアクションにつなげよう」

このように、KPIを通じてAIモジュールごとの状況を定量的に把握できるようになった結果、チーム全体の判断や議論の質が向上しました。

まだまだKPIには課題も多い

KPI1に加えてKPI2と3の計測を始めたことで数多くのメリットが得られましたが、一方で解決すべき課題や改善ポイントも浮かび上がっています。課題はたくさんありますが、ここでは以下の2点を挙げます

① 「アウトプットの質」のレベル評価基準をもっと明確化したい

「Expertizationレベル」という指標は、汎用AIがエキスパートAIへと専門特化していくプロセスをシンプルに評価できるよう表現されています。しかし、実際に運用してみると、ソフトウェア品質に関連する複数の要素が絡み合い、レベルの判定が曖昧になりやすいことがわかりました。現在は、これらの要素や関連する技術・手法の整理・構造化を進めており、今後はそれらを踏まえ、より客観的かつ実務的に運用できるよう評価基準を整備していく必要があります。

② 「アウトカム」の精度を改善したい

現在、AIモジュールの「販売状況」として、どれだけのサービスやソリューションで “採用されているか” の数で計測していますが、採用されている中でも ”よく提案されているもの" と "あまり提案されていないもの” に分かれそうです。できれば「事業部からお客さまに対してされている提案回数」や「提案された顧客の反応」のような高解像度な把握もしたいです。

とはいえ、逐一提案数や反応を記録するのは負担が大きいため、私たちが提供しているACES Meet（会議や商談の音声を音声認識し議事録を作成できるAIサービス）を活用して、商談中にどのAIモジュールが提案されたか・顧客の反応はどうだったのかを自動計測するなどの方法を考えています。