PMは仮説検証とアジャイル開発を使いこなす「両利き」を目指そう
この考え方はアジャイルにも通ずる。アジャイルは開発内のターンアラウンドを短くするためのものだ。つまりプロダクト開発にアジャイルを取り入れると、全体の段階設計とスクラムにより、ターンアラウンドが構造化されることになるのである。
「何を作っていけば良いのか、この方向性で良さそうだという意思決定のタイミングを増やすことができ、方向性を変えるタイミングを複数持てるようになる。そのため、人に必要とされるプロダクトにたどり着く可能性を高めることができる」と市谷氏は説明する。ターンアラウンドを最短最適化するために必要なのは、仮説検証とアジャイル開発なのだ。
だからこそプロダクトマネージャーは、仮説検証とアジャイル開発を使いこなす「両利き」であることが理想。「片側しか分からないままだと、結果に偏りが出る」と市谷氏は指摘する。
仮説検証に偏重していると、プロダクト開発時の開発内ターンアラウンドが長くなってしまい、一方アジャイル開発に偏重していると、全体のターンアラウンドが長くなる可能性があるという。詳細はそれぞれの専門家に任せるにしても、この二つの専門的な知見がなければ意思決定の精度は上がらないという。
「一つでも大変なのに、どうすれば良いのか」と思う人は多い。だが、「両利き」を実現するための作戦が二つあるという。
第一の作戦は専門性の獲得を段階的に行うことである。仮説検証やアジャイル開発の専門性を段階的に獲得するには、一度にやる範囲を小さくして、仕事の一回りを短くすることだ。そうすることで全体を通した経験が早く手に入り、結果として次の活動の最適化が早く始められる。また全体が分かると、どこに何が足りないのかも分かりやすくなる。つまり小さく、短く、一巡させるのである。そして仕事の一回りを短くするための段階の設計をする。
例えば1段階目では基礎的な知識習得のため、仮説検証の研修を行う。ここで疑似プロジェクトを設置するなどして、できるだけ手を動かし、体験を増やしていく。2段階目ではチーム外の関係者が少ないパイロットプロジェクトを実施する。ポイントは途中で終わっても大勢に影響がないものを選ぶことだ。3段階目でMVP開発・検証を行う。ポイントは長期間に及ぶ規模の大きなプロジェクトではなく、MVPの概念が適用できるテーマを選ぶこと。検証やローンチなど実際の目標到達まで目指すのである。
「パイロットプロジェクトの段階を飛ばすことが多いが、疑似的な開発と実際の開発には乖離があるので、必ず挟むことをお勧めする」と市谷氏は力強く語る。
第二はチーム内での役割の補完、チームで専門性を分担する作戦である。各段階に必要な専門性を担うメンバー、チームを定義し、連動するように設計する。プロダクトマネージャーは自身の不足する専門性を各メンバーに補完してもらうわけだ。だが、このような進め方をすると、意思疎通がうまくいかない、コミュニケーションが途絶えがちなど、分断が起こりやすい。それを防ぐために、仮説の外在化と重奏化を目指すことが重要になる。仮説の外在化とは仮説をしっかり立てて見えるようにする。こうすることで自分たちがやっていることに対する意見や疑問などを表明ができるようになる。仮説の重奏化とは、個々人の仮説を許容し、適宜チームの理解を更新していくことである。
「プロダクトマネージャーとは、ユーザーのフィードバックにただ反応していくための存在ではない。プロダクトを通して、社会のより望ましい状況を作り出すことが仕事である。そのためにチームと共に自分たちの世界観を描き、その実装に向けてターンアラウンドを実行し続けましょう」（市谷氏）
熱く盛り上がったQ＆Aタイム
Q＆Aタイムでは、現場での課題を中心に、多くの質問が寄せられた。
「コンサルタントからプロダクトマネージャーへのキャリアパスとしてどんな可能性があるのか」という質問に対しては、「慣れると思うが、何のコンサルかによってパスが異なる。例えば事業開発のコンサルタントであれば、仮説検証の立ち位置、アジャイル開発のコンサルタントなら、アジャイルの立ち位置から始め、得意としない知見を段階的に学んでいけば良い」と回答。
「チームの中での仮説の洗い出しや見える化ツールでお勧めのものを教えてほしい」という質問には、「キャンバス系のツール」をお勧めした。キャンバスでは大抵1枚の絵の中に情報をまとめていくことになる。そのためプロダクトを作る上で最小限必要な項目、最初に考えておくべき項目など、簡潔に書くしかない。だからこそ、認識を合わせるのに重宝するという。
「仮説の不在が起きている。この状態から仮説検証を回していくためにはどうすれば良いでしょうか」という質問には、「今やっているプロダクト開発の中でいきなり仮説検証を織り込むのではなく、仮説検証に関する書籍をチームの中で読み始めたり、勉強会を始めたりということから始めるのがお勧め。また研修を行う場合は、疑似的でも良いので、自分たちの手を動かしアウトプットことを織り込んでいくこと」と回答した。
また、「パイロットプロジェクトが必要なことが分かるが、仕事でそこをコントロールすることが難しい。そういったときにMVP開発検証をどのように進めると良いか」という質問に対しては、「パイロットプロジェクトの時間や予算をとってもらいたい。車の運転と同じ。プロダクト開発をど素人がいきなりやるのは、車の運転をしたことのない人がいきなり高速道路を走るのと似たようなこと」と説明。「時間の使い方の割合を決めて、1カ月の中で何割かをパイロットプロジェクトに当てるなどしてほしい。実際に実践している企業がある」とアドバイスした。
最後に「自社開発のプロダクトマネージャーがない組織で、その役割を作りたいと思っているが、何から手をつけるのか迷っている。個人的にはまず組織を作って、ムード情勢をしていくのが良いのかと思っています」という質問。
市谷氏は、「組織を先に作るのは辞めた方が良い。まずは自社開発に必要なプロダクトマネジメントに必要なタスクを試す場を作る。そして失敗できるような機会、時間を作り、その中でトライしていく。そうすることで、自社でプロダクトを作るというのはどういうことなのか、何に困り、どこが難しいのかを把握していく。その上で自分たちが必要なもの、強化すべきところはどこかを見極めていく。そういうプログラムを作っていくのが良いと思います」と回答し、セッションを締めくくった。
さらに、当日回答しきれなかった質問にも、以下のように回答いただいた。
Q：仮説検証時に、良しあしを判断するために注意されていることは何かありますでしょうか？
仮説検証の解釈をいかに注意深く行ったとしても、検証結果自体がバイアスを含んだものだと、判断を誤ってしまうことになります。どのようにして得られた検証結果なのか？まずはそこを問うことから始めたいところです。
Q：日本企業、SIあるあるで、開発機能を持たない＆外注開発が主な場合、アジャイル的な動きがとりづらく外部委託部分はウォーターフォールモデルをとる場合が多い（スピード感が遅くなる）かと思います。外注開発をしながらアジャイル的な動きをする際のアドバイスなどございますでしょうか（パートナーと同じ目線になるための工夫など）。
われわれはなぜここにいるのか？ そのプロダクト開発のwhyを問うことをチーム、関係者を含めて行うことかと思います。whyを取り違えているうちは、アウトプットについてのフィット感は弱いものになります。
Q：営業を抱えるフロント事業部と、プロダクトマネージャーが属するであろうサービス・商品を企画する部署（例：サービス・商品企画部）の二つがあるかと思いますが、プロダクトマネージャーが負う責任は何になるのでしょうか？
プロダクトの価値を最大化していくこと、すなわち、プロダクトで果たすべき目的をいかにして達成するかです。
