DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は、システム開発のやり方が多様化してきたことを踏まえ、「プロファイリング」により特定したプロジェクト特性に応じた品質マネジメント戦略を立てることの有効性について考察しました。

今回は、品質マネジメント戦略をもとに具体的な品質マネジメント計画を立てるうえで考慮しておきたい、開発ベンダーの開発部門と品質保証部門、そして、発注側の３者の役割分担について考えてみたいと思います。

【　発注側としての品質評価の難しさ　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
当ブログの　【第３５回】プロジェクト・サクセス・クライテリア（成功判断基準）　では、プロジェクトの成功判断基準である「プロジェクト・サクセス・クライテリアには、システム化の目的・効果の達成状況評価も含めるべきだ！」と主張しました。システム化の目的・効果を達成するには、開発ベンダーに丸投げするやり方では、思うように成果が出ないことは目に見えています。

そのため、発注側が主体的にシステム開発のプロジェクトをマネジメントしていく必要性があります。特にシステムの品質について、ベンダーまかせにしていては、発注側が求める品質を確保できないリスクがあるため、発注側としてしっかり品質評価を行う必要性があるということは確かです。

しかし、システム開発の経験が少ない発注側組織としては、自組織の品質データの統計値を蓄積していないことが多く、品質管理のノウハウも無く、そうなると一般的に公表されている統計値を定量的品質評価の拠り所とせざるをえないのが実情です。

また、前回のブログでも触れたように、システム基盤やシステム開発方法が多様化していることから、これまでのようにチェックリスト密度やバグ密度による品質指標に頼った品質評価では、本当の意味での品質評価はできなくなってきています。

そのような背景のなか、開発ベンダーが構築したシステムの品質評価を発注側が行おうとした場合に、なかなか双方の考え方が合わずに無用なコンフリクトが発生して、かえってプロジェクトが混乱してしまうケースもあるのではないでしょうか？

本来は、システム開発のプロフェッショナル集団である開発ベンダーは、システム開発技術の進歩に追随しているはずであり、加えて開発部門から独立した品質保証部門が第三者視点での品質保証活動を実施する取り組みも進んでいるはずなので、その専門性を十分活用するのが理にかなっているはずです。

ところが、開発ベンダーから発注側に対して十分納得できるような品質状況の説明が不足している場合など、発注側としてはなんとか結果を出さなければならないというあせりから、つい開発ベンダーにプレッシャーをかけてしまうことがあるかもしれません。もしそんなことをきっかけに開発ベンダー側があたふたしてしまうと、せっかくの開発ベンダーの専門性が十分発揮できずに、システム開発の品質や進捗に悪影響が出てしまいます。

当たり前のことではありますが、発注側と開発ベンダーがお互いをよく理解して、協力関係を築くことが、品質の良いシステムを構築するためには欠かせないということをしっかりと認識すべきです。

【　品質マネジメントのトリプルループコントロール構造　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
では、発注側と開発ベンダーが、お互いを理解して協力体制を築き上げるためにはどうすれば良いのでしょうか？

システムの品質を作り込むうえで、影響力のあるステークフォルダーとして、開発ベンダーの開発部門、品質保証部門、そして、発注側という大きく３つの組織があると考えられます。厳密に言えば、発注側組織の中にもＩＴ部門とエンドユーザー、スポンサー、経営層などのステークフォルダーは存在するし、開発ベンダー内でも経営層や再委託先などの多くのステークフォルダーが存在します。

しかし、ここではシステムの品質を作り込む品質保証活動の全体の構造をとらえやすくするために、すべてのステークフォルダーを漏れなく選定するのではなく、開発ベンダーの開発部門、品質保証部門、そして、発注側という大きく３つの組織をステークフォルダーとしてとらえ、その関係性を整理するというアプローチをします。

図１に示す通り、システム開発プロジェクトの中において、開発ベンダーの開発部門、品質保証部門、発注側の３つのステークフォルダーは、それぞれ品質マネジメント計画を作成し（Ｐ）、レビューなどによる品質保証活動を実施し（Ｄ）、その結果を評価・分析し（Ｃ）、分析結果に基づいて品質向上対策などを実施する（Ａ）というＰＤＣＡサイクルを回します。

この３つのＰＤＣＡサイクルがバラバラに回っていては、文字通り品質作り込みの歯車がかみ合わず、効果的な品質保証活動ができません。同じ開発ベンダー内に存在する開発部門と品質保証部門のＰＤＣＡサイクルを合わせることは、比較的やりやすいはずなので、発注側と開発ベンダーの思いを合わせることが大切です。

まず発注側としてどんな品質管理を行いたいかをきちんとＲＦＰ（提案依頼書）に明記して開発ベンダーに提示します。開発ベンダーは、発注側の思いを読み取って、品質保証部門と開発部門が十分協議して品質管理をどのように行うかを提案書に記載して、発注側に提示します。そして、発注側と開発ベンダーの間できちんとすり合せをして、そのプロジェトとしてどのような品質管理をするかを事前合意して、契約文書としてしっかり残すことが必要です。

合意のポイントとしては、以下のようなポイントがあげられます。

・　品質管理の目的とＧＯＡＬ（どこを目指すのか？）
・　各開発工程の品質管理カバー範囲、観点
・　開発ベンダーの開発部門、品質保証部門、発注側の役割分担
・　品質管理の進め方、手順
・　品質指標と目標値（基準値）
・　品質分析の切り口（不具合分類等）
・　開発ベンダーから発注側への品質報告内容とタイミング
・　品質問題発生時の対策の方向性
・　使用する様式や管理ツール類

開発ベンダーの開発部門や品質保証部門が行っていることと同じことを発注側が行ってもあまり意味がありません。それぞれの組織でうまく役割分担して、多面性のある品質をカバーしあうことが必要です。

また、発注側の品質保証活動としては、要求仕様がきちんとシステムに取り込まれているかをレビューや受入テストなどでチェックすることに加え、開発ベンダーから定期的に品質報告を受けることで、開発ベンダーが行っている品質保証活動の内容やプロセスが発注側の品質管理方針と合致しているかを確認することも必要です。

そのために、開発ベンダーから品質に関してどのような情報をどういうタイミングで提示してもらうかをしっかりと合意しておくことが必要です。単に発注側のやり方に合わせるということではなく、開発ベンダーの専門性をうまく引き出して、発注側のＰＤＣＡサイクルに当てはめるという感覚が必要です。

【　発注側、品質保証部門、開発部門の視点の重なり具合　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
プロジェクト実行段階における品質保証活動の監視・コントロールとして、開発ベンダーの開発部門と品質保証部門、発注側の３つのＰＤＣＡサイクルそれぞれがうまく回っていることだけでなく、３つのＰＤＣＡサイクルの歯車がきちんとかみ合っていることの確認も必要です。

３つのステークフォルダー間でコンフリクトが発生していないことを監視することは当然として、それぞれのステークフォルダーがうまく役割分担できていることを確認する方法として、それぞれの品質保証活動で摘出されている不具合の重なり具合を見るというアプローチが有効です。

具体的には、たとえばシステム開発の終盤であるシステムテストにおいて、それぞれのステークフォルダーが摘出しているバグの内容の重なり具合を当ブログの　【第６４回】品質マップのススメ～品質状況を見える化せよ！　でご紹介した品質マップなどを用いて確認します。

図２では、３つのステークフォルダーから摘出された不具合分類の重なり具合のイメージ図を示しています。

開発ベンダーの開発部門、品質保証部門、発注側のそれぞれの役割分担がうまく機能している場合には、＜Ｂ＞に示すように、それぞれのステークフォルダーによって摘出されている不具合分類は、適度に重なりあうはずです。

＜Ａ＞で示すように、それぞれのステークフォルダーによって摘出されている不具合分類に重なりが無い場合は、それぞれのステークフォルダーの向いている方向がバラバラで、プロジェクト全体として品質チェックの観点に抜け漏れがあることが懸念されます。

逆に＜Ｃ＞で示すように、それぞれのステークフォルダーが摘出している不具合が同じような不具合ばかりという場合には、それぞれのステークフォルダーの役割分担がうまくできておらず、品質チェックの視点が重複して、多様性のある品質に対応しきれていないことが懸念されます。

さらに＜Ｃ＞の状況では、第三者視点で品質をチェックするはずの品質保証部門により摘出されている不具合が、開発部門と発注側による摘出不具合に大部分が含まれているため、品質保証部門の存在意義がほとんど無いということになります。

現実のプロジェクトにおいて、そんなに単純明快に傾向が現れることは無いかもしれません。しかし、システム開発方法の多様化に伴い品質評価の方法も多様化し、難しくなっている状況の中、品質の良いシステムを構築するためには、開発ベンダーの開発部門と品質保証部門、発注側がうまく役割分担をしながらそれぞれのＰＤＣＡサイクルを回し、３つのＰＤＣＡサイクルの歯車をかみ合わせる取り組みと、そのことがうまく機能していることを確認するためにいろいろな切り口で品質を分析する試みは有効ではないでしょうか？

「発注側と受注側が協力し、品質マネジメントのＰＤＣＡサイクルの歯車をかみ合わせよう！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～