はじめに
ソフトウェア工学（Software Engineering）という学問があります。ソフトウェアに関して、開発・運用・保守に有用なプロセスを見出す学問で、生産性・信頼性・保守性などの向上を目指しています。しかし、領域の本質的な難しさもあってか、あまり上手く行っているようには見えません。正確な要求仕様 やそれに基づく 正確な見積り など市場のニーズ極めて高いという状況はありつつ、未だに見積りはKKD法だったりしますし、PMBOKをどれだけ読んでもソフトウェア開発が上手くいく感じがありません。PMBOKって、どちらかというと、ここまで頑張ったから失敗しても仕方ないよね、という言い訳づくりの印象しかありません…。
結局、前提となるシステム開発工程モデル（ウォーターフォール）をベースとした開発手法自体が否定されつつあり、逆に、仕様は確定しない、初期に無理に見積もらない、というアジャイル開発スタイルに世の中がシフトしていくと理解しています。
では、ソフトウェア工学という学問は消滅するのか？ といえば、それは違います。ソフトウェア構築で最も成功しているGoogleがその内情を紹介してくれています。それが現代で生きている真のソフトウェア工学なのです。全６３２ページ。今季紹介した書籍で２番目の厚みです。よくわからない迷走(
ポイント
１章 ソフトウェアエンジニアリングとはなにか
- 寿命の長いコードの稼働時間は、短命なコードの稼働時間の少なくとも１０万倍はある。その両方に同じベストプラクティスが普遍的に適用できるろ仮定するのは馬鹿げている。
２章 チームでうまく仕事をするには
- 隠蔽は有害
- 社会交流の三本柱 「謙虚」、「尊敬」、「信頼」
- チームや大規模組織の一員として効果的に仕事をしたいなら、自分の好む働き方のスタイルと、他者の好む働き方のスタイルについて認識せよ。
３章 知識共有
- 心理的安全性は学びの環境を促進する上で決定的に重要である。知識共有の環境を育む際の基盤である。
- 小さなことから始めよ。つまり、質問をすること。物事を書き留めることだ。
- 人間の専門家とドキュメントの両方から、必要な助けを簡単に得られるようにすべきである。
４章 公正のためのエンジニアリング
５章 チームリーダ入門
- マネージャーとテックリード
- サーヴァントリーダシップ
- アンチパターン ６つ
- 建設的パターン ８つ
- チームを率いるのは、ソフトウェアエンジニアリングとは異なるタスクである。結果として、優れたソフトウェアエンジニアリンアは必ずしも優秀なマネージャーとはならず、それで問題ない。
- 伝統的な意味での「管理」は行うな。リーダシップ、影響力、チームに仕えることに集中せよ。
- DIYは行うな。移譲せよ。
- チームの着眼点、方向、速度に特に注意を払え。
- いつでも立ち去れ：リーダとしての仕事は、時間の経過とともに、自分が居合わせる必要なしに曖昧な部類の問題を自動的に解決する組織・チームを構築することである。
６章 スケールするリーダ
- 「重要」対「緊急」
私にとっては問題が２種類あり、それは緊急なものと重要なものである。
緊急なものは重要ではなく、そして重要なものは絶対緊急ではない。
７章 エンジニアリング生産性の計測
- トリアージ：そもそも計測するほどの価値があるのか
- 生産性を計測する前に、結果が肯定的・否定的にかかわらず、結果が行動可能かを問うべきだ。結果に対してなにもできないならば、計測の価値はおそらくない。
- 意味のあるメトリックスを選べ。GSMフレームワーク
- 生産性の全要素を対象とするメトリックスを選択せよ。QUANTS。開発速度や品質を落とすことになることを防げる。
- 定性的メトリックスもまたメトリックスである。定性的メトリックスの結果が定量的なメトリックスと整合性が取れていることを確認せよ。整合しない場合は、誤っているのはおそらく定量的メトリックスの方である。
８章 スタイルガイドとルール
- ルールの強制は自動化せよ。
- 一貫性が鍵。
９章 コードレビュー
- 変更を小さくすること、高速なフィードバックと反復が、ベストプラクティス。
- プロフェッショナルな姿勢を維持しつつ、批判的フィードバックの機会を提供せよ。
- プロセスの自動化が決定的に重要。
１０章 ドキュメンテーション
- 長期的かつスケールの観点からみて、極めて重要である。
- ドキュメンテーションの変更は、開発者のワークフローに組み込む。
- １つの目的に専念したドキュメントとする。
- ドキュメンテーションは対象読者に向けて書くべき。自分のためではない。
１１章 テスト概観
- コードカバレッジの問題は、それ自体がゴール化してしまうことである。
- 自動テストは、ソフトウェアの変化を可能とするための基盤である。
- テストは自動化されなければならない。
- 組織内のテスト文化を変えるには時間がかかる。
１２章 ユニットテスト
- テストコードは明確・簡素にする。DRY原則を適用してはダメ。説明からわかりやすいコードにする。
- テストにロジックを入れない。
- 明確な失敗メッセージを書け。
１３章 テストダブル(test double)
- モッキング(mocking)みたいなこと。
１４章 大規模テスト
- ユニットテストが扱えないもののこと。
- テスト対象システム、データ、動作、検証、から構成される。
１５章 廃止
１６章 バージョンコントロールとブランチ管理
- 単一バージョンを守る
１７章 ユニットテストCode Search
１８章 ビルドシステムとビルド哲学
１９章 GoogleのコードレビューツールCritique
２０章 静的解析
２１章 依存関係管理
２２章 大規模変更
２３章 継続的インテグレーション
２４章 継続的デリバリー
２５章 サービスとしてのコンピュート
当アドカレ著者の私見
- ３人で立ち上げたベンチャーが本書に従う必要はない
- 本書が現時点で最もソフトウェア開発とサービス運用の実践を通して、その特性を知り抜いた最高の知性の人々の経験の集大成である。
- しかし、ソフトウェアの進歩は更に進んでおり、本書の主張は生成AIの影響を受けて、また変化していく可能性が高い。
書誌情報
- 書籍名：Googleソフトウェアエンジニアリング
- 著者：タイタス・ウィンタース
- 出版社：オーム社
- ISBN：978-4-87311-965-6