PMOとは、個々のプロジェクトからは独立して設置されるプロジェクト管理に関する専門部署です。
プロジェクト管理業務をプロジェクトマネージャー任せにせず、全社的に取り組むことでプロジェクトの質向上や平準化を図ります。
並行していくつものプロジェクトが進行するようなSIerやシステム開発会社、情報子会社に、PMOはよく設置されます。
プロジェクト管理手法の標準化、ナレッジの共有や普及、実施中のプロジェクトの管理業務支援、プロジェクト間のリソース調整などを行います。
このようにPMOの役割は様々ですが、役割のひとつに「品質管理」があります。
最近では、品質管理に特化した役割を担うQMO（Quality Management Officer）を設置する企業も出てきています。
今回は、この「品質管理」について、取り上げたいと思います。
トラブルの原因は、品質管理？
都内のSIer Ｓ社で働くプロジェクトマネージャー田中君。
今期の組織変更で、突如、PMOに任命された。
「プロジェクトのトラブルが、なかなか減らない。納期遅延・工数オーバー・リリース後のトラブルや手戻りが頻発している。そこで、田中君に全社的なプロジェクト管理の改善をしていってほしいと、前部署の上司から経緯を伝えられた。
Ｓ社では、プロジェクト管理の標準化や進捗・工数などプロジェクト情報の見える化は、すでに全社的にプロジェクト管理ツールを導入し浸透しつつある。
「どこが課題なのだろう？」
田中君自身、複数のプロジェクトを回してきた経験から、プロジェクト管理のことはなんとなくわかっている。
「どこから手をつけていけばいいのだろう？」
田中君は、まずは完了プロジェクトの分析をしてみることにした。
プロジェクト管理ツールを開く。
自分のアカウントにPMOの権限が付与されており、今まで見られなかったプロジェクトの状況もすべて見られるようになっている。
「さすがPMO。全プロジェクト情報が見られるのはなかなかできない経験。わくわくする」
納期遅延・工数オーバー・リリース後のトラブルや手戻りの原因を確認するため、完了プロジェクトに絞り、問題のあったプロジェクトの状況をひとつひとつ確認していく。
数時間かけて確認した結果、問題プロジェクトの特徴がいくつか見つかった。
＜田中君が問題プロジェクトを確認して見つけた特徴＞
- テスト工数が膨れ上がっているプロジェクトがいくつかあった
- リリース前に追加テストが複数回行われているプロジェクトがあった
- リリース後に修正作業を何度もしているプロジェクトがあった
- 問題プロジェクトの振り返りの内容は精神論なコメントが多い
これらの特徴から、トラブルの原因の多くに『品質管理』が関わっていることがわかった。
- 追加テストや修正作業で、納期遅延や工数オーバーが発生していた。
- リリース後に致命的なバグが見つかり、改修作業に追われていた。
ある程度プロジェクト管理手法が定着しつつあるＳ社が次に取り組むべき課題は、『品質管理』であることがわかった。
「今日はここまで。あとは明日にしよう」
品質管理の問題点を考察するも・・・
そして、翌日。
次に、完了プロジェクトの『品質管理』について、さらに深掘りしていくことにした。
「追加テストや修正作業が発生しているのはなぜだろう？」
「リリース後に致命的なバグが見つかってしまっているのはなぜだろう？」
「テストに問題があるのか？」
そこで、テスト管理とバグ管理を確認してみる。
テストの計画と実績を確認していくと、計画に対してテストも順調に実施されているものがほとんど。バグも計画通りに、ある程度検出されている。
次に、信頼度成長曲線も確認してみる。
それっぽい曲線が描かれているプロジェクトが結構あった。
テスト初期段階にバグを多く検出でき、テスト終盤ではバグがあまり見つからず、品質が安定してきていることがわかる。
特にテストで問題を発見することができない。
「テストの進め方とバグの検出には問題ないか……」
「では、仕様書に問題があるのか？もしかして、レビューがきちんとされていないとか？」
仕様書のレビュー結果を確認してみる。
確認した結果、レビュー会もきちんと開催されており、指摘もそれなりにされているようだ。
「レビューも、会社標準のプロセスに則って実施されており、問題ないか……」
「では、リリース後に致命的な不具合検出。これは、出荷判定に問題があるのか？」
プロジェクトの出荷判定結果を確認してみる。
一部のプロジェクトで漏れはあったものの、ほとんどのプロジェクトが会社標準の出荷判定チェックリストにチェックを入れて判定していることがわかった。
リリース後に致命的な不具合が検出されたプロジェクトも出荷判定チェックリストはきちんとチェックし判定されていた。
丸１日かけて確認した結果、自社の『品質管理』の標準プロセスは、ほぼどのプロジェクトも実施されていることがわかった。
プロジェクト管理手法は『品質管理』についても、全社に浸透しつつあることはわかった。
では、『品質管理』が浸透しつつある中で、なぜこのような『品質問題』がいくつも起こっているのか？
行き詰まった田中君は、友人でソフトウェア品質に詳しい佐藤君にアドバイスをもらうことにした。
佐藤君は、テスト専門会社に在籍し、複数の企業に対して品質コンサルティングを実施している。
PMOにとって大事なのは、ベースライン
週末、駅前で落ち合い、近くの飲食店へ。
軽く乾杯し、まずはお互いの近況を軽く報告しあう。
そして、本題へ。
今期からPMOに任命。トラブルがいくつかあり、プロジェクト管理手法を見直していること。
分析した結果、『品質管理』に問題ありと踏む。
『品質管理』に関するいくつものメトリクスを確認するも問題が見つけられず行き詰まると説明した。
田中君の話を一通り聞いた佐藤君、ふむふむとうなずいた上で一言。
佐藤君：「数字は大事。でも、数字に惑わされないこと」
田中君：「？ どういうこと？」
佐藤君：「メトリクス、たとえば信頼度成長曲線、バグ見積など定量的にはOK。でも、出荷後30分でクリティカルバグが見つかりクレームなんてことも」
佐藤君の言葉に、田中君ドキッ！
田中君：「まさにそんな感じ……」
佐藤君：「品質管理における定量管理でこのツールでやっておけばよいというものはない。各ツールは一長一短あるし。それよりも大事なのは、基準を決めること。」
田中君：「基準？テストケース数とか？」
佐藤君：「テストケース数も指標にはなるけど、数だけやれば品質が上がるかと言えば否。テストカバレッジやテストマップとか、どの機能にどれだけどのようなテストをしたかということも大事」
田中君：「単にテストの総数だけじゃないんだね。会社の基準としてこれくらいのシステムならこれくらいのテストをこれくらいの期間で実施してこれくらいのバグ検出をという指標はあるけど、カバレッジとかまであまり意識できてないな。」
佐藤君：「田中君はPMOだろ。PMOにまず一番に必要なのは尺度を作ること。各プロセスでの指標値。ものさしがないと外から測れないよね？基準がないと判断できない。なのでまず管理するためのベースラインを作ること。そして下回っていないか確認することが重要だよ」
田中君：「ベースラインは会社の標準プロセスとしてあるよ」
佐藤君：「でも、ベースラインがあってもトラブルが多いということは、ベースラインから判断してコントロールできていないか、ベースラインを無視してプロジェクトが進んでいるか、そもそもベースラインとして何かが足りていないかのどれかじゃないかな？」
田中君：「確かに……それでいうと、ベースラインとして何か足りていないのかも……」
佐藤君：「問題にはかならず原因がある。その問題を発生させないためにはどのようにすればよいのか、再発防止策を講じて、標準プロセスに乗せるのもPMOのひとつの役割だよ。問題プロジェクトのメンバーとなぜなぜ分析とかしてみたらどうかな？ただし、今後は意識してとか気合いいれてなどの精神論や根性論を結果にしては絶対ダメだよ」
田中君：「まずは原因とそれに対する対策を考えてみるよ」
佐藤君：「折角の機会なので、あともうひとつPMOとしての役割を参考にアドバイスしておくよ。PMOはベースライン・指標値を作って、それをもとに各プロジェクトをモニタリングする。アラートを見つけたらトラブルを確認し大事に至る前にアドバイス。ただし、尻を叩くだけじゃなく、メンバーがフラフラなくらい残業時間過多な状態だったら時として上にも掛け合う。このようにして確認・コントロールしていくのがPMOの役割だよ」
田中君：「大変参考になったよ。ありがとう。PMOは奥深いね。会社のトラブルが減らせるように、ひとつひとつ取り組んでみるよ」
品質管理のベースラインを見直す
佐藤君にアドバイスをもらい、一筋の光が見えてきた田中君。
翌日出社して早速完了プロジェクトを再確認。
問題は、テストカバレッジにあることが判明。
クリティカルバグを確認するためのテスト項目も、そもそも存在していなかった。
それは、異常系テストと呼ばれる異常値を入力したり、異常操作をしたりするテストで、普通に仕様通りの動きをしているかを確認するテストでは検出できないバグであった。
現行の品質管理プロセスでは、テストケース数とバグ検出数の指標しかなく、テスト設計やテストケース作成についてはプロジェクト毎に大きなバラつきがあることが判明。
プロジェクトによっては、テストケース数を稼ぐために同じようなテストを大量に作っているプロジェクトも判明した。
そこで、プロジェクト毎に品質目標を定め、必要なテストを明文化するためにテスト計画書を作成するよう改善した。テスト計画のレビューはPMOも参加するようにした。
また、どの機能にどのテストを実施するかのテストマップを作るようになり、テストの俯瞰もできるように改善した。さらに、テストケース作成のポイントやレビューの仕方などを社内教育で実施するようにした。
このように新たな品質管理の指標・ベースラインを策定し、全プロジェクトに与え、トラブル削減に向けて様子を見ていくことにした。
また、問題が発生したら原因分析をし、新たな指標を検討していこう。
それにしても、品質管理は奥が深い。
田中君のPMO道はこれからも続く……。
OBPMでできる品質管理
と、こんなPMOの品質管理指標から判断していくために、弊社の統合型プロジェクト管理ツール「SI Object Browser PM」にも便利な機能があるので参考にいくつか紹介していきます。
１．プロジェクト進捗報告一覧
現在進行中のプロジェクトのQCDが一覧で確認できます。
アラートもひと目で確認できるので、即座に確認・フォローが可能です。
２．レビュー管理・チェックリスト
会社標準の品質基準をドメインマスタに登録しておけます。
これを呼び出すことで、全プロジェクトに適用が可能です。
実施漏れも一目でわかるので、PMOにはうれしい機能です。
３．障害管理
障害情報をプロジェクトに紐づけて一元管理できます。
どの機能にどの工程でどのような分類のどのレベルのバグが見つかったか登録できます。
また、バグをクローズする際に原因も一緒に登録するため、バグ分析ができます。
４．品質分析
テスト管理・障害管理で蓄積した情報をもとに、パレート図、バグ収束曲線など品質分析結果を確認できます。
どの分類でバグが多いか、どの機能でバグが多いかなど確認ができ、次のプロセス改善につなげていけます。
５．障害横串検索
プロジェクト横断で障害を検索することができます。
キーワードで絞り込みを行い、過去に似たような障害が発生していないか確認できます。
修正方法などナレッジ共有にもお使いいただけます。
RedmineやBacklogなどのチケット管理ツールでバグ管理をしていると、情報だけは溜まっていくけど集計や分析がなかなかできないという声をたくさんお聞きしています。
OBPMだとプロジェクトに紐づいて情報を一元管理でき、自動で品質分析レポートができるので、お忙しいPMOの皆さんにもお役立ちできると考えています。
ご興味ある方、是非一度OBPMをご覧になってください。
またPMOについて詳しい資料もご用意していますので、こちらもぜひご活用ください。
