「そろそろ作り直しでは」という声が出たときに、感覚ではなく事実で判断するためのシートです。多くの場合、必要なのは全面的な作り直しではなく、一部の切り出しです。
作り直しを議論する前に
作り直したいという要望は、技術側から出ることも事業側から出ることもあります。どちらの場合も、最初に「今、何が困っているか」を具体的な出来事に落とします。「古いから」「綺麗ではないから」は理由になりません。困りごとが事実として挙がらない場合、作り直しの優先度は高くありません。
方向1: 負荷から見る
利用の増加に対して、システムがどこで先に苦しくなるかを確認します。全体を作り直すのではなく、詰まっている箇所を特定することが目的です。多くの場合、問題はデータベースへの問い合わせや、特定の重い処理に集中します。
方向2: 組織から見る
システムの構造は、それを触る人の数と分担に合っていることが必要です。人が増えたのに一箇所を全員で触っている状態では、待ち時間と手戻りが増えます。逆に、人が少ないのに細かく分割すると、管理の手間だけが増えます。
方向3: 技術から見る
使っている技術そのものが、事業の速度を落としているかを確認します。判断の軸は新しさではなく、更新が続いているか、扱える人を採用できるか、依存している外部サービスが継続しそうかです。
作り直す範囲を決める
3つの方向で出た困りごとを、範囲の大きさで分類します。全面的な作り直しは、期間中に新しい機能を出せなくなる期間が生まれるため、事業の勢いがある時期には選びにくい選択です。切り出せる単位を探し、動かしながら置き換える方法を優先して検討します。
時期を決める
作り直しは、事業の予定と資金の状況を見て時期を決めます。調達の直前や、大きな営業の山場と重ねると、両方が中途半端になりがちです。並行して走らせる場合は、どちらの遅れを許容するかを先に決めておきます。
作り直しを始める前の合意事項
着手時に決めておかないと、途中で目的が曖昧になります。「何が解決したら終わりか」を数値や状態で書き、関係者で共有してください。終わりの定義がないまま始めた作り直しは、長期化しやすくなります。
関連するインサイト
- 技術的負債との付き合い方 — 返済の優先順位を決める技術的負債はゼロにするものではなく、管理するものです。意図的な負債と無自覚の負債の違い、負債の可視化、事業インパクトと変更頻度による優先順位の付け方、開発計画への組み込み方を経営者向けに整理します。
- レガシーコードのモダナイズ — 全面リプレイスか段階移行か古くなったシステムを作り直すべきか、少しずつ置き換えるべきか。全面リプレイスと段階移行の比較、ストラングラーパターン、データ移行、テストのないコードへの向き合い方を経営者向けに整理します。
- クラウドインフラコストの圧縮 — 見直しの順番と落とし穴クラウドの利用料が事業の成長より速く増えているとき、どこから手を付けるべきか。可視化から監視の継続運用までの手順と、可用性や開発速度を損なう落とし穴を経営者向けに整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開