何をお探しですか?

コミュニケーション指針/規則

現在のページ:
目次

本記事の内容

自身が主導的役割を担う時に利用してきたコミュニケーション指針です。この指針を共有、準拠することで、何も指針がないチームと比べるとコミュニケーションコストやストレスが劇的に減ることが期待できます。

心構え・考えかた

効率的かつ正確なコミュニケーションを実現するには、テクニック以前に心構えや考え方も重要です。

うまく伝わらない場合は、発信側が悪い

伝えたい事が伝わらない場合に、その原因を受け手側のスキル不足・知識不足と考えずに、自分のコミュニケーション能力不足であると考えてください。

伝えたい内容が専門知識を必要とする場合は?
現実的には、伝えたい内容が専門的すぎて、専門外の人に平易に伝えるのが困難(=膨大な前提の説明が必要になる)な場合は多々あります。この場合、以下のように対処します。

  • 「例えば、○○でいうとxxです。」というように比喩を使って簡潔にあらわす。
  • 「専門的な内容になるので詳細は控えますが、要約するとXXXです」と書く。詳細は省略。専門用語も使って良い。

美しい文章 でなく 伝わる文章を書く

情報システム開発プロジェクトにおいては、詩や小説のように美しい文章や読み手をドキドキ・ワクワクさせるような文章は不要です。芸術や文学では読み手に解釈や想像の余地を残したほうがよいのですが、その技法や文体は「伝わる文章」にとっては有害です。ご注意ください。

例えば推理小説で、犯人は誰か?を最初に書いたら面白くありませんが、ビジネスでは先に書きます。

後述する指針を参考にして「(より正確かつ迅速に)伝わる」文章を書いて下さい。

宗教論争しない

賛否両論ある解、ベターな解が複数ある場合(*)に必要となる考え方・姿勢です。

この場合の正しい姿勢は「どちらでも良い。重要なのは一貫性」です。

プロジェクトとしての採用案が決定された後は、それ以上の議論や論評は控えて決定に従って下さい。

(*)例えば、インデントはタブかスペースか?インデントの数は?テーブル名は複数形・単数形?

1日の10%はコミュニケーションに

良いマネージャ・リーダは「プログラマに介入(質問含む)しすぎてモチベーションや生産性を落としてはいけない」と考えています。
したがって常に「知りたい事」より「知っていることが少ない」状況にいます。
プログラマは、1日の10%をコーディングでなくコミュニケーション(=わかりやすい報告~状況・課題・見通し~や質問を書く)に使って下さい。
プログラマがコミュニケーションに投資した時間は効率的な役割分担・スケジューリングとしてプロジェクト全体の利益となります。

プログラマ自身にとっても利益になります。マネージャに「安心」を与えることで「信用」を得ることができるからです。
優先的に成長の機会を与えられるでしょう。

書き方

考え方を理解した上で書き方です。

結論が先

結論を先に書いてください。

情報システム開発プロジェクトでは、推理小説のような文体は必要ありません!

※文書に限らず口頭での報告の際も同様です。

読み手をびっくりさせない(いきなり謎の用語・略語を使わない)

一般的でない(もしくは複数の答えがある)用語、略称・略語を使う場合は、必ず注釈で説明します。

クローズド・クエスチョンの活用 推奨

質問する際には、可能な限り、クローズド・クエスチョンを使用して回答する側の負担を減らしてください。
以下に例を示します。

悪い例 オープンな質問)

XXについては、どうしますか?

良い例)

XXについては、類似システムではXXXXになっています。そこで、XXXXのようにすすめようと思っていますがよいでしょうか?

「良い例」の場合は、YESもしくはNoで答えることができますし、Noの場合も論点や抜け漏れしている考慮事項が明確なので回答が容易です。

もちろんオープンな質問が必要な場面もあります。例えば発想に制約をもうけずより多くのアイデアを引き出したい場合です。

個人的には「最近どう?」という手抜きな質問は大嫌いです。笑

一文を短く

文書をできる限り短くして下さい。接続詞で、文章を続けないでください。

箇条書きの活用

箇条書きを多用して下さい。これにより文章も簡潔にできます。
以下に例を示します。

悪い例)

タスク1とタスク2とタスク3の対応をお願いします。

良い例)

以下の対応をお願いします。
- タスク1 
- タスク2
- タスク3

「悪い例」ではタスク名称が短いのでそれほど気になりませんが、ここが長い場合は読んで理解するのに時間を要します。チェックリストを作成する時も手間がかかります。

句読点(。、)の多用

句読点を正確に利用することにこだわる必要はありません。
文や単語の区切りが明確になるため外国人が読む時に句読点があったほうが読解が容易です。

注釈の活用

細かい内容は注釈に本文から分離することで、伝わりやすい文章になることがあります。

分離していない例)

プラットフォームにはAWS(Amazon Web Servicesの略。世界で最も利用されているIaaS型プラットフォーム。)を利用します。

分離した例)

プラットフォームにはAWS(*)を利用します。

(*)Amazon Web Servicesの略。世界で最も利用されているIaaS型プラットフォーム。

改行の活用

適宜、改行してください。

一般的に縦スクロールは容易で横にスクロールするのは大変です。

縦に長くなるほうが好ましいです。

目次・見出し・段落の活用

長文になる場合は、適宜、段落と見出しを付与してください。
長い(=ひと目で見れない)場合は、目次を付与しましょう。

以下について報告します。

・AAAについて
・BBBについて
・CCCについて

■AAAについて
 結論
 背景・概要
 詳細

■BBBについて
 結論
 背景・概要
 詳細

■CCCについて
 結論
 背景・概要
 詳細

定型文の活用

挨拶や締めの定型文はIME辞書に登録して、入力時間を短縮して下さい。

※時々、挨拶がない方がいらっしゃいますが、いきなり用件に入ると不快に感じる人は少なくありません。
原則として挨拶は省略しないで下さい。(チャットであればその日の最初に挨拶するくらいで良いでしょう)

一意の識別子を設定する

見出しや表に連番などの一意の識別を設定しておくと、コミュニケーションが円滑になります。(特にレビューの場合に重要)

「xxxxxxxについて」というより「項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回  ステークホルダー・マネジメント

ステークホルダーの整理

クライアント側

役割名前所属メールアドレス電話番号SKYPESlack備考
プロジェクトオーナxxx会社Ataro@example.co.jp03-xxxxx-xxxxxxxxxx
プロジェクトリーダxxx会社Ahanako@example.co.jp03-xxxxx-xxxxxxxxxx
プログラマxxx会社Apg@example.co.jp03-xxxxx-xxxxxxxxxx
契約・事務xxx会社Ajimu@example.co.jp03-xxxxx-xxxxxxxxxx

ベンダ側

役割名前所属メールアドレス電話番号SKYPESlack備考
プロジェクトリーダxxx会社Bhanako@sample.co.jp03-xxxxx-xxxxxxxxxx
プログラマxxx会社Bpg1@sample.co.jp03-xxxxx-xxxxxxxxxx
プログラマxxxフリーランスpg2@sample.co.jp03-xxxxx-xxxxxxxxxx
営業xxx会社Bjimu@sample.co.jp03-xxxxx-xxxxxxxxxx

コミュニケーション設計・タスク登録

それぞれのステークホルダーとのコミュニケーション方法を決定します。具体的には以下のような内容を検討します。
決定した内容はカレンダーアプリ(例.Googleカレンダー)に登録して、適宜リマインドされるようにします。

  • 対象 誰とのコミュニケーションか?
  • 内容 どういう内容を報告するか? 進捗はざっくりか?詳細か?予算や体制に関することか?
  • 形式 対面か?(リアルか?リモートか?)、口頭か?メールか?
  • 書式 PowerPointか?Excelか?印刷物か?
  • 頻度 毎日業務終了後?週1回?月1回?
PAGE TOP
MENU