プロダクト開発の経験が浅い中でProduct Owner になったら

デジタル変革や新規事業開発で、プロダクト開発責任者に任命されたり、プロジェクトマネージャーだけどアジャイルで、などと周りから期待されている方が、実際にプロダクト開発を始める際に向き合うことになることを書いていきたいと思います。

「調整役」からの脱皮

これまで、上司の言うことや全体の雰囲気の中で決まっていくことを具体化することはあっても、自分が中心にコトが回るなんて経験はない。

そんな中で、プロダクトオーナーになると突然問われる「VISION」に戸惑うことになります。「とめどなくやってくる意思決定」にも対処せねばなりません。

「では、あなた自身はどうしたいのか？」と問われ、
「・・・（うーん。まあこう言われているし、なあ。）」

となる人を多く見てきました。これは日本の歴史ある大企業などにいれば当たり前でのことです。
変革途中で権限委譲されていないケースも多く、実際に自身で決められない実情もある中で、やりたくてもできないという難しい状況に立たされていらっしゃる方も多くいることでしょう。

それでもチームは率いなければならない。
政治家の街頭演説と同じで、寒い日も暑い日も、人々に伝わるまで、工夫しながら伝え続けなければならない。何より苦難に陥った時に自身が踏ん張れる拠り所はほしい、ですよね。

自分の言葉で語り続けるには「熱量（気力創出力）」が大事ですが、いきなり心全開になれたら苦労はしないです。

足を使う

そんな時のおすすめは「足を使う」ことをお勧めしたいです。

”違和感”
”実はもってた問題意識”
”欲望”
”これが好き”
”ワクワクする！”

この様な感性を開くには、その領域の関係者（どんどんツテを辿ろう。紹介してもらおう。）や、プロダクトやサービスを通じて助けたい人を探し、話を聞くところから始めましょう。
そして自分のアイデアをとにかくたくさんの人に聞いてもらい、自分の仮説や物の見方が本当のところどうか？を確かめましょう。

そして1日の終わりに、胸に手を当てて、今日は充実していたか？どんな収穫があったか？振り返ってみましょう。

問題解決に向かう体験を考え、要求を言語化する

これまで、やりたいことをざっくりと依頼していた人にとっては、
なぜそれが必要なのか？
を細部に渡りロジックを持って説明することに苦慮する場面もあると思います。

ソフトウェア開発では、カスタマー・ユーザーに焦点を当てて、その人たちの困りごとを解決する（価値を提供する）ということを第一に考えます。
もしかしたら、ソフトウェアじゃなくてもその顧客の困りごとは解決するかもしれません。わざわざ新しいソフトウェア製品を作る意味って何ですか？

という問いに対する回答があったら、次は問題解決に向かう体験や要求を言語化していきます。問題解決のステップやそのプロダクトを使うフロー、使った後の気持ちなどを網羅して検討することが、いわゆる「顧客体験の骨子」となります。

ビジネスサイドでも、カスタマージャーニーという言葉やプラクティスは広く使われるようになりました。
しかし、

エンジニアやデザイナーが発言している「体験」は１０倍解像度を上げる必要があります。
要するに、もっと細かなレベルが要求されます。これを知らないと、意外と話が噛み合いません。

例えばカスタマージャーニーだと、「購入体験」とざっくりと括りますが、プロダクト開発上で使う時は、
全体的な購入体験を実現するための、一つ一つのタッチポイントとフロー（使う人の動作）とそれが本来の問題を解決するのか、を考えます。

例えば、商品一覧画面から、商品詳細ページに遷移することひとつとっても、
「商品詳細ページに行った後何をしたいのか」
によって、付帯させる情報、つけるボタンひとつ、全て違って来ます。

とてつもなく細かい工夫が、ソフトウェアプロダクトにはたくさん隠れています。あなた目線の「あったらいいかも」というソリューションに対する感性はこのタイミングでは一旦脇に置きましょう。大きな方向性は持ちつつも、それは丹念な調査と、緻密なロジックの先にあるのです。

検証も、開発費用をかけなくても、ペーパープロトタイプや簡単なモックアップが作れるサービスもたくさんあるので、開発に着手する前にテストをすることができます。

代替製品を使い倒す

上記で伝えたように、プロダクトであなたのソリューションを、「細かいレベルで言語化し、前後の文脈を補足し、それがなぜ良いのかを伝える」というのは結構難しいです。

慣れないかもしれませんが、言語化が難しいと感じたら、まずは自分が担当するものに近いサービスや競合/代替製品を使い倒してみることを勧めたいです。

普段さりげなく使っているアプリやWEBサービスを、ログアウトして、ログインするところから始めてみましょう。
いくつか使っていると、だんだんと「ユーザーとしてどこでどのような行動をとりたくなるのか」「製品ごとの細かな仕掛けの差分」がわかるはずです。

「対象としたい顧客にとってどのようなユースケースがあり得て、他のサービスよりも、このような使い方ができたら望ましいはず。」
というところを考えられたら、エンジニアやデザイナーに相談してみましょう。

システム仕様書と、要求仕様書の間。

プロダクトオーナーがプロダクト仕様を開発者に伝えるときに、あなたはどのようなツールや、伝え方をしているでしょうか？

正直にいうと正解はないです。組織のルールや考え方によっても違うのでチームの中で最適化していく必要があります。

プロダクト開発を行う際によく使われているのが
PRD（Product Requirement DocumentやBRD( Business Requirement Document)
です。

プロダクトの概要、リリーススケジュールから開発内容骨子まで網羅的に言語化されているドキュメントは、プロダクトオーナーやPdM（プロダクトマネージャー）の間で活用している人は多いと思います。
＃Mizuho Kushidaさんのnoteがとてもよくまとまっていたので掲載させていただきます。

ただし、もちろん使っていないチームもありますし、運用の仕方もそれぞれです。
気をつけたいのは、
メンテナンスが仕切れない量をドキュメント化し、運用に時間をかけすぎないことです

スクラムで活用する「プロダクトバックログ」における落とし穴

スクラムを活用するときには要求をプロダクトバックログに落としていきますが、そこでは「ストーリー」を作成します。伝える内容に余白があるストーリーの形式は、本来コミュニケーションを生み出すためで、要件定義書のようになる必要はありません。

大切なのは、「小さな体験や流れを通じてどの様なユーザーの困りごとを解決しようとしているのか」を考えていること、
余白は開発者とコミュニケーションして中身を充実させていくこと。

ちなみにパラドックスみたいですがストーリーはもともと曖昧にしか考えられていない仕様を助長するためのものではありません。
仮説や要求は「検証」をする必要があるので、当然考え抜きます。曖昧さが大きいまま進めても変更も起きやすくなります。内容に曖昧な部分はスプリント計画までに洗練させましょう。
開発者が何を知りたいのか、は話さないとビジネスサイドにはわかりません。

会話が十分になされず皆に同等レベルの詳細情報がなかいと感じると皆手探りで動きます。結果手戻りが発生したり、情報が散乱します。こうなると細かく資料を残さざるを得なくなります。
資料化が進んだ時、結果として以下の様な傾向が見られる際は注意が必要です。

• 受け入れ条件が最初から膨大になっている

• 添付資料リンクが増える（以前の開発よりもドキュメントが増えた？）

• ドキュメントが法典の様になってしまう。書いてないからやらない。という様な態度になる

• 柔軟なコミュニケーションが減ったり、ドキュメントがどんどん詳細化されたりする。

• 過去の発言ログを、批判の対象にしている（この時言ってないじゃないか、というような）

そしてドキュメントが多重構造化し、運用負荷が増えると、運用は困難になりますのでバランスが必要になります。（これは反復的に改善していくしかない）例えば、

Defenition of Ready (開発可能な状態)
などは、要件を書く際に、この内容は満たした上で計画に持ってこようね、という内容を開発者と決めることで、直前で情報が足りなくて見積もれない！という状態を回避することもできます。

一人で悩まない

色々書いてきましたが、どのフェーズにおけるプロセスでも直接のコミュニケーション「相互作用」がとても大切だと思います。
どうか、一人で悩まず色々な人と話してください！
また、守破離の観点で言えば、本を読み漁ってその通り進めてみるのも手。
不恰好でも、どんどん行動していきましょう！