kaji あらゆる面での「不確実性」が大きな課題になっていた。
開さんは、現在どのようなプロジェクトに取り組まれているのでしょうか？また、そのなかでどのような役割を果たしていらっしゃるのですか？
開さん：私は、プロダクトマネジメントグループのマネージャーとして、ピープルマネジメントが中心の役割です。自分がメインでプロジェクトに取り組むわけではなく、メンバーの成長支援、プロセス整備を担当しています。
お二人から見て、クラウドサインがプロダクト開発において直面する課題とはどのようなことでしょうか？
吉本さん：不確実性だと思いますね。
価値が不確実であるということが、まず一つ大きな課題です。「提供するものに本当に価値があるのか？」が分からない状態から始めなくてはならないということが起点となり、仮説検証型アジャイル開発を採用するにあたって、今回ご支援いただいた次第です。
開さん：価値の不確実性ということでは、MVP（Minimum Viable Product。お客様に価値を提供できる最小限のプロダクト）の特定の仕方に非常に苦戦してきました。つまり、ある機能におけるMVPの定義が異なるために組織内での合意形成が得られにくいことが課題になっていました。
原因は、そもそもの目的が明確になっていなかったからだと思います。検討するプロセスにおいて、必要な（不足している）情報はそれぞれ違うんですよね。そこを整えるために仮説検証を学び、各自が必要な情報をインプットすることができるようになったことで、格段に合意が得られやすくなりました。
吉本さん：例えば、「XXXという機能が必要なんです！」というお客様の声を受けて作ったものの、リリースしてみたら全然使われない機能であったり、または、致命的な（それがないと使い物にならない）機能の抜け漏れがあったりと、価値の不確実性からくるリスクがしばしば発生するシーンもありました。
開さん：もう一つ、スケジュールの不確実性もありました。当初は、「A機能」といった形でロードマップに起こした段階で開発期間の見積もりをしていました。いわゆる不確実性コーンの初期コンセプトの段階ですから、そもそも実現が極めて困難な話です。
吉本さん：エンジニアのリソースは一定で、固定のリソースプールの中で開発していかなくてはなりません。そのため、特に工期のスケジューリングにおいて見積もりの精度の低さが負担になることが課題でしたね。
仮説検証、価値探索の方法が確立したことで、根拠を持った優先順位付けができるようになった。
まさに、仮説検証を必要とされていたということだと思いますが、実際の理解や実践の状況はどうだったのでしょうか。また、今回の取り組みでどのようなことを感じられましたか？
開さん：仮説検証を学び、価値探索をした上でスコープをきってスケジュールを見積もれるようになったのは大きな変化です。
この一年はロードマップとのつきあい方に苦戦したのですが、原因として優先順位の不確実性が難しかったと思います。例えば、セールスとカスタマーサクセスでは見えている優先順位が違ったり、お客様においても業界や規模によって優先順位がそれぞれあるなかで、どこをセンターピンとして捉えるのかという基準を明確にする必要がありました。
仮説検証を学ぶ前からアジャイル開発には取り組んでいましたが、小さく作って小さく検証するというだけでは最大効率化は図れません。仮説の段階でヒアリングや検証を重ねるという方法が確立してきたことで、抱えていた課題の解決とともに効率化が進んできたという感覚があります。
少なくとも仮説検証した上での、根拠をもった優先順位付けができるようになったことは大きな変化です。
吉本さん：一通り取り組んでみて、今後は同じくらいのクオリティのものをより高速で出せるような仮説検証の高速化をしていく必要があると感じます。
例えば、Googleでは1週間で価値探索に近いデザインスプリントをまわしていると聞きます。ですので、我々もスピードアップのための方法を常に考えています。とはいえ、単にあるステップを省けばいいというわけではないと思います。各ステップにおいて、作る粒度を柔らかくしたり緩和したりすることで、最終的な成果には影響がないような形で仮説検証を回していく方法について、今まさに検討しているところです。
プロジェクトとしては、仮説検証、価値探索を終えてアジャイル開発待ちの状態のものがいくつかあり、そのうちの1つは価値探索をした上での開発期間の見積もりまで完了しています。価値を出すユーザーストーリーを描けているものですし、スタート地点としてはとても良い状態にあると感じています。
後編へ続きます。