はじめに
エンジニアやプログラマであっても（もしくは、だからこそ？）、仕事においてコミュニケーションがとても大切で、質や生産性、ひいては信頼に直結することは言うまでありません。
この投稿では、私が普段、資料やテキストベースのコミュニケーションを行うときに考えていることを書いてみます。
コミュニケーションそのもの、または資料や文章を作るのが苦手、という人いると思いますが、私の感覚では、システマチック・ロジカルに、プログラミング感覚で楽しめるものなので、そのへん共有できたらいいなというのが目的です。
主に3〜5年目くらいまでの若手を対象として想定しました。それ以上の方は、言語化せずとも何気なく実践していることだと思います。
テキストコミュニケーションって？
ここでいう「テキストコミュニケーション」とは、
- テキストや図表を介して行われる、
- お客様に対して、または開発チーム内での、
- 提案や報告、質疑応答など
のことです。
言い換えるなら、仕事において日常的に発生する、会話以外のコミュニケーションです。
各種設計書などの開発ドキュメントは含まれません。
「テキストコミュニケーション」でググると、単に Slack などのチャット上でのコミュニケーションだったり、その場における字面の表現（絵文字がどうのとか）が主に出てくるようです。
ただこの投稿では、メールやチャット、Backlog や Redmine などのタスク管理ツールでのやりとり、資料を交えた提案など、それよりも広範な意味で捉えます。
図とか入ったパワポ資料を作って、対面でプレゼンするとしても、テキストコミュニケーションに含めています。ここで言いたい趣旨から考えると同様に捉えられるからです。
テキストコミュニケーションの構成要素
テキストコミュニケーションは、「ゴール」「ストーリー」「テクニック」で構成されます。
- ゴールは、そのコミュニケーションで達成したい目的です。
- ストーリーは、ゴールを達成するための筋書きです。
- テクニックは、ストーリーを実装するための資料作成スキルです。
これらの要素がしっかり揃えば、質の高いコミュニケーションが成立して、仕事がスムーズに進められるはずです。
で、この投稿で言いたいのは、**ゴールとストーリーが大切！**ということです。
ゴール
「誰に何をしてほしいのか」がゴールになります。
そもそも、仕事におけるコミュニケーションの目的は、他者のアクション、つまり相手に何かしてもらうことでしょう。
たとえば内容としては、
- A案とB案のどちらかを選んでほしい
- 疑問点があるので回答してほしい
- Go / Stop を判断してほしい
- 報告を聞いて理解 / 納得 / 安心してほしい
- 問題点を正しく認識してほしい
など。
まずこのゴールを自覚、設定する必要があります。意志なくコミュニケーションを始めてしまうと、相手に負担がかかったり、自身の利益にならない結果になってしまいます。
ゴールの解像度は、高い方がいいです。というのも、ほとんどの場合、よく考えるとフラットなゴールにはならないはずです。つまり、「こちらを選んでほしい」とか、「こう理解してほしい」など、あなたの意志が乗るはずだからです。
- 解像度が低いゴール → 「どちらか選んでもらう」
- 解像度が高いゴール → 「こちらを選んでもらう」
分かりやすい例を挙げると、フラットに「自社と契約するかどうかを選んでもらう」とか、あり得ないですよね。「契約してもらう」ために頑張ってコミュニケーションを構築するはずです。
もっと日常的なコミュニケーションでも同じように、できるだけ解像度の高いゴールを設定すれば、よりコミュニケーションをコントロールできる余地が広がります。
ストーリー
ストーリーは、相手をゴールに導くための作戦です。
ストーリーはいくつかの要素に分けられます：
- 何を知らせるべきで、何は不要か（強調すべき点は何か）
- どのようなフォーマットが適切か（テキスト？表？図？）
- どのような場が適切か（メール？チャット？オンライン？オフライン？）
- 誰に伝えるべきか、誰には伝える必要がないか
たとえば、A案かB案か選んでもらう資料を作る場合、初歩的なポイントとして、「オススメを一番目に持ってくるように」って言われますよね。些細なことですが、相手をゴールに導くための工夫なので、これもストーリーの一部だと思います。
ストーリー作りに必要なもの
想像力
ストーリー作りに必要なのは、まず何より相手に対する想像力です。
- 何を知っていて、何を知らないのか
- どういう職種で、どういう経験、スキルがあるのか
- 性格もしくは職種、ポジション的に、気にしていることは何か
などを考慮して、相手がなるべく認知の寄り道なく、スムーズにゴールまで導くための論理的な導線を作ります。
逆に想像力が足りないと、伝わりにくいコミュニケーションになったり、ラリーが無駄に多くなります。
マイルストーンとスコープ
仕事である以上、相手の属性だけでなく、納期も大切な要素になります。
重要なのは、納期そのものではなく、その期日がマイルストーンとしてどういう意味を持っているかです。つまり、単に仮置きの日付なのか、契約上の理由で期末に間に合わせたいのか、展示会に出したいとか、外部的な強制力があるのかなど、つまり「なぜその日なのか」ですね。
さらに、納期までの期間におけるスコープも理解するべきです。マイルストーンの意味から、必要なこととと不要なこと＝スコープが導き出されます。
たとえば開発プロセスをフェーズ分けしている場合は、今回のフェーズの目的は何か、ユーザーに何をさせたくて、何はやれなくていいのか、があると思います。
これらは相手の大きな関心事なので、ストーリー作りにとって重要です。
ストーリーの例
ここで、ありそうな場面を例にしてストーリーってこういうこと、というのを示してみます。
クライアントワークのアプリ開発において、ある要件の実装方法についてお客様にA案 or B案どちらか決めてほしいとしましょう。
- A案は工数はあまりかからないが、要件を100％満たせるわけではない。
- B案はリッチプランで、工数はかかるが超使いやすくて要件を満たせる。
まず、相手にこの基本情報だけ与えて「決めてください」だと、ストーリーがないので、「どう決めればいいんですかね？」となってしまいます。決定までのストーリーが必要です。
相手がエンジニアではないとして、納期に間に合うか？要件を満たせるか？スコープに合致するか？など、相手が気にしそうなポイントを想像すると、こんな感じになるのではないでしょうか：
『A案は工数的にスコープに収まる。その代わり要件満たせない部分もある。ユーザーは、この操作はできるがこの操作はできない。ただ本フェーズの目的が◯◯◯であることを考えると、許容範囲と思われる。次フェーズで機能を追加することは可能。こちらもその前提で設計する。』
『B案は技術的には可能だが、現行体制では納期に間に合わない。納期を延ばすか、増員する必要がある。追加リソースはこれだけかかる（工数 or 金額）。』
こう説明すると、大体はA案が選ばれそうな気がしますね。何らかの理由でB案の方が都合がいい場合は、また違ったストーリーになるでしょう。
フォーマットの話をすると、本筋の説明は文章で OK としても、ユーザーの操作性を説明する部分には、画面モックなどを添えるとさらに良いと思います。特に企画系の部署のお客様であれば、「実際どうなるんですか？」っていうのは気になると想像できるからです。
場も考えます。スキルがあって話が通じる相手であれば、チャットなどが効率的でしょう。丁寧に説明した方がよければ、ミーティングを設けます。当たり前のことですが、何が言いたいかというと、これもストーリーの一部として、意識的に選択する必要があります。
相手がエンジニアかもしくはエンジニア経験がある場合は、また別のストーリーになるかもしれません。
報告の場合
提案ではなく、単なる報告の場合にも、ゴールが存在する限りストーリーは必要です。
報告内容のどこを見てほしいか、どう理解してほしいか、がゴールになるでしょう。これは重要視してくれなくてよくて、こっちを見てほしい、みたいな。
たとえば、報告書のアジェンダ①の文章が3行で、アジェンダ②が30行あったら、②に目がいきますよね。実は②はさらっと流してほしいのに、後から質疑がバンバン飛んできて、むしろ見てほしかった①がうやむやになるかもしれません。
報告であってもゴールとストーリーを設定すれば、伝えたいことがスムーズに伝えられるはずです。
（上の例だと、②の細かい説明は別紙にして添えるとかでしょうか。）
テクニック
テクニックとは、ストーリーを実装するための文章・視覚効果スキルです。
- 文章力
- デザインスキル
- 資料作成スキル
- パワポなどのツールの使用スキル
- もしかしたら HTML や CSS も
たとえば、どのように強調したい点を目立たせるか、もしくは、ある種類のデータを効果的に見せる場合に、円グラフがいいのか、棒や折れ線か、など、伝えるべき情報が複雑になると、ある程度のテクニックが必要になる場合があります。
私は、ゴールとストーリーが、テクニックよりも重要だ、と考えています。なぜなら、テクニックが必要なのは誰でも気づけることだし、学習もできるからです。
「ノンデザイナーズ・デザインブック」を始めとして一般ビジネスマン向けのデザイン入門書はいくつか出版されていますし、資料作成術みたいな本も最近たくさん出ています。そういう本を読んだり、同僚が作る資料を見たりすればテクニックは養われると思います。
テキストコミュニケーションが苦手な人
最後に、テキストコミュニケーションが苦手な人の原因と対策についてです。
「ゴール」「ストーリー」「テクニック」のフレームワークに沿って考えると、以下が挙げられるでしょう：
- ゴールがない or 間違っている
- ストーリーがない or 間違っている
- テクニックが不足していてストーリーをうまく表現できない
原因や対策としてテクニックに着目しがちですが、ゴールとストーリーがしっかりしていればテクニック面は調べれば出てくると思うので、うまくいかない場合は（特に若手の場合は）大抵 1. か 2. が原因だと思います。
原因をさらに深掘りすると：
- ゴールとストーリーが必要なことを知らない
- ゴールやストーリーを設定するだけの知識や経験がない
- お客様からのヒアリングが浅い
- チーム内の状況を把握していない
- 見通しを立てるだけの技術力またはビジネス知識がない
- 設定しているはずの人から聞いていない
- ゴールを設定できるだけのポジションに置かれていない
こんな感じでしょうか。
そうなると、対策は原因から自明な気がします。
- ゴールとストーリーにアタリをつけてから資料や文章を書き始める
- もっと深くお客様やチーム内から情報収集する
- 若手の場合はゴールとストーリーについて作業指示者と認識の擦り合わせをする
とかですね。
以上です 
最後に宣伝！
技術ブログやってます
技術系の記事は主にブログ HyperText Candy に書いています。
最近は React 入門記事を執筆中です 
フロントエンドエンジニア募集してます
私のチームでは、これからSPA開発などを学びたいフロントエンドエンジニアさんを募集してます。
詳しくはこちらの記事をご覧ください 
https://www.hypertextcandy.com/ari-job-offer-2020