なぜ「ゲームのルールを理解する」ことをしなければいけないのか
小城久美子氏：ではさっそく「ゲームのルールを理解する」から始めていきましょう。
（スライドを示して）先ほどもちょっと言いましたが、なぜゲームのルールを理解しなければいけないかというと、自分の発言のハードルを下げるために、今どうなっているか、何が大事にされているかを理解しなきゃいけないと私は思っているんですね。
例えばSlackひとつを例にとっても、スタートアップの会社はけっこう「Slackのリアクションは賑やかに付けたほうがいいよね」みたいな文化がありますよね。（でも）転職してきてすぐにめちゃくちゃリアクションしてもいいかみたいなところで、ちょっと悩んだりします。
これは噂で聞いただけなので本当に存在するかわからないんですが、会社によっては「上司に向かってグッドは失礼だ、ちょっとカジュアル過ぎる」みたいなことを言う会社もあるみたいな噂を聞いたことがあって。そういう文化だとなかなかSlackで賑やかに付けちゃダメだよねみたいなことが……。スタートアップならあまりないかなと思うんですけど。
そういう「会社の中で大事にしている考え方」みたいなものがわかると、自分も「たくさん賑やかにSlackでリアクションを付けていこう」みたいなことを行動できるし、発言もしやすくなるし、上司に向かってどういう態度でしゃべればいいのかみたいなことも徐々にわかっていって、どんどんしゃべれるようになっていきます。
なのでプロダクトマネジメントに関しても、とっつ（きやす）く（する）ということで、自分がモヤモヤしなくて済むためにという目線でルールについて取り組んでもらえるとうれしいなと思っています。
マインドセットを切り替える
というところで4つ話していきます。まず1つ目が、「マインドセットを切り替える」ことについて話そうと思います。何のマインドセットかというと、自分の一番の失敗の話をするのでなかなか話しづらいんですが……。
一番切り替えなければいけないマインドセットは、ユーザー目線のマインドセットだと思っています。
エンジニアだった頃はドッグフーディングがすごく大事だと思っていて。今も大事だと思っているんですけど。ドッグフーディングは自分のプロダクトを自分で使うことですね。自分が一番のユーザーになって、自分が使いたくなるようなものを作るというプロダクト開発がすごく楽しかったんです。
なので、自分の主観で「その仕様書がイケてないと思う」みたいなことを思って、企画の人に「これだと私は使わないです」みたいな、自分の意見として言ってしまっていたというのを反省しています。
今の私はこれはけっこうな間違いだったなと気づいていて。本当は「自分はどう思う」というのに追加して、「それに対してユーザーはなんて言うか」みたいなところまで考えなければいけなかったという反省があります。
どういうことかというと、企画をしてくれた人、その仕様書を作ってくれた人は、今までめちゃくちゃたくさんのユーザーさんに会ってきたはずなんですよ。100人のユーザーさんに会ってきて、その結果「ここに旗を立てよう」「ゴールを設定しよう」と思って仕様書を作っています。
それに対してユーザーとして「こう思います」と言ったとしても、それは101人目の意見でしかなくて、ユーザーさんに対してそれをしない理由を説明させるのもなかなか難しいことだったなとすごく反省をしています。その時の私がどうしたら良かったのかと（考えた時に）思うのは、エンジニアとして、1ユーザーとして「こう思った」というのは仮説ですよね。その仮説が他のユーザーさんにも当てはまるかどうかを検証しなければいけなかったなと反省をしています。
なので、「私はイケてないと思う」じゃなくて、「私だったらこれは使わないと思ってしまったんですけれど、どんなユーザーさんがこの機能を使うというような意見を持っていますか？」みたいな聞き方をしなければいけなかったなと、すごく反省しています。
「私がどう思うか」みたいなことと、「ユーザーがどう思うか」は別に考えなければいけないということを学びました。
プロダクトマネージャーとしてこれを学ぶことができたのは、私は日常的にプロダクトマネージャーとして「この機能は絶対にユーザーを幸せにできる」と思って仕様書を書いているんですよね。
それをプロダクトチームの方と議論をして作っていくんですけど、本当に残念ながらユーザーをめちゃくちゃ幸せにするために出している機能にも関わらず、「改悪じゃん」みたいなことをユーザーに言われてしまうことはけっこうよくあることだと思うんですよ。
自分としてはユーザーのためになるように「こうすると幸せになるんじゃないか」と思ってやるんですが、ユーザーはなかなか自分の頭の中にあるとおりには動いてくれないということがめちゃくちゃあります。
それは自分の中にあるバイアスで、「自分の頭の中にある理想のユーザーはそう動いてくれる」と思っているけれど、実際はそう動いてくれませんでしたみたいなことが本当に日常茶飯事なので、私は「自分の思うイケてる機能というのはイケてないかもしれない」ということを、今はすごく身に染みて理解しているんですよね。
なので、私が今エンジニアさんに戻って自分がコードを書く場合には、「自分や作り手はユーザーの代表ではない」ということを心の底にそれをしっかり据えて考えていって、「自分はこう思うけどユーザーはどう思うかな」みたいな考え方をしていかなければいけないというマインドセットの切り替えが1つ必要かなと思っています。というのが、1つ目のマインドセットの話でした。
意思決定の軸を理解する
続いて2つ目に、意思決定の軸を理解するという話をしようと思っています。
もし今までに私の発表を聞いたことがある方がいたら、「またその話かよ」と思うかもしれないんですが、いつもの魚の話をしようかと思います。
（スライドを示して）意思決定の軸の話をしたいんですが、向かって左側の「はじめ」と書いているほうの青い魚が、プロダクトだと思ってください。
このプロダクトを良くしようと思った3人の人がいました。とある人はこれをイラストだと思っています。かわいいイラストをよりかわいくするには「鼻があったほうがかわいいんじゃないかな」と思って、鼻とついでに眉毛を付けました。
別の人はこれを魚だと思っています。魚としてより良くするにはどうしたらいいかというところで、今旬のサワラやブリで流行っている、人気のカッコいいヒレみたいなものを取り入れて、よりリアルな魚にしました。成功ですね。
そして最後の人は、これは移動する物体だと捉えています。海の中だけじゃなくて陸上でも行けるとより良いんじゃないかと思って、このプロダクトをより良くするために足を付けました。
結果、生まれたものは、もともとは緩いイラストだったものが、化け物みたいなものができてしまいます。私はこれを蛇足のダソくんと呼んでいます。
この蛇足のダソくんなんですが、作るのにめちゃくちゃコストがかかっていますよね。エンジニアからすると「この足とかヒレとか、どう付いてんねん」という感じです。すごいコスト、お金がかかっているんです。
（でも）かわいいイラストがほしい人は何がほしいかと言ったら、これじゃなくて、『ちいかわ』を買っちゃいますよね。移動するものがほしい人はキックボードを買います。これがほしい人は残念ながら誰もいませんでした、というのが残念なお話です。
この3人のうち、誰が悪かったかというと誰も悪くないし、全員悪いんですよね。この3人の中の全員が良くしようと思ったので、各々の選択としては良いのかもしれないんです。ただ、その中でどれを良しとするかという方向性が揃っていなかった結果、このキメラみたいなものができてしまうというのが、この蛇足のダソくんです。
これはイラストで描いているので誇張しているように見えるかもしれませんが、これは私が実際にやってしまった失敗を絵に起こしている図なので、こういうプロダクトになってしまうことは正直けっこうあるあるなんじゃないかなとは思っています。
ではこの蛇足のダソくんにならないためにはどうすれば良かったかというと、意思決定の軸、良さの軸で、「何を良いとするのか」というところを揃えていくのが重要になります。
（スライドを示して）それをするために、私は“仮説のミルフィーユ”というものを提唱しているので、この図について説明をしますね。これは何かというと、プロダクトで考えなきゃいけないこと全部をまとめたもので、私は“仮説のミルフィーユ”と呼んでいます。
中を4つの階層に分けていて、上からCore、Why、What、Howと、名前を付けています。それと良さの軸の話のつながりですが、例えばHowのところに設計・実装や、UIがありますよね。とあるプロダクトがあって、そのプロダクトのUI、画面の中にあるボタンは赤いほうがいいのか、青いほうがいいのか。「良さの軸は何でしょうか」というのを探す時に、1個上の階層を見ると良いという図です。
そのUIのボタンが赤がいいか青がいいかを決定づけるのはWhatで、どんなユーザー体験を作りたいかによって変わってきます。ユーザー体験自体も、いろいろな良いユーザー体験が世の中にあると思います。いろいろな良いユーザー体験がある中で、どれが良いかを決める軸は1個上のWhyです。誰をどんな状態にしたいかです。ユーザーは誰でその人のどの課題を解決するかということですね。
そこでまた山登りがあるんですけど、誰をどんな状態にしたいかを決めるのはプロダクトの世界観ですね。余談ですが、昨日（2023年5月18日）のRubyのまつもとさんのお話がめちゃくちゃおもしろくて、ビジョンの大事さみたいなところも話されていたので、もし参加していない方がいれば、YouTubeでアーカイブを見ることを本当におすすめしています。
全部このビジョンから紐づいていて、そのビジョンを達成するためのWhyがあってWhatがあるからこそ、「UIを作らなければいけない」みたいな意思決定をして。そうすると、先ほどの蛇足のダソくんみたいなことが起きずに、1本の強い軸を通せるようになります。
私がエンジニアだった時は、プロダクトってHowのことだけだと思っていたんですよね。でも今はビジョンからHowまで全部含めてプロダクトだなと思うし、よくプロダクトマネージャーはこの「WhyとWhatに責任を持たなければいけない」みたいなことも言われます。
なので設計・実装、UIみたいな層で議論をする時には「なんでそれがいいのか」みたいなユーザー体験や、ビジネスモデルというところで話すのが良いと思います。
（コメントを見て）今質問でもらったGTMとは、Go To Marketの略ですね。マーケティングの戦略のことです。
この4階層の話の中で大事にしてほしいのが各階層のFitです。まずはこれを大事にしてほしいなと思っています。（これは）英語ですが、日本語で言うと「整合性が取れているか」ということですね。当たり前だと思うじゃないですか。プロダクトを作っていたら、WhyとWhatの整合性が取れているはずじゃないですか。
でも実際にこのプロダクトのWhyとWhatを書き出してみると、意外と「あれ？ ユーザーはこんな課題を持っているのに、それを解決するための体験がまだできてないわ」みたいなことに気づいたり、「あれ？ ユーザーが課題を持っていないのに、もしくは別のユーザーなのにうちが体験を提供しちゃっているわ」みたいなことに気づいたりするんです。なので、このFitをぜひ意識してもらえればと思います。
もう1個、（スライドの）右側がRefineですが、私が4階層の話をするとたまに誤解されてしまうのが、「ウォーターフォールのように上から下にズドーンって進めるんですか？」ということなんですね。私はそれはまったく思っていなくて、上と下に行ったり来たりを薄くどんどんしながら、より軸を固めて作ってほしいなと思っているんです。
それをRefineと呼んでいます。例えばユーザーの体験で、ユーザーさんにとってどういうユーザーストーリーマッピングをしていって、どういう体験があるといいかなみたいなことを考えていきます。
そうすると、だんだん「ユーザーさんってもしかしたらこういうところでも困っているかもしれないな」みたいに、1個上の階層のペイン・ゲインのところで何か新しいことに気づくこともあると思うんですよね。そういうふうに、1つ具体的なことを考えれば考えるほど、抽象的なところの理解がより進むことはすごくよくあると思っています。
なので、「一度決めたからもうこのWhyは変えません」みたいなことはなくて、下までいって仮説検証をすればするほどRefineをして、どんどんより良いものにブラッシュアップしていくみたいな考え方を、この4つの階層ではしてもらえるとうれしいなと思っています。
あとは補足ですが、ミルフィーユの話をした時に、この仮説のミルフィーユというのは、どうしても1本の強い軸を意識するフレームワークになっちゃうんですね。
（スライドを示して）その仮説のミルフィーユをクルッと90度回したものがこの図です。ここが先ほどのダソくんの例で、3人の良いものがぜんぜん別のものであったみたいな話をしたんですが、1個のビジョンであったとしても、それを満たすための良いものの選択肢は、本当はめちゃくちゃたくさんあると思っているんです。
たくさんあるWhyの中から一番良いものを選ぶ作業が必要なんですよね。なので「1個のこれ」というところに囚われるのではなくて、「他にもっと良い選択肢はないかな」という発散をする。そして収束するということを繰り返しながら、より強い軸を作るのが大事かと思っています。
私もエンジニアだった時に、「この仕様書はイケてないな」と思う時はWhatがイケてないなと思っている時で、そのプロダクトマネージャーの人とかとWhyの認識が合っていなかったり、同じWhyでも実はもっと良いWhatがあったりみたいなことがありました。
なので、自分の思っている解決策に囚われず、1階層上で一度考えてみるみたいな癖をつけると、「自分はなんでこの解決策がいいと思っていたのか」みたいなところの思考が進んだりすることもあるので、このミルフィーユの山登りを1回してみてもらえるとありがたいなと思っています。
あとは同じWhyに対して別のWhat（がある）みたいなこともあります。このあたりがコンタミ（コンタミネーション）されちゃうとダソくんになってしまうので、発散するのはいいですが、ちゃんと収束をするとロジックが通っている（か）みたいなところには注意をしてもらえると、より良いものになっていくかなと思っています。
「今」追うべき目標を理解する
そういったところで2つ目の話が終わったので、次に3つ目の話をしていこうと思います。3つ目は「『今』追うべき目標を理解する」というタイトルで書きました。ここでは「今」がキーワードです。
（スライドを示して）プロダクトの良さはいろいろあるという話をしました。プロダクトが目指している良さと同じ良さであったとしても、今ではないことがあるんですよね。なので、プロダクトについて議論する時に、「今は何が大事なのか」という概念もすごく必要だなと思っています。
特にエンジニアさんが「今」という概念になかなか目を向けづらいのには理由があると思っています。私がプロダクトマネージャーとしてコミュニケーションをする相手として、他にもいっぱいいますが大きく2つに分けるとすると、経営層の人と開発チームで、経営層の人とは中長期的なロードマップを使ってコミュニケーションをします。
ただ、開発チームに対してはもっと詳細なことを共有しなければいけないので、中長期のロードマップももちろん共有はしますが、ちょっと薄めにして、目先にやらなければいけないことのバックログのリストをよりたくさん話すことがすごく多いと思います。
今すぐやらなければいけないことについては開発チームとたくさん話しますが、「それはなんで今なのか」みたいなところの共有は、経営層に比べてどうしても薄くなりがちだなと思っています。
「この仕様はイケてないな」「あの機能を作りたいのになんであの機能を作らせてくれないのかな」みたいに思う時は、「今」という概念の認識が合っていない時だなと思っています。
（スライドを示して）、たぶんエンジニアさんも目標を持っている方もいらっしゃると思うんですよ。エンジニアチームとしての目標みたいなものもあるじゃないですか。
それと別に、もちろんプロダクトとしての目標みたいなものもあって、それをみなさんにもぜひ強く認識してもらえるとプロダクトマネージャーとしてはうれしいです。
その目標値みたいな、「売上がいくら」みたいなものがあったとして、それを分解していくとします。これが電子書籍のプロダクトだったらどうなるかみたいなことで書いてみました。
売上を上げるためのKPIツリーでいうと、もちろん全部大事なんですよね。どの数字が上がってもうれしいのはうれしいですが、戦略的に数字を上げる時はボワッて全部上げるんじゃなくて、「ここに注力しよう」みたいなことを思います。（例えば）有料化率に注力しようと。「有料化率に注力するためにこの機能を作ろう」「この仕様書を書こう」と考えています。
「私があの機能をすごく早く作りたいな」と思っているものが（あったとしても）、この有料化率に紐づかなければどうしても後回しになってしまうし、それがどちらが大事なのかみたいなことは、事業戦略みたいなところと紐づけて考えていかなければいけないということがあります。
（スライドを示して）なので、今・何というところを考えなければいけないので、このロードマップを使って会話をするのがすごく大事になってくると思っています。正直私がエンジニアだった頃はロードマップの読み方はあまりわかっていなくて、共有されたロードマップを見て「ふーん」ぐらいで終わっていたんですよ。「これからこういうことをするんだな」ぐらいで終わっていたんですけれど、ロードマップはコミュニケーションツールなんですよね。
なので、そこに何か1つ追加されることがあったら（それ以外のことが）後ろにずれていくみたいな感じで、リビングドキュメント、生きているドキュメントとしてずっと更新していくものがロードマップなんです。
「なんでその順番になっているの？」とか、「今やっている機能を作って本当に目指す数字は作れるの？」「それが上がると本当にこれが上がるの？」みたいな、パズルをしてあるのがロードマップだと思っています。
「なんでそこにそれがあるの？」みたいな考えでロードマップを読むとけっこうおもしろいんですよね。なので「次に自分が（着手）する機能リスト」みたいな目線じゃなくて、「どういう状態を作りたいからロードマップがこうなっているのかな」みたいなところを考えて読んでみてもらうと、もしかしたら企画の人、プロダクトマネージャーの人との話がしやすくなるかもしれないです、というのが3つ目の話でした。
ステークホルダーと意思決定フローを理解する
（スライドを示して）4つ目の話はすごくさらっと終わろうと思うんですが、「ステークホルダーと意思決定フローを理解する」ということですね。
というのは、どうしてもエンジニアとプロダクトマネージャーみたいな人がいたら、ここで情報格差が起きてしまうと思っています。
それはなぜかというと、プロダクトマネージャーがいて、その先にいる営業さんや偉い人や取引先という人がどういうことを言っているのかみたいなところはプロダクトマネージャーに集約されますよね。
そうすると、やはりエンジニアさんとは情報格差みたいなものがかなり出てきてしまいます。エンジニアさんにそれを「全部わかって」みたいなことはまったく思わないし、エンジニアとしてもそれをやっていたらふだんのコーディングはできなくなると思います。けれど、ユーザー以外の誰がプロダクトの意思決定にコメントをしていて、どういう順番で何が決まるのかみたいなことがわかっていると、冒頭に話していた「今このタイミングでこれを言っていいのかな？」みたいなモヤモヤはなくなると思うんです。
「先ほどの4階層で自分がモヤモヤしているのはどのあたりかな？」みたいな当たりを付けて、その当たりを付けたものが、どのタイミングで誰が意思決定をしているのかがわかってくると、ちょうど良いタイミングで差し込めるようになってくるかと思います。
なので、ステークホルダーや、どうロードマップができているのか、目標はどうできているのかみたいなところも知っておいたら良かったなと反省をしています。
というのが「ゲームのルールを理解する」という話でした。なんとなくプロダクトマネジメントと言った時にどういう範囲のことを考えているかみたいなことが伝わっているとうれしいなと思っています。
（次回につづく）
