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

» 2004年10月13日 00時00分公開

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

一を聞いて十を知った気になってはいけない

　顧客の要求を正しく理解するためのもう1つのポイントは、「顧客の隠れた要求を引き出すこと」である。顧客はすべての要件をいってくれるとは限らない。これは意図していわないのではなく、以下の理由によるものと考えられる。

（1）そもそも要件を知らない
（2）要件に気付かない
（3）いわなくても分かっているだろうと思っている

　これら3つの場合についてもう少し掘り下げてみることにしよう。

（1）そもそも要件を知らない

　顧客担当者にはプロジェクトが対象とする業務や既存システムに精通していることが求められる。しかし実際には、業務やシステムの複雑化、人材の流動化により、業務やシステムに精通した要員をプロジェクトにアサインできないことも多い。また、要件といってもプロジェクトによってその範囲は異なり、業務要件に加えてパフォーマンス要件やハードウェアなどのインフラ要件、セキュリティ要件、データ移行要件、保守・運用要件など多岐にわたることもある。そのため、顧客担当者側ですべての要件を把握し切れて位いないことも実際にはよくある。

　このような背景を踏まえて、顧客担当者が把握していないことについては、エンドユーザーや情報システム部などのプロジェクト外部の人であってもしかるべき人をプロジェクトに巻き込んでいくことが必要である。また、受注側で同業種や似たような構成のシステム構築の経験があれば、その経験をベースに顧客に指摘・提案することも必要である。

（2）要件に気付かない

　要件定義のフェイズでは、どうしても主要業務や重要テーマの検討が中心となり、例外業務やイレギュラーパターンにまで議論や検討が行きつかず、結果として要件として出てこないプロジェクトも多いのではないだろうか。要件の検討段階において、このような例外業務などにも重要要件やシステム的に影響の大きい要件が隠れていないか十分に留意する必要がある。また、このフェイズでは紙や言葉のやりとりが中心となるため、具体的な業務イメージが想像しにくいことも顧客が要件に気付かないことに影響しているであろう。この点については、作成する資料を画面イメージに近いものにするなど、顧客に具体的なイメージがわくものとすることを意識したい。

（3）いわなくても分かっているだろうと思っている

　顧客の組織やその業界では当然のこと、または、現行業務の範囲内のことや既存システムで実装されている機能については、「伝えてなくても分かってくれているだろう→紙には書いていないが、当然実装されているであろう」と顧客側が思い込んでいることもよくあるケースである。このことを防ぐためには、検討段階でのコミュニケーションを通じて齟齬（そご）がないことを確認するとともに、それを見ればプロジェクトで実現する要件全体が確認できる資料、いい換えれば要件全体を可視化する資料を準備しておくことが有効である。

　顧客がすべての要件をいうとは限らないことについては、顧客側にも問題のあるケースもあるだろう。矢見雲マネージャなら「そんなのいってくれなきゃ分からない。いわなかった顧客が悪い」とか、「いわれたことだけやればよくって、こちらから余分な仕事を増やさなくていいのだよ」と考えるかもしれない。しかし、これらの隠れた要件は「いずれ表面化する」のである。しかも多くはテスト後半やユーザートレーニングなどのプロジェクトの納期も押し迫った時点でだ。この時点で発覚したらどうなるか。いうまでもなくそのようなプロジェクトには大変な修羅場が待ち受けているであろう。

火事は起こる前に防ぐ

　上記で例示したプロジェクトはその後設計／開発フェイズへと進もうとしている。あなたの企業では社内にプロジェクトの品質向上を目的に品質管理を専門に担当する部署があり、その部署により内部品質監査が行われようとしている。その席での2人のマネージャの品質管理についての発言をのぞいてみることにしよう。

監査官の発言

「あなたのプロジェクトでは、どのように品質を担保しようと考えていますか」

矢見雲マネージャの発言

「やっぱりテストでバグをつぶすしかないですよ。そのためにテストスケジュールは長めにとってありますし、いろんな意地悪テストも行うつもりです」

監査官の発言

「あなたのプロジェクトでは、どのように品質を担保しようと考えていますか」

出来杉マネージャの発言

「設計やプログラミングの段階でバグが混入する可能性を極力少なくしようと考えています。そのために若い技術者でも理解しやすいような設計・コーディング標準を作成して展開するつもりです。加えてそれら標準が守られていることを確認するためにチェックシートを準備して各メンバーには設計や開発が終わったときに確認してもらいます」

　ここでは、設計／開発フェイズにおいてどのように品質を確保していくかについて考えてみたい。矢見雲マネージャは、テストにより品質を確保すると考えているが、テストとは品質が満たされていることを確認するための手段である。テストで品質を確保しようとすると、設計や要件定義フェイズへ、または、システムテストから単体テストへなど、どうしても前工程の作業に手戻りが発生し、必要となる工数は必然的に大きくなってしまう。そして、テストフェイズまでくると納期も迫っているので、収拾できない事態につながるケースも珍しくない。

　重要なのは、品質の確保は問題のあるものをいかに発見するかではなく、いかに問題が起こらないように作り込むかということである。

　出来杉マネージャは、設計や開発標準を展開して成果物の品質を均一化することで、問題のある成果物ができるのを事前に防ごうとしているが、実際にどうするかは、当然個々の組織やプロジェクトに応じて異なってくる。

　例えば、小規模のプロジェクトで組織もメンバーも同意するならXP（eXtreme Programming）開発手法を取り入れ、テストファーストやペアプログラミングを採用することで品質を向上できるかもしれない。また、メンバーの動機づけやプロジェクトの作業環境やプロジェクトの雰囲気づくりでメンバーの作業品質が大きく影響を与えるかもしれない。

　このように、プロジェクトマネージャはいかに問題なく作り込むかということをプロジェクトの開始から終了まで常に意識してアクションを取り続けていかなくてはならないのである。

　ここで、品質の確保の手段としてよくいわれるレビューについても触れておこう。

　レビューもテストと本質的には同様、品質が満たされているかどうか確認するための手段であり、品質を確保するためのベストな手段ではない。しかしながら、問題なく作り込む最善の努力をしたとしても人間が行う以上、問題が生じることは避けられない。その場合は、いかに早く問題を発見し対処できるか、つまりは、次の工程に移る前にいかに問題をつぶせるかが重要になる。設計時点での設計書レビュー、コーディング段階でのソースコードレビューなど、どれもテストより早い段階で問題を発見できるので、その意味においては有効な手段といえよう。

月夜にちょうちんは不要である

　先の内部品質監査は、まだ続いているようだ。もう少しのぞいてみることにしよう。

監査官の発言

「開発対象の一覧を見ていると当初の要件定義の成果物には含まれていなかった機能やレポートなどがいくつか見られますが、これらは何ですか」

矢見雲マネージャの発言

「それらはシステムとして品質を高めるために、われわれが考えて便利な機能やレポートを開発に盛り込んだのですよ。おまけみたいなものですがきっと顧客も喜んでくれますよ」

監査官の発言

「ほかのプロジェクトでは、顧客のためにサービス的な機能を盛り込むとしているところもあるようですが、あなたのプロジェクトでは？」

出来杉マネージャの発言

「それは品質と無関係だと考えます。顧客の要求と一致したものをきっちりと作り上げることが重要なのです」

　ここでは品質の高いシステムとは何かについて考えてみたい。矢見雲マネージャは、

　「システムとして品質を高めるために、われわれが考えて便利な機能やレポートを開発に盛り込んだ」

と述べている。これは品質を高めていることになるのだろうか？

　答えはNoである。このような機能に限って実装が困難であることが後から判明して苦労したことのある方はいないだろうか。こうなってしまっては本末転倒だ。今回の記事の前半でも触れたが、顧客が求めていることは、要求と一致したものであり、それ以上でもそれ以下でもない。このことはPMBOKでも余計なことを意味する“金メッキ“（Gold Plating）として扱われており、避けるべきとものとされている。

　また、品質とグレードの違いについても理解しておく必要があるとしている。低品質は問題だが、低グレードは必ずしも問題とは限らないのである。これは、パソコンやテレビをイメージすると理解しやすいだろう。顧客は必ずしも高機能なものを要求しているとは限らず、必要最小限の機能やスペックで十分なこともある。しかし、すぐに壊れてしまっては問題である。

　最後に再度、確認しておく。「品質とは成果物が要求と一致しており、使用に適していること」である。

今回のまとめ

プロジェクトに求められる品質とは、成果物が要求と一致しており使用に適していることで、それ以上でもそれ以下でもない。
品質マネジメントは、成果物自体だけでなくプロジェクトにおけるさまざまなプロセスも対象となる。
要件定義フェイズでは、顧客の隠れた要求を引き出し、相互に正しく理解しあうこと。
設計／開発フェイズでは、問題なく成果物を作り込むことに注力すること。
テストでまとめて問題を解消しようとするなど問題を後の工程に持ち越さず、そのフェイズの問題はそのフェイズ内で発見し解消すること。

著者プロフィール

杦岡充宏（すぎおかみつひろ）

スカイライトコンサルティングシニアマネジャー。米国PMI認定PMP。関西学院大学商学部卒業後、アンダーセンコンサルティング（現アクセンチュア）を経て現職。製造業や流通業のCRM領域において、業務改革やシステム構築のPM（プロジェクトマネジメント）の実績多数。特に大規模かつ複雑な案件を得意とする。外部からの依頼に基づき、プロジェクトの困難な状況の立て直しにも従事、PMの重要性を痛感。現在は、同社においてPMの活動そのものをコンサルティングの対象とするサービスを展開している。

「次回」へ

「プロジェクトマネジメントスキル実践養成講座」バックナンバー