システムリプレイスがなんで難しくなっちゃうのか |

システム開発のプロジェクトにはいろんな規模がありますよね。

0->1での新規プロダクト開発だったり、既に動いてるシステムに機能追加を行うものだったり…

今回はその中でも、「システム基盤のリプレイス」についての記事となります。

何かしらの目的を持ってシステムのリプレイスをするとき、気をつけたほうが良いことを、自戒含めて記載します。

プロダクトを「リプレースしながら」一部分だけリリースしていくの、結構難しい。

開発側は本当は黙ってリプレースだけに集中したいが、リリース後の対応とかで作業量が膨大になりがち。

— 山根正大 (@hiro_cashless) 2023年12月21日

[st-myblock id=”447″]

お前は誰？

な人です。

「大規模なプロジェクトとかはまだ任せてもらえてないけど、ちょっとずつマネジメントの階段登りつつある人」です。

ユーザから見た機能面はリプレイス前後で変わらない、(諸々の理由から)アーキテクチャのみを変える
リプレースには2~3年かかる
その間にも新規顧客導入は進めないといけない
- それゆえ新旧含めたシステムを顧客導入することもある
- リプレイス作業と並行で、リプレイス前のシステムにも仕様追加が入り続ける

といったビジネス状況を想定しつつ、具体的に何が難しいねん、というのを書いていきます。

「リプレイス前のシステムにも仕様追加が入り続ける」影響で、開発スコープが発散しがちです。

具体的には

みたいな感じです。

スコープが増えること自体は悪くないのですが、「当初決めたスケジュールとは別のスケジュールで」追いつき対応を入れるのがセオリーかなぁと思います。

【自戒】

リプレイスだけに留まらない話ですが、

ビジネスサイドから「これも追加で入れられない？」と言われた時に仕様追加をホイホイ受けちゃわないようにしたいですね。

（もちろんビジネス上緊急度が高いものについては優先度入れ替えてやる必要がありますが）

無邪気に受けちゃったが最後、具体的なタスクをメンバーに振った時に

となり、「リーダーがやる仕事ってこれだっけ？」 となります。。

新旧入り混じった状態で顧客提供しなければならない期間が生まれる場合、

一つのプロダクトとしてうまくアーキテクチャを考えないと、

新旧の依存関係が密結合になった保守しづらいシステムになる気がします。

結論出せてないのですが、具体的に発生しそうな課題は以下。

新旧のシステムでコード管理リポジトリを分けるのか分けないのか
- 分けるとしたら…
  - CICD方式は同じにするのが良いか？
  - 「新旧で同じロジックを書いてしまって、ビジネスロジックが散らばる->一時的に保守性が下がる」事態を避けたい。どうしたら良いか？

ここら辺、山根の勉強が足りず、しっかり言語化できていない部分です。誰かケーススタディとして教えて欲しい。。

そもそもアーキテクチャのセオリーというか、知識がない。

CICDとかコード基盤レベルの話だと「小さく失敗する」がしづらいので、王道を知った上で判断できるようになりたい。

リプレイスやる時って、主にユーザ目線よりは開発側目線（コストとか保守性とか）が理由になってくると思うのですが、

そんなもんユーザは知らん、ってことの方が多いと思います。

以下はお気持ち表明でしかないのですが、ユーザ目線で

「リプレイスだかなんだか知らないけど、使いづらくなった気がするよ？」

って言われるのを一番避けたいですね。

「システムリプレイスが難しくなる理由」について解説してきました。

エンジニア5年目の解像度だとまだまだ全然分析だったり振り返りが足りてないので、今回挙げたものが全てではないです。もっと要因はいっぱいあります。

ただ、一度リプレースを行った身としては、今回書いたようなアンチパターンを再度踏まないように日々精進していきたいところです。

ここまで読んでいただき、ありがとうございました！