wakatonoの戯れメモ このページをアンテナに追加 RSSフィード

たわいもないこと(日々の妄想とも言う)をつらつらと書いてます。断じて壊れメモではありません。ましてや「穢れメモ」でも爛れメモでもありません(涙)。
が、時により一つのことを掘り下げる傾向が見られるので、article数は少ないカモ。
ちなみにSlashdot Japanの日記もあります。個人的な連絡がある方はwakatono@todo.gr.jpまで("@"は2バイト文字になってるんで、てけとうに書き直してください)。GnuPG公開鍵はこちら

他のあたり:PFSEC - Systems Platform and Securityアマゾンのレビュー

強いWindowsの基本 WebDAVシステム構築ガイド(萌えバナーその1)
WebDAVシステム構築ガイドの方のバナーの絵柄は、内容とは何の関係もありません(汗)
アクセス探偵IHARA

おとなり日記はこちら

2009-03-21 3連休〜

なんかうれしいぞw

[]バー充 バー充を含むブックマーク バー充のブックマークコメント

バーチャル充実→バー充

リア充(リアル生活が充実)の対語として使い始めたw

2009-03-01 そして年度の最終月に…

あー…1つやらなきゃいけないことが…orz

[]まっちゃ445でのライトニングトーク まっちゃ445でのライトニングトークを含むブックマーク まっちゃ445でのライトニングトークのブックマークコメント

ライトニングトーク自体久々。

やったのは、Webtunnelの紹介と危険性、そして対応。

プレゼンテーション資料はこちら

[]マネジメントシステムを理解するということ マネジメントシステムを理解するということを含むブックマーク マネジメントシステムを理解するということのブックマークコメント

オレは別に、管理が好きなわけでもなければ、品質マニアでもない。

でも、ISMS(ISO27001)、PMS(JIS Q 15001)、QMS(ISO9001)に共通する特徴である「マネジメントシステム」の構築と運用管理には興味があるし、部分的にではあるけど(出来る範囲で)実践してるつもりw

[]マネジメントシステム原則の趣旨 マネジメントシステム原則の趣旨を含むブックマーク マネジメントシステム原則の趣旨のブックマークコメント

JISQ15001:2006をベースにした個人情報保護マネジメントシステム実施のためのガイドライン 第1版の6ページ「1. 個人情報保護マネジメントシステムについて」の記述に、以下のような記述がある(わかりやすいように、一部箇条書きにした)

  • 方針を作成し、
  • それに基づいて計画を作成し(Plan)、
  • 実施し(Do)、
  • 点検し(Check)、
  • 見直し(Act)を行う

という、いわゆるPDCAサイクルスパイラル的に継続することにより、事業者の管理能力を高めていくことにある。

非常にアバウトではあるが、理解はできるし共感もする。

[]マネジメントシステムの方針と実際のものへのあてはめ マネジメントシステムの方針と実際のものへのあてはめを含むブックマーク マネジメントシステムの方針と実際のものへのあてはめのブックマークコメント

マネジメントシステムを実施する理由は、あくまで「事業者の管理能力を高めていく」ためである。

では、管理能力をなぜ高める必要があるのか。そこの鍵は、○○マネジメントシステムの「○○」に入る言葉によって補完される。

例として、ISMS(情報セキュリティマネジメントシステム)を挙げてみよう。

決して「情報セキュリティ」を高く保つことではなく、情報セキュリティ管理を行う能力であることに注意したい。

同じように、個人情報保護マネジメントシステムにもこの原則を当てはめてみる。

  • 個人情報保護マネジメントシステムを実施する理由は、事業者の「個人情報保護」管理能力を高めていくことである。

あたりまえだが、「個人情報保護」そのものよりは、その体制や実施を行う一連の取り組みを高いレベルに持っていくことが目的である。情報をロックアウトして、必要な人以外は見れないようにした、というレベルではなく、個人情報保護という目的のもと、各種管理が正しく機能していることを求められる。

[]誰のためのマネジメントシステムなのか〜みんなのためのもの 誰のためのマネジメントシステムなのか〜みんなのためのものを含むブックマーク 誰のためのマネジメントシステムなのか〜みんなのためのもののブックマークコメント

ここまで読んだら、マネジメントシステムは「誰か一人ががんばった」からどうなるものでもない、ということが直感的に理解できるはずだ。

もちろん、経営層がその取り組みを理解・推進することは必要であるし、そのために必要な現場のアクティビティも必要となる。そして、経営層と現場の間をつなぐマネジメント層による「正しい理解と実践」も重要となる。

言うならば、「組織に属する人たち」が各々のロールを理解し、全うすることが重要となる。

正直「めんどくせえ」ことこの上ないと思うだろうが*1、ある程度の規模や実績を伴う組織/会社において、マネジメントシステムがまともに機能していない(もしくはない)組織は概して刹那的になりがちになるのだろう。逆に、この部分がまともに機能している組織は、場合によっては地味目に映るかもしれないが、非常に堅い運営を行っていることがわかる。

このあたりは、日科技連のWebページをざっと見てみると、想像できるところもあるだろう(オレ自身は、実務からそれを実感しているが…)。

[]マネジメントシステムの維持とコスト〜誰が負担するのか〜 マネジメントシステムの維持とコスト〜誰が負担するのか〜を含むブックマーク マネジメントシステムの維持とコスト〜誰が負担するのか〜のブックマークコメント

マネジメントシステムを構築・維持運用していくにはコストがかかる。で、このコストはたいていの場合、製造物やサービスの価格に反映される。

QMS(品質マネジメントシステム)の場合、製造物やサービスの品質向上に係るマネジメントシステムの構築となるはずなので、これはエンドユーザに対する製品やサービスの魅力向上*2となって現れる。

ISMS(情報セキュリティマネジメントシステム)とPMS(個人情報保護マネジメントシステム)の場合、場合によっては製造物やサービスの品質向上にもつながるだろうが、どちらかというと、「組織の信頼性向上」につながる部分が大きいため、製造物やサービスの品質向上のように「目に見える」とは言いがたい。しかし、この部分のコストもエンドユーザに対する製品やサービスの価格に反映されることになる。

QMSの場合、たいていの場合はマネジメントシステムの構築と運用を行うプロセスを実施することで、「組織の信頼性向上」に寄与することが多い。言ってしまうと、「中からも外からも成果が見える」性質のものである。

しかし、ISMSPMSは、やったからといって何が起こるわけでもない。むしろ手間ばかりが増えるように見えるわりには、「何か自分らにとって良いことが見える」というようにも見えない。

おそらく、現場が嫌がるのは、この「やることで手間が増える」という点に尽きるだろう。そうなると、いったい誰が率先してやるのだろうか。

[]客観的な視点でのプロセス評価とインセンティブ中の人にも成果に応じた評価を〜 客観的な視点でのプロセス評価とインセンティブ〜中の人にも成果に応じた評価を〜を含むブックマーク 客観的な視点でのプロセス評価とインセンティブ〜中の人にも成果に応じた評価を〜のブックマークコメント

QMSは、最終的な「製品やサービスの品質」が高まり、その結果としてお客様満足度が向上するということで、内部的な評価につながる。

しかし、例えばISMSはどちらかというと、「実践しないことで情報セキュリティの管理レベルが落ちるリスク」が強調される。どちらかというと「やってあたりまえ。やらないところは評価が下がる」というようになりがちだ*3

ついでに言うならば、取り組んでも取り組んだ現場の人たちが評価されるよりはむしろ、「旗を振る側だけ」が評価されがちだ。

もちろん、旗を振る側がそれを浸透させるのは、大変な苦労をしていると思うので、これについては異論はない。しかし、実際に動く現場が「やったからといって評価される」かというと、話は別である。

出来ることならば、このあたりの実施も、「高いレベルで実施できる=現場に対するインセンティブが付与される」ような形で出来ると良いのではないか。

このあたりはPMSも同じだ。

正直、北風*4だけでは人はなかなか動かない。本気でISMSPMSの構築に取り組むのであれば、現場の取組を評価できるような仕組みもあわせて構築すべきだろう。

[]事例は重要だが、その内容の公開レベルを考えることはもっと重要 事例は重要だが、その内容の公開レベルを考えることはもっと重要を含むブックマーク 事例は重要だが、その内容の公開レベルを考えることはもっと重要のブックマークコメント

よしおかさんのエントリで、なんかあれこれ書かれてるのをざっと読んだ。元エントリよりはむしろ、そこから出てきた議論の流れのほうが、今のオレにとっては有用に感じられたのだが*5

特に重要と感じたのは、以下のくだり。

「こんな失敗したよ」という体験的なものは果たして役に立っているのだろうか?たぶんだけど、体験的な情報はよほどの分析を伴わない限り役に立たない。

これは、成功の経験にもあてはまる。

失敗でも成功でも、「前提」「仮説」「実施」「検証」「結果」「考察」の6つが伴わない限りは、単なる経験談にしかならない*6。同じコトやっても失敗した(例:git導入してもリポジトリ管理がうまくいかなかった)という話が出た時に、「同じことやったのに…」とも言われかねない。ちとかっこよくw言うと、ベストプラクティスの真の共有には程遠い。

結果によらず経験談が公開されるのは良い傾向だが、その内容どおりにやって「自分ところもうまくいった」というところまでいくためには、「送り手の配慮」や「受け手の考察」が必要となる*7。せっかく情報を出してくれてるのに、これ以上送り手に負担はかけられないとなると、受け手のスキルが要求されるところだ*8

このあたり、マネジメントシステムの審査内容とか結果を見てる立場としては気になるところだが、

  • ストロングポイント(良いところね)
  • 改善指摘
  • 改善の機会

あたりが明確にわかるように書いてあるだけでもだいぶ違う。もしくは、受け手はこのあたりを意識して成功/失敗事例を見るようにするだけでもだいぶ違う。

[]いろいろ書き散らしたが… いろいろ書き散らしたが…を含むブックマーク いろいろ書き散らしたが…のブックマークコメント

失敗事例や成功事例として重要なのは「前提」「仮説」「実施」「検証」「結果」「考察」であり、「誰」というのは重要ではないと感じている。

もちろん、最初に情報が出る際には、上記で重要としている内容がすべて出るわけでもなんでもないのは承知だ。

しかし、受け手がそれを見て、仮説や考察を補完するなりして、それを公開していくことで、情報としてより有用なものに仕上がっていくのではないか。

ここまでの内容について、まったくもって「こんなあたりまえのコトをぐだぐだと」とか「何をまた上から目線で書いてやがる」といわれてもしょーがない内容だが*9マネジメントシステムの目的やら何やらを見てて、今のところ事例や経験をどう扱うか?という(オレなりの)結論ということで。

*1:オレもそう思っていたし、今でも実はそう思っている

*2:壊れやすかったり、すぐ止まるようなモンなど誰もほしがらないだろうから

*3:実際、これをやったからといってお金を直接的に稼げるようになるわけではない

*4:やらないと現場の評価下げる/やっても現場を評価しない

*5:失礼極まりないが、書いてしまうことにする

*6:もちろん、経験談でもないよりはあったほうが良いという向きもあるかもしれないが

*7:どちらかは不可欠となる

*8:これは、質問力とか想像力とかか

*9:状況を俯瞰的にながめて、起こったことや想定できることを書いてみることは、上から目線とは(オレ自身は)思ってないけど、「何をえらそーに」と思う人は絶対にいるだろう。そういう意味で書いている。

ルフィア爺ルフィア爺 2009/03/02 00:42 ワシは管理は大嫌いじゃが品質管理にはウルサイ天の邪鬼じゃて(苦笑。そいでも若いときは,真贋判定のために150名の指揮管理を任されて死ぬ思いをしたぞなも。
そのとき教訓じゃがの。PDCAサイクルでCをさぼる(誤魔化す)とAが楽になることに気付く輩が増殖したことじゃて。あと,Aで弁明するために意図的な不正バイアスをかけてCで歪める策士が出現したことじゃて(怒。
いずれも最終処分時のワシの品質管理段階(ファイナルオーラスC)で発覚したんじゃが(爆。こういうサボりや不正をやるのは若い人よりロートルが多かったのが不思議に思えたが,甘い汁を吸ってでも家計費の増大(師弟の学費等)に充てるため,今の高給にしがみつこうとするロートルが多いみたいじゃったで…。

wakatonowakatono 2009/03/07 05:22 もはやしょうがないともいえますが、PDCAのCでかかるバイアスを見抜くのは、監査を行う人の腕ともいえます。
つうか、そこが機能していないとコントロールが出来てないというように判断されてしまうので、やっぱ自然と見る目が厳しくなります。

0000 | 00 | 01 |
2003 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 04 | 05 | 06 | 07 | 08 |
2011 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 12 |
2012 | 01 |
2013 | 05 | 06 | 07 | 08 | 09 | 12 |
2014 | 03 | 06 | 08 |
2015 | 02 | 04 | 08 | 10 |
2016 | 02 | 03 | 04 | 07 | 08 | 10 |
2017 | 05 | 07 |
hacker emblem
ページビュー
1882003