業務改善

「コミュニケーション不足」を疑え 「現場のコミュニケーションが足りないから、トラブルが起きるんだ」――よく耳にする言葉だ。しかし、その一言で片づけてしまうことが、本当の問題解決を遠ざけていないだろうか。 コミュニケーションは確かに大切だ。情報の行き違いや誤解を防ぐためには、円滑なやり取りが欠かせない。だが、それはあくまで“潤滑油”であって、エンジンそのものではない。制度や構造、役割分担が曖昧なままでは、どれだけ話し合いをしても空転するだけだ。 責任を「現場の空気」に押しつける管理職 特に問題なのは、上司や管理職が「コミュニケーション不足」を常套句のように使い、現場の責任にしてしまうケースだ。例えば、業務フローが不明確でタスクの抜け漏れが発生した場合に、「もっとちゃんと話し合って」と指導して終わらせる。これは、構造的な設計ミスを現場に押しつけているにすぎない。 このような現象が続くと、現場では「空気を読んで動け」という圧力が強まり、曖昧な期待と責任だけが積み重なる。結果、誰もリスクを取らず、問題が発覚してから「誰が悪いのか」という犯人探しになる。これでは健全な業務改善は望めない。 RACIマトリクスという処方箋 そこで有効なのが、責任と情報の流れを明確化するためのフレームワーク、RACIマトリクスだ。これは、以下の4つの役割を明示することで、組織内の混乱や責任の曖昧さを解消する。 R（Responsible）：実行責任者 A（Accountable）：最終責任者（意思決定者） C（Consulted）：相談・助言を行う立場 I（Informed）：情報提供を受ける立場 ケース1：伝言ゲーム式の指示ミス 現場でよくある誤解：指示ミスを「コミュニケーション不足」で片づける 実際に、管理職から現場作業員への指示が曖昧なままトラブルが起きた場面がある。ある業務では、管理職が口頭で作業員Aに指示を出し、それを作業員Aが引き継ぎで作業員Bに伝えた。結果として指示がうまく伝わらず、作業ミスや遅延が発生した。 このとき、管理職は「コミュニケーション不足だ！」と現場を叱責したが、問題の本質はそこではなかった。 管理職は、作業指示を文書化していたのか？ 作業員が後から確認できる手順書・基準書を整備していたのか？ 引き継ぎのルールは明文化されていたのか？ 属人化を防ぐための標準化は行われていたのか？ これらを整備・運用する責任は、現場の個人ではなく管理職側にある。にもかかわらず、表面的な「コミュニケーション不足」論で問題の構造が見過ごされている。 このような事例こそ、「構造としての不備」を見直すべき典型例だ。 ケース2：サンプル持ち込みによるヒヤリハット 管理職がサンプル品を持ち込み、「ここに仮置きするから」と量産作業中の現場作業員に口頭で伝えた。しかし、作業員はその場での聞き取りが不十分だったり、サンプルの扱いが曖昧だったりしたため、サンプル品を量産品と誤って混ぜそうになるというヒヤリハットが発生した。 このとき管理職は「サンプルだって言って渡しただろうが！」と憤慨したが、そもそも問題はそこではない。 量産ラインにサンプル品を持ち込むべきではなかったのでは？ 作業に集中している作業員に、口頭での情報伝達を行ったのは適切だったのか？ サンプルの取り扱いルールや受け渡しの手順は整備されていたか？ つまり、このケースは「コミュニケーションの内容」に問題があったのではなく、そもそもコミュニケーションの“発生させ方”が管理として不適切だったのである。 現場での安全や品質が要求される製造業では、「話して伝える」こと自体がリスクである場面がある。話さずとも正しく伝わる仕組み――それこそが、管理職に求められる“仕組みの設計”なのである。 このような例まで「コミュニケーションが悪い」と片付けてしまうことは、現場の緊張感や設計上の問題を見過ごす危険な思考である。以下のような場面もある。 ケース3：指示否認による混乱 「この作業はこうしておいて」とその場で指示。作業員はその通りに実施したが、後日トラブルが発生。すると、管理職は「そんな指示はしていない」と発言。現場にいた他の作業員や間接員は「いや、そういう指示してましたよね？」と困惑する。 このようなケースでは、口頭指示が記録に残らず、証拠も曖昧で、責任の所在がうやむやになる。まさに、文書化・標準化・情報共有の仕組みがなかったことによる典型的な問題であり、「指示内容が確認できる媒体がなかったこと」が本質的な原因である。 こうした構造の欠陥を放置したまま、「もっとよく話し合っていれば防げた」と現場に責任を求めるのは、単なる責任転嫁でしかない。 ケーススタディ：製品トラブル時のRACIマトリクス たとえば、製品トラブル発生時の対応を考えてみよう。 タスク R A C I 不具合の初期対応 技術担当 現場マネージャー 品質保証 営業 原因調査 技術担当 技術部長 品質保証、製造 営業、顧客対応部門 顧客への説明 営業 営業マネージャー 技術、品質保証 法務 このように整理することで、「誰に話すべきか」「誰が決定するのか」「誰まで情報を回すか」が明確になり、無駄な確認や後出しジャンケンを防げる。 定常作業こそ「コミュニケーションが不要」な状態が理想 筆者の立場から言えば、極論かもしれないが、定常作業であるならば「コミュニケーションが発生しない」状態こそが理想だと考えている。 なぜなら、定常作業とは本来、手順・品質・安全のすべてがルール化・標準化されており、教育・訓練・力量評価も事前に完了しているべきものだからだ。つまり、「誰がやっても同じ品質・手順で、同じ成果が出せる」状態でなければならない。 したがって、わざわざ毎回「こうやって」「あれは気をつけて」などと声をかけなければならない状況というのは、裏を返せばその作業はまだ非定常であり、手順・訓練・仕組みが未整備であるという証拠でもある。 つまり、コミュニケーションが頻発していること自体が“業務設計の未熟さ”を示すパラメータになり得るのだ。 だからこそ、「もっとちゃんと話し合って」は業務改善の解決策ではなく、むしろ構造的な不備をごまかす“思考停止ワード”になりかねない。 組織内の問題が起きたとき、まず疑うべきは「コミュニケーション不足」ではなく、「仕組みや責任の曖昧さ」だ。会話は大事だが、それだけでは回らない。エンジンがなければ、どんなに滑らかな潤滑油も意味をなさないのだ。 だからこそ、真の業務改善には制度設計と責任設計の見直しが必要だ。「話せばわかる」ではなく、「仕組みで回る」組織こそが、現場に余裕と成果をもたらすのだ。

製造業におけるOODAとDMAICの実務的な使い分け 結論：製造業にはDMAICを基本に、緊急時や戦略領域にOODAを補完的に使うのが最適 製造業における業務改善や問題解決において、PDCA・OODA・DMAICといった各種フレームワークが語られることが多いが、実務家の視点に立てば、言葉に振り回されるのではなく、「どう制度に落とし込むか」が重要である。以下に、現場適合的なフレームワーク運用方針をまとめる。 DMAICの優位性と実務導入 製造業においては、DMAIC（Define, Measure, Analyze, Improve, Control）はPDCAの実質的な強化版である。 工程能力評価、ヒストグラム、ばらつき管理など、技術者にとっては「昔からやっていたこと」を言語化・構造化したものにすぎない。 特にControlフェーズが「標準化・再発防止策の定着」という、PDCAの弱点を補完している点で価値が高い。 DMAICという用語そのものに抵抗がある場合は、PDCAの中で次のように規定強化すれば同様の運用が可能： Plan：必ずデータに基づく仮説設計を含む Act：標準化と教育・監視体制整備を含める OODAの役割：緊急対応・戦略構築に適用 OODA（Observe, Orient, Decide, Act）は、即時判断と迅速行動を重視する思考モデルであり、改善活動のような分析重視プロセスには不向きだが、以下においては極めて有効である。 緊急時の品質トラブル初動対応 初期サンプル失敗時の再計画 顧客からの突発クレーム対応 また、OODAは製造業における事業戦略構築にも向いている。事業戦略には標準化や長期的プロセスの定着よりも、「現状把握」「変化への即応」「方向性判断」が求められる。つまり、OODAは業務改善ではなく、組織の意思決定や方向づけにこそ有効。 開発スタイルとの対応：ウォーターフォール vs アジャイル ウォーターフォール開発（製品設計、制御開発、医療機器など） 要求が明確で工程も安定 → DMAICが適合 要件定義、仕様分析、設計検証などにDMAICを適用しやすい アジャイル開発（Webサービス、UI設計、IoT試作など） 不確実性が高く、反復改善が必要 → OODAが適合 観察→判断→行動→学習の高速ループが求められる ケース別運用：DMAICとOODAの成否例 ケース1：不良率の慢性的な高さ（DMAICが適合） DMAICを使う → 原因分析、再発防止、標準化まで到達して不良率が安定的に低下 OODAで対応 → 原因の深掘りが不十分で場当たり対応になり、再発のリスク大 ケース2：出荷直前の異常発覚（OODAが適合） OODAを使う → 状況把握と即断で損失最小限、信頼維持 DMAICを使う → 初動が遅れ、顧客対応の遅延でクレーム拡大の可能性 最適なフレームワーク運用設計 DMAIC＝戦略的・計画的実行に使用（例：品質目標、設計プロセス見直し、標準化整備） OODA＝戦術的・突発的実行に使用（例：緊急対応、トラブル時の初期判断） 両者を制度上明確に分け、以下のようにルール化しておけば、混乱は避けられる。 DMAIC：標準業務の改善サイクル OODA：緊急判断フローや事業再構築フェーズ 結語 OODAとDMAICの違いを議論することは知識としては重要だが、実務で最も重要なのは「どの業務に、どの考え方を適用するか」を設計することである。製造業においては、PDCAを正しく深く運用する形でDMAICの考え方を取り込み、緊急時や戦略策定においてのみOODAを補完的に使うことで、最適な制度運用が実現できる。

教育して対策しました！の駄目さ加減 品質トラブルが発生した際、「教育して対策しました！」という報告を耳にすることがある。しかし、これは本当に対策になっているのだろうか？多くの現場で、この言葉が再発防止策の常套句として使われているが、品質管理の視点から見ると、非常に問題があると言わざるを得ない。 教育は対策ではない そもそも、「教育」は対策ではない。これを明確に理解しているのは、品質管理の原理原則をよくわかっている顧客や社内の品質保証部門、または失敗学などを真面目に学んだ人々である。逆に言えば、それを理解していない人ほど、トラブル報告の是正措置として安易に「教育しました」と書いてしまう。 なぜ教育が対策にならないのか。それは、人間という存在が「忘れる」ものであり、かつ「交代する」ものであるからだ。教えた本人が現場を離れたとき、また新しい作業者が加わったとき、口頭での伝承や一時的な教育に頼る体制は、あまりにも脆弱だ。 理想はハード的対策 理想的な対策とは、ポカヨケ装置の導入や、設備の構造的な改善など、物理的・機械的に不具合が起こらないようにすることである。いわゆる「ハード的対策」だ。これこそが、再発防止における本質的なアプローチである。人に頼る「ソフト的対策」とは異なり、環境そのものを変えることで、ミスを起こしようのない状態にする。 もちろん、すべてのトラブルにハード的対策を講じるのは難しい。コストや工数、設備の制約がある。だが、だからといって「教育しました」で済ませてよいはずがない。 人による対策を有効にするために ハード的対策が難しいときには、人に頼らざるを得ない。だが、その場合でも最低限守るべきことがある。「教育しました、以上」では話にならない。 教育用資料を作成する 手順書を明文化する 教育記録を残す 新たな作業者には必ず教育を実施し記録する 教育を受けていない者は作業できないというルールを設ける このように、教育そのものを制度化し、運用ルールとして管理できる仕組みを構築しなければならない。「自然な教育」「現場での伝承」に頼るようでは、管理者として失格である。仮にそれでうまくいったとしても、それは現場作業者が優秀だっただけであり、管理体制としては何もしていないのと同じである。 おわりに 「教育して対策しました！」という報告が出てきたとき、ぜひ一歩立ち止まって考えてほしい。それは本当に再発を防げるのか？　教育とは何を指すのか？　ルールと仕組みとして定着させる手段を講じているのか？ 品質を守るとは、再発を防ぐこと。そのためには、人に頼らない対策、あるいは人に頼る場合でも“仕組み”として成り立つ管理が不可欠である。教育は対策の一部かもしれないが、それ単体では“対策”とは言えない。 “教育＝対策"という思考停止から脱しよう。