全データを読み、1件ごとにマスタを何十回も読む。そんな処理でも、AS/400は約30分で完走しました。 速くて丈夫なプラットフォームだったからこそ、データアクセスのまずさが「こういうもの」として隠れてしまったのです。
01 / DISCOVERY
30分への違和感は、
雑談から見つかった。
対象は「条件追加機能」。約4億件のレコードに複雑な業務ロジックを通し、条件に合致した場合に 新しいレコードを発生させる処理です。現場から検査本部長を経由して要請書を受け取り、 私が部下へ実装を任せました。
処理には約30分かかっていました。けれど現場では、複雑な処理だからそんなものなのだろうと、 繰り返し実行されていたのです。
問題を見つけたきっかけは、正式な障害報告ではありません。検体受付部門のリーダーだった市坂さんとの雑談でした。 私が作ったアプリにしては異様に遅い——そう感じた市坂さんが、何気なく相談してくれたのです。
02 / RESPONSIBILITY
これは、私の責任です。
実装した部下だけの問題ではありません。コードレビューが不十分で、実行結果を処理時間まで確認できていなかった。 開発を任せた私の責任です。
要請書どおりにできているかを開発側で検証し、リリース後には現場が本番データで確かめる工程も、もともとありました。 それでも、処理時間が明示的な確認項目になっていなかったため、機能が正しく動くことだけで通ってしまいました。
以後は、現場側の確認条件にも処理時間を加えました。高速化したこと以上に大切なのは、 なぜ遅いまま通ったのかを工程へ戻し、同じ見落としを繰り返さないことだと思っています。
03 / TOO KIND
AS/400は、
優しすぎた。
元の処理は、約4億件を順番に読み、1件を判定するたびにマスタを何十回も参照していました。 仮に1件あたり30回なら、4億 × 30で120億回。記事タイトルの「120億回」は実測監査値ではなく、 処理量の大きさを伝えるための概算です。
頻繁に使うマスタのページや索引は、Db2 for iが管理する主記憶上のバッファに載っていた可能性があります。 だから、参照のすべてが物理ディスクを読みに行ったわけではないでしょう。それにしても、この仕事量を30分で終える。
AS/400が遅かったのではありません。新幹線の線路は立派なのに、データアクセスだけが自転車で走っていたようなものです。 しかもAS/400は、その自転車を最後まで運んでしまった（笑）。高い安定性と性能が、ときに設計の無理を隠すこともあります。
04 / REPAIR
業務ロジックを壊さず、
データへの行き方を直す。
必要だったのは、複雑な業務ロジックを捨てることではありません。必要なデータへ必要な順序で到達できるように、 データアクセスを組み直すことでした。
見直した結果、約30分かかっていた処理は20〜30秒になりました。魔法のような新技術を入れたのではなく、 IBM iとDb2 for iが本来得意な働き方へ戻したのです。
全件を読み、判定ごとにマスタを何度も参照
業務ロジックは活かし、データアクセスを再設計
05 / FOR PEOPLE
システムは、
使う人のためにある。
市坂さんは以前、検体照合の音声認識機能でも、実際に操作する立場から使用感を率直に伝えてくれました。 「こうなったらいい」「こんな機能があったらいい」。その声を聞き、早いときには30分後に改善版をリリースし、 1日に3回改訂したこともあります。私の思いつきで関西弁をメニューに忍ばせたら、現場で気づいた人が使って笑ってくれました。
要望を言えばすぐ変わる。だから遠慮なく言える。そんな関係があったから、今回の「異様に遅い」も雑談の中から出てきました。 技術だけでは見つけられない問題を、使う人との信頼が見つけてくれたのです。
私がAS/400を好きなのは、古いからでも、慣れているからでもありません。 現場の声をすぐ形にし、使う人が笑顔で働ける環境を育てられる——その力を、実際に何度も体験してきたからです。
AS/400は遅くなかった。
むしろ、優しすぎた。