DeNAでは、AIネイティブなプロダクト開発を推し進めるための「AIイノベーション事業本部」が存在しています。僕は、普段はDeNA DESIGN全体の戦略マネジメントを行いつつ、AIイノベーション事業本部のデザイナーの一人として、新たなプロダクトの開発も日々行なっています。

全社を挙げてAIによる「生産性向上」と「新規事業創出」にフルコミットするDeNA
AIネイティブなプロダクトがリリースされ始めている

今回は、このようなAIネイティブ度 (詳細は後述) が高いプロダクトにおいては、これまでと異なるデザインプロセスが必要になっていることが分かってきたため、その背景や現在のDeNAのAIイノベーション事業本部でのユニークな開発フローについてまとめてみます。

DeNAのAIイノベーション事業本部では、ソフトウェアの一部にAIを組み込むだけでなく、システムのコアな体験がAIで構成されているようなプロダクトをつくることにもチャレンジしています。

AIイノベーション事業本部では、このようなプロダクトを「AIネイティブ度が高い」と表現しています。

DeNA AIイノベーション事業本部における、AI-Nativeなプロダクトの定義

AIネイティブ度が高いプロダクトは、体験の自由度が高いのが特徴です。

これまでのソフトウェアでは、設計されたシステムによってルールベースに制御された挙動をしていました。一方で、AIネイティブ度が高いプロダクトでは、ある入力に対しての回答は無数、そこに対してのユーザーの入力も無数、、とユーザーの使い方によって無数の挙動が生まれます。

このような特徴を持つため、AIネイティブ度が高くなればなるほど体験設計が難しいということになります。

これまでのソフトウェア設計と比べて、AIネイティブ度の高いプロダクトでは、体験のパターンが無数に分かれ、想定しきれない

このように無数のパターンの体験が存在しているAIネイティブ度の高いプロダクトの開発は、既存のワークフローでは対応しきれません。

例えば、以前のソフトウェア設計においては、体験を想定するためにユーザーの行動をフロー図で整理するようなことを行っていましたが、AIの無数の挙動をフロー図で整理することは現実的ではありません。

AIネイティブ度の高いプロダクトの体験を、これまでのようにフロー図で整理するのは限界がある

とはいえ、期待された価値に対して適切な結果を返していくのがサービスだとすると、AIネイティブ度の高いプロダクトだとしても、体験をコントロールしなくて良い訳ではありません。

このような背景で、AIネイティブ度の高いプロダクトを開発するための、新しい体験設計の手法が必要になってきました。

そこでAIイノベーション事業本部で行き着いたのが「プロトタイプドリブン」な体験検証を行うことでした。

これまでのように、チーム内で要件を話し合いながら体験を設計する方法ではなくて、プロトタイプをベースに検証を進めながら体験を確かめるようなフローを取っています。

プロトタイプドリブンな体験検証

私たちは、AIネイティブ度が高いプロダクトを設計するときは、最初からプロトタイプで検証を進めるように切り替えていくべきだと考えています。

プロトタイプドリブンな体験検証の実例として、AIイノベーション事業本部で開発している、AIマッチングサービス「fromm」での新機能検証プロセスを紹介します。

AIマッチングサービス「fromm」での新機能開発の例

このfrommの開発では、最初からAIを用いたプロトタイプを用意して、体験を確かめながらプロトタイプをブラッシュアップしていく形で進めています。静止画やFigmaのデザインデータでは「AIからのメッセージに対してどのような印象を持っているのか」「本当に行動が起こるのか」ということが確かめきれないので、必ず動く実装されたものを用意します。

frommのユーザー体験や、集めるべきデータ構造を「AI Data Flywheel」として整理する

AIプロダクトは有効なデータが貯まれば貯まるほど、プロダクトの価値や独自性が強まります。なのでプロダクト全体の体験を「ユーザーの理想的な行動」「それを行うための機能」「実現するためのデータ」で整理しているのが、AI Data Flywheelです。

このフライホイール (=はずみ車、一度回り出すと止まらなくなるようなサイクル) の中で、どこをより強めていくのかを考えます。

(今回は、frommで相手とマッチングし、通話した後に、通話内容や話し方などに関してのアドバイスを行う「トーク診断」機能を検証することにしました。)

フライホイールの中で、どこを強めるのかを考えて、新機能のアイデアが生まれた

ここから、AIを活用して、すぐにPdMが要件やプロンプトを作成します。(ここまで1日未満)

機能アイデアが固まったら、AIを活用して、すぐにPdMが要件やプロンプトを作成

必要に応じてAIエンジニアが修正・改善を行いつつ、検証のためのプロトタイプテストをすぐに行います。

AIが出力するアドバイスを、適切なタイミングで送付することで、本当に価値が生まれるのかを検証できれば良かったので、新機能のUIをつくらず、希望するユーザーに既存のメッセージ画面の中でテストを行いました。

プロンプトから出力されたメッセージをユーザーに送付してみて検証。すぐ検証したいので、この新機能のために新しいUIをつくるようなことはしない

最初からすべてのシステムをAIエージェントでつくるのではなく、このような検証段階では、裏側は手動オペレーションで実施する部分もつくることもあります。

今回でいうと、ユーザーの方への返信などは運営が手動で行うこととし (送付するメッセージ自体はAIにつくってもらったもの)、その管理画面をエンジニアがサクッと実装しておきます。

また、ユーザーへの告知・利用促進・フォローなども、FacebookのメッセンジャーやLINEなどで行い、できるだけ最小工数で検証を行うようにしていました。

コアな検証以外はできるだけ最小工数で実装
メッセージ送付や、ユーザーへの告知など、手動で行える部分については手動オペレーションで対応した

結果として、この機能は現時点では有効ではないと判断し、検証を停止しています。

プロトタイプの検証を踏まえて、現時点では検証を停止することに。(ここまで2週間で完了)

ここまでの検証は、計測も含めて、2週間で終えています。AIを活用したプロダクトの機能は、そもそも検証してみないと体験が成立するかも分からないことが多く、早くプロトタイプして検証すること・側の部分は手動でも良いので出来るだけ工数少なく検証できるようにすること、が大事だと思います。

このように、AIイノベーション事業本部の中で、プロトタイプドリブンな体験検証の進め方が必要になってきたことを受けて、部署全体として開発ワークフローの更新が起こりました。

これまでは、プロダクトの仕様や企画をまとめる時に、ドキュメンテーションされた要件定義書をつくることが必須だったのですが、これに加えて、AIイノベーション事業本部では企画段階で「生成AIを使ったプロトタイプ」を持ち込むことが必須となっています。

AIイノベーション事業本部では「企画を通す際にプロトタイプが必須に」

さらに、プロトタイピングは、デザイナーの仕事というわけでもなくなっています。

AIイノベーション事業本部では、各職種が生成AIを活用してさまざまなプロトタイプをつくります。デザイナーが過去にGeminiで進めたプロトタイピングのプロセスを踏襲して、PdMが自分でGeminiでプロトタイプをつくっていたり。

PdMが自分でGeminiを使ってプロダクトの体験を確認できるようなプロトタイプを作成

ゲーム系のプロダクトであれば、PdMが自分でサービスのコンセプトをまとめた紹介動画を1〜2日でつくったり。

ゲームプロダクトのPdMが、1〜2日でサービスのコンセプトをまとめた紹介動画をプロトタイピング

また、これまでUIデザインを行っていなかったグラフィックデザイナーが、プロダクトのUIプロトタイプをつくり、プロダクト立ち上げ時の初回の打ち合わせに持ち込んだり。

グラフィックデザイナーがプロダクト立ち上げ時の初回打ち合わせに、UIプロトタイプを持ち込む例

このように、これまではプロダクトデザイナーが主に担っていた「UIデザイン」「プロトタイピング」という仕事が、さまざまな職種に解放され、常にプロトタイプを用いて体験や印象を確認するような進め方がAIイノベーション事業本部のみならず、DeNA全体に定着しつつあります。

このような変化の中で「デザイナーは何を行うべきなのか?」という問いにも考えを残しておきます。

私は、さまざまな職種からつくられたプロトタイプや、生成されたクリエイティブを、ユーザー視点で良し悪しを見極め、最適な体験を選ぶことこそがデザイナーの役割だと思っています。

なんとなくそれらしいアウトプット、ではなく、本当に価値のあるユーザーの体験が生まれるアウトプットに昇華していくためには、デザインの専門性をもとに体験のディレクションをすることが変わらず必要です。

AI時代のデザインプロセスは、仮説と具体が何度も往復する。その良し悪しをユーザー視点で判断するのがデザイナーの役割

逆に、それ以外の役割は積極的に手放すべきだとも思います。

前述したように、プロダクトのモックアップをつくるといった初期の仮説を出すのはPdMにお任せしている場合もあります。必ずしも、仮説を絵にまとめたり、プロトタイピングをデザイナーが担う必要はありません。

プロトタイプをつくることはどんな職種でも行っていくべき。逆にデザイナーは、つくられたアウトプットがユーザーに受け入れられるようにディレクションすることに責任を持つ

このようなプロトタイピングを軸とした開発プロセスから、体験を磨き込み、すでにいくつものAIネイティブ度の高いプロダクトがリリースされています。

AIイノベーション事業本部から生まれているいくつものAIネイティブ度の高いプロダクト

代表の南場の宣言でもあるように、DeNAはこれからAIを活用したプロダクト開発に全社を挙げて取り組んでいきます。toCでいうとLLMを具体的なユースケースに当てはめたアプリケーションレイヤー、toBではバーティカルなドメインの業務を支えるAIエージェントを、いくつも開発しているところです。

AIネイティブ度の高いプロダクトの成長サイクルを考えると、まずユーザーに使ってもらうというのは一歩目でしかありません。

そこで無数のデータが溜まってきてからこそ、データを軸としてさらにAIの真価が発揮されます。つまり運用に乗ることが最も大事ということなので、まず最初にユーザーに受け入れられるための行動をつくるのはとにかく早くやらないといけません。

さらにAI時代に最適な開発プロセスを磨いていけるように、これまでの開発プロセスを疑いながら、新しいワークフローをつくっていきます。

最後に、私の目線で、なぜこのような開発フローの変化が必要となるのかをまとめます。

私は、このような技術変革のタイミングでは、これまでの業務が再編され、新しい職種や、デザインポジションが生まれる可能性が高いと考えています。なぜなら、つくるものが変わるなら、必要な職種やデザインプロセスも変わって当たり前だからです。

例えば、紙やリアル製品が中心だったところから、ソフトウェアが登場した時、合わせて必要な職種も変わってきたと思います。グラフィックやハード製品のデザインから、情報設計/UIデザイン/体験設計/リサーチなどの新たなデザイナーの役割が生まれてきました。

同じように、これからAIネイティブなプロダクトが生まれてくると、それに合わせて新たな職種やポジションが生まれるはずです。

これまでも「紙やリアル製品」から「ソフトウェア」へとつくるものが変わってきた時に、必要なデザインの取り組みや職種も変わってきた。同じように「AIネイティブなプロダクト」をつくるなら、必要なポジションも変わるはず

DeNAではすでに、AIスキル度合いが全社の評価の仕組みにすでに組み込まれています。合わせてデザイン職種でも同じように、AI活用レベルを組み込んだ評価制度を用意しました。

これから、新たなワークフローがどんどん生まれていき、その再現性を生むためのポジション誕生などが起こるはずだと考えています。

これから起こる組織再編の一歩目として、評価制度も変更

DeNA Designでも、これから増えていくAIネイティブなプロダクト体験をつくるための、新しいデザインポジションの形を見つけていきたいと思います。

このデザイン組織をもっと知る