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

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

前回は、個別障害を「一本釣り」して、品質マネジメントプロセスの改善に結びつけるアプローチをご紹介しました。どんなことでも、「幅を広げること」と「深掘りすること」を合わせることで、成果に結び付けやすくなるはずです！

今回は、システム開発を行う多くの組織において実施されている「品質会議」について考察します。

【　あなたの組織の「品質会議」は形骸化していませんか？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
最近ツイッターを始めたこともあり、執筆するブログのテーマに関するリサーチにも、ツイッターを活用するようになりました。そこで、今回のテーマである「品質会議」についてリサーチしてみたところ、「眠い」「無駄な時間」「下っ端には関係無い」などなどネガティブなつぶやきばかりが目立ちました。（※１）

―――　ここで、プロジェクトマネジメント研修を受けてきたばかりの新人Ｐ子さんにも、「品質会議」にどんなイメージを持っているか、きいてみることにします。

＜新人Ｐ子さん＞　：　「そうねえ。私は品質会議には参加したことないのでよくわからないんですけど、、、そういえば、いつも回覧されてくる品質会議の議事録には、『組織の品質目標』とか『是正措置への対応状況』とか書かれているようですけど、プロジェクトの現場と何か関係しているのかどうか、正直それも良くわからないんです。。。」

―――　長年現場でプロジェクトと戦い続けてきたベテランＰＭのＭ男氏も、あまり興味が無い様子でブツブツつぶやいています。

＜ベテランＰＭのＭ男氏＞　：　「ふん。品質会議なんて、うちの会社はちゃんと仕事してますよってポーズのためにやってるんじゃろ？実際品質の良いシステムを作るのは、プロジェクトの現場で働くＳＥやプログラマーなんだから、そんな形式的な手続きなんてまったく意味無いんじゃ！」

・・・　おやおや、どうやら「品質会議」というものは、システム開発のプロジェクトとは切り離されて運営されているのでしょうか？もしそうであれば、プロジェクト現場の人たちから、「品質会議」は形式的なものであるとみなされても仕方がないかもしれません。

しかし、「品質会議」という名前から考えると、組織として品質マネジメントをしっかり行うための重要な位置づけのものであるはずであり、システム開発プロジェクトの現場にも密接に関係するものであるはずです。それがどうして、こんな風に「品質会議」が形骸化の代名詞ともいえるようなものになってしまったのでしょうか？

【　「品質会議」とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
そもそも「品質会議」とはなんでしょうか？確かに多くのシステム開発を行う組織において、「品質会議」という名前の会議が開催されています。これは、多くのシステム開発組織が認証を取得しているISO9001の要求事項として「マネジメントレビュー」の実施が求められているためです。（※２）

ISO9001では、「品質マネジメントシステムが、引き続き、適切、妥当かつ有効であることを確実にするために、あらかじめ定められた間隔で品質マネジメントシステムをレビューしなければならない」とされており、この「品質マネジメントシステムをレビュー」する場として、定期的に「品質会議」を開催しているのです。

本来的には、品質マネジメントシステムの有効性を定期的に評価することを求められているだけなので、必ずしも会議体によらなくても良いはずですが、ISO9001の認証を得るために「品質マネジメントシステムをレビュー」しているエビデンスとして、「品質会議」の議事録を残すことが手っ取り早いということで、どの組織も「品質会議」を定期的に実施するという運用を行っていると思われます。

こうして考えていけば、「品質会議」が形骸化する原因も明らかです。「品質会議」は品質を良くするための活動という本来の目的よりも、ISO9001認証維持のための手っ取り早い手段という意味合いが強くなっているために、形骸化に陥ってしまうのです。ISO9001認証維持という大義名分のために、多少形骸化していることがわかっていても、これまで通りの「品質会議」を続けるという論理に陥ってしまっているのではないでしょうか？

しかし、せっかく経営者も含む多忙なステークフォルダーたちを集めて「品質会議」を実施するのであれば、単にISO9001認証維持のためだけの形式的なものではなく、真の意味で品質改善の成果につながるような取り組みにすべきです。そして、実際にシステム開発プロジェクトに携わっている人たちにも「品質会議」が有益なものであると感じられるようにする必要があります。

「品質会議」を活性化させ、現場の人たちを巻き込むために、たとえば前回のブログでご紹介したような個別障害の深堀事例や品質の良いシステムが構築できた成功事例など、システム開発プロジェクトの現場で起きている身近なトピックを数多くアジェンダに組み込んでみてはどうでしょうか？

【　個別プロジェクトにおける「品質会議」　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、ここまではシステム開発を行う組織全体で行う「品質会議」について考察してきましたが、個別のシステム開発プロジェクトにおいては、工程完了時点で品質状況をとりまとめて報告する「品質評価報告」という会議を行うことが多いと思います。

本来、品質評価を行う目的は評価結果をフィードバックして、品質改善につなげるためです。しかし、工程が終了してから品質評価報告をされても、もし評価結果に問題があった場合には、次工程の開始を遅らせたり、最悪の場合カットオーバー時期の延伸という事態を招いてしまいます。（※３）

また、仮にある程度品質データがたまった段階で中間品質評価を行うにしても、どの程度たまってから実施するのか検討したり、プロジェクトの進捗状況をにらみながら報告者や会議に参加予定のステークフォルダーたちと開催時期の調整を行うなど、たいへん非効率になることが目に見えています。

そこで、工程の区切りや品質データのたまり具合に関係なく、たとえば毎週行っている進捗報告会議のうち月に一回だけは、進捗会議の後に「品質会議」の時間をとることにするなど、「品質会議」の定例化をご提案します。

個別プロジェクトにおける定例の「品質会議」では、レビュー指摘密度やバグ密度などといった品質評価結果だけではなく、品質マネジメント計画やテスト計画の内容を紹介したり、組織全体で行っている「品質会議」で話し合われたことなど、品質に関するさまざまなトピックの紹介を行います。もちろんタイミングがあえば、工程完了時の品質評価報告や中間報告を定例の「品質会議」の場で行っても構いません。

このように「品質会議」を定例的に実施することで、普段は品質のことをあまり考えたことの無いステークフォルダーたちに対して品質意識を植え付けるのです。工程の終盤やプロジェクトの終盤になると、進捗遅延が発生したり、その他の問題・課題が積みあがっていることが少なくありません。そんな状況になってから、品質の議論を持ち出しても、進捗遅延や問題・課題の解決が優先的に議論され、品質が二の次にされてしまう可能性が高くなります。

そこで、まだ工程が始まったばかりで、進捗遅延や問題・課題が起きないうちに、ステークフォルダーの意識を品質に向けさせるために、品質に関するさまざまなトピックをアレンジした定例の「品質会議」を仕掛けるのです。

このような取り組みを行うことで、個別プロジェクトにおける定例の「品質会議」と組織全体の「品質会議」をうまく連動させることができれば、実際にシステム開発プロジェクトに携わっている人たちと「品質会議」を結びつけ、「品質会議」を活性化させることができるはずです！

「個別プロジェクトでも定例の品質会議を行い、組織全体の品質会議の活性化につなげよう！」

ご納得いただけたでしょうか？

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

工藤武久

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

※１　「新感覚！プロジェクトマネジメント　ツイッター版」　では、ブログの没ネタやブログのメーキングに関する情報などを毎日つぶやいています。興味のある方はのぞいてみてください！
https://twitter.com/iti_kudot　（　ツイッターアカウントの無い方も見ることができます。　）

※２　ISO9000については、以下参照。
・「ISO 9000」『フリー百科事典　ウィキペディア日本語版』
2016年1月29日 (金) 03:58 utc https://ja.wikipedia.org/wiki/ISO_9000

※３　工程完了判定については、当ブログの以下の回も参照してください。
・【第３３回】工程完了判定基準にオフサイドトラップを仕掛けろ！
・【第３４回】カットオーバー・クライテリアとは何か？
・【第３５回】プロジェクト・サクセス・クライテリア（成功判断基準）