ITコーディネータの吉田聖書です。
システム開発において、
製品版としてリリースするまでに
様々なエラーに対して出会いと別れを繰り返します。
エラーと言っても様々で、
プログラム開発初期の文法エラーに始まり、
システム同士を接続する際の通信エラーなど、
種類を挙げたらキリがありません。
5年くらい前にも
開発中に出会うエラーメッセージにまつわる記事を
書いたことがありました。
⇒ プログラミングが得意な人、そうでない人
今回はそれとは別の開発プロジェクトでの話です。
時期としてはかなり前で、
私が初めての試みとして
継続的統合（CI）環境を導入したプロジェクトでした。
継続的統合環境というのは、
プログラマの開発端末とは別に
社内サーバ上に開発環境を構築して、
毎日深夜に最新のソースコードを
データベースから取得し、
コンパイル、ビルドをかけた上で
ユニットテストを自動で実行し、
テスト結果のレポートを作成するようにしました。
ユニットテストの導入に際しては
様々なトラブルもあったのですが、
それはまた別の機会にお話ししたいと思います。
実際の運用としては、
毎朝その実行結果をまず確認します。
エラーが出ていたら、
エラーを吐いているモジュールを特定し、
そのモジュールをコーディングしたプログラマに、
修正を依頼するというルーティーンを行っていました。
内部での開発が落ち着き、
徐々にクライアントの環境での
システムテストに移行していくと、
コードの修正作業が少なくなりますが、
それでも継続的統合環境は維持していまして、
毎日テストの正常結果をレポートしていました。
そんなある日、その自動テストが急に
異常結果をレポートするようになりました。
ログにはエラーが記録されていますが、
コードは何も変更していないし、
手がかりになりそうなものは思いつきませんでした。
なので、調査は早々に切り上げ、
そのエラーは気になるけれど
取扱が有耶無耶のままとなりました。
そんな事も忘れ、
私がその現場を離れしばらくした頃、
当時のリーダーだった方から連絡がありました。
例のシステムが本番障害で止まったとのこと。
どうやら、原因はミドルウェアの
ライセンスが組込めておらずに
試用期限切れでガードがかかったということでした。
そして、それは
私たちがあの時無視することにしたエラーの
原因そのものだったのです。
もちろん、対処としては、
取得済みのライセンスを
きちんと製品に組み込むことで
問題なく復旧したのですが、
当時のリーダーと
「あの時のエラーを放置せずに
踏み込んで調査していたら
今回の障害は防げたな」
という会話をしたのを覚えています。
結果的に放置した理由は
いくらでも言い訳できるのですが、
無念な気持ちになりました。
システム開発の現場では、
特に開発環境で発生するエラーは
一般に軽視されがちです。
それは開発環境が本番環境と全く同じ構成に出来ず、
特有の制約があるためでもあります。
それでも、開発環境だから、
プログラムには問題ないからという理由で
エラー情報を軽視する行為は
慎まなければならないと思わされました。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。