ぷろぐらまのお仕事、というと、コーディングだけ？とか思うかも知れないけれど、決してそんな事は無いです。仕様をプログラム言語に翻訳して機械語に登録させるのもお仕事ですが、それ以外にも、「何を誰がどうしたか」「なぜこれをこうしたのか」といった記録をとって、「これをこうするとこう動くよ」という証拠を残して、「これはこういうふうにするとこうなるんだよ」という手引きを作ってあげる必要があったりします。世に言う、ドキュメンテーション、ですね。
このドキュメンテーション、忘れられがちなのですがとても大事です。そしてプログラムするよりもずっと手間がかかり、かつ難しいのです。まぁ「プログラムしたことを日本語にするだけじゃん」なんて思うのでしょうけれど、違うのです。ドキュメントにする事柄は、自分が判れば良いものではダメです。他人が判るように書かなければそれはドキュメントではなくただのメモ、大括りにしちゃうと、対会社、対ユーザーには全く使うことのできない非公式文書であり、書かれている内容はそれがたとえ正しい事であっても「認められません」。
たとえば、「あるボタンを押しながらある事をするとプログラムがハングアップする」という不具合があった場合、これがドキュメントとして記載されていて、対会社、対ユーザーに対しての公式仕様として出ていた場合には「既知の不具合」となりますから、対応策検討の余地がありますし、もしかしたらすでに対応策を協議済としておけるかもしれません。けれど、これがプログラマのメモにだけ残されていたら……。最悪「テスト不十分なプログラムを納品した」という賠償責任が浮上するかもしれません。大げさな話、と思うかもしれませんが、そこを笑えないのがこの業界。信じられない魑魅魍魎が会議室に存在するのは事実です。
プログラマはプログラムを作るのと同時に、「何をどうしたのか」を何らかの形、メモなりコメントなりできちんと記録し、それをドキュメントに記載できるよう働きかけるようにしておくことに越した事はありません。
もちろんそれと同時に、まとめ役であるリーダー、マネージャは作業のスケジュールと見積もりにおいて、ドキュメンテーションというフェーズを軽視しないこと、ドキュメントの品質について責任を持つ事を自覚することも必要です。プログラマや担当者が作成するドキュメントの読み合わせ、レビューのフェーズ、案外と軽視されていたりするんですけれど。まぁ前述のような経験を経てきているリーダーさんやマネージャーさんがいると自然と盛り込んでくださるし、考えてもくださるんですが、ほら、そこは事実は小説より奇なり、だから（笑）
情けは人の為ならず、ドキュメントは人の為ならず