書く力 v.s. 読む力

ビジネス文書や技術文書というと
書く方に注意が行きがちです。
また、近年の他責NGの流れからか、
書き手と読み手とでは、
書き手の方が批判されがちです。

コミュニケーション能力向上の観点からは
片手落ちではないでしょうか？

1.使用頻度 ⇒ 書く力 ＜ 読む力

平均的なITエンジニアにとっては
何かものを書くより読む方が、
時間が長く、量も多いのではないでしょうか。

新聞、雑誌、書籍、ブログ、メルマガ、Twitter
メール、議事録、仕様書、設計書、ソースコード、
試験仕様書、障害報告、ユーザーマニュアル、etc.

本当にたくさんのものを読んでいますね。


2.責任 ⇒ 50:50

コミュニケーションにおいては、
発信者と受信者は対等です。
結果責任も、対等に50%ずつです。

仕様書に記述がおかしいと思えば、
そのまま作らずに確認するのが普通でしょう。


3.読む力は書く力の基礎

読めないものは書けません。
読む力が上がれば、書く力も上がります。

ビジネス書の内容をざっくりと知りたいときは、
次のような読み方をします。
・目次を眺めて章のタイトルから内容と構成を知る
・前書をざっと読んで、著者の意図や目的を知る
・全体をパラパラめくりながら気になった箇所をちょっと読む
これがやり辛い本は、構成が悪いです。

これは、ソースコードを読むときも同じです。
ということは、書くときも同じですよね。　
この読み方を知っていれば、
・関数(メソッド)の呼び出しを、本の目次の様にする
・クラスのヘッダコメントに、意図や目的（責務）を書く
ように意識が働き易くなります。

また長大で複雑な大河物語を熟読するときは
登場人物の相関図を書いたり、
出来事を時系列で整理したりします。
巨大なソースコードを読むときに
分かりやすいクラス図やシーケンス図などがあると
よく理解できるのと一緒ですね。