砂糖の甘い付箋

テレワークで経営者だけが知っておくべきこと～ITよりも労務管理に注意

本稿は、経営者向けの記事です。

新型コロナウイルス対策による緊急事態宣言で、急遽、テレワークを始めた会社の経営者が知っておかなければならないことがある。

テレワークをするために、資料やパソコンの持ち出しのための検討ばかりをした会社は、特に要注意である。
なぜなら、テレワークは、会社にとって、IT部門や総務部門が担当する情報管理やIT管理の課題であるばかりではなく、人事部門が担当する労務管理の課題でもあるからである。

 

今回の対応で、従来から裁量労働制などになっていなかったのに、「なんだ、テレワークって思っていたより簡単にできたな。」と思っているとすると、ここで紹介する問題に陥りやすい。

ここでは、文面を読みやすくするために、会社と書くが、会社ではない機関などでも同じである。
その場合は、文中の会社を機関、社員を職員などに読み替えて読んでもらうとよい。

勤務形態と就業規則

まず、テレワークの前に、そもそも、勤務（就業）とはなんだったのかを見返してみる。
勤務とは、決められた就業時間、決められた就業場所で、決められた仕事内容（就業内容）をすることである。
そして、これらの決め事は、就業規則で定めており、変更するには、就業規則を改定しなければならず、就業規則の改定は労働基準監督署に届け出なければならない。
就業規則の作成義務がない規模の会社でも、労働条件通知書での社員への通知が必要だ。
よって、どんな会社であっても、変更するには、何らかの書面の改定をする必要がある。

実際にも、厚生労働省が出している「テレワークではじめる働き方改革ガイドライン」の中で、以下のとおり、テレワークの導入には、就業規則等の改定が必要であるとしている。

テレワークを導入する場合には、就業規則などにテレワーク勤務に関して規定しておくことが必要です。（中略）テレワーク勤務に関する規定を作成・変更した際は、所定の手続を経て、所轄労働基準監督署に届け出ることが必要です。 例えば、テレワーク勤務について、就業規則に次のことを定める必要があります。 ●テレワーク勤務を命じることに関する規程 ●テレワーク勤務用の労働時間を設ける場合、その労働時間に関する規程 ●通信費等の負担に関する規程 なお、就業規則の作成義務がない会社では、前述のことについて労使協定を結んだり、労働条件通知書で労働者に通知することが必要です。

テレワーク導入は段階的に範囲拡大するのが基本

テレワークには、在宅勤務、モバイルワーク、サテライトオフィス勤務の3つの形態がある。どれか1つでもよいし、組み合わせてもよい。

テレワークを始めるために、最初にすることは、対象者、対象業務、実施頻度の３つの範囲を検討することである。
会社の業務・業態と社員の職種に合わせて、適した形態を選び、解決できる課題から取り組み、それぞれの実施範囲を段階的に順次拡大していくのがよいとされている。

しかし、緊急事態宣言を受けて、急遽、テレワークを始めた会社は、その目的が人との接触を減らすことから、在宅勤務を選んで、これら３つの範囲をいっぺんに開放したような状態になっていることが考えられる。

それだと、就業条件である、時間、場所、仕事内容のうち、場所だけの変更になると思うかもしれない。
しかし、就業時間の管理は、以下のいずれかで管理することになる。

●所定労働時間制

○通常の時間管理制（労働基準法第32条）

○フレックスタイム制（同条の2,3,4）

●みなし労働時間制

○事業場外みなし時間労働制（同法第38条の2）

○裁量労働制（同法第38条の3と4）

上記の中からの選択であることを踏まえて、テレワークについて考えてみる。

テレワーク中の就業管理

就業時間というと、規則に定められているので、社員がその時間に出勤する義務が一方的にあるだけだと思っているかもしれないが、それは雇用契約上の義務である。
労働基準法の観点からすると、会社が社員の就業時間を管理する義務がある。
管理というと上から目線だが、社員を縛るためのものではない。
社員が安全に労働できている状態であることについて、会社に責任を持たせるためのものでる。
したがって、法律上、会社が社員の就業時間を把握する義務があり、それは労働者を守るためにある。

テレワーク前が、通常の時間管理制だった場合には、たとえば、朝9時出勤で夕方6時に退勤、昼休みは12時の前後15分以内から1時間などの場合には、在宅勤務でも同じ勤務をしなければならない。
これを就業規則等の改定なしで変更することはできない。

オフィス勤務での昼休みは、弁当か外食、社員食堂の利用が想定されていると思うが、在宅勤務で食事を調理するなら、昼休みの1時間内に収めないといけないことになる。
また、家で子どもの面倒をみながらの在宅勤務であれば、子どもの世話をしている時間は、勤務を怠っていることになる。
簡単にいうと、オフィスに子連れで来て子供の世話をするのと同じ扱いになる。

みなし労働時間制には、事業場外みなし時間労働制がある。
派遣先常駐などで社員の就業状態を直接把握することが困難な状況に選択されるものである。
その点では、在宅で仕事をすると、直接把握できない状況と思うかもしれないが、法律上は以下の条件が含まれている。

●パソコンが使用者の指示で常時通信可能な状態ではないこと
●作業が随時使用者の具体的な指示に基づいて行われていないこと

そのため、在宅でインターネット接続したパソコンの使用を求めていたり、勤務中に作業指示をしたりする場合には、事業場外みなし時間労働にすることはできない。

時間管理制でも、勤務の中断という規程を設けることはできるが、たとえば、1時間ごとに5分間休憩を取ることなどを想定したものであり、子どもの世話などの偶発的なことを想定しているものではないため、在宅勤務にはあまり適していない。

テレワーク中の就業時間

以上のことから、パソコンをネット接続したり、作業を随時依頼したりする在宅勤務では、時間管理制以外の選択としては、フレックスタイム制か裁量労働制になる。

しかし、時間管理制だったものを、フレックスタイム制やみなし労働時間制に移行するには、規則等を事務的に改定する以上の検討が必要になることは容易に想像がつく。

時間管理制から、それらへ移行するための検討ですぐに思いつくのは、社員の業績評価基準の見直しや、その結果の管理職への周知・教育などの事業面のことがあると思う。
それらの課題は、事業部門が想像を働かせれば洗い出していけると思うので、ここでは、見落とされがちな課題を紹介しておく。

在宅での勤務になると、何が就業で、何は就業でないのかの区別の線引きが難しくなる。

その点では、通常の時間管理制は、定めた時間帯の中か否かで判断でき、線引きはいくらか単純になる。

オフィス勤務のフレックスタイム制では、時間は自由だが、オフィスに出勤している間が就業となり、こちらも線引きはできている。

しかし、テレワークでのフレックスタイム制や裁量労働制は、極端に言ってしまえば、社員が就業だと思ったことは就業になる可能性がある。
社員が、夕方にいったん仕事を終えた後で、夜になってからふと気になって、パソコンで会社のメールを読んだら、就業になるのかという問題である。
それが深夜時間帯でフレックスタイム制ならば、深夜残業をしたことになる可能性もある。
残業は、会社からの指示によってのみ本来は発生するが、黙示の指示があった状況とされれば、残業になる可能性があるのである。

そのようなことを会社が把握しなければならないという義務は、本来はとても難しい。
そこで、段階的にテレワークを導入する場合には、テレワークは社員の希望や選択で実施するという建付けから始めることが多い。

先述したとおり、会社が就業状態を把握する義務は、社員を守るためにある。
そのため、その社員が希望して実施するということにすると、会社が社員に強制したことではないということにしやすいからである。

その意味では、今回の緊急事態宣言の前から在宅勤務を導入していた場合も、オフィス勤務をすることができるが、「在宅勤務をしてもよい」という状態だったとすると、今回の宣言への対応で「オフィスではなく在宅で勤務してください。」という指示は、それ以前の在宅勤務と異質になっていることについて再確認の必要がある。（が、再確認の内容については、字数の関係で触れないことにする。）

テレワーク中の労災

フレックスタイム制や裁量労働制にしているのに、社員がしていることが就業か否かの線引きがなぜ必要になるかというと、労災保険適用の判断がひとつの理由である。

たとえば、オフィス内でトレイに行く途中に転んで怪我をすれば、基本的には労災になる。
しかし、それが在宅勤務中だとしたら、どう判断するのかということになる。

以下の事例がある。

自宅で所定労働時間にパソコン業務を行っていたが、トイレに行くため作業場所を離席した後、作業場所に戻り椅子に座ろうとして転倒した事案は、業務行為に付随する行為に起因して災害が発生しており、私的行為によるものとも認められないため、業務災害と認められる。

時間管理制であれば、朝9時から午後6時までなら、業務災害になるということである。実際にも、その時間帯は勤務に専念してもらっていることになるので当然といえば、当然だ。

しかし、フレックスタイム制や裁量労働制のときには、時間帯では決められないことになるので、どう取り扱うかには検討が必要である。

ちなみに、トイレ休憩で離席することは、法律上は生理現象として勤務時間から除外されない。
トイレ休憩ではなく、トイレ勤務ということだ。
一方で、喫煙は、法律上は生理現象として認められておらず勤務をしていないことになる。
したがって、タバコ休憩ではなく、タバコさぼりという違いがあることは、あまり知られていない。
喫煙者からすると、「いや、喫煙室での会話は仕事だ。」と言い出しそうだが、それなら、おやつ室があってもよいじゃないかとかいう話しも字数の関係で触れない。

家の中で転んで怪我をする人は少ないかもしれないが、急遽始めたテレワークを在宅勤務にしっかりと限定しておらず、モバイルワークによるテレワークやBYODをあいまいに認めてしまっていると、歩きスマフォでの事故などの可能性がある。
怪我まではしなくても、会社のメールを見ようとして、私物のスマフォを落として壊れることはあるかもしれない。

そのようなことに備えるためには、「テレワークをしてもよい」のではなく、テレワークを在宅勤務に限定した上で、BYODや定めた以外の勤務をしてはならない。とあらかじめ具体的に決め、なおかつ周知しておくことが不可欠になる。

歩きスマフォをしてはいけない。というためには、移動中は業務をしてはいけない。という覚悟が必要だ。
移動中にもメール連絡はとりたいが、歩きスマフォは禁止するというのでは、つじつまが合わない。

以上のような観点も含めて、労務管理としては、勤怠管理、在席管理、業務管理をしなければならないとされている。

テレワーク中の環境整備

また、テレワーク時の作業環境管理の義務もある。

近年、オフィスでは、「VDT作業における労働衛生管理」に対応したことが記憶にある人も多いと思う。
たとえば、パソコン画面は500ルクス以下、書面及びキーボード面は300ルクス以上の照明として明暗差をなくすなどの照度基準や、椅子と机とパソコンの高さの確認をして、必要に応じて改善をしたはずである。

在宅勤務においては、オフィスで定めている労働衛生管理と同等のことが会社に求められている。
照度確認だけでも、社員ひとりひとりの家庭の確認をするのは、少なくない作業である。

テレワーク中のコスト負担

さらに、テレワーク時のコスト負担がある。

先述した環境整備は会社の義務だから、基本的には、会社にコスト負担の義務がある。

それ以外にも、家で仕事をするために必要になるものがある。
書面での作業であれば、家で使う文房具のコストくらいでわかりやすい。
紙の書面がないクラウドサービスで社員のパソコンやスマフォを使わせるなら、そのコストがある。社員のものを使わせずに、会社のパソコンを貸与する場合であっても、通信回線のコストなどもある。
社員がもともと常時インターネット接続する契約をしていれば、在宅勤務によって追加の支出が発生していないはずであるが、もともとそうでなかったと言われれば、誰が負担するかを決めておかなければならない。
また、在宅で勤務するための光熱費のコストもある。
特に一人暮らしや、共働きなどで、平日の日中は家に人がいなかった場合には、在宅勤務によってエアコンの電気代の追加支出が必要になるかもしれない。

通信費や光熱費については、テレワークをする場合には、手当として要否を検討し、「あらかじめ」定めておく必要があるとされている。
手当をあらかじめ定めておかなかった場合は、手当を払わなくてよいということになるかというと、そうではなく、むしろ逆である。
就業のために発生した支出なのであれば、手当を出すのが基本になるという可能性がある。

電気代については、夏場のエアコン代は少なくない支出になる場合がある。会社に行っている間は、エアコンを使っていなかったとすると、2倍近くに増える可能性もある。1日7時間寝て17時間起きているとすると週に約120時間起きてることになる。一方で、平日の日中に在宅勤務すると、通勤時間の分も在宅になり、1日10時間家に居る時間が増えるとすると週に50時間家に多くいることになる。単純に計算すれば、家にいる時間が週70時間だったものが120時間になる。

先にも述べたが、テレワークを順次拡大しながら導入するなら、在宅勤務条件として、これらのコストの本人負担があっても在宅を希望する人などから導入を始めることができる。
希望者に対してであれば、「光熱費や通信費などの手当てがないですが、在宅での勤務を希望するならば、在宅勤務をすることができます。」という導入ができるということである。

テレワークに必要な社内ルール

以上で説明したこと以外にも、「テレワーク勤務に必要な社内ルールづくり検証項目チェックリスト」では、以下のことが示されている。

「テレワークしてもよい」と「してください」の違い

今回の緊急事態宣言では、政府や自治体は、「なるべく、在宅で勤務してください。」と市民に要請した。
これに応じて、会社が社員に「在宅で勤務してください。」と指示した。
なんとなく、在宅勤務を指示したのは、会社ではなく、政府や自治体であるような流れになっている。
しかし、上記のように書き改めてみると、指示したのが会社であることは明らかだろう。
テレワークについてITなどの情報管理の課題は、誰が指示したかによって違いはないものの、労務管理の課題は、違いがあることになる。

つまり、「テレワークしてもよい」と、「テレワークしてください」とは労務課題としては、抜本的なところで異なることを踏まえつつ、現状のテレワークが、「なんだ、テレワークって思っていたより簡単にできたな。」と思う事なかれと老婆心ながら紹介した。

詳細については、参考資料のリンク集を下記に用意しておいたので、そちらを参考にするとよい。

テレワーク導入のための社内規程類の改定に関して、ここまで読んでもよくわからなかったなんてことはないはずだ・・・が、コンサルティングについて オフィス四々十六 に相談してもいい。（ぺこぱ風）

注：本稿は、経営者向けの記事です。社員が読んで「え？在宅勤務に必要な照明器具とか椅子とか電気代って請求できるんだ！」などと悪知恵をつけてはいけません。。。

参考資料（リンク先は2020年4月時点）

厚生労働省

●働き方・休み方改善ポータルサイト → 参考資料 → テレワーク-資料

○テレワークではじめる働き方改革　テレワークの運用・導入ガイドブック [PDF]
　Ⅱ　実践編　第4章　テレワークのためのルールづくり

○テレワーク導入のための労務管理等Q&A集 [PDF]

●テレワーク総合ポータルサイト → 関連資料

○テレワークモデル就業規則～作成の手引き～ [PDF]

国土交通省

●テレワーク推進フォーラム

○THE Telework GUIDEBOOK 企業の為のテレワーク導入・運用ガイドブック
　6章 テレワークに関する社内ルール作り [PDF]
　　図表6-2 テレワーク勤務に必要な社内ルールづくり検証項目チェックリスト

総務省

●テレワーク情報サイト → ガイドブック

○情報システム担当者のためのテレワーク導入手順書 [PDF]
　第4章 ルールの整備 2.労務管理

○在宅勤務ガイドライン [PDF]

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

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

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

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

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

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

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

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

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

テスラの自動運転の衝突事故は、実際には現在市販されている自動車に搭載されたautopilot機能で起きたものだ。
この機能は古くは、アクセルを足から離しても、同一の速度で走行を続けるアクセル調節だけのころ（レベル１）から、そう呼ばれていた機能だ。これには衝突回避機能などはなく、運転者が自分でアクセルを解除しなければならない。
そんなものが役に立つのかというと、アメリカのフリーウェイのようなところを長時間走行するときには、足でアクセルペダルを微妙な位置に調整し続けて、足が疲れるのを防ぐのに役立つ。
この事故では、衝突回避機能が付いている（レベル２）を「自動運転」と訳して報道された。
しかし、昨今、開発が進められている自動運転（レベル３）は、英語では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."」
とのことで、レーダーによる衝突回避は、頭上の道路標識に遮られて、やはり検知できなかったということが付け加えられた。

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

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

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

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

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

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

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

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

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

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

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

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

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は、データの利用がどのように反映されたかについて確認できるようにすることで、利用者が趣向を選択できるようにしてます。

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

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

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

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

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

ＩＰＡ：約6万文字を収録した新しいIPAフォント（検証版）の公開

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

議題１：政府ＣＩＯ制度のグランドデザイン（案）

政府全体のＩＴ投資の管理

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

想定スケジュール

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

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

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

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

議題３：新たなオンライン利用計画について（中間整理）の概要（案）

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

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

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

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

議題５：国民ＩＤ制度の実現による新たな電子行政サービスイメージ（ＮＴＴコミュニケーションズ株式会社提案）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

すると、先頭にＩＢＭがいて、それをマイクロソフトとＧＥが第２グループとして追従しており、続く第３グループが５千億～１兆円の間で、ひしめきあっている様子がうかがえる。

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

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

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

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

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

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

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

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

開発中止の記事いくつか

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

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

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

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

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

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

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

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

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

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

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

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

もともと、DPI は、IDS (Intrusion Detection System：侵入検出装置) メーカーがパケットのヘッダ部分（送信元ＩＰ＆ポート、送信先ＩＰ＆ポート）だけではなく、パケット本体の中味も検査するようになったときに、ヘッダ部分しか検査しない 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 という用語だけを使って、逃げ道を作られないようにしつつ、
逃げ道をふさぐ用語（たとえば、「パケット本体分析」など）に適切な条件を付けずに否定して、無用の反発を受けないように議論する必要がある。

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

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

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

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

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

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

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

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

おまけ・・・

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

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

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

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

ＩＴゼネコンの構造的破綻？

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

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

ｅ文書法解説完結

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

　その１：ｅ文書法特需はありません
　その２：ｅ文書法解説(前編)
　その３：ｅ文書法解説(後編１)

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

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

連載の最終回は

●＃４：文書の電子化に踏み切る前に、知っておきたい電子文書の特性

です。

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

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

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

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

ｅ文書法解説(後編１)

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

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

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

●＃３：スキャンした紙文書に改ざんはないといえる？

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

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

ｅ文書法解説(前編)

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

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

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

●＃１：誤解から生まれるe文書法の落とし穴
●＃２：e文書法は電子化のための金科玉条ではない

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

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

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

IPA のセキュアＯＳ関連報告書

いわゆるセキュアＯＳ関係について 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

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

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

http://www.hpworld.jp/2005/

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

AERA 2005年5月16日号

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

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

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

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

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

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

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

Webアクセシビリティ

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

まずは、ＪＩＳ規格から。

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

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

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

●「事業活動のIT化に係る規制の状況」（平成１７年４月版）
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

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

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

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

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

ＩＴ道徳教育

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

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

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

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

とあるらしい。

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

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

報道発表より転載：

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

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

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

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

をあげています。