品質の作り込みについて考えてみる

PMBOKでは、品質については「作り込むもの」というスタンスで考えているようです。管理人も、この考えには全面的に賛成です。

しかし管理人は、PMBOKを学ぶまでは「品質の作り込み」という考えは腹落ちした状態ではありませんでした。

そこでどのような考え方で、実務ではどう捉えているかを書いてみます。

品質とは何か?

プロジェクトは成果物をつくります。ただつくるだけではありません。ステークホルダー(この場合は顧客を指します)の要求に合致したものを作ります。

またプロジェクトには制約があります。コスト・期間・法的な規制などです。

この成果物は、さまざまな制約の中、合意した顧客要求に合致したものを作らなければなりません。

プロジェクトで作成された成果物が「合意した顧客要求に合致していることを保障している」ということが、品質という言葉に凝縮されます。

品質を作りこむとは?

成果物を作成するにあたり「顧客要求に合致したものを提供しなければならない」ことは、さきほど書いた通りです。

すなわち「顧客要求を満たしたものづくりの実施」が、品質を作りこむということですね。

品質を作りこむ考え方

「顧客要求を満たしたものづくりの実施」を推進するためには、すべての工程で、それを意識して活動することが必要です。

つまりすべての工程で「顧客要件をしっかり意識しながら進めること」が重要ということ、とくに要件定義・設計工程はキモです。上流であればあるほど、その重要度は増していくことはいうまでもありません。

要件定義

要件定義工程では「制約を考慮しながら、顧客要求をしっかりと定義する」ことが品質の作り込みに該当すると考えています。さらに「定義した要求事項を確実に合意すること」が重要です。

設計工程

設計工程では「要件定義で合意した顧客要求に則った、機能要件の設計、非機能要件の設計をしっかり行うこと」が該当するでしょう。

製造工程

製造工程では「要件が満たされた設計書に従い、設計書通りの製造を行うこと」です。

このように各工程で「顧客要求を満たしたものづくりの実施」を推進することが、品質を作りこむということです。

なぜ上流工程で品質を作りこむ必要があるのか?

さきほどの考え方では、要件定義~製造工程で「品質を作りこむこと」と書きました。

ではこの工程で顧客要求が満たされていない成果物を作成していた、としたらどうなるでしょうか?

要件定義

要件の抜けモレ・誤りがあると、それ以降の工程で作成される成果物は、顧客要件を満たしていません。

つまり要件定義工程もダメ、設計工程もダメ、製造工程もダメということです。

要件定義でNGの場合

設計工程

顧客要件が反映されていない設計書を作成した場合、それ以降の工程で作成される成果物は、顧客要件を満たしていません。

つまり設計書に、機能不足、処理条件の抜けモレ・誤りなどがあると、設計工程もダメ、製造工程もダメということです。

設計工程でNGの場合

製造工程

顧客要件を満たしている設計書をもとにプログラムの製造をしていきます。しかし設計書の内容を反映していないプログラムを製造した場合、テスト工程以降で、顧客要件を満たしていないことが発覚します。

製造工程でNGの場合

上流工程での品質確保が重要

このことから、上流であればあるほど「顧客要件から逸脱したもの、すなわち品質が悪いもの」であると、後工程での影響が大きくなるということがわかるでしょう。

NG例

よくあるNGな例をあげてみます。このような考えのプロジェクトマネージャが結構います。

  • 「テスト工程で障害を全部出し切って修正を行いリリースする」という方法をとっている

テスト工程まで品質に対する十分な対策を行わず、モノができあがってから障害をつぶすというやり方ですね。「まずは動くモノを見てから」とか理由をつけているようです。

テスト工程でリカバリできるのか

ウォーターフォール型の開発を例にしますが、テスト工程で出てきた障害の原因が、設計工程、さらには要件定義工程に遡る場合はどうすればよいのでしょうか?

火を見るより明らかに「火を噴出す」プロジェクトになってしまいます。まったく持ってナンセンスであることがおわかりでしょう。

上流工程の品質の悪さは致命的

上流工程の品質の悪さは、プロジェクトにとって致命傷です。

もうおわかりだと思います。顧客要件が抜けていることがテスト工程で判明した場合、たとえば、あるプロセスがごっそり抜け落ちていることがテスト工程で判明した場合、リカバリすることが厳しくなります。

抜けている要件を再度定義して、設計して、製造して・・・コストもスケジュールも追いつきませんよね。プロジェクトは破綻してしまいます。

そうならないためにも、上流工程での品質の作りこみが重要というわけです。まさに、「検査より予防」ですね。

「検査」とは、製造物(成果物)に対するものです。システム開発でいうならば「テスト工程」が該当します。

品質が作りこまれていた場合

上流工程から「品質が作りこまれていること」が担保された状態ですすめてきたプロジェクトは、それは「ばら色の道」を進んでいくことでしょう。

たとえば品質が良ければ、次のような望ましい状態になるのではないでしょうか。

  • 納期遅延やコストオーバーも縁遠い。
  • コンティンジェンシー対策として確保していたコンティンジェンシー予備も、リスクが発生しなかったために開放され、さらに利益率があがる。
  • 予定通りにシステムがリリースされ、大きな障害もなく本稼動して、みんなハッピーになれる

すべてのプロジェクトマネージャは、そうなることを目指し日々研鑽していることと思います。

しかしながら、そのような状況には「なかなか」お目にかかれないのが現実です。

まとめ

ざっとですが、品質の作りこみの重要性について書いてきました。

プロジェクトを失敗に追い込む原因は、「品質が悪い」ということに尽きると、管理人は考えています。

そのためすべてのITベンダーで、品質保証の取り組みが行われていることと思います。

組織的な品質保証の仕組みも重要ですが、プロジェクトマネージャの品質を作り込むための仕掛けを、プロジェクト内に浸透させることも重要です。

そしてプロジェクトマネージャを中心に、組織の品質保証への働き掛け(支援を受ける)と、メンバーの品質モラルの向上に最大限の努力をしましょう。

 

SE

Posted by wpmaster