エンジニアリング原理原則大全：AI時代でも腐らない“現場の判断OS”をつくる
推奨タグ：
Engineering DevOps SRE PlatformEngineering AI Architecture TeamTopologies DORA Qiita
エンジニアリング原理原則大全：AI時代でも腐らない“現場の判断OS”をつくる
結論：強いエンジニアは「技術名」ではなく「制約・流れ・信頼性・認知負荷」で考える
エンジニアリングで本当に効く原理原則は、流行のフレームワーク名ではない。
現場で長く効くのは、次のような問いである。
- どこがボトルネックか
- フィードバックは何分・何時間・何日で返ってくるか
- 認知負荷は誰に偏っているか
- 本当に守るべき信頼性はどこか
- そのアーキテクチャは組織構造と噛み合っているか
- AIに任せたコードを、誰が、何で、どう検証するか
AIコーディング、Platform Engineering、SRE、DORA、Team Topologies、OpenTelemetry、SSDF、OWASP。名前だけ追うと疲れる。だが、背後にある原理は驚くほど一貫している。
エンジニアリングとは、不確実性を、検証可能で、変更可能で、運用可能な形に変換する技術である。
この記事は、個別技術の紹介ではなく、現場で判断に使える「エンジニアリングのOS」をまとめる。
読む対象は、ソフトウェアエンジニア、SRE、EM、PdM、Tech Lead、Platform Team、AI時代の開発プロセスを再設計したい人。
逆に、「このツールを入れれば全部解決」という答えを探している人には向かない。そんな銀の弾丸はない。たぶん、今週も来週もない。
この記事で持ち帰るもの
この記事で持ち帰るべきものは3つだけでいい。
1つ目は、開発生産性は“人の頑張り”ではなく、システムの流れで決まるという見方。
2つ目は、AI時代ほど、設計・検証・観測・意思決定ログの価値が上がるという現実。
3つ目は、よいチームは、速いチームではなく、速く学習し、壊れても速く戻れるチームだという基準である。
2025年のStack Overflow Developer Surveyでは、回答者の84%が開発プロセスでAIツールを使っている、または使う予定があるとされ、プロ開発者の51%が日常的にAIツールを使っていると報告されている。AI利用はすでに特殊技能ではなく、日常の開発環境になりつつある。:contentReference[oaicite:2]{index=2}
GitHub Octoverse 2025も、AI、エージェント、型付き言語がソフトウェア開発の大きな変化を生んでいると整理している。特にTypeScriptが大きく存在感を増したことは、AI時代においても「曖昧さを減らす仕組み」が重要であることを示している。:contentReference[oaicite:3]{index=3}
ただし、AIが普及したからといって、エンジニアリングの原理原則が不要になるわけではない。むしろ逆だ。
コード生成コストが下がるほど、何を作るべきか、どう検証するか、どう壊れにくくするか、どう運用するかの価値が上がる。
1. 原理原則の全体地図：エンジニアリングは「局所最適」との戦いである
現場の問題は、たいてい単体では起きない。
「レビューが遅い」
「障害が多い」
「リリースが怖い」
「仕様変更がつらい」
「AIでコードは増えたが品質が怪しい」
「Platform Teamを作ったのに、なぜか開発者体験が悪化した」
これらは別々の問題に見える。だが、構造は似ている。
どこかで、局所最適が全体最適を壊している。
| 現象 | 表面上の原因 | 深い原因 | 見るべき原理 |
|---|---|---|---|
| レビューが詰まる | レビュアー不足 | WIP過多、責任境界不明 | Littleの法則、フロー効率 |
| 障害が多い | テスト不足 | 変更単位が大きい、観測不能 | SRE、DORA、Observability |
| AIコードが怖い | AIの精度不足 | 検証設計がない | SSDF、ADR、テスト戦略 |
| マイクロサービスが地獄 | 技術選定ミス | 組織境界とサービス境界の不一致 | Conwayの法則 |
| Platformが使われない | 機能不足 | 内部顧客を見ていない | Platform as a Product |
| 生産性が測れない | 指標不足 | 単一指標信仰 | SPACE |
最初の重要な判断はこれだ。
問題を「人」ではなく「システム」に戻す。
誰かが遅い。誰かが雑。誰かがレビューしない。
そう見えるときほど、先に見るべきは、人ではなく、流れ、待ち行列、認知負荷、責任境界、測定方法である。
2. 原理1：速さは「作業時間」ではなく「待ち時間」で決まる
多くのチームは、個人の作業速度を上げようとする。
しかし、ソフトウェア開発のリードタイムを支配しているのは、実装時間よりも待ち時間である。
Littleの法則は、待ち行列理論の基本式として知られる。平均的なシステム内の数L、到着率λ、滞在時間Wの関係を L = λW と表す。Littleの1961年の論文では、一定の条件下でこの関係が成り立つことが示されている。:contentReference[oaicite:4]{index=4}
ソフトウェア開発に乱暴に翻訳すると、こうなる。
リードタイム ≒ 進行中の仕事量 / 完了率
つまり、完了率が同じなら、進行中の仕事を増やすほど遅くなる。
これは精神論ではない。システムの性質である。
現場で起きること
- 10件のPull Requestが滞留する
- レビュアーが毎日忙しい
- 優先度変更で着手済みタスクが増える
- 仕様確認待ち、QA待ち、リリース承認待ちが増える
- 全員が忙しいのに、何も完了しない
この状態で「もっと頑張ろう」は、火に油を注ぐ。
必要なのは、WIP、つまり進行中の仕事量を減らすことだ。
明日から使える判断式
改善したい対象 = 人の稼働率ではなく、完了までの滞留時間
見るべき数字 = 着手数、完了数、滞留中PR数、レビュー待ち時間、リリース待ち時間
やってはいけないこと = 全員の稼働率を100%に近づける
全員が100%忙しいチームは、変化に対応できない。
バッファのない道路が渋滞するのと同じで、バッファのない開発組織は詰まる。
3. 原理2：DORAは「速さ」と「安定性」を同時に見るための最低限の計器である
DORAは、ソフトウェアデリバリーのパフォーマンスを研究してきた長期的なプログラムであり、開発・運用能力と組織成果の関係を扱っている。([Dora][1])
DORAの指標は、単なるDevOpsダッシュボードではない。
現場の会話を「雰囲気」から「測れる改善」に変えるための計器である。
DORAは2026年1月時点のガイドで、Change lead time、Deployment frequency、Failed deployment recovery timeなどをソフトウェアデリバリー性能の指標として整理している。([Dora][2])
| 指標 | 何を見るか | 悪い使い方 | 良い使い方 |
|---|---|---|---|
| Lead Time for Changes | コード変更が本番に届くまでの時間 | 個人評価に使う | 待ち時間の場所を探す |
| Deployment Frequency | デプロイ頻度 | とにかく回数を増やす | 小さく安全に出せているかを見る |
| Change Failure Rate | 変更が障害を起こす割合 | 障害を隠す圧力にする | 変更単位と検証方法を見直す |
| Recovery Time | 復旧までの時間 | 障害対応者を責める | 検知・切り戻し・運用手順を改善する |
ここで重要なのは、DORAを「順位表」にしないこと。
指標は殴るための棒ではなく、診断装置だ。
反直感ポイント
速いチームは、雑に出すチームではない。
速いチームは、変更を小さくし、検証を自動化し、壊れても戻れるようにしている。
DORAが示す世界観は、「速度 vs 品質」ではない。
正しくは、「小さく速く流せる構造が、品質も上げる」である。
4. 原理3：アジャイルの本質は儀式ではなく、価値あるソフトウェアを早く継続的に届けること
アジャイルは、いつの間にかミーティング体系の名前になってしまった。
デイリー、スプリント、レトロスペクティブ、ポイント見積もり。
もちろん役に立つ場面はある。だが、それ自体が目的化した瞬間に、アジャイルは重くなる。
Agile Manifestoの原則は、「価値あるソフトウェアの早期かつ継続的な提供によって顧客を満足させること」を最優先としている。([agilemanifesto.org][3])
つまり、アジャイルの中心はプロセスではない。
中心は、価値の早期提供と学習速度である。
アジャイルが壊れる典型
| 壊れ方 | 何が起きているか | 修正する問い |
|---|---|---|
| スプリントが作業詰め込み表になる | 学習ではなく消化になっている | 何を検証するスプリントか |
| ポイントが評価指標になる | 見積もりが防衛的になる | 完了価値は何か |
| レトロが儀式化する | 改善が実行されない | 次の1週間で何を変えるか |
| POが仕様係になる | プロダクト仮説が消える | 誰の何を変える機能か |
本質は、「短いサイクルで、作り、見せ、学ぶ」こと。
そのためには、仕様書の量よりも、フィードバックの質が重要になる。
5. 原理4：SREは「障害をゼロにする思想」ではない。リスクを明示的に扱う思想である
SREを「監視と障害対応の専門部隊」と理解すると浅い。
SREの中心は、信頼性を感情論ではなく、測定可能な目標に落とすことだ。
GoogleのSRE本では、SLOはSLIによって測定されるサービスレベルの目標値または範囲と説明されている。([Google SRE][4])
- SLI：何を測るか
- SLO：どこまで守るか
- SLA：守れなかったときの契約上の扱い
- Error Budget：どこまで失敗を許容できるか
ここで大事なのは、信頼性は高ければ高いほどよい、ではないこと。
過剰な信頼性は、コストを増やし、開発速度を落とす。
SRE的な問い
このサービスのユーザーにとって、本当に守るべき体験は何か？
何%の成功率なら、ユーザー価値を損なわないか？
失敗予算を使い切ったら、何を止めるか？
復旧に何分かかる設計なのか？
GoogleのSRE本では、toil、つまり手作業・反復的・自動化可能で長期価値を生みにくい運用作業を減らす思想も強調されている。SRE組織では、運用作業を50%未満に抑え、少なくとも50%を将来のtoil削減やサービス改善につながるエンジニアリング作業に使う目標が示されている。([Google SRE][5])
これは強い。
「忙しい運用」を美徳にしないからだ。
6. 原理5：開発生産性は1つの数字で測れない。SPACEで多面的に見る
「エンジニアの生産性を測りたい」
この問いは危険だ。測り方を間違えると、組織が壊れる。
行数、コミット数、チケット消化数、PR数。
これらは測りやすい。しかし、測りやすいものが重要とは限らない。
SPACE Frameworkは、開発者生産性をSatisfaction and well-being、Performance、Activity、Communication and collaboration、Efficiency and flowの5次元で捉えるモデルとして提案されている。単一の指標だけで生産性を判断すべきではない、という点が重要だ。([queue.acm.org][6])
| SPACE | 見るもの | 例 |
|---|---|---|
| Satisfaction | 満足度・健康 | 開発者体験、ストレス、継続性 |
| Performance | 成果 | ユーザー価値、品質、事業インパクト |
| Activity | 活動量 | PR、レビュー、デプロイ、チケット |
| Communication | 協働 | レビュー品質、チーム間連携 |
| Efficiency and Flow | 流れ | 待ち時間、集中時間、WIP、リードタイム |
危険な単一指標
コミット数だけ見る → 小さい変更を乱発する
行数だけ見る → 膨らませる
チケット数だけ見る → 難しい仕事を避ける
稼働率だけ見る → 学習と改善が死ぬ
よい測定は、人を追い詰めない。
システムの改善点を見つける。
7. 原理6：認知負荷は、開発組織の“見えないCPU使用率”である
人間の頭は無限ではない。
コード、仕様、ドメイン、インフラ、CI、権限、運用、セキュリティ、監視、データ、例外処理。これらを全部1人に詰め込むと、どこかで壊れる。
認知負荷理論は、問題解決や学習において人間の処理能力には限界があり、余計な負荷を下げることが学習や理解に重要であると示してきた。Swellerの1988年論文は、認知負荷理論の基礎文献として知られる。([Wiley Online Library][7])
Team Topologiesは、チーム設計を認知負荷と価値の流れから考える実践体系であり、4つのチームタイプ、3つの相互作用モード、Platform-as-a-Product、価値ストリームへの整合などを主要概念として整理している。([チームトポロジーズ][8])
認知負荷が高いチームの症状
- 新メンバーが半年経っても自走できない
- ドキュメントを読んでも全体像が掴めない
- 本番作業に暗黙知が多い
- 「詳しい人」に依存する
- 障害時にSlackで人を探す
- 変更の影響範囲を誰も言い切れない
この状態で「もっとドキュメントを書こう」は半分正しい。
本当は、ドキュメント以前に、設計・責務・境界・命名・運用導線が複雑すぎる可能性がある。
実務判断
開発者が迷う場所 = プラットフォーム化候補
何度も聞かれる質問 = ドキュメント化候補
毎回人手でやる作業 = 自動化候補
理解に時間がかかる領域 = 境界再設計候補
Platform Engineeringの価値は、ツールを増やすことではない。
開発者が本来集中すべき問題以外を、見えないところで減らすことにある。
8. 原理7：Conwayの法則。アーキテクチャは組織構造の影を引きずる
「このサービス境界、なんでこんなに変なんだろう」
そう思ったとき、コードだけ見ても答えは出ない。組織図を見るべきことがある。
Melvin Conwayの1968年の論文 “How Do Committees Invent?” は、システム設計がそれを作る組織のコミュニケーション構造を反映するという、いわゆるConwayの法則の源流として知られる。([Mel Conway][9])
Martin Fowlerも、Conwayの法則の出典がMelvin Conwayの1968年の論文であり、Fred Brooksの『人月の神話』によって広く知られるようになったと整理している。([martinfowler.com][10])
何が怖いのか
組織が縦割りなら、システムも縦割りになる。
承認が多ければ、デプロイ経路も重くなる。
責任境界が曖昧なら、サービス境界も曖昧になる。
マイクロサービス化に失敗する組織は、多くの場合、技術で失敗しているのではない。
サービス境界とチーム境界と意思決定境界が噛み合っていない。
逆Conway戦略
逆Conway戦略とは、望ましいアーキテクチャに合わせてチーム構造を設計する考え方である。
| 望ましい状態 | 必要なチーム設計 |
|---|---|
| 独立デプロイしたい | 独立して意思決定できるチーム |
| 顧客価値ごとに改善したい | 価値ストリームに沿ったチーム |
| 共通基盤を使わせたい | Platformをプロダクトとして運営 |
| 障害対応を速くしたい | 所有権と観測可能性を明確化 |
アーキテクチャレビューで組織構造を見ないのは、地図なしで道路設計するようなものだ。
9. 原理8：マイクロサービスは銀の弾丸ではない。独立デプロイ可能性を買う設計である
マイクロサービスは便利な言葉だ。
便利すぎて、何でも説明できてしまう。そこが危ない。
Martin FowlerとJames Lewisは、マイクロサービスを「小さなサービス群として単一アプリケーションを開発し、それぞれが独立したプロセスで動き、軽量な通信で連携し、ビジネス能力を中心に構築され、自動化されたデプロイ機構で独立デプロイされるもの」と説明している。([martinfowler.com][11])
この定義で重要なのは「小さい」ではない。
ビジネス能力中心と独立デプロイ可能である。
マイクロサービスが向く条件
- チームがサービスを所有できる
- デプロイ自動化がある
- 監視・ログ・トレースが整っている
- API契約を運用できる
- 障害分離の価値がある
- ドメイン境界がある程度見えている
向かない条件
- まだドメインが見えていない
- チームが少人数すぎる
- CI/CDが弱い
- 監視が弱い
- DB分離ができない
- 障害時に全員集合する
- 単に「モノリスが古い」だけ
モノリスが悪いのではない。
悪いのは、変更理由も責任境界も見えない巨大な塊である。
逆に、サービスを分けても、すべて同じ人が手でデプロイして同じDBを触っているなら、それは分散モノリスだ。名前だけマイクロで、苦しみはマクロである。
10. 原理9：セキュリティは後付け検査ではなく、設計プロセスである
セキュリティを最後にレビューする組織は、毎回同じ場所で燃える。
なぜなら、脆弱性の多くは「実装ミス」だけでなく「設計時点の抜け」から生まれるからだ。
NIST SP 800-218、Secure Software Development Framework version 1.1は、ソフトウェア脆弱性リスクを減らすためのセキュア開発の推奨事項を整理した文書である。([NISTコンピュータセキュリティリソースセンター][12])
OWASP Top 10は、Webアプリケーションセキュリティリスクに関する標準的な啓発文書であり、2025年版が現在の最新版として公開されている。([OWASP Foundation][13])
OWASP Top 10:2025では、Insecure Design、Security Misconfiguration、Software Supply Chain Failuresなどが重要な論点として扱われている。([OWASP Foundation][14])
AI時代に増えるリスク
AIがコードを書くと、コード量は増える。
コード量が増えると、攻撃面も増える。
しかも、AIが出したコードは「それっぽい」ので、人間が油断しやすい。
AI時代のセキュア開発で必要なのは、AI禁止ではない。
必要なのは、次のようなガードレールである。
- 生成コードのレビュー基準
- 依存ライブラリの検査
- シークレット混入チェック
- SAST/DAST/依存関係スキャン
- 権限最小化
- 脅威モデリング
- ADRによる設計判断ログ
- 本番観測と監査ログ
セキュリティは、最後に貼るシールではない。
設計、実装、レビュー、CI、デプロイ、運用の全工程に織り込むものだ。
11. 原理10：Observabilityは監視ではない。未知の故障に答えるための認識能力である
監視は、知っている異常を検知する。
Observabilityは、知らない異常を調べられる状態を作る。
OpenTelemetryは、クラウドネイティブソフトウェア向けのオープンソースObservabilityフレームワークであり、トレース、メトリクス、ログなどのテレメトリデータを取得・収集・エクスポートするためのAPI、SDK、ツール群を提供している。([OpenTelemetry][15])
CNCFは2026年5月21日、OpenTelemetryのGraduationを発表し、標準的なテレメトリ収集・処理の枠組みとして本番利用の成熟を示した。([CNCF][16])
監視とObservabilityの違い
| 観点 | 監視 | Observability |
|---|---|---|
| 主な問い | 壊れているか | なぜ壊れているか |
| 対象 | 既知の異常 | 未知の異常 |
| データ | メトリクス中心 | メトリクス、ログ、トレース |
| 価値 | 検知 | 調査、学習、再発防止 |
| 悪い状態 | アラート疲れ | 高コスト・低利用の計測地獄 |
Observabilityを入れれば安心、ではない。
ログを増やすだけでは、ノイズが増える。
必要なのは、ユーザー体験、サービス境界、依存関係、SLOに沿った観測設計である。
12. 原理11：Platform Engineeringは「社内ツール係」ではない。開発者の認知負荷を下げるプロダクトである
Platform Engineeringが流行ると、社内に「共通基盤チーム」ができる。
ここで失敗する会社は、Platformをプロダクトではなく、インフラ共有物として扱う。
CNCFのPlatforms White Paperは、内部プラットフォームが、アプリケーション開発者などの内部顧客の作業を促進・加速するために、基盤能力やフレームワーク、体験を収集・整理して提供するものだと説明している。([tag-app-delivery.cncf.io][17])
CNCFのPlatform Engineering Maturity Modelでは、Platform Engineeringを、プラットフォームの人・プロセス・ポリシー・技術・事業成果まで含めて計画・提供する実践として整理している。([cloudnativeplatforms.com][18])
Platformが失敗するパターン
| 失敗 | 原因 |
|---|---|
| 誰も使わない | 内部顧客を見ていない |
| 申請が増える | セルフサービスになっていない |
| 抽象化が厚すぎる | 開発者の自由度を奪っている |
| 基盤チームが詰まる | Platform自体がボトルネック化 |
| ドキュメントが読まれない | 導線がプロダクト設計されていない |
よいPlatformの条件
- 開発者が自分で使える
- 安全なデフォルトがある
- 例外申請が少ない
- Golden Pathがある
- 利用者の成功指標がある
- Platform Teamが内部顧客から学習している
Platformは、押し付けるものではない。
使いたくなる「舗装された道」を作るものだ。
13. 原理12：ADRは、未来の自分たちに向けた設計判断のタイムカプセルである
設計判断は、時間が経つと消える。
そして半年後、誰かが言う。
「なんでこうなってるんですか？」
そのとき、答えられる人が退職していたら終わりだ。
だからADRがいる。
ADR、Architecture Decision Recordは、アーキテクチャ上重要な意思決定を、背景・選択肢・決定・結果とともに残す軽量な記録である。ADR GitHubの説明では、Architectural Decisionを、機能要件または非機能要件に関わる正当化された設計選択として定義している。([Architectural Decision Records][19])
Martin Fowlerは、Michael Nygardが2011年にADRという用語を広めたこと、ADRが軽量で意思決定そのものに焦点を当てる文書であることを整理している。([martinfowler.com][20])
ADRテンプレ
# ADR-0001: 認証方式にOIDCを採用する
## Status
Accepted
## Context
複数サービスで認証実装が分散し、運用負荷とセキュリティリスクが増えている。
## Decision
認証基盤としてOIDCを採用し、各サービスは認証を外部IdPに委譲する。
## Consequences
- 利点：認証実装の重複を削減できる
- 欠点：IdP障害時の影響が大きくなる
- 必要対応：SLO、監視、障害時手順を整備する
ADRの価値は、完璧な設計書を作ることではない。
未来の会議を短くすることだ。
14. 原理13：AI時代のエンジニアは「コードを書く人」から「検証可能なシステムを設計する人」へ移る
AIはコードを書く。
しかし、AIは責任を持たない。
2025年のDORAは、AI-assisted software developmentを扱うレポートを公開し、AIが開発チームに与える影響を分析対象にしている。([Dora][21])
Thoughtworks Technology Radarは、AI支援の急速な進化を取り上げる一方、AIによって開発者ツールを作る障壁が下がり、非常に新しく評価困難なツールも増えていると指摘している。([Thoughtworks][22])
これは重要だ。
AIで作れるものが増えるほど、選ぶ力、捨てる力、検証する力が必要になる。
AI時代に残る仕事
| AIに寄せやすい | 人間が握るべき |
|---|---|
| 雛形コード生成 | 問題設定 |
| テストケース草案 | 品質基準 |
| リファクタ案 | 設計意図 |
| ドキュメント初稿 | 読者と判断目的 |
| UI部品生成 | 体験設計 |
| ライブラリ調査 | 採用判断とリスク評価 |
AI時代の最強エンジニアは、AIを使わない人ではない。
AIを使い倒しながら、AIの出力を検証可能な工程に閉じ込める人である。
AI coding workflowの実務ガードレール
1. AIに作らせる前に、受け入れ条件を書く
2. 生成物は小さくする
3. テストを先に用意する
4. 依存関係とライセンスを見る
5. セキュリティスキャンを通す
6. ADRに設計判断を残す
7. 本番後の観測ポイントを決める
AIは加速装置である。
ただし、ブレーキと計器がない車で加速すると、事故も速くなる。
15. 現場で使える「エンジニアリング判断OS」テンプレート
ここからが実務編。
以下は、そのままチームのNotion、GitHub Issue、Confluence、Qiita Teamに貼れる。
テンプレ1：Engineering Decision Canvas
# Engineering Decision Canvas
## 1. 解きたい問題
- 誰の、どんな痛みか
- 何ができるようになれば成功か
## 2. 現在の制約
- 技術制約
- 人員制約
- 時間制約
- セキュリティ制約
- 運用制約
## 3. 選択肢
A:
B:
C:
## 4. 比較軸
- リードタイム
- 運用負荷
- 認知負荷
- セキュリティ
- 可観測性
- 移行容易性
- 将来の変更容易性
## 5. 決定
選んだ案：
## 6. 捨てたもの
採用しなかった案と理由：
## 7. 検証方法
- 何を測るか
- いつ見直すか
- 失敗条件は何か
テンプレ2：週次Flowレビュー
# Weekly Flow Review
## 今週の完了
- 完了した変更：
- ユーザー価値：
## 詰まった場所
- レビュー待ち：
- QA待ち：
- 仕様確認待ち：
- リリース待ち：
## WIP
- 着手中：
- 滞留中：
- 止めるもの：
## 数字
- Lead Time：
- Deployment Frequency：
- Change Failure：
- Recovery Time：
## 来週の改善1つ
- 改善対象：
- 期待する変化：
- 測定方法：
テンプレ3：AI生成コードレビュー観点
# AI Generated Code Review Checklist
## 受け入れ条件
- 仕様を満たすか
- エッジケースを扱っているか
- 失敗時の挙動が明示されているか
## セキュリティ
- 入力検証があるか
- 権限が過大ではないか
- シークレットが混入していないか
- 依存関係に既知リスクがないか
## 保守性
- 命名がドメインに合っているか
- 不要に複雑ではないか
- テストしやすいか
- 既存設計と矛盾しないか
## 運用
- ログは十分か
- メトリクスは取れるか
- 障害時に切り戻せるか
- SLOに影響しないか
テンプレ4：SLO設計メモ
# SLO Design Memo
## ユーザーにとって重要な体験
例：検索結果が2秒以内に返る
## SLI
例：検索APIのp95 latency
## SLO
例：30日間でp95 latency 2秒以内が99.5%以上
## Error Budget
例：30日間で0.5%の失敗を許容
## 予算消費時の対応
- 新機能リリースを止める
- 信頼性改善を優先する
- 原因サービスを特定する
## 見直し周期
月1回
16. エンジニアリング原理原則チートシート
| 原理 | 一言 | 現場での問い |
|---|---|---|
| Littleの法則 | WIPが増えると遅くなる | いま何件が滞留しているか |
| DORA | 速さと安定性を同時に見る | 変更は何日で本番に届くか |
| SRE | 信頼性を測定可能にする | 何を何%守るのか |
| SPACE | 生産性は多面的 | 単一指標で歪めていないか |
| Cognitive Load | 頭の負荷も制約 | 誰が何を抱えすぎているか |
| Conway | 組織が設計に出る | チーム境界とサービス境界は合うか |
| Platform as Product | 基盤は内部プロダクト | 開発者は自走できるか |
| SSDF/OWASP | セキュリティは工程 | 設計時に脅威を見たか |
| Observability | 未知の故障に答える | なぜ壊れたか説明できるか |
| ADR | 判断を残す | 半年後に理由を説明できるか |
| AI Engineering | 生成より検証 | AI出力をどう検証するか |
17. ありがちなアンチパターン
アンチパターン1：稼働率100%信仰
全員が忙しいのに、リリースが遅い。
これは珍しくない。むしろ普通に起きる。
原因は、人の能力不足ではなく、バッファ不足とWIP過多である。
100%稼働の組織は、予期しない仕事が来るたびに詰まる。
アンチパターン2：マイクロサービスごっこ
サービスは分かれている。
でもDBは同じ。
デプロイは同じ人が手作業。
障害時は全員集合。
API契約は曖昧。
監視は足りない。
これはマイクロサービスではなく、分散された苦しみである。
アンチパターン3：Platform強制利用
Platform Teamが善意で共通基盤を作る。
しかし、利用者の仕事を見ていない。
結果として、開発者は「便利な道」ではなく「遠回りの関所」を通らされる。
Platformは、使えと言うものではない。
使った方が速く、安全で、楽になる状態を作るものだ。
アンチパターン4：AI出力をレビューなしで混ぜる
AIが書いたコードは、それっぽい。
それっぽいコードは怖い。
なぜなら、間違っていても読めてしまうからだ。
AI時代のレビューは、スタイルを見るだけでは足りない。
受け入れ条件、テスト、依存関係、権限、失敗時挙動まで見る必要がある。
18. 30日導入プラン：チームで原理原則を使い始める
Day 1〜7：測る
- 現在のリードタイムを測る
- PR滞留数を数える
- デプロイ頻度を見る
- 障害復旧時間を見る
- 手作業運用を洗い出す
- AI利用箇所を棚卸しする
Day 8〜14：減らす
- WIPを減らす
- PRサイズを小さくする
- レビュー観点を揃える
- 手動リリース手順を減らす
- よくある質問をドキュメント化する
Day 15〜21：設計する
- SLOを1つ決める
- ADRを1本書く
- AI生成コードレビュー基準を作る
- Platform化候補を1つ選ぶ
- チーム境界とサービス境界を見直す
Day 22〜30：運用する
- 週次Flowレビューを始める
- SLO違反時の判断を決める
- toilsを1つ自動化する
- Observabilityの不足を1つ埋める
- 1か月後にやめることを決める
重要なのは、全部やらないこと。
全部やろうとすると、またWIPが増える。
最初は1つでいい。流れを変える1点を狙う。
19. FAQ
Q1. エンジニアリング原理原則は、初心者にも必要ですか？
必要です。ただし、最初から全部覚える必要はありません。
初心者ほど「なぜレビューがあるのか」「なぜテストを書くのか」「なぜ小さく出すのか」を原理で理解すると、成長が速くなります。
Q2. DORA指標は小さいチームにも使えますか？
使えます。ただし、個人評価には使わない方がよいです。
小さいチームでは、厳密なベンチマークよりも、待ち時間や変更失敗の原因を見つける目的で使うのが現実的です。
Q3. マイクロサービスは避けた方がいいですか？
避けるべきではありません。雑に始めるべきではない、が正確です。
独立デプロイ、監視、チーム所有、API契約、障害分離の準備がないなら、まずモジュラーモノリスや境界整理から始めた方がよい場合があります。
Q4. AIコーディングで生産性は上がりますか？
上がる場面はあります。特に雛形生成、調査、テスト案、リファクタ案、ドキュメント初稿では効果が出やすい。
ただし、検証工程が弱いチームでは、生成量が増えるほどレビュー負荷や品質リスクも増えます。
Q5. Platform Engineeringは何人くらいから必要ですか？
人数だけでは決まりません。
同じ作業が複数チームで繰り返され、環境構築・権限・CI/CD・監視・デプロイで開発者が頻繁に詰まるなら、Platform的な発想が必要です。専任チームを作る前に、Golden Pathを1本作るだけでも効果があります。
Q6. SLOはどのサービスにも必要ですか？
全部に厳密なSLOを置く必要はありません。
まずは、ユーザー体験や事業影響が大きい機能から始めるのが現実的です。SLOは飾りではなく、リリース判断や障害対応の優先順位に使って初めて意味があります。
Q7. 生産性を測ると、エンジニアが嫌がりませんか？
測り方次第です。
人を評価するために測ると嫌がられます。システムを改善するために測るなら、むしろ助かります。SPACEのように多面的に見て、単一指標で人を裁かないことが重要です。
20. まとめ：AI時代に残るのは、原理で考えられるエンジニアである
AIはコードを書く。
ツールは毎月増える。
フレームワークは入れ替わる。
ベストプラクティスは、文脈が変わるとベストではなくなる。
それでも残るものがある。
- WIPを増やすと流れは遅くなる
- フィードバックが遅いと学習は遅くなる
- 認知負荷が高いと品質は落ちる
- 観測できないものは改善できない
- 組織構造はアーキテクチャににじむ
- 信頼性は感情ではなく、目標と予算で扱う
- セキュリティは後付けではなく工程に埋め込む
- AI出力は、検証設計なしでは負債にもなる
- 判断を残さない組織は、同じ議論を繰り返す
エンジニアリングとは、コードを書くことだけではない。
不確実な現実を、変更可能で、検証可能で、運用可能な形に変えることだ。
そして、強いエンジニアリング組織とは、強い個人の集まりではない。
速く学び、早く戻り、余計な負荷を減らし、判断を残し、壊れ方まで設計するチームである。
参考文献・出典
- DORA：ソフトウェアデリバリー性能と組織能力に関する長期研究プログラム。([Dora][1])
- DORA Metrics：Change lead time、Deployment frequency、Failed deployment recovery timeなどの定義。([Dora][2])
- Google SRE Book：SLO/SLIの定義。([Google SRE][4])
- Google SRE Book：Toil削減とSREの時間配分に関する考え方。([Google SRE][5])
- SPACE Framework：開発者生産性を5次元で捉えるモデル。([queue.acm.org][6])
- Agile Manifesto Principles：価値あるソフトウェアの早期・継続的提供。([agilemanifesto.org][3])
- Little, J.D.C. “A Proof for the Queuing Formula: L = λW”。([IDEAS/RePEc][23])
- Sweller, J. “Cognitive Load During Problem Solving”。([Wiley Online Library][7])
- Team Topologies Key Concepts。([チームトポロジーズ][8])
- Melvin Conway “How Do Committees Invent?”。([Mel Conway][9])
- Martin Fowler：Conway’s Lawの解説。([martinfowler.com][10])
- Martin Fowler / James Lewis：Microservicesの定義。([martinfowler.com][11])
- NIST SP 800-218 SSDF Version 1.1。([NISTコンピュータセキュリティリソースセンター][12])
- OWASP Top 10 2025。([OWASP Foundation][13])
- OWASP Top 10 2025 Introduction。([OWASP Foundation][14])
- OpenTelemetry公式。([OpenTelemetry][15])
- CNCF OpenTelemetry Graduation発表。([CNCF][16])
- CNCF Platforms White Paper。([tag-app-delivery.cncf.io][17])
- CNCF Platform Engineering Maturity Model。([cloudnativeplatforms.com][18])
- ADR GitHub：Architectural Decision Records。([Architectural Decision Records][19])
- Martin Fowler：Architecture Decision Record。([martinfowler.com][20])
- Stack Overflow Developer Survey 2025：AI利用状況。([Stack Overflow Insights][24])
- GitHub Octoverse 2025。([The GitHub Blog][25])
- Thoughtworks Technology Radar：AI支援開発とツール増加への言及。([Thoughtworks][22])
[1]: https://dora.dev/?utm_source=chatgpt.com "DORA | Get Better at Getting Better"
[2]: https://dora.dev/guides/dora-metrics/?utm_source=chatgpt.com "DORA's software delivery performance metrics"
[3]: https://agilemanifesto.org/principles.html?utm_source=chatgpt.com "Principles behind the Agile Manifesto"
[4]: https://sre.google/sre-book/service-level-objectives/?utm_source=chatgpt.com "Defining slo: service level objective meaning"
[5]: https://sre.google/sre-book/eliminating-toil/?utm_source=chatgpt.com "What is Toil in SRE: Understanding Its Impact"
[6]: https://queue.acm.org/detail.cfm?id=3454124&utm_source=chatgpt.com "The SPACE of Developer Productivity"
[7]: https://onlinelibrary.wiley.com/doi/10.1207/s15516709cog1202_4?utm_source=chatgpt.com "Cognitive Load During Problem Solving: Effects on Learning"
[8]: https://teamtopologies.com/key-concepts?utm_source=chatgpt.com "Key Concepts"
[9]: https://www.melconway.com/Home/Committees_Paper.html?utm_source=chatgpt.com "Committees Paper - Mel Conway's"
[10]: https://martinfowler.com/bliki/ConwaysLaw.html?utm_source=chatgpt.com "Conway's Law"
[11]: https://martinfowler.com/articles/microservices.html?utm_source=chatgpt.com "Microservices"
[12]: https://csrc.nist.gov/pubs/sp/800/218/final?utm_source=chatgpt.com "Secure Software Development Framework (SSDF) Version 1.1 ..."
[13]: https://owasp.org/www-project-top-ten/?utm_source=chatgpt.com "OWASP Top Ten Web Application Security Risks"
[14]: https://owasp.org/Top10/2025/0x00_2025-Introduction/?utm_source=chatgpt.com "Introduction - OWASP Top 10:2025"
[15]: https://opentelemetry.io/?utm_source=chatgpt.com "OpenTelemetry"
[16]: https://www.cncf.io/announcements/2026/05/21/cloud-native-computing-foundation-announces-opentelemetrys-graduation-solidifying-status-as-the-de-facto-observability-standard/?utm_source=chatgpt.com "The milestone for OpenTelemetry ..."
[17]: https://tag-app-delivery.cncf.io/whitepapers/platforms/?utm_source=chatgpt.com "CNCF Platforms White Paper"
[18]: https://cloudnativeplatforms.com/whitepapers/platform-eng-maturity-model/?utm_source=chatgpt.com "CNCF Platform Engineering Maturity Model"
[19]: https://adr.github.io/?utm_source=chatgpt.com "Architectural Decision Records (ADRs) | Architectural ..."
[20]: https://martinfowler.com/bliki/ArchitectureDecisionRecord.html?utm_source=chatgpt.com "Architecture Decision Record"
[21]: https://dora.dev/dora-report-2025/?utm_source=chatgpt.com "DORA | State of AI-assisted Software Development 2025"
[22]: https://www.thoughtworks.com/radar?utm_source=chatgpt.com "Technology Radar | Guide to technology landscape"
[23]: https://ideas.repec.org/a/inm/oropre/v9y1961i3p383-387.html?utm_source=chatgpt.com "A Proof for the Queuing Formula: L = (lambda) W"
[24]: https://survey.stackoverflow.co/2025/ai?utm_source=chatgpt.com "AI | 2025 Stack Overflow Developer Survey"
[25]: https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/?utm_source=chatgpt.com "Octoverse: A new developer joins GitHub every second as ..."