正確な情報がパニックを抑えるのではない。フリーソフト開発秘話、目次へ
信用できる情報がパニックを抑えるのだ。
（逆にみなが信じれば嘘でも「パニック」は抑えられる。）東京電力は「正確な情報」と付け加えて伝えれば問題は起こらないと思っているのかもしれないが、全然信用に値しないので、少なくとも水の買占めは起こっている。それこそ東電の役員のご家族（お子様、お孫様たちも含めて）が、福島第一原子力発電所の横で魚を釣って食べているシーンでも写せば、今よりは多少信用してもらえるだろうに。
更に信用に値しないのが「計画停電」。首相をだまして導入したはいいが、誰それの選挙区では停電しないことになっている。公平性を確保するために、５つのグループを更に５つに分けてみたが、送電系統ではなく、県や市の単位で分けてしまったのでやっぱり停電しないところは停電しない。これで東電の言うことやることを信用しろというほうが無理である。節電担当大臣は何をやっているのだろう。夏には「昔取った杵柄」究極のクールビズ姿で登場してくれるのだろうか。国会議事堂でグラビア撮影をしたそうだから特に抵抗はなかろう。（個人的には見たいと思わんが、本人は期待されていると思っているのかな？）
ともかく日本人の「底力」で消費電力は劇的に下がり、当面の「計画停電」は回避される見込みだが、夏になるとこうはいくまい。本来は例えばオフィスの気温が２８度を超えると「労働安全衛生法」に基づき勤務停止、ということになるのだろうが、日本人は働いちゃうんだろうなあ。朝一番の輪番や夕刻の輪番ならば時差勤務をして乗り切れるとしても日中の順法は無理であったとしても、だ。
たまたまオフィスが東京都２３区内にあるので、結構のほほんとしていたが、若干心配になってきた。コンピューターセンターは自家発電装置を持っているとしても、オフィスのネットワーク機器は止まってしまう。メールが見れないのはがまんできる。問題は、ファイルサーバーにあるファイルにアクセスできないことである。紙と鉛筆でやれる仕事に注力すればよいが、それだけというのも辛い。では皆さん何をやるだろうか。
停電計画時間直前になると使いそうなファイルをごっそりローカルに持ってくる。
パソコン自体はノートなのでバッテリーで作業は出来る。
やばい、情報管理が形骸化する。でも「非常時だ！」と言われるとそれを止められないのだ。
で、多分、２３区外のオフィスではこの問題はすでに発生しているはずである。それこそKurdamnを使えば情報漏えいは防げるのだが、こいつには弱点がある。「共有ファイルの使用を前提としていない」。
つまり場合、同一ファイルに複数人の手が入って更新されるのを防げない。どうしてもこれが気になる。
つまり、誰かがあるファイルを使っている。後からそれを編集しようと開く。そのとき「そのファイルは使用中です。読み取り専用で開きますか？」なんて優しく聞いてくれるわけではない。後から誰かが上書きすればそれっきりだ。もっともこの問題は常に存在する。ただし輪番停電になると、この問題が激増するということだ。ライブラリアンの考えを利用すればよい。その手のプログラムなら作ったことがある。が、ライブラリアンとは違う部分が大きいのだ。
・区分データセットで作られたライブラリに比べ階層型ディレクトリは複雑。
・ユーザー数、利用回数とも比較にならんくらい多い。
・ネットワーク経由で借用・返却・閲覧される。
・ライブラリ管理担当なんてのは置かれないので自立的に動作する必要がある。Kurdammがいきなり葬りされたのがショックだったので、開発環境捨てちゃったからなあ。経験値も相当クリアされた。さて、どうしよう。
ただし今までと一つ違ったことがある。「絶対に必要とされる」という確信である。それこそ横浜や川崎にオフィスを構える皆さんは他人事ではなかろう。まあそれでも「今まで対策をとってませんでした」とは言いたくなかろうから問題の所在を認めたくはなかろうが、でも今なら言える。「問題点には気がつきましたが、東電のやり方が余りにも強引で対処の余裕がありませんでした。」当初は、ファイルサーバーに対してWebブラウザでアクセスしfileプロトコルでファイルをローカルに持ってくれば済むかなあ、なんてのんきに考えていた。知らず知らずのうちに「イントラネット」を使うと低コストで社内アプリが組めるという錯覚に毒されていたらしい。
クライアント＝サーバー間のプロセス間通信を使えば、出来るのはわかる。IPメッセンジャーレベルの通信でなんとかなる。
クライアント側にファイラー（MS-Windowsならエクスプローラーだ）置き換えソフトを作っておき、ファイル操作はそれでやる。カレントディレクトリを移動するたびにファイル情報をサーバーからもらってくるのだ。通常の情報に加え一つだけ必要なものがある。今このファイルが貸し出されているかどうかの情報だ。
ファイルサーバーには、クライアントのファイラーからのリクエストに応えて、該当ディレクトリのファイル情報一覧を送ってやればよい。借用の依頼が来れば、該当ファイルに借用中の情報を付加する。参照だけだとそのまま渡す。あ、そうそう、ファイルサーバーのファイルにはあらかじめ読み取り専用属性をつけとくのよ。クライアントのファイラーでその辺制御できればスマートなんだが、もともと読み取り専用にしたほうが「プログラミングが楽」である。
クライアントがファイルを編集のために借用するときは、直接ファイルをメモリにロードするのではなく、ローカルに持ってくる。でないと途中で停電になったときに「手動でローカルに保存する」ということになるから。できればラムディスクに持って来たいなあ。
で、クライアントのファイラーが終了するときに、借りてきたファイルをせっせとサーバー側に返して、ローカルからも消してゆく。起動時にはサーバー側の情報と同期を取る。仕様は作った。が開発環境がない。とりあえずクライアント／サーバー型の規模になるとテスト環境を持たない当方には作れない。しゃーない、MS-Excelのマクロでつくろか。
うーん。ファイルを返却するとき、タイムスタンプを比べないとまずいかなあ。
情報を更新する前に、別シートにバックアップを取って、後で比較、と。
結局、各ディレクトリに、ファイルサーバー側のMS-Excelワークシートを置いて、借用のときはそれを開く。返却のときはローカルに持った借用一覧から返すオペをやる、とこういう作りになった。もちろん、MS-Excelのマクロなんだから見てくれは悪すぎる。が、こうすれば出来る！人を説得するためには何かいるのだ。なにしろ僕の考えることは難しすぎて理解しにくい（らしい）。（自分では極めてシンプルな発想のつもりだし、順序だてて説明すると理解してもらえるのだが。）とりあえず完成したところで、東京電力は計画停電見送りの方針だそうだ。
やれやれこれでテンション下がるぞ。製品化すれば外販も狙えたのにな。実は次善の策を練っておいた。ファイルサーバー上のファイルのプロパティに一律で「ファイルサーバー格納分」と入れておくのだ。このプロパティはローカルに持ってきても消えないから、各クライアントに「該当プロパティを持つファイルがローカルディスクに見つかれば全部削除する」という働きをするサービスを常駐させ、シャットダウン時に走らせればよい。編集ファイルの二重更新防止、はできないが、不注意でローカルにファイルが残ることによる情報漏えい防止なら十分である。ついでに、ゴミ箱の中身でも消しておくかな。
これなら平時でも十分役立つソフトだと思う。開発環境を与えてくれれば２日でつくれる。えらそうな事を言った後で恐縮だが、当方、アプリケーションは作れるけどサービスは作れないので、そのやりかたを教えてもらえるという条件付ではあるが。