 |
|
第160回関西例会 報告 PMAJ関西KP 富 光弘 ： 12月号
はじめに ： 昨今、QCDバランスの担保とりわけ Q（品質）の部分に問題や課題を抱えているソフトウェア開発プロジェクトは多い。この課題の解決策の一つとして、品質向上のために「クオリティゲート」という考え方をプロジェクトフェーズとして組み込む事を提唱している。 この「クオリティゲート」の詳細を、プロジェクト事例も含めて解説する。
概要 ： ◯背景 講師の経験から、プロジェクト推進には「標準化不足、基準値設定の不備、属人化、品質問題、コスト超過」などの課題が山積みである。この内「品質」を取り上げて改善に取り込んでいこうというのが、今回紹介する「クオリティゲート」という考え方・サービスである。 数多くのプロジェクトが日本中で存在しているにも関わらず、そのプロセスを数値として捉えられていない。ある意味、スーパープロマネで支えられてきていると言っても過言ではないだろう。そんな現状を「データ」という視点で、蓄積～分析（見える化）～対策への反映を行っていくのが「クオリティゲート」の基本的な考え方でもある。様々なメトリクスを数値化し見える化することで、プロジェクト間の比較検討や各組織での基準の設定が行えるようになると考えていい。「クオリティゲート」は、この蓄積したデータを用いることで「品質」を確保、向上させるツールであり「改善プロセス」でもある。 ◯クオリティゲートとは 「クオリティゲート」は、次のような状態にあるプロジェクトに効果を発揮する。
以上のようなプロジェクトに今回紹介する「クオリティゲート」を適用すると次のような効果を得られる。
このように「クオリティゲート」を適用することで品質を作り込むプロセスができあがる。「各工程での設定する評価軸が明確になる」ことで「判定時の基準が明確になる」点が、もっとも期待値が高い。加えて、開発プロジェクトの各フェーズで定量的に判定を行うことができ、品質を確認すると同時に不具合の検出に繋げられる。 また、「クオリティゲート」は個別のプロジェクトに適用してもよいが、組織全体に適用することで一層効果を高めることができる。これは、対象の組織のプロジェクトは品質傾向が似ているケースが多いため対策や効果も似てくるケースが多いためである。 「クオリティゲート」では、品質傾向を定義するための数多くのパラメータ（メトリクス）を準備している。具体的には、開発特性（新規開発・既存開発・派生開発 など）に応じた判定基準を設定した上で、プロジェクトの特性を考慮した「補正値」も用いて実際のプロジェクトに合わせていく。これらのパラメータは、IPAなどでも公開されている内容に「クオリティゲート」独自の項目を追加した「評価軸」になっている。 このような構造になっているため、「クオリティゲート」の設定は次の3ステップで行われる。 Step-1 ： システムプロファイリング 開発種別（新規・既存・不具合改修）と プロジェクト特性から「クオリティゲートタイプ」を定義する Step-2 ： 指標の決定 定量的指標 ： プロセス（レビュー工数、レビュー指摘件数）、不具合件数など 定性的指標 ： 決めたドキュメントのレビュー Step-3 ： 効果的なレビュー方法の決定 このように「クオリティゲート」は、ノウハウの詰まったツールであり、使いこなせるようになるまでは支援が必要なツールでもある。しかし、プロジェクトマネージャーの視点では、各プロジェクトの特性に合わせた基準を設定できることが、勘と経験のマネジメントより、はるかに品質を確保しやすくできると言える。 ◯事例 続いて、実際のソフトウェア開発プロジェクトの事例に沿って、成功するパターンと失敗のパターンを見て行く。 【成功事例】 「プロジェクトの最初から、クオリティゲートを使うことで品質を確保」 プロジェクトの基本を改めて認識させられる事例である。様々な経験値を持ってプロジェクトを最初から統制していくことが、品質確保に限らずプロジェクト成功の不可欠な成功要因である。「品質は作り込むもの」として、改善のプロセスを「クオリティゲート」を用いることで回していくことが欠かせない。プロジェクト計画書で明確に品質維持活動を行うことを定義して、愚直に活動すること。ここでポイントとなるのが、可視化の難しい「品質の見える化」を「クオリティゲート」で行い、是正できるルーチンをプロジェクト内で構築することが品質維持の成功、プロジェクトの成長に繋がった事例である。 【失敗事例】 「既に品質問題が起きているプロジェクトへの途中参加は、十分に品質確保の活動が行えない」 成功事例に比べ比較的小規模の失敗事例であるが、どんなプロジェクトでも心当たりがある原因で品質問題が発生し、当初の目標を達成できなかった事例である。 この事例での失敗要因は大きく二つ。
◯品質保証 様々な対応を行っても不具合をなくすことは難しい。読者の方であれば、幾度となく経験されている方も多いことだろう。そのようなケースに対しての対応策が今回紹介する「品質保証」というサービスである。 よく知られているように、不具合の改修コストは発見されるタイミングが後工程になればなるほど大きくなる。（上流工程での改修コストを「1」としたら、リリース後の改修コストは「100」とも言われる）多くの失敗プロジェクトの場合、この改修コストが原因で納期遅延を起こしていると言ってもいいだろう。 この課題を解消するために、講師は「品質保証」というサービスを日本で初めて提供している。ソフトウェア業界では類を見ない、開発プロジェクトで「不具合発生時の改修コストを保険でカバーする」というサービスである。保険会社と提携した「お墨付き」の保険と考えていい。もちろん保険なので加入条件がある。それは今回紹介してきた「クオリティゲート」を採用し、きちんとプロジェクトの中で品質改善活動を行うことが必須条件になっている。これは「クオリティゲート」の利用料から保険会社に保険料が支払われる仕組みになっているためである。したがって「クオリティゲート」を使わない単独での保険契約はできない。 これは、ツールを導入しても品質維持の保証をどう担保するのか？プロジェクトのオーナーから見ると非常に不安な要素である。この不安を払拭するためにも、このサービスは非常に有効だと言える。「クオリティゲート」を用いて、きちんとした品質維持活動を行っても不具合が発生した場合は、その改修費用を保険でカバーできるからだ。もちろん、品質を作り込む活動が大前提ではあるが、プロジェクトとしてのリスクヘッジの一つとしても使える対策ととらえて良い。 ◯コラム ： クオリティドクター 講師が提供しているサービスを紹介する。このサービスを用いることで、今回説明してきた「クオリティゲート」の考え方を踏襲した品質管理ができるようになる。具体的には「ドクター」という名称からもわかるように、診断?可視化?対応策までを提示するサービスである。現状の品質に対しての課題を見える化して対応策の提示まで行うサービスである。現状の品質に課題があるプロジェクトは検討してみてはいかがだろうか？ ◯Q&A 「クオリティゲート」は期待も高いため、活発なQ&Aも行われた。簡単に要点だけをいかにまとめる。
まとめ ： 品質を確保するためには、以下の点を意識する必要がある。
「クオリティゲート」はプロジェクト期間中だけではなく、組織のナレッジとしても蓄積して行くべきもので、全てのプロジェクトへの適用でより効果を得られるツールである。 執筆者感想 ： 最初に頭に浮かんだのが、「目に見えなかった品質を科学する」というイメージでした。品質で苦しんでいるプロジェクトは、非常に多いので今回ご紹介した「クオリティゲート」を用いることで改善プロセスが定着できれば、過酷なソフトウェア開発プロジェクトの負荷軽減に繋がると感じました。今後、人口減少に伴い開発メンバーも減りノウハウの継承も問題となっていく中で、品質維持の活動を「クオリティゲート」で標準化していくことで新しいプロジェクト推進の在り方を見出せていけることを期待したいと思います。「クオリティゲート」については、プロジェクトのデータが集まりビッグデータ的な活用も期待できることから、更なる発展も期待したいと思います。 以上
|
 |