メソッドにも命名原則があります。こちらの原則は「メソッド名の長さはメソッドが呼び出される回数に反比例する」です。

繰り返しますが、大切なのはスクラムかSpotifyモデルかというプラクティスではありません。重要なのはプラクティスを支える原則や、それを生み出す価値観のあり方、すなわち文化です。「文化が重要」なのです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まずは数多くTryを出すようにしましょう。突拍子もないような改善策や、些細な改善策、実効性のない改善策を挙げていけば、数を増やせます。その中から、素晴らしい改善案が出るかもしれません。

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