仕様書がないレガシーシステムから業務ロジックを掘り起こす手順

仕様書がないレガシーシステムの改修依頼は、日本の受託開発では珍しくありません。コードを読むだけでは、なぜその処理がそうなっているのか分からないことが多く、下手に触ると業務が止まるリスクもあります。この記事では、こうした案件に向き合うときの実際の進め方を書きます。

ドキュメントに頼れない前提で始める

仕様書がないというのは、単に紙の資料がないという意味ではありません。作った本人が退職している、当時の意思決定の記録が残っていない、コメントもコミットメッセージも情報量が薄い。こうした状態がセットになっていることがほとんどです。

この前提に立つと、最初にやるべきことは「コードを読むこと」ではなく「聞くこと」になります。実際にシステムを使っている担当者に、日々どう使っているか、繁忙期に何か特別な操作をしているか、過去にどんなトラブルがあったかを聞きます。業務の暗黙知は、コードよりも人の記憶に残っていることが多いためです。

テストとエッジケース処理が最初の手がかりになる

コードを読み始める段階では、まず自動テストの有無を確認します。テストが存在する場合、そこには「意図された動作」が明示的に書かれているため、仕様書の代わりとして機能します。

テストがない、または少ない場合は、条件分岐の中でも特に不自然に見える箇所に注目します。一見無意味に見える特殊条件や、コメントもなく細かく場合分けされている処理は、過去に発生した実際の業務上の問題に対処するために追加されたものであることが多いためです。こうした箇所には、業務ルールが埋め込まれている可能性が高いと考えています。

こうした箇所は、削除や単純化をする前に、必ず「なぜこの条件が必要になったのか」を担当者に確認するようにしています。理由が分からないまま削ると、月末や繁忙期など特定のタイミングでしか再現しない不具合として跳ね返ってくることがあります。

全部を書き直さない、という判断

仕様が分からない部分が多いほど、いっそ全部作り直したくなります。しかし、業務が止まらないシステムの改修では、この判断がリスクになることがあります。

実際に対応した案件では、20年近く稼働しているCMSに対して、UIと処理が密結合しているという課題がありました。ここで、CMS自体を刷新する案と、既存のCMSに合わせてHTMLを自動生成する仕組みを追加する案を比較しました。刷新は根本解決になりますが、範囲も予算も超え、運用担当者の再教育も必要になります。今回は後者を選び、既存の運用に一切手を触れずに、HTML生成にかかる工数を70%削減する形で結果を出しました。

この判断のポイントは、レガシーシステムの課題すべてを一度に解決しようとしなかったことです。分からない部分、触ると危険な部分は残したまま、効果が確実に見込める部分から着手する。この案件はドキュメントが失われた条件分岐を解読した話ではありませんが、「全部を書き直さない」という判断がどう機能するかを示す例にはなっています。

まとめ

仕様書がないレガシーシステムに向き合うときは、コードより先に人に聞く、テストとエッジケースを手がかりにする、そして全部を書き直さずに効果が見込める部分から着手する。この3つを意識するだけで、リスクを抑えながら前に進められるようになります。