開発ステップの問題 プロダクトゴールの説明不足・自由度不足の問題
鈴木健太郎氏（以下、鈴木）：では続いてのフェーズです。ざんねんなプロダクト開発フェーズの問題に関してお話しします。
まず1つ目に発生する（問題の）話としては、プロダクトゴールの説明不足や自由度不足の問題が起きたります。これは開発開始時にどんな顧客課題（があるか）や、プロダクトの機能価値が生み出せるのかということを、開発メンバーに説明不足なケースです。
特によく練られた企画案ほど、仕様書どおりや企画どおりに開発を進めてほしいというような思いが先行して、開発メンバーが代替案をなかなか出せず、結局議論の余地がないような状況に陥ってしまうケースがあるかなと思っています。
こういう状況に陥ると、開発メンバーはプロダクトや機能に対して解像度が低い状態になってしまって、効果的・効率的なものが生み出せない状況になってしまいます。
あと（もう1つ）考えられるのは、デモチ（デモチベーション）のようなところもあり得るかなと思っています。
このような“ざんねん”を避けるアプローチ案としては、当たり前の話ですが、プロダクトのWhyやWhatをプロダクト開始時や途中できちんと説明し、インプットして共感してもらうことが大事だと思っています。
また、説明だけだとどうしても腹落ち度が低い場合もあるので、そういう場合はワークショップなどを通じて、プロダクトゴールを一緒に考えてもらうのも良い解決策かなと思っています。
ではどんなワークショップをするかというと、リーンキャンバスやバリュープロポジションキャンバスが代表的です。PMの方なら作ったこと、やったことのある人が多いかもしれませんが、大事なことは、これをPMだけだったり、（誰か）1人が作るのではなくて、プロダクトメンバーと一緒に作ってみたり、ほんの少しでも一緒に作る時間を取ることで、腹落ち度をさらに高めることができるのではないかと思います。
実際、私の会社でもこのようなワークショップなどを通じて企画への納得度や理解度を高めてもらったりしているという感じです。
開発ステップの問題 品質よりもリリース日を優先してしまう問題
続いての話です。開発もいよいよ終盤に近づいてくると発生しがちな問題として、品質よりもリリース日を優先してしまう問題もけっこう起きたりします。
リリース日のプレッシャーでPMの人も開発メンバーも頭がいっぱいになって、顧客の期待に応えるべき機能が足りていなかったり、グズグズな状態でリリースしてしまう。そんなことになってしまうと、目も当てられない状態かなと。「なんのために急いでリリースしたんだ？」という感じです。
また別の問題として、リリースまでにやることが山積していて、それをなんとかしないとリリースも間に合わないし、精神衛生上良くないような状態なのに、「みんなががんばれば、きっとなんとかなるだろう」みたいな妄想を抱えたまま開発が進むと、いわゆるデスマーチのような状況が発生します。（その結果）開発チームや会社自体も疲弊したり、評判が落ちるようなこともあったりするかなと思っています。
このような“ざんねん”ケースを避けるアプローチ案としては、まずリリース予定日に関しては極力対外公表しないことが非常に大事かなと思っています。リリース予定日自体を社内で合意するということは絶対やるべきだし、やらなきゃいけないと思いますが、社外への公表はよほどでない限り控えたほうが、PMとしてはリスクマネジメントをしやすくなるかなと思っています。
どうしても言わなければならない場合は「今年の春にリリース予定です」、といった感じでぼやかすと良いかなと思っています。
また、リリース予定日に出せないとどんな状況になってしまうのかを想定し、確認する。慌てないで、落ち着いて、なにが起こってしまうのかを考える、確認することも大事かもしれないですね。確認をすると、もしかしたらリリース予定日を延ばせたり、「この機能を削っていい」といったことの発見につながったりするので、そもそも考えてみることをおすすめしています。
ただ、テレビCMの出稿だったり、盛大なプレスリリースの会場をもう押さえてしまっているなどで、どうしてもリリース予定日が変えられないような感じであれば、最終手段として実装要件を減らす検討をきちんとするべきかなと思っています。実装要件を減らす場合は、リリース日に達成したいことや検証したいことをあらためて明確にして、その上でスコープを絞り込むことが大事かなと思っています。
運用ステップの問題 要望に優先順位がつけられない問題
いよいよ運用編です。フェーズとしては最後になります。
人数の多い会社や部署が多い会社だと、各所からの要望になかなか優先順位がつけられない問題（があるということ）も聞きますし、実際に私も体験したことがあります。
マーケティングやCS、法務、広報、あるいは経営陣から「なんだ、その要望？」「そんなことやらなきゃいけないの？」という要望が届いたりする。しかも必死で要求されるという感じです。（こうなると）PMとしてはつらいんですよね。PMとしては来る者をすべて受け入れたり断ったりしていると、ステークホルダーとの良い関係を築けないかなと思います。
また別の問題として、偉い人から「全権は君に任せるから」みたいに信任されていたPMが、開発を進めていたら、ある日、偉い人の一言で、根本を覆すような、ちゃぶ台返し（をされてしまう）状況が発生して、開発が大混乱することも実際体験としてありました。
ある方はこのような開発事例を、ウォーターフォール型開発をもじって「メテオフォール型開発」と言っていました。「うまいこと言うな」と思いましたが、そんな事例もあったりします。
こういう横やり問題を避けるためのアプローチの解決策ですが、複数部署から要望が届いたら、全部が全部をPMで決めようとしないという案も1つあるかなと思っています。
各部署のトップの人とかに優先順位を決めてもらって、最終的な優先順位はPMが整理すべきかなと思っているのですが、PMの負担を減らす（という）意味だったり、正しい優先順位をつけてもらうという意味でも各部署にお任せするのも案としてはありかなと思っています。
また、「影の意思決定者」はなかなかわかりづらいものだったりしますが、そういう人がいるがという話なら、（その人を）表に引きずり出して、ちゃんと対話をして決めるとか。 なんだったらその人に意思決定をしてもらう。PMは開発チームを健全な状況に導くために意思決定から外れて、整理に徹するのも、PMとして大事な仕事なんじゃないかなと思っています。
それから、プロダクトビジョンやゴールに合っていない要望に関しては、きちんと「No」の説明をするのも大事な仕事かなと思います。
運用ステップの問題 社内ニーズを無視してしまっている問題
サクサク（次に）進めて。視野の狭いPMだと意外と発生しがちなのが、社内ニーズを無視してしまっている問題です。
最も重要視すべきなのは顧客だということは間違いないと思っているのですが、社内で良好な関係を築いて事業継続性を築くのもまた大事な話です。「あなたのプロダクトは、ちゃんと期待どおり、（または）期待以上の成果を上げているプロダクトに現在なっているでしょうか？」と。
あとは、技術的負債や運用の負荷が非常に高い状況が続くと、「開発メンバーの業務ストレスみたいなところは大丈夫ですか？」。そしてPMもけっこうストレスが大きいので、「あなたも問題ないですか？」というところはきちんと確認しましょう。
こういった“ざんねん”を避けるアプローチとしては、上司や関連部署に、ちゃんとプロダクトが日々期待に添えているか、細かく探りを入れるようにするといいかなと思います。また、継続可能な開発体制を目指して、少しでも怪しさを感じたらちゃんと上司に相談してマネジメントとして動いてもらうことが大事なポイントかなと思っています。
運用ステップの問題 表層問題で悲観してしまう問題
最後、7つ目になります。表層問題で悲観してしまう問題です。
PMはけっこう短期的な結果で物事を悲観しがちだったりします。「リリース直後の結果が良くなかったから、もうだめだ」「このプロダクトは向いてないんじゃないか？」みたいに悲観するようなケースが、ジュニアのPMだとけっこうあります。
ただ、リリース直後の結果が良いから良いプロダクトというわけではなく、運用によって大きく成長を遂げたプロダクトも世の中にはたくさんあります。
あなたが知っている人気プロダクトに関しても、優雅に見えても水面下では水鳥のように必死で水をかいていたりするものかなと思っています。
なので、悲観する前に「やれること、やらねばならないことはまだありませんか？」とちゃんと考えるのも大事だと思います。また、「あなたが簡単に諦めてしまったら、顧客の課題は誰が解決するのでしょう？」という気概を持つのもPMに必要な要素かなと思っています。
このあたりの“ざんねん”を避けるアプローチとしては、リリース直後は不調でも、「顧客課題について理解が増えたんだ」「これが当たらなかったということが1つわかったんだ」という感じで、前向きに捉えることも、大事かなと思います。少し精神論っぽいですが。
一方で、意地を張り続けるのも、会社にとってもあなたにとっても、いずれ危険が伴うというところがあるかもしれません。なので、サンクコストがあってなかなか厳しいかとは思うのですが、KPIや期間みたいなところで区切って、「ここまでにだめだったら諦めて撤退する」という撤退ラインみたいなものを検討するのも大事かなと思っています。
“ざんねん”を避けるための勉強をしましょう
まとめです。
プロダクトというものは、気を抜いていると理想どおりのものが生まれなかったり、例えば安定したプロダクトでも、数年のスパンで考えるとサービス終了のような状況に陥ったりすることもあります。
なので、“ざんねん”を避けるための勉強をきちんとしていきましょうという感じです。社内から学ぶ、社外、今日のようなコミュニティから学ぶことも、とても大事かなと思っています。
最後に、今回は“ざんねん”を避けるという話をしましたが、それだけでは成功にたどり着けないかなと思っています。“ざんねん”を避けるのは、あくまで致命傷に至らないようにするだけの話なので、みなさまが社内の期待に持続的に挑戦していけるプロダクト開発を行えることをこのセッションを通じて願っています。
駆け足になりましたが、以上で終了とします。ありがとうございました。
