何度も書くようにここでは筆者個人の転職経験を相当な脚色とともに記述しているが、決して模範例として提示しているわけではない。それだけは忘れぬようにしつつお読み頂きたい。今回は新卒で最初に就職した電機メーカーからの転職をなぜ思い立ったのかについてである。

前回のエッセーで触れたように学生時代に就職活動で売りにできる専門的な知識やスキルを持たなかった僕は、入社してから経理マンとしての経験をつむことになる。

就職活動中の簿記会計の勉強は経理業務に対するアレルギー反応をなくす意味でも非常に役立ったし、実務を経験するにつれて経済学全般に対する興味も強くなってきた。その結果MIT教授のポール・クルーグマンや米国の一般会計原則の学習などにも手を出すようになった。

しかしこの企業の某工場で経理部員として仕事をするうちに、僕は自分が持っている趣味程度にすぎないパソコンの技術が意外にも実務の効率化に役立つことを発見する。

たとえば経理部のオフィス・コンピュータには昔の経理部員が日曜プログラマーよろしく開発した、お手製の損益集計プログラムが存在した。OSはCP/M、言語はBASICである。僕は業務の空き時間にこのプログラムをマイクロソフトのAccess（当時はまだバージョン1.1）に移植してしまった。

在学時に僕は研究室で、EPSONのNEC9800互換機で稼働するカード型データベースを使って卒業生の名簿を管理する手伝いをしていたが、関係データベースというものをまったく知らなかった。MS-Access1.1をマニュアルを読みながらいじくっているうちに、少しずつ関係データベースというものの考え方や「正規化」の手順を習得していった。

そうして旧式のオフコンで動いていた損益集計プログラムを、パソコンベースのAccessに移植したところ、工場全体の損益集計表を印字する業務が、丸一日かかっていたものがたった十数分で完了するようになったのだ。

ここまで劇的な効率化の効果が出たのには、とてもつまらない理由がある。CP/M上のプログラムはオフコンに直結されていたドットインパクト・プリンターでしか印字できなかったのだが、このプリンターが旧式で数枚印刷するごとに必ずビープ音をあげて停止していたのだ。

損益管理担当者はそのたびにプリンタのふたを開け、つまった用紙を除去し、再度印刷指令をかける。損益集計表を印刷するだけで日が暮れるわけである。大企業といえども業務効率化の支障になっているのは、こんなつまらない事実だったりすることもあるわけだ。

パソコン上のAccessへ移植したことによって、当時最新のEPSON製レーザープリンターを使えるようになった。Accessの印刷ボタンをクリックすれば用紙切れがないかぎり十数分で印刷は完了した。その資料は工場内の各製品の製造責任者に前月の損益実績を報告するものだったので、いくぶんか意思決定が迅速化されたかもしれない。

このように趣味程度のパソコンの技術が、経理部の実務で確実に効率化の効果をあげ、部長にも認めてもらえた。社会に出たばかりの僕が得意になるのも無理はないわけで、その後もOracleのインストール、SQL、PL/SQLを独学して部門サーバにOracle Workgroup Server 7.3を導入し、ホストコンピュータからの部門別経費実績データをロード、Excelへ展開して管理帳票を完全自動作成するプログラムを開発するなど、単純作業の効率化を実現していった。

製造業は生産現場だけでなく経理部のような間接部門でも作業効率化によって付加価値を生む仕事に使える時間をつくりだそうという意識が非常に強い。当時の僕は製造業に限らず、どんな企業でもホワイトカラーの業務効率化の意識は強いのが当然だと思っていたが、実は業種によって大きな温度差があるということを知ったのは数年後になってからだ。

損益集計プログラムのAccessへの移植につづいて、僕はHTMLとCGIを独学し、他部門への啓蒙のために原価管理に必要な用語集を全文検索機能つきでイントラネットに公開した。全文検索を実現するためのCGIプログラムはVisual C++をつかってコマンドライン・プログラムとして開発し、Webサーバには当時企業向けで主流だったNetscape Enterprise Serverを利用した。まだマイクロソフトのActive Server Pageなど、サーバサイド・スクリプト技術が存在しなかった時代の話だ。

また、部内のネットワークをIPX/SPXベースのNetWareネットワークからTCP/IPベースのWindowsネットワークへ移行する作業を、情報システム部門の支援をうけながら作業した。経理部内の40台のパソコンにWindows 95をインストールする作業も休日出勤で一人でおこなった。そうした作業を通じてWindowsネットワークとTCP/IPの技術を習得することができた。TCP/IPについては市販の技術書で基礎理論を補強した。

さらにたまたま工場内でロータス・ノーツが展開されたため、経理部側の窓口として部門にノーツサーバを構築する手伝いをすることでノーツの知識も得た。

入社当時は単なる趣味程度の知識だったものが、じっさいの業務に適用して評価されることで強い動機づけが生まれ、独学や情報システム部門の専門家との共同作業を通じて実務レベルのスキルにまで高めることができた。欲が出てきた僕は、工場内の情報システム部門に異動を申請し、ついに工場全体の情報システムの企画業務に関われるようになった。

「ついに」と書いたのは、同社で情報システム部に配属されるのは原則として理系出身者だけであり、僕のように純然たる文系採用がシステム部門の専任になることは非常にまれだったためだ。

情報システム部門では主にノーツの運用・管理をおこなっていたが、当時その工場の属する事業本部が業績悪化の時期にあり、システム化投資が特定の分野に絞り込まれた。そのためせっかく要員として任命された大規模システムの開発プロジェクトが中断の憂き目にあい、僕としてはかなり士気が下がってしまった。

今から考えれば企業としてはまっとうな経営判断だったわけだが、初めて経験する基幹業務システムの構築ということでやる気になっていたところへ、出鼻をくじかれた格好になった。

さらに同工場で客観的にみて明らかに非合理的なシステム化案件が全社方針ということで無理に推進されるということがあった。この件についてはその後さまざまなIT業界関係者に僕の意見の正しさを確認してきたが、当時のこの会社の方針は明らかに間違いだったと断言できる。

しかし一方で、僕がさまざまなスキルを身につけたことでかえってその会社の情報化戦略の欠点を必要以上に重大な問題ととらえてしまった面もある。無謬の企業などそもそも存在しないわけで、重要なのはその間違いをできるだけ早期に修正し、そこから何を学ぶかであるかもしれないからだ。

そうしたことから僕はひとつの企業の情報システム部門で利用者としての立場で仕事をすることに不満を抱きはじめ、情報システムを構築する側の方が展望のある仕事ができるのではないかと考えた。そしてその会社を去り、ベンダー側の企業である某コンピュータメーカに転職することに決めた。

いまふりかえると僕は自分のスキルが実務で評価されたことに有頂天になっていたようだ。いわば僕の中で「プチバブル」が発生していたのだ。そのプチバブルは次の勤務先で見事にはじけることになる。