はじめに

自分は３ヶ月くらい前に、プロダクトマネージャーからエンジニアに転身しました。
その中で、エンジニアの日々の苦労の半分くらいはコミュニケーションによって回避できるのではないかと思うようになりました。

例えば日々の仕事の中で「こういうことってできますか？」「こういうデータを出して欲しいです！」
と相談や依頼を受けて対応しても
「言われた通りに対応したつもりが何度も修正が発生する...」「作ってと言われて作ったのに使われない...」
となってしまう状況に思い当たる節がある人もいるのではないでしょうか？
こういう状況も、少し意識してコミュニケーションを取るだけで回避できることが多いです。

僕はプロダクトマネージャーとしていろんな関係者とコミュニケーションを取る機会が多かったからか、
普段こういったコミュニケーションにおける苦労が少ないなと感じたので、普段意識していることをまとめてみようと思います。

コミュニケーションとは何か

コミュニケーションについて語る前に、そもそもコミュニケーションとは何なのかを定義しておきましょう。
『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』では、以下のようなことが書かれています。

真に組織に求められるコミュニケーション能力とは、コミュニケーションの不確実性を減少させる能力のことだといえます

「コミュニケーション不確実性」をさらに砕くと以下の３つに整理されます。

他者理解の不確実性：人は他人や事象を完全には理解できない

伝達の不確実性：コミュニケーションが到達するとは限らない

成果の不確実性：仮に理解されたとしても予想されたように行動するとは限らない

そして「不確実性を減少させる」とはどういうことかについては以下のようにあります。

シャノンは、「不確実性を減少させる知識」のことを「情報」と定義しました。
(中略)「不確実性を下げること」はつまり、シャノンの定義に従えば、「情報を生み出すこと」に他なりません。

上記から、この記事ではコミュニケーションを
「コミュニケーションの不確実性を減少させるために、新たな情報を生み出す行為」 と定義します。

現場で起きる問題

システム開発において、「顧客が本当に必要だったもの」という有名な図があります。

(画像はこちらから拝借しました)

f:id:link-and-motivation:20211126170344p:plain

この図が表していることとしては
顧客自身が、自分が本当に必要なものを把握する事が難しく、
そしてそれをエンジニアが正しく理解することもまた難しいということです。

これはプロダクト開発という大きな話だけでなく、日々の仕事の中でも同じようなことが言えます。
記事の冒頭で出した例のように、「言われた通りにやったのに...」という状況になってしまう時は、だいたい上の図のように

依頼者の認識と、それを聞いた自分の認識がずれている
そもそも依頼者にとって本当に必要なものと、依頼者の要求がずれている

という状況に陥っている可能性が高いです。

なぜ問題は起きるのか

このようなことが起きてしまう要因の一つが、
コミュニケーションが正しく行われず、必要な情報が不足してしまうことです。
言われた通りにやっているのに...となってしまう時は、多くの場合
依頼者が言っていることしか見えていないという状況です。

実際はその裏に、依頼者の依頼者がいたり、説明と乖離がある「本当に必要なもの」が存在していたりするのですが、
それらに関する情報がないままにアウトプットをしようとしても正しいアウトプットに繋がりません。

f:id:link-and-motivation:20211126170456p:plain

どんなコミュニケーションをとると良いか

上の定義に基づくと、コミュニケーションとは不確実性を下げるために「新たな情報を生み出す」ことなので、
本当に必要なものがなんなのかを把握するためにいかに情報を引き出すかということが大事になってきます。

以下で具体的に、どのような観点でコミュニケーションをとっていけば良いかを整理していきます。

背景課題が何なのかを確認する

大事なのは、言われた通りに対応することではなく、依頼者の課題が解決されることです。
先ほども書いた通り、依頼者の言っていることだけしか見ていないと、正しいアウトプットにつながりません。

依頼や相談を受けた際はまず初めに、
なぜこの依頼をするに至ったのか？どんな課題を解決したくてこの相談をしているのか？
というように依頼者の発言の裏側に何があるかを確認するようにしましょう。

誰が困っているのか/誰が使うのかを確認する

そもそも、依頼者も自分が困っているから依頼してきたのではないことも多いです。
（上の図のように、依頼者の向こうにさらに依頼者がいるケースです）
その依頼者の先に誰がいるのか？というのをしっかり確認しましょう。

同じように「データ出してください！」と言われた時も、
顧客から要望があった、上司から頼まれた、などいろんなケースが考えられます。
最終的に誰が使うのか、によって
出してはいけないデータ、付加しておくべきデータなども変わってきます。

どのように使うのかを確認する

また同じように「データ出してください！」と言われた時、
そのデータをどのように使うのかも様々です。
そこからさらに分析をかけたいのか、それともサマリを資料に載せたいのか
などによってもアウトプットの形は異なってきます。

依頼されて作ったもの、対応したものが最終的にどう使われるのかを確認しておきましょう。

期日とその理由を確認する

なんかこれはもう当たり前も当たり前なのでいまさら書くことでもないんですが、ちゃんと確認しましょう。
明後日時間あるからやるか〜と思ってたらめちゃくちゃ急ぎで明日の朝には必要、とかいうことも全然あります。

そしてその上で、なぜその期日が設定されているのか？をきちんと確認しましょう。
適切な優先度付けをするためというのももちろんあるのですが、いざ確認してみると
え？それならもっと急がないとダメじゃないですか？みたいなことも発生します。
言われた期日を守って対応したけど、結局顧客やユーザーに迷惑がかかってしまった、なんてことになっては無意味です。

あとがき

改めてまとめてみると、まあ基本的なことばかりだなと思いますが、こういうちょっとした部分でずいぶん楽できるものなんだなあというのを最近は感じています。
特に僕のようなエンジニアになりたての時に技術的な部分以外でつまづく時間はもったいないなと感じるので、こういったことで悩んでいる人の参考になれば幸いです。