ソフトウェア開発における２つのパフォーマンス指標
安定性
行った作業の品質についての指標。
「これによって自分たちが作るソフトウェアの品質は高くなるか」
- 変更失敗率（Change Failure Rate）
変更によってプロセスの特定の地点でエラーが発生した割合 - エラー修復時間（Recovery Failure Time）
プロセスの特定の位置で起きたエラーから修復までにかかった時間
スループット
動作するソフトウェアという形でチームがアイデアをユーザーに送り届ける能力についての指標。
「これによって品質の高いソフトウェアを作る作業効率は上がるか」
- リードタイム（Lead Time）
「アイデア」を「動作するソフトウェア」に変える一行の変更にどれだけ時間がかかっているか。開発プロセスの効率性の指標。 - デプロイ頻度（Frequency）
変更はどれくらいの頻度で本番環境にデプロイされているか。変更ペースの指標。
ソフトウェア工学における2つの最重要スキル
学びのエキスパート
科学的な論理的思考スタイルを実践的に活用する。
具体的な行動様式は以下5つ。
- 反復的な作業
- 早くて高品質なフィードバック
- 漸進的な仕事の進め方
- 実験主義的であること
- 経験主義的であること
複雑さ管理のエキスパート
システムの複雑さに圧倒されないように、問題を切り分けながら複雑さを管理する。
具体的な要素は以下5つ。
- モジュラー性
- 凝縮度（一体性）
- 関心の分離
- 情報隠蔽/抽象化
- カップリング
反復的な作業
アジャイル開発における中心的な概念でもあるイテレーションについて。
ウォーターフォール的アプローチでは「十分に考えれば/仕事をすれば、最初から正しい結果が得られる」という前提からスタートする。この前提が成り立つことが滅多にないので、多くのウォーターフォール開発プロジェクトは苦戦を強いられることになる。
一方でアジャイル的アプローチでは「私たちは間違うことを避けられない」という前提からスタートする。そこで、失敗を許容可能な小サイズの仕事を実施してはフィードバックを受け、修正するというサイクルを繰り返す（学びのサイクル）。
この哲学はシステム開発に限らず、あらゆる仕事において役に立つものだと思う。
科学者は無知と疑いと不確実性を嫌というほど経験している。この経験こそ、何よりも重要なものだと私は思う。 ー リチャードファインマン
フィードバック
「私たちは間違うことを避けられない」という前提に立つので、間違いを早く検知するためのフィードバックを重要視する。
「フィードバックを重要視する」とは、開発テクニックの話（例：開発環境にリファクタリングツールを導入する）にとどまらず、アーキテクチャにまで好影響を与える観点である。
高品質なフィードバックを早く得られる仕組みを整えることによって、"フェイルファスト（早い段階で失敗せよ）"な開発プロセスを実現できる。
漸進主義
「私たちは間違うことを避けられない」という前提に立つので、間違えた時の爆発半径を最小限にとどめるために、少数の大きくてリスキーなステップではなく、多数の小さなステップで前進することを常に追求する。
問題の一つの部分を解くことを目的として、問題を小さな部分に分割する。そのメリットとして、個々のコンポーネントは単純になり、与えられた課題の解決に専念できるようになる。さらに個々のコンポーネントはテストしやすく、短期間でデプロイできるようになる。
理解の深まりと共に、後からコードを書き換え考え方を改める自由を確保できるように仕事を進めることは、工学として優れた仕事の基礎である。