「そろそろ作り直しでは」という声が出たときに、感覚ではなく事実で判断するためのシートです。多くの場合、必要なのは全面的な作り直しではなく、一部の切り出しです。
作り直しを議論する前に
作り直したいという要望は、技術側から出ることも事業側から出ることもあります。どちらの場合も、最初に「今、何が困っているか」を具体的な出来事に落とします。「古いから」「綺麗ではないから」は理由になりません。困りごとが事実として挙がらない場合、作り直しの優先度は高くありません。
- 直近3か月で、システムが原因で遅れた・止まった出来事を書き出す
- その出来事の頻度と、事業への影響（機会損失、対応工数、顧客からの申し出）
- 同じ出来事が今後も起きる見込みがあるか
方向1: 負荷から見る
利用の増加に対して、システムがどこで先に苦しくなるかを確認します。全体を作り直すのではなく、詰まっている箇所を特定することが目的です。多くの場合、問題はデータベースへの問い合わせや、特定の重い処理に集中します。
- 応答が遅い画面・処理を、実測値で3つ挙げられるか
- その遅さが、利用者数に比例して悪化しているか（一定なら別の原因）
- インフラ費用が、利用の伸び以上のペースで増えていないか
- 障害が起きた時間帯と、そのときの利用状況を記録しているか
方向2: 組織から見る
システムの構造は、それを触る人の数と分担に合っていることが必要です。人が増えたのに一箇所を全員で触っている状態では、待ち時間と手戻りが増えます。逆に、人が少ないのに細かく分割すると、管理の手間だけが増えます。
- 現在、コードを触る人は何人か。半年後は何人になる見込みか
- 同じ箇所を複数人が同時に触って衝突することが増えているか
- リリースの回数が減っていないか、1回あたりの変更量が増えていないか
- 新しく入った人が、最初の変更を出すまでにどれくらいかかっているか
- 本番へ反映する作業が、特定の一人に依存していないか
方向3: 技術から見る
使っている技術そのものが、事業の速度を落としているかを確認します。判断の軸は新しさではなく、更新が続いているか、扱える人を採用できるか、依存している外部サービスが継続しそうかです。
- 使っている言語・フレームワークの更新が続いているか
- サポートが終了する予定のものを使っていないか（期限を把握しているか）
- その技術を扱える人を、現実的な条件で採用できるか
- 特定の外部サービスに深く依存していて、乗り換えが困難な箇所はどこか
作り直す範囲を決める
3つの方向で出た困りごとを、範囲の大きさで分類します。全面的な作り直しは、期間中に新しい機能を出せなくなる期間が生まれるため、事業の勢いがある時期には選びにくい選択です。切り出せる単位を探し、動かしながら置き換える方法を優先して検討します。
- 設定や運用の変更で済むもの（数日〜数週間）
- 一部の処理だけを切り出して作り直すもの（数週間〜数か月）
- データの構造から見直すもの（数か月〜、事前に影響範囲の調査が必要）
- 全面的な作り直し（他の選択肢が取れないことを確認してから）
時期を決める
作り直しは、事業の予定と資金の状況を見て時期を決めます。調達の直前や、大きな営業の山場と重ねると、両方が中途半端になりがちです。並行して走らせる場合は、どちらの遅れを許容するかを先に決めておきます。
- 今後6か月の事業予定（調達、大型の商談、繁忙期）を書き出す
- 作り直しに充てられる人数と期間の見当
- 着手を遅らせた場合に増えるコスト（対応工数、機会損失）の見当
- 途中で中断が必要になったとき、どの時点なら止められるか
作り直しを始める前の合意事項
着手時に決めておかないと、途中で目的が曖昧になります。「何が解決したら終わりか」を数値や状態で書き、関係者で共有してください。終わりの定義がないまま始めた作り直しは、長期化しやすくなります。
- 解決したい困りごとと、解決したと判断する基準
- 作り直しの対象に含めないもの（機能追加を混ぜないことの確認）
- 期間の見通しと、超えた場合の判断のしかた
- 作業中も既存の利用者に影響が出ないようにする方法
- 終わった後に、効果を確認する時期と方法
関連するインサイト
- 技術的負債との付き合い方 — 返済の優先順位を決める技術的負債はゼロにするものではなく、管理するものです。意図的な負債と無自覚の負債の違い、負債の可視化、事業インパクトと変更頻度による優先順位の付け方、開発計画への組み込み方を経営者向けに整理します。
- レガシーコードのモダナイズ — 全面リプレイスか段階移行か古くなったシステムを作り直すべきか、少しずつ置き換えるべきか。全面リプレイスと段階移行の比較、ストラングラーパターン、データ移行、テストのないコードへの向き合い方を経営者向けに整理します。
- クラウドインフラコストの圧縮 — 見直しの順番と落とし穴クラウドの利用料が事業の成長より速く増えているとき、どこから手を付けるべきか。可視化から監視の継続運用までの手順と、可用性や開発速度を損なう落とし穴を経営者向けに整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開