第8章：プロジェクト品質マネジメント(その1)

ここでは、プロジェクト品質マネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

keywords
　・品質の定義
　・金メッキ(オマケ)
　・検査よりも予防が大事
　・品質マネジメントの定義
　・ジャストインタイム
　・ISO9000

　PMBOKでの品質は、一般的に使われる品質とチョト違う。厳密な定義と適用範囲がある。試験では一般的な「品質」を選択肢に紛れ込ませているので、経験だけで受ける人はコロリと間違える(そういう私もそう)

品質の定義(p.96)
　先ずはPMBOKから。「品質とは、明示された、または暗黙のニーズを満たす能力に関する特性の全体」(←棒読み)…なんのこっちゃ。翻訳ソフトに頼ってばかりだとこうなる、という好例やね。気を取り直して、

「品質とは、要求されたことと提供したものが一致していること」
「品質とは、使用適合性のこと(使うに足る、ということ)」

原文を引用する。リタ本はこれを覚えろと言っている。

Quality is defined as conformance to requirements and fitness of use.

　この定義から、プロジェクトが生み出す製品やサービスは、現実的なニーズに適合していなければならない。そして「適合していること」に近づけるために品質マネジメントが必要なことが分かる。

　さらに、

• プロジェクトマネージャは、予め委託されたことを完遂するだけでよい←言い換えるとそれ以上することはPMPの範疇外
  
• プロジェクトマネージャは、すべきことをするだけ。すべきこととはプロジェクト計画書で定義された目標を達成するだけ←それ以上はPMPの範疇外
  
• 品質そのものは顧客には何ももたらさない。求めるものに合致する製品・サービスを提供するだけだから←これ重要
  

品質 = 求められた製品・サービスに対し、どれだけ合致したものが提供できるか

　だから、「品質が良い」とは、「求められたものに合っている」ということで、顧客からすればアタリマエなこと。だって、金だしてやってくれと契約したものはやってくれるのがアタリマエだと考えているから。

　そのアタリマエができないからこんな資格が流行るんだろな…

　だから厳密にいえば「品質がよければ顧客満足度が高まる」はウソ。「顧客満足のためには品質(使用適合性)の良いものを提供しなければならない」がホント。

金メッキ(オマケのこと)
　PMIイズムからすると、以下のことは推奨されていない←経験で解答すると間違える

• 高品質な製品
  
• 豊富な付加機能(ただしスコープ定義外)
  
• 豊富なオプション(ただしスコープ定義外)
  
• 求められた以上の高性能
  

　要は「お客さんが求める以上のものを提供しても意味無いよ」ということ。金メッキ(gold plating)とあるが、オマケのことやね。「作っている現場でこんな付加価値をつけたらお客さん喜ぶだろうな…」と考えても的外れなことが多い、という→PMI←おおいに異論反論があろうかと。

　自分が何を欲しがっているのかすら分かっていない(もしくは表現できない)お客さんが相手な場合はどうする?　作っている途中に「あーやっぱこんな感じじゃないんだよねー」とコロコロ変更を求める場合はどうする?

　↑の異論に対しては、PMIではだからこそスコープ定義(p.57)に尽力せよとのたまふ。あの…「スコープ定義」は計画プロセスなんですけど…それでもPMIイズムだと計画→実行→コントロール→計画…をくり返すのだ(p.31)という。さらにコントロールでスコープにおいて定義と実際のズレが無いかスコープ検証で見よと言う(p.61)。言っていることは確かに合っている。あとはどれだけ適用できるかだけど。

検査よりも予防が大事
　ここも経験で解答すると間違えるところ。昔は「高品質」を求めるため厳密な検査を行っていた、製品が出来上がった後で。今、というよりもPMIイズムでは出来ちゃった後にあれこれやってもダメ、「品質は予め計画に組み込まれているもの。検査の中で追求するものではない」だそうな。まあ >>1は不良在庫をいっぱい抱えてなさいってこった。

品質マネジメントの定義
　これにもちゃんと定義がある。プロジェクト品質マネジメントとは、プロジェクトが意図するニーズを満足させるために必要なプロセス群のこと。あるいは、

プロジェクト品質マネジメントは「品質方針、目標および責任を定め、それらを品質システムの中で品質計画、品質保証、品質管理および品質改善によって実施する、全般的な経営機能の全ての活動」からなる(p.95)

　品質計画
　品質保証
　品質管理
　品質改善

　似たような名前が並んでいるが、明確に意味は違う。試験ではソコを突いた問題になるが、覚えるというよりも実践に即して考えてみれば身についてしまう。例えばバグについて考えてみる。

仕様は既にある。んで、

• 出来あがり規模がこれぐらい
  
• 言語がjavaでstrutsフレームワーク使って
  
• あいつが手伝ってくれてメンツがこんくらいで
  
• コーディング期間がこれぐらいかけられて
  

…と考えると、出来不出来の多寡は「ラインあたりバグ件数」つまりバグ密度で測ろう。しかもパッケージ単位で目標を分けよう。パッケージ単位でグループ割りするから、パッケージの難しさによってバグが出やすいこともあるからな。ライン見積もりができるなら、だいたいのドキュメント枚数も把握できるな。じゃ、設計段階ではドキュメント枚数あたりの指摘件数、コーディング段階ではバグ密度で出来不出来を測ろう。

…などと計画段階で考えておく。これが品質計画。このプロジェクトにとって一番適切な品質基準を設定して、それを満足させる方法を決めること。

かくしてプロジェクトはまわりだす。

バグ密度は週に2日、火曜日と金曜日に計出してチェック。チャート化して進捗度合いと一緒に分かるようになっている。監査部の人は抜き打ちでやってきてはドキュメントの「枚数だけ」を数えていくだろうから予め紙出ししておく(誰が紙媒体なんて見るか！)

…などと実行段階において、計画で定めたことをちゃんと測る作業、これが品質保証。プロジェクトの成果が定められた品質基準を満足している、と断言するために実施する作業のこと。

バグ密度チェックしているとマズいことに気づく。キロ1.45を超えているか…んーこれってヤヴァくねぇか? 1.45は社の方針だしなぁ… 仕方ない、あいつにサポート頼んでペアプロしてもらおう。書いている途中でツッコミ入れてもらえばバグの形で出ないだろうしな

…と、コントロールフェーズにおいて、決めた目標より逸脱してないかチェックして、ヤバそうなら手を打つ。これが品質管理。プロジェクトの実行結果が品質基準を満足しているか否かをチェックし、不満足な結果になりそうならその原因を除くための手を打つこと。

イテレーション2終わった時点でメンバーを集める。ライブラリ化したほうが良いメソッドがないか訊いてまわる。DBアクセスがボトルネックになっているみたいだ。あらたに永続化のためのクラスをつくり、これまでアプリケーションの中から呼び出していたSQL文を、そいつに任せることにする…パフォーマンス向上のため、ひとつひとつ洗い出しては直してゆく。インターバルではこうした積み上げが絶対に必要だ。やってる最中は間違いなく「動かす」ことに目が行ってしまうから。

…これが品質改善(改善、KAIZEN)。製品や製造プロセスにおいて小さな向上策を積み上げていくこと。注目したいのは製品そのものだけでなく、その製品を作り上げるプロセスも「改善の対象」となっていること。例えばあるツールを使えば試験プロセスが短縮できるのなら、それも「改善」と呼ぶ。

品質計画、品質保証、品質管理は非常に紛らわしい。以下にまとめ。

品質マネジメント

品質計画	品質保証	品質管理
計画フェーズ	実行フェーズ	コントロールフェーズ
計画を立てる	立てた計画を実行する	実行した結果を測る
どんな品質管理基準を設けるのか? どのようにその基準に合わせるのか(どこをチェックすれば「基準に合っている」といえるのか)	品質基準どおりにいっているか洗い出してみる。そもそも基準は正しいか?	洗い出した結果からエラーを数える。スケジュールどおりにいっているか測ってみる。計画とズレが生じるようなら手を打つ

ジャストインタイム(JIT:just in time)
「ジャストインタイムとは」googleにリンクしたから読んでくだされ、というのは酷だから簡単にまとめる。

在庫量を徹底的に減らすことを主眼とした生産方式。トヨタのが有名。言い換えると「必要なときに　必要なものを　必要なだけ」。

能書き終わり。世のエコノミスト厨どもが喜んで誉め称えているが、厨だから。その工場にとっての在庫量は減るが、シワ寄せは納入元にくる。ウソだと思うなら「ジャストインタイム」もしくは「カンバン方式」を導入していると嘯いている工場へ行ってみるといい(特に早朝)。納入業者のクルマの行列がきっと見つかる。

ISO9000
「その組織が品質マネジメントのための何か(システム、マニュアル、手順)を確立していて、その通りに実行していますよ」ということを保証しているだけ。別にISO9000がそのやり方を教えてくれたりするわけではない。

これ自体ムダ、不要。っつーか一時期「品質マネジメントで日本に遅れをとった欧米が主導権をとるためにこんなヤヤコシイ(but無意味な)手続きを編み出し、標準化させたんじゃぁねぇのか?」という意見が噴出していたが、今でもそう思う。陰謀説は極端だが。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--