« 2005年11月 | トップページ | 2006年1月 »

2005年12月31日 (土)

IT産業分野の失策

事業に関する「運営と運行」を整理して分ける事ができるようになったため、いままで少し思っていた別のことの整理が進んだ。

それは、人材育成についてのことだ。
およそ8年前に事業戦略策定を考えていたときに整理した「2種類の財布」と「2種類の使い方」という、人材育成とは一見関係のない視点の話しから始めることにする。



【2種類の財布:コンシューマとエンタープライズ】

IT市場のお客様には、2種類の財布が存在する。
それは、コンシューマ(消費者)の財布とエンタープライズ(法人)の財布だ。

●コンシューマの財布

WHAT:
この財布には、自分の満足を高めるために一時的に手元に持っているお金が入っている。

WHY:
満足をより高めるためには、財布以外のお金も使うことができる。使おうと思って予め引き出した現金と、足りないときのクレジットカードを想像すると理解しやすい。
逆に、満足を得られないと思えば、使おうと思って引き出していた財布のお金を1円も使わないと決めることができる。

WHEN, WHO:
満足を得るために、「使うかもしれないお金」と言える。
いつ使うかは、本人が使うかどうかを決める。

●エンタープライズの財布

WHAT:
この財布には、決められた目的達成のための手段を実現するために与えられたお金が入っている。

WHY:
与えられたお金以上の金額を使うことは通常できない。
与えられたお金を残すことは通常ない。そのお金は、目的達成のために何らかの使われ方をする。
目的をあきらめた場合に限って、そのお金を使わないということが考えられるが、そのような場合には、目的が変更されて、やはりそのための何かに使われるのが一般的だ。

WHEN, WHO:
目的達成のために、「使うと決まっているお金」と言える。
使うかどうかを組織が決めている。それを任されている人が使いかたを決める。

●SMB(Small & Midium Business)の財布

かれらは、コンシューマのように振る舞ったり、エンタープライズのように振る舞ったりする。
そのときどきに応じて、かれらが、どちらの顔を示すのかを見極めるのは難しい。
ときとして、かれら自身もどちらで振舞うのかについてわかっていないことがある。
SMB においては両方に備えるしかないのだろう。



【2種類の使い方:カスタマとクライアント】

お財布の種類は2種類あるが、その使い方に2種類ある。
それは、カスタマ(顧客)的使い方とクライアント(依頼人)的使い方である。

●カスタマ的使い方

HOW, WHERE:
この使い方は、自分の満足を高めることができる商品を、市場にある商品の中から選択する。

より多くのカスタマに対して、繰り返して売る事ができる商品を用意することがビジネスに役立つ。
この場合、繰り返しとは、異なるカスタマに対する空間的な拡大販売と、同じカスタマに対する時間的な追加販売の両方が含まれる。
商品の一部についてカスタマイズに応じることは有益だが、日々の運行において、まったく異なる個別の要望ごとの商品を1から用意することは、大きなビジネスとしては有益ではない。(※注)
繰り返して売れる部分を商品に多く持たせることが重要である。
新規カスタマを増やすためには、マーケティング戦略などを活用することでマスで対応することができる。

(※注)フルカスタム・メードを期待する需要があるのは事実で、そのようなニッチなビジネス領域はあるが、ニッチであるからこその需要だと思う。

●クライアント的使い方

HOW, WHERE:
この使い方は、自分の手段を実現することができるソリューションを、それを提供できる者に依頼する。

個々のクライアントに対して、個々の期待に沿うソリューションを提供できるようにすることがビジネスに役立つ。
繰り返して売る事ができるソリューションを用意することは、マクロ的に見れば、運行効率を高めることに役立たない。
新規クライアントの開拓に相当のコストを要するため、
ソリューションを購入してくれたクライアントが次に希望するソリューションを、クライアントの要望に応じて用意することの方が、運行効率を高める場合が多い。



【2x2=4つのビジネス象限】

コンシューマとエンタープライズという2種類の財布と、カスタマとクライアントという2種類の使い方を組み合わせて、4つの象限に分けてビジネスの特性を整理することができる。

・ コンシューマ・カスタマ
・ コンシューマ・クライアント
・ エンタープライズ・カスタマ
・ エンタープライズ・クライアント

IT市場においては、コンシューマ・クライアントというのはニッチとなるであろうから、これら4つを大まかには、以下の2つに整理することもできる。

・ カスタマ
・ エンタープライズ・クライアント



【エンタープライズ・クライアント・ビジネスの失策】

エンタープライズ・クライアント・ビジネスについては、個々の期待に応じる能力のある人材が運行に従事しなければならないことになる。既製商品をただ選択させるだけではないビジネスだからである。
人材としては、そのような個々の期待に応じる能力のある人材とそうではない人材を比べた場合、当然前者の方がコストも高く、また調達も比較的困難になる。
だからといって、ビジネスの生産性を高めるために、個々の期待に応じる能力のない人材をエンタープライズ・クライアント・ビジネスの運行に従事させるのは誤りである。
誤った運行というよりは、運営なき運行と言うのが正確である。

このミスリードは、カスタマ向けのビジネス戦略を、エンタープライズ・クライアント向けに誤用したと思われる事例が散見される。
カスタマ・ビジネスにおいては、「繰り返しが金(GOLD)」であるが、エンタープライズ・クライアント・ビジネスでは「繰り返しは禁」とまでは言わないが、必ずしも最良策ではないという認識があまりに低い。
これは、カスタマ・ビジネスだけを習得した MBA 人種による勉強不十分によるミスリードと思われる向きもある。

そのような何らかのミスリードによって、ソリューションを繰り返し売るために、容易に調達できる人材を十分な育成もしないでエンタープライズ・クライアント・ビジネスの運行に採用した。
その結果、個々の期待に沿うことができるソリューションを提供できる人材の数が、エンタープライズ・クライアント・ビジネス市場の成長率と同程度には増えておらず、エンタープライズ・クライアント・ビジネス産業全体に占める割合は、実際には低下した。

その結果、ここにきて、IT産業のエンタープライズ・クライアント・ビジネスにおける品質低下の兆候が見られるようになった。
これは、ビジネス戦略を運営がミスリードしたことで、人材の適材適所を誤った運行が生じた失策として多いに見直さなければならないことであるが、IT業界のエゴは止まらない。




【人材育成】

ここまでの整理をすると、人材育成は、4つのビジネス象限を分けて考えなければならないことが推定できる。
そして、育成によっては人材の調達ができないと考えなければならない象限が存在していることにも気づかされる。
人材育成をすべきではない象限において、育成策を講じることは、百害あって一利なしとなるので注意しなければならない。
これを見誤ると、高品質のソリューションを提供する能力のある人材は、やがてIT産業には訪れなくなる。
その結果、IT産業全体の品質が低下して、さらに優秀な人材の獲得もできないという負のスパイラルが起こってしまう。

たとえ実際にやっていなくとも、やればできる人材がいる間は、その産業は回復できるが、できない人材ばかりとなったときには、その回復はもはや期待できない。
いったんそうなると、できない人材が食えなくなって自主退場するところまで、産業規模が落ち込んでから、適正な人材の規模で回復することになるのだろう。
そうなるくらいなら、適材適所となっていない人材を強制退場させることも考えなければ、正しい運営とはいえない。

12月 31, 2005 | | コメント (0) | トラックバック (0)

運営と運行

この季節は、1年のうちでもっとも短時間で視野を広げることができる。
通常3ヶ月くらい思案しなければならないことが、一晩で飛躍的に整理が進む。

なぜこの季節かというと、会社を去った諸先輩との呑み会があるからだ。
仕事に忙殺されているいまとなっては、夜8時から朝5時まで議論を白熱させられる機会は、この季節以外にはあり得ない。

ただ、10時間の呑み会では、おもしろいことに、最初の6時間以上の議論は、最後の2時間程で得ることになる情報の前振りに過ぎない。
これは毎年同じだ。
議論するときには、背景の理解と使う言葉の定義という前振りがいかに重要なのかがわかる。
奇しくも、その配分は8:2に相当している。

この呑み会では、多くの話題について行ったり来たり飛び回るが、背景色は一色だ。
大先輩が設定したカラーは、今回に限らず文字にすると、いつも単調だ。
「知って学び、思って得る。」「Outside to Inside, Inside to Outside.」

この言葉はとても共感することだが、これそのものを紹介するのは別の機会にする。
ここでは「知った」言葉としての「運営と運行」について紹介することにする。
紹介するために文章を書くことは、「思った」ことになる。
そして、ブログに載せることは、Inside to Outside ということだ。

●運営と運行

事業を運行するのが CEO であり、オール漕ぎの号令役。
事業を運営するのが President であり、舵取り役。

運営力を失った会社は、運行力だけでは成長できない。
むしろ、衰退する潜在的可能性の方が高い。

企業には短期的ではないビジョンを示す President が必要である。
それがなければ、CEO が売り上げ・利益を追求するだけになってしまう。
しかし、売り上げ・利益を追求するだけでは失速する。
売り上げ・利益ではないビジョンも追求する会社が、結果的に、売り上げ・利益を成長させることができる。

会社のステークホルダは、運営と運行の両方の価値を高めることに興味をもつべきだ。
しかし、ステークホルダのうち株主において注意すべきは、デイトレーダに代表される短期投資家の存在だ。
かれらの主たる興味は、運行利益のみとなりやすい。
それによって株価が左右される場合には、その株価の維持にばかり気をとられてしまうと、結果的に、運営がおろそかになり運行を過度に優先するということが起こる。
これを防ぐことを CEO に期待するのは、正しくない。
CEO は運行に責任を持つ者だからだ。

CEO が運行の向上に全力を注ぎつつ、運営を司る President が的確な舵取りをしなければならない。
President と CEO を兼務するのは、至難の技であるとともに、求められるスキルが異なるため、分業にした方が President と CEO に最高の人材を起用しやすくなるはずだ。

ここで述べた President & CEO の定義からすると、日本では、CEO を社長と呼び、President を会長と呼ぶことがある。

また、President が舵取り役で、CEO がオール漕ぎの号令役であると考えるならば、
会社全体の CEO の下に、Company などの事業部制を設けて、そこに President を配置する場合には、そのことに十分な注意が必要となる。

事業を行なうとともに、営むことが必要不可欠なのである。

この2つを分けて考えてみると、「IT産業分野の失策」についての整理を進めることができる。

12月 31, 2005 | | コメント (0) | トラックバック (0)

2005年12月29日 (木)

HPスーパーサイエンスキッズ

小学校3年生~中学校3年生のお子様のいる方へのご紹介です。

HPスーパーサイエンスキッズという企画があります。
詳細は、以下の実行委員会ホームページを参照してください。

http://www.supersciencekids.com/

ホームページによると、企画趣旨は以下のとおりとのこと。

子ども達の創造性を伸ばし、「科学」的な思考力を育て、「何かを発見し、創作する」ことの面白さを楽しみながら学んでもらいたい。 また、子ども達の「理科離れ」対策や「 ICT( Information and Communication Technology )を活用した教育の普及 」の一助として、 『世界的なクリエーター / サイエンティストの卵を発見し、その育成をサポートする』ことを目的に、 紙と鉛筆に代わる魔法のソフトウェア「スクイーク」を用いたコンテストを実施します。 また、コンテストと並行して全国各地での(コンテスト対象年齢向け)「スクイーク・ワークショップ」を開催します。

パソコンの父と言われる、アラン・ケイ博士が開発している、スクイークというパーソナルコンピューティング環境を使ったコンテストです。

うちの子は、ひょっとして芸術の才能があるのでは?とかがあれば、HPスーパーサイエンスキッズで受賞できれば、子供はアメリカ西海岸に行けるようです。

スクイーク(Squeak)については、以下のホームページに情報があります。

http://squeakland.jp/

無償でダウンロードできるので、試してみようかと思っているのですが・・・
なかなか時間が取れません。
この正月にでもと思っているのですが、どうなることやら。。。

12月 29, 2005 | | コメント (0)

2005年12月14日 (水)

JIS Q 15001 改定のパブコメ募集

プライバシーマークとして知られている JIS Q 15001 の改定のパブコメが募集されていますね。
今回の改定の主題は、もちろん、個人情報保護法対応ということになります。

JIS Q 15001 の改定に関する意見募集要領
より抜粋して転載。

日本工業規格「個人情報保護に関するコンプライアンス・プログラムの要求事項」(JIS Q 15001)の改定に関する意見募集要領

日本工業規格「個人情報保護に関するコンプライアンス・プログラムの要求事項」(JIS Q 15001)につきまして、個人情報保護法施行等に伴う改定を検討しております。現在の試案について御意見の募集をいたしますので、以下の要領に従いご提出ください。

1.意見募集対象

日本工業規格「個人情報保護に関するコンプライアンス・プログラムの要求事項」(JIS Q 15001)の改定試案(PDF形式:76KB)
*現行の規定(JIS Q 15001:1999)については、日本工業標準調査会のページ
http://www.jisc.go.jp/)にてご参照ください。
 
2.意見募集期間

平成17年12月13日(火)から平成18年1月10日(火)まで


今年のお正月は、こたつでみかんを食べながら、パブコメを書きましょう。ということですね・・・

12月 14, 2005 | | コメント (0) | トラックバック (0)

2005年12月13日 (火)

社内個人情報保護ガイドラインを無償公開

日本HPの社内で使用している個人情報保護ガイドラインを無償配布させていただくことにしました。

以前、以下のような調査をさせていただきました。

【IT media】
中堅・中小企業で対策の苦慮目立つ――日本HPの個人情報保護法対策進展調査

その結果、中堅・中小企業では、個人情報保護の社内ガイドラインの具体例があると役立つのかなぁ・・・とおもっていたところ、、

政府が、政府の内部基準を公開してくれたのだから・・・
それに感謝して、企業は、企業の社内ガイドラインを公開して世の中の役に立てられたらいいよね。

ということで無償配布させていただくことにしました。

無償配布については、以下を参照ください。

  • 日本HPのプレスリリース

    関連記事:

    【日本経済新聞】 2005年12月13日(火)朝刊
    個人情報保護ガイドライン - 日本HP、無償で公開

    【IT media】 2005年12月13日(火)
    「たたき台」としての活用を――日本HPが個人情報保護ガイドラインを無償提供

    【Enterprise Watch】 2005年12月13日(火)
    日本HP、自社の個人情報保護ガイドラインを無償提供、「策定のたたき台に」

    【電波新聞】 2005年12月14日(水)
    日本HP 個人情報保護ガイドラインを無償で提供開始 - 具体的な対策事例示す

    【Web BCN】 2005年12月14日(水)
    日本HP、社内で実際に使用している「個人情報保護ガイドライン」を無償配布

  • 12月 13, 2005 | | コメント (1) | トラックバック (1)

    政府機関統一基準の全体版公開

    政府機関の情報セキュリティ対策のための統一基準の全体版が公開されました。

    2005/12/13 に、第3回情報セキュリティ政策会議が開催されました。

    政策会議にて報告がありましたが、「政府機関の情報セキュリティ対策のための統一基準」に追加すべき項目に関する意見の募集の結果が公開されました。

    約1ヶ月に渡って実施していた意見募集の結果として、「政府機関の情報セキュリティ対策のための統一基準」の2005年12月版[全体版初版]が掲載されています。

    そのページでは、遵守事項本文だけですが、統一基準のページでは、解説書も公開されています。

    政府機関の情報セキュリティ対策のための統一基準

    以前にも紹介しましたが、「解説書」は、統一基準について逐条での解説を加えたものになっており、自分の会社や組織などにおける情報セキュリティ対策基準策定にあたって今回の統一基準を参考にする際にも役立てられるものと思います。

    ここで公開された統一基準は、民間でも著作権を気にすることなく活用することができます。
    このような雛形に相当するものだけを使って、情報セキュリティのコンサルティングと称している事業者にとっては、より付加価値のあるサービスを提供しなければならないことになります。
    その結果、本当にコンサルティング能力の高い人を見抜きやすくなるかもしれません。

    これまで、セキュリティポリシーはなんとなく作れたけど、その次の具体的な基準は大変だ。と思っていた方は、解説書を読みながら役立ててみてください。

    まったくの偶然ではありますが、同日付けで、会社の方ではこんなこともしてみました。

    社内個人情報保護ガイドラインを無償公開

    12月 13, 2005 | | コメント (0) | トラックバック (1)

    2005年12月10日 (土)

    要求事項を示さなかったことによる結果責任は発注者にある

    建物の耐震構造設計の偽造問題が取り上げられているが、そこから学ばなければならないことがある。
    そして、学んだら、自分にできることが何かを考えなければならない。

    建設業界に関係しない者も、この問題を狭くとらえずに、自分が何を改善するかを考えるべきだ。

    何か社会的な問題があれば、そこから「自分は何をできるか」を考えようということを、
    バカな行政、バカな報道、バカな国民では再発は防げない
    で述べた。

    今回、耐震構造設計偽造問題から何を学ぶべきかを考えてみる。

    ●学ぶべきこと

    この問題には多くの原因があるが、もっとも単純化すると以下のようなことが言える。

    ・発注者が受注者に丸投げすることは無責任意識の温床となる。

    丸投げ関係は、人の意識にとても悪い影響を与える。
    もしも丸投げしたことに対して、事故が発生した場合に、発注者は受注者のせいにし、受注者は発注者のせいにすればよいと思い始めるかもしれないからである。
    このことは、発注者と受注者双方の利害関係が一致した場合に最悪のシナリオとなる。
    双方が互いに、事故の発生を予測できたとしても、そのことについては双方とも触れずに済ませることができてしまう。
    耐震構造設計書の偽造事件では、被害者の救済のために税金が使われるしかないが、多くの人は、そのことに釈然とはしていないのではないだろうか。
    この場合、そこに悪事があったことは確かと思われるのに、その責任の所在がはっきりしない。そして、責任所在が不明なので、その悪事の被害者が救済されるためには、まずは税金を使うしかないだろうということを理解せざるを得ない。納得できないが理解するしかない。ということが、モヤモヤ感を生むのかもしれない。

    ここで注意深いのは、検査機関というものがうまく機能しなかったことだろう。
    しかし、そのことは自明とも言える。
    「事故の発生を予測できたとしても、そのことについては双方とも触れずに済ませることができる」状態においては、検査機関は経済的に機能しないことが十分予想される。

    結論だけ先に書けばこんなかんじだ。

    ・検査の合格証書をもらうことだけが目的化したとき、民間による検査は正しく機能しなくなる。

    本事件でも、検査機関は、「あそこは審査が厳しいと思われたら、ビジネスに悪影響が出る」ということを懸念した。このことは、「審査の甘い機関」がひとつでもあれば、多くの機関が「あまい審査」をすることについて、拍車がかかるのは経済原則として当然だ。
    検査機関は、「検査をする場」であるが、そこで検査を受ける側からの視点でいえば、「合格をもらうための場」になる。その場で検査機関を民間ビジネスとして運営すれば、「合格を与えるビジネス」というビジネスモデルになるのは当然のことだ。

    自動車運転教習所を考えるとわかりやすい。
    非常に安全な運転を指導してくれるが、それを完璧にマスターするまで、かたくなに合格させてくれない教習所に、「客」は集まるだろうか。そこに集まる客は、本来の目的は「安全な運転を習得する」ことではあるが、実際には、「合格証書をもらう」ために教習所に通うことになる。
    このとき、「すぐに合格証書をくれる教習所」が出現したらどうなるだろうか。
    そこでは、「安全な運転を習得する」ことができないから、「客」は来ないのだろうか・・・それはないだろう。
    「合格証書さえもらえばよい客」が集まる。ことによっては、安全な教習所より繁盛してしまうかもしれない。
    しかし、実際の教習所ではそうならないだろう。色々な理由が考えられるが、少なくとも2つの側面がある。
    教習所にとっては、安易な合格乱発をしたくとも、「合格証書を与えるための条件」が細かく規程されているからそうはできない。
    また、受講者にとっては、「あまりに何も教えてくれないのでは、実際に運転もできない」ことになるし、「安全な運転を習得する」ことができないのは、自分の不利益となる。
    そして、最終的な運転免許証は、試験場で合格しなければ入手できない。そのため、いい加減な教習所の授業では合格率が確保できないことになり、その評判はビジネスに不利益となる。試験場で合格するように、ちゃんとした学科教習を少なくとも実施しなければならない。
    これらの環境によって、合格証書を乱発する教習所は、ビジネスとして成立しないのだろう。

    今回の耐震構造設計の検査については、「合格証書を与えるための条件」が見直されることになるだろう。
    しかし、その検査だけに頼るのは現実的ではない。
    「ちゃんとした検査を受けたい」という意識と、「ちゃんとした検査をしないとビジネスが成立しない」というシステムが全体として構成される必要があるのだろう。
    このとき、「ちゃんとした検査を受けたい」という意識には、それなりの覚悟が必要だ。
    ちゃんとした検査を受けるためには、そのための費用も手間も必要だと、居住者は認識しなければならない。
    そうしなければ、安全性の欠陥に気づいてもそれに触れずに済ませることができる状態では、検査だけですべてを管理するのには限界があるはずだ。
    この問題の解決のために、どのような検査の仕組みができあがるのかは、とても興味深い。

    と書いてきたが、これは他山の石だ。
    本題の、「自分は何ができるのか?」について考えてみる。

    ●自分ができること

    「建設業界にいない自分には関係ない」という発想は、「自分は何ができるのか?」をさぼる言い訳にはならない。
    この場合、これと同種の問題が自分の環境の中にないかを考え、その問題について考えることこそが、「自分は何ができるのか?」を考えることになる。

    先に述べたことを繰り返すと以下のとおりだ。

    ・発注者が受注者に丸投げすることは無責任意識の温床となる。
    ・検査の合格証書をもらうことだけが目的化したとき、民間による検査は正しく機能しなくなる。

    もう、多くを書く必要はなさそうだ。

    IT業界において、情報セキュリティ対策はまさに、以下の状態といえる。

    ・受注者に丸投げ
    ・認証取得が目的化

    しかも、建設業界よりも始末が悪い。
    おそらく、耐震構造設計の偽造をした人達は、耐震強度が弱くなり、そのことはよいことではないことだとわかっていたし、その強度は本来高めることは可能だが、コストを下げて利益やビジネス機会を増やすために「悪いことをしている」という意識はあったはずだ。
    情報セキュリティ業界というのは、たちが悪い。
    「情報セキュリティに完全はない」を声高々に掲げてビジネスをしているのだ。
    こんな業界は他にないだろう。
    「情報セキュリティに完全はない」と言いつつ、認証制度があるという矛盾についても、解決しないまま、合格証書が次々と出されている。
    いまのところの救いは、まさに、証書をもらいに行く側が、「実際にちゃんとした対策にしておきたい」という動機付けが大きいことだろう。
    しかし、この後、「合格証書の取得」ばかりを推進すれば、認証取得が目的化することになる。

    さて、「自分にできること」は何か。

    『発注者が具体的に要求事項として示さなかったことが原因で問題が生じた場合には、その責任は発注者自身にあるという意識を持つこと』を具現化することだろうと思う。
    それを2つに分解すると以下のようにすることができる。

    ・IT構築の委託先に対して、単にISMS認証取得を強要しない。
    →認証取得を相手に示させるのではなく、情報セキュリティ対策の要求内容を発注者が具体的に示す。
    ・IT構築の受託者は、具体的な要求内容も示されていないことに無責任に合意しない。
    →「十分な対策を講じること」のような抽象的なことは、業務委託として確約できないはずだ。確約もできないことに合意するのは、事故が発生したときに責任不在を生じることになるということの重大さを自覚すべきだ。

    その昔、「なるべく停止しないこと」というような抽象的な要求では適切な情報システムを構築することができないことを経験してきたはずだ。いまは、計画停止時間と計画外停止時間などを具体的にSLA(サービスレベルアグリーメント)で定めているはずだ。SLAなくして、「なるべく停止しないこと」という契約が無意味であるように、セキュリティ対策についても、発注者と受注者間で具体的な内容について審議し合意する必要がある。
    そのような合意をちゃんとすることは、両者にとって責任を明確にすることになってしまい、自らの足かせとなる。
    足かせを作らなければ、事故が発生してしまったときに、事故原因そのものについて、両者がともに言い逃れることができるように思うかもしれない。そのため両者とも、それをうやむやにしておきたいという衝動に駆られるかもしれない。
    しかし、それでは、両者とも、説明責任を果たせず、再発防止策も立てられないということになる。
    いまや、そんなことは社会が許してくれないということを、耐震構造設計書偽造事件で知ったはずだ。

    下請け会社に対して、発注する業務個別に要求事項を定めていないようなISMS認証を取得させるというのは、まったく無意味であることを正しく認識すべきだ。ましては、単に会社としてISMS認証を取得しているかを確認するというのは、発注者における情報セキュリティ対策との依存関係はない。
    下請けに出した発注業務プロジェクトについて、発注者が情報セキュリティ対策の要求事項を定めた上で、プロジェクト個別にISMS認証を取得するのならば大変有意義だ。
    そのとき、要求事項を達成しなければ、下請けの責任であるし、要求事項に不足があれば、発注者の責任であることが明確になる。ただし、その場合には、そのための相当のコスト請求を覚悟しなければならない。
    下請け企業に情報セキュリティ対策を自立させようとするのは、最善ではない。発注者が、下請け企業に対する監督責任を果たすのがあくまで基本だ。
    すなわち、『発注者が具体的に要求事項として示さなかったことが原因で問題が生じた場合には、その責任は発注者自身にあるという意識を持つこと』が重要だ。契約というのはそういうものだ。
    「後はよきに計らえ」では情報セキュリティ対策の当事者意識は、どこにも生まれない。
    「後の責任は全部下請けが取る。という契約を締結すること。」を、発注者の監督責任だと説明するISMS審査員がいるという話をときどき耳にする。それは契約リスクの軽減策のひとつであって、監督策とは無縁のことだ。

    以上のような説明をすると・・・
    『示さなかった要求事項による結果責任は発注者にある』ということを局所的だけにしか考えることができない人にとっては、発注者責任ばかりが増大するように思うかもしれない。しかし、そのことで得られる経験を広く共有していく仕組みを作ることができれば、ある時間と空間の範囲では、発注時要求事項が改善され、受注者による対策が改善・向上していくはずだ。
    短期的・局所的にだけ解を求めようとすれば、それを得ることはできないことが予想される。
    あるレベル設定により、それが時間と共に「より改善される」という仕組みをちゃんと作りこめれば、最初に設定したレベルが少しくらい低くてもよいはずだ。
    いまは、最初から高いレベルを求めようとするあまりに、時間を浪費してしまい、結果的にレベルが高まらないというジレンマに陥っているように思う。
    言い換えると、「その対策は3年かかるのでは長い。1年でできる対策を考えよう。」と言って、3年間考えているとしたら、「3年前に3年間でできる対策に着手していれば、もう対策できていたはず」ということになる。いまは、あまりに短期的に解決しようとしすぎている試みが散見される。
    人は責任を感じれば、それを全うしようとするものである。と考えることによって、責任の所在を明確にすることによって、人が物事を改善していくことに期待してもよいのではないだろうか。
    それが、PDCAの本質ではないだろうか。
    PDCAは、人によって回されるもの。人にしか回せないものだ。
    あまりに人から離れたところで、解決策を求めるのはもうやめたほうがよい。

    情報セキュリティ対策の責任について、誰がどの部分をどうやって持つのかを、改めて考えるべきときだ。

    12月 10, 2005 | | コメント (0) | トラックバック (0)

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

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

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

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

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

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

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

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

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

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

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

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

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

    おまけ:

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

    参考:

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

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

    佐藤の講演から:

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

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

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

    12月 10, 2005 | | コメント (3) | トラックバック (1)

    2005年12月 9日 (金)

    みずほ証券発注ミス

    まるちゃんの情報セキュリティ気まぐれ日記にも出てますが、小さな事故をこまめに対処しない組織では大きな事故が発生するというHRO対策の基本そのままの事例ですね。

    推察ですが・・・

    ・株価と株数の取り違い

    入力画面でそれぞれを区別する工夫が、画面設計上足りなかったのではないかと推察します。
    東証での同じ、株価、株数取り違えによる億単位のミスは、今回で3件目のようですから。
    そう考えれば、より少額のミスは常態化していたかもしれません。
    その他には、ITではなく業務処理手続きに落とし穴があったかもしれませんね。
    たとえば、ほとんどの指示が、「10万円で10株を売り」というように、「金額、株数」という順番の様式なのに、その中に、「10株を10万円で売り」という指示が混在すれば、それを「10円で10万株を売り」と入力してしまうでしょう。

    ・警告画面を無視した

    警告画面の出現頻度が高い設計だったのではないかと推察します。
    しょうもないことまで、常に警告画面を表示させるようなシステムでは、人は、それを無視しはじめるでしょう。
    極めて稀にしか表示されないような、警告画面を、即座に無視するとは思えません。
    あるいは、グローバライズ気取りで、意味もなく警告文を英語で作っていたり。
    日本人には、「WARN や ALERT」と表示するより「警告」と表示した方が直感的なはずです。でも、かっこつけて英語で表示するものが意外に多いですよね。
    少なくとも、警告画面の頻度が少なくなるように、警告条件を考慮するのは、設計上の問題です。そして、警告条件が取り引き条件に依存するなら、警告条件を変更できるような設計がなければ、「人」はそれを正しく使えません。
    最後は「人」なんだという配慮に欠けた設計のシステムが最近多い気がしています。

    などと勝手に推察してみましたが、そんなことは揚げ足取りの邪推でしかありません。
    まぁ、いろいろな事情があったのでしょう。
    しかし・・・

    ・再発防止のためには

    一般的に考えて、これまで株数と株価を入れ間違えるミスがまったくなかったところに、いきなり数百億円のミスが発生したとは思えません。
    日々の小さなミスを軽視して、設計変更をしなかった責任は重いはずです。

    まさに、HRO対策を怠ったということですね。

    HROとは、 高信頼組織(High Reliability Organization)の略で以下の書籍で解説されています。

     不確実性のマネジメント(Managing Unexpected)
     出版:ダイヤモンド社

    良書なので、amazon に書評を書いたことがありますし、佐藤の講演では、ちょくちょく紹介してます。

    バカな行政、バカな報道、バカな国民では再発は防げない」で書いたとおり、今回のような事件を他山の石として失敗から教訓を学び、自身についても同種の潜在的な問題点を改善をしないといけませんね。

    12月 9, 2005 | | コメント (0) | トラックバック (0)