はじめに
newmoグループでは参画してくれたタクシー会社のDXを行っています。タクシー業界は老舗企業が多く、運用されているシステムに関する知見が社内に残っていないケースが珍しくありません。また、長年稼働してきたシステムは技術的にもレガシー化が進んでいます。開発当初は時代に合った優れたシステムだったとしても、年月が経てば保守・運用の負担は増していきます。こうした課題を解決するため、グループ全体で使用するシステムを内製で統一し、モダンな技術スタックへ移行するDXを進めています。
このエントリでは、給与計算システムの置き換えに取り組んだ事例を紹介します。今回、置き換え対象となった旧システムは、外部の企業が開発したもので、長年運用されてきたものです。上記の知見が社内に残っていないケースで、給与計算ロジックがブラックボックス化していました。 本エントリでは、そんなちょっと辛い状況をClaude Codeに助けてもらったことを振り返ります。
1ヶ月悩んだ話
設計書通りに作っても、値が合わない
プロジェクトがスタートし、新システムの概要の設計がされると、設計書が手元に届きました。しっかり読み込んで、設計書通りに実装しました。しかし、いざ旧システムの出力データを使って検証してみると、値が合わない。入力値は同じはずなのに、出力値が違う。何度見直しても原因がわからない。
仕様書も信用できない
次に、設計書の元となる旧システムの仕様書をかき集めて読み込んでみました。しかし、ここにも問題がありました。 仕様書はメンテナンスされていなくて、内容が明らかに実態と違っていたり、読めば読むほど疑問が増える状態でした。
特に、長年運用されていたせいかドキュメントの一貫性が失われていて、理解が難しくなっているところが難点でした。基本給 という単語が指す意味が 基本給単価だったり 基本給A だったり 基本給A - 控除 だったりして、各文脈でどの意味で使われているか、実際に計算してみないと分からず、仕様の把握にかなり手間を取られてしまいました…。
有識者不在による課題発見の難しさ
そんな時、有識者に確認するのが一般的だと思います。しかし、この案件では、有識者はいません。旧システムを利用している部署はありますが、システム導入時のメンバーはいないので、システムの内部詳細まで把握している人はいません。
有識者不在なため、自分で営業所まで出向いて過去の資料を漁ったり、システムを開発した外部企業にコンタクトを取ったりといった動きが必要になります。時間もコストもかかる上に、それで解決する保証もありません。
最終的に
旧システムの仕様書とこれまでの給与計算結果の実績を照らし合わせて、計算式を推測するなど頑張ってみましたが、計算結果は合致しませんでした。 この時には、夢で給与計算の検証をするぐらいに悩んでいました。プライベートが給与計算で侵食されそうな頃に、ダメもとで旧システムのソースコードがもらえないか交渉したところ、入手することができました。
夢を見る前に交渉すれば良かったです。
AIにコードを解読してもらう
やったこと
1. Claudeに解読してもらう
抜粋したコードを渡し、「歩合給の計算はどのように行なっていますか」といった感じで依頼しました。 プロンプトは特に凝ったものではなく、シンプルな聞き方です。
2. 出力されたロジックを確認
Claudeが出力した計算ロジックの解説を読み実装し、旧システムの出力結果と照らし合わせて妥当性を確認しました。
結果
コードを手に入れてからは3日もかからずに解決できました。
誰も把握していなかった給与計算ロジックがまとまりました。
当初想定していたより複雑なもので、 勤務形態（昼勤・夜勤・隔日勤務）と契約形態（正社員・嘱託社員）の組み合わせによって、使用する係数や閾値、計算式自体が変わります。 さらに、ある項目の計算結果が別の項目の入力になるという依存関係もありました。
実際の計算給与ロジックと仕様書を比較すると複数の差異がありました。係数の値が違ったり、前提となる労働時間などの値の算出方法が違ったり、計算式に使用する変数が違ったり、これらの差異を自力で解決しようとしていたらかなりの時間がかかっていたと思いますが、Claudeのおかげで短時間で解決できました。 実装当初に悩んでいた1ヶ月が嘘のようでした。嘘なら良かったんですが。
学びを活かした話
仕様書が正しいとは限らない
この経験から、「仕様書が正しいとは限らない」という前提で臨むようになりました。
別のタスクで、ある計算式を調査する必要がありました。 今回は最初から仕様書ではなく、データベースに蓄積されている実績データを使うことにしました。
やったこと
1. サンプルデータを抽出
テーブルから数行のサンプルデータを取得し、Claudeに渡しました。
2. Claudeに仮説を出してもらう
「このデータから、どのように計算されているか推測してください」と質問しました。
3. 仮説を検証
実際のデータで計算結果が合致するか確認しました。 入力ミスなどのごく僅かなケースを除き、全てのデータで合致することが確認できたため、実績データから推論させた計算式は正しいと結論づけしました。
結果
前回に比べると一瞬で終わりました。1日もかかっていません。
最初からこのアプローチを知っていれば、あの1ヶ月はもっと短くできたかもしれません。
おわりに
仕様書は保守されていないことがあります。実際に動いているコードや、蓄積されたデータの方が真実に近い可能性があります。今回の場合、最初から旧システムのコードを入手していれば、1ヶ月悩むことはありませんでした。
レガシーシステムのブラックボックス解明は、多くの現場で頭を悩ませている課題だと思います。
もしブラックボックス化したシステムの調査で困っている方がいれば、一度AIにコードやデータを投げてみることをおすすめします。意外とあっさり解決するかもしれません。
書いた人: kumachan(@kumachan_bearr)
