はじめに
特定のプロジェクトの話とかではなく、十年以上開発に関わってきて個人的に感じていることです。
いくつかのプロジェクトで、古いシステムや負債の多いシステムに遭遇した際に「作り直した方が早いんじゃないか」と感じた経験は少なからずあると思います。
本当に作り直した方が早いのか
これはあくまで個人的な経験に基づく話しですが、作り直しの目的が単純に生産性改善や品質改善になっている場合は要注意です。
なぜなら、
Velocity comes from Process, not Architecture
だからです。
生産性あるいは品質の改善を行う際に最初にやるべきことは開発プロセスのチェックなはずです。
たとえば以下のように行っている(行うべき)プロセスを並べてAS-IS(現在), To-Be(あるべき)を列挙してTo-Beになっていないところを取り組むことでも多くの場合かなりの改善が見込めると思います。
| プロセス | As-Is | To-Be |
|---|---|---|
| 要件定義 | hogehoge | foobar |
| 実現方式レビュー | ||
| 設計 | ||
| 実装 | ||
| 単体テスト | すべて手作業 | リファクタのうえ BEはカバレッジxx%を目指す |
| ソースレビュー | ||
| 結合テスト | ||
| 性能試験 | ||
| 強化テスト | ||
| リリース運用 |
結局のところ、同じような体制/プロセスで作り直しても、同じような問題を引き連れてきてしまいます。
先の見えない「翻訳作業」
「Aという言語だと人が集まらないので、Bという言語にしたい」が作り直しの主な動機になっている場合も要注意です。
そもそも言語を置き換える場合、両方の言語を理解できる人が一定数必要なはずで、その人たちがリファクタリングするのではなぜだめなのか、がシャープになっていないとただの翻訳作業になってしまいます。
(置き換えた言語の人材トレンドが過ぎたらまた作り直すのでしょうか。)
それでも作り直した方がいいとき
考察すると、作り直しが成功するためには コーディングや設計ができる人だけでなく、開発体制の見直し/各開発プロセス(テストも含めて)のあるべき姿を提言できる人材が不可欠ということになります。
そのうえで組織・体制ごと変革せざるをえない場合が作り直しを選択する一つの大きな機会ではないかと思います。たとえば、以下のようなケース
-
外注化していたシステムを内製化する
- リファクタしようにも既存システムの知識をもった人の協力がどこまで得られるか不明
-
オンプレのシステムをクラウドに持っていく
- インフラチームのあり方、インフラエンジニア人材の要件から変えざるをえない
まとめ
- まずは、開発プロセスの見直し
- アーキテクトだけでは作り直しプロジェクトは成功しない
- 作り直しは「選択する」というよりも、「選択せざるを得ない」場合に取りうる手段