第3話　品質情報システム（その２）
 
■品質部門の役割
 
先週に引き続き，品質情報システムについての考察を続けます．今週は，品質情報システムがどのような機能を果たすべきかを踏まえて，品質部門がその主管機能として，どのような役割を果たすことによって，どのようなシステムを設計・構築し，運用の管轄・監視，支援，調整をするか考えます．
 
品質情報システムの構築・運営に関して，品質部門は以下のような使命・役割を担っていると言ってよいでしょう．
　・品質情報システムの設計・構築
　・品質情報システムで運用されることになっている品質情報が品質情報システムの設計・構築の意図通りに
　　収集・蓄積・活用されているかどうかの定期的チェック・監査
　・各部門での品質情報システムの運用に関わる指示・支援・調整
　・品質情報システム自体の有効性評価と改善・改革への提言
以下ではこれらについてさらに検討してみます．
 
■品質情報システムの設計・構築
 
情報システム設計にあたっては，以下の4つの側面に留意する必要があるでしょう．
　・実現したい機能
　・情報の流れ
　・データ構造
　・業務の流れとの関係
 
「機能」を考えるとは，品質保証のために「何をするか」を考えるということです．要は，品質保証体系が明確に定義されていなければならないということです．ここで重要なのが「機能」です．どのような活動をするかではなくて，何が実現できればよいかを考えることが必要です．品質保証に必要な機能を考えるにあたり，第一に顧客価値を生む主プロセス（バリューチェーン），第二に主プロセスを支える経営資源・インフラを整える支援プロセス，さらに第三に品質保証のフレームワークという3つの切り口で考えることができます．
 
主プロセスとは，顧客・市場の要求・ニーズから製品・サービスの企画，製品・サービスの設計・開発，その実現（生産・サービス提供），調達，顧客への引き渡し・付帯サービスという製品・サービスを生みだしていく品質機能の流れです．支援プロセスとは，人材，知識・技術，設備・機器類，供給者，物流，ユーティリティ・備品，業務環境など，主プロセスで利用される経営資源を利用可能な状態に維持する機能です．フレームワークとは，品質保証システムの設計・構築，運用の枠組み，評価（監視，監査，レビュー），改善などの機能です．
 
「情報の流れ」とは，これらの機能間を移動し変換されていく情報の流れ，あるいはこれらの機能のインプットとアウトプットを考え，それらがどう連結されるかを考えることです．流れの他に蓄積（記憶），取出し（参照）についても考えます．いわゆるDFD（Data Flow Diagram；データ・フロー・ダイアグラム）を書くことをイメージすればよいでしょう．
 
「データ構造」とは，機能間を流れ，蓄積，参照される情報・データの構造です．テンプレート，図表，文書類の書式，さらにはデータベース設計などをイメージしていただけばよいでしょう．
 
「業務の流れとの関係」とは，品質情報システムを使って，業務がどのような流れで行われていくか，その関係を決めることです．画面設計と，ある業務ステップにおいて業務実施者が情報システムとどのようなやり取りをすることになるかを検討します．
 
製品・サービスのタイプ，業種・業態によって変わりますが，品質保証の観点からは，以下のようなことに関心を寄せてシステム設計をするとよいでしょう．
　・検査設計：いつどのような特性について検査すべきか
　・レビュー設計：いつどのような観点でレビューすべきか
　・市場品質情報：顧客・市場はどう受けとめているか
　・トレーサビリティ：どのような粒度でトレーサビリティを把握すべきか
　・進捗把握：主プロセスの各段階の進捗状況，課題をどのような粒度で把握すべきか
　・品質特性間関係：要求，製品・サービス仕様，プロセス仕様，プロセス条件，工程中間特性間の関係を
　　どの程度把握できるようにすべきか
 
■品質情報システムの運用状況の確認
 
前項のような考察を経て構築された品質情報システムが期待通り運用されているかどうか把握し，必要に応じて指示，推奨，支援，調整を行います．こうしたことができるためには，各品質保証機能が品質情報システムを効果的，効率的に活用しているかどうかを端的に把握するパフォーマンス指標，効率指標を把握するとともに，代表的な問題・課題に対して，その原因系についての仮説を持っていることが重要です．品質保証の主管部門として様々な問題に遭遇し解決してきているのですから，起こり得る問題の類型とその主たる原因の切り分けができるようになっていて自然で，こうした知識基盤があってこそ品質情報システムが生きると言えます．
 
例えば，量産工程での品質保証であるなら，まずは製品・サービスの特徴から品質に影響を与える要因として「ひと」と「設備」のどちらが大きいかを知り，重点を置いた管理をするように指摘・指導すべきです．「ひと」であるなら，作業標準の意味・意義の理解，作業に必要な能力付与，ヒューマンエラーの考慮の必要性，品質意識のレベルなどを把握し，適切に対応するように指示・支援をします．「設備」であるなら，設備構造・動作原理の理解，加工点解析，自主保全などのレベルに関心を持ち，それを把握し，自律的に管理するように，現場を強化・支援します．
 
設計・開発プロセスでの品質保証であるなら，QFD的考慮（要求と実現仕様の関係理解），展開（要求から実現方法へ，さらに詳細仕様への展開），実現手段・方法の影響の考慮，DRの視点，FMEAの実力，評価能力（項目・特性，条件，判断基準），変更管理（変更の影響評価）などの活動についてのレベルを評価し，プロセスの脆弱性を特定し，改善するように指摘・支援をします．
 
営業・サービスプロセスでの品質保証であるなら，顧客ニーズの把握と理解の的確さ，サービス情報の利用，各種情報の本質理解，様々な事象に対する仮説の持ち方などを品質情報システムから獲得できる情報を分析して判断し，適切に対応できるように指示，助言，誘導，支援，調整します．
 
品質部門としては，各機能の運用支援のみならず，機能間・部門間のつながりが健全であるかどうかを品質情報システムを通じて判断し，適切な対応をすべきです．とくに，企画と設計・開発，設計・開発と生産技術，生産技術と生産部門の関係，情報の円滑な伝達には留意し，問題があれば直ちに指摘・支援・調整に乗り出すべきです．
 
品質部門としては，各部門が品質情報システムの意義を理解し有効活用できない事象・症状がどこに現れるか知っているべきです．そもそも意義を理解していないならきちんと説明するし，とくに組織全体に及ぼす影響の大きさを強調します．一応は納得できるが，無駄・非効率と感じるとか，工数がかかり過ぎて対応できないというのであれば，それを使わなければ業務が進行しないようにシステムで縛るとか，効率向上によって工数を捻出するなどの対応をします．部門として「指示」をすることもありますが，相手の理解力，実施能力，意欲，そして品質部門に対する信頼感を考慮した方法を取る必要もあります．
 
■品質情報システムの改善・改革
 
品質情報システムの改善・革新のためには，その有効性と効率を把握する指標を設定しておく必要があります．もちろん，個別の品質問題の発生状況を深い洞察力をもって分析していれば分かりますが，組織全体に改善・改革の提案をしていくためには，関係者がその背景に何が起きているか容易に理解できるような指標が必要です．
 
例えば，市場・顧客クレーム，客先納入不良，出荷検査不良，工程内不良，受入検査不良，DR指摘，企画変更，設計変更，開発リードタイムなどのうち，品質保証システムの脆弱性を示唆する指標を手掛かりに，品質情報システムに内在する問題・課題を明確にし，その充実のために必要な対応策を検討し，組織的改善・改革に結びつけます．
 
こうした指標とは別に，重要品質問題が発生したときには，その事案について，問題の発生原因，見逃し原因，稚拙な対応原因を追求し，適切な再発防止，未然防止策を講じます．また，市場や技術などの外部環境や組織内部の状況の変化があって，品質情報システム，ひいては品質保証システムの改善・改革が必要と判断したら，その見直しの活動を起動させリードします．こうした活動が適時咳適切にできるためには，世間相場を知り，ベンチマークを怠らないことも重要です．
 
近年の情報技術の急激な進化もまた改善・改革へのトリガーとなることを忘れてはいけません．技術の進歩によって，かつては導入を断念・躊躇していたような機能を導入することが可能になっているかもしれません．速度・容量の増大，コスト低減という量的変化は，システムの質的変化を可能にするかもしれません．道具の進化の本質を見抜く洞察力とベンチマークを怠らないことが大切です．
 
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（飯塚悦功）