こんにちは。じじグラマーのカン太です。
はじめに
前回、「[Access業務システムを、Claude Codeで丸ごとRailsに移植してみた話（実体験）](https://jijigrammer.info/programming/3740/)」という記事で、あるお取引先の在庫管理業務システムを、Access/VBAからRails + PostgreSQLへ全面移植した話をお伝えしました。
今回はその続編です。移植そのものは無事に終わったのですが、実際に画面をあれこれ触って仕上げていく「仕上げの段階」で、また新たにいくつか「ハマった話」が出てきたので、今回もシェアします。前回同様、お取引先を特定できないよう、細かい部分は一般化してお伝えします。
「動くのに、なぜか使えない」が一番厄介
前回ハマったポイント（`localhost`の接続エラーや、CSRFトークンの話）は、どちらかというと「動かない」「エラーが出る」という、分かりやすいタイプの不具合でした。今回紹介する話は、それとは少し性質が違います。
自分でテストしているときは何の問題もなく動くのに、実際にユーザーとして触ってみると「あれ、なんかおかしいぞ」となる。しかもエラーメッセージは一切出ない。そういう、地味だけど厄介な種類のハマりどころが中心です。
実際にハマったところ
① 数字を入力する欄が、日本語入力(IME)がオンだと打てない
一番びっくりしたのがこれです。単価や数量、重量を入力する欄は、素直に`<input type=”number”>`という、数字専用の入力欄を使っていました。数字しか入らないので理にかなった作り方のはずなのですが、実際に運用が始まってしばらくして「数量が入力できない」という報告が上がってきました。
原因を確認してもらったところ、これはブラウザの仕様に近い話でした。日本語入力（IME）がオンになっている状態だと、一部のブラウザでは`type=”number”`の欄にキーボードから直接数字を打ち込めなくなり、欄の右端についている小さな上下矢印（スピナー）をクリックして1ずつ増減させるしかなくなる、という現象があるそうです。
これは正直、開発している側からするとかなり気づきにくい問題です。というのも、開発中に動作確認するときは、変数名やコマンドを打つのに忙しく、IMEはほぼオフのままキーボードを叩いています。ところが実際の利用者は、直前まで商品名や取引先名など日本語の項目を入力していて、IMEがオンになったままの状態で、そのまま次の「数量」欄に移動してくることが多いわけです。つまり、開発時の入力の癖と、実際の利用シーンの入力の癖が、そもそも違っていたということになります。
対応としては、数量や単価などの欄を、数字専用の`type=”number”`から、文字入力用の`type=”text”`に変更しつつ、`inputmode`や`pattern`という属性で「スマホでは数字キーボードを出す」「数字以外を入力したらエラーにする」という制御はそのまま保った、という形にしました。見た目や検証のルールは変えずに、IMEがオンでも直接キーボードで打てるようにした、というイメージです。単価・数量・重量など、金額や数字を扱う画面をひととおり洗い出して、同じ修正を横展開しました。
② 一括処理の途中で1件だけおかしなデータがあると、全部止まってしまう
月次の締め処理（請求書や支払明細をまとめて確定させる処理）は、対象となる取引をまとめて一括で処理する作りになっています。ここで見つかったのが、対象の中に1件でも想定外のデータ（たとえば単価が未設定のまま残っている品目など）が混ざっていると、その1件のエラーをきっかけに処理全体が止まってしまい、本来なら問題なく処理できたはずの残り99件まで巻き込まれて未処理のまま終わってしまう、という挙動でした。
月末の忙しい時間帯にこれが起きると、「なぜ締め処理が終わらないんだ」と原因を探すだけで一苦労です。しかも、どの1件が原因だったのかを特定するのも簡単ではありませんでした。
対応としては、一括処理の中で1件ずつ処理を試み、途中でエラーが起きた品目があっても、そこだけスキップして処理を続行し、最後に「正常に処理できた件数」と「エラーになった品目の一覧」の両方を画面に表示する、という作りに直しました。全部が止まる「オール・オア・ナッシング」の処理から、「できるところまではきちんと進める」処理へと考え方を変えた形です。
③ あえて作らなかった「収益性」のグラフ
これは不具合というより、開発を進める中での判断の話です。ダッシュボード画面を充実させる中で、「取引先ごとの月別の売上推移」を折れ線グラフで見られるようにしました。作業を進めながら、「ついでに、原価や利益率まで出したら便利では」という話も一瞬出たのですが、ここは踏みとどまりました。
理由は単純で、このシステムには人件費や倉庫の維持費といった「経費側」のデータが一切存在しなかったからです。売上の数字だけをもとに、それっぽい「利益率」のグラフを作ることは技術的には簡単にできてしまいます。しかし、その裏付けとなる経費データがない以上、そこに表示される数字は実態を反映しない、いわば「それっぽいだけの数字」になってしまいます。
見た目が賑やかなダッシュボードを作ることよりも、「今あるデータから確実に言えることだけを見せる」という誠実さの方を優先し、収益性のグラフは今回作らないことにしました。作れるからといって作ってしまうと、後になって「このグラフの数字、実は正しくないんです」と説明する羽目になりかねません。地味な判断ですが、業務システムを預かる上では大事な線引きだったと思っています。
非エンジニアの実感として
今回の3つに共通しているのは、どれも「実際にシステムが動き始めてから」でないと気づきにくい種類の問題だった、ということです。①は実際の利用者の入力の癖、②は月末の実データの量と質、③はそもそもどんなデータを持っているか、という「現場でしか分からない前提」に関わる話でした。
こうした問題が出てきたとき、Claude Codeが助けてくれたのは、単に修正コードを書いてくれることだけではありませんでした。①のIMEの問題では「なぜこれが起きるのか」というブラウザ側の仕様まで調べて説明してくれましたし、③の収益性グラフの話では、こちらが「作ってほしい」と言いかけたのに対して、「元データに経費の情報がないので、その指標を出すと誤解を招く可能性があります」と、先回りして懸念点を指摘してくれました。言われてみれば当然のことですが、作業に没頭していると意外と見落としがちなポイントを拾ってもらえたのは助かりました。
まとめ
Access業務システムのRails移植、実際に運用が始まってから見えてきた「ハマった話」を3つお伝えしました。
– テスト用のキーボード操作と、実際の利用者の入力の癖は違う。日本語入力(IME)がオンの状態での動作確認も忘れずに
– 一括処理は「全部成功するか、全部失敗するか」ではなく、「1件ずつ、できるところまで進める」作りにしておくと、実運用で助かる
– データが足りない指標は、それっぽく見せられるからといって作らない、という判断も時には必要
前回の「[Access業務システムを、Claude Codeで丸ごとRailsに移植してみた話](https://jijigrammer.info/programming/3740/)」もあわせて読んでいただけると、プロジェクト全体の流れが分かりやすいかと思います。過去のクラウド化の話は「[Accessで作ったシステムをクラウドに移行する方法とコスト](https://jijigrammer.info/programming/access/2570/)」でも書いていますので、Accessの業務システムを抱えている方はあわせてどうぞ。
同じような場面で困ったことがある方、逆に「うちはこう対処した」という話がある方は、ぜひコメントで教えてください。
コメント