僕が開発したソフトウエア（以下、A）は工場製造実行系のソフトウェアで、我が社の製造の大部分を担っています。
僕が以前のソフトウェア会社に勤めていた時に開発したものです。
「就職先が決まりました」参照
Aが出す計画やスケジュールに従い
数百人の作業者が作業を行いAに作業実績を入力していきます。
Aで取り貯めたデータを使って日々の分析が行われ
業務の結構な部分にお役に立てていると自負しております。
これまで、自分が納品したソフトがどのように使われているのか
身近で見る機会はほとんどありませんでした。
出張時に少し工場見学させてもらう程度。
今は僕のすぐそばで動いてくれています。
こわいですね。
そのお話しをちょっとさせて下さい。
僕の開発したソフトAとは
製造実行制御(MES:Manufacturing Execution System)の簡易版だと考えて下さい。
丁度、7年前でしょうか。
先代のプロジェクトリーダーから、
このお客さんを引き継いで完成しているソフトの出来の悪さに唖然。
5年ほど前に全部作り直して今に至ります。
僕がプログラマー7年生の時に作ったシステムです。
僕をリーダーに6人のメンバーで仕上げました。
ざっくり言えば、計画立てて実績とって集計する仕組みです。
上位のERPなどから生産指示(どの製品をいつまでに何台つくるか)をもらい
納期に間に合う範囲でスケジュールの最適化を行い、
ストップウォッチのような機能で計測します。
他にも多少の設備制御や在庫管理も行います。
それまでは巨大な機械の制御をやっていたので、
常に人の命が関わってくる仕事でした。
+と-を間違えた不具合や
long(4byte)とshort(2byte)とサイズやunsignedの付け忘れが命取り。
機械が大暴走して、腕を失ったり死んだり。
僕の開発は（放送禁止）系、自動車系、精密機械系とジャンルは様々ですが
機械に載せるソフトウェアでメーカーに売るソフトが中心でした。
つまんないし、危険だし、ユーザーのフィードバックもありません。
それが、Aの仕事はエンドユーザー向けです。
ユーザーの評価が直に聞けるし、人も死にませんしケガもしません。
引き継いだ直後はすったもんだありましたが、ある程度落ち着いた頃には
「チョロ過ぎね？こんなんでカネもらえんの？もう勝ったね。」
と、考えていましたのです。
まぁ、Aはそんなソフトウェアです。
全部で30程度のサブシステムから成り立ち
2層3層混在のデータベースを利用したクラサバ型システムです。
消し去りたい過去の恥
①データベースのカラム名の綴り間違い
②適当につけた名前
③やっつけで作ったソフト
④プログラム中の残念なコメント
⑤センス皆無のUI
⑥ふざけてつくった裏技
⑦使ってほしくない自信の無い機能
⑧不具合を機能として使っている
①データベースのカラム名の綴り間違い
僕はデータベースのテーブルカラム名を英語で付けています。
恥ずかしながらいくつか綴りを間違えてしまいました。
もちろん中学生レベルの英語です。
代表的なものではスタッフ。
〇Staff→スタッフ、職員、部員、社員
×Stuff→材料、原料、資料、くず、がらくた、ゴミ
不幸ですね。見る度に心が咎めます。
まぁ、僕が作ったところだけなら恥で済むのですが
社内報告資料や他の仕組みのテーブル名にも間違いが継承されているという・・・ね。
②適当につけた名前
何かとソフトウェアは名前をつけなければなりません。
アプリケーションの名前。
クラスの名前。
変数の名前。
関数やメソッドの名前。
UI上のエリアやボタン、項目の名前。
日本語で丁度良い言葉が無い場合に適当につけます。
特にシステム上必要な例えば「ID」や「区分」等。
まぁ、かなり適当です。
例えば、当初エクセルのシートをベースにした「シート区分」とか
言葉だけが独り歩きしてシートが何のことかわかりません。
しかも紆余曲折を経て、現在本家もエクセルを使用していません。
その「シート区分」が社内で普通に浸透しているのです。
何の罰ゲームか。
③やっつけで作ったソフト
開発している最中に「あったら便利だよなぁ」と思うものが、ままあります。
デバッグで使えたりするので、大小ありますが簡単なものなら1時間程で作ります。
当然、ドキュメントなんて残しませんし、納品物ではないので色々適当です。
ただ、ピンポイントで狙った事ができるので、結構便利。
当時、現地デバッグの際に使っていたら、
お客さんの眼にとまり、そのままあげたものがいくつか存在します。
喜んでもらえたりしたら調子に乗って機能拡張したりします。
案外自由につくれるので楽しいんですよね。
何だかんだで機能モリモリになったおまけアプリが10はあります（もっとかも）。
中には納品物より力が入っているものもあります。
しかし、超限定仕様なので、
プロジェクトが終わると僕は使わなくなり記憶からは完全に消え去ります。
当然、転職時は全く覚えてませんでした。
入社して間の当たりにしたのは古い記憶で微かに見覚えのあるUI。
僕「これ、そういえば作りましたね。まだ使ってたんですか？」
相手「かなり重宝してますよ。これが無くなったら仕事になりません。」
僕「それは何よりです。」
相手「そうそう、そう言えばちょこっと変更して欲しいところがあるんですよね。」
や・ぶ・へ・び
そのアプリケーションの名は「SampleApp」
④プログラム中の残念なコメント
他社の人間だった時は、全く入ってこなかったトラブルが毎日上がってきます。
本気でヤバいやつも月１位あって、冷や汗かきながら応急処置です。
当然ですが短時間での対処が求められます。
ホント、僕がいなかった時はどうしていたのでしょうか。
不具合個所に当たりをつけていざ修正。
開いたソースコードはかなり巨大なスパゲティソース。
しかも問題個所にあるコメントが言い訳。
パターン①
// ここをコメントアウトすると何故か動く
パターン②
// TODO:XXXXX機能が未実装
パターン③
// ここは通らないハズ
察してください。
⑤センス皆無のUI
背景をバリバリのグラデーションにしてしまいました。
センスの無い相性の悪い2色のグラデーション。
目に染みる。
少し落ち着いてはきましたが昨今フラットデザインが
僕のUIのダサさに拍車をかけます。
なんかダサい。
兎に角ダサい。
本当にダサい。
余談ですが、操作性もクソです。
適当に配置したボタンにイライラします。
ボタンにフォーカスした時、
アニメーションが加えられてふわっとなるのですが苛立ちを増長します。
頑張るところが違う。
⑥ふざけてつくった裏技
デバッグ用で仕込んだ機能を
作業者が普通に使っているのでビビります。
デバッグ用ですのでデータの整合性を保つとかそういうことは考えていません。
また、
僕「「Ctrl + Alt + 右ダブルクリックで発動」とか、絶対バレないっしょ？」
メンバーA「後、F1も入れてみたらどうっすか？」
メンバーB「そこは、あまり人気の無いF8でしょ？」
僕「いやいや、さすがに押せなくね？まぁ、リリース時は消すから良いっしょ。（笑）」
と、当時内輪で盛り上がった機能なのですが、消すの忘れてリリースしてました。
現在、普通に使われています。
言わずもがな。
隠しているのですからそこそこ危険な機能です。
やはり、F8も組み込むべきだったか。
⑦使ってほしくない自信の無い機能
あまり使ってほしくない機能が、たまにあります。
「そんなものリリースするな」は、ごもっともです。
しかし別に手を抜いたわけではありません。
「時間の都合でテストが甘いと感じている機能」
「かなり複雑なケースで発生するバグを内在する機能」
などです。
前者は運用に耐えているので、おそらく大丈夫でしょう。
しかし後者はバグを確認しているだけに恐怖です。
うっかり発覚して直してくれと言われたら・・・。
直せなかった苦い記憶だけ残っているので最悪です。
そういう機能に限って荒い使い方をするのは何故でしょうか。
神はいないのか。
⑧不具合を機能として使っている
意図していない動きがユーザーにとって都合の良い結果になる場合、
不具合を直してはいけないのです。
ユーザーは多少違和感があっても都合が良いので、そういうものだと思って使います。
しかし開発者から見たら「得体のしれない動き」をしているのです。
何となく原因が想像がつくのですが、問題は得体のしれない動きの後。
例えば問題のあるデータ発生後、そのデータを使っての動きは想像がつきません。
できれば使用を中止させたいのですが、それは不可能です。
せめて不具合の動作をテストしたい。
何を言っているのか良く分かりません。
まとめ
長々と書いてしまいましたが、
何より問題なのは5年前につくった自分のソフトが、社内の大部分で現役稼働していることです。
そんなものに会社と人生を預ける僕。こっわ。
皆さん保守性の高いソフトウェアを開発していますか？
おわり
コメントを残す