私的システム作成事情

　あるお客様の「人事・給与システム」を作ったことがある。

システム名は「人事・給与」だが、中身は共通・採用・評価・昇格・昇給・研修・異動・退職 ・給与支給（含振込データ）・賞与支給（含振込データ）・臨時賞与支給（含振込データ）・年末調整・標準報酬月額変更 ・申告・保険・赴任・社宅・慶弔・災害補償・財形貯蓄・健康診断・社員名簿・制服・証明書発行・勤怠・通勤・出向・組織・規程・電話・車両 ・経理（伝票作成）の３２サブシステムからなっている。

「サブシステム」はいたるところで絡んでいる。

マイクロソフトの「ＡＣＣＥＳＳ」で作成し、最終オブジェクト数は５６００本を超えた。

知っている人に片っ端から声を掛け、教えを請い、使えそうなサンプルが載っている本はすぐに買い求めた。

インターネットで「ＡＣＣＥＳＳ」に関する「情報」「知恵」を検索した。

「システム設計者」「プログラマ」「データ切替責任者」「システムサポータ」全て兼務である。

　ここまでやるとシステムに「愛着」が沸いてくる。

「現状分析」から「本番」迄、お客様と二人三脚で作りあげてきた。

「即断」「即決」「即実行」の為「仕様書」という代物は一切作成していない。

「仕様書」を作成する間にシステムはもう出来上がっている。

そのうちに機能が変更されていく。

「分厚い仕様書」より「分かりやすいソース」が筆者の哲学である。

　過去、真面目に「仕様書」を見た事がない。

そもそも「他人の説明」「仕様書」は信じていない。

「ソース」こそが「真実」であると考えている。

「仕様書」の内容は「オブジェクトの説明欄」「コメント」「ヒント」「ヘルプ」等に記載し、表示画面とリンクしている。

紙の資料を調べる作業も過去の話。

「システム変更」のやりとりは、以下の３通りになった。

目の前で即、変更する

２時間待って貰って変更する（即検証）

大体の話を聞いて（詳細は聞かない）後日叩き台（動くシステム）を作成し詳細を詰める

「打合せ議事録」も「修正報告書」もない。

「言った」「言わない」の「やりとり」はしないことにしている。（飲み込めばいい）

毎月、システムが「機能アップ」している。

頼れるのは己一人という環境のわりには「ストレス」がない。

久々に作り上げた「達成感」に浸っている。

　夏季休暇を取った時の出来事である。

筆者は、出かける際にはパソコンを持参して「メールチェック」をしている。

某日、東京から遠く離れたホテルの一室で「メールチェック」をすると、お客様から「緊急修正要望」が届いていた。

このシステムには「修正要望登録メニュー」があり、実行すると自動的に筆者の「メールボックス」に届く仕掛けになっている。

メール受信後、パソコンから携帯電話経由「ダイアルアップ」してお客様の「ネットワークシステム」に入り、じかに修正していく。

　修正要望欄の隣には回答欄が用意されており、そこに結果を書き込み、終了である。

時間にして約一時間。

お客様からの「担当者はどこにいるのか？」「休みはいつ迄か？」なんて問い合わせは「過去の話」。

筆者の仕事の多くは「自前の環境」で事が足りてくる。

　こうなると、「出勤する意味がどこにあるのか？」という疑問が生じてくる。

通勤時間に要する往復３時間がとてももったいなく感じてくる。

個人宛の社内メールが筆者の私的メールボックスに自動的に届き、書類等の授受を週１回に決めれば、週１日出社は現実のものとなる。

決してふざけた話ではない。

　ただ、仲間と一杯引っ掛けないと帰宅できない「生活習慣病」の「御仁」には論外であろう。

これ以上言うと「不良社員」と言われかねない。

多くのやり方が変わっていく。

自ら作り上げた「常識」「開発方法」を自ら壊している。