« UMLモデリングの本質 | トップページ | 光の使者プリキュアこそが文明社会を破壊する »

第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試験対策の目次に戻る
--

このエントリーをはてなブックマークに追加

|

« UMLモデリングの本質 | トップページ | 光の使者プリキュアこそが文明社会を破壊する »

コメント

現在大学二年でPMの勉強をしています。最近PMBOKガイドの第3版を買い、勉強しようと本を広げました。読んでみたところ全く理解できず困っていました。もともと読解能力も低いんですが・・・
しかし、Dainさんのおかげで少し理解することが出来ました。感謝しています。

投稿: はなたれ小僧 | 2005.10.13 14:45

ほへー

大学生でPMBOKですか…はなたれ小僧 さんが眩しいようなうらやましいような。スゴい世の中になったものです。

ただ、気をつけていただきたいのは、「PMBOKはクルマの教則本のようなもの」というところです。知識、ハウツー、ルールが並んでいますが、路上では違うところ。現場優先ですね。

だから、社内では若い方にはオススメしてません。現場(というか修羅場)をある程度くぐってからでないと、そのアタリマエなことの重要性が理解できないかもしれないから。

教則本をいくら読んでもクルマの運転が上手くなるわけじゃない。でも読まずにハンドルを握るのは限りなくリスキー… ってなことを考えながら、PMBOKに取り組むと良いかもしれません。

投稿: Dain | 2005.10.13 16:40

pnbokuどうしょう。たかい

投稿: | 2005.10.18 15:20

むずかしいです

投稿: | 2005.10.18 15:21

名無しさん、コメントどうもです。

「PMBOKは高い」について : 最新のPMBOK3のpdf版は無料で入手できますよ。
以下のリンクからどうぞ。
http://www.pmi.org/prod/groups/public/documents/info/pp_pmbok2000licenseagr.asp
…英語ですが。

「むずかしい」について : 私の記事が難しいのでしょうか… これは自分用のまとめなので、分かりにくいところはご容赦を。PMBOKの理解については良書がありますよ。
http://www.amazon.co.jp/exec/obidos/ASIN/4774122017/daincocologni-22/ref=nosim
http://www.amazon.co.jp/exec/obidos/ASIN/4274166937/daincocologni-22/ref=nosim
…日本語です。

「何のために学ぶのか」を心において、がんばってください。

投稿: Dain | 2005.10.18 23:22

はじめまして。
独立系SI企業でPMをしている者です。
PMPを受けようと思いPMBOK2000のコースを受講したのが3年前・・
問題集も購入し、勉強を始めようとした矢先に仕事が忙しくなりそのまま放置・・今日に至ってしまいました。(涙)

やっと仕事も落ち着き勉強を再開しようとしたところ、PMBOKが改定されているのを知ってショック!を受けました。
・・が、気を取り直してPMBOKガイド第3版(日本語版)を一通り読み、知識を再インストールしているところです。(笑)

更に先日rita本を購入しました。
購入したのは良いのですが、このrita本をどのように活用したらよいか悩んでいます。
一番のネックは英語です。
①書いてあることはなんとなーくわかりますが、わからない部分(単語)も多いです。
②しかし、辞書を片手に全部訳していたのでは、いくら時間があっても足りません・・
・・といった具合です。
Dainさんは、rita本をどう活用しましたか?

投稿: Revo | 2005.10.19 00:32

Revo さん、コメントありがとうございます

 Rita本は最強のPMP受験対策です。合格のためにはPMBOKの知識プラスアルファが必要で、Rita本は「プラスアルファ」を補給してくれます。通読するだけで、いわゆるPMIイズムを身につけることができます。私の場合、次のように使いました。

  ・通読する: 3回読みました。読書百遍じゃないですけれど、
   くりかえし読むことで理解に至ることは、本当です

  ・PMBOKとの連携: Rita→日本語版→英語版の順で各分野を
   追いかけました(Rita→英→日ではないことに注意)。私の英語は
   あやしいので、日本語で理解のスピードを加速させ、英語で正確さ
   を期しました

  ・so what?: Rita本に限らないですが、「誰かに教えるつもり」で
   読みました。「結局、ここでは何がいいたいの?」を念頭に置き、
   翻訳ではなく「まとめ」をつくりながら読みました

  ・わからない単語: 日本語版の巻末の用語集が役立ちました
   あと、英語pdf版で検索して、その前後の文から類推しながら
   理解を深めました

で、そのまとめのまとめがこのエントリというわけです。また、社内勉強会でレクチャーすることで、自分の理解をより深めることができました(間違いも指摘してもらえたし)。

日本語の参考書も確かにあるのですが、Rita本と比べてはかわいそうです。それほどの「威力」を持っています。あとは信じて、くりかえし読むだけ。

がんばってください。

投稿: Dain | 2005.10.19 09:34

Dainさん、勉強方法の伝授、ありがとうございます。
「PMBOKとの連携」「翻訳ではなくまとめ」参考になりました。
m(_ _)m

現在は、日本語版の2回目を読み始めたところです。
まだ理解しきれていないので、3回くらい読んでイメージをつかんでから、rita本でDainさん方式を試してみようと思います。

PMPの取得が最終目標ではないので、多少時間を掛けてでも、確実に理解を深めて行こうと思います。

投稿: Revo | 2005.10.19 23:37

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 第8章:プロジェクト品質マネジメント(その1):

« UMLモデリングの本質 | トップページ | 光の使者プリキュアこそが文明社会を破壊する »