PMPの資格の勉強をすると、会社の規則とかプロセスがPMPを真似していることに気付きます。
しかし、PMPの中にはあるけど会社のプロセスにないものがいくつかあります。
先人が取捨選択して役に立ちそうなものを制度化したと思いますので、PMPにあっても作っていないものがあっても何も不思議ではありません。
「要件トレーサビリティマトリクス」というのは、私の会社の規則では義務化されていませんでしたが、使ってみてとても役立ちましたので紹介します。
PMP
PMP(Project Management Professional)という資格があります。
プロジェクトマネージメントの過去から伝わるノウハウ集であるPMBOKから出題される、プロジェクトマネジメントの資格の最高峰です。
実務経験が必須ですので学生でとるのは難しいですが、会社員として働く中で勉強時間を確保して勉強する資格としては、最難関です。私もとてもシンドイ思いをしてとりました。
例えば、要件定義、スコープ記述、リスク管理、変更管理などPMBOKに記述されている重要なものになります。
会社やプロジェクトは、多かれ少なかれPMPの影響を受けていますので、作らなければいけない資料がPMBOKに書かれているものが多いです。
少なくとも、私がいたプロジェクトでは9割くらいの書類がPMBOK由来でした。
PMBOKに書いてあるもの全てを作ることはPMBOKそのものを想定していなくて、プロジェクトごとに作るものを選べばいいよ、と書いてあります。
その中で「要件トレーサビリティマトリクス」というのがあります。私はPMPの勉強をするまで、知りませんでした。
しかし、とてもとても役立つものだと思っていますので紹介します。
要件トレーサビリティマトリクスとは
「要件トレーサビリティマトリクス」は、「要件」と「工程」を縦、横にとった表のことです。
| 外部仕様 | 内部仕様 | コーディング | 単体テスト | システムテスト | |
| 要件1 | |||||
| 要件2 | |||||
こういう形、とだけ決まっているだけです。要件定義書がない場合は、製品仕様書の章を並べたりします。
私は、〇×をつける簡単な表を作りますが、
プロジェクトによっては、仕様書であれば章番号、テストであればPCL番号を書くなどの運用であったり、どういうことを書いたと細かに書く場合もあります。
まず、私の会社では要件トレーサビリティマトリクスを作る規則はなく、PMPの勉強をしたときに初めてその存在を知りました。
第一印象は「当たり前のことを書くだけだから不要かなぁ」と思っていました。
しかし、実際にプロジェクトでお試しで作ってみて必ず作ろうと思う資料になっています。
要件トレーサビリティマトリクスが役に立つのはいつか？
要件トレーサビリティマトリクスが示すものは、製品が含まなければならないこと(=要件)を全て含んでいるかどうかをチェックします。
設計者は常に製品のことを考えているため、全工程で要件を網羅しているつもりです。なので不要と考えていました。
以下のような場面で役に立ちます。
- 要件が多すぎる
- 品質見解、完了報告を書く
- QAやお客を黙らせる
要件が多すぎる
マイクロマネージメントというか、要件を事細かに作るプロジェクトがたまにあります。このとき、要件の数が増大します。
あるいは、大プロジェクトのため単純に要件が多いというときがあります。
要件の数が一人のPMの頭のキャパシティを超える場合必要です。
担当者間のコミュニケーション
仕様書を書く、コーディングする、テスト項目を作る、が同一人物とは限りません。
担当者がちゃんと仕事をし終えたかをチェックするとき有効です。
悪意をもって項目を除く人はあまりいませんが、人間にはウッカリがつきものです。
品質見解、完了報告を書く
不良が多すぎたり、少なすぎたりしたとき、品質見解を書かなければなりません。
まぁ、分析はしっかりやるべきとは思いますが、最後の締めの文句として、
「要件トレーサビリティマトリクスを作成し要件を網羅している」
という文句はとても強力です。この一文を書くためだけに作ると言ってもいいです。
>>> 【完了報告書の書き方】工程完了報告書、テスト完了報告書、品質見解書
QAやお客を黙らせる
網羅しているテストをしているかとか仕様が網羅しているか、と何を求めているか分からない問を発する馬鹿なQAなどを黙らせるのに役立ちます。
「網羅」というバカの一つ覚えみたいな言葉、意味わかって言っているんでしょうか？
「要件トレーサビリティマトリクス」は、そもそも要件を網羅しているかを確認する表です。
これ以上に網羅を表す表はありません。QAや顧客が意味なくうるさいプロジェクトでは率先して作っていきましょう。
まとめ
要件トレーサビリティマトリクスを紹介しました。
コメント