開発後かなり時間が経ったシステムの問い合わせ対応

今日はたまたま、
・数ヶ月前にまとめてお渡ししたSMTPプロキシ
・1年以上前に作ったサーバ2重化システムWindows版
・1年前くらいにお渡しした動画中継システム
と、少々間があいたシステムのお問い合わせ、対応を行いました。依頼した方としては、開発した当人に相談しているのだからすぐに解決できて当然だろう、と考えるのでしょうけれど、開発した側はその間に全く他のシステムの開発をいくつも行っていて、実は大抵の場合、すっかり忘れているものです。

こんな時のためにドキュメントをきちんと整備しておけばいいのに、と言われそうですが、お客さんにお渡ししたシステムはもちろんドキュメントも必要最低限はお渡ししています。が、多くの場合、ドキュメントを調べてみるよりまずメールや電話が飛んできます。開発した当人も実はほとんどの場合、ドキュメントはあてにしません。ドキュメントはメンテナンスされていないことが多く、信用できない場合がかなり多いのです。

結局どうするかと言えば、ソースを見るしかないのです。ソースはバージョン管理さえミスしていなければ、実際に動いているものと確実に一致した記述になっています。ソースがどれだけシンプルで見やすくできているかがポイントなのです。私の場合、大抵はソースを見て、動かせる環境があれば動かしてみればかなり思い出せます。動かせる環境がないことも多いのですが、それでもソースをじっくり見直せば大体解決できます。

解析するためのもう一つのポイントがログ出力です。実機で問題が発生した場合にログがあるかないかで解決の確率が大きく変わります。ユーザに見せるログではなく、解析用のログがポイントです。体裁や文言はあまり凝らずに、必要な情報がきちんと出力されていることが何よりも大切です。ログを出力すると負荷がかかると嫌われることもありますが、実機で問題が発生したのを再現できる確率はかなり低く、ログがなければお手上げと言うことが非常に多いものです。syslogなどは量が多いと本当に遅くなるので必要最低限にし、普通のファイルにローテーションしながら記録する仕組みを解析専用に作っておくのがお勧めです。ただし、組み込み系だとそもそも記録する場所が物理的にない場合が多いので、辛いものです。

解析のポイントは、
・シンプルで分かりやすいソース
・ドキュメントは大抵あまり役に立たない
・ログはとても重要
というところでしょう。依頼する立場の方もどうせ使わないドキュメントに時間を使わせるより、ソースをきちんとレベルアップさせることや、ログの確認を行う方が重要かも知れません。あとは開発者が似たようなタイプの仕事を続けているかどうかもポイントです。毎回全く違う分野の仕事を担当していると本当に思い出すのが大変になります。私はすでにWEBやDB関連の仕事は数年自分で担当していないので思い出すのは辛いですねぇ。