これは SRE アドベントカレンダー 2023 15日目とLivesense Advent Calendar 2023 番外編の記事です。
システム移行などの大きいプロジェクトでは、スコープも大きく、かかる時間も長いです。結果、つきまとう不確実性も大きくなり、残念ながらプロジェクトを途中で中止することになってしまうことも多いです。
完成形を目指して最短距離で進んでいたプロジェクトが途中で止まり、残骸をそのままにしてしまうとシステムに残す傷跡が大きくなります。
プロジェクトを中止したり方向転換する決定をしたあとの、限られたリソースの中でシステムに残すダメージを可能な限り抑えましょうというのが今回の話の要旨です。
今回の記事では、どのような『受け身』を取ればシステムに残すダメージを抑えられるかを考えていきます。
とあるシステム移行プロジェクトでの受け身
ここでは、ある途中で止まってしまったシステム移行プロジェクトを例に、プロジェクトの概要と起きた問題を説明し、その後でどのような対応をすれば問題が軽減できたかを考えていきます。
プロジェクトの概要
あるIT企業で老朽化して修正が困難になったシステムの新システムへの移行プロジェクトが進んでいました。
移行の戦略としては、ストラングラーパターンを採用しました。
手前に用意したファサードで新システムと旧システムのどちらに振り分けるかを制御します。新システムでの実装ができた機能から順番に、古いシステムに向けていたトラフィックを新システムに振り分けていくことによって、移行を順次進めます。
新しいシステムに切り替えた部分については、システム移行が完了したらコード全体として不要になるため、削除等は行わない方針でプロジェクトを進めることにしました。
突然のプロジェクトの中止
移行プロジェクトが始まってしばらく経ったあと、移行プロジェクトを一旦停止することになりました。システム移行に当初の予定よりも多くの時間がかかってしまったことや、変更頻度が高い部分についての移行が終わったことためです。代わりに、社内の他の優先度が高いプロジェクトを進めることになりました。
結果的に、残されたレガシーシステムでは使われているコードと使われていないコードが混在した状態となり、以前よりもさらに修正が困難になってしまいました。
数年後、インフラ関連の変更を進める上で、レガシーなシステムと新しいシステムの両方に変更を行う必要が出ました。横断的な修正が必要でしたが、レガシーシステムでそれぞれの機能が使われているのかを一から調査する必要が発生し、工数が予定よりも多くかかってしまうことになりました。
どこが問題だったのか
このプロジェクトでは、レガシーシステムでは移行が済んだコードの削除を行わず進めていました。システム移行をやり切る前提では、無駄のない最短コースでの移行作業です。対象のコードに対しての知識が蓄積されている状態での移行作業では、コードの削除を行わずとも大きな問題は起きませんでした。一方で、関連知識がない状態で関わることになった人には、使われているコードと使われていないコードが混在している状態は認知不可が高く、コードを把握するのに時間がかかってしまいました。
ここで考えたいのは、デッドコードを消さない判断は、システム移行をやり切る判断に支えられていたはずだということです。システム移行をやり切ってしまえば、デッドコードがあろうとなかろうとそのシステム自体がなくなるので大きな問題ではないでしょう。一方、その前提が変わったのであれば、デッドコードを可能な限り削除しながら進める普通の開発の状態に近づけるのがベターと言えるでしょう。
(普段の開発でもデッドコードが残っている場合は・・・CI等ででデッドコードに気づける仕組みを導入しましょう)
一方で、プロジェクトが止まったのは、会社として新しく進めたいプロジェクトがあったためであり、このような状況で、デッドコードをすべて消すのは難しいです。
そんなときに、コードの削除を全くやらないのではなく、また完全に消し切るのでもなく、リソースが許す範囲で効果が大きい方法で掃除を行うことで、『受け身』をとりましょう。
どんな『受け身』が取れそうだったか
このような場合、なるべく労力をかけずに、かつ使われているコードと使われていないコードの判別が可能な状態に戻すために、ポイントを抑えて削除していく必要があります。将来に関わるの人が読んだときに、認知負荷が高まるのをいかに抑えるかを意識すると良いでしょう。
具体的には、Webシステムであれば以下のような選択肢の中から状況に応じて選ぶと良さそうです。
- デッドコードを全部消す
- コントローラだけ消す
- ルーティング設定だけ消す
- 使われている機能をドキュメントにリストアップ（残された機能が少ない場合）
簡単なMVCのシステムであれば、コントローラを消すだけでも大きな効果がありそうです。また、残された機能が少ないのであれば、そもそも現状でまだ使っている機能をリストアップして終わりということもできるでしょう。
またデッドコードだけではなく、システム移行する前提で、経過措置としての不自然な構成にしてしまっている場合などはそのような構成もなるべく戻すようにすると良いでしょう。
その他のプロジェクトでは？
今回の記事では、レガシーシステムの移行を題材に扱いましたが、新技術の導入の途中で技術的困難に遭遇してやめる判断をする場合や、ビジネス的な判断で開発が止まった新機能などでも、どのような『受け身』をとるのがよいか考えていけば、技術的負債をなるべく増やさないことにも繋がりそうです。
また、そもそもの進め方で、スモールスタートして技術検証を着実に進めることでダメージを減らせるでしょう。
まとめ
システム開発には不確実性が伴い、プロジェクトの方向性が大きく変わってしまうことはよくあります。そんなときに、なるべく後の人のためにきれいな状態でシステムを残していくために、『受け身』をとってダメージコントロールしていきましょう。
