読書メモ。2025年46冊目。
『KAG Tech Book -Vol1-』を読んでの感想となります。（2025/6/20記載）
本の概要
本書は、KDDIアジャイル開発センター株式会社（通称KAG：カグと呼ばれます）で日々、システム開発に向き合っているメンバーたちの有志によって執筆されました。
それぞれが異なる現場やプロダクトに携わる中で得た経験や知見を持ち寄り、チームとしての実践や学びを一冊にまとめたものです。
そのため、本書に収められている内容は一つの視点にとどまらず、多種多様なアプローチや考え方が織り交ぜられています。
どこかの章が、いま皆さんが直面している課題や、これから取り組もうとしている挑戦のヒントとなれば、これ以上嬉しいことはありません。
読者の皆さまにとって、本書が新たな気づきや前向きな一歩につながることを願っています。
引用：
動機
-
アジャイル開発の実践的な話をもっと知りたい。
-
KAGの方の発信に恩恵を受けております。
-
技術書典オフラインで無事にゲット出来ました！！
感想
アジャイルを社名に掲げるKDDIアジャイル開発センターの方々が執筆したというだけで、濃厚すぎる学びを味わえるのではないかと楽しみにしていました。
中でも、私にとって監視を捉え直すきっかけとなった北浦さんも執筆に加わっており、読む前から強い期待がありました。
結果、多岐にわたる内容により、自分の知識の薄い部分については純粋な学びとなり、既存のプラクティスや役割を捉え直しチームでの学びや変化を考え直すきっかけにもなりました。
また、生成AIによるアプリケーション開発が扱われていることも印象的で、今時点での情報を整理して理解することができました。
値段で価値を測るのは適切ではないかもしれませんが、これが無料は凄すぎます。
忘れたくないメモ
エモーショナルレトロスペクティブ入門
認知の4点セット
チームのふりかえりにおいても同様で、作業計画や成果物について「良い」「悪い」という意見の奥には、それぞれの感情や価値観があります。だからこそ、 表面的な意見だけでなく、その裏にある感情をふりかえり、共有することが大切なのです。感情を共有することで、チームメンバー同士の理解が深まり、より良いコミュニケーションと協力関係が生まれていきます。チームの感情を育てるために、個々人の感情を丁寧に扱う必要があると学びました。
そのうえで、認知を「意見」「経験」「感情」「価値観」に切り分けることで、盲目的な直情の衝動からも逃れられる気がします。
ファシリテーターの重要性を改めて感じます。
共有メンタルモデル
チーム開発における阿吽の呼吸の難しさを感じています。共有メンタルモデルとは、チームメンバーが共通して持っている理解や知識、そしてそれに対する考え方のことです。もともとは心理学の分野で個人の理解を表す概念でしたが、チーム全体に広げた考え方として発展しました。研究によれば、共有メンタルモデルが充実しているチームほど高いパフォーマンスを示します。これは、メンバー間で共通理解があることで「ダイアログ(対話)なしに互いの考えや行動を予測し合える」ためです。メンバーが同じ方向を向いていれば、頻繁な確認や話し合いがなくても一貫した行動が取れ、チーム全体の効率が向上します。この共有メンタルモデルを育てるためには、以下が重要と言われています。
私たちはコミュニケーションを通してお互いの状況を知りますが、コミュニケーションの頻度が高ければ高いほどお互いのことを分かっていない状態なんだと思っています。
お互いのことを知るのは必要ですが、お互いのタスク状況の細かい部分を知りたいと思う気持ちはマイクロマネジメントに偏っていき、結果チームとしての行動を阻害する形になると思います。
本書では、共有メンタルモデルを築くための方法として、活発な話し合い、情報や知識の共有、役割や責任を明確にすることを挙げています。
自己組織化はチームに集まった個々人で必要な行動を実現できることでは無いと最近気づきました。
我々はお互いのことを知り、チームとしての認知を作ることで、阿吽の呼吸で動ける状態を目指す必要があるのだと思います。
Tryを出さない
過去、スクラムマスターを務めた時のふりかえりを思い出し猛省しました。ふりかえりの効果は、次のTryを見つけることだけではありません。 むしろ、「Tryを出す」ことだけを目的にしてしまうと、以下のような弊害が生じる可能性があります:
1. 本当の課題ではなく、Tryから逆算して「解決しやすい問題」だけを取り上げてしまう
2. 日常の些細な気づきや感情を共有する機会が減り、前述した共有メンタルモデルの形成が阻害される
3. その場で解決策を出せない複雑な問題が議論から除外されてしまう特に感情を共有するふりかえりでは、「気づき」や「理解」そのものに価値があります。メンバー同士がお互いの考えや感情を知ることで、日々のコミュニケーションがスムーズになり、長期的にはより大きな効果をもたらすことがあります。
個人の経験からその状況で必要と思えるTryを出し、チームでそこに向かうように推進していました。
自己組織化やスクラムの思想とは離れた行動だったと反省しています。
そうではなく、チームでTryを考える必要があり、それがチームのストレスを解消する安易な解決策に偏りそうな場合は、止める必要があったのだとも思っています。
うめき声ゾーンをチームで体験することでメンタルモデルが醸成されると思います。
本書を通じて、先日のふりかえりカンファレンスで得た学びの解像度があがりました。
スクラムにSREを取り入れるにはどうすればいいか？
ユーザーが信頼性を決める
SREでは、「監視が信頼性を決めるのではない。ユーザーが決めるのだ」という原則があります。つまり、システムが要求される信頼性をユーザー視点で具体的かつ測定可能な形で定義し、その目標を明確にします。SLO (Service Level Objective)はその手段の一つであり、信頼性の目標を設定することで、開発チームと運用チームが共通の認識を持ちながら、リスクとスピードのバランスを適切に判断できるようになります。手段の目的化を防ぐ。
特に監視を開発チームが実施すると機能を作ることとは別の営みとなるため、目的を忘れがちな気がします。
暗黙知やロジックの背景の共有
若干、書籍の文脈からの切り抜きにはなりますが、個々人のなかに暗黙知やロジックの背景が埋もれることに悩んでいたため、改めてチーム内でのコミュニケーションが必要であると理解しました。・コードレビューや相談を通じて、暗黙知やロジックの背景が共有される
こうした日常の働きかけによって、開発者は徐々に「全体像を見渡せる力」 を獲得していきます。フルスタックである必要はなく、むしろチーム全体でお互いを支え合いながら、自然にゼネラリスト的な力を育てていく環境を整えることが大切なのです。
チームで信頼性を捉えるために
チームで指標を眺めて会話をすることで、信頼性に対してチームとしての認識を作ることができるイメージができました。おすすめのアプローチは、1スプリントに1回、オブザーバビリティにフォーカスした“パフォーマンス定点観測会”を開催することです。1時間という短いタイムボックスを設け、事前に定めたメトリクス、たとえば「平均レスポンスタイム」「5**エラー数」 「リクエスト成功率」などをチームで一緒に眺めてみましょう。
この観測会の目的は、原因究明やアラート設定といった“対処”をすぐに行うことではなく、チームとして今のシステム状態を共通の言語で認識し、信頼性に関する感度を高めることです。
現状、スプリントごとに担当者を変えてローテーションして実施していますが、それだと共通の認識は持ちづらいと感じていたため、参考にしたいと思いました。
ピープルマネジメントの基本
Iメッセージ
相手を批判したり命令するのではなく、I(アイ) メッセージとして、その行動によって自分がどう感じたかを伝えることで、相手を尊重しつつ建設的なコミュニケーションが可能となります。マネジメントを行う上でIメッセージは常に心がけていたいです。
会議の冒頭に瞑想を行う
リソース効率に陥りがちな営みを意識してゆとりを作る重要性を感じました。これは、"瞑想する = この時間にゆとりがある"と感じてもらえたからではないかと考えています。「大勢のメンバーがいる中、皆が忙しい中、こんな話をしていいのか？」という不安が軽減したのではないかと考えています。
そこから私は、「時間にゆとりがある。安全である。安心して話を切り出せる」 と感じてもらうことで、素晴らしいアイデアが生まれたり、議論や対話が活発になったり、問題が大きくなる前の兆し、火が上がる前の情報を集めることができると考えるようになりました。
アイスブレイクとかも意図して扱いたいです。
