読書メモです。個人的には気づきも多く、考える材料をたくさんもらえた良書でした。
読んで思ったことを雑に書いていきます。

第1章イントロダクション

この本で何が書かれるかのおおよそのサマリが書いてあるのでざっと読んでおくと後半が頭に入ってきやすい。
工学についての論は読み飛ばしてもいいかも。

第2章工学とは何か

ここもざっくりで良さそうだが一個メモ

2.11 私たちがソフトウェア工学をしていない理由

SpaceXを例に取り、彼らには実験を行うにあたり合理的な理由を持っていることを説明している
- 材料選定におけるコストと品質のトレード (カーボン?アルミ?鉄鋼?)
我々がソフトウェアを作っていく上でこのような合理的な理由づけを常に行えているか？という提議
- では、どう考えれば良いのだろう？
  - 事前に設計する際に案をいくつか出す？
  - その際にどういう指標を持つべきかみたいなのが後半の章で出てくるのかも

第3章工学的アプローチの基礎

DevOpsの重要性など。「LeanとDevOpsの科学」を読んでおくと頭に入りやすい。

3.2 計測の重要性

安定性とスループットが重要で、それらは継続的デリバリーによって支えられる
それらは変更失敗率,エラー修復率という指標で計測可能
自分のチームでこれを計測しようと思ったどこ起点で測るのがいいのか？と考えると...
- 変更失敗率
  - QA時にエラーが発覚したら、遡ってどの実装が影響していたのかを調べるとかかなあ
  - 失敗「率」なので、前後30日間でのマージ数で↑の発生回数を割るとか？
- エラー修復時間
  - ↑の変更失敗から修正がマージされるまでの時間を測れば良さそう
    - なので、リリースサイクルを週次でなくすればこの指標は大きく改善される
      - これはどういうことなのかMiroとかで理想と実際を図示したい
    - hotfixも同様の計測でいいかも。QAがstg、hotfixはprodなので、結果的にエラー修復時間が長くなるはず

第4章反復的な作業

イテレーティブとインクリメンタルの違いについて語られている。
この辺雰囲気理解してたのが深まって良い。

4.1 反復的な作業の実践的な利点

バッチサイズの縮小はとても良いアプローチ。
一方で、「完成」までどのくらい時間がかかるかを知ろうとすると話がややこしくなる
- ですよねー。なので、時間とかストーリーポイントを測ろうとするのは割とナンセンスじゃね？って気持ちにもなってきた
- まだマシな計測指標として「デプロイ回数」はあり
  - ただこれも、変更単位を小さくすればいくらでも増やせると言える
  - それは基本的には良いことなんだけど、デプロイ=価値とは限らないので要注意
    - 価値が生まれるかもしれないサイクルを早くしているだけ
    - 本当にやらなきゃいけないのは価値を生むこと
CD = 1日に複数回本番デプロイすることと書かれているが弊チームはまだできていない
- この辺はどういう環境を作っていきたいのかメンバーで話してみたい

4.3 計画の誘惑

コラム無限の始まり
- 表意文字と象形文字の違いが面白い
- 転じてソフトウェアをどのように実装すべきか

第5章フィードバック

書いてあることは割と一般的なのでさらっと読むで良さそう。自分の組織にではどうか？を考えたい

5.4 設計に対するフィードバック

以下の指標が重要とのこと
厳密な運用になってなくてもいいが、PRの雛形にこれらを書いておくだけでもいいかも
- 実装した人が気にするだけで違ってくるのでは？という

5.7 製品設計に対するフィードバック

「プロダクトのアイデアを生み出してから本番システムに価値を届けるまででフィードバックループを閉じているところが継続的デリバリーの真価です」
- できてねえなあ...
- 少なくとも「お客様の声」ぐらいは実装しておいていいのかもなと思った
  - 今だとSalesが商談の場で聞くことしかできてない
    - それはそれは深ぼって聞けるからいんだけど
    - お客さん起点での発信の方がより強そう
    - あと、そもそも我々はどこでどういうFB拾ってるんだ？っていう可視化とかしてみたい

5.8 組織と文化に対するフィードバック

「プロセスやツールよりも個人と対話を」
- これは結構大事なところ
- 1on1もやってりゃいいって話でもないよなと最近思う
  - どういう視点でどういう会話をしてる？
  - ちゃんと話せないと逆にエンゲージメントは下がる
- 雑談とか、チーム内での意見交換の時間は取れているか？
GoogleDORAグループの話はちゃんと読んでなかったので時間とりたい

第6章漸進主義

コードを積み上げていく上での理想論を語った章という感じかなあ。
重要性はわかるが実践のイメージがつきにくかったかも。。。

6.4 コード変更が与える影響の最小化

ポートアンドアダプターパターン (ヘキサゴナルアーキテクチャ)
- これもどこまでやるかだよなあ
  - Railsみたいにやり方がある程度決め打ちになってる場合、テーブル分割をどうする？っていうのが戦略の肝になりそう

6.5 漸進的な設計

「簡単に変更できるような構造のコードを書くべき」
- それよく言われるけど簡単なものでもないよねっていう
- 各自それを頑張るのは当然として、それ以外にも策を持っておきたい
  - ここでの論の一つとして、「いらないものを作ったときに捨てれないと困る」っていうのがありそうなので、それを解決する視点とか
  - いったん作ったものを苦しんで使い続けるんじゃなくて、マイグレーションかけて新しく作り直すのを簡単にやる方法を考えとくみたいな
    - 例えばそのために月に一回サービス停止するタイミングをビジネスと握っておくみたいなことも手段の一つではないかと思った

第7章経験主義

予測を立てた上でちゃんと事実を確認しましょうねという話。
非機能要件の検討とかで重要かなと。
これもPRの雛形に何か書いておくといいかもしれない

第8章実験主義的であること

8.1 「実験主義的であるということ」とはどういう意味か

以下の4つの要素から学ぶことである
- フィードバック
  - 必ずフィードバックを得られるようにする、というのが大事
  - できてないよねー...
- 仮説
  - 評価しようと思っていることをはっきりさせる
  - 「データを集める」が先にくるのはNG
- 計測
  - 「成功」や「失敗」は何を意味するのか？
  - 評価の方法を明確にしておく
- 変数の管理
  - 実験から得られるものをはっきりさせるため、余計な変数をできる限り削り落としておく

8.4 計測

ここはだいぶ重要。というか自分達がどうあるのか考えさせらる。

「事実をデータに適合」させようとして自分を騙すのは簡単
- 特に事業開発や営業で起こりがちなこと
テスト開発などでカバレッジを上げるためにアサーションを減らした事例
- これはまあ極端な例だが、そもそもカバレッジあげることに本当に意味あるの？とかはどの現場でも自問自答した方がいい
遅延について、平均値ではなくて最大値をテストすべき、などなど
- 管理したい指標を見直す

第9章モジュラー性

コードをちゃんと分離させてインターフェイスに依存するようにしましょうね、という話。
図9-1,2,3は課題にしたいことは何か？が分かりやすくて良い。
べき論としては全く正しいんだけど、実際にこれをやろうとするとテストとか大変ではある...
プロジェクトの導入時点から「これでやっていくぞ」という指針を示して育てていくのが良さそう。
既に育ってしまったプロジェクトの場合は、気合を入れてここと向き合う誰かがいないと難しいかも。
(契約による設計、防衛的プログラミングなどが近い概念に当たりそう)

第10章凝集度

具体的なコードの踏み込んで解説がなされる章。

10.5 カップリングとの関係

AとBという2つのコード行があったとして、
- Aが変更されたからと言ってBも動作を変更しなければならない場合、それらは結合していると言える。
- Aの変更によってBが変更され、両方が新しい価値を追加することができるとき、凝集していると言える。
結合度が高い=問題があるではない点に注意する
- 多分、結合が必要な範囲をどういうスコープで閉じこめるかが大事なんだと思う

10.8 低凝集度のコスト

10.7の図を参考に、凝集度の落とし所について解説
- リーダブルコードのこれ版ほしいなーと思った
- デザインパターンと同じぐらい有用なものになりそう

11章関心の分離

ここでもコードが出てくるが、サンプルコード然としていて具体感がちょっと見えづらいなと。
この手の話でよく出てくる永続化するレイヤーの分離とかって世の大半のFW,ライブラリでは既に対応できていそうで、
もうちょっとアプリケーションロジックに寄ったとこでどう実装するの？みたいな例示あると本当は嬉しい。

11.2 本質的な複雑さと付随的な複雑さの分離

本質的な複雑さ =　システムが解決したい問題とそのビジネスロジック
付随的な複雑さ = 画面への表示の詳細、データの永続化、認証、クラスタリングなど
両者を同じところに置かないように注意する
- かつ、付随的な複雑さを以下に小さくしていくか (無視はできない)

12章情報隠蔽と抽象化

なぜ情報を隠蔽すべきなのっか？の掘り下げが素晴らしい。
変化しないソフトウェアは死んでいく。それを防ぐために、簡易に変更できるようにする設計が必要で、そのための隠蔽であると。

12.10 問題ドメインからの抽象化

イベントストーミング
- 以前にチーム内で取り組んでいたがこれは非常に良いワーク
- 同期する時間的なコストがすごくかかっちゃうのが難点
  - コロナ禍オンラインだったので、今ならリアルでもっとスムーズにやれるかもしれない

13章カップリングの管理

13.1 カップリングのコスト

「過度に疎結合」もコストはかかるが、「過度に蜜結合」よりも格段にコストは低い。ゆえに疎結合を目指すべき
- ですよねー

13.7 疎結合と関心の分離の違い

蜜結合だが関心の分離はできている
- 注文を処理するサービスと、注文そのものを格納するサービス
  - 注文の実装に変更があった場合両方を書き換える必要がある
  - 両者はお互いの挙動を知っている必要はない
疎結合だが関心の分離はできていない
- ある口座から別の口座に送金する
  - 出金するという実装と、入金するという実装は完全に別であるべき
  - が、両方のトランザクションが完了しなければ処理は完了しないためお互いを知る必要はある

14章工学分野のためのツール

DIとテスタビリティ、devopsの重要性について実装を交えて解説。
さらっと読むで良さそう

15章現代のソフトウェアエンジニア

15.2節で登場するOBAP vs BAPOの話が出てくる。
逆コンウェイ戦略がなぜ必要か？が自分の中で感覚的にはわかってもうまく説明できなかったんだけど、こういうことかと得心した。
https://www.linkedin.com/pulse/structure-eats-strategy-jan-bosch

全体通しての感想

「LeanとDevopsの科学」と内容は似ているが、別の視点やエピソードを持って語っているので、両方を読むのをお薦めしたいです。実際にこれを読んで実践していくのはEM, VPoEとかの立場の方々やスクラムマスターから彼らへの助言ということになりそう。

'フラットな組織'を公言している組織の人にこそ読んでほしい内容かもしれないですね。
雰囲気だけがフラットでは何もよくはならなくて、適切な組織構造の構築、何を起点に開発をドライブしていくのか？、戦略と戦術・それをリードするのは誰？みたいなとこを考えていきたくなる本かなあと思いました。