PDCAはサイクルではなく同時進行させるべきもの

PDCAをサイクルにしようとすると、おかしくなる。

PDCAは4本同時進行させるべきものだ。

Plan, Do, Check, Actではなく、Planning, Doing, Checking, Actingとして同時に-ingさせるもの。

そのようにすれば、PDCAのAがActなのかActionなのかとか、PDCAよりOODA(Observe, Orient, Decide, Act)の方がいいとかは、大したことではなく、むしろ、組織ごとに気になることがあれば、5本以上走らせたっていい。

アイゼンハワー大統領がノルマンディ上陸作戦の計画段階で言ったとされる言葉がある。

"Plans are nothing, planning is everything."

PlanではなくPlansと複数形なこと、planではなく日本語にしにくいplanningであることの意味を十分にくみ取った邦訳が見当たらなかったので、自分なりに訳すとこんなかんじ。

「計画（書）に熟慮を重ねることが重要なのではない，計画（作業）を継続することが重要なのである．」

だから、PDCA Cycleと言わずに、PDCA Threadsと呼ぶ方がよい。

BYOD導入のための３ステップ

フレックスタイム制を導入した企業が、それを中止することがあるそうだ。

ダイヤモンド・オンラインの記事「フレックスタイム制が好評なのに廃止へ向かう理由」

フレックスタイム制を外形的にだけ導入してしまうと失敗することは、あり得るだろうなと思った。

フレックスタイム制導入の前には、業務の成果査定体制が必要で、それが問題なくできるようになってから、フレックスタイム制を導入できる。
フレックスタイム制を問題なくこなせれば、フレックスワークプレース（テレワーク）を導入でき、それも問題なくこなせたら、いよいよＢＹＯＤの導入ができる。
ひとつ前のステージを完璧にこなしてから、次のステージに進むべきという、組織論のピーターの法則の典型例のようなものだ。

上記の記事で書いているような、勤務時間がルーズになることは問題なくて（というか、それがフレックスタイムなのでは？というかんじｗ）、ルーズでも成果を出してもらえばよく、その成果をどのように評価するかを決めて、それに則って現場の管理職が査定できるかが問題だと思うのだけれど、どうだろうか。

そういえば、ＢＹＯＤはＩＴ戦略に位置付けるのではなく、人事政策に位置付けるべきという紹介を何度かした気がしたので、昔の講演を探してみた。
ご興味あれば、ご笑覧ください。

YouTube「BYOD導入のための３ステップ」

リスクは細部に宿りたもう

「リスクの集中管理」と言った場合に、リスクを集中的に管理するというのは、リスク管理作業を集中化するということを意味するのではないと思っている。
そのように集中化できることを否定はしないが、そのようにするには、リスク管理のスーパーマンを想定しなければならない。

すべての企業にそんなスーパーマンはいるのだろうか？
いたら頼めばよいが、いなかったら育成するのだろうか？
育成できないならあきらめるしかないのだろうか？

そんなことについての考えを、翔泳社の IT Compliance Web が取材でまとめてくださったので、よかったらどうぞ。
もとは雑誌の記事だったけれど、Ｗｅｂにも掲載されたのでお読みください。

IT Compliance Web

　「リスクは集中管理できるのか～企業における法対応とITのバランス」

公益通報者保護制度

2006年4月1日から、公益通報者保護法が施行されますね。

内閣府がこれのポータルサイトを用意してくれており、とてもよくできています。

ただ、公益通報者保護を Whistleblower Protection と英訳するのは、いただけません・・・

内閣府の「公益通報者保護制度ウェブサイト」は、

　http://www5.cao.go.jp/seikatsu/koueki/index.html

として公開されています。

法条文そのものの他に、運用上のガイドラインや報告様式の雛形なども用意してくれています。
また、立法時の審議内容や諸外国の動向調査報告書などを、まとめてくれており、ポータルサイトとしてよくできています。
他の法律もこれくらいのことをやってくれていると大変ありがたいです。
他の事案についても、立法審議時、施行時、施行後の政府としての情報提供のお手本として見習って欲しいものです。

ところが・・・
ちょっと残念だったのは、このポータルサイトそのものではなく、内閣府のホームページのリニューアルです。2006年1月6日にリニューアルされたのですが、それまでは、ホームページから、上記のポータルサイトには、「公益通報者保護制度」という見出しからワンクリックでアクセスできたのに、リニューアルによって、２クリックになってしまいました。ワンクリックできるといいのに。。。
ということで、クリック１回分の違いだけなのですが、ここに URL を残しておくことにしたのでした。ｗ

本題に戻りますが・・・
関連情報のポータルサイトとしてお奨めしますが、現時点での、公益通報者保護法制度の内容そのものについては、まだ議論の余地が多くありそうです。

まず、このサイトでは、公益通報者保護を Whistleblower Protection と英訳していますが、これはやめた方がいいと思っています。
Whistleblower Protection の邦訳は、内部告発者保護でよいと思います。正確には、内部はなくて、単に告発者保護だとは思いますがまぁいいでしょう。
そこで、なぜ、公益通報者保護を Whistleblower Protection と訳さないほうがよいかというポイントはいくつかあります。
・Whistleblower Protection = 内部告発者保護と思われており、そうすると公益通報者保護＝内部告発者保護と誤解される。しかし、公益通報者保護制度は、外部告発者も対象にしている。・・・でも、これは些細なことです。
・内部告発者保護は、不正の告発を広く対象にするが、公益通報者保護制度は、公益通報を限定的に定めている。・・・こっちが大きな違い。

今後の運用の議論の中で、これらの違いがなくなって、公益通報者保護＝告発者保護となれば、それ以後は、公益通報者保護を Whistleblower Protection と英訳してよいと思いますが、それまでは言葉による誤解を生じることになるのでやめたほうがよいと思います。

たとえば、個人情報保護をプライバシー保護と混同してはいけないのと同じ問題です。
それぞれの英訳は、Personal Information Protection と Privacy Protection とで異なるわけです。
公益通報者保護を Whistleblower Protection と英訳することは、個人情報保護を Privacy Protection と訳してしまうことと同じようなものだと思います。

名は体を表すことになりますから、米国において、Whistleblower Protection Act として名と体が定着している「名」を安易に使い始めるのはよくないことです。
その「名」に体を合わせるという覚悟を示したいということであればよいのですが、まだそう決めているわけではないのでしょうから。。。

英訳語のことだけ書きましたが、本題の、公益通報者保護制度の中身については、気になるところがありますが、それはもう少し勉強してから書くことにします。

性善説を前提にして性悪説を想定する

組織における情報セキュリティ対策について、性善説では不十分だとか、性悪説を前提にするとかいうのは正確な日本語ではない。
言葉を正確に使わないと、意図は正しく伝わらない。
むしろ、話し手の期待と異なって、誤解を生じてしまうということに注意しなければならない。

●誤：性善説を前提にするのをやめて、性悪説を前提にする
●正：性善説を前提として、性悪説も想定する

「性善説を前提にするな」というようなことを、有識者と呼ばれる人達も言ったり書いたりしているが、彼らの全文をちゃんと読んでみると、その思いを正しい日本語で表現できていないように思う。
正しくは、佐藤が以前から使っている「性善説を前提に性悪説を想定せよ」と同じのようだ。つまり、「前提」と「想定」を使い分けていない。
「前提」と「想定」を使い分けない例は、有識者ばかりではなく政府にもある。
ｅＪａｐａｎ戦略では、「事故前提社会」と言っているが、それを言うなら、「事故想定社会」の方がより正確だ。
事故を前提に社会制度を作られたらたまらない。
この場合も、「想定」のことを強調する意味で、「前提」と使っているのだろう。

これら政府や有識者の思いは性悪説「想定」なのであって、単に「前提」という用語を誤用しているだけと思われる。
しかし、それらの発言に対する影響度の大きさには気をつけた方がよい。
自分たちの発言力は、自分が思うほど小さくないということだ。
彼らの思いとは異なり、その言葉を真に受けてしまうことで、「性悪説前提」論者が出てきてしまっている。

たとえば、「当社は性悪説で考えます」と経営者が言うことは、「社長のぼくのことも信じないでね。チャンスさえあれば、会社の資産を悪用するよ」と宣言しているわけだ。暗黙には、「予めそう言ったのだから、ぼくが不正しても文句言わないでよね」という完全無責任宣言だということがわかっていないのだろう。

●誤：性善説対策ではなく、性悪説対策を実施する
●正：性善説対策を実施した上で、性悪説対策を追加実施する

世の中には、もうひとつ、不十分な日本語表現が、誤解を生じている。
「組織における情報セキュリティは、性善説から性悪説へ」というものだ。
この表現は暗黙に、「性善説から性悪説へ切り替えよ」という述語を含んでいるが、それはまちがえだ。

これも日本語を誤用して広まっているものだ。
このたぐいのデマを吹聴する人のほとんどが米国事情を引き合いに出すが大嘘だ。
性善説から性悪説に移行した企業なんて存在しない。
性善説対策をある程度達成したら、次に、性悪説対策も追加するのであって、切り替えるものではない。
性善説対策もできていない組織が、性悪説対策なんてできるはずがない。

ルールは性善説の者にしか守られないのだから、性善説を前提にしなければならないのは自明だ。
性善説を否定することは、ルール設置を否定することに他ならない。
性善説の人に、性悪な人と戦ってもらわなければ、体制は成り立たない。

日本で見かける「性善説対策＝信頼するから組織は何も定めないし、何もしない」はまちがえだ。
「性善説対策＝善悪の違いについてをその理由とともに明確に定め、それを周知・徹底すること」と考えなければならない。
本来はそれを定める役目が、情報セキュリティポリシーだったのに、教条主義に走ったため、「その理由」が欠落して、例外事象への適応ができなくなり、結局、例外ではない明確な遵守事項までもが守られなくなった可能性がある。

性善説対策が相当程度に完遂できているかを、確認することが今とても重要になっているのだと思う。
それができた組織が、性悪説対策を実施すれば、効果があがるはずだ。
そうでない組織は、いつまでも、性善・性悪とも共倒れして、同じ事故を繰り返すことになるだろう。

ちなみに、性善説対策の達成が、そもそも、情報セキュリティガバナンスだ。
したがって、情報セキュリティガバナンスを論じるときに、性善説対策をあまり取り扱わずに、性悪説対策のことばかりを偏重するのはよくないことだ。
概ねは、性善説：性悪説＝８：２くらいの比率で考えるべきだろう。
性悪説対策は、情報セキュリティガバナンスの下に実施される情報セキュリティ対策の中で、集中的に取り扱えばよい。

おまけ：

性弱説という人当たりのよい言葉選びをしている人がいる。
ただ、性弱説というのは、性善説と性悪説の中間をとらえたような考え方になり、現象を説明するためにはよいが、それに基づいた解決策を導き出すことには、不向きだと思う。
性弱説として現象を説明はできるけれど、最初から性悪の人がいないとも言えないし、常に性善の人を否定するのもよいこととは思えない。そのためだと思うが、性弱説を唱える人が示す解決策は、何か抽象的な精神論になるか、あるいは、明らかに飛躍したものになることが多いように感じている。
性善と性悪の間で、人は性弱に揺れながら、どちらかにたどり着くのだということにした上で、その後の、性善説対策と、性悪説対策のどちらを人に適用するかを決める。という図式の中にならば、性弱説を持ち込んでみるのは説明を容易にすることに役立つに違いなし。
しかし、性弱説対策という切り口には、あまり同意できていない。

参考：

　・まるちゃんの情報セキュリティ気まぐれ日記

　・日弁連コンピュータ委員会シンポジウム'04

佐藤の講演から：

　・I-4 Regional Meeting (2002/12/5)

　・ネットワークセキュリティワークショップin越後湯沢 (2003/10/2)

　・第21回 Korea Techセミナー (2005/7/7)

PDCA 本家の陥落

NASA はアポロ月面着陸プロジェクトのときにプロジェクト管理手法を確立させた。その後、その手法は「プロジェクト」と呼ばれるものすべてに採用された。いわば、NASA はプロジェクト管理手法のご本家だ。しかし、いまやその本家の威厳は地に落ちてしまった。

いまや工程管理の常識である、PDCA, WBS, PERT図などのプロジェクト管理手法やツールのほとんどは、米国 NASA がアポロ計画の中で生み出したものだ。
情報公開制度により、アポロ計画における当時の手書きの議事メモなども含めて見れるようになっている。
それらを目の当たりにすると、アメリカの先進性に驚かずにはいられない。

そんな NASA が今やプロジェクト計画本家の見る影もない。

毎日新聞　2005年7月14日　3時26分　（最終更新時間　7月14日　10時56分）を参照

発射直前の TBS ニュース23 で取材が放映されていたが、プロジェクト指揮官が長官に品質改善のためにプロジェクトの見直しを要請するも、当初計画日程遵守を偏重し却下されたため、指揮官が辞任している。
指揮官は取材の中で、「いまや現場は悪いことは上に報告できない環境にある。上も良い報告しか受付けない。」と言っていた。

HRO としてあってはならない環境だ。

いくら WBS と PERT 図を厳密に準備しても、PDCA がちゃんと機能しなければ意味がない。

最近ときどき、PDCA を PDC としているのを見かける。
Plan, Do, Check したら、Action を適切に取らなければならない。
Check しっぱなしでは意味がない。
Plan, Do, Check が手続き的に実施できるのに対して、もっとも重要な Action は、人の判断によることになる。
PDCA を P|D|CA と分けるのは、あまりに危険だ。
本質的なところでは、PDC|A で分けてもよいくらいだと思っている。
PDCA を PDC にする人達は、C+A をまとめて C にするということがあってはならない。
A が異質だから PDC についてまずは考える・・・というのはナンセンスだろう。

PDC については、より多くの人間の意見を求め、上位までの承認プロセスを持つのがよいだろう。
しかし、A については、現場にもっとも近い少数の人間の意見を十分に尊重する必要がある。
fail safe の観点からすれば、Go サインについては、現場全員の同意を必須とする必要があるだろう。
ひとりでも、No Go がいるならば、No Go をまずは決定すべきだ。

現場指揮官が No Go を要請し職を辞してまで訴えたものを、その長たる者が、Go を強行するような NASA には、もはや、アポロ計画の頃のようなプロジェクト遂行は期待できないのだろうと思った。

納期という圧力に人が負けたとき、現在のプロジェクト管理手法のすべてが機能しないことは、図らずもそれを生み出した NASA が証明したことの意味を考えるべきだろう。

アポロ計画の遺産である WBS や PM 手法を使った、昨今のＩＴ構築であるが、ちゃんと PDCA ができているのだろうか・・・
似たような話しを見聞きするのは気のせいだろうか・・・

NASA は発射延期により、最後の最後でぎりぎり No Go のブレーキが残っていたわけだが、はたしてＩＴ構築の現場はいかに？

企業における情報セキュリティガバナンス

年度末だったから、色々出てるわけですね。
３月３１日だけですごい量だ。
http://www.meti.go.jp/press/index.html

前にちょっと気になった、これ↓も最終報告書が出ていた。

企業における情報セキュリティガバナンス

http://www.meti.go.jp/press/20050331004/20050331004.html

この報告書は、ちょっと期待と違っていた。
情報セキュリティガバナンスをどうやって確立するのかが、企業の課題だと思うのだが、こちらの報告書は、情報セキュリティガバナンスがあるとして、それをどう活用するかという観点というように思う。

うーん。