本書の中で気になったことをいくつかまとめておきます。

経験主義、仮説思考

PDCAのような感じですね。問題解決になりそうな案が浮かんだらまずやってみる。その後検証し、うまくいってもいかなくても、なぜその結果になったのかを考えて次の行動に移す。それを繰り返す。
やってみなければ分からないことってたくさんあるし、経験したこと（特に失敗したこと）って記憶に定着しやすいという実感もあります。検証を重ねていくことで、個人にもチームにも知識が蓄積されていく思ってます。スクラムの各サイクルも、経験主義を軸にしているようですね。

考えるための材料は観測できるもの

他者が何を考えているか、本当のところは分からないけれど、他者の行動した結果なら分かります。数値に落とし込まれていると、より考えやすい（測ることができる）と思います。何を何分でどれくらいやったか、みたいな。
仮説思考でもコミュニケーションでも、観測できるものなら考えようがありますが、そうでないならどれほど考えても答えが出ない可能性もあります。

問題認知

「視野・視座・視点」やリフレーミングなど、いつもの自分とは違った考え方を意識してみると、新しい問題に気づけるような気がします。そのために、自分では気づいていない自分のことを知る必要があるかもしれません。エンジニアであれば評価制度のある会社は多いと思いますが、他者からの評価（フィードバック）が良い機会になりそうです。対話の重要性について、改めて気づかされました。

不安の可視化

不安を見えるようにするという考えが書かれていたことにちょっと衝撃でした。不安になるのは、わからないことが多いから。目に見える形であれば考えやすくなるので、例えばバッファのとり方も、タスク毎ではなく、全体で大きめのバッファにするとか。見積もりの精度も上げていきたいので、バッファ無しの見積もりと実績で検証した方が良さそうな気もします。
開発中に不安になることも多々あるので、何かしら形に出来ないか考えるようにしてみようと思います。

まとめ

プロジェクトを進める上で不安なことやモヤモヤ、分からないことなどは、情報として形にしていけば、建設的に考えられるようになりそうだなと感じました。分からないことを掘り下げて、分かるレベルの情報にする。そのために知っておくべきことが多く書かれているので、何度も読み返して定着させていきたいです。