JP
Business/Technology
NTTコミュニケーションズ
ヒューマンリソース部
植田 純生
NTTコミュニケーションズグループではデータ利活用やアジャイル開発をけん引できる人材の成長支援に注力していると同時に、それらのスキルを活用し、顧客や市場に価値を届けるプロダクト・ソリューションを創出するため、近年注目が集まっているプロダクトマネジメント力の強化にも注力しています。
その一環として今回、NTTコミュニケーションズ株式会社技術顧問の吉羽 龍太郎氏（@ryuzee）に、昨年オライリー・ジャパンから出版された書籍「プロダクトマネジメント ービルドトラップを避け顧客に価値を届ける」を題材にした社内セミナーを開催いただきました。特に大企業において陥りやすいとされる、機能開発やリリースに集中し顧客の真の課題・プロダクトの本当の価値がおざなりになってしまう状況「＝ビルドトラップ」がなぜ起きるのか、また、それをどのように回避していくといいのか、についてお話しいただいたため、本記事ではその模様をお伝えします。同じようなお悩みを抱える組織や企業の方、現場のプロダクト担当者の方もいらっしゃるかと思いますので、ぜひご参考にしていただけましたら幸いです。
セミナーの模様（中央下部が吉羽さん）
「ビルドトラップ」とは、生み出された価値ではなく機能の開発とリリースに集中してしまっている状況
ビルドトラップの話の前に、「アウトプットがいつも最重要なわけではない」と述べられました。アウトプットとは「人や機械、組織が作った物の『かたまり』や『量』を示すもの」と定義され、プロダクトの文脈では開発・リリースした機能や消化タスク、コードの量などが該当します。一方で、アウトプットに類似した単語や概念として「アウトカム」や「インパクト」があります。「アウトカム」とは、アウトプットがもたらす成果のことで、顧客が抱える問題の解決や行動変容などが該当します。さらに「インパクト」とは、「アウトカム」がもたらす組織への影響（収益など）が該当します。
つまり「アウトプットが最重要なわけではない」の意味するところは、（組織では機能数やリリースなどのアウトプットに集中しがちになるが）プロダクトにおいて最も重要なことは、顧客へ価値を届け、その対価として金銭などのビジネス的インパクトを得ること、この価値交換を継続しなければならないことだということです。これについては、先述の吉羽氏訳の書籍内において「価値交換システム」という考え方でも説明されています。
その中で「ビルドトラップとは何か？」という疑問について、以下の2つの状況であると吉羽氏は述べました。
- アウトカムではなくアウトプットで成功を計測しようとして行き詰まっている状況
- 実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況
実際のプロダクト開発の流れに当てはめると、例えば、「競合他社に倣ってA機能とB機能を作らないといけない」「どうやったら、もっと効率的に開発できるだろう」などのように「ソリューションを作る」や「スケールする」の部分に組織として注力してしまっている場合、ビルドトラップの兆候といえます。事実、約64％の機能はほとんど使われないという調査結果や、機能を増やせば増やすほどユーザー満足度が下がるというデータもあります。
プロダクトと混同しやすい概念の一つに、「プロジェクト」があります。本セミナーでは、プロダクトとプロジェクトを比較しながら、プロダクトをプロジェクトの軸で評価しようとすると「ビルドトラップに陥る」と述べられました。とにかくプロダクトにおいて大事なことは、「決められた予算と期限とスコープを達成すること」ではなく「人が欲しがるものを作る」ことに尽きます。
ここまでは、ビルドトラップとは何か、さらにいくつかビルドトラップの兆候についてご紹介いただきましたが、この他に、どのような兆候があるのでしょうか？
「ビルドトラップ」の症状
できるだけ避けたいビルドトラップですが、具体的な兆候はどのようなものなのでしょうか？ いくつかの例を、ご紹介いただきました。
- 約束されたロードマップ、長すぎるバックログ
- 競合他社との機能比較
- 必要性が分からない機能
- 生産性やベロシティに対する課題ばかりが表出
- ステークホルダーの干渉
- 権限のないプロダクトチーム、意思のないプロダクトチーム
- 利用状況などのメトリクスを取っていない
- 役に立たないKPI
- 使い切れなければいけない予算
本セミナーでは、参加者へリアルタイムアンケートをとって弊社内の傾向をつかんだりしましたが、これら全部に手を打たないといけないわけではありません。プロダクトチームの現状に応じて、カイゼン活動などと同様に、効果の高いところから一つずつやることが鉄則です。
では、次の章では「ビルドトラップ」への対応方法についてお伝えしていきます。
「ビルドトラップ」への対処方法
ビルドトラップの兆候が現れたとき、どのようにしてカイゼンしていけばよいのでしょうか？ その対処方法として、次の6つのポイントをご説明いただきました。いくつかポイントを、弊社の取り組みと併せてお伝えします。
- 適切なプロダクトマネージャーを据える
- 適切なチーム構成にする
- 適切な戦略を組織へ行き渡らせる
- ソリューションの前に問題を理解する
- 適切な指標を定めて活用する
- 組織をプロダクト主導にする
適切なプロダクトマネージャーを据える
プロダクトの「Why（なぜ）」に責任を持つ、適切なプロダクトマネージャーを据えることが大切です。なぜこれを作るのか？ どうやって顧客に価値を届けるのか？ ビジネス目標を達成する上で、どう役に立つのか？ などの問いに答えることができて、会社のビジョンや目標・ビジネス・マーケットを理解した上で語れることが、プロダクトマネージャーには求められます。よく誤解されますが、プロダクトバックログ管理・供給することだけでは、プロダクトマネージャーの役割としては不十分です。
弊社では、社内のタレントマネジメントの仕組みの中で「プロダクトマネージャー」というタレントプロファイル（職種）を新設し、その成長支援に取り組んでいます。
ソリューションの前に問題を理解する
問題を根本的に理解していなければ、適切なソリューションは作れません。ただ、人間はソリューションを考える方が得意なため、そちらを優先しがちです。思い込みでソリューションを作ってしまう前に、本当に解決すべき問題は何なのかしっかり考えることが重要で、そのためには建物の外へ出て顧客の声を聞くことも大切です。実際に、弊社で今年4月に一般公開したオンボーディング・ハンドブックは、新入社員やその上長などへのアンケート・インタビューといったコミュニケーションを通して、オンボーディングの課題の本質は何なのか？ をメンバー間で検討して、ブラッシュアップを繰り返しながら制作を進めました。
ソリューションを探索する
プロダクト開発はやってみないと分からないことが多いので、学習するために素早く実験することが重要です。実験方法としては、主に以下の方法があります。
- コンシェルジュ（顧客に代わって手作業でやってみる）
- オズの魔法使い（裏側に人がいる）
- コンセプトテスト（コンセプトをデモしたり、ランティングページを用意したりする）
例として、米国の大手オンライン靴店「Zappos.com」のケースを紹介されました。創業者がサービスを立ち上げる際、オンラインで本当に靴が売れるのか疑問を持っていたといいます。それを確かめるために簡単なWebサイトだけを準備し、注文が入れば自ら走って買いに行き、宅配業者に持ち込んで発送。この実験により、このソリューションはうまくいくと考え、実際にサービスを立ち上げました。他にも「Dropbox」も投資家から資金を集める際、実際にプロダクトを作るのではなく、プロダクトの動きが分かるコンセプト動画だけを作って見せたという話もあります。
弊社でも、自社開発のタレントマネジメントシステム「ODYSSEY（オデッセイ）」の新規施策の企画フェーズで、モックアップのデモ動画を用いてユーザーである社員とソリューション仮説検証を行いながら、施策・検討を進めています。
適切な指標を定めて活用する
リリースをした後は、適切な指標を定めて意思決定していかなければいけません。指標を定めるといっても、ユーザー数やPVでは意味がありません。もちろん、完成した機能の数やスクラムのストーリーポイントも同様に意味はありません。
プロダクトのコンテキストが分かる数字を集めていくことが重要になり、近年では収益目標（KGI）の先行指標となり、さらにプロダクトビジョンの実現や顧客への価値提供への先行指標にもなる単一指標、North Star Metric（ノーススターメトリック）を定める組織も多くなっています。
弊社でも技術顧問の及川卓也氏らと連携し、経営幹部やミドルマネジメント層への勉強会などを通じて、North Star Metricを含むモダンなプロダクト成果指標の定着に取り組んでいるところです。
Q＆Aセッション
セミナーの後半では、吉羽氏に、参加者からの質問にお答えいただきました。その一部を以下に紹介します。
Q. ビルドトラップの兆候の一つである「競合他社との機能比較」について、顧客からのRFPなどの条件として必要な機能が羅列されているケースが多く、対応せざるを得ない状況がよくあります。こういった状況に対して、どのような考え方で向き合えばよいでしょうか？
A. 毎回同じ機能で失注するなら投資として機能を追加するのはいいですが、失注した額と機能追加の額を見積もって、投資対効果から考えるべきです。顧客から言われるたびに作っていては無駄な投資になり、逆にユーザー満足度も損なうリスクがあります。
Q. ステークホルダーから機能開発要望が現場へ落ちてくることがあるが、担当者としては「これは売れないだろう」と思うものがあったときに、どのように上層部やステークホルダーを巻き込んで軌道修正していくとよいのか？（場合によっては開発をやめる判断に持っていく）ノウハウがあれば、教えていただきたいです。
A. メトリクスを基に判断することが重要です。ビジネス的なメトリクスであれば、営業サイドと協力して、顧客とのミーティングや見込み顧客などのパイプライン、競合の状況など定量的なデータを基に上層部やステークホルダーへ相談すること。売れないと思っていることを定量的に伝えることが重要です。一方で、メトリクスだけではない、製品ラインアップとして追加機能が必要と感じていて売れなくてもいいと思っている可能性もあるので、確認は必要です。
NTTコミュニケーションズグループは、真の「DX Enabler®」としてお客さまから選ばれ続けるサービス・ソリューションを開発するべく、社外技術顧問の強力な支援のもと、日々アップデートしています。そして、Smart Worldを実現するべく、これからも社会的課題の解決に一層取り組んでいきたいと考えています。
今後も、人や組織の成長支援の取り組みについて、ご紹介させていただきます！ ソフトウェアエンジニアポストもオープンしていますので、よろしければ、ぜひご覧ください！
