背景をきちんと説明し、相手の領域には踏み込まない　PdMがエンジニアと働く時に気をつけたいポイント

プロダクトをコードレベルでわかっていると一言言いたくなってしまう

横澤佑輔氏（以下、横澤）：今度はコミュニケーションの話です。伝え方やチームの作り方にたぶん関連すると思うのですが、エンジニアとして見た時に、このような伝え方をされるとちょっと怒（オコ）になるのか。永嶋さんはいっぱいありそうですが、どうですか？　いつ怒になるんですか？

永嶋章弘氏（以下、永嶋）：僕はないですよ。

横澤：ないんですか？

永嶋：ビジネス好きなので。「いいから早くやろうぜ」と言ったりしますね。もう忘れちゃいましたね。

鈴木康弘氏（以下、鈴木）：そうですね。yamoryの初期や1個前のプロダクトもそうですが、コードレベルで全部わかっているタイミングで言いたくなってしまう気持ちを抑えるのをがんばっていた時期はありました。

逆に、今はもう手が離れてぜんぜんコードを見ていないので、わからないからそちらのほうが楽です。わからないようにしたほうが楽だというのはメチャクチャあります。

永嶋：それはわかります。わかると言いたくなりますね。

鈴木：なりますね。

横澤：逆に、そういうことを言えないビジネスサイドのほうが、むしろ実はよかったという話（笑）。

永嶋：最初のテーマに戻るのですが、変に付け焼き刃程度の知識があるより、「できないのでお願いします」のほうがいいかもしれない。

横澤：「ここの構造のここのモデルが……」などと言われると、「うるさい！」みたいな。

（一同笑）

永嶋：確かにそれはなるわ。

ユーザーの課題感から伝える・「とりあえず」でお願いしない

横澤：明石さんがエンジニアとコミュニケーションを取る時は実際どうですか？

明石衛氏（以下、明石）：僕は、意識していることが2つあります。1つは機能要望を出す時に、お客さまの開発要望の元となる課題感から伝えることです。すると、「その課題解決をしたいのであれば、このような作り方もあって、こちらは重いですけどこのようなものができます」と提案してもらえるので、課題から伝えるようにしています。あとは、「とりあえず」でお願いしないこと。

（一同笑）

横澤：なるほど。

明石：「できるならやって」は絶対に言わないようにしています。背景や理由があって依頼していることをきちんと伝えるように意識しています。そうしたら、あまり怒られないと思っています。

横澤：「『とりあえず』だったらいらないですね」と、僕だったらたぶん言ってしまいますね。

明石：「『とりあえず』で人の工数を使わないで」と言われるじゃないですか。

横澤：そうですね。うちは受託なので、「とりあえず」で全部やったら崩壊するので。

明石：そうですよね（笑）。

横澤：そこはきちんと線引きしないと。

明石：このへんはビジネスサイドからすると意識しているところですね。

横澤：やはり、突然ビジネスサイドから「○○言語で作って」とか「○○アーキテクチャで作って」とか言われたら、たぶん普通のエンジニアは怒ると思う。怒るというか、「おいおい」となると思うんですよ。そういう意味で、判断を委ねるのが結局良いのかもしれないですね。相手もプロフェッショナルなので。

明石：そうですね。それこそ先ほどお二人が言っていた、わからないからこそそのようなお願いしかできないので、それが良い感じになっているとは思います。

エンジニアには背景を説明し、最終的な判断は委ねる

横澤：このへんは、友也さんの中でなにか意識していることはありますか？

伊藤友也氏（以下、伊藤）：真っ先に思ったのは、今、明石さんが言った「背景を説明する」こと。あとは彼らの領域に自分が踏み込まないということです。

それ以外のことで言えば、僕らの会社のエンジニアはものすごくいい人で、本当に心が優しいです。こちらが「これをやってください」という言い方をしてしまうと、やはり依頼側の気持ちを量ってやってくれてしまうことがあります。最終的に「やってください」ではなくて「これをやろうと思っているのですが、どう思いますか？」という聞き方にしています。

横澤：なるほど。

伊藤：最終的にやるか・やらないかを彼らに委ねることはけっこう重要です。

横澤：あまりにも良い人すぎるから、「やって」というとそのままやってしまいます。

伊藤：そうなんですよ。

永嶋：これは別に対エンジニアだけではないですよね。

横澤：それはそうですよね。

永嶋：全部のことに対してですね。

伊藤：本当にそうですね。

横澤：確かに。「やって」と言うとそのままやってしまうことはけっこうありますよね。

永嶋：「実はどう思う？」と聞くと、「実は反対だった」ということもあります。

横澤：よくあります。特にみなさんはタイトルが付いているから余計にそのフォースが出やすいと思います。

永嶋：それはすごく思います。こちらは反対の意見があったら当然言ってくれると思っているのですが、向こうは指示として受け取ることを、タイトルが付いてしばらくはわかりませんでした。それなら「言ってよ」と思いました。

（一同笑）

伊藤：「これはやっても大丈夫ですか？　どう思いますか？」と聞くようにしていて、「大丈夫です」と言われていたのでてっきり納得しているものだと思ったら、あとでコミュニケーションをする中で「あの時、実はそう思っていなかったです」と言われたことが過去の会社でありました。

「でも、聞きましたよね？　その時は『いい』って言っていましたよね？」と話したら、「1回聞かれるだけだと、言いにくいこともある」と。それぐらい言いにくいと思われることがあると知ったので、それ以来、2回ぐらい聞くようにしています。

（一同笑）

横澤：なるほど。確かに。前職が外資系じゃないですか。指揮命令系統がけっこう厳密なイメージもあります。

伊藤：それもそうですね。ただ、2回聞くと「なぜ2回聞くんですか？」と言われることもあるので、そのバランスがけっこう難しいです。

（一同笑）

横澤：なるほど。

エンジニアや作り手側にユーザーのポジティブな声をきちんと伝える

鈴木：先ほどの背景知識についてはいろいろ情報を開示して、インプットはこまめにやったほうがいいと思います。それをやりつつも、情報過多になってしまうと、何に焦点を絞っていくかのかが組織的に合わせにくくなる側面もあります。

PMの機能としてやはり大事なのは、今はこのような課題構造でこれが大事だとか、いろいろな断片的な課題が見えていて、こういう構造でこう考えているとかを、かみ砕いてあげること。今はスプリントレビューの週次のタイミングですが、私が思っていることや課題をまとめてあげるコミュニケーションは、PMとしてとても大切だと思っています。理解しやすくする意味で大事だと思います。プロダクトがお客さまにこのように純粋に喜ばれているというポジティブな意見をチームに伝えたいですね。

横澤：それはそうですよね。意外と伝えないことも多い感じがします。

鈴木：私もやはり課題に向きがちで、そこだけを言ってしまいがちになります。「こう褒められたよ」と営業現場で言われたら、エンジニアや作り手側にその声を届けるためにも意図的にきちんと伝える。

横澤：それはわかります。

鈴木：それはすごく大切だと思っています。

永嶋：今のポジティブなフィードバックをすることについて。僕はOHEYAGOのNPSフォームを内見が終わった顧客全員に送っているのですが、けっこういいんですよ。全部Slackに通知するようにしたら、エンジニアに限らずみんな「自分たちはイケていることをやっているんだ」と思える。

横澤：「お客さんは喜んでいるんだ」と。

永嶋：だんだんと調子が出てくるんですよね。メチャクチャ良いですよね。社内の口コミにもなるし、「俺らのプロダクトってイケているんだ」という雰囲気になるので士気も上がるし。

横澤：うちは受託で間接的だから、そこはより意識していないとまったくわからないです。なのですごく意識しています。

（次回へつづく）