文書の指導

ソフトウェアを開発する際には、プログラミングしてコードを書くことに加えて、さまざまな文書を書きます。文書を書く上で、読み手が理解できるか否かを考えることは重要なのですが、自分では理解できるだろうと思っても、実際には理解しにくことがあります。また、作成する文書によっては、書き方のフレームワークがあることがあります。

フレームワークとして企業内における昇格時の昇格レポート（昇格論文）を例として挙げます。昇格レポートのフレームワークに関しては企業の特色が出てきます。たとえば、私が一番長く勤務した富士ゼロックス（および富士ゼロックス情報システム）では、QCストーリ的な組み立てが求められていました。それは、以下のような骨格です。

• 担当業務の説明
• 課題（問題）は何か
• 課題の原因を分析
• 改善策の検討
• 改善策の実施結果と効果
• 残された課題に対する今後の方針

大枠はこのような感じで、課題は2つは書く必要がありました。そして、これらをA4の2ページに論理的にまとめる必要がありました。すべての昇格でこのようなレポートを書くことが求められていました。昇格の種類によっては面接も行われますし、レポートだけで判断される場合もあります。

当然、昇格ごとに、レポートを作成して、上司にチェックしてもらい、提出締切のギリギリまで修正を行うことになります。一方、上司の立場からすると、最初は部下に任せて書かせて、その後、さまざま指摘をしながら、何度も修正させます。

当時、このような昇格レポートの作成やチェック、それに審査は面倒だなと思っていました。しかし、振り返ってみると本人にとってはかなりよい文書作成のトレーニングになっていたと思います。そのことを痛感したのは、リコーに勤務していたときです。

リコーでは富士ゼロックスと異なり、昇格ごとにレポートを書く必要がなく、管理職になるまでに2回しかレポートを書かない人事制度になっていました。私自身は昇格の審査をしたことはありませんでしたが、事業部内で昇格の面接練習の面接官として、何度か昇格レポートを読んだことがあります。しかし、そのほとんどがQCストーリ的な論理建てがほとんどなく、私にとっては分かりにくいレポートが多かったです。

技術者であれば技術レポートを書くことも多いと思います。技術レポートも上司からチェックしてもらい、第三者が読んでも理解できるものにしていくことが重要です。チェックして修正させるのは、昇格レポートと同様に、「部下と上司の関係の上で成り立つ行為」ではないかと思います。私自身も、開発の部門長や開発グールプのリーダーをしているときは、技術レポートもかなり手直しさせていました。

私自身がいつもきちんとしたものを書けるわけではありませんが、文章を書く訓練ができていない若手のエンジニアが指導される機会もなく、年齢を重ねると、指導する側になることもなく成長しないのではないかと思います。Wikiに書く簡単なまとめから、さまざまな文書まで、第三者が読んで誤解なく理解できるかに関して指導を受けていく必要があると思います。そして、自分自身で一歩下がって、自分が書いた文章を第三者が理解できるかを意識して見直していく必要があります。