組織のトップが変わるタイミングで、システムのアーキテクチャ判断が急に揺れ動くことがあります。CTO やプロダクト責任者の交代を控えているチーム、あるいは経営体制の変化の影響を受けそうなエンジニアに向けて、今回はその「落とし穴」を整理します。
Apple では、Tim Cook から John Ternus への CEO 交代が発表されてから 2 週間足らずで、新型 iPhone の発表イベントが開催されました。新製品には Apple 初の折りたたみ式スマートフォン「iPhone Duo」も含まれていたと報じられています。経営体制の移行期に、大型の技術投資や新製品の意思決定が集中して動いた事例といえます。これは消費者向けハードウェアの話ですが、社内システムやプロダクト開発の現場でも、似た構造の問題が起きやすい局面です。
何が起きるか：意思決定の空白と急加速が同時に発生する
経営トップが交代する前後には、技術的な意思決定が二極化しやすくなります。
一つは「空白期間」です。後任が固まるまで、大規模なアーキテクチャ変更や基盤リプレースの承認が止まります。予算承認者が不在、あるいは権限が明確でない状態が数週間から数ヶ月続くケースがあります。
もう一つは真逆の「急加速」です。新しいリーダーが就任直後に「自分の色」を示す製品や機能を出そうとし、レビュー工程を短縮してリリースを急ぐ動きが出ます。Apple の事例のように、就任からわずかな期間で大型発表が行われるのは、後者の典型パターンです。
この二つが交互に起きると、システムには特有の負債が積み重なります。空白期間中に溜まった保守タスク（依存パッケージの更新、監視体制の見直しなど）が、急加速期の直前にまとめて後回しにされる構造です。
なぜ起きるか：意思決定構造とレビュー体制の変化に分解する
原因を段階的に分解すると、3つの層に整理できます。
まず「承認ライン」の変化です。誰が最終的にアーキテクチャ判断（新技術採用、大規模リファクタリング、クラウド移行など）を承認するかが、組織図の書き換えとともに不明確になります。既存の稟議フローが、新体制下でそのまま機能するかは保証されません。
次に「優先順位付けの基準」の変化です。前任者が重視していた非機能要件（可用性、セキュリティ）と、後任者が重視する軸（機能追加のスピード、市場への露出）が食い違うことがあります。この食い違いが表面化するのは、たいてい次の四半期計画やロードマップ策定のタイミングです。
最後に「レビュー工程の圧縮」です。新体制の初期に大型リリースを予定していると、設計レビューやセキュリティレビューにかける時間が削られがちです。これは意図的な手抜きというより、スケジュールが先に確定してしまい、レビュー工数が逆算で削られる構造的な問題です。
自分のプロジェクトが該当するか確認する方法
該当するかどうかは、以下の観点で確認できます。
- 直近3ヶ月以内に CTO・VPoE・プロダクト責任者クラスの交代、または大規模な組織再編（レポートライン変更）があったか
- 変更管理台帳や ADR（Architecture Decision Record、アーキテクチャ上の重要判断を記録する文書）の更新頻度が、交代の前後で急に落ちていないか
- 直近のリリースで、設計レビューやセキュリティレビューの実施記録（チェックリスト、承認コメントなど）が省略されていないか
- リリース予定日が先に固定され、そこから逆算してテスト期間が短縮された形跡がないか
ADR を運用していない場合は、まず GitHub や Confluence 上で「なぜこの技術を選んだか」を記録した文書が存在するか確認してください。存在しない、または更新が止まっている場合は、意思決定の追跡ができない状態にあると判断できます。
対策の手順
以下は、経営体制の変化がある、または予定されている場合に取れる具体的な対策です。
1. 承認ラインの棚卸しを先に固定する
組織図が変わる前に、「誰がアーキテクチャ判断を最終承認するか」を文書化します。RACI 表（Responsible・Accountable・Consulted・Informed の役割分担表）を使うと、責任の所在が明確になります。
2. 非機能要件の合意を書面で残す
可用性目標（SLA・SLO）、セキュリティ基準、パフォーマンス要件について、現行の合意事項を一枚のドキュメントにまとめておきます。新しい意思決定者が着任した際に、この基準を引き継ぐか変更するかを明示的に確認してもらう材料になります。
3. リリース前のレビューゲートをコード化する
CI/CD パイプライン（継続的インテグレーション・継続的デリバリーの自動化基盤）に、セキュリティレビューやアーキテクチャレビューの完了をマージ条件として組み込みます。GitHub Actions や GitLab CI であれば、以下のように必須チェックとして設定できます。
name: release-gate
on:
pull_request:
branches: [main]
jobs:
require-review:
runs-on: ubuntu-latest
steps:
- name: Check architecture review label
run: |
if ! echo "${{ github.event.pull_request.labels.*.name }}" | grep -q "arch-reviewed"; then
echo "アーキテクチャレビューのラベルが未付与です"
exit 1
fiこのように「人間の承認」を仕組みに固定しておくと、経営判断のスピード変化に振り回されにくくなります。
4. 技術的負債のバックログを可視化しておく
空白期間中に積もったタスクを、Jira や Linear のバックログで「負債」ラベルとして独立管理します。急加速期に紛れて消えないよう、四半期ごとの棚卸しをカレンダーに固定します。
まとめ
経営体制の変化そのものは避けられませんが、システム側の備えは今から始められます。
まず ADR や変更管理台帳の更新が止まっていないか、直近3ヶ月分を確認してください。
次に、承認ラインと非機能要件の合意を文書化し、CI/CD のレビューゲートをコードで固定します。
意思決定者が変わっても、非機能要件の基準とレビュー工程を仕組みとして残しておけば、急加速期のリリースでも品質を守れる可能性が高まります。