障害対応の工数は謎だらけ

開発現場では、新規の開発案件等に対して必要工数の見積もりを要求され、それはそれなりに難しいものが有るけれど、それ以上に難しいのは障害対応の工数見積もりだと思う。もちろん、内容を一目見て容易に原因と修正内容が分かるものがある一方で、原因の調査に難航し、さらに修正確認にも手間取るものが珍しくなかったりする。

何故そんなに時間がかかってしまうのだろうかと思って改めて考えてみたところ、対応に時間を要するものはこんな特徴を持っているようだ。

  • 障害レポートに記載されている再現手順に従っても問題が再現しない。記載されていない情報に相違があるらしいので、レポートの報告者に詳細を問い合わせをする必要があり、そのやり取りに時間がかかってしまう。
  • 原因調査のためにログ出力を追加したら問題が発生しなくなってしまう。ログ出力処理が、タイミングを何か変えてしまっているらしいが、その原因や影響理由が分からない。
  • 不特定のタイミングで問題が発生するが、その規則性が分からない。全くのランダムという訳でもなさそうだし、何かの規則性を持っているようにも見えるが、それを調べるために再現確認を行うだけで時間がかかってしまう。
  • 問題が発生しているのは社外から調達したモジュールと分かったものの、既に瑕疵期間が終わってしまっているので対応を依頼できず、内部を知らない社内の開発者が手探りで原因を調べなければならない。
  • 本番環境や実機環境では問題が発生するのに、開発環境やシミュレーション環境では再現しない。環境の違いが症状の違いを引き起こしているらしいが、何がその違いを生み出しているのか分からない。
  • 開発規模が大きく、問題箇所は離れた開発拠点で作られたものと判明する。そこで調査を依頼するものの、担当者は別の案件で手が離せなかったり、既に退職した後だったりする。
  • 原因調査のために特別にログ出力を仕込んだモジュールを用意し、これを使って動作確認したいのだが、通常のビルド手順やリリース方法とは異なるのでビルドや起動に成功せず、調査が進められない。
  • 複数の構成管理リポジトリから取得したモジュールを利用して最終的なビルドを組み立てているので、問題箇所の担当者はどのチームの誰なのか全く分からない。仕方なく、各チームリーダを渡り歩いて担当者を探しだす羽目になる。
  • 昔の開発環境で作られたシステムなので、同じ環境を用意するところから始めなければならず、そのセットアップやシステムの導入に時間がかかる。しかも当時の記録は不充分なことが多いので、同じ環境を再現できず、そもそも問題調査を開始出来なかったりする。

問題を再現させることが出来れば原因は分かったも同然だし、対策方法も考えやすいのだが、そんな古き良き時代の開発とは全く異なるのが今の開発現場だと思う。問題箇所を絞り込むことが先決だよ、キミ、という有り難いアドバイスを貰ったこともあるけれど、そもそも100万行を越えるソースコードをどうやって絞り込んで行くべきなのか見当もつかない。

「至急対応」とか「急ぎの修正をお願いします」と要求してくる人の気持ちは分かるし、早く直したい気持ちはこちらにも有るけれど、大きく複雑なソフトになればなるほど修正は難易度は高くなる。一体いつになったら直るのだ!と詰問されても、問題を見つけ出す銀の弾丸は無いし、直ぐに完了出来るという見込みも保証も無い。作業工程を尋ねられるので仕方なく希望的日程を出してみたりするけれど、実際のところ「問題の状況は様々だから、目処を付けるにはある程度調べてみなければ分からない」のが実情ではないかと思っている。