システムエンジニアのドキュメントを作成するスキルを上げるには

エグゼクティブや他のマネージャと雑談をしているとワタシの専門領域がプロジェクトマネジメントであるから故に、プロジェクトマネージャやその候補のエンジニアのコンピテンシの話題になることがままあって、それも続けば食傷気味になりつつも、こうスパッとした解決策がないことに手を拱いている感覚をずっと引きずっているような気分になって仕方がない。

エンジニアのスキルは二つ
エンジニアに必要なスキルは二つあるのです。一つは会話、振る舞いや社会性などの社会人として求められる基礎スキルがありますね。もう一つは、技術などの専門性の領域で、技術領域の知識とそれを実践する技術スキルです。

このどちらのスキルもその人の一番ベーシックなスキルの上に載っているもので、そのベーシックなスキルが“読み書き”なのだと思うのです。

書くことは理解を自分の言葉に変えること
読むことは、対象となる書籍や人との会話というコンテキストを相手の言葉を自分が理解している言葉で解釈することです。書籍や相手の話す語彙がわからなければ先方の意図は正しく解釈することはできませんが、コンテキストから補完してしまえることもあるので“分かったつもり”になりやすいという罠があるなぁと思うのです。

そして、その解釈したことが先方の意図とあっているかどうかは、受け手であり解釈した側の言葉でどのように表現するかにかかっています。それは、解釈した言葉を自分の持つ語彙を使って“抽象化”するプロセスでありそのプロセスの質の高さが会話のコンテキストやドキュメントの文章として具現化するのだと思うのです。

システムエンジニアが質の高いドキュメントを書きたいとか書かせたいというとき、勿論、システムエンジニアであるが故に技術領域の知識はそのシステムエンジニアのロールレベルに準じて必要となりますが、いくら技術知識が形式知としてそのシステムエンジニアに詰め込まれていても、具現化するプロセスの質が見劣ればそこで表見されたレベルでしか評価されません。

そうすると、システムエンジニアの「ドキュメントを作成するスキルを上げたい。」とか、そうした期待に対する策は“表そうとする文章の解釈する力とそれを表現する力を訓練するほかない”と思うのです。それは、そのシステムエンジニアが自分で解釈して理解した語彙で表現するプロセスであるために、そのプロセスを何度も何度も繰り返し使い、鍛え、改善することをしなければ全く変わらないでしょう。

それは結局、そのシステムエンジニア自身が自分の頭と手を使って書かないと“質は変わりようがない”ということなのです。

エンジニアのみなさん、日記をブログに書きましょう。