 |
プロセス１１：プロジェクト品質マネジメント |
◆復習 アクティビティ１で、プロジェクト品質マネジメントの指標として以下の４つがあることを説明した。 （１）プロダクトの品質 （２）プロセスの改善度 （３）メンバー個人のパフォーマンス （４）顧客満足度 今回は、プロジェクトの立上げプロセスにおいて、それぞれの視点から何をすればよいかを説明する。立上げは、品質の作りこみの基礎になるプロセスである。この段階でしっかりとした「方針」を策定できなければ、計画プロセスで策定する品質計画や、コントロールプロセスで行う品質保証は砂上の楼閣となる。 ◆プロダクトの品質 プロダクトの品質マネジメントとしてプロジェクト立上げで行うべきことは、まず、品質方針を決めることである。方針とは、例えば、潜在的バグ数を極力減らすだとか、あるいは、顧客要求水準以上の品質実現については納期を優先するといった、品質管理に関する大枠の方針である。 品質方針は、計画に渡されて、その方針に沿った形で実際の品質計画が立案されるので、そのことを踏まえて方針は策定する。つまり、極端に抽象的であると、計画は多様になり、結果として品質レベルが徹底されないといったことが発生する。逆に、数値化するなどあまり詳細に方針を決めると、計画が非現実的なものになる。このバランスが重要である。 さらに、方針に対しては、常にリスクを考えておく必要がある。現実問題として、ＩＳＯの導入企業では、品質方針は既定であることが多い。このような場合には、リスクを十分に検討することによって、プロジェクトの性格による品質マネジメントの特殊性を回避（あるいは緩和）することが肝要である。 ◆プロセス改善 プロセスの改善として行うべきことは、プロセスの客観的評価の手段を確保することである。言い換えると、プロセスの計測の準備をすることである。 プロセスの計測は一般的にはコストが伴う。計測項目は、不適合件数だけではなく、プロセス内での不適合の推移、品質向上に費やした時間、不適合に至った経緯・原因など、改善をするためには、少しでも多くの計測データがあった方がよい。しかし、計測項目の中には、担当者自ら計測を行わなくてはならないものが多く、その分、本来のプロジェクト作業への負担になる。 そこで、明確なプロセス管理方針を作成し、その管理方針に合意し、コストの発生の必要性の認識を高め、計測を行い、プロセス改善につなげていく必要がある。特に、立上げ段階では「合意」し、自然に品質改善活動に取り組めることが重要である。 ◆個人のパフォーマンス 個人のパフォーマンス向上に対して立上げプロセスで行うべきことは、パフォーマンスの基盤になる「倫理意識」を徹底することである。プロセス改善（チームのパフォーマンス改善）についても同様な側面があるが、特に個人のパフォーマンスについては、計測値の改ざんが起こったり、あるいは、パフォーマンスアップのために見えない部分で手抜きをするといったことが見られる。 たとえば、システムインテグレーション（ＳＩ）で言えば、ドキュメントの品質を下げることにより、パフォーマンスを上げるということが日常的に行われている。このように検収作業が手薄になる部分が手抜きの標的になることが多い。 これを制度（ルール）の問題として捉えて、作業規約を策定して対策をするという考え方もあるが、作業規約はパフォーマンスにとって阻害要因になるので、別の次元で考えることが望ましい。その方法の一つに倫理規定を策定して、その既定を守ることにより、作業方法の自由度を確保しながら、上に述べたような問題の発生を防いでいくという方法が考えられる。 さらに、このように倫理規定を明確にすることは、顧客満足度を向上させる、リスクを低減させるという点でも効果がある。そんなに形式ばったものは必要ないが、 ・成果物は自らが検収者の立場になった場合にクレームが出ないようにする というように、違う立場から、自分の価値観で判断できるような定め方が効果的である。 二点目は、個人のパフォーマンス向上の優先度を明確にしておくことがあげられる。ここが難しいところで、個人のパフォーマンスの向上がチームのパフォーマンスによくない影響を与えることがある。例えば、意識の高いプロジェクトで、作業効率が向上し、品質レビューがボトルネックになることがよくある。品質レビューをプロジェクトの外部で行う場合には、手待ちが発生し、前倒しに作業を進め、手戻りが発生してしまうケースは意外と多いものだ。倫理性の問題だといえばそうなのだが、手待ちを発生させてプロジェクトをストップさせると、モチベーションの維持が難しくなる。 個別のパフォーマンス改善が悪いというのはなく、全体としてバランスできるように計画変更を行っていかなくてはならない。このために、個人のパフォーマンス改善のチームにおける取り扱い方針を明確にしておくことが望まれる。 ◆顧客満足 顧客満足の向上という点では、立上げプロセスが最も重要である。プロジェクトが計画レベルに入ってしまうと、顧客との関係ではコンフリクトの方が多くなる。 ＳＩを例にとって考えればよく分かるが、顧客（発注者）とプロジェクト（受注者）がまったく前提なしで対峙したときに、利害関係が対立しないのは不自然である。例えば、顧客は１円でも出費を抑えたいし、プロジェクトは１円でも多くの売上が欲しい。Ｗｉｎ−Ｗｉｎの関係というのは、基本的にはこのレベルではなく、何らかの前提がある中での関係である。例えば、顧客は自分たちのビジネスの利益が倍増する。 プロジェクトは十分に利益の出る金額で受注できる。これであれば、Ｗｉｎ−Ｗｉｎの関係になり得るのだが、ここでの前提は、顧客のビジネスの利益が倍増することである。 ということは、顧客満足はこの前提を実現しない限りないということだ。利益の倍増というのは一つの例であるが、要するに、プロジェクトの成果として顧客が何を望んでいるか、言い換えると顧客にとってのプロジェクトの目的は何かを明確にしない限り、顧客は満足しない。 ＳＩプロジェクトの場合、これと要求分析を混乱してはならない。要求とはシステムに対する要求であり、プロジェクトに対する要求ではない。例えば、こういう例を考えてみよう（実際にあった例）。 ある企業Ａ社（エンドユーザ）がまったく同じシステムを繰り返し作ることにした。一つは社内で、一つは顧客向けだ。まず、社内で検証して、次に顧客に展開するというシナリオを描いた。この場合、最初のプロジェクトでは、Ａ社の期待は早く作ることにあった。品質を多少犠牲にしてもよいので、早く作る。Ａ社としては３ヶ月で欲しかったが、随意契約で受注が決まっていたＳＩ企業Ｎ社は６ヶ月かかると言い張り、代わりにＡ社の要求に対して、品質の高いシステムを作った。ところが、次のフェーズの顧客向けの展開では、Ａ社は別のＳＩ企業に発注した。 この例は、プロジェクトへの要求とシステムへの要求が混乱している典型的な例だ。プロジェクトへの要求は本来、Ｓ社側のプロジェクトの立上げフェーズで明確にし、うまくプロジェクト計画の中に折り込んでいかなくてはならない。 まず、顧客の期待がどこにあるをはっきりさせることが重要である。ただ、顧客の期待は一つではない。当然、あれもこれもということで、複数の期待を持っている。ここが重要だ。その期待に優先度をつけていく必要がある。詳細はアクティビティ３で説明するが、例えば、トレードオフマトリクスといった方法がある。顧客の要望の中でコンフリクトを引き起こすものを洗い出し、トレードオフを定義していく方法である。 さらに、重要なことは、顧客の期待が一元化されているとは限らないことだ。これは仕様レベルでもよくあることだが、多くの場合、顧客の社内でも要求に対するトレードオフがあると考えておいた方がよい。例えば、顧客管理のシステムを作るときに営業は早くほしいと思うが、マーケティング部門は完成度の高いものをほしがるといった類のことだ。この点をきちんと認識しておかないと、とんでもない対応になることがある。このような混乱の解消のためにもトレードオフマトリクスの作成が効果的である。 （2004/04/08号より抜粋） ◎この前後のアクティビティをお読みになりたい方は、こちらからバックナンバーをご購入ください。 http://www.pmos.jp/honpo/professional.htm 以下のような内容です。 ■アクティビティ１：マネジメントプロセスとマネジメントポイント ■アクティビティ２：立上げにおける品質の作りこみ ■アクティビティ３：品質の計画と計画ツール ■アクティビティ４：品質コントロールとコントロールツール > 2004/04/01 アクティビティ１：マネジメントプロセスとマネジメントポイント ◆品質とは何か ◆プロジェクト品質とは何か？ ◆プロジェクト品質のポイント ◆マネジメントプロセスと品質マネジメント ◆品質とコスト > 2004/04/08 アクティビティ２：立上げにおける品質の作りこみ ◆復習 ◆プロダクトの品質 ◆プロセス改善 ◆個人のパフォーマンス ◆顧客満足 > 2004/04/15 アクティビティ３：品質の計画と計画ツール ◆計画プロセスの位置づけ ◆プロダクトの品質向上 ◆個人のパフォーマンス ◆顧客満足度 > 2004/04/22 アクティビティ４：品質コントロールとコントロールツール ◆コントロールの位置づけ ◆プロダクトの品質向上 ◆プロセスの品質向上 ◆個人のパフォーマンス ◆顧客満足 ◆終結マネジメント |
|
購入はこちら |
|