メンバー全員を味方につける
ロードマップの作り方

チートシート: 技術チームの同意を取り付けるための 10 のヒント

Martin Suntinger Martin Suntinger

ロードマップのプレゼンテーションは開発者とプロダクトマネージャーの双方にとって、いらいらさせる展開になる場合があります。片方はビジョンを描くことに懸命になり、もう片方は自分たちの作業に影響を及ぼすことになる未知の部分がわかるまで様子をうかがいます。

I felt this tension when I worked as a developer and I often found myself unsatisfied with the roadmaps product management put together. I didn't fully buy into the decisions, and I'd often walk out of a planning meeting with the sentiment of "Well, this doesn't make sense to me, but if they think so...", or even worse, a "We'll have to figure out things ourselves and make it look like what we do fits this roadmap.

問題は、私が NIH (Not Invented Here (ここで発明されたものではない) 症候群) にかかっていることだと反論されるかもしれません。その可能性もあります。開発者として、私は何を行うことが正しいかについて非常に強固な意見を持っていました。しかし、プロダクトマネージャーになった現在は、このすれ違いの原因を理解しており、どのような汎用学習をすればプロダクトマネージャーが次のロードマップのプレゼンテーションでこのすれ違いを避け、成功を収められるかわかります。結局、技術チームが全体像に同意し、理解すれば、日常的な設計と実装の意思決定は適切な状況で行われ、プロダクトマネージャーは思い描いたとおりの製品を手にできます。

1. 業界の流行語よりも本質を重視する

「ビッグデータ分析」、「機械学習」、「モノのインターネット (IoT)」などの業界の流行語は、ハイレベルのアンカーポイントとしてビジネス部門の関係者の共感を得るかもしれませんが、技術チームにとっては、有用ですぐに実行可能な項目ではありません。技術者は、何を作成しようとしていて、それが現在の製品とどのような関係があり、どのように提供されるべきで、最終的に誰が、何の目的でそれを使用するのかということを正確に知る必要があります。

Setting high-level themes is great for structuring the roadmap and context, but make sure you don’t stop there and have good answers for what is behind each high-level item. For example, if you've called a theme "intelligent services," make sure to break this down into key initiatives and epics that are needed in order to deliver this theme.

2. 適切な状況を設定する

技術チームは、あなたがロードマップ上で何かを作成している理由の背景事情を知る必要があります。技術チームでなければ、「どうしてほしいか言ってくれれば、作りますよ」と言うでしょう。 しかし、技術者はあなたがある機能を要求する根拠を理解する必要があります。データに語らせるだけでなく、ユーザーの観点からも強力なストーリーを伝えてくだいさい。ペルソナを使用し、あなたが除外した代替案について、その理由と共に話します。チーム全体がロードマップを理解できるようにするには、「何を」と同じぐらい「なぜ」も重要です。

3. コミットメントを慎重に考慮する

ある機能が十分に考え抜かれていないか現実的でないように思われるのに、まだロードマップ上にある場合、これは危険信号です。あなたが誰かに約束してしまったために技術チームが物を開発しなければならないという印象を与えないようにします。これは、お客様へのコミットメントの場合もあれば、「経営陣がそれを望んでいる」からという場合もあります。したがって、コミットメントはよく考えて行ってください。特定の変更を要求する強制的な働きかけがあなたの背後にあっても、必ず論理的根拠を理解して、チームに伝えるようにし、それを自分自身でも支持できるようにします。

4. 現実的な計画を作成する

ビジョンを持つのは素晴らしいことですが、達成できるという確信を全員が感じられれば、もっと良いです。綿密な計画である必要はありませんが、開発マネージャーがロードマップを見たとき、最初に目にするものが大きな障害であればどうなるでしょうか。たとえば、量が多く、フロントエンド中心の設計なのに、チームには設計者が一人しかおらず、その設計者はすでにここ数カ月フロントエンドのトピックにずっと取り組んでいる、といった場合です。プレゼンテーションの残り時間すべてを使って、ロードマップを巡って開発マネージャーと闘うことになるでしょう。

現実性について率直にチームと確認し、what-if シナリオを確認するようにしてください。あなたは全員のコミットメントを求める際に、「どのように達成できるか」という質問に対する回答と、明確な実行計画および簡潔な意見をもっている必要があります。 

Presenting product roadmaps | Atlassian agile coach

5. 大きく考え、小さく始める

あなたがチームに求めるゴールに対して、製品およびチームのスキルの現状を心得ておく必要があります。新たな領域に進むのは素晴らしいことですが、チームに新しいスキルが必要になったり、既存のテクノロジーを捨て去る必要があるかもしれません。したがって、年内の達成目標に関する理想を掲げるだけではいけません。現実的に、それをどのように達成するかについて考えてください。人材の獲得には時間がかかります。新しいテクノロジーの導入も同様です。さらに、既存製品を中止するには明確なコミットメントと移行計画が必要です。

6. ビジネスケースを作成する

ビジネスケース?そうです。技術チームはビジネスケースに関心があります。上層部の経営陣ほどではないかもしれませんが、全体として開発チームは、あるものがそのビジネスになぜ関係しており、現実に成果が出るのかどうか、それはどのように測定されるのかに関心があります。技術チームの知識と経験を活用してください。誰もが全体としてのビジネスの成功に関心を持っているので、知識や経験から得た知恵はフィードバックまたは追加のアイデアの宝庫になる可能性があります。

また、ビジネスに対する影響が完全に明瞭で、その成果を目にすることができれば、意欲を高める大きな要因になり得ます。好結果につながることは、単に機能を作成して出荷する以上の満足感を与えます。

7. メリハリをつける

技術者は、誇りに思える、独自性を持った革新的な製品を作りたいと考えます。以前に聞いたことがあるようなよくある話では、やる気を失ってしまう可能性があります。しっかりと下調べをして、あなたが考えているとおり革新的な内容であることを確認してください。開発者の士気の低下は別にしても、革新的でなければビジネスに打撃を与えます。

そうは言っても、ロードマップでさえ、刺激的な新機能と技術的に面白みのない、やらなければならない必須機能の間で常にバランスを取ることになります。ありふれた作業でもロードマップで意欲を高められるように努力しみてください。 

8. MVP と v1 の先を考える

MVP (必要最小限の能力を備えた製品) を作成してから、バージョン 1 を作成する作業がありますが、ローンチ後にもあらゆることが生じます。たとえば、運用、保守、ユーザーからの機能リクエスト、継続的な改善、他製品の新しいバージョンや統合されるプラットフォームなどです。ローンチ後に課題と障害になりそうなものを素早く考えることによって、さほど労せずにこれらを明らかにできます。技術者は、こうした現実をあなたが無視しなかったことに感謝するでしょう。大ざっぱに見積もって、新機能の作成における初期の労力は、多くの場合、その存続期間全体を通して費やされる全労力のわずか 1/3 から 1/2 にすぎません。つまり、初期のビルドよりもリリース後のほうがコストがかかり、「短期で作成できる小規模なもの」は、結局は非常にコスト高になります。

9. 柔軟に対応する

見積もりは望ましいことです。指針になり、各特定の時点でプロダクトマネージャーが知っている限りのことに基づいて作成されます。しかし、見積もりのために行われた多くの想定は、実装が始まった後や、設計の改良後にかなり間違っていることが判明します。変更に柔軟に対応できるように、ロードマップを準備し、提示するようにしましょう。

10. 隠し立てせずに誠実に

ロードマップは指針を与えるためにあります。実行に向けた詳細な計画ではありません。ソフトウェアチームの全員がそのことを知っています。それ以上のものであるかのように売り込む必要はありません。あるトピックに関してまだすべての詳細を把握しているわけではないのなら、正直に話してください。把握していること、目的、未解決の問題、およびこれから取り組む必要がある最大のリスクについて共有しましょう。「何か」を見極めるために実験と追加の調査が必要な領域を示してください。そして、この実験期間について計画で説明することを忘れないようにしましょう。

結論

チームが必要としているのは、明確な全体像を描きながら、現実を無視していないロードマップです。また、意欲を高め、刺激的で、次の 1 ~ 2 スプリントで実行すべきことをソフトウェアチーム全体が知るのに十分な詳細が記述されており、さらに、ビジネスに重大な影響を及ぼす素晴らしい結果を達成できるという自信を与えてくれるロードマップでなくてはなりません。

次の記事
製品要件