■面倒なこと⇒困っていること
前回、「面倒なことは、大抵、既に解決策が存在する」と書きましたが、個人単位ではなくプロジェクト単位になると、「面倒なこと」⇒「困っていること」になってきます。
面倒だけど、避けては通れない事態で、しかも時間が足りないというようなケースです。
■事例紹介
今回紹介するのは、SPI Japan 2007で私が報告した事例です。
少し古い事例ですが、内容的には今も十分有効だと思います。
そのプロジェクトは製品開発の最終テストの段階で、テストチームからの不具合報告が日々上がり、対応が追い付かない状況でした。不具合の報告数が対応数を上回っていたのです。
担当していたパートが全体の制御を司る部分であったため、原因の推測がつかない不具合は一旦ここに振られていたというのも、報告数が多い要因でした。
■開発者の本音
そんなプロジェクトに私が参画し、改善を試みることになりました。
開発者からは「問題があることはわかっているが対応は難しい」「忙しいのに余計な仕事を増やさないで」という声が上がっていました。
まぁ、それも無理はないでしょうね。
■まずは「見える化」する
まずは、状況の見える化から始めました。
1日に報告される不具合の数と、解決(または他パートに移管)される不具合の数をグラフ化しました。
その結果、1日当たりの解決件数が予想よりも少ないことが明らかになりました。
不具合が再現できずに何時間も試しているケースや、原因が推測できずに時間を費やすケースがあることがわかりました。特に、若手メンバのバグ対応時間が長い、他パートのバグを深追いしている、といった原因が推測されました。
当時、プロセスレベルで工数のメトリクスを収集していたため、「バグ対応」の工数を分けて記入してもらいました。
数日間の結果から、平均バグ対応時間は22時間/件で、個人差が大きく、特に若手が長時間悩んでいることが明らかになりました。
また、対応済の不具合を分析すると、不具合の40%が他パートに移管されていることが確認できました。
つまり、推測が正しかったということです。しかも、想定よりもはるかに大きな数値が出たことで開発者も驚きました。
定量的な数値による見える化は、人を説得するには非常に有効です。
見える化によって、問題点が明確になり、改善の方向性が見えてきました。
■不具合対策のフロー化
組織標準では、不具合対策について詳細な手順は記載されていませんでした。
そこで、プロセス改善の取り組みとして、不具合対策をフロー化しました。
その結果が以下の図です。
ポイントは、5つのフェーズに分け、それぞれの上限を2時間と定め、それを超える場合はリーダーに報告するというルールを設けました。
さらに、ホワイトボードに誰がどの不具合を担当し、どのフェーズを対応しているのかを見える化しました。
現在では、ホワイトボードではなくネットワーク上の共有ツールを使うのがよいでしょうが、当時はそのようなツールがなく、アナログながらも一目で状況が把握できる良い方法だったと思います。
その結果、若手が何に悩んでいるのかが明確になり、リーダーの指示もいくつかのパターンに分類できることがわかりました。
また、再現しない原因はテスト担当者が記載した不具合報告書の情報不足であるケースが多く、2時間という時間ではなく、より短い時間で判断し、テスト担当者に相談するほうが良いことも明らかになりました。
これらの知見をバグ対応手順としてまとめることで、リーダーに報告せずとも自主的に対応できるようになっていきました。下図はその手順の抜粋です。
■結果の共有
この取り組みの結果、平均バグ対応時間は、わずか１週間で22時間/件から7.1時間/件にまで短縮されました。
積み上がっていた不具合報告が次々と解消され、残件ゼロのゴールが見えてきました。
重要なのは、こういった「効果」をメンバと共有することです。
感じていた効果を数値で示されると、それは確信に変わります。
メトリクスの取得期間や精度は必ずしも重要ではありません。
効果がでているのですから、「頑張ったね」「凄いぞ!!」と数値で示すことが重要です。
結果として、メンバのモチベーションが上がり、さらなる改善への意識も向上します。
次回はメトリクスの活用についてお話します。
プロセス改善をやってみよう(1/3) ～ 面倒なことはしたくない ～
プロセス改善をやってみよう(2/3) ～ プロジェクトでの課題を改善する ～
プロセス改善をやってみよう(3/3) ～ メトリクスを有効活用する ～