システム開発を進めると必ず必要になるのはメトリクスによる状況把握です。
3回に渡って、メトリクスとは
①何のためにとるのか
②どのようなものがあるのか
③どうやって評価するのか
などを考えていきます。
今回は①何のためにとるのか、です。
①何のためにとるのか
私がこれまで関わってきた中では、以下のような目的をもって運用していました。
［メトリクスを取る目的の例］
- 各個人の作業進捗を確認する
- 各個人の品質状況を確認する
- システム全体として作業遅延抑止の材料
- システム全体としてのリスクを把握
- 上流工程〜下流工程への品質推移把握
- 品質状況や作業近況を上司に報告する
- 品質状況や作業近況を顧客に説明する
など、多くの目的があります。
他のシステムのメトリクスと比較することで、開発中のシステムの品質状況の良し悪しなどを予測することも可能です。
もちろん、下流工程やリリース後にトラブルが発生した場合には、メトリクス実績を再点検することで、進めてきたプロセスの弱点が見える事もあります。弱点がわかれば、品質改善施策を効率的に進めることに繋がります。
このように、上手にメトリクスを取ることで、品質向上やプロセス改善に繋げることが出来ます。
しかし、トラブル発生時にメトリクスを再点検しても、なにも弱点が見つからないこともあるかもしれません。
この場合には、3つの可能性があります。
- メトリクスが足りなかった
- メトリクスが正しく取られていなかった
- メトリクスを取るよりも前の工程に問題があった（企画、要件定義、他）
1.は次回のメトリクスの種類にて説明しますので、今回は2.と3.について説明します。
- メトリクスが正しく取られていなかった
開発するメンバがメトリクスの意義をきちんと理解しておらず、細かな数値化を行わないまま作業を進めた場合におこります。メトリクスの項目毎の意義や活用方法などを予め十分に伝えておく事が肝となります。
また、メトリクスが多すぎて、忙しさのあまり記録しきれない事もあるかもしれません。出来るだけ自動的にメトリクスが取れる仕組みの構築が有効となります。
- メトリクスを取るよりも前の工程に問題があった
要件の洗い出しが不十分で、負荷量や性能値などの合意が出来ていなかった場合などに起こります。または、出来たものの画面イメージが違ったなどの事例もあります。
上流での要件合意のやり方に問題がある場合や、合意結果の記録に問題がある場合（特に、なぜそのようになったのかの根拠が記録されておらず、後になり要件の誤解に繋がったなど）もあります。要件を整理する際に業務についての理解が不十分である場合にも、要件考慮漏れの大きな原因になります。
今回はメトリクスの目的について考えてみました。
次回からは②メトリクスにはどのようなものがあるのか③どうやって評価するのか、について考えていきたいと思います。