リプレイスはなぜ新規開発より難しいのか|「今と同じものを作って」が通用しない理由
「今のシステムと同じものを作り直してほしい」と考えている方に向けた記事です。結論から言うと、リプレイスが新規開発より難しいのは、今のシステムが画面の裏で行っている処理が文書に残っておらず、毎日使っている人も正確には把握していないからです。この記事では、何が見落とされやすいのか、ソースコードの解析で足りない理由、どう進めればよいかを説明します。
ここでいうリプレイスは、今動いているシステムの仕様を引き継いで作り直すことです。運用していた担当者が退職した、開発会社と連絡が取れなくなった、技術が古くて直せる人がいない、といった事情で検討が始まることが多くあります。
リプレイスで、何が見落とされやすいのか
最も見落とされやすいのは、画面に出てこない処理です。システムは大きく、画面・データ・機能の3つでできています。
- 画面:どんな項目があり、どう操作でき、どの画面に移り、入力の何をチェックするか
- データ:画面の操作で、どんな情報がどう保存されるか
- 機能:画面の操作をきっかけに、データを作る・直す・探す・消す処理
このうち機能には、2つの種類があります。
- 画面の入力がそのまま保存されるもの
- 画面の入力をもとに、利用者から見えないところでデータを加工したり、別のデータを作ったりするもの
見落とされるのは後者です。たとえば、売上を月別に集計して表示する処理は、1件ずつの売上を裏で集めて合計しています。注文が入ると在庫を引き当て、在庫が足りなければ発注のデータを自動で作る、という処理もあります。使っている人にとっては当たり前に起きていることなので、わざわざ口に出されず、要件から漏れます。
使っている人が、なぜ正確に説明できないのか
システムの動きに慣れて、業務がその動きに合わせて組み立てられているからです。業務に詳しい人ほど、「システムがこう動くから、自分はこうしている」の前半を意識しなくなります。
その結果、「今と同じでいい」と言われても、その「今」が何を指すのかを誰も正確に言えない状態になります。
仕様書が全くないものから仕様を把握して同じものを作る工程のつらみを表現するために、フラッと入ったラーメン屋のラーメンを食べただけでこのラーメンと同じものを作れるようになれって話ですよという、例えを思いつきました。
素材も調味料も工程も当てなければ、同じ味にはなりません。レシピの再現は、新しく作るより難しいものです。
ソースコードを解析すれば、仕様は分かるのか
動きを書き出すことはできますが、それが正しい仕様かどうかは分かりません。この点は、この記事を最初に書いた2019年から変わっていません。
変わったのは、書き出す速さです。今はAIを使えば、ソースコードから処理の流れを読み取って文書に起こす作業は、人が一から読むよりずっと速く進みます。それでも、次の2つは残ります。
- 書き出せるのは「今どう動いているか」だけ:不具合や、昔の事情で入った処理も、そのまま書き出されます
- 正解を決めるのは発注側:書き出した動きと業務の期待が違ったとき、どちらに合わせるかは、業務を知っている発注側にしか決められません
ソースコードの解析は、現状を調べる材料の一つです。仕様を決める作業の代わりにはなりません。
リプレイスは、どう進めればよいのか
今の動きを調べて文書にし、残す・変える・やめるに分けてから作り直します。
- 今の動きを調べる:業務の流れ、画面と帳票、データ、外部との連携を、現場の操作とデータで確かめる。ソースコードの解析も材料に使う
- 正しい動きを決める:書き出した動きを業務の担当者と確かめ、残す・変える・やめるに分ける
- 決めた動きをテストの基準にする:作り直したシステムが、残すと決めた動きを守っているかを確かめられるようにする
調べ方は「現状分析では何を調べればよいか」で、リプレイス全体の進め方は「システムリプレイスの進め方」で説明しています。
実際の案件では
GILT・GLADDを含む3アプリのFlutterリプレイス(la belle vie様)では、既存アプリのコードとAPI仕様を参照しながら、3つのアプリをFlutterで作り直しました。当社はTech Lead/PLとして要件定義から入り、テストは別の会社がテストシナリオの設計から担当しています。作り直しの基準を、作る側とは別のチームが確かめる体制です。
モバイルオーダーの再構築(大手外資系ファーストフードチェーン)は、10年ほど前にリリースされたシステムの作り直しでした。外部システムとの連携が非常に多かったため、連携の取り決めを守ることと、その組み込みを特に慎重に進めました。画面の裏の処理の中でも、外部との連携は、漏れると利用者に直接影響が出るところです。
まとめ
- リプレイスで見落とされるのは、画面の裏でデータを加工したり、別のデータを作ったりする処理
- AIでソースコードから動きを書き出す作業は速くなったが、正しい仕様を決めるのは今も発注側
- 今の動きを調べ、残す・変える・やめるに分けてから作り直す
自社のシステムをどう作り直すか相談したい方は、お問い合わせからご連絡ください。
よくある質問
仕様書が無いシステムでも、リプレイスできますか?
できます。ただし、作り直す前に、今のシステムの画面・データ・機能を調べて文書にする工程が必要です。その分の期間と費用を、最初から計画に入れておきます。
AIでソースコードを解析すれば、仕様書の代わりになりますか?
動きを書き出す作業は速くなりますが、仕様書の代わりにはなりません。書き出せるのは「今どう動いているか」で、「それが正しい動きか」は、業務を知っている発注側が判断する必要があるからです。
リプレイスのついでに、機能を見直してもよいですか?
見直すこと自体はよいことですが、範囲を絞ります。今の動きを残す・変える・やめるに分け、変える範囲が広がりすぎないようにすると、終わりが見えなくなるのを防げます。