アーキテクチャ変更の影響をどう分析しますか？

Question

IT Interview Practice · Accepted Answer

変更の影響を**要件、契約、データ、運用上の依存関係**に沿って追跡して分析します。旧要件と新要件の正確な違いから始めます。「もっと大規模にする」「リアルタイムにする」では、安全に評価するには曖昧すぎます。

## 依存関係グラフをたどる

```text
[Changed requirement] --> [Affected business flow]
                                  |
                         [Interface contracts]
                           /              \
                    [Consumers]       [Data/state]
                           \              /
                       [Operations + tests]
```

追跡記録とインターフェースカタログを出発点にし、配置済みの設定、実際の通信、システム責任者の知識で検証します。文書にはバッチジョブ、エクスポート、他チームが管理する利用側が漏れている場合があります。

## 例：在庫状況をより早く見せる

当初の合意が1時間ごとの在庫更新で、新要件が1分以内の可視化だとします。障害中にも適用するのか、利用者が必要とするのは見積もりなのか、確実な引き当てなのかを明確にします。

ERPの変更配信能力、下流APIのクォータ、キャッシュの有効期間、鮮度表示、レポートの前提を調べます。ソースの更新が1時間ごとなら、ポータルの更新間隔を変えても要件は満たせません。分析の結果、ソースの能力か事業目標を変える必要があると結論付ける場合があります。

## 実行につながる評価を作る

- 間接的な利用側も含め、影響するコンポーネントと責任者を列挙します。
- 互換性のある変更と、連携した展開が必要な契約・データモデル変更を分けます。
- 過去の負荷テストや復旧見積もりなど、変更で無効になる証拠を特定します。
- 楽観的な推測ではなく判断基準を付け、未知の点を調べる実験を提案します。
- 新形式で書き込まれたデータの扱いも含め、移行、展開、ロールバックの手順を定義します。

ロールバックには特に注意が必要です。アプリケーションコードを戻しても、データ変換や外部への副作用が元に戻るとは限りません。逆移行が安全でなければ、前進復旧の計画と運用コストを説明します。

## 面接での評価点

代替案、前提付きの工数範囲、各選択肢の事業影響を示します。優れたアーキテクトは、求められる成果により広い変更が必要な理由を説明し、制限を明示した、より小さく実現可能な成果を提案できます。

依存関係グラフをたどる

例：在庫状況をより早く見せる

実行につながる評価を作る

面接での評価点

関連する質問