読者です 読者をやめる 読者になる 読者になる

品質管理・進捗管理に質問表を活用する

「要件や仕様が正しく伝わっているか?」ということを把握するのは難しい、と感じます。

  • 自分は当たり前に思っていても、相手はそうでない
  • 打ち合わせで説明したつもりが、相手には意図した通り伝わっていなかった
  • 仕様書はレビューしたけど、理解が違っていることに、受入になってから気付いた

などなど、問題の事例を挙げたら、キリがないでしょう。

要件定義のやり方や、レビューのやり方で、ある程度は改善できるモノの、大抵の場合、問題に気付くのは試験や受入段階になってから。
それがプロジェクトの遅延や失敗に繋がることにもなります。

アジャイルなら、早期に問題に気付ける、というのはあるかもしれませんが、それでも手戻りが多ければ、イテレーションはうまく回らなくなるでしょう。


そのような状況に対し、質問表(Q&A表)を分析すると、プロジェクトの傾向が良く分かると感じ出しています。

現在、こんな感じで、質問表の分析を行っています。


発生件数(New)/解決件数(Close)+未解決件数(Open)

ここから分かるのは、以下のような傾向です。

  • 設計工程の開始段階で、質問が挙がらないようなプロジェクトは、仕様がきちんと理解されていないリスクがある。理解しているのではなく、理解できていないから質問が出てこない、という状況(大抵はそう)。
  • 試験工程で、仕様漏れや仕様誤解の検出に気付きやすい。


平均滞留時間/平均遅延時間

ここから分かるのは、以下のような傾向です。

  • プロジェクトがうまく回っているかどうかが分かる。滞留時間/遅延時間が高い値になる、ということは、プロジェクトが、うまくマネジメントできていない状況である。

このようなメトリクスを分析していて感じたのは、以下のようなメリット。

  • 質問は、工程の最初で出てくる分、問題に早く気付きやすい。
  • 質問は、普通に開発作業を進めていけば出るモノなので、集計方法さえ確立しておけば、負担はあまりない。
  • 質問の多過ぎる機能/少な過ぎる機能を、重点的にレビューすると効果も高い。


ソフトウェア開発の可視化をテーマとして活動している「StagEプロジェクト」でも、同様の研究を行っているらしい。

可視化の仕方は違いますが、コンセプトは近いように思います。


質問表のメトリクス分析は手軽に行えますが、プロジェクトの(特に上流での)品質状況・進捗状況を把握するためには、効果が高いモノだと感じます。

質問表の管理は、Excelでも可能ですが、チケット管理システムを使うと、質問のやり取り回数なども分かって、より有効な分析ができます。