この記事は『カオナビ Advent Calendar 2023(シリーズ2)の 7日目』です。

はじめに

今年のアドカレ投稿も4本目になります
カオナビでVPoEやってるKeeeenです。

今回は『こいつ優秀だな！』と思われるような、質問者や意思決定者の思考をhackしたコミュニケーションの仕方について書いていきます。

結論

結論から言うと最も重要なのは『相手が知りたい順と粒度で伝えること』です。

コミュニケーションに関連する多くの書物では『結論から語ることが最も大事』と論ぜられていることもあります。しかし実際は場合によってアンチパターンになることもあります。

今回はその辺も含めてコミュニケーション手法について掘り下げていきます。

エンジニアが陥りやすい罠

エンジニアはその職種柄、コーディングや設計中など作業をする場合かなり細部まで注意していることが多いものです。時にはメテオフォールが起きないように保険をかけることも多いでしょう。
弁護士であれば六法全書がそうであるように、我々エンジニアにとっては企画をする人や上司の言質、仕様書がそれに当たるでしょう。
もちろん近年ではスクラムなどの開発手法が広まり、チームとしての開発が何たるかを理解されつつありますが、いまだこの沼から這い上がれない人は少なくないと思います。

ミスはしたくないし、バグは出したくないという心理から大体の人は(稀に『Done is better than perfect.(たぶん動くと思うからリリースしようぜ)』という人もいますが)、基本的に思考が保守的になりがちです。

保守がいいか悪いかはさておき、その心理が働くから『私は言いましたよ』というエビデンスを元にコミュニケーションを取る人がいます。これが同じ職種同士であればある程度成立するのかもしれませんが、こと立場が異なる人とのコミュニケーションではこれが思わぬ地雷になることがあります。

例えば

『この仕様を変更は可能か？』

というオーダーに対し

『インフラでまずAWSかGCPか選んで、DR観点を考慮し、言語はメモリー管理までしっかり出来るCあたりで書いてｘｃｖｂんｍ，。・…』

と答えてしまうのがその一例です。
客観的に見るとYesかNoで答えろよ！と思うかもしれませんが、大なり小なり多くのエンジニアがこういうコミュニケーションの仕方をしてしまっています。かく言う私も昔はしてしまっていたと思います。

ただこれは職種柄しょうがないことであることも理解しています。
エンジニア的に即断できない場合はそれを実現するために積み上げながら思考を進めることが多いので、それをそのままコミュニケーションをとってしまうとこうなってしまいます。

このように(もちろん全員が全員そうではないのですが)、そもそも回答、仮説、思考をパラレルに動かすとどうしても何かが欠落し、相手がほしい/知りたい回答とは乖離してしまうのです。
なので我々エンジニアはコミュニケーションの仕方について改めなければならないのです。

相手が知りたい順と粒度で伝えること

そこで大事になる考え方がこの『相手が知りたい順と粒度で伝える』というわけです。
我々エンジニアが積み上げながら、ある種帰納的に回答するように質問者はその逆でファクトから仮説をもって逆算する形で答えを求めています。
これが『相手が知りたい順と粒度で伝えること』なのです。

ではより詳細に見ていきましょう。

相手が知りたい順とは

例えば先の仕様変更の件で考えてみましょう。

『この仕様を変更は可能か？』

この裏には『できる/できない』という質問者なりの仮説があります。
『できる』が質問者の仮説であり回答者の回答が『できる』である場合、それ以上のことを求められることはないでしょう。しかし逆に質問者の仮説が『できる』に対し回答者の回答が『できない』だった場合、仮説と回答が異なり質問者にさらに情報をほしいという状態を生み出すことになります。

プログラミング的に書くとこんな感じでしょうか？

$answer="できる"; //できる or できない　を入れる
question("できる", $answer);

function question($質問者の仮説, $回答者の回答){
    $質問者の仮説 ??= "なぜ？";
    $回答者の仮説 ??= "できる";

    if($質問者の仮説 = $回答者の回答){
        exit; //正常終了
    }
    else if($質問者の仮説 != $回答者の回答 && ($回答者の回答 = "できる" || $回答者の回答 = "できない")){
        //次の仮説をgenerate
        quetion($hoge, $fuga); //$hogeには質問者の仮説、$fugaには回答者の回答が都度はいる
    }
    else if($質問者の仮説 = "なぜ?"){
        horisageru(); //質問者が分からないところを聞く
    }
    else {
        throw new Exception('どっちなんや！！！！'); //質問者の異常終了、思考停止
    }
    exit;
}

基本に異なる立場の人とのコミュニケーションはこの再帰的な関数を回すことになります。
※厳密には『できる/できない』と『できない/できる』で分岐は異なりますがここでは省略します。

重要なのは質問者の仮説と回答者の回答が一致するか否かということです。
そしてこのif文にひかからずelseに入るコミュニケーションが最もダメな例となります。

相手が知りたい粒度とは

さて次に粒度の話です。

早速例から考えていきましょう。
例えばバグが複数発生している、具体的にはA〜Zのバグが発生しているプロダクトがあるとします。
この場合の最適解は以下の通りです。

A〜Fは軽度のバグ
G〜Vは中度のバグ
W〜Zは重度のバグ

このうち

Wは危険度75%
Xは危険度80%
Yは危険度75%
Zは危険度90%

なので

Zを優先度高く対応すべき！

このように情報の粒度をある程度グルーピングしてドリルダウンした報告ができると、意思決定者の理解を劇的に進めることができます。逆に良くないのは『バグXがやばいです！』と進めるパターンです。
緊急性があるものであればある程度信頼ポイントで成立する場合もありますが、これが複数ある機能における実装の優先順位の話であれば上の報告方法がベストでしょう。

それは先のエンジニアが保険を掛けまくりながら話すのと同様に、意思決定者は全体感を把握しながら答えを探していきたいという欲求を持っているからです。これはエンジニアの考慮漏れに対する恐怖心と同様に、全体に締めるその事象が及ぼすシェアを知った上で判断しなければ誤った判断をしてしまうかもしれないという恐怖心を持っているからです。

まとめ

いかがでしたでしょうか？
このように質問者や意思決定者の意志をhackして最適なコミュニケーションを取ることで最速の理解を得ることができるようになります。
今回はコミュニケーションとしての話をしましたが、この考え方はプレゼンなどでも応用できるものです。

是非、質問者や意思決定者とのコミュニケーションにお役立ていただけると幸いです。

それではシリーズ2の8日目の記事もお楽しみください！！