2016年9月20日 (火)

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

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

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

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

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

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

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

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

9月 20, 2016 | | コメント (0) | トラックバック (0)

2016年7月 2日 (土)

テスラの自動運転事故から学ぶべきこと

テスラの自動運転の衝突事故は、実際には現在市販されている自動車に搭載されたautopilot機能で起きたものだ。
この機能は古くは、アクセルを足から離しても、同一の速度で走行を続けるアクセル調節だけのころ(レベル1)から、そう呼ばれていた機能だ。これには衝突回避機能などはなく、運転者が自分でアクセルを解除しなければならない。
そんなものが役に立つのかというと、アメリカのフリーウェイのようなところを長時間走行するときには、足でアクセルペダルを微妙な位置に調整し続けて、足が疲れるのを防ぐのに役立つ。
この事故では、衝突回避機能が付いている(レベル2)を「自動運転」と訳して報道された。
しかし、昨今、開発が進められている自動運転(レベル3)は、英語ではautonomic drivingとも言われ、直訳するなら「自律運転」となる。
いずれのものも日本語では自動運転と訳してしまうので紛らわしいが、今回の事故を将来の「自動運転」の教訓にすることは必要だと思う。

テスラの自動運転の衝突事故では、当初の報道「米テスラ車 自動運転機能で走行中に初の死亡事故」
http://www3.nhk.or.jp/news/html/20160701/k10010579451000.html
で、
「テスラによりますと、当時は日ざしが眩しかったことから自動運転の装置が白い色のトレーラーに反応せず運転手も認識できなかったためブレーキをかけられなかったとしています。」
とのことで、カメラが逆光などで白いトレーラを検知できなかったとのことだった。

その後の報道「Tesla driver killed in crash with Autopilot active, NHTSA investigating」
http://www.theverge.com/2016/6/30/12072408/tesla-autopilot-car-crash-death-autonomous-model-s
で、
「Tesla CEO Elon Musk said that the vehicle's radar didn't help in this case because it "tunes out what looks like an overhead road sign to avoid false braking events."」
とのことで、レーダーによる衝突回避は、頭上の道路標識に遮られて、やはり検知できなかったということが付け加えられた。

何やら不幸な偶然が重なり、想定外のことが起きたという弁明に思えるが、それについては主観的・定性的ではなく、より客観的・定量的な検証をすべきではないだろうか。

この事故について他社の自動運転車で比較再現実験をするべきなんじゃないかな。
全車種でも同じく回避不能ならテスラが想定できなくても仕方ないが、回避できる車種があるなら、テスラには一定の非はあるのではないかな。想定外と言っても、テスラの開発者にとって想定外だっただけで、他社は想定できていたなら、それは人類未踏の想定外ということではなく、テスラ担当者の想定能力が不足していただけということになる。
その意味では、自動運転の開発においては、安全対策のための情報を全社が共有することにすべきじゃないかな。
間違っても、それを各社の差別化に使うべきではないわけで、以下のような情報共有が必要だと思う。

まず、上記の再現実験はリアルに車を走らせる必要はない。
自動運転の計算処理は、車載の各種センサーからのデータを入力としているのだから、そこに疑似データを与えて処理結果を検証すれば効率的だ。
それをも超えた想定外のことを検証するには、いよいよ車を走らせる必要性は残るが。

それこそ、ビッグデータ活用という意味では、自動運転車を街に走らせるよりも、普通の自動車に自動運転車と同じ車載センサーを付けて、それを大量に収集するのがよいんじゃないかな。
それらのデータを自動運転プログラムに処理させて、自動運転プログラムはブレーキをかけなかったのに、人はかけていたというケースに着目すれば、想定外と思っていることの洗い出しができる。
また、人の運転をそのようにして、ディープラーニングさせれば、自動運転者車を街で走らせて人体実験をしなくても、想定外のことを相当に洗い出せるんじゃないかと思う。
ディープラーニングで、前人未到のことを達成させるのは困難だが、人が適切に判断した大量のデータがあれば、そこから判断基準を学ぶことには長けている。ただし、人が10~100の事例で学べるところ、ディープラーニングでは10万~100万の事例が必要なので、自動運転車からのデータ収集より、現行の一般車両からのセンサーデータとそれに人がどう対処したかのデータを収集することが不可欠なはずだ。

その上で、自動運転プログラムの方がブレーキが遅れたデータを、自動運転のヒヤリハット例としてネットワークで自動共有することができれば、世界中のどこかで起きた自動運転によるヒヤリハットから全車両が学習できるようになる。
そうなると、いかに人と同程度に安全に運転するかという現状の目標を超え、むしろ、機械の方が人より安全に走行できる目標に挑戦を始めることができるようになるかもしれない。

まぁ、上記のようなことは、素人のぼくが思いつくようなことなので、既にメーカーがすべてやっているような気もするが、少なくとも会社を越えた連携にも注力して欲しいと思う。

そうでもしないと、陽射しが逆光になり頭上に大きな道路標識がある交差点などという、ありふれた条件を想定外だったとされて事故を起こされて、人の命や安全がプログラムの改善の糧にされても困る気がする。

7月 2, 2016 | | コメント (0) | トラックバック (0)

2015年1月 2日 (金)

facebookが2015年に導入した「プライバシーベーシック」について

facebookが、2014年末に全利用者に対して、2015年1月1日から「弊社は利用規約とポリシーを改定し、Privacy Basics(プライバシーベーシック)を導入します。」と通知していました。
その中で、紹介されたプライバシーベーシックのトップページがこちらです。

https://www.facebook.com/about/basics
※この記事で紹介するfacebookの各ページのアドレスは、2015/1/2時点のものです。変更されている場合には、facebookページなどからたどってご確認ください。

今回の利用規約の変更について、facebookが利用者に事前に許可を得ずに、利用目的を拡大変更したとか、収集する情報の範囲を拡大したという指摘をする人がいますが、少なくとも、正確な表現ではないと思います。

上記ページから、すべてのことを参照できますが、個人的にポイントを3点まとめてみました。
(私個人の感想であり、ポイント選びには個人差がありますw)

1.利用規約の変更内容
https://www.facebook.com/about/privacy/update/

内容としては、facebookが収集する情報について詳細が書いてあり、一見すると、そんな詳細まで今後は取られちゃうの?とショックを受けるかもしれません。
しかし、これは従来は「facebookに送信するすべてのデータ」という大雑把な表現だったものを、具体的に列記したもので、従来と比べてより多く収集することになったわけではなく、これまで同様に継続して収集する内容を明記したということです。

2.全データのダウンロード機能
https://www.facebook.com/settings

上記の1を知って、収集されるのが嫌だからfacebookをやめたい。でも、これまでアップしたデータを簡単に移行できず削除されてしまうと困るので仕方ないから利用し続けるしかない。ということだと、利用者に事実上の選択肢がありません。しかし、これまでfacebookにアップロードしたデータを一括してダウンロードする機能に、今回わかりやすくアクセスできるようになりました。
ウェブブラウザ版facebook(ウェブブラウザでhttps://www.facebook.com/にアクセスすること)の画面右上の▼アイコンをクリックして、設定/一般を開くと画面最下部に「Facebookデータをダウンロード」があって、これを使って全データのダウンロードができます。
利用者は、これまでアップロードしたデータを人質に取られて、利用を事実上解約できないということについて配慮されています。

3.特定の広告が表示される理由の確認機能
https://www.facebook.com/about/basics/what-you-see/ads/

上記の1の利用規約の中で、facebookは情報収集の目的のうち利用者の便益として、利用者個人ごとに最適で有益な広告を表示するためだとしています。
各広告について、それをfacebookがなぜ選んだのかという理由を利用者本人が確認できるようになりました。また、その種の広告表示を本人が望まなければ今後表示されないようにすることができます。それでもマス広告として表示される広告のうち特定企業の広告表示を止めたい場合は、個別に非表示にすることもできます。

以上の1から3は、今回の変更に関係して個人的に気になったことだけ抜粋しましたが、プライバシーベーシックについては、一通り全部見てもそんなに時間はかからないので、一度見るとよいと思います。
これら1から3については、以下の観点で、よい改善だと思います。
1は、個人情報という抽象的な示し方ではなく、個人情報のどういう項目のデータを取得し利用しているかを具体的に示すことで、利用者が何について同意するかの判断材料を提供しています。
2は、保存しているデータを利用者が簡易にダウンロードできることで、利用解約時の不利益を軽減して、利用者が不同意を選択する機会を提供しています。
3は、データの利用がどのように反映されたかについて確認できるようにすることで、利用者が趣向を選択できるようにしてます。

利用規約の内容は、従来と比べて何かが変更されたというよりも、内容が具体的になったのが主です。
これまでも気にしてない人は読み返さなくても、従来との違いという点での不利益はないものと思います。
規約内容について興味ある人にとっては、これまでページが分散されていて全体像を知るのが面倒でしたが、1つのページに集約されて確認しやすくなったと思います。ただし、その結果として1ページ内で長文になっています。わかりやすくなったかというと、難易度はこれまでと変わらず、一般の人にとっては難解なままですが、1ページだけ参照すればよくなったという点で確認しやすくなりました。

ここでは、今回の変更点についてだけポイントを示しました。
しかし、facebookを利用していて投稿やアップロードしたデータの公開範囲について、設定内容を今までにちゃんと確認したことがない人は、以下の手順で一度ちゃんと確認するとよいと思います。
ウェブブラウザ版facebookで画面右上の鍵アイコンをクリックして「共有範囲を確認」から「1.投稿、2.アプリ、3.プロフィール」を画面指示に従って、順番に確認する。
特にアプリのところでは、表示されるアプリを一つずつ全部みるために、ちゃんとスクロールして、各アプリの提供会社にどういう情報の提供を自分が許可しているかを確認しましょう。これはfacebook利用中にアプリをクリックしたときに画面表示されて自分で事前に許可した内容です。アプリにアクセスするときには、内容をよく見ないでクリックしているかもしれませんが、改めて確認するとよいと思います。
なお、スマフォなどのアプリ版facebookでも設定のプライバシーとアプリの設定から同様のことができますが、操作がわかりにくいので、ウェブブラウザ版facebookから設定する方が、ミスがなくてよいと思います。

1月 2, 2015 | | コメント (0) | トラックバック (0)

2011年6月 7日 (火)

行政機関向け文字情報基盤検証版の公開

関連発表は以下のとおり。

経済産業省:行政機関向け文字情報基盤検証版の公開について

IPA:約6万文字を収録した新しいIPAフォント(検証版)の公開

6月 7, 2011 | | コメント (0) | トラックバック (0)

2011年2月17日 (木)

「窓口のオンライン化」ではなく「システムのインターネット対応」と考えるべき

IT戦略本部企画委員会の電子行政に関するタスクフォース第11回
http://www.kantei.go.jp/jp/singi/it2/denshigyousei/dai11/kaisai.html

傍聴した雑感を備忘のため書いておきます。
(メモを書き込んだ資料を捨てたいので 笑)

以下は、個人的に気になった箇所だけをピンポイントに抜き出して雑感を書いただけなので、審議の総括や主要箇所が抜き出されているわけではありません。(ここに書いていないことで、有意義な審議もあったということです)

「オンライン利用に関する計画について」だが、これは前回の「電子行政タスクフォース雑感」でも書いたことだが、これまでを総括して終わりにして、仕切りなおした方がよい。

構成員から、「すべての手続きをオンライン化することを考えるべき」という提案をされ、これを事務局が法的に制約があるとして否定したが、これはまったくの間違えだ。(というか、そもそも、構成員意見を事務局が否定するというのは、どういう立場での発言として許されているのだろうか)
事務局が言うには、「家にパソコンがない人が手続きできなくなると法的に難しい」であったが、前回の雑感でも書いたように、すべてオンライン化した上で、従来の役所窓口にはインターネット端末を設置して、そこで入力するための支援をする職員をおいて、窓口での手続きも継続すればよい。
こう書くと、これまでと異なる窓口のようかもしれないが、単に窓口の中で使っている端末をインターネット端末にするということでも意味は変わらない。それなら、窓口の見た目は今と同じだ。

課題とすべきなのは、窓口手続きとオンライン手続きの併存ではなく、窓口手続き用システムとオンライン手続き用システムを両存させようとすることだ。
そのようにすれば、窓口手続きは、オンライン手続きの利用度合いを見ながら、縮小や別の手続きとの統合を段階的に実施することにも支障がない。
窓口専用手続きシステムを使っている限り、それを段階的に縮小することはできない。最後のひとりがいなくなるまで、そのシステムを稼働し続けなければならない。

上記を踏まえると、「オンライン利用」という表現が適当ではない。
よって、「これまでを総括して終わりにして、仕切りなおした方がよい。」と思うのである。

すなわち、「これまでは失敗だった」と総括する。
しかし、手続きをすべてオンライン化することが失敗だったのではなく、それを実現する方策が失敗だったのであって、全手続きをオンライン化する目標は取り下げるべきではない。

したがって、
窓口手続きのオンライン化ではなく、
窓口手続き専用システムのオンライン手続き対応化とするべきだ。
技術的には、
窓口手続きシステムの機能を取り込めるようなオンライン手続きシステムの導入
となる場合もあるだろう。
既存システムに手を加えるのか、新規システムで既存機能を設けるのかの違いということだ。

かなり乱暴に、はしょって書けば、本タイトルのように
「窓口のオンライン化」ではなく「システムのインターネット対応」と考えるべき
ということになるだろう

さらに、前回のタスクフォースで構成員から意見があったが、
現行の手続きを単にオンライン化するのではなく、手続きそのものを見直すべきというのも同感だ。
住民票をコンビニやネットで取り寄せられるようにすることが目標ではなく、他の手続きへの提出のために住民票の発行をすることがないようにすることを、最終目標に置くということだ。
たとえば、住民票を取り寄せる機会は多くの人にあるだろうが、住民票を家に飾っておきたいから取り寄せる人はいないはずだ。
何らかの手続きの提出種類として、住民票が求められているだけで、役所からもらった住民票は、そのまま別の手続きに提出するだけの用途しかない。
これらは連携されるべきで、理想を言えば、住民票の発行手続きはなくなって然るべきということだろう。
もちろん、住民票を家に飾りたい人のためには、残してもよいが・・・
以前は、民間の手続きのために、企業がとりあえず提出させるということがあったが、昨今は個人情報保護の観点で、民間も住民票を見て確認することはあっても、徴収するということは減っていると思われる。
この点については、国の行政と、自治体の行政との壁があるので簡単ではないが、このタスクフォースはそれを議論すべき場であろうと思う。


その他に、構成員から、紙申請は職員による入力ミスのリスクも少なくないという意見があった。
このリスクは、紙申請した後に職員が入力したデータを、本人が見る機会がすぐにないから、問題発生に気付きにくい。という点に着目してはどうだろうか。
上記のように、窓口ではオンライン手続きシステムへの入力を職員が本人に代わって代行する。ということであれば、入力結果を印刷して、本人に控えとして渡せばよい。
渡された内容をちゃんと確認するかは本人次第であるが、それを確認する機会が担保される点で、現在の窓口手続き専用システムにどう入力されたかを、本人がその場で通知されない現状よりも、入力ミスのリスクは低減するはずだ。

また、構成員から災害時などの情報システムの可用性の点の指摘があったが、これは、現在の窓口手続き用システムでも言えることだ。それと同程度の検討があればよいはずで、オンライン化して増える課題ではない。
課題になるとすれば、紙で申請されたものを、電子化せずに、紙でだけ管理している手続きについてだろうが、それが紙である必要があるのなら、いよいよ、その手続きはオンライン化から除外してもよいかもしれない。

最後にもう1点、これまでの「オンライン利用に関する~」を、いったん終了した方がよいパラダイムシフトがある。
すべてをオンライン化する場合には、現在の約7000種類の手続きのシステムを、それぞれ上記のようにして移行するのは、確かに困難であった。
そのため、重点71手続きをまず決めて、その他は費用対効果等を評価して、取捨選択する必要があっただろう。

しかし、霞ヶ関クラウドという俗称の省庁間共有情報システム環境を平成24年度末までに運用開始することが決まっており、今年度になって、政府は政府CIOを設置することも決めた。
これによって、何が変わるかと言えば、これらすべての手続きを、ある程度の数のワークフロー・エンジン・システムに集約することができるという、環境変革が起きていることを見落としてはならない。
技術的には、省単位でもワークフロー・エンジンへの集約は可能であるが、扱う手続き件数が増えてくると、システムの特にハードウェアに柔軟なスケーラビリティが求められることになる。しかし、ハードウェアとソフトウェアを一体調達する省庁において、そのような共有情報システムを構築することは、これまでの業務縦割り型のIT構築では、予算措置が困難だったものと思われる。
しかし、業務共有、省庁共有での情報システム・ハードウェア利用に実現可能性が出てきた今は、ワークフロー・エンジン・システムに集約することは、現実味が出てきている。
(逆に言うと、霞ヶ関クラウドは、そのようなことができるようなシステムにしないと、単なる共用ハウジングセンターにしかならない。)

このとき、経験のない者は、ワークフロー・エンジンでの手続き集約と言っても、数千は無理だろうと思うかもしれないが、保険業界では、大手になれば数千の商品を持っており、それを単一のワークフロー・エンジンに集約した例は国内にもある。
保険業界と接点がないと知られていないだろうが、保険商品というのは、普段われわれが接する保険会社の営業担当が紹介してくれる数点だけではない。
これは、100円均一ショップなどの小売店チェーンが本部に数万点の商品登録をしていて、その中から、各店舗が自店舗の購買層に合わせて数百品を選んで店舗陳列しているのと同じ関係だ。
そして、保険商品の品数と行政手続きの種類の数の多さには、共通点がある。
保険商品は、さまざまな条件で保険加入者の料率が変わるわけだが、どの条件の組み合わせの保険商品であるかによって、必要な書類が異なり、また、保険会社内での、それら書類の審査部署や順序も異なり、それが複雑であるために、手続きの種類が増えていくのである。
まさに、行政の手続きが7000種類もあるといっている種類数の数え方と同じだ。
ワークフローの類型の数は、ある程度の種類しかないのに、それを処理する部署が異なれば、部署ごとに数を数えていくからだ。
おわかりのように、類型が同じで、部署が異なるだけ。というのは、ワークフロー・エンジンで処理すれば、単にインスタンスが異なるだけで済ませられる。

「オンライン利用に関する~」で事務局は、IT戦略本部設置以来の数年間で検討したことだと胸を張るが、
むしろ、これだけ技術革新が速い時代に、動的なパラダイムシフトを踏まえずに、初年度の環境を礎に検討し続けていることが、周囲の状況を見失うのではないかとさえ思った。


個別に解決策の例示をしたが、この種の議論をするときには、ビジョナリーが必要なのだと思う。
決めようとしている方針は、100年後をも思い描いたものなのか?が問われる。
この件であれば、100年後にも紙の申請とネット申請を別のシステムでやるの?ということに疑問を持たなければならない。
そこで、本当に100年後の遠い未来のことなのか?というとそう思ってはいない。
100年後くらいを思い描いても、それで想定する技術革新は、おそらく10年後には到来するだろう。という気がするので、いっそのこと、「100年後」くらいを思い描いても、結局10年くらいしか耐えられないだろうということだ。
ましてや、最初から数年後を想定するようなビジョナリーでは、来年には期限切れになりかねない。
インターネットが家庭に入り始めてから、まだ15年しかたっていないという速度の中で、モメンタムが大きく、すぐには舵をきれない電子行政の数年後の政策を考えるには、必要なビジョナリーのスパンだと思う。

2月 17, 2011 | | コメント (0) | トラックバック (0)

2011年1月 7日 (金)

電子行政タスクフォース雑感

IT戦略本部企画委員会の電子行政に関するタスクフォース第9回
http://www.kantei.go.jp/jp/singi/it2/denshigyousei/dai9/kaisai.html

傍聴した雑感を備忘のため書いておきます。
(メモを書き込んだ資料を捨てたいので 笑)

以下は、個人的に気になった箇所だけをピンポイントに抜き出して雑感を書いただけなので、審議の総括や主要箇所が抜き出されているわけではありません。(ここに書いていないことで、有意義な審議もあったということです)

議題1:政府CIO制度のグランドデザイン(案)

政府全体のIT投資の管理

IT予算要求をピン留めしようとしているようだが、そもそも、IT予算という切り出し方ができるのか要確認。
省庁内は個別行政予算申請で予算枠が確保され、その枠内で、IT支出が発生しているということはないか。
それだと、予算部分をつかまえようとしても、すり抜けられてしまう。
この点は、政府CIOの設置においてとても重要。
IT投資を管理下に置く必要があるという指摘は正しく、そのようにしないとならないが、そもそも省庁内で上記のとおりIT予算が横串ささってない可能性あり。
もしも、それがささっていれば、それをかき集めて、政府横串をさせるが、もとがささっていないとすると、本件で集約するという方法は空転する可能性あり。
企業で考えてみると、事業部予算の中で、IT投資が各事業部で実施されているところに、全社的IT予算編成をするための、移行計画に相当することをする必要がある。と思えばよい。
このとき、企業であれば、暫定的には枠内予算の支出の際に、勘定項目で制御がかけれるが、省庁内でそれに相当することができるかの実現可能性の確認が必要。それができないとすると、IT予算を行政予算から切り出すことができなければ、現実的には「IT予算」なるものは存在せず、別の大枠予算の使途としてIT支出があるだけということになる。もちろん、その大枠予算を積み上げるために、IT経費が明記されているはずだが、予算執行時に枠内予算をどう使うかは必ずしも厳密な制約がないことが想定されるということ。
これらのことを確認し、それを前提としたグランドデザインにする必要がある。
政府CIOの成功因子のひとつに、IT投資の管理があることは確実。これがなければ、現行のCIO補佐官制度以上の効果は期待できなくなると考えてよい。(なお、CIO補佐官制度は、全体最適化以外については、相当の成果を出しているというのが、個人的認識)

想定スケジュール

準備室立ち上げを早急かつ具体的に。という意見があり、正論であるが、注意が必要。
たとえば、NISC(内閣官房情報セキュリティセンター)の設置の際は、事実上休眠に近かった、内閣官房情報セキュリティ対策推進室でNISCの立案作業を行い、その後、同室を発展解消して、NISCにした。
そのテクニックを参考にしてもよいかも。
すなわち、準備室を新設するのではなく、既存の組織に役割を持たせ、かつその組織をベースに政府CIO室に発展させると労力が少ない。
ただし、これはあくまで、「早急に」するのが至上であればの話し。政府CIO室を慎重に立案するのであれば、白紙としての準備室から設置を始めるというのは、時間を要すが、それは必要な時間と思ってスケジュールを考えるのは「遅い」ことにはならない。
NISCのときのように、既存組織で使えるものがあればよいが、関連性からすると、内閣官房情報通信技術(IT)室=本タスクフォースの事務局になりそうだが、ここにその能力があるかは(未検証という意味で)不明。
情報セキュリティ対策推進室には、NIRT(National Incident Response Team)という既存機能があったが、そこを事実上封印して、空箱にした状態で過去のしがらみなく立案作業ができた。IT室は、現業を持っている組織なので、そのときのような使い方をできるとはあまり思えない。
そういえば、前回のタスクフォースで、政府CIOグランドデザインの中で、既存組織との関係を明示すべきとの意見があったが、「5 政府CIO制度の組織」で、「IT戦略本部のほか関係する行政機関との関係の整理と併せて、引き続き検討する。」と丸められているだけ。
構成員が今日、詰め寄ることができれば、ここに、「内閣官房IT室が政府CIO室の準備室としての事務を行ない、その中で、同IT室の改廃も含めて検討する。」と書かせてもよかったかもしれない。しかし、上述のとおり、IT室が適任かは要確認。

なお、政府CIOの所掌を情報システムやITに限るのではなく、本来の情報戦略とするのであれば、NISCの統廃合も検討材料の中に入れるべき。(するかは別として検討材料の中という意味)
現行案では、NISCが外付けありきの図だが、なぜそう考えているのかは説明されるべき。
建前としてNISCには、民間の情報セキュリティ対策の立案も入っているが、事実上の活動はなく、それらはセキュア・ジャパンなどで各省庁の役割として分担させているだけ。それなら、その箇所だけを残して、それ以外を政府CIO室に併合することは、考えられなくはない。ただし、長所短所の検討をちゃんとした上での話し。

議題2:電子行政推進に関する基本方針の骨子案

特になし
(冒頭に書いたとおり、雑感がないというだけで、審議が不毛だったということではない)

議題3:新たなオンライン利用計画について(中間整理)の概要(案)

この範囲が、国の行政手続き(自治体を除く)であるということが再確認された。
言われてみると、建てつけとしては、それもありかとも思うが、切り出し方法が何か不自然という印象。
構成員からも、国の手続きの受付を自治体がしている場合の責任分解点が不明確であることが指摘されたが、明確な回答はなかった(ように聞こえた)。
その意味では、これは既定作業なので、これでいったん終結させた上で、今回の電子行政で範囲拡大して追加審議とするのが妥当かもしれないが、よくわからない。

議題4:使いやすくわかりやすい電子行政の将来像(株式会社サイトフォーディー提案)

実態はユーザインターフェースの改善提案に過ぎないものだが、それはそれで必要。
ただし、これを政府ポータルサイトでやる必要性は、個人的には不同意。そうではなく、ここで提案されたようなユーザインターフェースのフロントエンド処理又はクライアントツールを構築可能なような、APIを政府の各電子行政サービスは提供すべき。(構成員からは「エージェント実現機能」という表現があったように記憶しているが、そのとおり。)
言い換えると、提案されたようなツールを、家計簿ソフトで開発したり、企業会計ソフトで開発したり、自治体のウェブサービスで開発したりできるような、APIを各省庁が提供できるようになればよい。
技術標準化のような意見も構成員からあったが、定型データ形式のものは、XMLで提供するだけで簡便にした方がよい。なぜなら、そのAPI提供のシステム構築で大きな投資をするのはやめた方がよいから。定型でないものがあれば、適宜検討の必要をすればよい程度ではないか。ほとんど、定型のような気がしている。
なお、その場合、この範囲において、国民IDは技術的に不要。

しかし、国民IDがない場合には、バックエンドアクセスのための主体認証やクリデンシャルのデータをフロント又はクライアント側でデータ隔離をする設計が必須となる。Open Authenticationに相当するものがあれば、論理階層としてはよいが、その実装レベルでの隔離には、CMW で仕様化された Trusted Windows における Trusted Path (いわゆる T アイコン)に相当する技術がクライアント端末側に必要となる。それの技術解決は必要だが、国民ID番号の導入とのトレードオフは、これになると考えるべき。
この部分は、最上位技術を知っている技術者による検証をすべき。これができるのは防衛関連など限られているが、商用技術の限界で検討するのは不十分となる可能性あり。

議題5:国民ID制度の実現による新たな電子行政サービスイメージ(NTTコミュニケーションズ株式会社提案)

こちらはワークフローの提案。
構成員からも意見があったが、提案内容は「新たな」ではなく、現行サービスを組み合わせた提案だったのだが、それはそれで必要。というか、まさにやろうとすれば、本来できる内容であるとも言える。
仮に、それができない理由があるとすれば、各行政の根拠法の問題。だとすると、その法的解決は国民ID制度でも必須となること。そして、逆にその法制化をすれば、国民IDは必須ではないということに注意が必要。

提案資料には、「国民ID基盤(仮称)の整備が必要」とあったが、これはIT室に迎合して書いたのかわからないが、上述のとおり、提案内容は国民IDなしで実現不可能ではないもの。
時間の関係で、出生時の申請のサービスイメージだけが説明されたが、これは作ろうと思えばマッシュアップの延長線と言えなくもないものだった。

構成員から、自治体ポータルを共通化して統合ポータルにすべきとの意見があり、他の構成員が否定していたが、否定は当然。
自治体には個別サービスがあるのであって、自治体間を共通化するなどあり得ない。おそらく自身が住んでいる自治体と近隣の自治体のサービスを比べたことすらなかったのだろう。
電子政府ポータルとして、国のポータルサイトを考えるのも、ちょっと違和感。
住んでいる自治体のところに、電子行政ポータルがあるというのが、国と自治体をまとめた場合のポータルの現実解ではないかと思われる。その過渡期として、自治体ポータルから、国ポータルへのリンクがあってもよい。ただし、それでは、議題4で提案されたものと異なり、カテゴリがサービス提供者分類になることを意味する。
分類は、あくまで利用場面とすべき。
むしろ、切り分けるとすると、個人向けポータルと、企業などの事業者向けポータルという分け方ならば、入り口が2箇所に分かれていてもよい。

構成員から、電子行政を開始したら、書面手続きの廃止を検討する必要があるような意見があったが、これはまさに、SoA(サービス・オリエンテッド・アーキテクチャ)なく議論する落とし穴。
現状でも書面申請手続きのバックヤードにITがあるのが常識。
問題なのは、そのITシステムと、電子行政(と言われるオンライン利用)用のITシステムが2重になること。
電子行政用のITシステムができあがったら、書面申請手続きを廃止するのではなく、書面申請手続きのバックヤードに、電子行政用ITシステムをそのまま利用すればよい。
すなわち、役所に書面で申請されたら、窓口では担当者が書面で受理して、窓口内のネット接続PCから電子行政用システムにアクセスして、書面内容を申請代行すればよい。
それならば、書面申請を廃止した場合の、受付業務担当者の雇用問題も軟着陸できる。
そのような事務サービスを先に考えた上で、ICカードが本当に利便性を高めるかも議論してゆくことが不可欠。
オンライン利用化したら、書面手続きを廃止するのではなくて、書面手続き専用ITシステムを廃止する。というサービス設計が必要ということ。

(このページについては、後日、加筆・修正する場合があります。)

以下、前回気づいたことを備忘。

本タスクフォースの枠外で、この日の議題でもないが、電子行政という範囲が不十分。
電子政府の議論もすべき。
行政だけではなく政府という意味は、司法・立法の事務についても電子化の検討をオープンにすべきということ。
すなわち、主として裁判所と国会。
日本の裁判所が判例検索やデジタルフォレンジックに耐えれていないのは事実。これまで、電子証拠を裁判で取り扱うことについての課題が指摘されている。それが実際大きな問題になっていないのは、主として民民間であれば契約などで解釈を処理できているが、電子政府が入ってきて訴訟が絡んだ場合に、現在の裁判所で一般人の常識の通じるような、電子証拠の議論がされ得ないことに問題認識が必要。司法のIT対応は、加速させるべきだし、電子行政で発生する紛争解決のためにも必要なので、本来は電子司法と電子行政議論とは必ずしも、分離しておけることでもない。
立法についても同様。そちらは説明省略。

1月 7, 2011 | | コメント (0) | トラックバック (0)

2010年6月22日 (火)

情報経済革新戦略-日本勢は営業利益率で差

経済産業省が平成22年5月に発表した「情報経済革新戦略」は興味深い内容だ。

スライドは以下のPDFとして公開されている。

情報経済革新戦略
~情報通信コストの劇的低減を前提とした複合新産業の創出と社会システム構造の改革~
http://www.meti.go.jp/committee/summary/ipc0002/report01.pdf

この中のスライド6に「日本勢は、世界の主要プレイヤーと比較して、営業利益で大きな差」というスライドがある。

Slide1

これにちょっと書き込みをしてみると、さらにおもしろい。

Slide2

書き込んだオレンジ色の点線は、横軸の売上高に縦軸の営業利益率をかけただけだ。
つまり、営業利益額の等高線になる。
5000億~4兆円までを書き入れてみた。

すると、先頭にIBMがいて、それをマイクロソフトとGEが第2グループとして追従しており、続く第3グループが5千億~1兆円の間で、ひしめきあっている様子がうかがえる。

第3グループには、真上に向かう選択肢がありそうだが、営業利益率の上限はありそうだ。
40%を超えたら、ぼったくりと言われるかもしれない。(笑)
また、右に向かう選択肢はあるのだろうか?それはあり得るが、等高線をまたぐのが大変なことがわかる。

今後の競争は、オラクルやグーグルは、営業利益率を維持したまま売上拡大をし、サムソンやHPは、売上高を維持しつつ営業利益率向上をしようとしているのかもしれない。
各社は競争するかもしれないし、この中の位置づけを飛躍させるために合併するのかもしれない。

この資料、他のスライドにもいろいろ興味がある分析がされていて面白いが、いずれにしても、日本企業には対抗策が必要のようだ。
日本企業が成長してくれないと、在日外資製造業に未来はないので、何らか役立つことがしたいと改めて思ったが、肝心の日本企業にその切実感があるといいのだけれど・・・

6月 22, 2010 | | コメント (0) | トラックバック (0)

2010年6月 7日 (月)

LZHファイルを検索して全変換しないといけない

国産の圧縮ソフトとして有名な「LZH 書庫」ファイルですが、先月に発生した脆弱性問題が一因となってか、開発中止になりそうですね。

開発者の Micco さんのホームページ

もしも、最終的にも開発中止となったら、自分のディスク内で、LZHファイルをすべて見つけ出して、いまのうちに解凍するか、別の形式に変換しておかないと、将来開けなくなるかもしれません。

今回の経緯については、いろいろネットで取り上げられていて、中止の犯人探しがされています。(笑)

開発中止の記事いくつか

Unlha32.dll等開発停止、LHA書庫の使用中止呼びかけ

国産の圧縮形式「LZH」のUNLHA32.DLLの開発中止へ、LZH形式使用中止を呼びかけ

国産のソフトが開発中止になると悲しいということはありますが、それよりも、この種の長期に提供されることが重要なソフトが打ち切られると、国産ソフトの継続性を信頼する観点でイメージダウンになることも心配です。

現在、クラウドコンピューティングにおいても、クラウドベンダーの事業継続性はひとつの観点となっていますしね。


と、国の心配をする前に、まずは、自分のハードディスクやバックアップの中に、LZH ファイルがないかを検索して、みつけたら、今のうちに解凍するか、別の形式に圧縮しなおしておかないといけませんね。

媒体の種類が経年でドライブがなくなったとき(たとえば、8インチフロッピーとか、DDSテープとか)に備えないといけない問題がありましたが、このようなアクセスソフトの継続性も注意しないといけませんね。
このことは、e文書法の検討でもふれられていますが、実際に起こり得る状況になったということですね。


PDF 形式ファイルも国際規格の仕様範囲内と、拡張仕様に違いがあるけど、国際規格が定まっていることと、それにアクセスするソフトを誰かが将来に渡って開発継続してくれるかは別問題なことに注意しないといけませんね。

6月 7, 2010 | | コメント (0) | トラックバック (0)

2010年6月 3日 (木)

技術者以外にもわかる「DPI技術のマーケティング利用議論」入門

総務省が『「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会」第二次提言』の中で、DPI に触れたため、DPI の議論がちょっとホットになってきた。

でも、「DPIって何?」「小文字の dpi なら、dots per inch でプリンタの印刷精度だよね」というのは、文系に限らず、IT系の人にとっても、あっても不思議ではない。
文脈を踏まえないと、唐突な3文字略語だからだ。(3文字程度では、他のものと同じ略語になってもしかたない。)

DPI (Deep Packet Inspector) 技術のマーケティング利用を議論するときに、そもそも、DPI ってどこから登場したのか?を知っておくと、議論に参加しやすいかもしれない。

クラウドコンピューティングというバズワード(Buz Word: Business word)のもとに、
一部の ASP(アプリケーション・サービス・プロバイダー) が自らを SaaS ベンダーと名乗ってみたり、
一部のサーバホスティング会社が、自らを HaaS ベンダーと名乗ってみたり、
と同様に、DPI という用語は技術的には範囲があいまいで、「自称」でしかないということを踏まえないと、最後に大切なことを取りこぼしてしまうかもしれない。

もともと、DPI は、IDS (Intrusion Detection System:侵入検出装置) メーカーがパケットのヘッダ部分(送信元IP&ポート、送信先IP&ポート)だけではなく、パケット本体の中味も検査するようになったときに、ヘッダ部分しか検査しない IDS との機能差別化を狙って作った、バズワードだ。

それを差別化しようとした背景には、その頃、登場した後発の IDS メーカーが、IPS (Intrusion Prevention System) という機能を設けて、「侵入(intrusion)を検出(detection)するだけでは意味がなく、阻止(prevention)しないと対策として役立たない」というもっともらしいことを主張したからだ。

これを「もっともらしい」と表現するのは、老舗IDSはヘッダ部分だけの頃からやっていて、その時代にはファイヤーウォールとIDSは一組で使うもので、ファイヤウォールが侵入を阻止して、その取りこぼしを IDS が監視するという役割分担があったため、検出に特化していればよかった。
なので、「意味がなく」というのは、誹謗であって、「意味もあり、役割も果たしていた」のが正しいはずだ。
ところが、パケット本体を IDS が検査するようになると、処理性能の問題から、それをリアルタイムでファイヤーウォールが通過制御するというのは困難なため、パケット本体の検査を備えた IDS が、ファイヤウォールと連動して、IPS を実現するということが期待されるようになった。
つまり、ファイヤーウォールは、従来どおりパケットヘッダ検査による通過制御を行い、それと同時に IDS がパケット本体検査をして、不適切なパケットを検出したら、それをファイヤウォールなどに通知して、そのパケットを中断させることで、不適切なパケットが通信を完遂できないようにして、結果として、IPS として「阻止」をするというわけだ。
近年は処理性能が向上したため、このような「ちょっと遅れた阻止」ではなく、リアルタイムに阻止できるようになっているが、当初はそのような、IDS の機能差別化によって始まった。

技術の経緯はまどろっこしいが、ビジネスの背景としては単純だ。
IDS の技術は成熟していたが、ファイヤウォールなどと連動するなどして IPS を実現するという部分は、後発メーカーとしては、先行メーカーと競合するときの売りになるということで、IPS に着目させるため、「侵入を検出するだけでは意味がなく、阻止しないと対策として役立たない」として IDS の土俵を仕切りなおすという、売り文句ができた。

この経緯において、パケットのヘッダだけ処理するファイヤーウォールや IDS と、パケット本体を検査するものを区別するために、後者について、DPI (Deep Packet Inspection) という用語を用いた。

そして、当初の DPI は単純な(静的な)パターンマッチングだったが、DPI を掻い潜ろうとする不正パケット側が動的に変化するパターンを用いたため、DPI 側もそれを検出するべく、動的パターンにもマッチングできるように進化していった。

したがって、DPI は侵入検出又は阻止を目的として進化を遂げた技術が出発点だ。

ところが、パケット本体内部の動的パターンのマッチングができるようになると、それは、利用者のアクセス嗜好解析など侵入阻止以外の目的にも使えることになるというパンドラの箱になったことを意味する。

DPI のマーケット利用の是非の議論は、このパンドラの箱のフタを開けることの是非の議論だ。

そして、いったんフタが開いてしまうと、リアルタイム検出していただけだったのが、ゲートウェイサーバ(中継サーバ)のように配置して、もとのパケットにない「印」をパケットに挿入してから中継することなどの機能も出始めた。その印としては、たとえば、cookie などを挿入することが考えられる。
そのように、他にない機能を盛り込みつつ、その機能があるのが、真の DPI だという製品差別化が行われた。


街中の別の物に置き換えて考えてみるとわかりやすい。


駅や商店街などに、防犯のために、監視カメラが設置されている。
この監視カメラを使って、利用客の行動分析や嗜好分析をできないか。
たとえば、食堂から出てきた人が、次にコンビニエンスストアに入ったなら、その人には、おにぎりを勧めるよりも、雑誌などを勧める方がよいということに使うということである。
このとき、そのようなサービスを有難いと思うか、監視カメラの先でそんなことを分析されるのは気持ち悪いと思うかは、その人次第なので、本人の希望次第でよいのではないかという考え方もある。
あるいは、監視カメラは、その名のとおり、監視が目的なのだから、それ以外のことに使うのは絶対禁止という考え方もある。


上記の例は、DPI のマーケット利用に否定的と取れる例を出してしまったかもしれないが、この記事では、その是非の結論を出すつもりはない。

ここで明確にしておきたかったことは、DPI のマーケティング利用の是非という議論が始まっているが、「DPI」という用語に限定するとおかしなことになる。
なぜなら、DPI という用語は、IDS や IPS という製品を売っていた人が、自らのビジネスや技術の差別化のために用意したバズワードであって、はっきりとした技術領域ではない。
つまり、「DPI の D はどういう意味で deep なの?」とか「DPI の I は検出や阻止、あるいは解析と inspection は何が異なるの?」というのは不毛で、「Deep Packed Inspection」という表現がビジネスインパクトのある語感だったというだけのことだろうからだ。
議論の過程を単純化するために、「DPI」という用語を使っておいてもよいが、それで結論が出たら、最後に、その用語の部分を「パケット本体の分析」に置き換えないと、本質的な問題を取りこぼしてしまうことになる。
すなわち、仮に「DPI のマーケット利用禁止」という結論が出たら、その表現のままでは、製品カテゴリーを DPI 以外に変更されたら逃れられてしまう。
それを正しく表現するには、「パケット本体分析のマーケット利用禁止」として、逃げ道を塞ぐ必要がある。
そうしないと、そもそも、自分達の都合で自ら名乗ったカテゴリーなのだから、それが不利な名称なら自分達で勝手に変えられてしまう。

また、議論が DPI を ISP に設置する文脈でなされているのか否かで、逆に技術制約の範囲を不必要に拡大してしまうことになる点にも併せて注意が必要だ。
たとえば、オンラインショッピングサイト自身が、自社の利用者の行動分析に、自社サイト内に DPI 技術を用いた装置を設置することは、ISP に設置してその分析結果を ISP 以外が利用することとは意味が異なることに注意が必要だ。
なぜなら、DPI を「パケット本体分析」とするなら、ショッピングサイトが自サイトの利用者行動分析をすることは、通常の cookie や web beacon などでも行っていることで、それを DPI 装置に高速に処理させるということは、ISP が第三者に利用させたり、第三者が ISP に設置することとは意味合いが異なる。

このように、DPI の議論は、その文脈で暗黙の範囲や条件が設定されていることを踏まえて、それを確認した上で議論に参加しなければ意見がかみ合わなくなる。
そして確認して議論したならば、議論の最後で、それら暗黙のことを明示的に示してから、議論に参加していなかった人達に示さないと、議論の意図が伝わらないことが考えられる。

DPI という用語だけを使って、逃げ道を作られないようにしつつ、
逃げ道をふさぐ用語(たとえば、「パケット本体分析」など)に適切な条件を付けずに否定して、無用の反発を受けないように議論する必要がある。

6月 3, 2010 | | コメント (0) | トラックバック (0)

2008年9月 5日 (金)

経済産業省 「ITサービス継続ガイドライン」

経済産業省が「ITサービス継続ガイドライン」を公表しました。

これまであいまいにされてきたことについて、このガイドラインで、実はさらっとふれています。。。

情報セキュリティと事業継続は包含関係なのか、上下関係なのか、横並びなのかについて、いろいろな考え方があります。
このガイドラインでは、図 2.1-2 「IT サービス継続、事業継続、IT 戦略との関係」(4ページ)で、事業継続にITサービス継続を含むとした上で、以下の図 2.1-3 「IT サービス継続と情報セキュリティとの関係」(5ページ)があります。

図 2.1-3

この図では、情報セキュリティの基本要件である機密性・完全性・可用性のうち、可用性だけをITサービス継続に配置した上で、以下のような注釈を加えています。

4ページ 脚注5

広義のIT サービス継続には、機密性・完全性の要素も含まれ得るが、本ガイドラインでは主に可用性の 面に着目し、情報の機密性と完全性の確保を主に情報セキュリティ上の責務と捉えた上で、IT サービス継 続は常に情報セキュリティ対策と並行して確保すべきとの考えに立つものとする。

つまり、「情報の機密性と完全性の確保は、情報セキュリティの責務であり、ITサービス継続には含んでいない。ただし、それはやらないということではなく、常に情報セキュリティ対策と並行して確保しなければならないことを意味する。」という考え方もあるとしました。
言い換えると、
「仮に、ITサービス継続にて、可用性を維持したものの、機密性と完全性だけが損なわれた場合があったとしたら、その場合には、ITサービス継続は機能したことになり、その際に、情報セキュリティのうち可用性以外の要件が機能しなかった。」という考え方で整理して、マネージメントシステムを構築することができます。

ガイドラインでのひとつの捉え方として、これを一般論とするつもりではないことにしていますが、これまであまり仮例も示されていなかったので、いいきっかけになるものと思います。


おまけ・・・

一方で、ITサービス継続で、情報セキュリティからはみ出している部分はどういうものになるのでしょうか?

結構つらいですが、
一応、無理無理ですが、以下のような解釈を議論の出発点にするしかなさそうです。

「情報セキュリティ対策は、リスク分析時の脅威の特定に基づくため、脅威として、たとえば故障を含めていなければ、それへのリスク対応としての情報セキュリティ対策が見逃されることになる。
それに対して、ITサービス継続対策は、脅威の有無を問わず、継続するという目標に必要な対策をすべて講じることがあってもよい。
検討においては、必要な対策をすべて洗い出す際に、脅威を想定するのが一般的であるため、ほとんどの場合は、可用性の侵害への脅威として特定されることで足りると考えるが、分類の考え方としては、情報セキュリティは脅威の特定に基づくもの、ITサービス継続は、必ずしも脅威に基づくことに限定しないものとして、わずかながら相違部分がある。」

これについてもいつかガイドラインに明記できるような仮例が示せるときがくるといいですな。。。


9月 5, 2008 | | コメント (0) | トラックバック (0)

2008年2月28日 (木)

ITゼネコンの構造的破綻?

ちょっとショッキングなタイトルですが、第1弾として、「無責任な委託の連鎖」ということで・・・

Y's Station にて、「委託先における情報セキュリティ対策のあり方と認証制度の関係」をお聴きください。

2月 28, 2008 | | コメント (0) | トラックバック (0)

2006年2月10日 (金)

e文書法解説完結

これまで、以下のとおり書き連ねたe文書法ですが・・・

 その1:e文書法特需はありません
 その2:e文書法解説(前編)
 その3:e文書法解説(後編1)

e文書法解説の完結編の紹介です。

後編は、通称、e文書法ガイドラインと呼ばれている「文書の電磁的保存等に関する検討委員会」の報告書を2回に分けて解説しました。
その2回目となり、これで全4回の連載はおしまいです。

連載の最終回は

●#4:文書の電子化に踏み切る前に、知っておきたい電子文書の特性

です。

これまでの連載は、こちらにリンクがあります。

なお、第3回で予告した隠しページは・・・
スキャンした電子文書の見読性についてというページにあります。
これは、連載の第3回原稿を編集者に提出した際に、「改ざんの画像イメージを用意してもらえませんか?その中のいくつかを記事に挿入したいので。」と言われて、画像イメージをまとめて送るときに、編集の人への解説として用意したものでした。
ところが、編集の人曰く、「こっちのページの方が原稿よりわかりやすいじゃないですか~」とのことでした。

ぼくとしては、原稿の方が内容として濃くて、こちらは、一見わかりやすそうだけど、実はスキャナ遊びのようなもので文章そのものには内容がない。と思っていたのですがねぇ。

みなさんはどう思われますかね。

2月 10, 2006 | | コメント (0) | トラックバック (0)

2006年1月20日 (金)

e文書法解説(後編1)

e文書法解説の後編の紹介です。

後編は、通称、e文書法ガイドラインと呼ばれている「文書の電磁的保存等に関する検討委員会」の報告書の解説です。

前編につづいて後編の第3回が掲載されました。

●#3:スキャンした紙文書に改ざんはないといえる?

実は上記の第3回解説には、隠しページがあります。。。
それは、もうちょっとしたらお知らせいたします。

連載は、次回の第4回で最終回となります。
衝撃のラスト・・・んなわけないです。。が、ご期待ください。

1月 20, 2006 | | コメント (0) | トラックバック (1)

2006年1月 6日 (金)

e文書法解説(前編)

以前、愚痴のように書いた「e文書法特需はありません」をもとに、IT media エンタープライズの連載として、まとめ始めてみました。

言いたいことは同じなのですが、解説とかもちゃんとつけて整理してみたつもりです。


IT media エンタープライズの連載としてe文章法の解説を書き始めました。

●#1:誤解から生まれるe文書法の落とし穴
●#2:e文書法は電子化のための金科玉条ではない

この後はe文書法の報告書の説明になるため、急に技術的な話になってしまいますが、参考にしてみてください。

連載回数は、上記を含めて全部で4回か5回を予定しています。

後編が仕上がったら、また紹介させていただきます。

1月 6, 2006 | | コメント (1) | トラックバック (0)

2005年5月13日 (金)

IPA のセキュアOS関連報告書

いわゆるセキュアOS関係について IPA が公開した報告書です。

強制的アクセス制御に基づく Web サーバーに関する調査・設計(IPA)
http://www.ipa.go.jp/security/fy16/reports/mandatory_access_contol/web_server.html

電子政府システムにおけるアクセス制御要件に関する調査(IPA)
http://www.ipa.go.jp/security/fy16/reports/eGov_access_control/index.html

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

2005年5月10日 (火)

情報セキュリティと情報活用のバランスをふまえた企業情報管理戦略

ヒューレット・パッカードの自社事例として、「情報セキュリティと情報活用のバランスをふまえた企業情報管理戦略」と題して当社のプライベートイベントである HP World 2005 にて講演をすることになっています。


情報管理戦略の中でも、個人情報のILMについてを中心に紹介します。
今週号の AERA にて少しふれられていますが、ある条件下では、社内の誰も顧客の個人情報にアクセスしなくてもビジネスを遂行することができます。アクセスしなければ漏えいすることはありません。

ただ、ここで紹介する内容は、HPにとっては、1996年に計画し2001年に完成する予定だったIT戦略です。
その後、Agilent Technologies との分社や Compaq との合併などにより、当初計画から2年遅れて2003年に一部運用を開始したものです。
1996年当時は、この計画のセキュリティアーキテクトとして参加し、その後分社や合併で進捗がなかったため半ば忘れていたものでしたが、いまとなっては、その運用の責任者になるとは思っていませんでした。
今回の講演のために、96年当時に自分で作成した資料などを復習したりしています。
これらのことは国内社外でも講演しているものですので、不思議なかんじです。
約9年前に設計したアーキテクチャを、最新の対策として紹介するわけですから・・・

実際に90年代後半には、国内日本企業にコンサルティングも実施しており、当社の当初線表どおりに2001年に実現した日本企業もあります。
しかし、IT戦略というものは、外見からは実は見えにくいものです。
この講演内容を聞いて、どれだけの人が、このIT戦略に基づいたITを実装している日本企業を言い当てることができるのかが実は楽しみです。
そして、そのことがITアーキテクトの重要性に気づき、関心を持ってもらえるようになればいいなと思っています。

日本のIT構築の多くは、欧米企業の「外見」だけをまねているように思えて、嘆かわしいからです。
ITはビジネスを向上するための方策であって、目的ではないということが当たり前のことですが、とても重要なことなのです。

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

2005年5月 9日 (月)

経済産業省 e文書ガイドライン

「文書の電磁的保存等に関する検討委員会」の報告書が発表されました。

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

個人的なコメントは、
経済産業省 e文書ガイドラインの補足
として書いておきました。

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

2005年5月 8日 (日)

Webアクセシビリティ

Webアクセシビリティについてお勉強しましょう

まずは、JIS規格から。

JIS X8341-3
http://search.yahoo.co.jp/bin/query?p=JIS+X8341-3&fr=top

5月 8, 2005 | | コメント (0) | トラックバック (0)

2005年4月28日 (木)

事業活動のIT化に係る規制の状況

内閣官房IT担当室
「事業活動のIT化に係る規制の状況(平成17年4月版)に関する意見の募集」
http://www.kantei.go.jp/jp/singi/it2/pc/050408iken.html
にあったリンクを以下にメモしておきます。


●「事業活動のIT化に係る規制の状況」(平成17年4月版)
http://www.kantei.go.jp/jp/singi/it2/pc/050408iken_s.html
の抜粋として;
●「事業活動のIT化に係る規制の状況(概要)」(PDF)
http://www.kantei.go.jp/jp/singi/it2/pc/050408iken/00gaiyou.pdf

それらの発端
●「事業活動のIT化に係る規制の概要」
http://www.kantei.go.jp/jp/singi/it2/dai16/16kisei.html


ITで注意すべき法令等を俯瞰するのに役立つよい資料です。


ちなみに、当社は、この意見募集について、米国商務省から案内をいただきました。
日本国内でのITビジネスの促進に活用するとよいですよ。という趣旨です。
後日、在日アメリカ大使館からも通達するということになっています。
日本の有力企業には同様に政府から案内を能動的に行なっているのかな?
Webに掲載しただけだとすると、不親切かもしれませんね。

この類のことはよくあって、在日アメリカ大使館に呼ばれて意見を求められたり、勉強会で勉強させられたり・・・
商務省のマメさには感心してます。

4月 28, 2005 | | コメント (0) | トラックバック (0)

2005年4月 5日 (火)

IT道徳教育

読売新聞2005/4/5朝刊によると、世田谷区にて、区立小学校1校を「情報モラル教育」の研究校に指定する。とのこと。

きっかけは、世田谷区立中学の生徒が、旧千円札を偽造したこと。

3/25 に提出された検討委員会提言には、

家庭でのパソコンや携帯電話を使うルールとマナーの徹底や、有害情報を見分ける健全な価値観を子どもたちに育てるため、親も一定程度、情報を判断し、使いこなす能力を身につける必要がある。 また、学校には、パソコンの使い方に偏った従来の情報教育を改め、コミュニケーション能力や判断力を育てるカリキュラム編成などを求めた。

とあるらしい。

「コミュニケーション能力や判断力を育てるカリキュラム」。
大人にも展開してほしい。


4月 5, 2005 | | コメント (0) | トラックバック (0)

2005年4月 1日 (金)

経済産業省 技術戦略マップ

報道発表より転載:

経済産業省は、産学官の知見を結集し、我が国初となる『技術戦略マップ』を20分野で策定しました。技術戦略マップは、新産業を創造していくために必要な技術目標や製品・サービスの需要を創造するための方策を示したものです。今後、本マップを幅広く産官学に提供し、異分野連携等を促進するとともに、当省の研究開発マネジメントに活用していきます。

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

ソフトウェアのセキュリティとしては、

アクセス制御技術
デジタル・フォレンジック技術
電子署名・認証
暗号技術
セキュリティ評価技術

をあげています。

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