共通化の罠！「個別カスタマイズ地獄」を標準化しようとして痛い目を見た話

乱立する分岐地獄！「個別仕様の山」を標準モジュールへ一本化する

新規のレガシーシステム改修の現場では、仕様書がないことと同じくらい、あるいはそれ以上にエンジニアの頭を悩ませる現実があります。 それが、「画面やロジックのあちこちに散らばる、際限のない個別分岐の山」です。

私がかつて担当した機能改修でも、画面のレイアウトや表示制御において、以下のような3つの個別ロジックが複雑に乱立していました。

• ベースとなる「共通画面」
• 特定の顧客要望を満たすための「顧客別（特定企業）拡張画面」
• 特定のエリアや条件に縛られた「拠点別（特定条件）特化型画面」

このままでは運用コストが増大し続けるため、固有の処理がない画面から順次、共通画面側の設定で対応できる形へ切り替えていくことになりました。

「これ共通化しても大丈夫でしょ」という独断が招いた冷や汗

いざ作業を始めると、仕様書がない現場特有の壁が立ちはだかりました。「どこまでが共通で、どこからが固有の仕様なのか」という境界線がまったく見えず、ソースコードの解読と影響調査は難航を極めました。 

調査を進める中で、一見すると「個別処理」として書かれていたものの、よくよく紐解いてみると共通処理に置き換えられるケースがいくつか見つかりました。解析は非常に難航したものの、「ロジックを見る限り、共通化の設定を使っても同じ挙動が実現できる」と判断し、共通化への切り替えを実施しました。 

しかし、ベテランの運用担当者から「ここのお客様のこの画面動きが変わっている」との指摘を受けた。 慌ててお客様へお詫びの連絡を入れたが、実際にはお客さんはその機能を使っていなかったため事なきを得た。

失敗と冷や汗から学んだ！「安易な標準化」を防ぐ3つの鉄則

このヒヤリハットを通して、私は「目に見える設定やコードだけで勝手に大丈夫だと判断すること」の危うさを痛感しました。仕様書が存在しない現場で、画面やロジックの標準化を安全に進めるために辿り着いたのが、以下の3つの鉄則です。

「たぶん大丈夫」の自己判断は厳禁！事前のヒアリングを徹底する
「見た目が同じだから共通化しても大丈夫だろう」と独断で決めつけるのは非常に危険です。仕様書がない現場だからこそ、手を動かす前に長年システムに携わっている運用担当者や知見者に必ずヒアリングを行います。
事前に確認を挟むことで、コードや画面からだけでは見えない暗黙の仕様や運用上のトラップを未然に防げるようになります。

他者の視点を入れてダブルチェックする
自分一人だけで「問題なし」と完結させず、別のメンバーにも見てもらい、「この条件のときに挙動が変わらないか」「抜け漏れがないか」を第三者の視点を入れてダブルチェックするようにしました。

「使われていない」と分かった時点でナレッジとして残す
今回のように「実は業務が変わってもう使われていなかった」と判明したロジックや設定は、絶好のナレッジ共有のチャンスです。放置せずしっかりと記録を残すことで同じ轍を防ぐことができます。

 泥臭い確認こそが、レガシーシステムを救う最短ルート

「個別カスタマイズ地獄」を整理し、標準化していく作業は、一見すると美しいリファクタリングのように思えます。

しかし、最新の仕様書が存在しないレガシーシステムにおいて最も重要なのは、きれいなロジックを書くことやスマートに共通化することではありません。「自分の思い込みを疑い、泥臭く事実を確認し続けること」です。

私は「コードや設定値だけで判断せず、人に聞き、第三者の目を入れ、判明したナレッジを残す」という行動を身につけることができました。