Sean Osawaさん
  • コラボレーター
  • アトラシアン株式会社
  • Sean Osawa

プロダクトマネージャーがロードマップを作るための10のヒント【連載/第6回】

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet

今回は、プロダクトマネージャーが、プロダクトのロードマップについて開発チームの同意を取り付けるための10のヒントをお届けします。

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

メンバー全員を味方につけるには?

開発者として仕事をしていた頃、プロダクトマネージャーが作成したロードマップを不満に思っている自分に気づくことがよくありました。その決定に完全には同意しておらず、多くの場合、計画会議の後「納得いかないが、これが上層部の考えなら仕方ない」という気持ちで会議室を出ました。もっと感情が高ぶっているときには、「自分たちで考えて、このロードマップを開発作業に合ったものにしなければだめだ」とさえ感じました。

しかし、プロダクトマネージャーになった現在は、このすれ違いの原因を理解しており、どのようにすればプロダクトマネージャーが次のロードマップのプレゼンテーションでこのすれ違いを避け、成功を収められるかわかります。

結局、開発チームが全体像に同意し、理解すれば、日常的な設計と実装の意思決定は適切な状況で行われ、プロダクトマネージャーは思い描いたとおりのプロダクトを手にできるのです。

1. 業界の流行語を細分化する

ビッグデータ分析機械学習モノのインターネット (IoT)、などの業界の流行語は、ビジネス部門の関係者の共感を得るかもしれませんが、開発チームにとっては、有用ですぐに役立つものではありません。技術者が関心あるのは下記のような事項です。

  • 何を作成しようとしているのか
  • 誰が何の目的でプロダクトを使用するのか
  • 顧客にどのように提供されるべきか
  • 現在のプロダクトとどのような関係があるのか

ビッグデータ分析、機械学習、モノのインターネット (IoT)、といった大きなテーマを設定することは、ロードマップと文脈を構成するには優れています。ただし、そこで終わってしまわずに、大きなテーマを実現するための答えを用意しておくべきです。大きなテーマをカテゴリに細分化し、優先順位をつけましょう。

2. ユーザーの観点からロードマップの背景を開発チームに伝える

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

3. コミットメントはよく考えてする

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

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

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

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

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

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

開発チームはビジネスケースに関心があります。上層部の経営陣ほどではないかもしれませんが、全体として開発チームは、あるものがそのビジネスになぜ関係しており、現実に成果が出るのかどうか、それはどのように測定されるのかに関心があります。技術チームの知識と経験を活用してください。誰もが全体としてのビジネスの成功に関心を持っているので、知識や経験から得た知恵は追加のアイデアの種になる可能性があります。 また、ビジネスに対する影響が完全に明瞭で、その成果を目にすることができれば、意欲を高める大きな要因になり得ます。好結果につながることは、単に機能を作成して出荷する以上の満足感を与えます。

7. メリハリをつける

技術者は、誇りに思える、独自性を持った革新的なプロダクトを作りたいと考えます。以前に聞いたことがあるようなよくある話では、やる気を失ってしまう可能性があります。しっかりと下調べをして、あなたが考えているとおり革新的な内容であることを確認してください。 ただし、ビジネスを成功に導くためには、やらなければならないありふれた作業もあるので、「革新的なこと」と「やるべきこと」で常にバランスを取る必要があります。ありふれた作業でも意欲を高められるように努力しみてください。

8. MVP と v1 の先を考える

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

9. 柔軟に対応する

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

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

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

プロダクトマネージャーがロードマップを作る10のヒント【まとめ】

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

  1. 業界の流行語を細分化する
  2. ユーザーの観点からロードマップの背景を開発チームに伝える
  3. コミットメントはよく考えてする
  4. 現実的な計画を作成する
  5. 大きく考え、小さく始める
  6. ビジネスケースを作成する
  7. メリハリをつける
  8. MVP と v1 の先を考える
  9. 柔軟に対応する
  10. 隠し立てせずに誠実に

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet