確定拠出年金というもの、要するに会社が年金運用をやめちゃって「あとは個人が自己責任で運用してね」と言っているらしい。
各人が運用指図をしなければならないということで、はっきり言って大変である。でも極力前向きに取り組むことにした。まあぶっちゃけた話「会社の年金基金運用部門が（リスクをとるのがいやだから）その仕事を各個人に振った」ということであるから、自分の確定拠出年金を運用するというのは「業務」であると言えるわけだ。おお、経済情勢を展望しての資産運用って、私が会社にはいるときやりたかったことじゃないか。これが業務で（つまり勤務時間中に堂々と）できるぞ。やっと証券アナリスト検定会員の資格が生きてくる。ただ悪いことに、私は「運用」というよりも「経済動向分析（あるいは産業動向分析）」の方がしたかったので、「調査」に時間をかけるかもしれない。しかしその辺は裁量の範囲内だろう。運用額が少ない（つまりポートフォリオらしいポートフォリオが組めない）というのは不満だが、やっと入社時の希望が叶った。かくして堂々と「業務」を始めることにした。しかし年金基金運用というと普通は複数人の担当者がフルタイムで行う仕事である。これを各自が個々バラバラに業務としてやるのは・・・ものすごい生産性の低下につながらないのだろうか。もちろんつながる。確定拠出年金やるゾー、と言ったところはこの生産性低下を本当に容認しているのだろうか。
確定拠出年金は極端な例だが、仕事を分散させるというのは、その分生産性を低下させる。これは当たり前の事実である。古典的なものでは「専用の電話交換手を省き、ダイヤルインにする」。もちろんかかってくる電話が自分宛とは限らないから、他人の電話の応対で仕事を中断することになり、またフロアをうろうろすることになる。セールス電話の場合撃退する必要すらある。
トム＝デマルコなら怒り狂うだろう。彼の説によるとエンジニアは自分宛の電話さえいやがるのだから、他人宛のセールス電話なんぞ受けさせられた日には。閑話休題。今回はソフトウェアが当然にサポートする機能をユーザー任せにしてしまったので、任された私が苦労した話。
Webベースでちょっとした情報を参照する一種のイントラネットシステムのパッケージの説明会に参加した。既存のIPネットワークがあれば導入できます、というホントにまあ、ちょっとしたもの。でも一応アクセス制限のためにユーザーIDとパスワードを使う。よくあるイントラネットの情報システムの形式である。
期待はしていなかったが詳しい話を聞くと、あまりにタコな実装！ログアウトせずにWebブラウザを、例えば[×]ボタンで落とすとセッションが張られたままになり、タイムアウトするまで再度使用不可。ユーザーIDとパスワードでアクセス制限をかけているにも拘わらず、サーバー側でアクセスログはとらない。極めつけは「ユーザーIDは１ライセンス毎に結構なお金をいただきます。複数人で使用することもできますが。管理方法はお客様の方で考えてください。」
要するにユーザーIDを沢山買ってくれということ。ユーザーIDを共有するのは不可能ではないですが、そうできないように嫌がらせをしていますよ、ということ。パッケージにその機能がないならプロキシーサーバー立てりゃなんとかなるだろうと思ったが、考えたこともないらしい。（しかしアクセスログがとれないとは、Webサーバの基本機能ではないか。わざわざ自前で作ったのか？）
私の怒りは「ユーザーが想定外の使用（しかもブラウザを落とすというごくごくありふれた動作）をすると、タイムアウトでしか収拾できないとは、どういう手抜きだ！」「アクセス制限をかけたつもりでアクセスログもとれないとは、いったいセキュリティをなんだと思っているんだ！」というものだが、多分きっちりと教育されていないシステム開発者はそんなこと言ってもわかりゃしないだろうなあ。仕方ない、俺が教育してやろう。ユーザーをシステム側の都合（もっというと自分のプログラミングの腕）に合わさせるのではなく、システムをユーザーの使い勝手に合わせるということがどういうことか教えてやろう。てめーはその辺で黙って見学していろ、である。
ついでに言うと、姑息な手段でユーザーIDのライセンスで儲けようったってそうはいきません、ということを証明してやるということ。が、怒り狂っても、なかなか良いアイディアが出ない。まずは、複数人でユーザーIDを使い回す仕組みを作らなくてはならない。これがサーバーの管理者IDであれば、作業する日時は予め分かるし、それなりの体制もとるし、ということで、作業届と連動してIDを貸し出し、パスワードは都度変更する、というやり方もとれる。しかし、このパッケージが対象とするものは「あれ、どうなってたっけ？」と思いついて、その場でさっさと確認する、そういったものだ。従って貸し出し・返却が都度リアルタイムにできないと使い勝手が悪すぎる。
となると、本の貸し出しのように借用簿を作って、ということを考えるものだがこれにも問題がある。本は現物を借りるためには、必ず現物のところに行かなければならないが、ユーザーIDの現物を持ってくることは不可能である。借用の手続きをとらずとも覚えていれば、その場でイントラネット端末でささっと打ち込める。まあ、貸出／返却の都度パスワードを変更すれば否応なく借用に来るのだろうが、そんなことすると一日中パスワードを変更する羽目になる。運用を考えると現実的ではない。最低でも「座ったままユーザーIDを借用できる」程度の仕組みは必要だろう。いろいろと考えてはみた。IPネットワーク上のインスタントメッセンジャーを使うとか、Webサーバを自前で立ててプロキシサーバにするとか。でも気軽に使ってもらうには制限が多すぎる、これでは使ってもらえない。「使いなさい」と通達を出しても、とても使う気になれないものならそれは提供した方が悪い。
途方に暮れながらWebをウロウロしていると、ん、VBAでブラウザって作れるのね。（正確にはIEのコンポーネントをVBAから呼び出せると説明すればよいのだろうか。）
・・・天才とは努力する才能である。努力する才能は、努力が報わるという幸運によって育てられる。。。まーず、ネットワーク上の共有フォルダに借用簿のMS-Excelファイルを置こう。ユーザーIDを借用すると自動的にWebブラウザが立ち上がり、返却するとWebブラウザが落ちるようにしよう。何時に誰が借用したかは自動でMS-Excelワークシートに記入される。これでログがとれる。更に誰かがユーザーIDを借用中だとMS-Excelファイルが編集中ということで、新たに借用しようとしても排他制御がかかりメッセージ通知される。
当初は借用の時点でパスワードを通知しようとしたが、これは明らかなセキュリティホール。まあいいかな（当初の仕様に比べるとずいぶんましになったし・・・）と思いつつも、おー1997年に当社初のイントラネットシステムを手作りした経験が生きる。どうせユーザーID、パスワードの入力はCGIを使っているに違いない、とするとURLにそいつを自動で打ち込むようにすれば（そしてVBAで作るブラウザにURL表示欄をつけなければ）ユーザーにパスワードを意識させることなくアクセスができる。意識させないと言うことが大事である。
当初は、パッケージソフトで提供されているのとは別に使用者ごとにユーザーID、パスワードを用意して入力させないとセキュリティ上まずいかな、という気はしていたのだ。しかし、意識させないとすればその必要はなくなる。つまり「シングルサインオン」と言い張ることができるのだ。少なくとも共有ディレクトリにアクセスできるということは、ユーザーが各自のユーザーID、パスワードでログインしたということ、それ以上のアクセス制限がなくとも問題はない。問題があるとすれば別にシングルサインオンを採用しているシステムも問題があるということ。おお、一挙に楽になった。この借用簿、不本意ながらVBAで作らなければならない。しかしVBAで作るメリットもある。普通のプログラミング言語だと「プログラム書きました。社内システムに乗っけてください」と言うとセキュリティがどーたらと難色を示される可能性が高い。しかし「MS-Excelのシートを共有フォルダに入れます。業務効率化のためにマクロも活用しました」と言うと正面切って文句を言われることはなさそうだ。
ついでに言うと、VBAのフォームは大きさ固定にしかできないようだ。不便だが逆転の発想をしてみた。つまりフォームの幅を画面より大きくするのだ。するとこんな効果がある。右上の[×]ボタンが画面からはみ出るため、間違っても押せなくなるのである。まあこれは画面サイズが規格化されているイントラネットだからできる技だけども。
- 導入の論旨はこんな感じになる。
- ユーザーIDの借用・返却管理をMS-Excelのワークシートで行う。
- アクセスが容易なようにMS-Excelのファイルは共有フォルダに置く。
- ワークシートの入力省力化。改竄防止のために、入力フォームをVBAで提供する。
- 入力フォームからWebブラウザを起動可能とし、パスワードはシングルサインオンのシステムに倣い自動入力とし、ユーザーに意識させない。
- Webブラウザ終了時に自動でユーザーID返却の旨をワークシートに書き込ませる。
ともかく殆ど、というか全部の問題が解決してしまうことに気がついた。たいしたものだ。せめて表彰してくれ。
でもだめだろうなあ。表彰するということはシステムに欠陥があることを認めたということ。あー、あほらし。まあ、製造元には思いっきり威張り散らしてやろう。ところで私を怒らせたこと、御社は何回目？