今の仕事は、とあるお客さんのWebシステムの保守運用が中心。
「保守運用」というのは、
- 今度新しい商品を扱うようになったので、その商品をWebから購入できるようにしてほしい
- 社内の販売管理システムを新しくするので、連携できるようにしてほしい
- なんだかメールが送信されていないようなんだけど、調べてほしい
- 毎月、利用状況のレポートを出して
といったことをやる。
で、こういった作業、特に、トラブルの対応でどのくらいかかりそうっていうことは、事前にわからないので(わかるのだったらトラブルにならないように対応しろ!ということだ)、
- 実際に対応した時間をレポートにして提出する
- あるいは、事前に○時間分の作業が発生すると見積もっておく。見積を超えそうな作業量になりそうなときは、翌月にするか、別途見積もるか相談する。
といった契約になる。
明らかに、最初に構築するときよりもお金が出ないにおいがプンプンするし、実際、出ない。だから、予算の都合上、中途半端な機能で妥協するという、誰も嬉しくない解決策がとられることも多くある。
なので、ライブラリーのバージョンアップなどは、セキュリティーホールが見つかって大騒ぎにならない限り、まず行えない。
最近「フロントエンドが複雑になっている」なんて話は、まさに別世界。時代遅れとなったライブラリーを騙し騙し使いながら、機能変更の要望に対応していくことになる。
「機能変更の際、ついでにバージョンアップもやってしまう」というのは、残念ながら現実的ではない。
- 存在しない仕様書
- 意図の読み取れないプログラム
- 退職している、初期開発担当者
- 状況不明な、他システム連携
- 意味不明、かつ、現機能を網羅しているとは思えない、テスト報告書
- 自動テストどころか、ユニットテストすら影も形もない
こういった現実を見ると、機能変更ですら怖気付いてしまう。
初期開発を適切に行なっていれば解決できる問題が大部分であるものの、それはそれで、費用や時間の制限で、いろいろ妥協しなければならないことが発生する。
妥協したツケを保守で払わされることになるため、保守からプロジェクトに参加したメンバーは、身に覚えのないツケを払わされることになるのだ。モチベーションなど上がるわけもなく、また、要求されたことを限られた費用の中で実現していくので、ますます意味不明なシステムに育っていく。
一回大きなトラブルでも起こって、「つくり直すくらいのコストをかけてしっかり確認、改修しないと」ということにならないと、この負の連鎖からは脱却できないだろう。