後で後悔しないための品質マネジメント：プロジェクトマネジメントスキル 実践養成講座（5）（1/2 ページ）

[スカイライトコンサルティング]

品質マネジメントで何を想像するか

　前回（「第4回 コストマネジメントは、「時は金なり」でうまくいく」）は、コストマネジメントについて解説した。これに1点だけ補足しておきたい。コストマネジメントは、予算がそれほど逼迫（ひっぱく）していない（逼迫していることが表面化していない）場合は、おろそかになりがちなので注意する必要がある。

　例えば、プロジェクト前半で少々の支出超過や進ちょくの遅れは、後半でばん回可能と考えていないだろうか。支出超過や進ちょくの遅れの原因が明らかになっており、具体的かつ合理的なばん回策があればよいが、根拠もなく何とかなると楽観的にとらえていたり、最後は根性で何とかするしかないと考えていると至極危険である。

　これはコストだけでなく作業進ちょくにもいえるが、それまで遅れていたものが、翌週から急に計画どおりの支出スピードや作業進ちょくに戻るだろうか。さらにいえば遅れを取り戻すためには、当初計画どおりに戻すだけではなく、それ以上のパフォーマンスが必要なのである。当然、計画からの超過や遅れが大きければ大きいほど、ばん回は困難になる。支出超過や作業超過の兆候が見られたら甘く見ず早めに対処することを忘れないようにしたい。

　さて今回は、プロジェクトにおける品質マネジメントについて解説する。

　品質マネジメントと聞くと具体的に何を想像するだろうか。現場を知っている読者の意見としては、数多くの文書作成に始まり、承認や変更履歴の管理など面倒なことが増えるだけ、というものが多いだろう。また、これまで解説してきたスケジュールやコストマネジメントと比較するとイメージしづらいかもしれないし、実際のプロジェクトにおいてもスケジュールやコストほど意識して品質マネジメントを実施しているプロジェクトは少ないのではないだろうか。これは「品質というものが時間やお金と異なり目に見えにくいこと」に加えて、「品質マネジメントということを意識して行わずともプロジェクトは取りあえず先に進める」ことに起因している。

　その一方で、品質が低ければ顧客は決して満足しない。即ち、品質は顧客の満足の充足に直結する要素である。顧客の満足なしにプロジェクトの成功はあり得ないのだから、プロジェクトマネージャは品質マネジメントがスケジュールやコストと同様に重要であることを認識して、プロジェクト期間を通じて品質向上に取り組んでいく必要があることを前書きとしておく。

　では、まずPMBOKにおける品質マネジメントの定義を確認することにしよう。

プロジェクト品質マネジメントとは

　PMBOKでは、プロジェクトにおける品質マネジメントとは、プロジェクトのニーズを確実に満足させるためのプロセスであり、品質方針、目標および責任を定め、それら達成するために、品質計画、品質保証、品質管理、および、品質改善を実施していくことと定義している。また、PMBOKの基本的なアプローチは、品質管理の国際標準モデルであるISO9001などの規格やガイドラインとの整合性を図っている。品質マネジメントのプロセスと主要成果物を下表に整理しておく。

品質マネジメント のプロセス	主要成果物	説明
品質計画	品質マネジメント計画書 など	プロジェクトの計画プロセスにおいて品質を保証し改善してくための組織構造、責任、手順、プロセス、および、経営資源を定義したもの
品質保証	品質改善	プロジェクトの実行プロセスにおいて、プロジェクトの成果物とプロセスが適切な品質かどうかを保証するために行う活動。例）品質監査など
品質管理	品質改善 （検査に対する）受け入れの決定 プロセスの調整など	プロジェクトのコントロールプロセスにおいて、プロジェクトのあらゆる活動結果が適正かどうかを判断するために、結果をモニタし問題があれば必要に応じて対応していくこと。
表1　PMBOKにおける品質マネジメント

　PMBOKでは上記のように解説しているが、少々概念的な説明なので、理解を促進するために若干、補足しておく。まず、品質マネジメントの品質とはそもそも何か。品質管理の業務に携われた方であれば、一度は考えたことのあるテーマではないだろうか。この点をまず解説しよう。

　プロジェクトにおける品質とは、成果物が要求と一致しており使用に適していることと定義され、この「成果物が要求と一致すること」に品質マネジメントのヒントが隠されている。

　1つ目のヒントは、「要求をすべて把握して初めてその要求に一致するものを作れること」、もう1つのヒントは「要求と違うものをいくら作ってもそれは品質と無関係なこと」である。このあたりの話は、実際のケースを交えてさらに掘り下げて紹介していきたい。

　まず品質マネジメントについて考えてみよう。これは要求と一致した使用に適している成果物を作ることを保証するために、プロジェクトの計画を立て、その進ちょくを随時モニタし、問題があれば改善していくことである。ここで理解が必要なことは、品質マネジメントは、成果物自体だけでなくプロジェクトにおけるさまざまなプロセスも対象となることである。例えば、バグをつぶすことでも品質は改善されるが、発見されたバグの原因と対処法をほかのチームと共有し、ほかのチームでの問題を事前に回避できるようにバグ管理フローを改善することでも品質は改善する。

　「正しい結果は正しいプロセスから」生まれるのである。覚えておいてもよい言葉ではないだろうか。

　それでは、プロジェクトにおける品質マネジメントの勘所についてケーススタディを通じて紹介することにしよう。

理解の一致は品質確保の第一歩

　ここに要件定義フェイズにあるシステム開発プロジェクトが2つある。

　2つのプロジェクトはともに、これまで顧客へのインタビューや現状業務とシステムの調査を実施してきた。その後、内部で要求仕様を整理し今日は顧客と機能に関する要求仕様の確認会を行っている。そのミーティングに参加している2人のマネージャの様子をのぞいてみることにしよう。

矢見雲マネージャの発言

（一通り要求仕様をまとめた資料の説明を終えたところで……）

「今回の新システムへの要件は、以上と認識しておりますがよろしいでしょうか」

顧客の発言

「そうですね。新システムへの要件は大体大丈夫と思います」（うーむ。実は資料も技術的な言葉が多くてよく分からなかったが、こちらがいっていたことは大体入っていそうだったのでまあ大丈夫だろう）

矢見雲マネージャの発言

「ありがとうございます。では、今回の資料にご承認印を押していただいてお戻しください」（よし、これで一段落だな。後はこれを作っていくだけだ）

出来杉マネージャの発言

（一通り要求仕様をまとめた資料の説明を終えたところで……）

「今回の新システムへの要件は、以上と認識しておりますがよろしいでしょうか」

顧客の発言

「資料も技術的な用語を理解しやすく表現してもらっていたし、インタビューのときなどにもこちらが気付かなかった点までケアしていただいて非常に満足しています。新システムへの要件はこれで大丈夫です」

出来杉マネージャの発言

「ありがとうございます。では今回の資料にご承認印を押していただいてお戻しください」（よし、これで一段落だが、設計や開発に進むにつれて具体的なイメージがわけば追加要件が出てくるかもしれない。そのときの話もしておく必要があるな）

「これでいったん要件を凍結して、今回の要件でプロジェクトを進めていきます。しかし、今後やむを得ず要件に追加や変更が発生する可能性もあるかと思います。その場合どう対処していくかについてプロジェクトでのルールを決めておきたいと思います。こちらでフローなどの案を考えますので、また検討のお時間をください」

顧客の発言

「分かった。よろしく頼むよ」

　品質マネジメントは、開発やテストフェイズだけで行うものではなく、要件定義や基本設計などの上流フェイズでも意識して行うものである。

　ここでは上流フェイズの例として要件定義フェイズを挙げた。先に品質とは成果物と要求が一致していることと説明したが、顧客と双方で要求自体を正しく理解し合意していなければ、要求に合った成果物を作ることは不可能である。顧客の要求を正しく理解することが品質マネジメントの第一歩である。

　ではどうすれば顧客の要求を正しく理解することに到達できるのだろうか。

　1つは「こちらの理解を正しく相手に伝える」ことである。顧客が具体的なイメージを持たずに理解しないまま先に進むことは極めて危険である。上の矢見雲マネージャの例では、顧客が“資料も技術的な言葉が多くてよく分からなかった”と感じており正しく伝わっていない。これに対して出来杉マネージャの例では、“資料も技術的な用語を理解しやすく表現してもらっていた”と相手の言葉に合わせて資料を作成することで、顧客の理解を促進させている。「同じ意味の言葉でも相手の組織の言葉を用いる」もしくは、「専門的用語は平易な表現を用いる。または説明を付加する」など、相互に正しく理解できる文書を作ること。ビジネスの基本ではあるが、プロジェクトメンバーの中には分かりやすい文書を作成するのが苦手な人がいる可能性もあるのでマネージャとしては十分注意したい。

　また、よくいわれることであるが、要件や仕様の文書への記述があいまいにならないようにしたい。顧客との検討で説明や議論した後、お互いに何となく分かった気になっていても、後続フェイズで再度要件定義のやり直しを強いられるというケースはよくある。若干手間はかかるかもしれないが、この段階で顧客と相互に明確に理解しておかないと、後工程で問題が発覚した場合の影響は比べ物にならないくらい大きくなるので気を付けたい。