職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している(いた)組織の意見ではない。

業務システム刷新

先日、会社の業務システムを刷新してきました。
書けること書けないこと色々ありますが、書けることだけかいつまんで、概要だけ紹介したいと思います。
もちろん、後年、自分自身で振り返ったときのためのメモでもあります。

形態と規模

一般的なLAMP(Linux / Apache / MySQL / PHP)によるWebアプリケーションです。
近年ではWebをやるにしても新しい技術が色々と流行っていて、どうやって作るか悩ましいところでもありますが、後任の技術者の見つけ易さを考えるとやはりLAMPかなーということで、このようにしました。

システムの規模は、画面数にして200弱、Ajaxの動作のためのものも画面として数えると200を少し超えるくらいです。あとはストアド・プロシージャがいくつか。

ユーザ規模は、毎日つきっきりで使うヘビーユーザが10人程度、数日に1回使う程度のユーザが5人程度、数週間に1回使う程度のユーザが数千人程度、という構成です。
普通のハードウェアで、「普通」のソフトウェア設計をしていれば、Apacheの負荷分散とかMySQLの負荷分散とかを特に考えなくても十分高速に動作させることができます。

開発体制

開発は2名+デザイナ1名で行いました。
僕は仕様をほぼ全て決めるのと、難しめのところを本気で開発していく役割。
もう1人の開発者は、比較的簡単な部分を超高速で大量生産していく役割。

2人でやるときは、やはりこういう役割分担が最適だな、と思っています。

僕自身は基本的にC言語Objective-CJavaAsteria の人間であってPHP歴は1年と少し(商業的な経験はほぼ初めて)程度です。もう1人は基本的にはMicrosoft系言語(VBだったはず)の人間。
PHPにやや不安はありましたが、特に問題にはなりませんでした。基本的なコンピュータ科学の知識やApacheそのものの話、そしてHTTPそのものの知識があれば、PHPはやっぱりカンタン且つ超便利です。

デザイナの役割はロゴマークの作成やサイト全体の色とかの調整、僕が書いたCSSの校正(検閲かも?笑)、あたりです。IA(Information Architect)的な立場からのアドバイスも少し頂いたり。

刷新に至った経緯

なぜ業務システムを刷新するに至ったか、という理由はいくつかありますが、全て「旧システムがダメダメだった」というものに集約されます。
ヘビーユーザや会社の経営陣達からはいろんな要望を頂いていましたが、それを実現するためには旧システムは基盤として十分ではなかったのです。

旧システムの問題点は挙げればキリが無いですし、もちろん一部には開示できない情報もありますが、代表的なのは以下のようなものです。

MySQLのDBのアーキテクチャ

業務システムと言えば通常は MVCC(MultiVersion Concurrency Control:多版型同時実行制御。要はトランザクション制御)の機能を利用するので、MySQLであれば InnoDB を利用するべきところですが、なんと旧システムでは MyISAM を利用していたのです。
ということは、ヘビーユーザAさんとヘビーユーザBさんが、同じデータを同時に編集するときは(その機能の編集対象が複数テーブルや複数行に及ぶ時は特に)、データの不整合が発生し得た、ということになります。恐ろしい…。
システムを刷新することなく InnoDB に変更することも可能と言えば可能なのですが、MyISAM でしか使えない機能を利用していないか?の調査を旧システム全体に渡って進めるのは、時間がかかる割に得られるメリットの低い作業なので、忌避しました。もちろん、InnoDBに変更するだけでは MVCC の恩恵にあずかることはできませんので、この件はシステム全体を一から作り直すという判断の大きな後押しとなりました。

ちなみに、MyISAMは「マイアイサム」と読みます。日本に居た頃は「マイイザム」と読んでました。ぐぬぬ。

DB上の金額のカラムが浮動小数点型

どうしようもない欠陥です。
これに気付いたときは、僕は機嫌を損ねて周囲に当たり散らしたものです。
各種処理の都合上、発生し得る誤差は高々2セント程度(今は1豪ドル=101円くらいなので、せいぜい2円くらいの誤差)ですが、業務システムでこれは良くない。。
これも先ほどのMyISAMの件と同様に、刷新させることなく修正することは可能ではあるのですが、やはり一から作り直すのが賢明です。

正規化されていないテーブルの数々

正規化し過ぎることは、テーブルの数を増加させ、DB処理のパフォーマンスを下げ、SQLを書きづらくする可能性をはらむので、敢て正規化しないという選択をすることもあります。
しかし、「理解した上で正規化しない」ことと「正規化という作業を知らないから正規化しない」こととは全く別のことなのです。
流石に第一正規形ですらないテーブルは存在しませんでした(そのように作る方が技術力を要するため)が、問題を多く抱えたテーブル構成が出来上がっていました。
システムの根幹部分に抱え込まれてしまったこの問題を解決する方策は、やはり「システムを一から作り直す」の一択です。

拙い英語

エラーメッセージやソースコードのコメントに書かれた英語が酷過ぎるのです。
日本人にありがちな、「意味は通じるけど一般的な言い方ではない英語」というものではなく、そもそも意味もよくわからない、間違えた英語が沢山あったのです。
このメッセージを書いた人が、豪州で日常生活を送ることができてるのかどうか心配になってくるレベルです。僕も言ってしまえば英語は片言レベルですが、それよりも酷い。

もう旧システムを見るのも嫌になっていました。

Redirect

通常のWebアプリでは、HTTP Post によってブラウザからサーバへデータを送出した際、サーバは処理をした後、 HTTP 303 をブラウザに返し、リダイレクトさせます。
ユーザは送出させた結果の画面を見ることになりますが、ここでF5を押してリロードしても、データは再送出されないようにする訳です。
ところが、この旧システムはこの仕組みを上手く利用できておらず、F5を押すとデータが再登録されるという問題を抱えていました。恐ろしい。。



ああ、愚痴だらけになってしまった…

開発期間

就職して、旧システムを担当するようになって、上記に掲げたような問題点に色々気付き始めた2012年11月頃に「システム、1から作り直したいなー」という「妄想」が立ち上がり、12月には「妄想」が「構想」に変わりました。
年末には習作とも呼べる、別の業務システムを同じアーキテクチャ(LAMP)で新規に開発し始め、2013年1月中旬に本番稼働開始させました。こいつの画面数は20くらい。
こうやって必要な技術検証をこなした上で、1月下旬から本格的に今回のシステムを作り始めました。

一部のヘビーユーザ向けにβ版を提供したのが3月末。約5週間のテスト期間を経て、先週本番稼働開始を迎えることができました。

安定稼働

業務システムを刷新した直後は、責任者はたいてい22時以降まで残業して監視や障害の原因調査にあたるものですが、今回は稼働開始してから1週間、僕が19時以降まで残業することはありませんでした。先日の金曜日だけは20時までオフィス居ましたが、これはシステムの安定度合いとは無関係な用事があったためです。

システムの責任者が毎日19時までに帰宅している。このたった一つの事実よりも的確に、システムの安定度を客観的に示す指標は存在するでしょうか?

バグが全く無かった訳ではありませんが、ほぼ全てのバグはユーザからの報告のあと10分から20分程度で修正し、本番リリースしてきました。
かなり好調な滑り出しであることは間違いありません。

今後の展望

駆け足で本番稼働を迎えてしまったので、実は「あまり使われていない機能」を新システムには載せていないのです(笑)
今後はこいつらを実装して提供していくことになります。
もうしばらく頑張ります。