システム導入の大前提『企業は経済活動を行うところである。たとえ品質部門であってもこの基本から外れる事はできない』

頭では理解できるワードなのだが、品質屋さんとしては 往々にして腹落ちしないときもある。

例えば、ある品質不具合で100万円の費用損失が発生したする。
大きな問題である。
しかしこれを対策しようとする時に200万円の追加費用が掛かるとする。
単に費用比較なら『対策は行わない』という判断になるのかもしれない。
でも、この品質問題による製品や企業の評判が、将来の売れ行きに影響してしまうとすれば、『対策する』という判断もあるだろう。
実際将来の売れ行き影響を見極めるなんてことは 想像は出来ても 占い師でもなければ判断は無理だし、結局どちらも正解という話になってしまう。

ただ、原理原則として経済活動であることを忘れて行動してはいけない。
そこで 私は、所属する品質部門を以下のように定義した。
『【品質】という道具を使い 経済活動をする部門』
品質というワードを目的ではなく道具と定義し、目的はあくまで経済活動であるとした。

そうすると次に【品質】って何？ 言葉の定義を探したくなる。

JIS、ISO9000シリーズを調べてみると
『品質とは、対象が要求事項を満たす能力の程度』とのこと。
なんとも直観的に理解するのが難しい感じの言葉。

たとえば、4文字熟語で、会計品質、情報品質・・・ 品質が付けば なんでも品質部門が担当なの？　経理やIT部門の要求事項を満たす能力の程度 を私が管轄するの？？
なんて事にならないように、私自身の中で、品質を以下のように定義した。

販売された製品に対し お客様（エンドユーザー）の経験する機能/性能/仕様/製造上の
1. 故障・不良・不具合　＝　クレーム（& 苦情）
2. 安全欠陥、法規不適合など市場回収を必要とする案件　＝　リコール
この2つのみである。

なんだか当たり前のようなことを言っているようだが、実際の現場にいると、目の前で日々発生する生産現場の工程内不良等が どうしても社内的注目度が高くなりがちで、
自分自身の立ち位置を忘れないためにも、この定義が大変重要であった。

元来、品質の良し悪しは お客様（エンドユーザー）が判断するものであり、
従って、クレームとリコール が 唯一の品質の定義であり、ターゲットでもあると私は考えた。

前出 品質部門の定義に置きなおすと
『【クレームとリコール】という道具を使い、これを削減する行動をもって経済活動をする部門』
という事になる。

従って、品質部門内のシステム開発/導入であっても その活動行為が、部門の定義に合致するのか？ 企業にとって有益であるか？を基準にし、それが具体的にイメージできないようなものは開発してはならない。

実際にそのシステムが現場でどのようなシーンでどのくらい使われるのか？ どれだけ役に立つのか？ それを使う事でどれだけの削減（クレーム費、リコール費用）につながるのか？ これらが口先ではなく本当に具体的なイメージ/想像ができるのか？が、導入可否に対する唯一の判断基準である。

しかし現実には、システム開発そのものが目的になってしまっている事例をしばしば見受ける。（むしろこちらの方が多いくらい）

在任中に私自身が経験した一例で、
『現状 Excel手作業で作成していた品質月報をシステム化する』という企画が発足した際、その提案者に このプロジェクトで何を求めるのか？ どう改善したいのか？ 等々を聞きいたことがある。
1. 今々、部長に提出するための品質月報を毎月作成するのに フルタイム数名の工数がかかり大変なので、システム化して工数削減を図りたい。
2. 社内で DX風潮の高まりから、このテーマを推進したい。
とのことだった。

これを聞いたとき正直愕然とし、ここまで大企業病が深刻であるのか？ 頭を抱えたものである。

1. まず、この職場では品質月報を部長に提出することが 業務目的になっている事。
→ 本来は、製品の品質向上を図り、結果として企業利益を創出すること。そのために 月報発信を通じて、今々の品質課題を全社的に明確に さらに社内全体に公にする（さらす）こと、共有化することで、問題部門 改善活動の自発的活性化を促し、更に必要に応じて上位レベルへのエスカレーション・サポートを図ることが目的であるはず。

2. 次に『職場の工数削減』が システム開発の動機＝目的になっていること。
→ 本来は、この月報を通じて 生産/開発現場が 最新の情報/状況/指摘/指示を受け取り 最速＆リアルタイム品質改善活動につなげることが、目的であるはず。
このシステム開発の目的が、自部門の職場改善になっており、本来の目的である製品の品質改善を完全に忘れてしまっている。

ここでありがちな誤解が一つある。
それは『職場の効率化・工数削減』は、そのまま企業/部門の利益目的に合致するのではないか？という発想である。
ただよく考えてみると、そろばんや電卓を打ち込んで集計作業をしていた時代ならいざ知らず、職場にPCやネットワークが無くてはならない時代において、システム化は その導入/開発/維持/保守に相応の工数・費用が継続的に発生し、それを部門の工数削減にて相殺できるようなレベルにないことは、まず最初の事実として認識しておくべきである。

システム化において求めるべきものは、単純なデータの出し入れに伴う工数の削減ではなく、人力では不可能な桁違いの精度/速度と量の計算と 完璧な記憶（データ保存）を可能とするコンピュータ技術を用い、本業（ここでは品質向上）の加速を行う事であり、その加速効果で企業/部門の利益目的に貢献する事である。

企業規模がそこそこ大きいと、各担当の作業が細分化され、部門本来の目的から遠ざかってしまう（気づきにくくなってしまう）ため、このような 目の前の作業改善を目的としたシステム化提案は、往々にして起こりうるものである。（実際、頻繁に目にする）

ちなみに その後 この企画が破綻したことは 言うまでもない。

述べたいのは、ExcelやPowerPointのような道具導入を否定することではない。
ただ、ここまで大げさな話ではなくとも、『こんなシステム/ツールを導入したら便利になる、楽になる』『こんな出力ができる様になる』的な発想は日常的に多くある中、部門の定義/企業目的に沿うべく如何に導いてゆくか？を考ることが大変重要であると私は考える。

『【クレームとリコール】という道具を使い、これを削減するための行動をもって経済活動をする部門』という定義に、直接的に貢献/働きかけられるもの　効果を期待できるものでなければ、多額のコストをかけてシステムを開発・導入すべきではない。

これは本来、品質部門やシステム開発だけでなく すべての領域/部門/作業/業務に通じる基本認識であるべきと考える。

#創作大賞2026 #ビジネス部門