引き継いだシステムに仕様書が無い。作った人はもういない。この状態から調査を始めるとき、多くの人がまず全体像を掴もうとします。ディレクトリを一通り開いて、テーブル定義を眺めて、フレームワークのバージョンを確かめる。悪いことではありませんが、これを続けても一週間後に「だいたい分かった」以上のことは言えません。
順番を変えます。全体から入らず、いま動いている経路から辿ります。
入り口を数える
最初にやるのは、そのシステムに外から何が入ってくるかを数えることです。画面のURL、外部から呼ばれるAPI、定期実行されるバッチ、受信するファイル。この4種類を洗い出すと、システムの輪郭が出ます。
数えるだけで、たいてい発見があります。画面が80あるのに、アクセスログを見ると実際に使われているのは20だった。バッチが30本あるのに、半分は数年前から異常終了し続けていて誰も気づいていなかった。この時点で調査の対象が半分以下になります。
ログが残っていない場合は、アクセスの多い順を関係者に聞きます。正確でなくてかまいません。使われていないものを後回しにできれば十分です。
データの出入りを見る
次に、どのテーブルに誰が書き込んでいるかを調べます。読み取りは無視します。書き込みだけを追うと、業務の流れが見えてきます。
ここで外部連携も一緒に拾います。他社のAPIを叩いている、CSVを置きに行っている、メールを送っている。外に出ていく処理は、置き換えるときに最も慎重さが要る部分です。相手先の都合で動いているので、こちらの都合では変えられません。早い段階で一覧にしておきます。
この作業をしていると、同じテーブルを別々の場所から更新している箇所が出てきます。片方は画面から、もう片方は夜間バッチから。こういう場所が、あとで置き換えるときに問題になります。印を付けておきます。
分岐を読む
コードを読むのはここからです。それも全部ではなく、条件分岐だけを追います。
業務システムの仕様は、たいてい分岐に書いてあります。特定の取引先だけ処理が違う、月末だけ計算式が変わる、ある日付より前のデータは別扱いになる。こうした例外が仕様の本体で、正常系はどこも似たようなものです。
分岐を読むときは、なぜそうなっているかを推測しないでください。コードから読み取れるのは何をしているかまでで、理由は書いてありません。理由は関係者に聞くか、分からないままにしておきます。推測した理由をメモに書くと、あとで事実として扱われます。
読まないものを決める
調査で時間を失うのは、読む必要のないものを読んだときです。
自動生成されたコード、フレームワークの内部、コピーされたまま使われていないファイル、コメントアウトされた大きな塊。これらは最初に除外します。除外したことをメモに残しておけば、あとで必要になったときに戻れます。
コメントも同じです。古いコメントは、書かれた時点の仕様を説明しています。今の動きとは違うことがあります。コメントと実装が食い違っていたら、実装のほうが正しいと考えます。
一週間で何が分かればいいか
最初の一週間の目標は、システムを理解することではありません。どこから手を付けられるかを決めることです。
入り口の一覧があり、使われていないものに印が付いている。データの書き込み経路と外部連携が分かっている。危なそうな箇所がいくつか特定できている。この3つがあれば、次の判断ができます。ここまで来て初めて、どこにテストを書くか、どこから置き換えるかという話になります。
逆に、この段階でテストを書き始めるのは早すぎます。どこが重要か分からないまま書いたテストは、置き換えのときに一緒に捨てることになります。
調べたことをどこに置くか
調査結果を立派な資料にまとめる必要はありません。むしろ、まとめた時点で古くなります。
置き場所はコードの近くにします。リポジトリの中にテキストファイルを1つ作り、分かったことを日付とともに追記していく。この形なら、次にコードを触る人が必ず見つけます。共有ドライブに置いた資料は、半年後に誰も見つけられません。
分からなかったことも書いておきます。「この分岐の意図は不明」と書いてあるだけで、次の人は同じ時間を使わずに済みます。
