トラブルシュートの時に書く文書

問題の解明・解決を行った時に書く文書の2回目です。このような場合に書く文書は大まかに4種類あるとして、以下のようなものを列挙しました。

• 解明・解決策を探っているときに上司に宛てる報告書
• 解明・解決後に組織に納める報告書
• 解明・解決策を同僚に知らしめる報告書
• 問題が発生しないよう顧客に知らしめる報告書

前回説明したのは「上司に宛てる報告書」。今回はそれ以外の文書について書きます。

解明・解決後に組織に納める報告書

問題の解決後に、記録を目的として所定の形式の文書を書かなければならないことがままあります。これはしっかりした会社では極普通に見られ、新入社員として入ると先輩からきちんと書き方を教わったりします。
出来事の文書化と言うのは業務の基本の基本です。文書化することで問題の再発を防ぎ、知識の共有を図るわけです。が、本当にそう機能しているかどうかは運次第といった面もあります。文書を書くことが目的となってしまっている場合、そのような文書を書くのは苦痛でしかないでしょう。
特に若い方には。
形骸化した文書を書かされている場合には、次に書くような別目的での流用をこっそり図るのも手です。

解明・解決策を同僚に知らしめる報告書

同僚に自分がえた知識を分け与えるというのは、職場の改善に劇的な効果があります。

• 相談相手が増える
• 一度やった仕事が回ってこなくなる
• より高度な仕事に就く機会になる

技術職に就いたことがあるならば経験があると思いますが、相談相手のあるなしは極端に生産性に影響します。きっと一緒に考えると言うことが良いのでしょう。相談する場合、必ずしも相手が自分より経験のある人、高い知識を持っている人である必要はありません。しかし、自分と同程度以上の実力のある人に越したことはありません。自分のえた知識を共有すれば、相談相手が増えます。
また、自分ができる仕事は他人もできる様になりますので一度やった仕事が「君しかできない」と繰り返し回ってくることを防ぐことができます。その結果、より上の仕事のチャンスが来るかもしれません。
同僚に経験を伝える方法は幾つもありますが、たいていは要点をかいつまんで説明するだけで十分です。同じ仕事をしている者同士の利点で、ある程度の共有知識はありますから、懇切丁寧に説明する必要はありません。
むしろ必要なのはぱっと読んでわかる適切な量と、タイトルを並べたときの閲覧性です。
この手の文書を共有して成功するかどうかは、組織の文化に強く依存します。あるいは、そのような文化がない場合もあるでしょう。その場合、仕事の面で信頼できる友達と見つけて、一緒に始めると良いでしょう。
多くの場合、「書くのは自分だけ」になりがちです。しかし、あきらめずに続けるのが肝心です。最悪の場合、自分用の仕事メモになっても何の損もありません。
また、ある程度整理さえしておけばこの情報は顧客に見せることもできます。頻繁に入ってくる質問は「これをお読みください」で済ませることができるので非常に重宝します。

問題が発生しないよう顧客に知らしめる報告書

アプリケーション・ノートです。問題が生じた場合、その問題が知識の不足からきたのであれば、アプリケーション・ノートを書いて他の顧客での発生を防ぐことができます。Linux文化でいうところのHowToも同じです。あれを問題予防と見ない方もいるかもしれませんが、「どうしたらいいかわからない」という問題を解決することで、相手を前進させるというのはどのようなコミュニティにとっても利益のあることです。
アプリケーション・ノートが完備すると、顧客のつまずきが減るため、自分のところにつまらない問題が回ってこなくなります。これは自分自身と会社の生産性にとって非常に良い事です。
アプリケーション・ノートは会社の顔になるものですので、個人では始めるのも継続するのも大変です。しかし、機会があるなら始めることをお奨めします。

技術ドキュメントには書く価値がある

技術者の文書嫌いは洋の東西を問わず一般的です。しかし、実際のところ技術を広めるのは製品ではなく文書です。技術文書を書くと言う行為は常に内省的なものになり、自分の身になります。
「書かされている」
という気持ちを捨てて、その文書で何かをつかんでやろうと考えれば、きっとよい結果がもたらされます。