本記事の内容
自身が主導的役割を担う時に利用してきたコミュニケーション指針です。
この指針を共有、準拠することで、何も指針がないチームと比べるとコミュニケーションコストやストレスが劇的に減ることが期待できます。
ありがたいことに私はクライアントから「コミュニケーション能力が高い」と評価されることが多いですが、これは天性や性格ではなく、後述した指針を守ることを心がけているのが理由です。
賛否ある内容も含まれるかもしれませんが参考にして頂ければ幸いです。
推薦図書
キャリアの最初期（１５年以上前）にこの本に出会えたのは幸運でした。
購入額の1000倍以上のリターンがあったと思います。
例題（悪い書き方、良い書き方）とその理由という形式で要点が簡潔にまとめられています。
また技術以前の心構えについても納得のいく主張でした。
以下のような主張や話も非常に興味深いものでした。
- 日本では、コミュニケーションがうまく成り立たない場合は、受け手側に責任があると判断する傾向が強い。
- 日本では、以心伝心や行間を読むという特殊なスキルが発達していてかつ期待される（のでライティングが重視されてない）
- 欧米にはライティングの学位があるが日本にはない
当時はこの手の書籍はほとんどありませんでしたが、今、Amazonを「書く技術」「伝える技術」で検索したら大量に出てきて驚きました。
海外勤務や外国人と仕事することも増えて意識があがってきたんですかね。よい傾向だと思います。
以降、本題です。
Ｅメール規約・指針
コミュンケーションの主体となる「Ｅメール」の規約・指針です。
メーリングリストの活用
メーリングリストを利用します。情報共有の促進、宛先入力の省力化による生産性向上が目的です。
タスク管理ツール（例えばRedmineやBacklog）であれば「関係者全員に送信」を選択します。
xxxxxx@googlegroups.com
メール件名
プロジェクトの推進に決定権を持つ人は毎日大量のメールに埋もれています。
優先的に処理してもらうにはコツがあります。まずは件名が重要です。
プリフィックス（プロジェクト名） 必須
件名の先頭にプリフィックス[< プロジェクト略称・短縮名 >]を付与して下さい。（件名を利用したフィルタ設定で利用するため）
※メーリングリストへ送信する場合は自動的に付与されますので入力不要です。
プリフィックス（用件） 推奨
[質問]、[相談]、[連絡]、[報告]といったメールの性格や読み手に期待するアクションを暗示するプリフィックスを付与します。
これにより読み手側は「本文を読まなくてもいつ読めばよいかを判断」できます。
プリフィックス（名前） オプション
質問する場合、回答を得たい人の名前を件名に含めると効果的です。
例）[質問][急ぎ]山田様:xxxxxxについて
プリフィックス（重要度・緊急度） オプション
急ぐ場合や重要な場合は[重要][緊急][急いでます！]などを付与しても良い。
メール件名と内容の一致 必須
（後から検索しやすくするために）メール件名と内容を一致させて下さい。
よくある悪い例として「返信のついでに件名と無関係の話題や質問をする人」がいますが避けてください。
一メール一内容 強く必須
（後から検索しやすくするために）原則として、１つのメールには１つの用件としてください。
関連度が高い内容であれば複数の内容を記載することは可能です。
文章規約・指針
考えかた
効率的かつ正確なコミュニケーションを実現するには、テクニック以前の考え方も重要です。
うまく伝わらない場合は、発信側が悪い。
伝えたい事が伝わらない場合に、その原因を受け手側のスキル不足・知識不足と考えずに、自分のコミュニケーション能力不足であると考えてください。
伝えたい内容が専門知識を必要とする場合は？
現実的には、伝えたい内容が専門的すぎて、専門外の人に平易に伝えるのが困難（＝膨大な前提の説明が必要になる）な場合は多々あります。この場合、以下のように対処します。
- 「例えば、○○でいうとxxです。」というように比喩を使って簡潔にあらわす。
- 「専門的な内容になるので詳細は控えますが、要約するとXXXです」と書く。詳細は省略。専門用語も使って良い。
美しい文章 でなく 伝わる文章を書く
情報システム開発プロジェクトにおいては、詩や小説のように美しい文章や読み手をドキドキ・ワクワクさせるような文章は不要です。芸術や文学では読み手に解釈や想像の余地を残したほうがよいのですが、その技法や文体は「伝わる文章」にとっては有害です。ご注意ください。
例えば推理小説で、犯人は誰か？を最初に書いたら面白くありませんが、ビジネスでは先に書きます。
後述する指針を参考にして「（より正確かつ迅速に）伝わる」文章を書いて下さい。
宗教論争しない
賛否両論ある解、ベターな解が複数ある場合(*)に必要となる考え方・姿勢です。
この場合の正しい姿勢は「どちらでも良い。重要なのは一貫性」です。
プロジェクトとしての採用案が決定された後は、それ以上の議論や論評は控えて決定に従って下さい。
(*)例えば、インデントはタブかスペースか？インデントの数は？テーブル名は複数形・単数形？
１日の１０％はコミュニケーションに
良いマネージャ・リーダは「プログラマに介入（質問含む）しすぎてモチベーションや生産性を落としてはいけない」と考えています。
したがって常に「知りたい事」より「知っていることが少ない」状況にいます。
プログラマは、１日の１０％をコーディングでなくコミュニケーション（=わかりやすい報告～状況・課題・見通し～や質問を書く）に使って下さい。
プログラマがコミュニケーションに投資した時間は効率的な役割分担・スケジューリングとしてプロジェクト全体の利益となります。
プログラマ自身にとっても利益になります。マネージャに「安心」を与えることで「信用」を得ることができるからです。
優先的に成長の機会を与えられるでしょう。
書き方
考え方を理解した上で書き方です。
結論を先に
結論を先に書いてください。
情報システム開発プロジェクトでは、推理小説のような文体は必要ありません！
※文書に限らず口頭での報告の際も同様です。
読み手をびっくりさせない（いきなり謎の用語・略語を使わない）
一般的でない（もしくは複数の答えがある）用語、略称・略語を使う場合は、必ず注釈で説明します。
クローズド・クエスチョンの活用 推奨
質問する際には、可能な限り、クローズド・クエスチョンを使用して回答する側の負担を減らしてください。
以下に例を示します。
悪い例 オープンな質問）
XXについては、どうしますか？
良い例）
XXについては、類似システムではXXXXになっています。そこで、XXXXのようにすすめようと思っていますがよいでしょうか？
「良い例」の場合は、YESもしくはNoで答えることができますし、Noの場合も論点や抜け漏れしている考慮事項が明確なので回答が容易です。
もちろんオープンな質問が必要な場面もあります。例えば発想に制約をもうけずより多くのアイデアを引き出したい場合です。
個人的には「最近どう？」という手抜きな質問は大嫌いです。笑
一文を短く
文書をできる限り短くして下さい。接続詞で、文章を続けないでください。
箇条書きの活用
箇条書きを多用して下さい。これにより文章も簡潔にできます。
以下に例を示します。
悪い例）
タスク１とタスク２とタスク３の対応をお願いします。
良い例）
以下の対応をお願いします。
- タスク１
- タスク２
- タスク３
「悪い例」ではタスク名称が短いのでそれほど気になりませんが、ここが長い場合は読んで理解するのに時間を要します。チェックリストを作成する時も手間がかかります。
句読点（。、）の多用
句読点を正確に利用することにこだわる必要はありません。
文や単語の区切りが明確になるため外国人が読む時に句読点があったほうが読解が容易です。
注釈の活用
細かい内容は注釈に本文から分離することで、伝わりやすい文章になることがあります。
分離していない例）
プラットフォームにはAWS（Amazon Web Servicesの略。世界で最も利用されているIaaS型プラットフォーム。）を利用します。
分離した例）
プラットフォームにはAWS（＊）を利用します。
（*）Amazon Web Servicesの略。世界で最も利用されているIaaS型プラットフォーム。
改行の活用
適宜、改行してください。
一般的に縦スクロールは容易で横にスクロールするのは大変です。
縦に長くなるほうが好ましいです。
目次・見出し・段落の活用
長文になる場合は、適宜、段落と見出しを付与してください。
長い（＝ひと目で見れない）場合は、目次を付与しましょう。
以下について報告します。
・AAAについて
・BBBについて
・CCCについて
■AAAについて
結論
背景・概要
詳細
■BBBについて
結論
背景・概要
詳細
■CCCについて
結論
背景・概要
詳細
定型文の活用
挨拶や締めの定型文はIME辞書に登録して、入力時間を短縮して下さい。
※時々、挨拶がない方がいらっしゃいますが、いきなり用件に入ると不快に感じる人は少なくありません。
原則として挨拶は省略しないで下さい。（チャットであればその日の最初に挨拶するくらいで良いでしょう）
一意の識別子を設定する
見出しや表に連番などの一意の識別を設定しておくと、コミュニケーションが円滑になります。（特にレビューの場合に重要）
「ｘｘｘｘｘｘｘについて」というより「項1.1.1について」というほうが速いです。
※本書の指針にそもそも連番がふってない理由
Wordだと自動で設定できるが、GoogleDocsやMarkdownではできない。
手入力で連番設定するのは時間の無駄なので、省略してます。
画像の活用
百聞一見に如かずです。画像を添付することで正確で効率的なコミュニケーションが可能になります。
なお画像の共有はそれなりに手間がかかりますので、ツールの活用が必須となります。
以下で有用なツールを紹介します。
- gyazo
- google photos
gyazo 強く推奨
デスクトップやブラウザのスクリーンショットを非常に簡単に取得・共有できるツール。
Windows標準機能で行う場合は以下のように多くの手間と時間を要しますが、Gyazoを利用するとこれらが非常に簡単にできます。
[非推奨]Windows標準機能でスクリーンショットを取って添付する手順
- Ctrl + Alt + PrintScreen ボタン押下
- ペイントソフト起動
- ペイントソフトに貼り付ける
- 適宜加工する。（トリミングする、枠線で囲む、テキスト追加）
- 保存する
- メールに添付する（もしくはシステムに登録する）
※画像の加工はPro版（月額300円）でのみ可能
詳しくは以下のような記事を参照してください。
Gyazoとは？撮った画像をその場で相手と共有できるツールの使い方を解説
Google Photos
スマホで撮影した写真を自動的にネット上にアップロードして共有できる無償サービスです。
パソコン外の画像を共有する際に利用
ステークホルダーマネジメント
まずはプロジェクト関係者を明確にします。これを元にコミュニケーションの内容・方法・頻度等を設計します。
詳しくはPMBOKを参照すると良いかと思います。
PMBOK®ガイド 第5版紹介シリーズ 第3回 ステークホルダー・マネジメント
ステークホルダーの整理
クライアント側
| 役割 | 名前 | 所属 | メールアドレス | 電話番号 | SKYPE | Slack | 備考 |
|---|---|---|---|---|---|---|---|
| プロジェクトオーナ | xxx | 会社A | taro@example.co.jp | 03-xxxxx-xxxxx | xxxxx | ||
| プロジェクトリーダ | xxx | 会社A | hanako@example.co.jp | 03-xxxxx-xxxxx | xxxxx | ||
| プログラマ | xxx | 会社A | pg@example.co.jp | 03-xxxxx-xxxxx | xxxxx | ||
| 契約・事務 | xxx | 会社A | jimu@example.co.jp | 03-xxxxx-xxxxx | xxxxx |
ベンダ側
| 役割 | 名前 | 所属 | メールアドレス | 電話番号 | SKYPE | Slack | 備考 |
|---|---|---|---|---|---|---|---|
| プロジェクトリーダ | xxx | 会社B | hanako@sample.co.jp | 03-xxxxx-xxxxx | xxxxx | ||
| プログラマ | xxx | 会社B | pg1@sample.co.jp | 03-xxxxx-xxxxx | xxxxx | ||
| プログラマ | xxx | フリーランス | pg2@sample.co.jp | 03-xxxxx-xxxxx | xxxxx | ||
| 営業 | xxx | 会社B | jimu@sample.co.jp | 03-xxxxx-xxxxx | xxxxx |
コミュニケーション設計・タスク登録
それぞれのステークホルダーとのコミュニケーション方法を決定します。具体的には以下のような内容を検討します。
決定した内容はカレンダーアプリ（例.Googleカレンダー）に登録して、適宜リマインドされるようにします。
- 対象 誰とのコミュニケーションか？
- 内容 どういう内容を報告するか？ 進捗はざっくりか？詳細か？予算や体制に関することか？
- 形式 対面か？（リアルか？リモートか？）、口頭か？メールか？
- 書式 PowerPointか？Excelか？印刷物か？
- 頻度 毎日業務終了後？週１回？月１回？