前書き
全体を通しての感想
読んだ本
Googleのソフトウェアエンジニアリング
―持続可能なプログラミングを支える技術、文化、プロセス
https://www.oreilly.co.jp/books/9784873119656/
ソフトウェアエンジニアリングについて、その定義からうまく実行するために必要な文化、プロセス、ツールといった内容についてGoogle社での実際の事例をもとに書かれた本で、とても良い本でした。
かなり分厚く読むのが大変な本ですが、それに見合った学びが得られる内容が記載されていると思います。
特に文化、プロセスについて優秀な集団が多くの年月をかけて実験や失敗を繰り返して醸成し、磨き上げてきたものであることが感じられる内容です。
自社でのやり方と比較したり、これから先直面するであろう問題を既に経験した先人の知恵として得られます。
これから自社内でCI/CDの仕組みを構築したり、プロセスを策定したりする際に辞書的に参照し活用していきたいと思っています。
この記事について
かなり分厚い本であるため、以下のように感じています。
- 単純に分量が多いためすべてに対して感想を一気に書ききるのが難しい
- 流し読みをした部分や情報量が多く頭に入りきっていない部分がある
- 実践的な内容なので問題に直面して実感することで感じることが変わりそう
そのため章ごとに感想を書いていきます。
この記事は1章「ソフトウェアエンジニアリングとは何か」の感想です。
感想
1章 ソフトウェアエンジニアリングとは何か の感想
まず第1章がこのソフトウェアエンジニアリングとは何か、という問いである点がこの書籍が素晴らしい書籍であることを表していると感じます。
「プログラミング」は単にコードを生産する活動、「ソフトウェアエンジニアリング」は生産したコードを稼働期間中に保守するためにプログラミングを拡張する活動。
両者ではコードの稼働期間が全く異なる。
稼働期間の違いによって、
- コードを書いたことによる価値
- コードにを書くにあたって直面する制約
- コードを書くためのベストプラクティス
が全く異なる。
稼働期間が長いと、
- ビジネス要件が変化する
- 提供する機能も増えていく（かもしれない）
- 依存するOS、ミドルウェア、ライブラリ、他のアプリケーションが変化する
- ソフトウェアを保守する人間が変化する
ほとんどのプロジェクトは無期限の継続を前提に運営されなければならない。
変化しないことを選択することはできるが、変化できないことはプロジェクトの継続において致命的なリスクになり得る。
依存する他のソフトウェアが変化するように、自身が保守するソフトウェアも変化を強いられる。
その時どのように変化していくのかを決定していくためにスケールするポリシーが必要である。
ぽつりぽつりと、しかし確かな関連性を持って綴られる各事例は
ソフトウェアを保守する上で体感し続けてきた難しさを言語化してくれていると感じました。
特に印象に残った内容
Hyrumの法則とBeyonceルール
Hyrumの法則：
あるAPIに十分な数のユーザーがいる場合、APIを作った者自身が明示した仕様として何を約束しているかは重要ではない。
システムが持つあらゆる観測可能な挙動について、それに依存するユーザーが出てくる。
これは放っておくとAPIを開発している人があらゆる利用者の利用方法を担保しなければいけなくなることを示していますが、それに対して
Beyonceルール：
製品がインフラストラクチャーの変更の結果として障害やほかの問題に陥った場合、問題がCIでのテストで表面化しなかったのならば、インフラストラクチャーの変更に落ち度はない。とするポリシー。
を定めて責任範囲を明確にし、一つの現実的に可能な運用を示してくれていると感じました。
徹底したデータ駆動での意思決定
書けなくなったり無くなってしまうホワイトボードマーカーによってミーティングの思考が寸断されてしまうことを防ぐために、あらゆる場所に十分な量のホワイトボードマーカーを置く、という簡単な事例と
開発者のローカル端末で頻発するビルド待ち時間を解消するために、大きなコスト（開発コスト、運用コスト、利用者教育コスト）を支払って自社用の分散ビルドシステムを開発した事例が挙げられ、それぞれの背景には徹底したデータ駆動の意思決定があるという点が記載されていた。
特に後者では、運用後今までエンジニア個人がビルドにかかるリソース消費を抑えようという前提で行動していた共通のインセンティブが失われ、分散ビルドにおける浪費が横行するようになり予想以上のコストがかかったといった話が記されていた。
継続してデータを取り続けることによって決定を再考すること、間違いが起きる（時間経過によって間違いとなる）前提であることの重要性が記載されていた。
表層的な施策ではなく、データ駆動での意思決定という本質的な取り組みを踏まえた上で自分たちの取り組みに取り入れなければいけないと感じた。
まとめ
- ソフトウェアエンジニアリングは難しい
- ソフトウェアエンジニアリングとプログラミングは違う
- ソフトウェアエンジニアリングを継続するには「良い状態のコードセット」も「文化を維持するポリシー」も「それらを支える周辺の仕組み」も全てが重要である
といったことを強く感じました。
2章の感想につづく。