連載
開発をもっと楽にするNAgileの基本思想

第2回 伝わるコミュニケーションとは

小島 富治雄
2006/05/17
Page1 Page2 Page3 Page4

■■ブロードバンド・コミュニケーション■■

そこで、次に「情報の帯域」ということを考えてみたい。ここで帯域というのは時間当たりの情報量のことだとする。

帯域 = 伝わる情報量 ÷ 伝わるのに要した時間

というわけだ。

 例えば、以下のプロジェクトの進ちょくを伝える2つの方法を比べてみてほしい。

A) 「めったに見に行かない共有フォルダに進ちょくを書いたExcelシートが置いてある。そのExcelシートは適宜更新される」

B) 「進ちょくをグラフィカルに表現した図が壁に貼ってある。図はリアルタイムに更新される」

 進ちょく自体の情報量は同じだとしても、下の方が伝わる情報量はずっと多く、伝わるのに掛かる時間も短い。すなわち、下の方が帯域が広い、つまりブロードバンドなコミュニケーションということになる。

   
なるほど。
   

では以下で、顧客の要望に関するコミュニケーションの5通りの例を、仕様書に頼ったコミュニケーションの例から順番に見ていこう。

顧客の要望に関するコミュニケーションの5とおりの例:

A) 「何を作るべきか、こと細かに書いたドキュメントが、印刷され棚にきちんと収納されている。どのようなソフトウェアが出来上がるのか知りたければ、いつでも誰でもそれを閲覧することができる」

B) 「仕様に関するドキュメントは関係者にメールする、というルールになっている」

C) 「仕様書に関して、関係者を集めて、PowerPointやホワイトボードを使ってプレゼンテーションを行っている」

D) 「関係者を集めて、実際に少し動くものを使って実演を行った」

E) 「関係者を集めて、実際に少し動くものを触ってもらい、体験してもらった」

   

A)〜E)は、下に行くほど情報の帯域が広い。つまり、下のコミュニケーションほどブロードバンド(=広帯域)だ。以下のような関係といえよう。

   

一般的に以下のようなことがいえるだろう。

   

後ろに行くほど、ブロードバンドになる。言葉だけ文書だけの場合と比べて時間当たりにより多くのコミュニケーションが可能だ。

 しかし、ここでいっておく。

多くの情報を提供することが重要なのではない。伝えるべき情報が伝わることが重要なのだ。

 例を挙げよう。

見積書の例:

 以前、とあるプロジェクトでのことだ。

 そのプロジェクトは、いわゆる「仕様書駆動型」だった。私は、要求仕様書を参考に、プログラマーとして見積書を書いてプロジェクト・マネージャに提出した。

 すると、プロジェクト・マネージャは以下のように私に述べた。

 「今回も納期が厳しいんだ。納期を守るため、今回はプロジェクト計画の精度を前回よりも上げたい。だから、見積もりは日単位でなく、時間単位で記入してくれ

   

当然のことだが、こんなことはばかげている。

 日単位の見積もりの精度すらものすごく怪しいのに、時間単位にすることに意味はない。有効数字が1けたしかないデータの記述を2けたに書き換えただけで精度が上がったりしない。情報を冗長にしているだけだ。こんなことでより多くの必要な情報が伝わったりはしない。

 別の例を挙げよう。

重さを伝える例:

 AさんとBさん、それにCさんがMP3プレーヤを買った。3人に「そのMP3プレーヤはどのくらいの重さですか?」と尋ねてみた。すると、AさんとBさんは、それぞれ以下のように答えた。

Aさん:「52.3グラムです」
Bさん:「ニワトリの卵くらいです」

 どちらが、よりブロードバンドなコミュニケーションだろうか? A さんの方がより詳細に述べている。にも関わらず、多分、伝わるべき情報がより多く伝わるのはBさんの方だろう。

 そして、最後にCさんだが、Cさんは次のような行動を取った。

Cさん:(黙って、実際にプレーヤを相手に持たせる)「……(無言)」

 実はこのCさんの伝え方の方が、さらにブロードバンドなのだ。言葉は発していない。だが、相手の欲していた情報をBさんよりもさらに短時間に多く伝えることに成功している。

   

そうか、分かりました! 細かくいえば多く伝わるというものではないんですね。情報を詳細にすればよいというものではないんですよね。

いっておこう。

“There's a difference between telling fully and telling precisely.”
(「つぶさにいうのと、的確にいうのは違う」)

 例えば、ニュアンスを伝えるのが重要な場面では、数字を並べ立てるようなことは適切ではない。前回、

  • 「情報は持っている方に説明責任がある」

  • 「プル型よりプッシュ型のコミュニケーション」

ということを学んだことと思う。

はい! 習いました!
   

相手に伝えるべきことをきちんと伝える。それが「コミュニケーションにコミットする」ということだと知れ。

【まとめ】

■■和のコミュニケーション■■

さらにコミュニケーションの例を挙げてみる。

UMLの例:

 とあるプロジェクトでの話だ。

 そのプロジェクトでは、よその会社のチームと一緒に開発を行うことになった。ある日、その会社からUML(Unified Modeling Language:統一モデリング言語)の文書が大量に送られてきた。ユースケース図やらアクティビティ図やらが大量に印刷され、ファイリングされていた。10cmほどの厚みのものが10冊ばかり。

 しかしそれを受け取った方のチームには、UMLに習熟したメンバーがいなかった。

 しばらくは、UMLの入門書を片手に格闘していたが、やがてそれらは丁寧に棚にしまわれることとなった。多分、随分苦労し時間を掛けて描いたであろうその大量のUML文書は、結局ほとんど開発の役に立ててもらえなかったのだ。

   

UMLを使うこと自体は別に悪くない。

 実は私はUMLは好きだ。特にUML 1.Xはシンプルでよい言語だと思う。UMLを使うな、ということではない。ただ、上の例では、どちらもUMLに不慣れなのにUMLを使ったことに問題がある。読まれないドキュメント(=WOD:Write Only Document)に価値はない。

 ここでいいたいことは次のメタファ(=隠喩、例え)だ。

「日本人が日本人に話し掛けるのに外国語を使うな!」

 慣れない言語でまくし立てるのが、質の高いコミュニケーションではない。何も双方が不慣れなコミュニケーション方法を選ばなくてもよい。

 何度でもいうが、大切なのは「伝わること」だ。

 

 INDEX
  開発をもっと楽にするNAgileの基本思想
  第2回 伝わるコミュニケーションとは
    1.ドキュメントを書くことが重要?
  2.ブロードバンド・コミュニケーション
    3.和のコミュニケーション
    4.創造的コミュニケーション
 
インデックス・ページヘ  「開発をもっと楽にするNAgileの基本思想」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間