Technology LifecycleとCapacity：限界・更新・廃止を先に設計する
技術は導入時ではなく、peak、脆弱性、support終了、provider障害、data増加、撤退時に真価が問われます。Lifecycleとcapacityを継続的に管理します。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Technology standardとlifecycle
- Capacity model・limit・backpressure
- Patch・upgrade・migration・retirement
体験60 · LIFECYCLE / CAPACITY（限界を先に設計する）
LTS(長期support)のversionを使っていれば、アップグレード計画は不要か確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際の依存versionと回帰testを確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
LTS（長期support）のversionを使っていれば、アップグレード計画は特に立てなくてよいと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
LTSは何を保証していて、何を保証していないでしょうか？
ヒント2を見る
技術のlifecycleは、導入時だけ考えれば十分でしょうか？
もっと詳しく：この問いで使う専門用語
- Technology Radarは、技術を採用・試行・評価・保留などの状態で管理する仕組みです。
- Backpressureは、処理能力を超えた入力を制御し、system崩壊を防ぐ仕組みです。
- Fitness Functionは、Architecture上守りたい性質を継続的に検査する仕組みです。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Technology Lifecycleは採用時だけでなく、試行、標準化、patch、upgrade、縮退、退出、廃止まで管理します。
Capacityは平均負荷ではなく、peak、burst、成長、障害時縮退、外部制限、queue、backpressureをmodel化します。
Architecture Fitness Functionを自動化し、依存version、latency、権限、契約、回復性など重要な性質の劣化を継続検知します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Technology Radar
技術を採用、試行、評価、保留などの状態で管理する仕組みです。
流行と無秩序な標準増加を抑え、学習を共有するためです。
Java 21、Spring Boot、Next.js、Supabaseの採用根拠と期限を管理します。
Backpressure
処理能力を超えた入力を制御し、system崩壊を防ぐ仕組みです。
queue無限増加やtimeout連鎖を防ぐためです。
振込受付へrate limit、queue上限、明確なretry応答を設計します。
Fitness Function
Architecture上守りたい性質を継続的に検査する仕組みです。
小さな変更の積み重ねによる劣化を早期発見するためです。
既存URL、Ledger借貸一致、認可、API互換性、buildを自動検査します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
Technology Radarを統制へ使う
versionだけでなくJDK、framework、OS、database、library、container image、protocol、cipher、SaaS APIをinventory化します。
| 状態 | 意味 | 必要な行動 |
|---|---|---|
| Assess | 限定検証 | hypothesis、sandbox、exit criteria |
| Adopt | 標準利用を推奨 | golden path、support、training |
| Contain | 新規利用を止め維持 | risk control、migration plan |
| Retire | 廃止期限を決定 | owner、dependency removal、archive |
| Exception | 期限付き例外 | 代替control、review date |
Capacityを式にする
| 要素 | 例 |
|---|---|
| Demand | 平常TPS、peak、burst、成長率、batch |
| Service time | p50/p95/p99 latency、DB time、external time |
| Concurrency | 同時request、thread、connection、lock |
| Queue | 長さ、待ち時間、expiry、dead letter |
| Resource | CPU、memory、I/O、storage、network |
| Business limit | 件数、金額、口座、cutoff |
| Safety margin | 障害時片系、release、予測誤差 |
BackpressureとOverload
無制限queueは可用性ではなく遅延した障害です。金融commandをtimeout後に勝手に別経路へ再実行せず、受付identityで結果照会します。
- 01入口でrate・size・authenticationを制御
- 02priorityで重要業務を保護
- 03queueとpoolへ明示上限
- 04timeout budgetをdependencyへ配分
- 05retryへjitter・上限・idempotency
- 06限界超過は早く安全な応答
- 07滞留・拒否・顧客影響を監視
UpgradeとRetirement
MinibankはNext.js 16、React 19、Java 21、Spring Boot 3.3、Supabase clientなど複数lifecycleを持ちます。dependency updateを機能開発の余り時間ではなく継続能力として計画します。
- support・CVE・license・互換期限を把握
- artifactとdata formatのforward/backward compatibility
- production-likeな負荷・failure test
- canary・blue/green・rollingの適合性
- DB migrationのexpand / migrate / contract
- rollback可能点と不可逆点を明示
- 旧runtime・secret・DNS・data copyを確実に廃止
- 廃止後の監査・保持・vendor契約を完了
Architecture Fitness Functions
architecture原則を継続的なtestへ変えると、資料reviewだけでなく変更のたびに逸脱を検知できます。
| 守る特性 | 自動検査例 |
|---|---|
| Dependency | 禁止layer import、循環参照 |
| Security | public schema、secret、dependency CVE |
| Reliability | timeout・retry・pool上限 |
| Data | migration、constraint、lineage |
| Performance | p99・TPS・lock wait budget |
| Lifecycle | EOL version・未所有resource |
| Recoverability | backup age・restore test・reconciliation |
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Technology RadarとFitness Functionの考え方を読んだところで、教材内の参照元で実際の依存versionと回帰testを確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず依存versionの管理を見て、次に回帰testが何を継続的に守っているかを見ます。
教材の参照元を確認する — Source Trail ↓JavaScript technology lifecycle。
package.jsonarchitecture特性を継続検査する基盤。
scripts/regression/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜTechnology Lifecycleは導入時ではなく、限界・脆弱性・support終了・撤退の場面でこそ重要になるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Technology Radar」という言葉を使って書いてみましょう。
ヒント2を見る
Fitness Functionが継続的に何を守っているか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Technology Radar、Backpressure、Fitness Functionの3つを使って、技術を継続的に管理する方法を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- LTSはアップグレード計画の不要を意味しないと説明できる
- Fitness Functionが劣化を継続的に検知すると説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1負荷試験で平均TPSを満たせば十分ですか？
不十分です。peak、burst、hot key、依存先劣化、retry storm、回復時間を試します。
Q2LTS製品ならupgrade計画は不要ですか？
必要です。support期限、security patch、互換性、test環境、rollbackを管理します。
Q3Technology Architectureを継続的に守る方法は何ですか？
ownerとlifecycle台帳を持ち、Fitness Function、capacity trend、障害学習をroadmapへ戻します。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- 金融庁 — 金融機関のITガバナンスに関する論点・プラクティス
経営戦略、IT戦略、DX戦略、次世代architecture、投資・risk・人材の統合
- The Open Group — TOGAF Standard, 10th Edition
Enterprise Architectureの方法、領域、governance、migration planningの基礎
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
package.jsonJavaScript technology lifecycle - 現在の実装 — CURRENT IMPLEMENTATION
services/payment-service/pom.xmlJava technology lifecycle - 現在の実装 — CURRENT IMPLEMENTATION
scripts/regression/architecture特性を継続検査する基盤