「NO」と言うのはメチャ重要
及川卓也氏（以下、及川）：逆に言うと、リソースが限られているからこそ研ぎ澄ます時に、どこを削るべきかというのができる。
吉羽龍太郎氏（以下、吉羽）：そう、それが振りで、「NOと言う覚悟」の話をしようかなと思っていたんですけど。
及川：あと、あれですよ。「未完成なプロダクトを人に使ってもらう覚悟」というところにつながってくるんですよね。
吉羽：そうそう、そうそう。そのあたりの話をしていけたらいいかなと思うんですけど。
「NO」と言うのはメチャ重要だなって。僕らはすごく気軽に「NOと言ってください」と言うんですけど、いざ言うとなったら、むちゃくちゃ難しいワードだと思います。
及川：そのとおりですね。でも、「NO」と言っていますよね。
吉羽：そう。自分の経験上まあまあ言っていると思うんですけど、けっこう慣れが必要な気もしますよね。
及川：そうですよね。私は吉羽さんと違って優しいので。
吉羽：はいはい……はいはいとか言っちゃった（笑）。
及川：（笑）。基本的に相手が「NO」と言うと思っていないことも多いんですよね。だから、どうやっているんだろう？ たぶん相手に「NO」と言わせているんじゃないですか（笑）？
吉羽：それもありますよ。でもそれってあれですよね。必要な情報、背景、現状とかを伝えた結果、相手に「あっ、これはNOなんだ」とわかってもらうという、結局、説明責任を果たしているから相手がNOに気づいてくれるということですかね？
及川：そうですね。今ちょっと思ったんですけれど、「NO」と言ったり、プロダクト組織として「NO」と決めたりする時は2つあると思うんですよ。
1つは、先ほど言った、巻き込み巻き込まれでいい感じのチームができている時は、今私が話し、吉羽さんも補足していただいたように、これはどう判断するのがいいかという適切なデータや情報を与えることで、チームとして「NO」と言う判断をしていけるように持っていけばいいわけですね。
よかれと思ってアドバイスをしてくるステークホルダーにはどう対応する？
及川：一方で、プロダクトマネージャーは、やはりプロダクト組織の代表者として見られているんですよ。そうすると、理不尽な社内からの要求や、理不尽なお客さんからの要求に対して、明確に「NO」と言うことが必要な時もあるんですね。
吉羽：ありますね、ありますね。
及川：その時は、はっきりがんばって「NO」と言うわけですよね。サラリーマン人生を懸けてでも「NO」と言うわけですよ。
吉羽：なかなか難しいですけれどね。でも、今の及川さんは「理不尽な」と言ったじゃないですか。でもこれって、自分がステークホルダーの立場に立つと、ぜんぜん理不尽を言っているつもりはなくて、たぶんよかれと思って言っているんですよ。
みなさんのプロダクトの外側にいるステークホルダーの人も「ああしたらいいんじゃない？」「こうしたらいいんじゃない？」とか、「ああせい」「こうせい」と言うと思うんですけど、別に「嫌がらせをしたい」とか「こいつらをもっと働かせてやろう」とか思っているわけじゃなくて。基本的になんとか成功させたいし貢献したいので、いろいろアイデアを言ってくれると思うんですよね。
だから、それに対して「NO」をはっきり言わなきゃいけないんだけど、意見をくれたこととか、なんとかして協力してあげようと思ってくれていることに対しての感謝がセットになっていないとまずいよね、という気はするんですよね。
及川：そうですね。
吉羽：「あのステークホルダー、また余計なことを言ってきたので、NOと言いました。もう来ないでください」みたいなのは、まずいなという気はしますね。
及川：そうなんですよ。特に日本の大企業でそれなりのポジションに就いている方は、過去においての会社に対する功労者であり、あるエリアにおいて、しっかりとした実績に裏付けられて今のポジションがある方なんですよね。
その方々もアドバイスを求められたりステークホルダーというところで大事な位置に置かれているから、よかれと思って善意でアドバイスするんですね。でもそれは、的外れなことが多いわけですよ。
吉羽：そう、「昔の知識だったら正しかったです」みたいなのがありますよね。
及川：例えば車の組み込みをやっていた方々が技術のトップのほうにいたりすることもあるわけですよ。今の、1個1個の部品的なものが壊れまくっても、クラウドで全体の冗長性できちんとした信頼性があればいいというのは、組み込みの世界とは違うんですよね。
1個1個の品質の掛け算で最終的な品質が決まっちゃうところなので、組み合わせで冗長性を高めるということがわからないと、「あれもやったほうがいい」「これもやったほうがいい」「それもやったほうがいい」と言うんですよね。
これはすごく難しいんですけれど、「あなたに求めているアドバイスはこれです」とか、もしくは「アドバイスを求めていません」と言っちゃったほうがいい。だから、吉羽さんもよく紹介されているRACIとかDACIを使っちゃうといいんですね。
吉羽：RACIマトリクスというやつですね。
及川：そうです、そうです。だから、「あなたは、インフォームドされるだけです」と。「情報共有されるだけなので、ここでコントリビュートしないでください」と。言いにくいけれども、でもそれを明確にしちゃったほうがいいんだと思うんですよね。
吉羽：それぐらいスパッと切れるものだったらそれでいいかなという気がします。プロダクトに対する有象無象のアドバイスやコメントには、まあまあ決めにくいやつもありますよね。どうですか？
及川：ありますね。例えばアドバイスが多すぎて、すべてをチームが採用した場合に起こり得るデメリットがやはりあるわけですよね。
吉羽：そうですね。
及川：そのデメリットを避けるべきだというのを、チームとステークホルダーで握っておくべきだと思います。
吉羽：そうそう。そう思います。
どこにフォーカスすべきかの共通認識をみんなで持つ
及川：例えば、スピードはわかりやすい話だと思うんですよね。山崎さん（山崎聡氏）が、エムスリーでは確かMVPを2週間でとか、前の対談の時に教えてくださいました。
これが2週間かどうかはわからないんですけれども、「うちの会社ではMVPとかPoCとかファーストリリースをこのぐらいのスピード感でやるぞ」ということを全員が合意できているならば、そこで絶対に取捨選択しなきゃいけないということが全員に理解してもらえると思うんですよね。
吉羽：確かに。僕はふだんスクラムを教えることが多いんですけど、似たような話として、スクラムはここ最近、すごいゴール思考になっていて。プロダクトゴールという、プロダクトが達成したいゴール、3ヶ月で達成したいとか半年で達成したいという計測可能なゴールを定める。その上でスプリント単位で、スプリントゴールを設定して、ゴールを積み上げることでプロダクトゴールにたどり着こうという考えなんですけど。
それも同じなんですよね。ゴールがぶれると最終的に大きなプロダクトのゴールにたどり着かないので、まずは、どこにフォーカスすべきかの共通認識をみんなが持って、それに合わないものは、それこそバックログの順番的にいうと後ろに下げていかないといけない。
バックログみたいなやつを見える化すれば、「これは関係ないよね。あっちも要らないよね」とか「もう捨てちゃえ」みたいなことを、けっこう簡単にできるようになるのかなという気はします。
「NO」の後ろにあるロジックをしっかりと共有しておく
及川：あと1個思ったのが、今のに近いかもしれないんですけれども、「NO」と言う時の後ろのロジックをしっかりと共有しておくことなんだと思うんですね。わかりやすいところでいうと、KPIの話だと思うんですよ。
KPI、トップKPIがあり、例えばこのフェーズにおいては、貢献する先行指標として、このKPIを上げるんだというのにこだわっていれば、「ほかのKPIに対しての貢献は、今やるべきじゃないでしょ」ということがロジカルに導き出されるゴールになると思うんですね。
吉羽：わかります、わかります。そうですよね。でも、今の話って、「ゴールは1つであるべき」とか、「フォーカスすべき」とか、これはもう、みなさん思っていると思うんですけど、それが難しいというのはありますよね。
及川：そうですね。
吉羽：「いや、だって両立したい。3つゴールがあるんですけど」とかはけっこう言われますよね。
及川：あります、あります。
吉羽：どうします？ そういう時？
及川：どう？……いやぁ、でも。
吉羽：まあまあ、ありますよね。
及川：ありますね。だからこれは、人を巻き込むとか「NO」と言うとかいろいろ言っているけど、実際には難しいんですよ。怖い上司だったら、「お前、そこまで言うんだったら覚悟しているんだろうな」とか本当に言われかねないかもしれないんだけれど（笑）。
吉羽：（笑）。
及川：でもここはやはり、どこまで自分が妥協するかに結局かかってくるかもしれないんですよ。
吉羽：そうですよね。だから説明はする、納得してもらえるように話すんだけど、上司・部下の関係になったら、最後は会社の意思決定に従わなきゃいけない。Disagree and commitですかね。
及川：そうです、そうです。そのかたちですよね。
吉羽：ですよね。だから自分が全身全霊を懸けて「駄目なものは駄目」と言うんだけど、いざ会社が決定したら、もう四の五の言わずに従ってそれを達成できるように全力でやります、みたいなのが。
僕はAmazonで働いていましたけど、AmazonもDisagree and commitで、後からぐちゃぐちゃ言うなと。先にぐちゃぐちゃ言って、でも決まったら全力でやりましょうみたいなのは、会社の方針というか行動原則として定義されていました。
及川：でも、Disagree and commitは、その前提としてDRIでしたっけ？ Directly Responsible Individualという人がいて、それはおそらくプロダクトマネージャーなんですよ。
だから、プロダクトマネージャーは肩書き、ジョブレベルじゃなく、これに関してはあなたがDRIである。すべての責任を持つ……。
責任を持つ個人が特定されているというのがあるので、その人が決めたことならば、Disagree and commitで全員コミットしようという話になるんですね。
吉羽：そう、そうですね。確かに、確かに。
自分の中で落としどころを見つけたほうがいい
及川：そういう意味でいうとやはり、プロダクトマネージャーが最終的には意思決定するべきだというのが理想。
吉羽：そうですね、理想ですね。
及川：やはりAmazonもそうだし、GitLab社もそうだし……。彼らが外部に公開しているドキュメントに全部これが書いてあるんですけど。
もしかしたら日本的な、必ずしも合理的な意思決定をしない組織における処世術かもしれないんだけれども、やはり、いつも「NO」とは言えないというのは事実ではあると思うんですよ。
吉羽：それはそうですね。
及川：でも、その時になんとなく思ったのが、じゃあ、ここで「NO」と言うのを諦めることによって自分が何を勝ち得ようとしているのかというような、自分の中で落としどころを見つけたほうがいいと思うんですよ。今回、この上司の言うことを聞くことによって恩を売っておこうでもいいし。
吉羽：（笑）。ありますね。
及川：いったんこれで失敗して、この失敗をもとに上司にも理解してもらおうとか、ここで妥協することによって何を得ようとしているかを持っておかないとずるずるいっちゃうかなと思いますね。
吉羽：それはそうですね。毎回「NO」と言っているとね、ちょっと印象も悪いし。だから、ここぞという時に取っておいたほうがいいというのはあるのかもしれないですね。
及川：でも、実際そうなんですよね。意見が相違する時は、そもそも解決しようとしているものや目的がずれてしまっているか、その目的を達成するための方法論に関して意見が相違しているかのどちらかなんですよね。これは正直、正解がない可能性もあるわけです。
吉羽：ないですね。
及川：そうすると、自分が責任者だからといって、自信を持って全部やっても失敗するかもしれない。ある意味、自分もどっちか迷う時は相手を尊重するほうを取るのもありかもしれないですね。
吉羽：はいはい、それはありですね。
決められないんだったらとっとと実験すりゃいい
吉羽：あと、なんだろう、決められないんだったら実験すりゃいいというのもありますよね。1週間、2週間、試しにやってみましょうと。言っていることも一理あるし、わからないので試してみようと。タイムボックスで切った仕事のやり方をして、1週間ぐらい実験して、駄目だったら捨てればいいやって簡単にできるので。
よく研修で言うんですけど、こういうものを作ろうとか、この機能があったらうれしいよねとかって、妄想の塊じゃないですか。仮説というより妄想と言っているんですけど。
だから、とっとと検証してOKだったら進めればいいし、駄目なら捨てるというのも、下手にぐちゃぐちゃ交渉して長い時間かけて説得して、とやるよりも、「じゃあ、試してみましょう」のほうが早いかもしれないですよね。
及川：一時Googleもけっこうデータドリブンだったのが、どんどん実験しましょうという方向になったんですよね。だからそれは一理あると思います。
吉羽：ですよね。だから、実験しようと思ったら実験するだけの時間的余裕みたいなものは必要ですよね。
及川：あとは、その検証基盤がしっかりないとですね。検証基盤を持てていないところや整備できていないところがあって、そうすると意見の相違があった時に、どうしても机上の空論で終わってしまう。特にデザインとかそうじゃないですか。
吉羽：そうですね。
及川：デザインとか、正直よほどクリエイティブで実績がある人じゃない限り、最後の最後は好き嫌いの部分になりかねないところがあるわけですからね。
吉羽：そうですね。それこそ「リリースしてから、A/Bテストでもしたら？」みたいなこともあるかもしれないですね。
及川：そう思いますね。
（次回へつづく）
