概要

本記事では、10年以上前に開発された既存システムをリプレイスする際に、私自身が直面した「課題」、「課題に対するアクション」、「結果」について紹介します
また、自身のリプレイススキルを証明する一つの材料として執筆しております

本記事は下記のサービスにて公開しております。公開日時：2024年12月15日
複数のプラットフォームで発信することで、多くの方にご覧いただき、少しでも参考になれば幸いです。

Zenn
Qiita
Twitter
linkedin
Findy
Forkwell
LAPRAS
職務経歴書のレジュメ
etc

結論

10年以上前に開発された古いシステムをリプレイスする際、特に“現行踏襲”要件が盛り込まれている場合は、精度の高いデータが重要です。

具体的には、下記のようなケースが該当します。

旧システムの1つのテーブルに100カラムを超える非正規化されたDB設計群を、リプレース後も引き継ぐ場合
旧システムにおける数千～1万行を超える巨大なビジネスロジックや複雑なSQLを、リプレース後も維持する場合

といったケースである。

このような現行踏襲開発するケースでは、開発初期段階で「精度の高いデータ」早期に入手することが重要です。逆に「精度の高いデータ」を確保できないと、不具合多発や納期遅延などのリスクが高まります。

結論の背景

前提

項目	詳細
開発分野	Web
概要	10年以上前に開発された業務Webシステムのリプレイス && 新機能開発
Webシステムの画面数	100画面以上
DBのテーブル数	100テーブル以上

発生した課題

初期ローンチ直前なのに1番大事な機能が未完成であるという課題が発生した。
10年以上前に開発されたリプレイス前のシステムには、ユーザ自身の売上を詳細に確認できる機能が備わっており、新システムでも現行踏襲する要件となっていたが、初期ローンチ直前にも関わらず、この機能群は未完成状態であった。
仮にこの状態を自身の生活に置き換えると、自身の給料明細をWebで確認する際に、そこに記載されている数字がデタラメである状況と同義である。

課題が発生した経緯・原因

下記要因が複合的に重なった結果、本課題が発生した。

要因1

現行踏襲機能開発における制約をクリアにできなかった。

主に2つ制約がありました。
1つ目の制約は、現行踏襲機能の実装方針が基本的にリライトするという制約があった。
つまり、10年以上前に開発された旧システムの非正規化されたDB設計を、リプレイス後も継承し、旧システム同様に、アプリ側で複雑なSQL(ORM)とビジネスロジックをリライトする必要があるという制約があった。
本来であれば、DBを正規化したい所ですが、商流や外部システム連携との兼ね合いがあったため、現行踏襲機能のDB正規化は不可能だった。

2つ目の制約は、現行踏襲機能開発に必須である「精度の高いデータ」を共有して貰えないという制約があった。
つまり、現行踏襲機能の実装過程でダミーデータを作成する際は、各実装者が10年以上前の旧ソースコード、旧DDL、旧テーブル定義書を参考に各テーブルのデータ構造を主観的な予想でダミーデータを作成することになります。
旧システムの非正規化されたDB設計は、1つのテーブルのカラム数が多く、場合によっては100カラム超えるテーブルが存在します。
精度の高いデータが無いとモノリス度が高いリライトほど不具合が多発するリスクがある。

精度の高いデータ共有NG理由は、個人情報保護の観点からローンチ直前までNG状態でした。
上位商流企業に対して、データ共有の要請を数回行ったが、本番データには、個人の売上など重要な個人情報が含まれている為、NG状態でした。

要因2

バックエンド力とリライト力が得意な私のリソースが現行踏襲機能開発以外にリソースが持ってかれた。具体的には、新機能開発>結合試験>受入試験対応>追加要望といったところで私のリソースが持ってかれてしまい、現行踏襲機能開発に十分な集中ができなかった。

要因3

上位商流企業に対する交渉が足りなかった。
納品完了が初期リリース+合意のある納品遅れという結果だった。

この納品遅れを改善する為には、開発初期フェーズの段階で、上述べした現行踏襲機能開発に必須である「精度の高いデータ」を死守することが必要条件である。「精度の高いデータ」死守するためにも、私個人もしくはチーム全体で、上位商流企業に対してもっと深い交渉をするべきであったと反省している。
「精度の高いデータ」NG理由が個人情報を懸念しているという理由であることから、例えば、万が一個人情報が流出しても安全であるように、徹底したマスキングを提案するなど、より具体的且つ深い提案を行うべきだった。

課題に対するアクションと結果

■課題に対するアクション
現行踏襲機能開発に必須である「精度の高いデータ」共有要請を交渉した。

■アクションの結果
- 「精度の高いデータ」を一部共有して貰うことに成功した。
- 以前から提案していてテスト手法である画面比較法が浸透したことで、現行踏襲機能の受入試験が円滑に進行した

■課題に対するアクション
業務時間外で下記キャッチアップを行った
- リプレイス前の旧ソースコードをソースリーディング
- リプレイス後の他担当者がリライトしたソースコードのソースリーディング

■アクションの結果
実装不備を自ら手を動かして修正完了した

■課題に対するアクション
PMに対して課題に関する懸念と提案を定期的に実施した。

■アクションの結果
上位商流に対して本課題に対する調整が行われた