メモの話

初めに

私は上司からソースコードの修正を依頼されたら、まず作業内容の手順メモを取ります。
大抵の場合その作業はすぐには行わないので(何故なら私は納期の迫っている別案件のソースコードを書いているからです!)、数日後にメモを見返した時、自分自身の書いたメモの真意が分からなくなる時があります。
幸いにも上司は温厚ですので、作業を始める時にはもう一度修正内容を聞きます。「同じ事を二度言わせるな!」と罵声を浴びせられた事はありません。
むしろ「仕様が分からないなら何度でも説明しよう」と仰るくらいです。


そして私の後輩も、私が依頼した作業に関するメモをとります。
後輩はメモを取る事に熱心な人ですが、残念な事に、当初はメモが役に立たない事が多かったのでした。
今はメモの取り方を少しだけ私が教えたので、ある程度改善はしています。
また、私は上司を見習って、後輩にも「同じ事を二度言わせるな」とは言わない事にしています。
ただ、後輩はCentOSについてはジュニアエンジニアなので、「公開されている事(コマンドの使い方など)はググってください」「ググって試して出来なければ聞いてください」「ググっても出ない事、つまり業務知識については何度でも聞いてください」と答えています。

メモという言葉の分割

私の仕事はパッケージソフトを顧客ごとにカスタマイズする事です。
何度も同じソースコードと向き合っていると、「似たような事」をやる時があります。
「昔、似たような修正を行っている」と感じた時は、私はソースコードを修正しながら作業内容をメモします。作業手順を作成するのです。
(同じ事なら何度もしないようソースコードを改変すべきという意見もあるでしょうが、それは無視してください:-p)


後輩も初めはメモを取っていましたが、全く役に立っていませんでした。
そのメモは後輩の理解を助長する為のものでもなく、後で見返して思い出せるものでもなく、TODOリストでもない、ただの単語の走り書きだったのです。
そこで私は、後輩に「手順書を作りなさい」というアドバイスをしました。


メモにはいくつかの側面があります。

  1. 理解のメモ
  2. 手順書
  3. TODOリスト


理解のメモは、自分がメモを見たら即座にその事柄を思い出せるものです。
特定環境でビルドしたC言語のバイナリのようなものですので、他人との互換性はありません。あくまで自分が理解する為のものです。
逆に、このバイナリが自分でも理解不能なものを書いていた場合、それはすぐにシュレッダーにかけましょう。それはゴミです。
私はこれを書いた時は、理解の一助とする為に大事に手元においています。顧客から仕様について問い合わせの電話があれば、そのメモを見て、詳細な仕様をお答えしています(ソースコードを読みながら答えろ? 私には難しい話です。その時は「調査致します」と答え、そこで電話を切ります)。


対して手順書は「これに従えば作業が遂行出来る」ものです。
言ってみればこれはC言語ソースコードです。実行する人間が変わっても、手順書の内容が正しく、手順を間違えなければ誰でも成果を出す事が出来ます。
このメモは他人との互換性が高く、私が収録した作業手順は後輩に渡しています。
後輩はそれを忠実に実行すれば成果が出せるのです。スゴイ!



メモは誰が取るべきか

ところが、後輩に渡した手順書で後輩は成果を出せませんでした。
後輩はCentOSというOSの名前は知っていましたが、コマンドはcdやlsくらいしか知らなかったのです。
後輩はNTPサーバを使って時刻補正を行う手順で、エラーメッセージを出しているにも関わらず、何の対処もしなかったのです。
後輩が悪いのでしょうか? 業務を教えきれなかった先輩(私)が悪いのでしょうか? いいえ、手順書にはエラーメッセージを出した時の対処方法が載っていなかった事が悪いのです。


そこで、私は後輩に対して「手順書に不備があれば、改定しなさい」と教えました。また、後輩の手に追えない手順が手順書に必要になった時は、私が追記をしました。
手順書として書いたメモは他人との互換性は高いのですが、C言語のように未定義動作はどうしても発生してしまうのです。
手順書メモは後輩が入るまで私一人によって運用されていました。ですから、私から見れば手順書に書く必要がない事であっても、他人からすれば記載が必須な場面が存在したのです。
後輩は今では手順書に不備があるたびに、必要な事柄を手順としてメモに追加しています。


もちろん、私個人の手順書も日々改定されています。
ここで大事なのは、メモを書くべき人間は部署の人間全員(上司、私、そして後輩)であるという事です。
手順書は生き物だったのです。メンテナンスなしでは、成果が得られないのです。



メモは詳細な手順書が理想

私は酷く理解力がないので、メモは詳細な手順書である事を望みます。
何かを思い出すのはとても大変な事です。ぼーっとしていると誤読をして間違った理解をする時もあります。
手順書に落としておけば、昨日飲んだ楽しいお酒が二日酔いとして襲ってきた時でも安心です。手順書に従えばいいのですから。


モヒカンの方々に断っておくと、手順書の中には「手順を自動化したスクリプトを流す」という項目があります。
また、手順書に出来たという事は自動化の余地があるという事です。手順書に落としたものは私が暇を見つけて自動化スクリプトを書いて、手順書も同時に改定しています。
全ての手順は、最終的には機械が実行してくれるでしょう。



総括

総括として、私は以下のように思っています。

  1. メモは手順書であるべきである。
  2. メモは立場に関係なく誰でも書く。
  3. 手順書になっているメモは、人に引き継ぎしやすい。
  4. メモは書き終えた時点で陳腐化が始まる。メンテナンスは必須。