すべてのプログラムは属人化する

Hello World,はーぼです。

去年退職した人が作成し業務で使っているExcelのプログラム（いわゆるVBAというやつです）があります。

このExcelのプログラムが動かないと、今の業務に大きな支障をきたすことになります。今までプログラムが数分で行っていたデータを処理して資料を作成するという自動化された作業を、人が手でしないといけなくなるのですが、これが膨大な作業で時間もかかるし、人がやるということは精度においても常にミスが起きることを考慮しなくてはなりません。

ところが、このプログラムを作った人は、どうせ退職するんだからと思ったのかどうかはわかりませんが、プログラミングに関する資料を一切残していませんでした。

インプットのデータとアウトプットの資料はありますし、正規業務なので、どういうことをしているかはわかっているのですが、それをプログラムでどのように実現しているか（コーディングしているか）ということを一切残していないんですね。

残っているのは数千行にもわたるVBAのソースコードのみ。
で、それを数カ月前からボクが解析しているというわけです。

例えば人が、なにかの本を読み（インプット）、それに気づきを得て、ブログを書いた（アウトプット）として、インプットの本とその成果のブログの文章だけがあっても、その人の思考の過程はわからないわけです。

なぜそのような結論に至ったかを書いていない場合、誰も理解することはできないでしょう。

プログラムもまたインプットからアウトプットを作るための、思考の過程の塊なのではないかと思います。

なぜこのような判断をしているのか、この変数になぜフラグを立てているのか、変数の役割はなにか等々。設計思想という思考の過程はプログラムを組む人の性格や思考の癖が大きく関与します。

他人の思考がわからないように、他人が作ったプログラムを理解するより、自分がイチから作った方が早い、と言われることがあるのはきっとそういうことがあるからなのでしょう。

まずきちんとしたプログラムの設計書を作って、関係者でレビューを行なったのち、それに基づいてプログラムを作成し、ソースコードレベルで関係者の理解を統一させる。業務の重要さにもよりますが、そのくらいのことをしないと、プログラムは属人化し、その人がいなくなったら、再び手作業で業務をしなくてはならなくなることになります。

意外とトップの人って、こういうことに理解がない人が多いような気がするのは、ボクだけなのでしょうか？

ということで今日はここまで。Good-Bye World,はーぼでした。