昨日は社内で開発されたとあるシステムの引き継ぎを受けていました。
「このシステムは比較的安定しています。ユーザーから不具合やトラブルの報告はほとんどありません」
ということだそうです。
説明が一通り終わった後、実際にユーザーのオペレーションを確認しましょう、ということで現地に向かいました。
ところが実際にユーザーの話を聞いていると・・・
「こういう操作をするとねぇ、よくエラーが発生するんですよ・・・ほら、出た！」
画面には例外発生を知らせるプロンプトが表示されていました。
話を聞くと以前から頻繁に色々な場面でこういうエラー発生していたそうです。
しかし、そのユーザーは経験的にエラーが発生した場合の対処方法を独自で編み出していたらしく、本当に困ったとき以外は我々に助けを求めなかったそうです。
つまり、トラブルがない、安定している、というのは幻だったわけです。。。
うちの会社の場合、社内で開発されたシステムはどうも正常系の仕様しか中心に考えていないのでは？と思うようなシステムが多いです。
正常系の仕様を満たすことは必要最低限なので出来て当然です。
しかしシステムは異常系も十分考慮すべきです(これも当たり前なんですが・・・)。
システム稼働前に予測可能な異常系(例えば更新衝突とか)はシステムの振る舞いを決めて、テストもされるべきですし、全く予想できない実行時エラーについてもログを残したり、通知メールを送信したりした後で、システムは「安全に死ぬ」べきです。
そういえば他にも一見安定しているように見せかけて、実は発生した例外を握りつぶし続けていただけ、っていうシステムもあったなあ・・・。
あとはいわゆる非機能要求ってやつですね。パフォーマンスとか可用性とか。
このへんも本番環境を十分に考慮できていないシステムをよく見かけます。
開発用PCやテストサーバーでサクサク動いているだけじゃ意味が無いわけで、本番環境のデータ量、ユーザー数等を見込んで最初から設計、テストをやってましたか？と聞きたくなります。
それから仕様書がほとんどないシステムも痛いです。。。
社内向けのシステムってユーザーとメールや口頭でだいたいの仕様を決めて、細かい動きは開発者が頭の中で考えて、ユーザーに試用してもらってOKが出たらハイ終わり、ってな感じで作られてきたんじゃないでしょうか？
システムが稼働してからしばらくの間は開発者がサポートも担当するので、仕様書が無くてもその本人の頭の中にある仕様書で対処できます。
しかし組織が変わったり、開発者が退職するなどしてオリジナルの開発者がサポートを離れたら、さあ大変です。
細かいことは誰も分からないので引き継ぎを受けた人は非常に不安になりますし、実際にトラブルや改造要求が発生したら、コードを追いかけることぐらいしか出来ないのでとんでもなく時間がかかります。
ちなみに冒頭でお話ししたシステムは2回目の引き継ぎです。
つまり説明をした人もオリジナルの開発者から引継ぎを受けた人で、詳細な仕様は理解できていません。。。
仕様書が無いのと似たような理由でプログラムもめちゃくちゃになります。
つまり「動けばOK」的ないきあたりばったりのコーディングやトリッキーな(というか無駄に複雑な)俺様ロジックがあちこちに登場して、結局引き継ぎを受けた人が苦労します。
というか、そもそも一人で要求を聞いて、一人で設計・開発して、一人でサポートしてきた従来の開発スタイルがおかしいんですよね。
普通だったら何名かのチームで開発・テストするから、もう少しレビューされて洗練されたシステムが出来上がると思うのですが。。。
こういう開発スタイルのメリットをあえて挙げるなら「スピード」ですね。
ドキュメントも書かない、正常系しか中心に考えない、テストも十分にしない、自分が作りたいように作る、ってやれば、かなりのスピードでシステムがリリースできるでしょう。
もちろんスピードは大事ですし、顧客のためにもだらだらと開発期間を延ばすことは良くないです。
しかし、こういうスタイルはその代償としてシステムの「負の遺産化」を招くわけです。
ええ、引き継ぎを受けた人にとっては負の遺産の何者でもありません。
結局、将来のことを十分に考えず、大事なことを後回しにしているだけですから。
なんでおいらはこんなにたくさん「負の遺産」を相続し続けてるんだろ？
引き継ぎばっか受けるんじゃなくて、おいらもシステムを作りた〜い!!
・・・すみません、なんか色々と話が発展して、何が言いたいのかよく分からなくなってきました。
結局ね、思ったのは「この会社の内作システムの品質はどいつもこいつもこのレベルかい！」ってことだけです。
これまで「とほほ内作システム」を何本も見てきたので、もういい加減にしてくれという意味で愚痴りたくなっただけです。
そう、これは結局ただの愚痴・・・。
