スマートニュースVP直伝! エンジニアと一緒に働くすべての人向けのコミュニケーションTips

f:id:smartnews_jp:20190827104913g:plain
Vice President of Ad Product 前田俊太郎

「A/B Test機能におかしいところがあるのでみていただきたいです」
「どなたか、この現象の原因がわかるエンジニアさんいますか?」
「これストップしてください」

このような表現で、エンジニアに仕事を依頼してしまったことはありませんか? 目の前の仕事で手一杯になっているときは特に、普段よりもコミュニケーション不全を起こしがちです。

テック企業に務める従業員ならば、より高い成果を出していくため、職種を横断して協力し合いたい気持ちは同じはず。エンジニアとビジネスサイドの従業員のように、異なるプロフェッショナル領域を持つ人同士が、スムーズにコミュニケーションをとって業務を推進していくには、どのようなことに気をつければ良いのでしょうか。

エンジニアとの円滑なコミュニケーションの実現を目指して、今回はVice President of Ad Productとして広告のプロダクトマネジメントをはじめ、エンジニアの組織開発まで幅広い領域を担当する前田俊太郎さんに相談してみることにしました。

VPが教える「エンジニアと円滑に働くためのコミュニケーション術」

前田 もしかしたら、エンジニアとコミュニケーションをとることに苦手意識を持ってる人もいるかもしれませんね。依頼や質問をするときに、適切に情報を伝えられずにコミュニケーションが効率的にできなかった経験がある人もいるのではないでしょうか? 今回は、Slackで行われるような簡易的なコミュニケーションを想定してお話をします。

── はい、よろしくおねがいします。

前田 コミュニケーションをはかるときの方針は、大きくこの2つです。

1. コンテキストに依存したコミュニケーションをせず、「課題」「考え」「要求」を明示的に伝えるように意識する。
2. 情報をちゃんと構造化して伝える。

いずれも結構大変なので、いきなり実践する必要はありません。自分のペースで少しずつ試していくことをおすすめします。「こういうこと気をつければよいのか」「余裕があるときだけやってみよう」くらいの気持ちで大丈夫です。

── できることからはじめるのでいいんですね。ちなみに1つ目の「コンテキストに依存したコミュニケーション」って、なんですか?

前田 「伝えたいことを理解するのに、実際の言葉や文章には含まれてない暗黙的な前提を必要とするコミュニケーション」と定義します。もう少し噛み砕いてお伝えすると「他人が自分と同じ文化的背景をもってること」や「他人が自分の頭の中を大まかに理解していること」を前提として話し始めるようなコミュニケーションです。

── なるほど。逆に、コンテキストに依存しないコミュニケーションとはどんなものですか?

前田 コンテキスト非依存のコミュニケーションはこのような前提をおかずに「どういう課題を持っているか」「なぜそれが問題だと思うか」「相手にどういう行動をとってほしいか」などをすべて明示的に文章や言葉として伝えるようなコミュニケーションのことを指します。では、コンテキスト非依存のコミュニケーションをすることでどんな嬉しいことがあるのでしょうか。僕は、以下の2つだと考えます。

1. コミュニケーションの主体が考えを整理するようになる
(課題や問題が曖昧なまま話してしまうことって、とても多いですよね)
2. コミュニケーションを受け取る側の理解が簡単

コンテキスト依存のコミュニケーションは、主体はすごく楽できるけど、受け取る側に大きな負担を強いるものです。全体のコストを考えるとコミュニケーションの主体がちゃんと考えを整理して、コンテキスト非依存のコミュニケーションをしたほうがよいと思います。

ただ、日本の文化はそもそもかなりコンテキスト依存のコミュニケーションが多い文化だと認識しています。そのため、コンテキスト非依存のコミュニケーションスタイルを身につけるには努力が必要です。ただし、努力は必要でも努力に見合う価値はあるはずです。すでにスマートニュースのメンバーのBackgroundが多様化している中では、かなり重要なスキルだと思いますよ。

「コンテキスト依存のコミュニケーション」の悪例と改善例

前田 「コンテキスト依存のコミュニケーション」を具体的な例を表にして明示してみます。

[CASE1] 調査依頼

悪例
「このDashboardこわれてるんですけど、みてもらえないでしょうか?」

NGポイント
何がおかしいと思うのか? 相手にいつまでにどういう行動をとってほしいのか?が自明ではない

改善例
「このDashboardの X日のYの数値がいつもより二倍程度大きいです。このような高い数値になることは考えづらくデータの集計ミスだと思うので、確認して、もし問題があれば修正してもらえないでしょうか?緊急ではないのでお手すきの際で大丈夫です」

[CASE2] Feedback

悪例
「僕のRecommendでこの記事が出てました。さすがにおかしくないですか?」

NGポイント
何が問題だと思っているのか、どういう結果を期待していてどこにギャップがあるのか、相手に何をして欲しいのかなどが不明。

改善例
「僕のRecommendにこの記事が出てました。この記事のサムネイル画像は過度な暴力表現であり、基準に抵触していると考えます。配信除外されるべきだと思うので、ご検討よろしくお願いします」

[CASE3] Manager Feedback

悪例
「Aさんはコミュニケーションに課題があるよね」

NGポイント
どのようなケースのどういう行動に課題があったのか具体的に提示し、自分は何を期待しているのかも合わせて示すべき。そして、改善案も一緒に考える必要あり。

改善例
「AさんがこないだのMTG X で使っていた言葉 Y は、かなり強い表現であり、相手が萎縮してしまうと思います。同僚に使うべき言葉ではなかったと思うけどどう思いますか? 同じことが言いたいならこういう言い方もあるけど」

[CASE4] タイプミス

悪例
「打刻修正してくだしあ」

NGポイント
相手が日本語のNative話者であり、このような表現でも瞬時に訂正してもらえることを期待している。

改善例
「打刻修正してください」

[CASE5] MTGの招待

悪例
”XXXについての相談" としか記載されていないミーティング

NGポイント
想定Agendaない。ミーティングのゴールがない。

改善例
簡易的でも良いので、その日のゴールと想定Agendaをdocumentにまとめて招待するときにカレンダーに記載する。


── 具体例を見ていてハッとさせられました。無意識のうちに、実はかなりコンテキストに依存しているのかもしれません。

前田 他にも例は無限に挙げられますが、以下の3点を明示的にしてコミュニケーションするのが良いと考えます。

1. 何がなぜ問題だと思っているのか
2. 自分の期待は何で、どこにギャップがあるのか
3. 相手に何をしてほしいのか

── 長期間同じプロジェクトに関わっていたことのある仲間とのコミュニケーションでは、ついコンテキストを省略してしまうシーンがあったかもしれません。気をつけます。

前田 もちろん、ハイコンテキストなコミュニケーションはショートカットになりうるので、相手が自分の頭の中をある程度理解していると確信できるときは使ってもよいと思いますが、乱用は危険です。

情報を構造化して伝える|フォーマットを有効活用しよう

前田 さて、コンテキスト非依存のコミュニケーションにトライできたら、次は情報を構造化して伝えるよう意識してみてください。

── 情報の構造化?

前田 はい。課題、事実、目的、自分がよいと思う解決方法など、あらゆる情報をごちゃまぜにしたり、もしくは一部の情報が欠落した状態でコミュニケーションをはかってしまうような事例がおこりがちです。必要な情報が整理されていないとエンジニアの専門性を活かしづらいので大変非効率です。エンジニアが課題解決しやすい情報の構造化をして伝えるといいですよ。フォーマットを作っておくと便利です。また、いくつか例を提示して説明しますね。

[例1] 障害やバグを指摘する際のコミュニケーション

── 何かおかしな挙動を見つけたから、エンジニアとコミュニケーションをとりたいけれど、どう伝えたらいいんだ……って思っているひとは多そうです。

前田 大きな問題が発生していると思われるとき、もしくは問題の調査をしているときは、以下のように情報を構造化して伝えています。フォーマットにすると、このような感じです。

1. Fact(事実)
2. The Problem(問題)
3. Expected Result (Optional but highly recommended)(期待している結果)
4. Assumption (Optional )(仮定)
5. Opinion of how to solve the situation (Optional)(状況解決するための方法)
6. Proposal for next action (Optional)(次のアクションの提案)

前田 事実(Fact)と、仮説(Assumption)をわけて伝えることが重要です。事実は正しいか、正しくないか確認できますし、事実さえわかっていれば、エンジニアが別の仮説を出せるかもしれません。なので、事実をちゃんと列挙する。その上で自分が問題だと思っている事象について事実をもとに説明する。そこから先の自分なりの仮説などについては書いても良いけど、その場合も事実と仮説はわけて記載するのがおすすめです。

── 1〜3の部分をしっかり伝えるようにするといいんですね。このフォーマットがあれば、今日からでも実践できるかも……。ただ、もっと具体的な例を教えていただきたいです。

前田 では、具体例を考えてみましょうか。よくありそうな事例を創作してみます。

A/B Test機能におかしいところがあるのでみていただきたいです。

── たしかに、よくありそうな例ですね!

前田 この内容を、さきほどのフォーマットを使ってエンジニアに伝えるのなら、こんな感じにするのがベストです。

Fact
(事実)
1: A/B Testの設定を作成した。アメリカのAndroidの10%のユーザーを対象として、A/B Testを実施している。
( https://◯◯◯...◯◯◯.◯◯ )
2: 下記のページから実際に確認できる、A/B Test適応ユーザーがX人となっている。
( https://◯◯◯.◯◯◯ )
Expectation
(期待している結果)
アメリカの全ユーザーがY人であることを考えると、自分としては、Yの10%程度の数値が上記のページで観測される想定であった。これは実際確認されたXとはかなり乖離した数字であり期待と異なります。
Assumption
(仮定)
設定におかしいところがあるか、もしくはA/B Test機能になんらかバグが混入している気がする。昨日リリースがあったようなのでそれを少し疑っています。
Proposal for next action
(次のアクションの提案、お願い)
こちらの調査お願いできないでしょうか? 明日までには正しい状態にもっていけると大変嬉しいです。今日中に一次回答もらえると嬉しいです。

── 事実や期待していた結果が明記されていると、障害やバグを指摘するに至った背景がわかりやすいですね

[例2] 課題解決のためのコミュニケーション

前田 他の例も考えてみましょう。課題解決のためのコミュニケーションをはかる場合です。

── エンジニアに解決してほしい課題、たくさんあります!

前田 このとき、一番多いのは XY 問題と言われるコミュニケーションの仕方です。自分が本当に解決してほしい問題Xを伝えずに、自分が解決手段だと考えている、Yの解決について聞いてしまうことがあります(※ XY problem)。

── XYプロブレムについては、Data Science Teamの小松さんも言及してますよね。

saleszine.jp

前田 そうですね。XY問題を回避して、きちんと課題を解決してほしいときには、以下のように構造化すると伝わりやすいです。

[Why] ゴールや解決したい課題の共有
[Why] 重要度や緊急度が伝わるFact
[How] 自分なりの解決方針の提案(Optional)
[What] 作って欲しいものや、やってほしいことを記載する(Optional)

── この項目を埋める形で伝えればいいんですね。だんだんわかってきました。

前田 こちらも具体例を交えて、もう少し詳しく説明します。

このSQLのQueryを高速化できないでしょうか? Queryのなかでランダムで並びかえてるのですが、タイムアウトしてしまいます。

これは実際にエンジニアではないメンバーからあったSQLを高速化したいという質問です。質問の内容はSQLの高速化ですが、質問者が本当にやりたかったことは、とあるシステムの入力に使うために、一定の条件を満たしたユーザーをランダムで2グループずつ抽出し、それぞれを別のCSVファイルとしてダウンロードしたいということでした。この真の課題が質問からは読み取れず、ここが改善ポイントです。

このケースの場合、本当にやりたいことを実現するためには、質問にある「ランダムに並び替える処理」は必ずしも必要ではないのです。もしエンジニアがこの質問を受けSQLの高速化の方法について調べはじめると実際の課題解決からは遠ざかってしまいます。

今回のケースでは、以下のように質問をすればスムーズにコミュニケーションをとれたでしょう。

[Why] ゴールや解決したい課題の共有 ◯◯の条件を満たしたユーザーをランダムで2グループずつ抽出し、それぞれを別のCSVファイルとしてダウンロードし、システムXの入力として利用したい。
[Why] 重要度や緊急度が伝わるFact これは、□□のプロジェクトのブロッカーになっており、明日中に何らかの方法で解決する必要がある。
[How] 自分なりの解決方針の提案(Optional) 自分としては、以下のようなQueryで解決できると考えたが実際にはランダムに並び替える処理でタイムアウトしてエラーになってしまっている。
[What] 作って欲しいものや、やってほしいことを記載する(Optional) どのようにQueryを書き換えれば自分の目的を実現できるか教えてもらえないか? 明日までに対応したいので、今日中にQueryを可能であれば直したい。

[例3] 新機能の要望を伝えるコミュニケーション

── 前田さん、目の前の問題を解決するためのコミュニケーションだけじゃなく、新機能の要望もエンジニアに明確に伝えられるようになりたいです。そういうときに使えるフォーマットも考えてもらえませんか?

前田 一番良いのはPRD(※プロダクト仕様書)を作ってもらうことですけど、かなり大変なのでカジュアル版のフォーマットを用意してみました。

[Why] Objective 、解決したい課題。その課題が解決したといえる成功の定義
[Why] その問題が重要であることを示唆する定量的なFact
[Why] 定量的なImpact Estimation
[How] どのように問題を解決するべきかという自分なりの仮説 (Optional)
[What] 解決方針を満たすような解決案の提案(Optional)

今回は架空の問題で見てみましょう。画像入稿システムの効率化をしてほしいときの要望依頼の例です。

課題の提示 とあるシステムに画像を入稿するオペレーションを効率化したい。
Fact(事実) 現在管理画面から一枚一枚、人が入稿作業をしており、この作業に大変時間がかかっている。概算ではチームの30%の時間がこのオペレーションに充てられている。
成功の定義
インパクト
今後も画像の入稿量自体は増加していくと考えられるため、このオペレーションを効率化したい。具体的には現時点でチームの30%を時間がかかっているが、5%以内に下げたい(成功の定義)。これを実現できれば、チームが本質的な課題に多くの時間を充てられるようになる。また、半年後に画像の入稿量が倍程度まで増えることが予想されるが、そのような状況にも対応可能になる(Impact Estimation)。※可能であればDAUや売り上げなど、より直接的なビジネスインパクトを定義できると良いです。
解決方針の
仮説
Localにある画像とそれに対応するメタデータをアップロードできればよいため、一枚一枚アップロードするのではなく一括でアップロードする機能を作れば解決できるのではないか?
具体的に
作って欲しいもの
画像の一括入稿システムを作って欲しい。

前田 もし、このような伝え方をしてくれると、優先度を上げやすいし、かつ解決方針についてももっとよい解決の仕方をエンジニアが提示することができます。

── 教えてもらったフォーマットを活用すれば、円滑にコミュニケーションがとれるようになりそうです。とても参考になりました!

感謝を伝えて終わりにせず、必ずFeedbackをしてほしい

前田 最後に、ビジネスサイドのみなさんにお願いしたいことをお伝えしてもいいですか?

── はい、なんでしょう?

前田 エンジニアは自分が時間をかけて作ったものが、どのような価値をもたらしたか常に気にしています。特に、機能開発においてはFeedbackは重要です。Feedbackをすることで次回以降エンジニアが類似の問題に手を付けるときに、よりよいものを作れる可能性が高まります。

── 「感謝の気持ちを伝えて終わり」にならないように意識します。

前田 ここまでお伝えしてきた点を意識して適切なFeedbackを行い、お互いに学習してくことで、次回以降の類似の要求の優先度が上がりやすくなります。新しい機能が実装された際には、良い点も改善点もFeedbackしてみてください!

── 前田さん、丁寧なアドバイスありがとうございました!

スマートニュース株式会社 採用情報