今だから話せる！今なら絶対にしないソフトウェアの仕様（１）
かれこれ10年以上ソフトウェア開発に携わっていますので、お客様には申し訳ないのですが、おかしな仕様で作ってしまった案件というものは・・・正直たくさんあります。
特に新人時代から少し経験を積んだ２年目、３年目でその傾向が顕著だったと思います。
中でも、今でも思い出せばお詫びして作り直させてください！と言いたくなるような失敗設計を今回１つご紹介したいと思います。
新しい事がしたいんです
少し経験を積むと陥りがちな落とし穴として、「使い古された方法ではなく目新しいモノを試したくなる」ものです。
それ自体は悪い事ではありません。
ただ、「何故使い古された方法が、今も使われ続けているのか」という点をキチンと押さえておく必要はあります。
若き日の僕は完全にこの部分を疎かにしていました。
テキストファイル最強説
当時、１秒毎に結果をアウトプットするという比較的シビアな案件を受け持っていました。
まだローカルデータベース等が簡単には展開出来ない時代です。
当初はAccessで作成していたのですが、レコード数が肥大化するとレスポンスが本当に使い物にならない位悪く、また最悪な事にファイルが壊れたりしたのです。
そこで白羽の矢が立ったのが、固定長のテキストファイルにデータを出力するというもの。
予想に反して一番レスポンスも良く、バイナリにもしなかったので、ファイル自体が壊れるというリスクも一番低かったのです。
これが今回のお題でいう所の「使い古された方法」にあたります。
何かスマートな方法はないものか
テキストファイル最強説が脚光を浴びた状況下で、何かもっとスマートで今まで行ってこなかった新しい方法はないものか、と密かに考えておりました。
そこに３人月程度の比較的容易な改修案件の設計を任されました。
おお、これは渡りに船だと言わんばかりに、「スマートな方法で新しい方法を確立して見せるぜ！」と張り切っておりました。
画期的なのか阿呆なのか
求められる仕様としては単純でした。
Aという機械の進捗情報を随時Bで確認するだけ。
機械A（複数台）で数分毎に１本製品が出来るので、その情報を加算して機械B（複数台）に送るというだけです。
今ならば、こういう仕様にすると思います。
- 機械Aそれぞれに識別Noを持たせる
- 製品が１本出来れば識別No毎のテーブル（またはテキストファイル）に加算する
- 機械Bは保存されている機械Aの情報を取得し、画面に表示する
はい、至ってなんて事のないシンプルな内容です。
なのに、当時の僕は何を思ってか下記の仕様を考え実装してしまいました。
ちなみにUDP通信にしたのは、TCPと違い片方向通信の為レスポンス待ちのタイムラグを無くす為というなかなかな発想の元に採用されました。
これならば、何もわざわざ毎回ファイルアクセスのI/Oも発生しないし、リアルタイムで通知出来るから進捗表示も精度が上がるよね！と意気揚々でした。
外部の変化に弱かった
当然ですが、動作はキチンと動くものに仕上げていざ本番環境へ導入という段階になりました。
事前検証もしていたのですが、一つ抜けていた点がありました。
それはファイヤーウォールの監視規制が強化され、UDPの制限が行われていたという事。
結果は当然ながら動きませんでした。
UDPポリシーの変更に関する情報が当初伝わっていなかったという事もあって、原因を突き止めるまでには時間がかかってしまいました。
結果、結構な大目玉を食らう羽目に。。。
新しい事をするということは、過去の経験が無いのでトラブル時には非常に困るというのをつくづく痛感した出来事でした。
使い古された方法には、トラブルに対する対処法も色々と用意されているんだという事です。
振り返って
今ならばUDPでデータの送受信をするようなリスキーなやり取りはしません。
斬新さに走り、使い古しの方法を格好悪いと認識してしまったのが最大の敗因でした。
周りの誰かも止めてよ・・・という愚痴は当時こぼしましたが。
失敗は成長する上での良薬です。
若いうちに手痛い失敗はたくさんするべきだというのが持論ではあるのですが、やはり失敗はしたくないものです。
久しぶりに己を見つめなおすために過去の失敗を振り返った訳ですが、恥ずかしいったらありゃしない。。。
あまり中身の無い内容でしたが、最後までご覧頂きありがとうございました。