#Engineering

112件のフレームワーク

ADL(アーキテクチャ決定ログ)

ADRを時系列管理し設計判断を組織知に

設計判断の記録と共有 新メンバーのオンボーディング 過去の意思決定の振り返り
難易度 ⏱ 30分〜1時間(1件あたり)

イベントモデリング

時系列イベントでシステム全体の振る舞いを設計

システムの全体設計 ビジネスとエンジニアの認識合わせ イベント駆動アーキテクチャの設計
難易度 ⏱ 3〜6時間(ワークショップ形式)

インシデント・コミュニケーション

障害時の社内外への情報発信とステークホルダー管理の体系的手法

障害時の顧客通知 社内エスカレーション ポストモーテム共有
難易度 ⏱ テンプレート整備に1〜2日、運用は障害発生時

カオスゲームデー

計画的障害注入でシステム耐障害性を検証するイベント型演習

システム耐障害性の検証 インシデント対応訓練 障害検知の改善
難易度 ⏱ 準備1〜2週間、実施半日〜1日

キャパシティプランニング

サービス成長予測とインフラリソースの事前確保で安定稼働を実現する手法

インフラコストの最適化 トラフィック急増への備え サービス成長に伴うリソース計画
難易度 ⏱ 初回策定に1〜2週間、以後は四半期ごとに見直し

コントラクトファースト設計

API仕様を最初に定義してから実装する開発アプローチ

API設計の品質向上 フロント・バック並行開発 マイクロサービス間の契約管理
難易度 ⏱ 仕様策定に1〜3日(エンドポイント群ごと)

テクニカルデット象限

意図的/無意図×慎重/無謀の2軸で技術的負債を分類・管理する思考ツール

技術的負債の優先順位付け リファクタリング計画の策定 経営層への技術投資の説明
難易度 ⏱ 分類に30分〜1時間、管理は継続的

トイルバジェット

手作業の上限を設定し自動化投資の判断基準に

手作業コストの可視化 自動化投資の優先順位決定 エンジニアリング時間の確保
難易度 ⏱ 1〜2時間(初回計測+予算設定)

ブラストレディアス縮小

障害影響範囲を最小化する設計パターン集

障害影響範囲の最小化 耐障害性設計のレビュー 本番環境のリスク評価
難易度 ⏱ 継続的(初期設計3〜5時間)

モノレポ戦略

単一リポジトリで複数プロジェクトを管理する利点・課題と導入判断

リポジトリ構成の見直し チーム間コード共有の効率化 CI/CDパイプラインの最適化
難易度 ⏱ 導入判断に1〜2週間、移行に1〜3か月

ランブック

定型運用手順をドキュメント化し属人化排除

インシデント対応の標準化 オンコール引き継ぎ 運用の自動化判断
難易度 ⏱ 1〜3時間(1手順あたり)

進化的アーキテクチャ

フィットネス関数で品質を守りつつ進化

長期運用システムの品質維持 技術負債の予防 段階的なアーキテクチャ移行
難易度 ⏱ 継続的(初期設計2〜4時間)

APIゲートウェイパターン

クライアントとマイクロサービス群の間に玄関口を1つ置き、ルーティング・認証・レート制限などの横断的関心事を集約するアーキテクチャパターン。導入判断から設計手順までを解説。

マイクロサービス統合 API管理 クロスカッティング関心事の集約
難易度 ⏱ 30分〜1時間

BFF(Backends for Frontends)

フロントエンドごとに専用バックエンドAPIを用意

マルチプラットフォーム対応 API最適化 フロントエンド開発の高速化
難易度 ⏱ 30分〜1時間

DORA指標(実践ガイド)

Googleが支援するDORAチームが定義した4つのソフトウェアデリバリー指標。デプロイ頻度・リードタイム・変更失敗率・復旧時間でチームの能力を測る

開発チームのパフォーマンス計測 DevOps成熟度の評価 改善サイクルの定量化
難易度 ⏱ 計測基盤構築に1〜2週間、運用は継続的

DX(開発者体験)

開発者の生産性と満足度を計測・改善する

開発生産性向上 エンジニア採用・定着 開発環境改善
難易度 ⏱ 30分〜1時間

STRIDE脅威モデリング

6分類で脅威を体系的に洗い出すセキュリティ

新システムのセキュリティ設計 脅威の網羅的洗い出し セキュリティレビューの体系化
難易度 ⏱ 30分〜1時間

アーキテクチャ・フィットネス関数

パフォーマンス・セキュリティ・結合度などアーキテクチャの特性を数値で評価し、CI/CDで自動検証し続けるフレームワーク。コードにユニットテストがあるように設計にもテストを書く手順を解説。

アーキテクチャ品質の自動検証 設計劣化の早期検出 進化的アーキテクチャの実現
難易度 ⏱ 1〜2時間

サービスレベル目標(SLO)

SLI/SLO/SLAの設計と運用でサービス品質担保

サービス品質の目標設定 エラーバジェットの運用 信頼性とベロシティのバランス
難易度 ⏱ 30分〜1時間

バーティカルスライスアーキテクチャ

機能単位で全層を縦に切るアーキテクチャ

機能単位の独立開発 レイヤー間結合度の低減 CQRS適用の前段階
難易度 ⏱ 30分〜1時間

バーティカルスライス設計(詳細)

機能単位でレイヤーを縦断する設計手法

スライスの内部設計 Handler実装のベストプラクティス テスト戦略の策定
難易度 ⏱ 30分〜1時間

インシデント管理フレームワーク

障害対応の型を定め平均復旧時間を短縮

障害対応プロセスの標準化 MTTR短縮 ポストモーテム運用
難易度 ⏱ 1時間〜2時間

インフラ信頼性設計

冗長性・フェイルオーバー・自動修復を組み込んだ基盤

高可用性アーキテクチャの設計 障害耐性の向上 SLA達成
難易度 ⏱ 1時間〜2時間

エラーバジェット

SLOから逆算した許容障害量でリリース速度と信頼性のバランス

リリース速度と信頼性のバランス SLO運用 障害対応の優先順位付け
難易度 ⏱ 30分〜1時間

データベースレプリケーション

読み取り性能と可用性を向上させるDB複製戦略

高可用性の実現 読み取り性能の向上 災害対策
難易度 ⏱ 30分〜1時間

エンジニアリング・エフェクティブネス

開発組織全体の有効性を多角的に測定・改善

開発組織の健全性評価 投資対効果の最大化 ボトルネック解消
難易度 ⏱ 30分〜1時間

エンジニアリング・ロードマップ

技術投資の優先順位と時間軸を明示する計画手法

技術戦略の可視化 ステークホルダーとの合意形成 四半期計画の策定
難易度 ⏱ 1時間〜2時間

エンジニアリングメトリクス

DORA指標を超えた開発生産性の多角的測定

開発チームの健全性評価 改善施策の効果測定 経営へのレポーティング
難易度 ⏱ 30分〜1時間

エンジニアリングラダー

技術職のキャリアパスと期待値を明文化

キャリアパスの明文化 昇格基準の透明化 1on1での成長支援
難易度 ⏱ 1時間〜2時間

エンジニアリング生産性メトリクス

DORA・SPACE等の複合的生産性測定

生産性の多面的評価 チーム健全性の定量化 施策効果の測定
難易度 ⏱ 30分〜1時間

エンジニアリング投資配分

新機能・改善・負債返済・インフラへの投資比率設計

開発リソースの最適配分 技術負債の計画的返済 経営層への投資説明
難易度 ⏱ 30分〜1時間

ゴールデンシグナル

レイテンシ・トラフィック・エラー率・飽和度の4指標監視

サービス監視の設計 アラート設計 障害検知の迅速化
難易度 ⏱ 30分〜1時間

オニオンアーキテクチャ

依存性を内向きに制限する同心円型設計

ドメインロジックの保護 テスタビリティの向上 外部依存の差し替え
難易度 ⏱ 30分〜1時間

ポート&アダプター

外部依存を抽象化し交換可能にする設計手法

外部依存の抽象化 テスタビリティの向上 技術選定の柔軟性確保
難易度 ⏱ 30分〜1時間

オンコール管理

障害対応当番制度の設計・ローテーション・燃え尽き防止

オンコール制度の設計 アラート疲れの解消 エンジニアの燃え尽き防止
難易度 ⏱ 30分〜1時間

クラウドコスト最適化

クラウドインフラの無駄を削減しコスト効率最大化

クラウド費用削減 リソース最適化 FinOps導入
難易度 ⏱ 1〜2時間

コマンドクエリ分離原則(CQS)

副作用のある操作と問い合わせを分離する

API設計 ドメインモデル設計 スケーラビリティ改善
難易度 ⏱ 30分〜1時間

システム設計レビュー

大規模変更前の体系的な設計審査プロセス

大規模リファクタリング前の審査 新システム導入の妥当性確認 非機能要件の漏れ防止
難易度 ⏱ 30分〜1時間

スロットリングパターン

リクエストレート制限でリソース消費を制御

APIレート制限 リソース保護 マルチテナントの公平性確保
難易度 ⏱ 30分〜1時間

ゼロトラスト・アーキテクチャ

全通信を検証する境界なきセキュリティ設計

リモートワーク環境のセキュリティ強化 マイクロサービス間通信の保護 コンプライアンス対応
難易度 ⏱ 30分〜1時間

テクニカルデット優先順位付け

技術的負債を影響度・利子率で定量評価し返済順序決定

技術的負債の棚卸し 返済計画の策定 開発速度低下の原因分析
難易度 ⏱ 30分〜1時間

テックレーダー

技術の採用・試用・評価・保留を4象限で管理

技術選定の標準化 技術スタックの可視化 採用・非推奨の意思決定
難易度 ⏱ 30分〜1時間

デプロイメント・ロールバック戦略

障害発生時に安全かつ迅速に前バージョンへ戻す手法

リリース障害の復旧 デプロイ安全性の向上 MTTR短縮
難易度 ⏱ 30分〜1時間

デプロイメント戦略比較

ローリング・カナリア・ブルーグリーン等の選択指針

デプロイ方式の選定 ダウンタイム削減 リリースリスク低減
難易度 ⏱ 30分〜1時間

パフォーマンスバジェット

読込速度の許容上限を設定し品質を維持

Webサイトの表示速度管理 パフォーマンス劣化の防止 Core Web Vitals改善
難易度 ⏱ 30分〜1時間

ビルド vs バイ判断フレームワーク

自前開発と外部導入の意思決定基準を体系化

技術選定 SaaS導入判断 内製化判断
難易度 ⏱ 30分〜1時間

プラットフォームチームモデル

内部プラットフォーム提供チームの構築・運営

内部開発基盤の構築 チーム間の重複作業削減 開発者体験の向上
難易度 ⏱ 1時間〜2時間

プログレッシブ・デリバリー

カナリア→リング→GAの段階的リリース戦略

リリースリスクの低減 本番環境での段階的検証 A/Bテストとの統合
難易度 ⏱ 30分〜1時間

マイグレーション戦略

レガシーから新システムへの移行パターンと段階的実行

レガシーシステムのクラウド移行 モノリスからマイクロサービスへの段階移行 データベース移行
難易度 ⏱ 1時間〜2時間

モジュラーモノリス

モジュール境界を明確にした単一デプロイ構成

マイクロサービスの複雑さを避けたい場合 モノリスの秩序を保ちたい場合 将来の分離に備えた設計
難易度 ⏱ 30分〜1時間

リリースエンジニアリング

ビルド→テスト→デプロイの信頼性と速度を工学的に設計

リリースプロセスの自動化 リリース頻度の向上 リリース品質の担保
難易度 ⏱ 1時間〜2時間

リポジトリパターン(DDD)

永続化の詳細を隠蔽する集約のアクセス手法

永続化ロジックの分離 テスタビリティの向上 DB技術の差し替え
難易度 ⏱ 30分〜1時間

開発者オンボーディング

新メンバーの立ち上がり時間短縮の仕組みと環境整備

新メンバーの早期戦力化 離職率改善 組織拡大期の品質維持
難易度 ⏱ 30分〜1時間

境界づけられたコンテキストマッピング

ドメイン間の関係性を可視化するDDD手法

マイクロサービス分割 チーム境界の設計 ドメインモデルの整理
難易度 ⏱ 1〜2時間

集約設計(DDD)

トランザクション整合性の境界を定めるDDD手法

ドメインモデル設計 マイクロサービス境界決定 データ整合性設計
難易度 ⏱ 1〜2時間

ADR(アーキテクチャ決定記録)

アーキテクチャ上の重要な意思決定を構造化して記録し、将来のチームに「なぜその決定をしたか」を伝える手法

アーキテクチャ決定の記録と共有 技術選定の根拠の文書化
難易度 ⏱ 1件あたり30分〜1時間

APIバージョニング

APIの後方互換性を維持しながら進化させるためのバージョン管理戦略

公開APIの互換性維持 破壊的変更の安全なリリース
難易度 ⏱ 戦略策定に1〜2日

API設計原則

使いやすく、一貫性があり、拡張可能なAPIを設計するための原則とベストプラクティス

REST API の設計 マイクロサービス間のインターフェース設計 外部公開APIの設計
難易度 ⏱ 設計に1〜3日

BFFパターン(Backend for Frontend)

フロントエンドごとに専用のバックエンドを設けることで、UIに最適化されたAPIを提供するパターン

モバイルとWebで異なるAPI要件に対応 フロントエンドの開発効率向上
難易度 ⏱ 設計・実装に1〜2週間

CI/CD

コードの統合・テスト・デプロイを自動化し、高品質なソフトウェアを高頻度でリリースするプラクティス

ビルド・テストの自動化 デプロイの高速化 品質の継続的担保
難易度 ⏱ パイプライン構築に1〜2週間

CQRS(コマンドクエリ責務分離)

データの読み取りと書き込みのモデルを分離し、それぞれに最適化されたアーキテクチャを実現するパターン

読み書きの負荷が非対称なシステム 複雑なドメインの分離
難易度 ⏱ 設計に1〜2週間

DRY原則

Don't Repeat Yourself — 同じ知識やロジックを2箇所以上に書かず、一元管理するための原則

コードの重複排除 保守性の向上 バグの予防
難易度 ⏱ 即日適用可能

GitOps

Gitリポジトリを唯一の信頼源として、インフラやアプリケーションの宣言的な管理とデプロイを自動化する運用手法

Kubernetes環境のデプロイ自動化 インフラ変更の監査・追跡
難易度 ⏱ 導入に1〜2週間

Gitフロー

main/develop/feature/release/hotfixの5種類のブランチで、リリースサイクルを管理するブランチ戦略

リリースサイクルが明確なプロジェクト 複数バージョンの並行開発 チーム開発のルール整備
難易度 ⏱ 導入に1〜2日

GraphQL設計原則

クライアントが必要なデータだけを効率的に取得できるAPI設計のための原則とベストプラクティス

柔軟なAPI設計 フロントエンド駆動のデータ取得
難易度 ⏱ スキーマ設計に3〜5日

Infrastructure as Code

インフラ構成をコードとして管理し、再現性・自動化・バージョン管理を実現するプラクティス

インフラ構築の自動化 環境の再現性確保
難易度 ⏱ 導入に2〜4週間

KISS原則

Keep It Simple, Stupid — 不必要な複雑さを排除し、できるだけシンプルな設計を目指す原則

設計のシンプル化 コードの可読性向上 過剰設計の防止
難易度 ⏱ 即日適用可能

Sagaパターン

分散システムにおける長時間トランザクションを、補償アクションで一貫性を保ちながら実現する設計パターン

マイクロサービス間のトランザクション管理 分散システムの整合性確保
難易度 ⏱ 設計に1〜2週間

SOLID原則

オブジェクト指向設計の5つの基本原則で、変更に強く拡張しやすいコードを書くためのガイドライン

クラス設計の改善 コードの保守性向上 リファクタリングの指針
難易度 ⏱ 理解に1〜2週間、実践は継続的

SRE原則

ソフトウェアエンジニアリングの手法で運用問題を解決し、信頼性をシステマティックに管理するGoogleの運用哲学

運用の体系化 信頼性目標の定量管理
難易度 ⏱ 組織導入に3〜6ヶ月

Twelve-Factor App

クラウドネイティブなSaaSアプリを構築するための12の方法論。移植性とスケーラビリティを高める

SaaSアプリケーションの設計 クラウドネイティブ開発 デプロイの自動化
難易度 ⏱ 理解に1〜2日、適用は段階的

サーバーレスアーキテクチャ

サーバー管理を不要にし、イベント駆動で関数単位の実行とスケーリングを実現するアーキテクチャ

イベント駆動処理 MVPの高速開発
難易度 ⏱ 最初のデプロイまで1〜3日

サーキットブレーカーパターン

障害の連鎖を防ぐために、呼び出し先の異常を検知して一時的に通信を遮断する耐障害パターン

外部サービス呼び出しの障害対策 カスケード障害の防止
難易度 ⏱ 実装に1〜3日

サービスメッシュ

マイクロサービス間の通信をインフラ層で統一的に管理する通信制御アーキテクチャ

マイクロサービス間通信の統一管理 サービス間認証・暗号化の一括適用
難易度 ⏱ 導入に1〜4週間

イベントソーシング

状態ではなくイベントの履歴を保存することで、システムの完全な変更履歴を保持するアーキテクチャパターン

完全な変更履歴の保持 監査ログの実現 状態の時間旅行
難易度 ⏱ 設計・実装に1〜2週間

イベント駆動アーキテクチャ

システム間の通信をイベント(出来事)の発行と購読で行い、疎結合で拡張性の高いシステムを構築するパターン

サービス間の疎結合化 リアルタイム処理 マイクロサービス間連携
難易度 ⏱ 設計に1〜2週間

データベースマイグレーション

データベースのスキーマ変更をバージョン管理し、安全かつ再現可能にデプロイする手法

スキーマ変更の安全なデプロイ 環境間のDB同期
難易度 ⏱ 導入に1〜3日

データベース設計

データの整合性、パフォーマンス、拡張性を兼ね備えたデータベースを設計するための原則と手法

新規システムのDB設計 既存DBの正規化・非正規化 パフォーマンスチューニング
難易度 ⏱ 設計に1〜5日

データメッシュ

データの所有権をドメインチームに分散し、データをプロダクトとして扱う分散型データアーキテクチャ

大規模組織のデータ基盤刷新 データの民主化
難易度 ⏱ 組織導入に6ヶ月〜1年

レートリミティング

APIやサービスへのリクエスト数を制限し、過負荷やサービス乱用を防ぐ保護メカニズム

APIの過負荷防止 DDoS対策 公平なリソース配分
難易度 ⏱ 実装に1〜3日

コードレビュー手法

他の開発者のコードを体系的にレビューし、品質向上・知識共有・バグ防止を実現するプラクティス

コード品質の向上 チーム内の知識共有 バグの早期発見
難易度 ⏱ 1回15〜30分

オブザーバビリティの3本柱

ログ・メトリクス・トレースの3つの信号で、システムの内部状態を外部から把握する手法

システムの可視化 障害の迅速な原因特定
難易度 ⏱ 基盤構築に2〜4週間

カオスエンジニアリング

本番環境に意図的に障害を注入し、システムの弱点を事前に発見・改善する実践手法

システムの弱点の事前発見 耐障害性の検証と改善
難易度 ⏱ 最初の実験に1〜2週間

カナリアリリース

新バージョンを一部のユーザーにだけ先行公開し、段階的に展開範囲を広げるリリース戦略

リスクの低いリリース 本番環境でのA/Bテスト的な検証
難易度 ⏱ 構築に1〜2週間

キャッシング戦略

頻繁にアクセスされるデータを高速な記憶領域に保存し、レスポンスタイムとスケーラビリティを改善する手法

レスポンスタイムの改善 DBの負荷軽減 APIのスケーラビリティ向上
難易度 ⏱ 設計に1〜3日、運用は継続的

クリーンアーキテクチャ

依存関係を内側に向けることで、変更に強く保守しやすいシステムを設計するアーキテクチャパターン

中〜大規模アプリケーションの設計 テスタビリティの向上 フレームワーク依存の排除
難易度 ⏱ 設計に1〜2週間

グレースフルデグラデーション

システムの一部が障害を起こしても、機能を縮退させながらサービス全体を維持する設計手法

部分障害時のユーザー体験維持 大規模トラフィック時の優先機能の保護
難易度 ⏱ 設計に2〜5日

コンテナオーケストレーション

コンテナ化されたアプリケーションのデプロイ、スケーリング、運用を自動化する管理手法

コンテナの本番運用 マイクロサービスの管理
難易度 ⏱ 基盤構築に2〜4週間

コントラクトテスト

サービス間のAPI契約を自動テストで検証し、互換性の破壊を早期に検出する手法

マイクロサービス間のAPI互換性保証 破壊的変更の早期検出
難易度 ⏱ 導入に2〜5日

シフトレフトテスト

テスト活動を開発プロセスの早期段階に前倒しし、品質を作り込むテスト戦略

バグの早期発見とコスト削減 リリースサイクルの高速化
難易度 ⏱ 戦略策定に1〜2日、段階的導入

ストラングラーフィグパターン

レガシーシステムを段階的に新システムへ移行する、リスクを最小化したモダナイゼーション手法

レガシーシステムの段階的移行 リスクを抑えたモダナイゼーション
難易度 ⏱ 数ヶ月〜数年

セキュリティバイデザイン

開発の最初からセキュリティを組み込み、後付けではなく設計段階で脆弱性を防ぐアプローチ

安全なシステム設計 脆弱性の予防的対策
難易度 ⏱ プロジェクト全期間を通じて適用

ゼロトラストアーキテクチャ

ネットワークの内外を問わず、すべてのアクセスを検証・認可するセキュリティモデル

セキュリティ強化 リモートワーク対応
難易度 ⏱ 導入に数ヶ月〜1年

ソフトウェアアーキテクチャパターン

システム全体の構造を決定する代表的なアーキテクチャパターンの概要と選定指針

新規システムのアーキテクチャ選定 既存システムのリアーキテクト判断
難易度 ⏱ 学習に1〜2週間

テスト駆動開発(TDD)

テストを先に書き、テストが通るコードを後から書く開発手法。Red→Green→Refactorのサイクルで品質を担保する

コードの品質向上 リファクタリングの安全網構築 設計の改善
難易度 ⏱ 習得に2〜4週間

ドメイン駆動設計(DDD)

ビジネスドメインの知識を中心にソフトウェアを設計し、ビジネスとコードの距離を縮める手法

複雑なビジネスロジックのモデリング チーム間の共通言語の構築 マイクロサービスの境界設計
難易度 ⏱ 習得に数ヶ月、継続的に改善

トランクベース開発

全員が1つのメインブランチに頻繁にコミットし、長期ブランチを作らないブランチ戦略

継続的デリバリーの実現 マージコンフリクトの削減 リリース頻度の向上
難易度 ⏱ 導入に1〜2週間

バルクヘッドパターン

システムのリソースを区画化し、障害の影響範囲を限定する耐障害パターン

障害の影響範囲の限定 リソース枯渇の防止
難易度 ⏱ 設計・実装に2〜5日

フィーチャートグル

コードのデプロイとリリースを分離し、設定変更だけで機能のON/OFFを制御する開発手法

デプロイとリリースの分離 A/Bテスト 段階的ロールアウト
難易度 ⏱ 導入に2〜3日

フィーチャーブランチ戦略

機能ごとに独立したブランチを作成し、レビュー後にメインブランチにマージするGit運用戦略

機能単位の並行開発 コードレビューの標準化
難易度 ⏱ 導入に半日〜1日

ブルーグリーンデプロイメント

本番環境を2面用意し、切り替えるだけでリリースとロールバックを瞬時に行うデプロイ戦略

ダウンタイムゼロのリリース 安全なロールバック
難易度 ⏱ 構築に1〜2週間

プラットフォームエンジニアリング

開発者が自律的に開発・デプロイできるセルフサービス基盤を構築し、開発者体験を向上させる手法

開発者体験の向上 セルフサービスインフラの構築
難易度 ⏱ 基盤構築に3〜6ヶ月

ペアプログラミング

2人1組でリアルタイムにコードを書く開発手法。コード品質と知識共有を同時に実現する

複雑な問題の解決 新メンバーのオンボーディング 品質の重要な機能の開発
難易度 ⏱ 1セッション1〜2時間

ヘキサゴナルアーキテクチャ

ポートとアダプターで外部依存を切り離し、ビジネスロジックを中心に据えるアーキテクチャ

テスタブルな設計 外部依存の切り離し
難易度 ⏱ 設計に1〜2週間

マイクロサービスアーキテクチャ

システムを小さな独立したサービスに分割し、それぞれを独立してデプロイ・スケールできるアーキテクチャ

大規模システムの設計 独立デプロイの実現 チームのスケーリング
難易度 ⏱ 設計・移行に数ヶ月

モニタリングとオブザーバビリティ

メトリクス・ログ・トレースの3本柱でシステムの状態を可視化し、障害の予防と迅速な対応を実現する

システム障害の早期検知 パフォーマンスのボトルネック特定 SLO/SLAの管理
難易度 ⏱ 基盤構築に1〜2週間、改善は継続的

モブプログラミング

チーム全員で1台のパソコンに向かい、同じ問題を同時に解決する開発手法

複雑な問題のチーム解決 新メンバーのオンボーディング 設計判断の合意形成
難易度 ⏱ 1セッション2〜4時間

リトライパターン

一時的な障害に対して自動的に再試行を行い、システムの回復力を高める耐障害パターン

一時的なネットワーク障害への対応 外部API呼び出しの信頼性向上
難易度 ⏱ 実装に半日〜1日

技術的負債管理

短期的な速度を優先して蓄積した設計・実装上の妥協を可視化し、計画的に返済していくマネジメント手法

レガシーコードの改善 開発速度の回復 品質と速度のバランス管理
難易度 ⏱ 可視化に1〜2日、返済は継続的

負荷テスト手法

本番想定のトラフィックをシミュレーションし、システムの性能限界と改善点を発見するテスト手法

パフォーマンスボトルネックの発見 キャパシティプランニング
難易度 ⏱ 準備から実行まで1〜2週間

分散トレーシング

マイクロサービスをまたぐリクエストの流れを追跡し、ボトルネックや障害の原因を特定する手法

マイクロサービスの障害原因特定 レイテンシボトルネックの発見
難易度 ⏱ 導入に3〜5日

冪等性パターン

同じ操作を何度実行しても結果が変わらないように設計し、リトライや重複リクエストに安全に対処するパターン

決済処理の重複防止 APIのリトライ安全性の確保
難易度 ⏱ 実装に1〜3日