本書で心から伝えたいことは２つだけだ。「権限を与えること」「信頼すること」。

拠点の異なる複数チームが協働する場合、組織全体をつなぐ、明快でオープンなコミュニケーションチャネルが必要になる。

スタートアップのプロダクト開発ではひたすらイテレーションを重ねる。プロダクトを一度だけ構築して勝利を宣言するのではなく、計測、分析、テストの結果から得られた知見をプロダクトに何度も何度もフィードバックする。

アーキテクチャ評価ワークショップの目標は、アーキテクチャを評価するのに必要なデータを集めて分析することだ。ワークショップの終わりまでに、アーキテクチャが望ましい品質特性やその他のASRをどれだけ満たしているかを確認できている必要がある。

アーキテクティングの最終的な成果は、ビジネスおよびステークホルダーの目標を満たすシステムを設計して実装することだ。

品質特性という観点では、ただ一つの正しい設計や誤った設計というものは滅多にない。望んでいるシステム特性に対して良い設計か悪い設計かがあるだけだ。

アーキテクチャを形にする最も一般的な方法は、モデルを作成することだ。

“Model という概念があるから何かを Model と呼んでデータをつっこまなきゃいけない気になるけど、React ではカプセル化されたコンポーネントをベースとしてそれに必要なデータが宣言的に取得されるようにしておけば、Model というデータの抽象化が必要かどうかというのは本質的な議論にならないのよ。”

アジャイルとリーンには共通の価値があるため親戚のように見なせるが、その起源は異なっている。リーンは製造業から生まれ、アジャイルはソフトウェア開発から誕生したのだ。お互いの原則は相性が良くて、適用できる範囲も幅広い。

「開発準備OK」ステージは、基本的に「このステージには、エピックからの分割と見積りが行われており、要求の内容が明確になった機能が集まっているが、どの順番で開発を行うかまではまだ決定していない」という意味を持っている。

プロセス改善ワークショップとは、それぞれの機能開発チーム、要求分析チーム、テストチームといった、担当チームから１人ずつ代表者が集まるスクラムオブスクラム形式で実施するふりかえりだ。

プレイバック効果、すなわち想起性は、脳内検索性ともいえます。（……）マインドマップは、過去の経験や記憶を、脳内検索するとっかかりとなることができます。

マインドマップはすべての線が「連想」という糸でつながった１つの意味であり、あいまいであることが、逆にスピードを生み、発送の柔軟性を引き出しているのです（速記性、容易性）。

緩やかな形でもよいので一度マインドマップの形として情報を表現することができれば、これをドメイン分析モデルに変換することは、生の情報から直接ドメイン分析モデルを生成することに比べてはるかに容易です。

バーンダウンチャートとは、作業の進捗報告を見える化するツールです。

合意と同意は異なります。主責任者を決めて、その人に丸投げしてしまい、その人が困っていたとしても周りが助けないというのは、合意ではありません。合意とは、同意に加えて「全面的にサポートするという意思」まで含んでいます。

KPTとは、ふりかえるのに適した思考フレームワーク（視点）で、「Keep」「Problem」「Try」という３つの単語の先頭文字をつなげたものです。（「けぷと」と呼びます）

アジャイルプロジェクトでは、生み出され続ける機能と知識の流れが、仕事を進めていく指針となる。

「リリース」という大まかなゴールに対する進捗をトラッキングすることに加えて、個々のイテレーションの作業を完了するという、身近なゴールに対する進捗もトラッキングする価値がある。この20章では個々のイテレーションのトラッキングに使う２つのツールを紹介する。タスクボードとイテレーションバーンダウンチャートだ。

ベロシティを予測する理想的な方法は、実際に１回、イテレーションを実施してしまうことだ（１回に限らず、２回でも３回でも構わないが）。そして、実施したイテレーションのベロシティをもとに、今後のベロシティを見積もるのだ。ベロシティを知る最もよい方法は実際に測ることなのだから、まずはこの方法を採用すべきである。