【読書log】エンタープライズアジャイル開発実践ガイド：実践編（Chapter8〜）

「アジャイル開発に関する書籍等を数冊読んで、知識やスキルの補強と向上を図ります！」の3冊目です！

構成管理やDevOpsは、先に参画されている方々が整備されたものに相乗りさせていただいているだけなので、今一度勉強し直したいです！

いつものように、私が特に勉強になったと思った内容と個人的な感想を、備忘録としてまとめています。

Chapter8 構成管理

私はSubversionの歴がかなり長く、ぬるっとGitに移行してしまいました。（一応CVSの経験者でもあります）。

そのため、Gitは何となく理解できている（ので業務が遂行できている）のですが、Subversionの概念が邪魔をしてしまったり単語が混ざってしまったりと、正確に理解しきれていない内容もあるなと思いました。

個人的な経験上、何となく使えてしまっている状態の方がいざという時に問題になりやすい傾向があるので、これを機にGitについて改めて勉強しなおします！

従来のように開発チームと運用チームに分かれている組織では、リリースに対する両者の利害が対立する。
- 価値を提供するための新しい機能をリリースしたい vs 安定稼働させるためにリリース回数を減らしたい
- しかし、本来は両チームともビジネス価値の高いソフトウェアをユーザーに届けたいという目的がある。
ツールと組織文化の両面から対応していく必要がある。
CI/CD/継続的デプロイは、組織やチームの文化やルールなどに基づいて、自動化する範囲を決定する。
DevOpsチームのような専門チームを新設することは、開発や運用を担当するメンバーのスキルや課題認識が無視されかねないので、注意が必要。
専門チームに分け過ぎてしまうと、利害の対立・ボトルネックの発生・組織のサイロ化などが発生しやすい。
- 大きなソフトウェアは、マイクロサービス化して、それぞれのサービスに開発から運用までを担当するチームを割り当てる。
- メンバーをマルチスキル化する。

経験が浅いもしくはほとんどないタスクに関しては、挑戦したい気持ちもありつつ他の人が担当した方がチームとしてのベロシティは安定するなと考えてしまいます。チームならびに自分に対して長い目で見た時には色々なノウハウを習得した方が良いので、少しずつ私ができる範囲を広げていきたいです！

特に、フロントエンド関連とTerraform関連のスキルは瀕死状態なので、先日に思い切って挑戦したいと伝えたところです笑

※ Conclusionの章も含みます。

インセプションデッキのプロジェクト計画書に対する利点
- プランニング段階でわかっている内容のみを記載して、わからない項目は後から記載するので、完了スピードが早い。
- チームメンバー全員で考えるので、メンバーの理解度が高い。
効果的なレトロスペクティブを実施するためには、チーム内の心理的安全性の確保が重要。
アジャイルは魔法の杖ではない。状況に応じて、一度に導入するのではなく、スモールステップで始めることが重要である。

何度も出てきますが、心理的安全性はやはり大事ですよね！

心理的安全性が全くないチームも過去に経験しているので、その大切さは痛感しています。自分も含めた皆が考えを言いやすいチームにできるように、自分の言動を日々向上させたいです。

また、そのために自分の心身のコンディションを常に良い状態に保つ努力も必要ですね！

広範囲を網羅していて、プロダクトオーナーから開発メンバーまで必ず参考になる内容があると思います！

一方で、本書のメリットの裏返しですが、自分の業務に関連が薄い内容がある方も多いと思うので、必要な章はピックアップして読み込み、その他の章はこんなこともあるんだなと軽く体を通しておく感じの読み方が良さそうです。

たまに誤字脱字がある（気がする）のが気になります。

アジャイル開発に関しては3冊読んで一旦満足したので、これらで得た知識を活用しつつ、また困ったら書籍に戻ってこようと思います！

リンク

以上