トップ > エンジニアのためのコミュニケーション術

エンジニアのためのコミュニケーション術

エンジニアの方々も「うまく話そう」~エンジニア流の話し方~

本質:簡潔に

エンジニアがプレゼンや自己紹介の場でよく言われる内容は、簡潔にという指摘です。

この「簡潔」について自分の結論を述べると、最も大事なことについて優先順位をつける能力と無駄な内容を捨てる能力に加えて、優先したものを相手がわかる言葉に直す能力のことだと思います。

必要なことだけを相手がわかる言葉にする

Journal of Language and Social Psychologyに掲載された研究によると 「難しい専門用語」で「いらない内容で装飾した」文章であるほど、大衆は理解から遠ざかることがわかりました。 ある意味当然の内容ですが、念のため中身を確認しましょう。

この研究では、650 人の成人がオンラインで参加しました。 彼らは、自動運転車、手術用ロボット、3D バイオ プリンティングという 3 つの科学と技術のトピックのそれぞれについての段落を読みました。 彼らの約半数は、専門用語のない段落のバージョンを読み、半分は専門用語のあるバージョンを読みました。

専門的な用語を使ってしまうと、次のような文章になります。

    • これは、モーション スケーリングと振戦軽減による AIインテグレーションにより機能します。

確かに大変読みずらい文章ですが、一部のエンジニアはこれをそのまま顧客に流してしまいます。 これでは顧客は理解することをあきらめてしまいます。

この文章を 「簡単な言葉で」「必要なものだけに絞る」 様にすると、次のようになります。

    • このシステムは、ロボットの動きをより正確にし、揺れを少なくするプログラミングのために機能します。

以前と比べればとても読みやすい文章になりましたが、どう改善されたのでしょうか。

  1. モーションスケーリングという言葉をなくす。利益だけが欲しい顧客にとっては、ロジックは優先順位が低いため。内部の仕組みを知る必要のあるチームリーダーには必要な内容だが。）
  2. AIインテグレーションという言葉を、ロボットにくくる。ここでもロボットというでか主語に代わってしまったことで、情報が失われているが、顧客がわかる言葉に直さなければならないこともある

このほかにも変更された点は多々ありますが、ここでの結論は以下の通りです。

  • 「難しい専門用語」で「いらない内容で装飾した」文章であるほど、大衆は理解から遠ざかる

  • 「簡単な言葉で」「必要なものだけに絞る」 という点が大事

「怠惰」「シンプル」はエンジニアの美徳（のはず）

そもそも、全体的なエネルギー消費を削減するために多大な努力を払う姿勢はエンジニアにとっての三大美徳である「怠惰」にも当てはまるはずです。

怠惰

全体的なエネルギー消費を削減するために多大な努力を払う品質。他の人が役に立つと思うような労力を節約するプログラムを作成し、作成したものを文書化して、それについて多くの質問に答える必要がないようにします。したがって、プログラマーの最初の大きな美徳です。そのためにも、この本。焦りと傲慢も参照してください。(p.609)

from https://wiki.c2.com/?LazinessImpatienceHubris

ですので、顧客にとって最小限のエネルギーで理解するように表現を変えるということは ある意味エンジニアが目指すべき姿であるともいえます。（そして可能であれば文章化し、同じ質問が二度来ないように努力することも必要かもしれません）

参考:https://qiita.com/ggggnonaka/items/7ea0e6c545bea9ce22ee

準備:上司が欲しい情報はデッキインセプションのどこかにある

ではどのようにして上司や顧客が欲しい情報を整理するのかということですが、 その整理方法は、アジャイル開発のインセプションデッキというものが役に立つはずです。

要は現在あなたが所属しているプロジェクトについて、「ある程度の粒度で目的と手段と根拠を説明できること」と「そのカンペを忍ばせておくこと」が大事になります。 そのためのひな型がインセプションデッキであるわけです。

インセプションデッキで12の質問に答える

インセプションデッキはプロジェクトに関する12個の質問に答えることで出来上がる、プロジェクトを説明するためのスライドのことです。

以下では具体的な内容について触れていきます。

我々はなぜここにいるのか？

ここの問いは、次の質問に答えるためのスライドを用意することに繋がります。

  • なんのために自分たちはチームを組むのか？
  • 自分たちの顧客は誰なのか？
  • そもそもこのプロジェクトが始まった理由はなんなのか？

これらを再確認しましょう。

from https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/

エレベーターピッチを作る

30秒以内に2センテンスでプロジェクトをアピールするもの。 エレベーターピッチとは文字通り、自分たちのプロジェクトをエレベーター内部であった顧客にアピールするぐらい簡潔なものになります。 簡単なテンプレートが存在しますので、それに当てはめるだけで誰でも説明可能です。

想定されている質問

  • このプロジェクトは誰のためにやるの?
  • ほかのプロジェクトとどう違うの?

ビッグファイブについて

顧客のペルソナを想定する際に、その人の特性をパラメーターとして表示することで、よりペルソナの理解が深まります。

よく使われるパラメータは、ルイス・R・ゴールドバーグが提唱したビッグファイブというものです。

from https://jinjibu.jp/keyword/detl/1455/

詳しい内容はまた別の機会に記事にしようと思います。ともかくこのように「性格」を分析し、理解しようとする試みが顧客の理解を深め、最高のUIUXにつながると思います。

パッケージデザインを作る

雑誌のページに君のソフトウェアパッケージが販売されていたらどんな内容が良いだろうか？ という内容。 ビジュアルも含めて雰囲気を伝えることができます。

想定されている質問

  • このプロジェクトはどんな雰囲気なの？
  • 顧客にアピールするべき点は何かな？

ブランドアーキについて

顧客のペルソナを想定する際に役に立つのはビッグファイブだけではありません。 心理学者のカール・ユングは、誰もが無意識のうちに 12 の本質的な性格を持っており、それぞれが優位に立っているという理論を提唱しました。 数年後、マーケティングとブランディングの専門家はこのアイデアを採用し、各ブランドが12のアーキタイプまたは「キャラクター」のいずれかに適合すると主張しています。 これを、ブランドアーキタイプと呼びます。

from https://sketchcorp.com/whats-your-brand-personality/

やらないことリストを作る

「プロジェクトで実現したいこと」とというのは明確になっている。 そこに加えてやらないこともはっきりさせて、一覧に表す。 このように要件をはっきりしておくことで、後々やるやらないでもめることを防ぐことができる

ご近所さんを探す

「プロジェクトの関係者」に含まれる範囲はかなり広い。

そういった関係者をコンタクトをとっておくことはあらゆるリスク回避に役立つ

想定されている質問

  • このプロジェクトの利害関係者は誰?
  • 問題が起きたときは誰に連絡すればいいのかな？
  • このプロダクトの保守は誰?

解決案を描く

チーム全員の認識が揃っていることを確認するために、概要レベルのアーキテクチャ設計図を描いておこう。

想定されている質問

  • どんな技術を使ってやっているの？
  • 誰がこのコードを書くの？

夜も眠れなくなる問題はなんだろう？

プロジェクトで起きる問題について、考えるだけでも恐ろしいものものある。

そういった心配事こそ、話し合う必要がある。 どうすれば被害を最小限に食い止められるだろうか？最悪の事態を避けられないだろうか？ これらの問題をあらかじめリストアップしておくことで、いざというときに対応できます。

想定されている質問

  • システムが致命的なエラーを出したときに、どこに連絡する？
  • このシステムはフルマネージドの方がいいのでは？

期間を見極める

どれくらいの期間が必要なプロジェクトだろうか？ 3ヶ月か半年か9ヶ月か？

想定されている質問

  • おおよそどれくらい時間がかかりそう?

何を諦めるかはっきりさせる

プロジェクトにはいくつか操作可能な要素がある。

期間にスコープに予算に品質。 現時点で譲れない要素はどれか？譲にやむをえないものは何だろうか？

「全部大事！」では優先順位付けができていない証拠なので、すべて大事だとしてもいらないものは捨てるようにしましょう。

想定されている質問

  • プロジェクトが間に合わない場合はどうするの？
  • 期限を延ばすことは可能なの？

コストはどれくらい?

期間はどれくらいかかりそうか？ コストは？ どんなチームならプロジェクトをやり遂げられるだろうか？

想定されている質問

  • 期限まで間に合いそう?
  • お金は足りる?

title:エンジニア流コミュニケーション