マネジメントシステムをフレームワーク化してみる

という話です。

マネジメント「システム」って名前が付くくらいなんですから、仕組みとして体系化されているということですので、ただ文章でつらつら書くだけだとわかりづらいので、モデル化してしまえばいいんです。

モデル化すれば、ダイアグラム（図）で表現できるようになります。

これは、私がQMSとISMS、そしてPMSを１つのマネジメントシステムとして規定や運用の流れを統合しようと思って、検討していた頃のものになります。まぁ、QMSもISMSもバージョンが変わっていませんし、PMSは…2006年版をベースにしていますが、2017年版でも大して差はないので、そのまま活用できると思います。

ここではまず、従来のマネジメントシステムをモデル化していきましょう。と言っても、８章だけは無理ですけど。ここは、共通化を図る部分ではなく、連携させていく部分なので、それぞれのワークフローを連結させるイメージでなければうまくいきません。

前回も最後に説明しましたが、マネジメントシステムは例外なく、すべてＰＤＣＡサイクルをベースにしています。

ＰＤＣＡ自体が、１つのフレームワークですが、これをもう少し対象となる物ごとに整理したものがＩＳＯのマネジメントシステムです。

そして、これも前回説明したように、共通テキストの各章は次のようなつながりを持っています。

これをもう少しＩＳＯ規格にあわせてみたものをモデリングらしく、ＵＭＬにしてみました。

これが一番粒度の粗いフレームワーク構成となります。

では、それぞれ粒度をもう少しＩＳＯ規格の章立てにあわせて細かくしていくとどうなるのでしょう。

計画（Plan）

具体的に落とし込むと、ざっとこのようになります。
これらを、規格の章・項に照らし合わせると…こうなります。

もしも、以前から継続運用しているのであれば、右上の「改善する」ルートからスタートになりますし、初回運用になるようであれば、4.1「組織の状況」からスタートになります。

そして、作業の流れはというと…

こうなります。

以前はあまり触れませんでしたが、５章や６章についても触れていますね。実際、計画まで立てようと思ったら４章だけでは実現できません。

４章は、足元をよく確認して、ゴールを見据えるまでの章です。
５章は、トップの役割定義と、指し示す方向（方針）を決定する章です。
６章になって、やっと具体的かつ実現可能な計画の作成になります。

７章は、８章をスムーズに運用するための環境面や育成面などの準備をしっかりしておくことが求められています。

こうやって見てみると、大きく２つのラインによって、下へと向かっているのがわかりますね。「目的から計画へと進む」ラインと、「リスクの洗い出しから計画へ進む」ラインです。

これらはそれぞれ、何を言っているのかと言うと

赤いラインは、経営あるいはトップからの方針に沿って計画する「プラスにするためのアプローチ」になります。一方で緑のラインは、現状（As-Is）を把握したうえで、理想（To-Be）との間にあるギャップを埋めるための「マイナスを埋めるためのアプローチ」と言ってもいいと思います。

すくなくとも、私はこう解釈しました。

実行（Do）

先ほども申しましたが、この実行フェーズ（８章）はマネジメントシステムごとに全く違います。

ここでは、私がたまたまQMS/ISMS/PMSを運用していたので、そちらについてざっと１枚にまとめてみます。

それぞれの規格の中で重複する部分もありますが、すべてが重複するということはなく、基本的にはそれぞれのマネジメントシステムならではの運用部分が必ずあります。

たとえば、ＰＭＳは機密情報のうちの『個人情報』だけに特化していますが、「情報の取得」「情報の管理」「情報の利用」「情報の廃棄」の４点について厳密にルールが設けられています。

対してＩＳＭＳでは、「情報の管理」についてルール化されていることが殆どで、それ以外については管理上必要とされない限り、あまりうるさく言われていません。

また、ＱＭＳでは取り扱う顧客情報や契約情報、新製品を作るのであればその機密情報などについて、「文書」として保管することや一意に識別することは求められていますが、セキュリティに関する話は一切出てきません。その点についてはＩＳＭＳで補填してあげるしかありません。

このように、「共通化」ではなく「連携」するため、それぞれの業務フローを洗い出して、連結していくことが重要になってきます。

評価（Check）

評価は、以前も書いた通り、

『計画との乖離』を監視し、測定したうえで、分析を重ね、行うものです。そのため、必ず「計画」と「実行」それぞれと強いつながりがあります。

これらを、規格の章・項に照らし合わせると…こうなります。

まさしく９章の中だけに閉じています。

この業務の流れを明確にしてみると…

こうなります。

マネジメントレビューとは、トップマネジメントに定例報告する場のことです。多くの企業では１年に１回行われていると思いますが、適用範囲内のマネジメント実施状況や問題の発生状況、改善状況、現場からの要望や指摘など、様々なデータを集計し、分析した結果を報告します。

そして「レビュー」と言われているように、トップマネジメントはその報告内容を全て確認したうえで、指示／指摘を行います。

これはいわば、トップマネジメントからの「改善要望」です。そのまま経営にも深くかかわることになる物が多いため、ここで提起された課題は比較的優先度が高いものと言えるでしょう。

監視・測定しなければならないものが何であるかは、各業界、各企業ごとに異なりますが、

　スケジュール(計画)監視・管理
　コスト監視・管理
　リソース(資産)監視・管理
　コミュニケーション監視・管理
　ステークホルダ監視・管理

など、一般的なものを見てみると、実はPMBOK（プロジェクトマネジメントの知識体系）とほぼ同じであることがわかりますね。

改善（Action）

改善は、ざっとこのようになります。

改善するためのトリガー（きっかけ）は、大きく３つあります。

　①インシデント（事故になり得る危険な行動や事態、あるいは事故）
　②内外からの改善要望
　③指摘（外部の認証機関、または内部監査からの指摘、推奨等）

です。これらが１件もなくなる状態にするのが最終的なマネジメントシステムの理想となります。とはいえ、ある年だけ１件もなかったとしても、翌年も同じように１件も無い…とは言い切れません。

なぜなら、時代の移り変わりによって、世の中が変化した時、今までのやり方が正しいとは言い切れなくなるからです。常に見直しを行い、改善し続ける気概が必要なのです。

これらを、規格の章・項に照らし合わせると…こうなります。

下段は９章の続きです。見事に10章だけに閉じていることがわかります。この業務の流れを明確にしてみると…

一般的な…というか、私なりに解釈した「是正」「改善」「再発防止」の定義とは、次のようになるものと考えています。

　現状マイナスの値を±０にする　　　　　　　 …是正
　±０にしたものをマイナスにしないようにする …再発防止
　マイナスになる可能性を解消する　　　　　　…改善
　０以上の値を、よりプラスへと向上する　　　…改善

監査や審査などで「観察事項(Observation:ob)」…いまでは「改善の機会」って言うんでしたっけ？、となったものは、この③に該当します（「改善の機会」では④も取り扱われるようになりました）。そのため、是正必須というわけではありませんが、先々マイナスに転じてしまう可能性があるため、対策することが望まれます。

多くの人が「『指摘事項』じゃないなら、別にやんなくてもいっかー」と考えがちですが、それはリスクマネジメントの観点からも推奨できません。

昨今の新型コロナ祭りと同じです。

無自覚な感染者が８割以上と多く、軽症者でも風邪程度の症状でたいしたことない…と軽く見ていたものだから、今まさに収拾のつかない状態になってきていますよね。

人の命を「数字」で見てしまったがために、事態を軽く見てしまって、実際には死者が５０人以上出てしまっていますし、重篤患者もまだまだ増え続けています。

経営でも同じです。

物事の『最悪』を見据えて、致命的な事態にならないよう、先手を打つのがリスクマネジメントの醍醐味です。大赤字、顧客クレーム、倒産など、致命傷となりかねない危機に差し迫ってからでは遅いのです。これは、品質であっても、情報セキュリティであっても、環境であっても、労働安全であっても同じです。