プロダクトバックログがフィーチャーリストではなく課題の優先順位リストになっていると、変化に対応しやすくなる。フィーチャーを届けることを早いうちから約束する必要はなく、新しい技術が利用可能になれば、それを使うことができる。ロードマップを見える化し、定期的に新しい情報を取り込み、それを用いてロードマップを評価することは、アジャイルであり続けるのに役に立つ。
Atlassianでプロダクトマネージャを務めるJonno Katahanas氏は、Portfolio for Jiraのチームがどのようにロードマップを構築しているかAtlassian Summit 2018で説明した。InfoQではサマリとQ&Aでこのイベントについて紹介する。
長期的および短期的なロードマップの構築、変化に対応するためロードマップをアジャイルにし続けること、プロダクトロードマップ管理のヒントについて、Katahanas氏にインタビューした。
InfoQ: Portfolio for Jiraのロードマップ作りには誰が関わっているのですか?
Jonno Katahanas: 大勢です! 今後3年間のハイレベルな計画を立てるときは、とても大勢の人が関わります。これは取り組むべきことをリストにした典型的なロードマップとは異なります。Portfolioが何を目指すべきか、私たちにとって成功はどのようなものか、もっと明確に表現したものです。社内では、プロダクトのデザイナー、エンジニアリングマネージャ、プロダクトマーケッターと緊密に働き、初期の3年計画のドラフトを作ります。これは主に、私たちがすでに知っていることとコアチームとして実施している追加の調査に基づいています。社外では、ニーズとペインポイントを理解するために、顧客との対話に多くの時間を費やします。また顧客の理解を深めるために、他の様々なチャンネルを調査します。例えば、サポートチームからのフィードバックやアプリ内アンケートなどです。
直近1年の短期的なロードマップを見ているとき、社外からの視点では、顧客から得た反応やフィードバックを重視します。社内からの視点では、プロダクトマネジメント、デザイナー、エンジニアリングマネージャ、プロダクトマーケッターがコアチームに参加します。最後に、ロードマップにおいて何がどこで終わるか最終判断するのは、一般的にプロダクトマネージャです。でも、この決定は、チーム内の他のメンバーによる多くのインプットと議論をもとに下されます。必要に応じて、特定のロードマップアイテムに関係する他チームの人を呼んでくる場合もあります。ロードマップに別のチームに依存するようなものがあれば、できるだけ関わってもらうようにします。おかげで潜在的な障害物に取り組む時間が増やせています。
InfoQ: ロードマップがアジャイルであり変化に十分対応できることを、どうやって確かめるのですか?
Katahanas: 私たちがどうやって短期の1年のロードマップを作っているかに焦点を当ててお答えします。1年のロードマップを構築する際には、作るべきフィーチャーではなく、その1年で解決すべき課題リストを用意することを目指します。これは私が見てきたパターンに反しています。よくあるのは、プロダクトチームがロードマップを、出荷する予定の長いフィーチャーリストとして構築することです。チームが9ヶ月のうちに出荷する予定の機能を教えてくれるのは、珍しいことではありません。
フィーチャーではなく課題の優先順位リストとしてロードマップを持つことにフォーカスするのには、2つの理由があります。1つは、好むと好まざるにかかわらず、日付のついたフィーチャーをロードマップに追加するとすぐに、ステークホルダーはコミットメントを意味していると受け取るためです。その時点でそのフィーチャーを出荷するというコミットメントだと思うのです。ここでの課題は、顧客が望んでいるものや必要としているものが、6、9、あるいは12ヶ月間、確実に今と同じであるかがわからないことです。私たちが実際に問題に取り組むとき、どうすれば彼らのニーズに最もかなう機能がわかるでしょうか? 多くのチームは、自分たちはアジャイルでやっていて、顧客のニーズに対応して絶えずイテレートしている、と言います。でも、もし何ヶ月も前にフィーチャーを出荷するとコミットしていたなら、これはどうやって実現できるのでしょうか? こうした無意識のコミットメントはみな、ずっと前からフィーチャーと日付をロードマップに載せるという単純な行為によって起こります。
2つめの理由は、技術による変化の度合いにあります。技術は急速に変化しており、今は不可能かもしれないことが、1年のうちに非常に容易になる可能性があります。つまり、最初にロードマップを計画した時点では不可能だったフィーチャーも、ロードマップにある課題に取り組むときには可能かもしれないということです。例えば、私たちのプロダクトでは、ユーザーが巨大なデータセットを管理するために使うテーブルのユーザビリティ改善を進めています。最近は、技術スタックにも内部的な改善を加えました。現在出荷を検討しているソリューションのいくつかは、去年、1年のロードマップを作成した時点では実現不可能だったものです。
InfoQ: どんなことを学んできましたか?
Katahanas: おそらく最大の学びは、ロードマップ作りのプロセスは、単にやるべきことのリストを日付をつけて書くという行為ではない、ということです。今ではおかしいと思っていますが、プロダクトマネージャになる前は本当にそう書くものだと思っていました。典型的なロードマップだと思っているもの、ものごとに取り組む予定の時期と各作業アイテムに要すると思う時間の優先順位リストを書き始める前にも、ロードマップに関連した作業は非常にたくさんあります。
多くの人はロードマップ作りのプロセスを、やるべきことのリストを書く行為を意味していると受け取っていますが、優先順位づけした作業の物理的なリストを作り始める前にやってくるすべての基本的な活動を効果的に考慮していません。こうした基本的な活動には、プロダクトの長期計画をもっと明確にすることなどが含まれます。チームは3-5年先をみて、プロダクトが何を目指しているのか、どうやってプロダクトがマーケット勝利を収めるのか、成功はどのようなものかを定義することが重要です。これはプロダクトチームが来年の短期ロードマップに何を追加するか決めるときに、焦点を合わせるのに役立ちます。
InfoQ: チームがプロダクトロードマップを管理するためのコツは何ですか?
Katahanas: ロードマップ作りのプロセスで、チームにとって本当に役立った重要なコツが2つあります。
1つ目は、プロダクトの長期的方向性に関して共通理解を築くための仕組みをプロダクトチームが持つことです。これを助けるために、Atlassianの全プロダクトチームは"VSO" というフレームワークを採用しています。"VSO" は、Vision(ビジョン)、Strategy(戦略)、Objectives(目的)を表しています。これは1ページで、次の3年でプロダクトがどこへ向かうのかを明確に定義するのに使います。それができると、全員が同じページを見られるように、プロダクトチームの内外に共有します。これは本当に便利です。短期の1年のロードマップを作成し、何に取り組むべきかを決める際に、フォーカスとガイドレールを与えてくれます。
2つ目は、とても重要なことです。定期的に新しい情報を入手し、それを使ってロードマップを再評価することです。チームはロードマップが現実的かどうか、定期的に再評価する必要があります。これは時間の経過とともに、様々なレベルの情報を検討する必要があるためです。休む人もいれば、チームに加わる人もいます。問題の解決が非常に複雑で、価値あるものを出荷するには時間がかかることにチームは気づきます...。新しい情報が明らかになったら、それをロードマップに反映させて、必要なトレードオフのある判断についてチームと話し合う必要があります。こうした判断は通常、作業スコープ、作業をすべき人員、作業完了までに与えられる時間に基づくトレードオフになります。例えば、誰かが休めば、作業をする人が減ります。同じ量の作業を少ない人数で時間をかけてやるか、もしくはスコープを減らすか、決める必要があります。新しい情報を検討する時間をかけなかったために、世界に誓ったのに届けられないという罠に陥ってはいけません。
Rate this Article
- Editor Review
- Chief Editor Action