文章力がイマイチなエンジニア

文字ばかりの設計書
とあるプロジェクトの要件定義書をレビューしていて驚かされた。そのボリュームと文字の多さに。ワタシの感覚ではそこまでならないだろう？と予想していたから、まず、量で驚かされた。そして、文字の多さ。書かないといけないことは勿論書いてもらわないといけないけれど、「それを本編に書くんだ...。」というのもあってね。

もちろん、設計書なので文章を書くことは当たり前だか、いろいろ想像を超えていたから。ううん。スゴかった。

「随分量が多いね？」
「後で思い出せるように全部書いておきたいから。」
「でも、例えばこれは後ろか別紙でいいんじゃない？」
「いやこれで！」
「(間違いじゃないからなぁ。)」

“後で思い出せるように”とか、普段開発するエンジニアが忘れた振りをしていることを、“運用後も考えて”いるから殊勝な心がけだなぁ、と思う。

でもね、それね、よくよく見ると、文字情報より図や表形式で整理したほうが読み手にとって理解しやすいし、あとあと経緯を紐解くにしたって、見安いのではないかな？と思ったわけです。

もちろん、まったく図や表がないわけではないけど何より文章が長い。ワタシの個人的な見解は、

“文章は、2行を超えたら分割しなさい”

です。長い文章は間違いを起こす。なぜなら、

“多量な情報量を理解して書いている書き手と同じレベルを読み手に要求するのだから。”

暗黙に高いレベルを要求するこということは、読み手に“誤謬”を引き起こすのだ。

空中戦とホワイトボード
とある勉強会で、やっぱり上流工程の話になって、システムエンジニアが顧客と話すとき、“もっと図を多用して理解の差をなくすことに努めたほうが良い”という流れになった。

要領を得ないエンジニアの説明は、資料が手元に配られていたとしても空中戦を始めてしまう。例え、会議室にホワイトボードがあったとしても、不思議とマーカーを持つことをしないんだよね。
＃当事者たちが気付くか、こちらが痺れを切らすか不思議な戦いが始まる...。

言葉は話し手と聞き手と違った理解で遣り取りされるものだ。それを知ってか知らずか。

ふと、過去に自分がプロジェクトマネージャをしていたときのプロジェクトの要件定義のセッション資料を開いてみたら、目分量でザックリこんな比率だった。

図　　40%
表　　30%
文字　30%

このプロジェクトは、コミュニケーションが顧客とSIerの間で良く取れてた印象が残ってる。定例会でお互い、冗談と厳しい遣り取りを混ぜながら進められたような思い出。

勉強会でもやっぱり、文字だけでセッションを維持するのは無理だというのが大勢で、システムを良く知っている立場のSIerが夫々の案のメリット/デメリットを並べ判断しやすいように場を作るために、図と表を駆使するのが必要なスキルなのではないか、と。

文章力は文章が書ければよいのではない
顧客と意思疎通して、deliverableを届けるために文書を作る。文書は、文字だけではなくて、文字で表現した方が良いものもあれば、図にしたほうが理解できるものもあるし、表にしてMECEにした方が良いなど適材適所でなことが明らか。

文章を書くに当たって、文字ばかりで表現するエンジニアは、表現の選択肢は幾つもあるのにどこでどの表現方法を使ったら良いか思いを巡らせられないのだろうか。
＃判別がつかないのだろうか、それとも別な理由があるのかなぁ。

言葉だけで説明しようとしたり、文字ばかりで書こうとするならば、それは文書を表現するときに適切な手段を選択する思考する力を上げないと難しいのかもしれない。