昨日までの正解が、今日も正しいとは限らない。
市場、技術、ユーザーの価値観が絶えず変化するVUCAの時代では、時間をかけて完璧な計画を作るより、素早く試し、ユーザーから学び、軌道修正することが重要です。
AgileやMVPが重視される理由も、変化に対応しながら、学習のサイクルを速く回すためだと考えています。
以前の私は、エンジニアとして求められた機能を素早く実装することが、プロダクトへの一番の貢献だと考えていました。
けれど、生成AIによって実装速度を上げやすくなった今、ただ速く作るだけでは、良いプロダクトを作ることはできないと痛感しました。
「速く進める」と「速く実装する」は違う
振り返ると、私は「プロダクトを早く前に進めること」と「機能を早く実装すること」を取り違えていました。
目の前の要望に応え、UIや機能を素早く変更する。
コードを書いて成果物が増えれば、プロダクトが前進しているように感じられます。
しかし、本当に考えるべきなのは、
- 誰に、どのような価値を提供するのか
- このプロダクトのコアバリューは何か
- なぜ、この機能を作るのか
ということです。
以前のプロダクト開発では、この判断軸が曖昧なまま実装を進めてしまいました。
目の前の要望やUIの変更には素早く対応していましたが、プロダクト全体として届ける価値が明確ではなかったため、表面的な仕様変更を繰り返すことになりました。
変更のたびに設計の一貫性が失われ、別の箇所との矛盾が生まれ、手戻りが増えていく。
一つひとつの実装は速くても、プロダクト全体では、むしろ開発生産性が下がっていました。
MVPの目的は、小さく作ることではなく、早く学ぶこと
この経験から、AgileやMVPにおける「速さ」の意味を捉え直すようになりました。
MVPは、単に機能を減らして、早くリリースするためのものではありません。
プロダクトにとって最も不確実で、最も重要な仮説を、必要最小限の方法で検証するためのものです。
重要なのは、どれだけ多く実装したかではなく、
- どの仮説を検証したいのか
- そのために本当に必要な機能は何か
- 何を作らないと決めるのか
- 結果から何を学んだのか
を明確にすることです。
プロダクト開発における本当に必要とされるスピードとは、Outputを増やすことではなく、
価値仮説を定め、意思決定と学習のサイクルを速く回すことだと学びました。
コアバリューからプロダクトを設計する
この学びを踏まえ、生成AIを活用した新規プロダクト「Journal with AI Coach」では、企画・設計の段階から、
- 誰に、どのような価値を届けるのか
- ユーザーは、どのような課題を抱えているのか
- ユーザーにとってのコアバリューは何か
を考えることから始めました。
市場を調査し、複数のMVP案を比較しながら、個別機能ではなく、プロダクト全体として届けたい体験を整理しました。
そして、その価値を一貫したプロダクトとして形にするために、DDD（ドメイン駆動設計）を取り入れて設計しました。
UIや個別機能から考えるのではなく、プロダクトが向き合う課題や重要な概念を整理し、ドメインモデルとチームの共通言語へ落とし込んでから実装するアプローチです。
コアバリューとドメインモデルを判断軸にすることで、新しい要望が生まれたときにも、
- この要望はコアバリューにつながるのか
- 既存の概念やルールと矛盾しないか
- 今、本当に作る必要があるのか
を考えられるようになります。
AI時代だからこそ、価値を考える
生成AIによって、コードを書く、UIを作る、プロトタイプを作るといった作業は、これまで以上に速くなっています。
しかし、実装が速くなっても、AIが自動的に「誰に、どのような価値を届けるべきか」を決めてくれるわけではありません。
AIによって「作る速さ」が上がるからこそ、
- 何を、なぜ作るのか
- 何を作らないのか
- ユーザーは何を求めているのか
を深く考え、ユーザーを知ることの価値は、これまで以上に大きくなっていると感じます。
速く作ることは、これからも重要です。
ただし、その速さは、表面的な変更を繰り返すためではなく、価値仮説を検証し、ユーザーから学ぶために使わなければなりません。
これからは、技術を使って素早く実装するだけでなく、ユーザー、事業、開発に関わる人たちと向き合いながら、本当に届けるべき価値を見つけ、それを持続的に成長できるプロダクトとして設計できるビジネスパーソンを目指します。
