脳内会議11 / norio.nakayama
昨日、担当している案件の役員報告に参加しました。
大型案件の本番リリース前は、必ず役員あてに報告を
行うのが僕の会社のしきたりです。
”案件の概要”、”コスト”、”品質”、”コンティンジェンシー”などが
主な報告の対象。本当にリリースをして問題ないか？
最終的な承認をもらうための場でもあります。
一昨日から説明するための資料を作成していたのですが、
テスト品質について問題が。
網羅的にテストを実施しているか？ ということを客観的に
評価するための”テスト密度”という考えかたがあります。
一般的には、テスト実施数 ÷ 修正規模（ステップ数）という
計算式で算出します。
今回の案件もこの計算式でテスト密度を算出したんですが、
業界標準の指標を大きく超える結果となってしまいました。
（テスト実施数が基準より多い）
多いぶんには別にいいじゃん！と言いたいのですが、
なぜ多いのか？という理由を説明しなければなりません。
理由はかんたん。
今回の案件はパッケージとよばれる既製のソフトウェアを
多く利用しており、自分たちで手を動かすコーディングの部分が
少なかったためです。
ちゃんとした理由があるのでそのまま説明すればよかったのですが、
なぜか資料の見栄えを整える方向に話しが進みました。
結局、基準としている指標を調整し、テスト件数はそれほど
多くない（と見せる）修正を行うことに。
”リリース実施の承認をもらう”という目的から考えれば
適切な決断だったのかもしれません。
今回は会議までに時間がなく、仕方ない部分もあると思います。
本来であれば、実際の数値を見せた上で問題ないことを
納得してもらいところでありました。
今の部署は、みな案件をかけもちかけもちで
１つの案件にかけられる時間も限られています。
目の前の仕事に追われるのではなく、腰を据えて１つのことに
取り組むことも必要。
効率化して時間を捻出していきたいと思います。