無理なExcel管理が招くプロジェクトの停滞について

はじめに

こんにちはーこんにちはー。

たーせるです。プログラマ3年生です。

今日は、バグ管理にまつわる話を起点にした連ツイを適当にだらだらまとめました。

バグが発覚したら…

プログラムを作ってテストをしていると、必ずと言っていいほど想定外の挙動（バグ）が発覚します。

実際の開発現場ではバグをその場で直してはいおしまい、ということは基本的にありません*1。

どのプロジェクトであっても、バグは何らかの形で管理されます。


バグを単票で管理しておくと、開発者は「今どんな問題が起きていて、誰が対処しているのか」を把握することができるようになります。正しく運用されれば、バグがそのまま放置される危険性を大幅に減らすこともできます。

もう少し広い視点で見ると、バグの発見頻度・既知バグの件数・バグの収束状況などが、PMOや顧客に対して品質を担保する際の根拠として使われることもあります*2。

Excel管理は絶対におすすめしない


溜まりに溜まったExcel製のバグ票*3を集計して「数字が合わない」「いつの時点の集計値だ……」とか言いながら、メンバーに対して「Excel単票を削除していませんか？」とか「台帳と数が合わないんですけど」とか問い合わせている悪い夢を何度か見ました*4。

そもそもバグ取りのような流動性の高い事象をExcelで管理してうまく回し切った事例を僕は知りません。集計のしやすさというメリット以上に、管理情報が不整合を起こしやすいデメリットの方が勝っているせいです。

そうこうしている間にも、新たなバグ票がやってきたりクローズの報告がきたり事態は秒速で変化するわけです。対応能力の限界なんてあっという間に超えます。これでは収束が見えるはずなどありません。

システムを作っていく過程でバグが大量に発生するのはある意味当たり前で、それをいかに効率よく消化できるかがプロジェクトを加速させるポイントなのに、開発者が自分の責任以外のところで仕事を止められるのは不幸だと感じるわけです。

一部門がパンクするとプロジェクト自体が失速する

上記ツイートの“仕掛かり在庫”とは、クローズされていないバグ票を意味しています。

まとめ

思いつくまま推敲なしにつぶやいているうちに、話がいろいろ蛇行してしまいました。結局なにが言いたかったかというと……

  • バグ管理そのものは大事である
  • Excelによるバグ管理には無理がある
  • 無理を通そうとするとプロジェクト全体が停滞する
  • 炎上してみんな燃え死ぬ

開発者は「品管がのろまなせいだ」と考えているし、品管は「開発者がバグをいっぱい作りこんだせいだ」と考えている。

……という夢をみた、ということです。

こんな経験、ありませんか？

おまけ

*1:例外的に、静的解析やテストツールで自動検出されたつまらないバグはしれっと直すことが多いです。

*2:個人的には、それらの情報はあまり品質指標として意味をなさないと考えています。

*3:1バグにつき1Excelファイル。

*4:御用聞きの新人ならまだしも、これを中堅レベルの人がやっていたりすることがあります。

Copyright (c) 2012 @tercel_s, @iTercel, @pi_cro_s.