ソフトウェア工学

概要
ソフトウェア工学とは何か
ソフトウェア開発の現実
要件定義
設計
アーキテクチャとの関係
実装規律
テスト
品質特性
保守と運用
技術的負債
見積もりと計画
スコープ・リスク・ステークホルダー管理
チーム開発とレビュー
変更管理と構成管理
継続的デリバリとDevOps
失敗パターン
現場で使う判断軸
ケーススタディ
DevOps Research and Assessment (DORA)
アジャイル宣言と価値観
ISO/IEC 25000 Software Product Quality Standards
Martin Fowlerの設計パターンとベストプラクティス
Google Cloudとの統合
ソフトウェア品質メトリクスの実装
まとめ
参考文献

概要

まず、この章の中心構造を図で確認します。細部に入る前に、どの概念がどこへつながるかをつかむための地図です。

flowchart LR A["要求"] --> B["設計"] B --> C["実装"] C --> D["テスト"] D --> E["リリース"] E --> F["運用"] F --> G["保守"] G --> A B --> H["品質特性"] D --> H F --> H

要件定義・設計・テスト・保守・品質・技術的負債をつなげる

ソフトウェア工学は、コードを書く技術だけではありません。何を作るかを定義し、どう壊れにくくし、どう長く育てるかを扱う学問です。

要点

ソフトウェア工学の中心は「よいコードを書くこと」だけではなく、「変更が続く現実の中で、壊れずに前へ進めること」です。要件、設計、テスト、保守、品質、チーム運営は分断せず一つの流れで見る方が実務に近いです。

この章で重視すること

設計をUMLの記号ではなく、変更への備えとして捉える
テストを品質保証の全部だと思わない
保守を後工程ではなく、最初から織り込む
技術的負債を感情論ではなく意思決定の問題として扱う
アプリケーションアーキテクチャ と重複せず、より工学全体の視点で整理する

ソフトウェア工学とは何か

ソフトウェア工学は、ソフトウェアを計画可能に作り、変更可能に保ち、継続的に価値を出すための知識体系です。

単なるプログラミングとの違いは、対象がコードそのものだけでなく、

要件
設計
プロセス
チーム
品質
保守

まで含むことです。

なぜ「工学」なのか

工学と呼ぶからには、再現性、トレードオフ、制約下での最適化を考えます。

時間は有限
人数も有限
品質要求は複数ある
変更は止まらない

この中で、毎回場当たり的に決めるのではなく、判断の型を持つことが工学的な態度です。

ソフトウェア開発の現実

現実の開発では、最初から仕様が完全に分かっていることはほとんどありません。

要件は変わる
人は入れ替わる
依存ライブラリは更新される
インフラも変わる
ビジネス側の優先順位も変わる

そのため、工学的に重要なのは「最初から完璧に設計すること」より、変更が来ても崩れにくい形を保つことです。

ウォーターフォール対アジャイル、で終わらせない

開発プロセスの議論はしばしば方法論の対立に見えますが、本質は次の問いです。

不確実性はどれくらい高いか
途中で学ぶ余地はあるか
リリースを刻めるか
検証をどれだけ早く回せるか

重要なのは流派ではなく、フィードバックをどれだけ早く、安く、正確に回せるかです。

要件定義

要件定義は「画面の項目を洗い出す作業」ではありません。何を達成したいのか、誰にとって何が価値かを明確にする工程です。

要件の種類

機能要件: 何ができるべきか
非機能要件: どの程度の性能、可用性、安全性が必要か
制約条件: 法規制、予算、期限、既存環境

よくある失敗

手段を要件だと思ってしまう
非機能要件を後回しにする
利害関係者ごとの成功条件が違うのに統合しない

要件定義で本当に決めること

要件定義で大事なのは「何を作るか」だけではなく、

何を作らないか
どこまでを今回のスコープにするか
何を後で検証するか

を明確にすることです。

ユーザーストーリーだけでは足りない

ユーザーストーリーは便利ですが、それだけでは

データ移行
障害時運用
権限管理
監査ログ

のような横断要件が抜けやすいです。

非機能要件を早く出す理由

性能、可用性、セキュリティ、可観測性は後からも足せますが、構造に食い込むことが多いです。後出しにすると、アーキテクチャ全体をやり直すことがあります。

設計

設計は、コードを書き始める前にすべてを図にすることではありません。どこを変わりやすい場所として扱い、どこを安定させるかを決めることです。

設計で見るべき観点

責務の分割
依存方向
データの境界
失敗時の振る舞い
テストしやすさ

良い設計の目安

変更理由がまとまっている
影響範囲が閉じている
境界が説明できる
例外系を無視していない

設計は未来の変更コストを下げる活動

設計の成果物は図そのものではなく、将来の変更に対する耐性です。

たとえば「料金計算ロジックが頻繁に変わる」と分かっているなら、その変化がUI、DB、外部APIにまで伝播しないように境界を作る必要があります。

凝集と結合

設計で古典的に重要なのは、高凝集・低結合です。

高凝集: 一つのモジュールの責務がまとまっている
低結合: 他モジュールへの依存が少なく、狭い

この2つは今でもかなり強い指針です。

設計レビューで見る観点

名前と責務は一致しているか
この境界は変更理由で切れているか
例外系や失敗時の流れは設計されているか
監視や運用の視点が入っているか

アーキテクチャとの関係

アーキテクチャは設計の中でも特に大きな決定です。モジュール分割、デプロイ単位、データ境界、チーム境界に影響します。

アプリケーションアーキテクチャ が扱うのは構造の選択ですが、ソフトウェア工学ではそれを

要件
テスト
運用
変更頻度

と結びつけて評価します。

アーキテクチャを早く決めすぎる危険

マイクロサービス、イベント駆動、CQRSのような構造は魅力的ですが、要件や組織の成熟度に合わないと負債になります。

アーキテクチャの選択は「かっこいい構成を選ぶこと」ではなく、

チーム境界
デプロイ頻度
障害許容度
データ整合性要求

に見合う構造を選ぶことです。

実装規律

実装規律は「きれいなコードを書く」以上の意味を持ちます。

命名
小さな関数
一貫したエラー処理
ログ方針
境界でのバリデーション

が崩れると、変更コストが跳ね上がります。

実装規律は個人技ではなくチーム規律

個人がきれいなコードを書くことより、チーム全体で一貫した書き方を維持することが大事です。

フォーマッタ
Linter
命名規約
例外処理方針
ログの粒度

を共有すると、コードレビューの摩擦も減ります。

境界で厳密に、中では簡潔に

入力境界で検証を厳密に行い、内部では仮定を少し強く置けるようにすると、コード全体の見通しがよくなります。

テスト

テストは単なるバグ検出ではなく、振る舞いの仕様化でもあります。

主な種類

単体テスト
結合テスト
E2Eテスト
性能テスト
セキュリティテスト
回帰テスト

テストの誤解

テスト件数が多ければ安心、ではない
E2Eだけでは不安定になる
単体テストだけでも不足する

重要なのは、どの層で何を保証するかの分担です。

テストピラミッド

よく知られた考え方として、テストピラミッドがあります。

下層: 単体テストを多く、速く
中層: 結合テストで境界を確認
上層: E2Eを少数に絞る

これはE2Eを否定する考え方ではなく、コストに応じて保証の置き場所を調整する発想です。

良いテストの条件

速い
独立している
意図が読める
壊れたとき原因が追いやすい

テストしにくい設計は、設計のシグナル

モックが大量に必要、環境依存が強い、状態初期化が長い、といったときは、実装だけでなく設計境界が悪い可能性があります。

プロダクトコードとテストコードの関係

テストコードは使い捨てではありません。長く保守される資産なので、

重複を減らす
ただし抽象化しすぎない
テスト名で意図を残す

ことが大切です。

品質特性

品質は「バグが少ないか」だけではありません。

代表的には次の観点があります。

正確性
保守性
可用性
性能効率
セキュリティ
可観測性
使いやすさ

非機能要件と品質特性は強く結びつきます。

ISO/IEC 25010では、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性といった品質特性で整理します。すべてを最大化するのではなく、サービスの目的に対してどの品質をどこまで必要とするかを明示することが重要です。

品質特性はしばしば衝突する

たとえば、

強い整合性を取ると性能が落ちる
セキュリティを高めると利便性が落ちる
可観測性を高めるとコストが増える

といった衝突があります。品質は単一指標ではなく、優先順位づけの問題です。

可観測性を品質の一部として扱う

現代では、壊れないこと以上に「壊れたとき早く分かること」が重要です。

ログ
メトリクス
トレース
アラート

を設計時点から考える必要があります。

保守と運用

ソフトウェアのコストの多くは保守で発生します。

保守には次があります。

不具合修正
仕様変更
性能改善
ライブラリ更新
監視と障害対応

書いた後が本番です。最初からログ、メトリクス、トレーシング、移行手順を考えておく必要があります。

保守の4分類

保守はよく次のように分けられます。

修正保守: バグ修正
適応保守: 環境変化への対応
完全化保守: 機能改善
予防保守: 将来問題を起こしにくくする改善

このうち予防保守は後回しにされやすいですが、長期コストに大きく効きます。

運用を後工程にしない

実際の障害では、コードの正しさだけでなく

デプロイ手順
ロールバック
feature flag
データ移行
インシデント時の権限

が重要になります。

技術的負債

技術的負債は「汚いコード」の別名ではありません。短期的利益のために将来コストを受け入れる意思決定です。

負債の例

十分なテストなしで急いで出す
境界が曖昧なまま機能追加を続ける
古い依存関係を放置する
ドキュメントと実装がずれる

問題になるのはいつか

変更のたびに影響範囲が読めない
障害時に原因が追えない
新メンバーの立ち上がりが遅い

負債は借りてよいが、記録しないのが危険

負債を取ること自体が悪ではありません。むしろ短期の価値を優先するために必要なこともあります。

危険なのは、

どこが暫定か分からない
なぜそうしたかが残っていない
返済条件が決まっていない

状態です。

負債返済のタイミング

大きな変更の前
障害が続いている領域
オンボーディング負荷が高い領域
依存更新が止まっている領域

では、返済効果が大きく出やすいです。

見積もりと計画

ソフトウェアの見積もりは難しいです。なぜなら、未知が多く、実装前に全部を正確に数えられないからです。

それでも見積もりが必要なら、

不確実性を明示する
スパイクを入れる
機能の粒度をそろえる
バッファを持つ

ことが大事です。

見積もりは約束ではなく予測

見積もりを契約のように扱うと、現場では嘘が増えます。必要なのは、

現時点の知識での予測
不確実性の幅
何が分かれば精度が上がるか

を共有することです。

バーンダウンよりリスクの見える化

計画管理では作業量だけでなく、

外部依存
技術的不確実性
データ準備
仕様未確定領域

を見える化した方が実務では効くことが多いです。

スコープ・リスク・ステークホルダー管理

ソフトウェア開発が難しくなる理由の多くは、コードそのものよりも

どこまで作るか
何が崩れる可能性があるか
誰の期待をどうそろえるか

が揺れ続けることにあります。

スコープを固定しすぎず、溶かしすぎない

スコープ管理で大切なのは、「全部やる」でも「何でも変える」でもなく、変更を扱える形にすることです。

今回必須のもの
あれば望ましいもの
今回はやらないもの

を分けておくと、後からの変更要求をさばきやすくなります。

特に期限が厳しい場面では、機能追加をそのまま積むより、

既存スコープの削減
後続リリースへの分割
検証用の簡易版への切替

のような調整が必要になります。

リスクは一覧化より更新頻度が大事

リスク管理は、立派な台帳を作ることより、変化に応じて見直されることが重要です。

見るべき典型は、

外部依存
キーパーソン依存
性能未検証
データ移行の不確実性
要件未確定
ベンダや他チーム待ち

です。

実務では、発生確率と影響度の掛け算だけでなく、「いつ気づけるか」「小さく試せるか」も重要です。早く露出できるリスクは、後半に爆発するリスクより扱いやすいです。

ステークホルダー調整は仕様調整でもある

現場では、利害関係者ごとに成功条件が違います。

利用部門は使いやすさを重視する
運用部門は安定性と手順を重視する
セキュリティ部門は統制と証跡を重視する
経営層は期限と費用対効果を重視する

この差を放置すると、「言われた通りに作ったのに評価されない」が起きます。ソフトウェア工学では、仕様の文書化だけでなく、期待値のすり合わせ自体が設計活動の一部です。

チーム開発とレビュー

レビューは誤り検出だけでなく、知識共有と設計整流の場です。

よいレビューの観点:

仕様意図に沿っているか
境界条件を見ているか
将来の変更を妨げないか
テストが意図を表しているか

レビューで見ない方がよいもの

ツールで自動化できる

フォーマット
import順
単純なlint

に人間の時間を使いすぎない方がよいです。レビューでは設計意図や境界条件に集中した方が価値が高いです。

チームの共有知識を増やす

属人化を減らすには、

設計判断をPRに残す
ADRを書く
変更理由をコミットに残す

といった活動が効きます。

変更管理と構成管理

ソフトウェアを壊れにくく育てるには、「誰がいつ何を変えたか」が追えることが大事です。これは単なる監査のためではなく、障害時の切り分けや安全なリリースのためでもあります。

変更管理で最低限ほしいもの

変更要求の起点が分かる
影響範囲を事前に確認する
レビューや承認の経路がある
本番反映の履歴が残る
問題時にロールバック手順がある

変更管理が弱いと、

いつの変更で壊れたか分からない
緊急対応がそのまま恒久化する
本番だけ設定が違う
責任が人に閉じる

といった問題が起きやすくなります。

構成管理の対象

構成管理はソースコードだけではありません。

アプリケーションコード
インフラ設定
データベースマイグレーション
環境変数や秘密情報の参照方式
監視設定
ドキュメントやrunbook

を含めて、どの環境で何が動いているかを説明できる状態にすることが重要です。

職務分掌と承認の考え方

すべてを厳密に分ける必要はありませんが、少なくとも

書いた人
レビューする人
本番反映を承認する人

が完全に一体化しすぎない方が、事故も不正も起きにくくなります。小さなチームでも、PRレビュー、branch protection、CIの必須化 のような軽い分離は十分効果があります。

証跡を残す場所

証跡は、あとから「正しさを説明する材料」です。

Issueやチケット
Pull Request
コミットメッセージ
ADR
デプロイ履歴
監査ログ

がつながっていると、障害対応でも振り返りでも強くなります。

継続的デリバリとDevOps

開発と運用を分断しないために、CI/CDと観測基盤が重要になります。

自動テスト
自動デプロイ
feature flag
rollback
canary release

は、速く出すためだけでなく、安全に出すための仕組みです。

CI/CDの本質

CI/CDはパイプラインを作ることではなく、「小さく出して早く戻す」ための能力です。

継続的インテグレーションでは、変更を小さく頻繁に統合し、自動ビルドと自動テストで統合問題を早く見つけます。ここで大切なのはツール名ではなく、mainlineが常に動く状態に近いこと、失敗したらすぐ直す文化、再現できるビルドです。

統合を日常化する

Martin FowlerのContinuous Integration解説では、CIの中心は「各メンバーが少なくとも毎日mainlineへ統合し、自動ビルドとテストで統合エラーを早く見つけること」として整理されています。これは単にCIサービスを導入することではありません。統合を特別なイベントにしないためのチーム規律です。

flowchart LR Small["小さな変更"] Local["ローカルでビルド・テスト"] Main["mainlineへ統合"] CI["CIで自動検証"] Fix["失敗したらすぐ直す"] Release["リリース可能な状態"] Small --> Local --> Main --> CI CI -->|成功| Release CI -->|失敗| Fix --> Small

観点	よい状態	危険な兆候
変更粒度	数時間から1日で統合できる	数週間の巨大ブランチが残る
ビルド	誰でも再現できる	「自分の環境では動く」が頻発する
テスト	主要な回帰を自動で検知する	手動確認に頼り、結果が人で変わる
mainline	常に次に出せる状態へ近い	壊れていても放置される
レビュー	小さく早く確認できる	レビュー待ちが長く、統合が遅れる

CI/CDは速度の話に見えますが、本質はリスク管理です。統合が遅いほど、問題の原因候補は増え、レビューも重くなり、リファクタリングも怖くなります。逆に、統合が日常化すると、設計改善、テスト追加、デプロイ改善を小さく積み上げられます。

トランクベース開発とフィーチャーブランチ

ブランチ戦略も宗教論ではなく、

統合頻度
テスト速度
リリース手法

との組み合わせで決まります。

DevOpsは役職名ではなく性質

開発と運用の壁を低くし、責任と観測をつなぐ考え方です。組織設計、権限、ツール、文化の全部に関わります。

失敗パターン

アーキテクチャだけ立派で実装規律が伴わない
テストが遅すぎて回らない
非機能要件を最後に考える
技術的負債の返済タイミングを持たない
運用担当が設計に入っていない

もう少し具体的な失敗例

モックだらけで結合不良に気づかない
権限設計を後回しにして全面改修になる
スキーマ変更のロールバックがなく本番で詰む
監視が弱く、障害検知より先にユーザーが気づく
非同期化したが可観測性がなく原因不明になる

現場で使う判断軸

日々の判断を支える簡易的な軸として、次の質問が有効です。

この変更で将来の変更は楽になるか、苦しくなるか
壊れたときに気づけるか
影響範囲を説明できるか
ロールバックできるか
この近道はあとで返済可能か

大きな方法論より、こうした小さな判断軸の積み重ねが品質を左右します。

ケーススタディ

ケース1: 仕様変更が多い料金計算

ECサービスで、料金計算ルールが毎月変わるとします。

ありがちな悪い形:

画面層に計算ロジックが散らばる
SQLに計算式が埋まる
テストが画面経由のE2Eに偏る

このとき重要なのは、

計算ルールを独立した境界に寄せる
入出力を固定し、中のルールだけ差し替えやすくする
ルール単位の単体テストを厚くする

ことです。

ケース2: 障害が起きるまで監視が弱い

サービス自体は動いているが、障害検知がユーザー報告頼みのケースです。

この状況では、コード品質だけでなく、

何を正常とみなすか
どのメトリクスで異常を知るか
どこでアラートを上げるか

が設計されていません。これは運用の問題であると同時に、設計の不足でもあります。

ケース3: マイクロサービス化したのに遅い

サービス分割後に開発速度がむしろ落ちることがあります。

よくある原因:

境界が業務責務でなく組織事情だけで切られている
テストとローカル再現が極端に重い
データ整合性の設計が弱い
observabilityが不足し、障害時に跨ぎ追跡できない

このケースでは、サービス数を増やしたこと自体より、分割の前提条件が足りていたかを見直す必要があります。

DevOps Research and Assessment (DORA)

DORA (DevOps Research and Assessment) メトリクスは、ソフトウェア配信パフォーマンスと組織の効果を測定するための科学的フレームワークです。Google Cloudが主導する年次調査に基づいています。

4つのキーメトリクス (dora.dev)

デプロイ頻度 (Deployment Frequency)
- 本番環境へのデプロイ回数（日単位、週単位、月単位、年単位）
- 高頻度デプロイ（1日複数回）が高パフォーマンスの指標
- 継続的デリバリー (CD) の成熟度を反映
リードタイム (Lead Time for Changes)
- コミットから本番環境への反映までの時間
- 短いリードタイム = 迅速な価値提供
- 目安：高パフォーマンス = 1日未満
Mean Time to Restore (MTTR)
- インシデント発生から復旧までの平均時間
- 低いMTTRは高い信頼性を示唆
- 目安：高パフォーマンス = 1時間以内
変更失敗率 (Change Failure Rate)
- 本番デプロイの失敗割合（ロールバックが必要な率）
- 低い失敗率 = 品質の高いデリバリー
- 目安：高パフォーマンス = 0-15%

パフォーマンスレベルの分類

メトリクス	Elite	High	Medium	Low
デプロイ頻度	複数回/日	週1回以上	月1回以上	月1回未満
リードタイム	1日未満	1-7日	1-6ヶ月	6ヶ月以上
MTTR	1時間未満	1-24時間	1-7日	7日以上
変更失敗率	0-15%	16-30%	31-45%	46%以上

参考: dora.dev では、毎年の調査結果と業界別ベンチマークを公開しています。

アジャイル宣言と価値観

Agile Manifestoは2001年に17名のソフトウェア開発者によって署名され、アジャイル開発の基本原則を定めました (agilemanifesto.org)。

4つの価値

プロセスとツール よりも 個人と相互作用
包括的なドキュメント よりも 動作するソフトウェア
契約交渉 よりも 顧客との協調
計画に従う よりも 変化への対応

12の原則

顧客満足度を最優先
要件の変更を歓迎
2週間～数ヶ月の短いイテレーション
ビジネス担当者と開発チームは日々協力
モチベーションの高いチームを信頼
対面でのコミュニケーション最適
動作するソフトウェアが進捗の最も重要な尺度
持続可能なペースを維持
技術的卓越性への絶え間ない注目
シンプルさ（不要な複雑さを回避）
自己組織化チームが最良の成果を生み出す
定期的な反省と改善

ISO/IEC 25000 Software Product Quality Standards

ISO 25000ファミリーは、ソフトウェア製品の品質を評価・管理するための国際標準です (iso25000.com)。

品質特性モデル (ISO/IEC 25010:2023)

ソフトウェア品質
├── 機能性 (Functional Suitability)
│   ├── 完全性 (Completeness)
│   ├── 正確性 (Correctness)
│   └── 適切性 (Appropriateness)
├── パフォーマンス効率性 (Performance Efficiency)
│   ├── 時間効率性
│   ├── リソース効率性
│   └── キャパシティ
├── 互換性 (Compatibility)
│   ├── 共存性 (Co-existence)
│   └── 相互運用性 (Interoperability)
├── ユーザビリティ (Usability)
│   ├── 認識可能性 (Recognizability)
│   ├── 学習性 (Learnability)
│   ├── 操作性 (Operability)
│   ├── ユーザーエラー保護
│   └── ユーザーインターフェース美学
├── 信頼性 (Reliability)
│   ├── 成熟性 (Maturity)
│   ├── 可用性 (Availability)
│   ├── 障害容認性 (Fault Tolerance)
│   └── 復旧可能性 (Recoverability)
├── セキュリティ (Security)
│   ├── 機密性 (Confidentiality)
│   ├── 完全性 (Integrity)
│   ├── 否認防止 (Non-repudiation)
│   ├── 説明責任性 (Accountability)
│   └── 認証 (Authenticity)
├── 保守性 (Maintainability)
│   ├── モジュール性 (Modularity)
│   ├── 再利用性 (Reusability)
│   ├── 分析性 (Analyzability)
│   ├── 修正性 (Modifiability)
│   └── テスト性 (Testability)
└── 移植性 (Portability)
    ├── 適応性 (Adaptability)
    ├── インストール性 (Installability)
    └── 置換可能性 (Replaceability)

品質メトリクス (ISO/IEC 25021:2023)

内部メトリクス（開発時に測定）:

コード複雑度（Cyclomatic Complexity）
テストカバレッジ率
コード重複率
静的解析脆弱性検出数

外部メトリクス（使用時に測定）:

システム障害率
MTTR（Mean Time To Recovery）
ユーザー満足度スコア

使用品質メトリクス（ビジネス視点）:

ユーザータスク完了率
ユーザーエラー率
ユーザー満足度

Martin Fowlerの設計パターンとベストプラクティス

Martin Fowlerの著作 (martinfowler.com) は、エンタープライズアプリケーション設計の実践的な知見をまとめています。

アーキテクチャ関連記事

Microservices Architecture:

各マイクロサービスは独立デプロイ可能
サービス間通信は明確に定義
チームごとの技術選択の自由度
デプロイ複雑性とオペレーション負荷の増加に注意

Continuous Integration / Continuous Deployment:

コード変更 → ビルド → 自動テスト → デプロイ
  |
  自動フィードバック

ビルド時間 < 10分が理想
テスト自動化率 > 80% が目安
フィーチャーフラグによるリスク軽減

Event Sourcing と CQRS:

イベントストアに全変更履歴を記録
Command Query Responsibility Segregation で読取最適化
監査可能性とイベントリプレイが可能

デザインパターンカタログ

クラシックなGoF 24パターンに加え、エンタープライズ向けパターン:

Repository: データアクセス抽象化
Dependency Injection: 依存性管理
Adapter: 既存システムとの統合
Strategy: アルゴリズムの切り替え
Observer: イベント駆動アーキテクチャ

Google Cloudとの統合

Google Cloudのソフトウェア工学サービス (cloud.google.com) は、DevOps、CI/CD、品質管理ツールを提供します。

主要サービス:

Cloud Build: マネージドCI/CDパイプライン
Cloud Deploy: デプロイオーケストレーション
Cloud Code: IDE統合開発環境
Artifact Registry: コンテナ・バイナリレジストリ
Cloud Trace / Debugger: 分散トレース・デバッグ

# Cloud Build configuration
steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/myapp', '.']
    
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/myapp']
    
  - name: 'gcr.io/cloud-builders/gke-deploy'
    args:
      - run
      - --filename=k8s/
      - --image=gcr.io/$PROJECT_ID/myapp
      - --location=us-central1
      - --cluster=production

ソフトウェア品質メトリクスの実装

実務で追跡すべきメトリクス:

テストメトリクス
- ユニットテストカバレッジ: >= 80%
- 統合テスト通過率: 100%
- 回帰テスト実行時間: < 30分
デプロイメトリクス
- デプロイ失敗率: < 5%
- ロールバック率: < 2%
- 平均デプロイ時間: < 1時間
可観測性メトリクス
- エラーレート: < 0.1%
- レイテンシ（p99）: < 500ms
- 可用性: >= 99.9%
技術負債メトリクス
- 重大な脆弱性検出数: 0
- Cyclomatic Complexity平均: < 15
- テクニカルデビット比率: < 10%

まとめ

ソフトウェア工学は、要件定義から保守までを分断せずに扱うための考え方です。設計、実装、テスト、運用、品質、技術的負債を一本の流れとして捉えることが、実務でぶれない土台になります。