コミュニケーション指針
1. 概要#
コミュニケーションの指針です｡
本指針を関係者が共有･準拠することで、何も指針がないチームと比べるとコミュニケーションコストやストレスが劇的に減ることを保証します｡
大きく以下の構成で記載しています｡
- 心構え･考え方
- テクニック
- 推奨ツール
2. 心構え・考えかた#
正確かつ効率的なコミュニケーションを実現するには、テクニック以前に心構えや考え方が重要です。
2.1. うまく伝わらない場合は、発信側が悪い。#
伝えたい事が伝わらない場合に、その原因を受け手側のスキル不足・知識不足･能力不足と考えずに、発信側（自分）のコミュニケーション能力不足であると考えてください。
伝えたい内容が専門知識を必要とする場合は？
現実的には、伝えたい内容が専門的すぎて、専門外の人に平易に伝えるのが困難（＝膨大な前提の説明が必要になる）な場合は多々あります。この場合、以下のように対処します。
- 「例えば、○○でいうとxxです。」というように比喩を使って簡潔にあらわす。
- 「専門的な内容になるので詳細は控えますが、要約するとXXXです」と書く。詳細は省略。専門用語も使って良い。
2.2. ｢美しい文章｣でなく｢伝わる文章｣を書く#
情報システム開発プロジェクトにおいては、詩や小説のように美しい文章や読み手をドキドキ・ワクワクさせるような文章は不要（有害）です。
大切なことなので繰り返します｡
読み手をドキドキ・ワクワクさせるような文章は｢不要（有害）｣です。
芸術や文学では読み手に解釈や想像の余地を残したほうがよいのですが、その技法や文体は「伝わる文章」にとっては｢有害｣です。ご注意ください。
例えば推理小説で、結論（犯人は誰か？どういう手口か?）を最初に書いたら面白くありませんが、ビジネスでは先に書きます。
後述する指針を参考にして「（より正確かつ効率的に）伝わる」文章を書いて下さい。
2.3. 宗教論争しない#
賛否両論ある解、ベターな解が複数ある場合(*)に必要となる考え方・姿勢です。この場合の正しい姿勢は「どちらでも良い。重要なのは一貫性」です。 プロジェクトとしての採用案が決定された後は、それ以上の議論や論評は控えて決定に従って下さい。
絶対的な正解がない（=どちらでも構わない）例
- インデントは､タブかスペースか？
- インデントの数は､2か4?
- テーブル名は､複数形か単数形か？
2.4. プログラマは､１日の１０％をマネージャ･リーダとのコミュニケーションに費やす#
良いマネージャ・リーダは「プログラマに介入（質問含む）しすぎてモチベーションや生産性を落としてはいけない」と考えています。したがって常に「知りたい事」より「知っていることが少ない」状況にあります｡
プログラマは、１日の１０％をコーディングでなくコミュニケーション（=わかりやすい報告～状況・課題・見通し～や質問を書く）に使って下さい。
プログラマがコミュニケーションに投資した時間は効率的な役割分担・スケジューリングとしてプロジェクト全体の利益となります。
プログラマ自身にとっても利益になります。マネージャに「安心」を与えることで「信用」を得ることができるからです。 優先的に成長の機会を与えられるでしょう。
3. テクニック/書き方#
上述した､心構え･考え方を理解した上でいよいよ具体的なテクニックです｡
3.1. 結論が先#
結論を先に書いてください。
情報システム開発プロジェクトでは、推理小説のような文体は必要ありません！
※文書に限らず口頭での報告の際も同様です。
3.2. 読み手をびっくりさせない#
一般的でない（もしくは複数の意味がある）用語、略称・略語を使う場合は、注釈で説明します。
3.3. クローズド・クエスチョンの活用#
質問する際には、可能な限り、クローズド・クエスチョンを使用して回答する側の負担を減らしてください。 (個人的には「最近どう？」という質問が大嫌いです）
以下に例を示します。
悪い例/オープンな質問
XXについては、どうしますか？
良い例
XXについては、類似システムではXXXXになっています。そこで、XXXXのようにすすめようと思っていますがよいでしょうか
Note
「良い例」の場合は、YESもしくはNoで答えることができますし、Noの場合も論点や抜け漏れしている考慮事項が明確なので回答が容易です。
オープン質問が有用な場合は?
オープンな質問が必要な場面もあります。 例えば発想に制約をもうけずより多くのアイデアを引き出したい場合です。
3.4. 一文を短く/接続詞を使わない#
文書をできる限り短くして下さい。 方法は簡単です｡接続詞を使わないことです｡
3.5. 箇条書きの活用#
箇条書きを多用して下さい。これにより文章も簡潔にできます。 以下に例を示します。
悪い例
タスク１とタスク２とタスク３の対応をお願いします。
良い例
以下の対応をお願いします。
- タスク１
- タスク２
- タスク３
「悪い例」ではタスク名称が短いのでそれほど気になりませんが、ここが長い場合は読んで理解するのに時間を要します。 チェックリストを作成する時も手間がかかります。
3.6. 句読点（。、）の多用#
句読点を正確に利用することにこだわる必要はありません。 文や単語の区切りが明確になるため外国人が読む時に句読点があったほうが読解が容易です。
3.7. 注釈の活用#
細かい内容は注釈に本文から分離することで、伝わりやすい文章になることがあります。
悪い例
プラットフォームにはAWS（Amazon Web Servicesの略。世界で最も利用されているIaaS型プラットフォーム。）を利用します。
良い例
プラットフォームにはAWS（＊）を利用します。
（*）Amazon Web Servicesの略。世界で最も利用されているIaaS型プラットフォーム。
3.8. 改行の活用#
適宜、改行してください。
一般的に縦スクロールは容易で横にスクロールするのは大変です。
縦に長くなるほうが好ましいです。
3.9. 目次・見出し・段落の活用#
長文になる場合は、適宜、段落と見出しを付与してください。 長い（＝ひと目で見れない）場合は、目次を付与しましょう。
以下について報告します。
・AAAについて
・BBBについて
・CCCについて
■AAAについて
結論
背景・概要
詳細
■BBBについて
結論
背景・概要
詳細
■CCCについて
結論
背景・概要
詳細
3.10. 定型文の活用#
挨拶や締めの定型文はIME辞書に登録して、入力時間を短縮して下さい。
挨拶文の要否について
ビジネスのやりとりで｢挨拶文は不要｣という考え方もあると思いますが､筆者は必要と考えてます｡ いきなり用件に入ると不快に感じる人が少なくないからです｡特にご年配｡ ですので原則として挨拶は省略しないで下さい。（チャットであればその日の最初に挨拶するくらいで良いでしょう）
3.11. 一意の識別子を設定する#
見出しや表に連番などの一意の識別を設定しておくと、コミュニケーションが円滑になります。（特にレビューの場合に重要）
「ｘｘｘｘｘｘｘについて」というより「項1.1.1について」というほうが速いです。
3.12. 画像の活用#
百聞一見に如かずです。画像を添付することで正確かつ効率的なコミュニケーションが可能になります。
なお画像の共有はそれなりに手間がかかりますので、ツールの活用が必須となります。 以下で有用なツールを紹介します。
4. 推奨ツール#
4.1. gyazo#
デスクトップやブラウザのスクリーンショットを非常に簡単に取得してWEB共有できるツールです｡ 正確かつ効率的なコミュニケーションを実現するために欠かせないツールです｡
有料版では､テキスト､矢印､枠線を追加したり､モザイク処理を施したり､動画が取得共有することが出来ます｡
