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

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

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

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

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

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

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

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

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

見積書の例：

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

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

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

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

重さを伝える例：

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

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

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

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

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

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

UMLの例：

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

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

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

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