そして年度の最終月に…
あー…1つやらなきゃいけないことが…orz
マネジメントシステム原則の趣旨
JISQ15001:2006をベースにした個人情報保護マネジメントシステム実施のためのガイドライン 第1版の6ページ「1. 個人情報保護マネジメントシステムについて」の記述に、以下のような記述がある（わかりやすいように、一部箇条書きにした）
- 方針を作成し、
- それに基づいて計画を作成し(Plan)、
- 実施し(Do)、
- 点検し(Check)、
- 見直し(Act)を行う
という、いわゆるPDCAサイクルをスパイラル的に継続することにより、事業者の管理能力を高めていくことにある。
非常にアバウトではあるが、理解はできるし共感もする。
マネジメントシステムの方針と実際のものへのあてはめ
マネジメントシステムを実施する理由は、あくまで「事業者の管理能力を高めていく」ためである。
では、管理能力をなぜ高める必要があるのか。そこの鍵は、○○マネジメントシステムの「○○」に入る言葉によって補完される。
例として、ISMS（情報セキュリティマネジメントシステム）を挙げてみよう。
- 情報セキュリティマネジメントシステムを実施する理由は、事業者の「情報セキュリティ」管理能力を高めていくことである。
決して「情報セキュリティ」を高く保つことではなく、情報セキュリティ管理を行う能力であることに注意したい。
同じように、個人情報保護マネジメントシステムにもこの原則を当てはめてみる。
- 個人情報保護マネジメントシステムを実施する理由は、事業者の「個人情報保護」管理能力を高めていくことである。
あたりまえだが、「個人情報保護」そのものよりは、その体制や実施を行う一連の取り組みを高いレベルに持っていくことが目的である。情報をロックアウトして、必要な人以外は見れないようにした、というレベルではなく、個人情報保護という目的のもと、各種管理が正しく機能していることを求められる。
誰のためのマネジメントシステムなのか〜みんなのためのもの
ここまで読んだら、マネジメントシステムは「誰か一人ががんばった」からどうなるものでもない、ということが直感的に理解できるはずだ。
もちろん、経営層がその取り組みを理解・推進することは必要であるし、そのために必要な現場のアクティビティも必要となる。そして、経営層と現場の間をつなぐマネジメント層による「正しい理解と実践」も重要となる。
言うならば、「組織に属する人たち」が各々のロールを理解し、全うすることが重要となる。
正直「めんどくせえ」ことこの上ないと思うだろうが*1、ある程度の規模や実績を伴う組織／会社において、マネジメントシステムがまともに機能していない（もしくはない）組織は概して刹那的になりがちになるのだろう。逆に、この部分がまともに機能している組織は、場合によっては地味目に映るかもしれないが、非常に堅い運営を行っていることがわかる。
このあたりは、日科技連のWebページをざっと見てみると、想像できるところもあるだろう（オレ自身は、実務からそれを実感しているが…）。
*1:オレもそう思っていたし、今でも実はそう思っている
マネジメントシステムの維持とコスト〜誰が負担するのか〜
マネジメントシステムを構築・維持運用していくにはコストがかかる。で、このコストはたいていの場合、製造物やサービスの価格に反映される。
QMS（品質マネジメントシステム）の場合、製造物やサービスの品質向上に係るマネジメントシステムの構築となるはずなので、これはエンドユーザに対する製品やサービスの魅力向上*1となって現れる。
ISMS（情報セキュリティマネジメントシステム）とPMS（個人情報保護マネジメントシステム）の場合、場合によっては製造物やサービスの品質向上にもつながるだろうが、どちらかというと、「組織の信頼性向上」につながる部分が大きいため、製造物やサービスの品質向上のように「目に見える」とは言いがたい。しかし、この部分のコストもエンドユーザに対する製品やサービスの価格に反映されることになる。
QMSの場合、たいていの場合はマネジメントシステムの構築と運用を行うプロセスを実施することで、「組織の信頼性向上」に寄与することが多い。言ってしまうと、「中からも外からも成果が見える」性質のものである。
しかし、ISMSとPMSは、やったからといって何が起こるわけでもない。むしろ手間ばかりが増えるように見えるわりには、「何か自分らにとって良いことが見える」というようにも見えない。
おそらく、現場が嫌がるのは、この「やることで手間が増える」という点に尽きるだろう。そうなると、いったい誰が率先してやるのだろうか。
*1:壊れやすかったり、すぐ止まるようなモンなど誰もほしがらないだろうから
客観的な視点でのプロセス評価とインセンティブ〜中の人にも成果に応じた評価を〜
QMSは、最終的な「製品やサービスの品質」が高まり、その結果としてお客様満足度が向上するということで、内部的な評価につながる。
しかし、例えばISMSはどちらかというと、「実践しないことで情報セキュリティの管理レベルが落ちるリスク」が強調される。どちらかというと「やってあたりまえ。やらないところは評価が下がる」というようになりがちだ*1。
ついでに言うならば、取り組んでも取り組んだ現場の人たちが評価されるよりはむしろ、「旗を振る側だけ」が評価されがちだ。
もちろん、旗を振る側がそれを浸透させるのは、大変な苦労をしていると思うので、これについては異論はない。しかし、実際に動く現場が「やったからといって評価される」かというと、話は別である。
出来ることならば、このあたりの実施も、「高いレベルで実施できる＝現場に対するインセンティブが付与される」ような形で出来ると良いのではないか。
このあたりはPMSも同じだ。
正直、北風*2だけでは人はなかなか動かない。本気でISMSやPMSの構築に取り組むのであれば、現場の取組を評価できるような仕組みもあわせて構築すべきだろう。
事例は重要だが、その内容の公開レベルを考えることはもっと重要
よしおかさんのエントリで、なんかあれこれ書かれてるのをざっと読んだ。元エントリよりはむしろ、そこから出てきた議論の流れのほうが、今のオレにとっては有用に感じられたのだが*1。
特に重要と感じたのは、以下のくだり。
「こんな失敗したよ」という体験的なものは果たして役に立っているのだろうか？たぶんだけど、体験的な情報はよほどの分析を伴わない限り役に立たない。
これは、成功の経験にもあてはまる。
失敗でも成功でも、「前提」「仮説」「実施」「検証」「結果」「考察」の6つが伴わない限りは、単なる経験談にしかならない*2。同じコトやっても失敗した（例：git導入してもリポジトリ管理がうまくいかなかった）という話が出た時に、「同じことやったのに…」とも言われかねない。ちとかっこよくｗ言うと、ベストプラクティスの真の共有には程遠い。
結果によらず経験談が公開されるのは良い傾向だが、その内容どおりにやって「自分ところもうまくいった」というところまでいくためには、「送り手の配慮」や「受け手の考察」が必要となる*3。せっかく情報を出してくれてるのに、これ以上送り手に負担はかけられないとなると、受け手のスキルが要求されるところだ*4。
このあたり、マネジメントシステムの審査内容とか結果を見てる立場としては気になるところだが、
- ストロングポイント（良いところね）
- 改善指摘
- 改善の機会
あたりが明確にわかるように書いてあるだけでもだいぶ違う。もしくは、受け手はこのあたりを意識して成功／失敗事例を見るようにするだけでもだいぶ違う。
いろいろ書き散らしたが…
失敗事例や成功事例として重要なのは「前提」「仮説」「実施」「検証」「結果」「考察」であり、「誰」というのは重要ではないと感じている。
もちろん、最初に情報が出る際には、上記で重要としている内容がすべて出るわけでもなんでもないのは承知だ。
しかし、受け手がそれを見て、仮説や考察を補完するなりして、それを公開していくことで、情報としてより有用なものに仕上がっていくのではないか。
ここまでの内容について、まったくもって「こんなあたりまえのコトをぐだぐだと」とか「何をまた上から目線で書いてやがる」といわれてもしょーがない内容だが*1、マネジメントシステムの目的やら何やらを見てて、今のところ事例や経験をどう扱うか？という（オレなりの）結論ということで。
*1:状況を俯瞰的にながめて、起こったことや想定できることを書いてみることは、上から目線とは（オレ自身は）思ってないけど、「何をえらそーに」と思う人は絶対にいるだろう。そういう意味で書いている。
