Googleのソフトウェアエンジニアリング、実践ソフトウェアエンジニアリング第9版の関係

まとめ

  • 両者のソフトウェアエンジニアリングの定義は大体似ている。「規律」が共通点。規律でありながら適用が厳格でないと述べている点も一緒。「時間で積分したプログラミング」が SEatGoogle での独特な表現。
  • SEPA はソフトウェアエンジニアリングの全体を示している。対して SEatGoogle では全体を示しておらず、設計、プロセスモデル、品質保証といった章になりそうな領域でさえ省かれている。代わりに、SEPA におけるソフトウェア構成マネジメント(22章)が最も関係している。
  • SEatGoogle がそのような構成になっているのは Google 最初期のプロダクトである検索と広告が商業的に大きく成功したことによって持続可能性とスケーラビリティを追い求めてきたから
  • SEPA は基礎を学ぶための本。SEatGoogle はその基礎に基づきつつ、Google のソフトウェアとビジネスにとって重要な領域を独自に体系化した本。それにある程度近い業界であるほど役立ちそう。「そこは第一じゃない」と異論を唱える業界もいそう。

本編

この文章は 実践ソフトウェアエンジニアリング第9版アドベントカレンダー の8日目です。 米国の大学を中心に教科書として採用されており、40年に渡って改訂されてきたベストセラーであるという Software Engineering: A Practitioner's Approach 9th edition の訳書 "実践ソフトウェアエンジニアリング第9版" が2021年12月1日にオーム社より発刊されました。これを記念して、翻訳者による感想や解説などの本書にまつわる文章をアドベントカレンダー形式でお届けします。7日目は 複数名で進める翻訳環境と事前準備 のお話でした。

今回は、この第9版と Googleのソフトウェアエンジニアリング (原著: Software Engineering at Google) との関係を簡単に見出します。 Google のソフトウェアエンジニアリングは、その名の通り Google で行われているソフトウェアエンジニアリングについて記されており、そのページ数は体系的解説書である実践ソフトウェアエンジニアリング第9版よりも多く(640>520)、発刊時期も2021年11月下旬とほぼ同じです。 同じ分野の重い本が同時に世に出ましたので、ECサイトや本屋で両方を目にすることがあるでしょう。 重い本にチャレンジする気概がある読者候補であっても両方を読む方は少数で、「どっちにしようか」選ぶのではないでしょうか。 また、私は第9版の共訳者で、普及の意味でこのアドベントカレンダーを書いているのですが、「実はGoogle本の方が今時の役に立つことが書いてあるんじゃないの?」 *1という疑問と期待を持っていました。というのが、関係を見出す動機です。

この文章では、それぞれの原著名にちなんで、実践ソフトウェアエンジニアリング第9版を SEPA と、Googleのソフトウェアエンジニアリングを SEatGoogle と記します。 そして、両者の関係を見出す質問として以下のものを設け、これらを本文章の構成とします。

  • ソフトウェアエンジニアリングの定義は同じか?
  • SEatGoogle の内容は SEPA に記された領域の多くをカバーしているか?
  • なぜ SEatGoogle の SEPA に対する特徴がそうなっているのか?
  • 誰が読むと役立つのか?

両者の関係を 簡単に 見出すと書いた理由は、私が SEatGoogle を全体的に浅く読んだだけであり、この文章を書くのも1日しかかけていないからです。 より深く正確に、多くの人にとって意義ある関係を見出すには時間がかかるでしょう。 また、そこに集中して労力をかける意味はそれほどなく、今後の活動の中で両者を参照していくうちにわかっていけばよいと考えています。

ソフトウェアエンジニアリングの定義は同じか?

どちらの本も序文でその定義について触れています。共通要素はあるものの、SEatGoogle には独特な記述があります。

SEPA の "まえがき" では次の文があります。

経験をもとに失敗の真因に立ち向かうためには、設計や構築における規律(discipline)が必要である。すなわちエンジニアリングというアプローチの必要性を意味する。 … その成果である手法、プロセスモデル、ツールは、多種多様な産業分野において活用されている。

国際的には ISO/IEC/IEEE 24765:2017 で定義されているそうで、SEPA では次のように訳されています。

ソフトウェアの開発、運用、メンテナンスに対するシステマティックで規律(discipline)ある、 定量化できるアプローチの適用、すなわちソフトウェアに対するエンジニアリングの適用[IEE17]。

対して、SEatGoogle の "はじめに" では、定義の後に「規律」が同じく登場し、その定義を別の独特なフレーズで示し直しています。*2

我々が提案するのは、「ソフトウェアエンジニアリング」とは単にコードを書く行為のみならず、組織が時間の経過に応じてコードを構築し保守するために用いるツールとプロセス全てをも包含するということである。 … エンジニアたちはどのようにして、コードベース(codebase)をさらに持続可能にしつつ、ソフトウェアエンジニアリングの規律自体を厳格化できるだろうか。 … 本書が共有する重要な認識に、ソフトウェアエンジニアリングとは「時間で積分したプログラミング」とみなせる、というものがある。

仕事で、特定のプロダクトのコードを何年も書き続けたことがある人にとっては SEatGoogle が提唱する定義の方が納得できるかもしれません。私はその一人です。 というのも、私はプログラミング以上にソフトウェアエンジニアリングが必要になる理由の主要要素を「時間」「他人」「要求(または品質)」だと認識してきたからです。 「時間」と「他人」は SEatGoogle の全編で触れられています。

そして、定義の周辺にも共通する記述があります。規律とはいっても適用が厳格でない点です。

SEPA ではこう書かれています。

マネージャも開発者も規律の必要性を認識している。一方、規律の適用方法については意見が分かれている。たとえ最先端技術を扱う開発であったとしても、規律が適用されていない現場は珍しくない。…規律の適用方法まで含めて完全に成熟するまでには、すべきことがまだまだ山積みだ。

SEatGoogle にも似た記述があります。

比較的確立された他のエンジニアリング専門職と異なり、現在のソフトウェアエンジニアリングの理論やプラクティスは、同程度に厳格であるとはいえない。 …ソフトウェアが我々の生活にさらに統合されていくに従い、ソフトウェアエンジニアリングもさらに厳格なエンジニアリングの方式を採用し、そうした方式に頼らなければならない。 …Google自身も、本書のページ内に収められている概念の多くをいまだに不完全にしか適用していない。

この業界では、多様な状況下で規律の仮説と実証が繰り返され、規律が練り上げられてきました。 ただ、規律がどのような条件下であるほど有用か、その条件を示す変数(例:ライフサイクル、品質特性、コード量、計算機資源、人数、ビジネスモデル)が何なのかは明らかにされていません。 また、特定の状況に有用な規律が判明したとして、その適用過程は個々の事例レベルにとどまっておりパターン化が進んでいません。規律の適用条件と適用過程が解明されれば、これまでに蓄積された規律の価値が爆発的に向上するという未来を私は見ています。*3 *4

というわけで、定義が同じか?という疑問に私が出した答えはこうです。

  • 両者のソフトウェアエンジニアリングの定義は大体似ている。「規律」が共通点。規律でありながら適用が厳格でないと述べている点も一緒。「時間で積分したプログラミング」が SEatGoogle での独特な表現。

SEatGoogle の内容は SEPA に記された領域の多くをカバーしているか?

全然そうではないというのが SEatGoogle を浅く読んでわかったことです。 SEatGoogle の "はじめに" には "本書が扱わないもの" という節があり、次のことが書いてあります。

ソフトウェア設計という、それ自体独立した書籍を必要とする専門分野を扱うことは、本書の目指すところではない。 …本書で扱っていないソフトウェア開発上の重要な問題も多い。 例えば、プロジェクトマネジメント、API設計、セキュリティ強化、国際化、ユーザーインターフェイスフレームワーク、その他のプログラミング言語特有の概念だ。 そういった問題が本書では省略されているからといって、各問題の重要性が失われることを意味するわけではない。むしろ、それらの問題が値する処遇を提供できないことを承知しつつ、 本書ではあえて扱わないことを選択している。 我々が心がけたのは、本書での議論を、プログラミングというよりエンジニアリングをめぐるものとすることだ。

実際に、プロジェクトマネジメント、API設計、セキュリティ強化、国際化、ユーザーインターフェイスフレームワーク、その他のプログラミング言語特有の概念は 主題として扱われておらず、出てくるとしてもきわめて断片的に登場するのみです。

SEPA の章に当てはめて言えば、ほとんどの章は主題として扱われていません。例えばプロセスモデルの話はありません。アジャイル (agile, agility) という言葉は度々登場し、Lean と DevOps の科学、Successing with Agile という文献も参照されていますが、Googleアジャイル開発あるいはリーン開発をどのように行っているかという切り口の文面はありません。iteration という言葉は本書に多く登場しますが、イテレーティブプロセスの iteration ではありません。ただし、多くの人から見て頻繁に思えるであろう程度のリリースをしている記述があります。24.4 では

ある時点では、Google検索のバイナリを本番環境に1回しかリリースしておらず、週1回の目標を達成することすら稀で、運次第のことが多かった。 …現在では、Google検索の新バイナリを本番環境へ1日置きに安定的にリリースできるようになっている。

16.2.3 では

製品の各リリース間の期間(またはリリースの存続時間)が数時間より長いならば、製品のリリースビルドに入ったコードを正確に表すリリースブランチを作成するのが賢明かもしれない。

という記述があります。

ほか、software requirements も quality assurance もヒットしませんし、diagram で出てくる文にはモデリングの話はありません。

代わりに、SEPA の 22章:ソフトウェア構成マネジメントで扱われている内容が SEatGoogle 第3部のほとんどの章に登場します。 16章:バージョンコントロールとブランチ管理、17章:Code Search、18章:ビルドシステムとビルド哲学、19章:GoogleのコードレビューツールCritique、21章:依存関係管理、22章:大規模変更、23章:継続的インテグレーション、24章:継続的デリバリーにて、SEPA で扱われている内容が具体的され、さらなる発展的な問題が取り上げられています。これら以外の章でも変更マネジメントに関する内容が部分的に登場します。

SEatGoogle の第2部は「文化」という名前で、2章~7章があります。SEPA での近い章としては5章:ソフトウェアエンジニアリングの人間的側面が挙がります。2章:チームでうまく仕事するには と比べると、どちらにも「チーム」「心理」「信頼」という言葉が出てきますが、起点も論旨も両者でかなり異なっています。SEPA ではトム・デマルコのピープルウェアを引用しているのに対し、SEatGoogle では独自論(部分的には Team Geek の内容を含む)がソフトウェアエンジニアの人間的な弱さを深堀りして展開されているように見えます。ほか、第2部文化に対する SEPA の記述としては、ポストモーテム(16.7)、マネジメントの要素としての人材(24.1.1)、人材構成(29.4.4)、協働的開発(29.5.3)、品質保証における教育(17.2)、プロセス改善における教育(28.2.2)という部分が相当するように見えますが、それらの細切れの節を集めても第2部文化の各章名に足る内容にはならないように見えます。そして、第2部の最後にある7章はエンジニアリング生産性の計測で、SEPA における近いようでそうでもない章が23章のソフトウェアメトリクスと分析です。SEPAの23章では、見積もり、品質測定など生産性計測以外の目的もその序文に書いてあり、多数のメトリクスが載っています。SEatGoogle では GSM 法に基づいた生産性計測の方法、具体例、注意点が載っています。GSM は SEPA に載せてもよかったんじゃないかと思います。

テストについては SEatGoogle では11~14章、SEPA では19~21章で扱われています。どちらも小規模なテストと大規模なテストの違いを述べており共通点があります。ただ、SEatGoogle には SEPA その他テストの書籍にあるような古典的テスト技法がなく、代わりに自動テストに大幅な紙面が割かれています。SEatGoogle の11~13章だけを切り出しても、Googleの文脈にそれほど関係のない一般的で有意義なユニットテスト本になりそうな出来です。

SEatGoogle の10章は「ドキュメンテーション」です。SEPA にドキュメンテーションの章はありませんが、21.12ドキュメントとヘルプ機能のテスト、9.4.1設計モデリングの原則、4章の冒頭に記述があります。ドキュメントはソフトウェアと共に成長すべき、という意見が両者で一致します。

SEatGoogle の最後25章は「サービスとしてのコンピュート」という名で、SSHログインによる手動のデプロイから始まり、スケジューリング、障害対応、監視といったタスクをプログラマブルに実現させきた歴史と方法が書かれています。23章からたびたび登場する Borg という自前のコンピュートサービスについて最も詳細に触れられ、Google 以外の会社がとれる代替手段も説明されています。この内容を1章として24章「継続的デリバリー」に続く最後の章にしているところは超絶的な規模でサービスを運用している Google らしいと感じました。これに相当する章は SEPA にはありません。次の版ではサーバーサイドに限定しない運用の章でこういう内容を扱ってもいいんじゃないかと思います。

浅いとはいえ重い2冊を扱ったので長くなってしまいましたが、SEatGoogle の内容は SEPA に記された領域の多くをカバーしているか?に端的に答えるとするとこうなります。

  • SEPA はソフトウェアエンジニアリングの全体を示している。対して SEatGoogle では全体を示しておらず、設計、プロセスモデル、品質保証といった章になりそうな領域でさえ省かれている。代わりに、SEPA におけるソフトウェア構成マネジメント(22章)が最も関係している。

なぜ SEatGoogle の SEPA に対する構成がそうなっているのか?

SEatGoogle の "はじめに" には、一般的なソフトウェアエンジニアリングに対してこのような文面が書かれています。

過去50年にわたり著されてきたこれまでのソフトウェアエンジニアリングに関する文献の全集に付け加えるに足る独特な観点を、何故Googleが持っていることになるのだろうか。

過去50年というのは、ソフトウェアエンジニアリングという工学分野が生まれたとされる 1968年の NATO 会議からの50年を指しているとみて間違いないでしょう。 そして、それを把握して文献の全集と言っているからには、SEPA に載っているような一般のソフトウェアエンジニアリング体系を把握している上で、 SEatGoogle として練り上げた体系は独特だと主張しているのでしょう。

その独特さは、ソフトウェアエンジニアリングとはプログラミングを時間で積分したものという定義に始まります。 続く章では、他のエンジニアと共にコードを持続的し、システムや組織を市場の需要に沿うよう(あるいは自身の目標に沿うよう)スケールさせる意義や方法が文化・プロセス・ツールという軸で語られます。 先の節で述べた通り、同じ "ソフトウェアエンジニアリング" を冠した重い本でも、その構成は SEPA と全く異なります。

個々の章の内容は「これまでのソフトウェアエンジニアリングに関する文献の全集」のどこかにあるのだと思います。はっきりとはわかりませんが。 とすると、独特なのはその構成ということになります。 なぜそのような構成になったのか?それは

  • Google 最初期のプロダクトである検索と広告が商業的に大きく成功したことによって、
  • ユーザーが世界的に増え、社員が増え、コンピュートが増え、コードの寿命が伸び、
  • 創業者ら初期メンバーが得意としていたであろうプログラミングを超えたソフトウェアエンジニアリングの必要性に気づき、
  • 既存の文献を参照しつつ持続可能性とスケーラビリティを追い求め、
  • その追求にふさわしい人材とコンピュートを投入し、
  • Piper や Critique や Borg といったツールを生み、
  • ツールの背景にはプロセスが、さらなる背景には文化があることを認識し、
  • システムのバグや人間関係のトラブルといった痛い目を見て、トイレに tips を貼るキャンペーンという地道な活動をし、
  • 続けてきた活動が正しかったと確信したから

ではないか、というのが SEatGoogle を浅く読んだ結果と、読む前から知っている断片的な Google の情報を直感的に結びつけた答えです。 なので、SEatGoogle をもっと深く読んだり、他に公開されている Google の文献 (例:How Google Works?) を読むと、商業的な要因まで含めた経緯がわかりそうです。

誰が読むと役立つのか?

SEPAは、読書感想文 の最後に述べた通り、 実務経験者がソフトウェアエンジニアリングの基礎を理解するのに役立つと思います。 入門書ではなく基礎が体系的に書かれている本なので、実務経験者が読むのが望ましいです。 学生や実務経験が乏しい方が入門書として読む場合は識者のレクチャーが必要だと思います。 (著者は、情報関連の学部4年生以上か、実務者が読むことを想定しています。)

SEatGoogle も実務経験者が具体的な経験と抽象化された知識を結びつけて理解を向上させる読み方ができると思いますが、 ソフトウェアエンジニアリングの全体を扱っていない(Googleが大事だとみなしている領域に集中している)点に留意しておく必要があります。

Googleと同じように持続可能性とスケーラビリティが求められるプロダクトを扱っている読者であるほど、 SEPA より先に SEatGoogle を読む方が合う情報にたどり着きやすいと思います。 そして、読者は別に Google と同じく巨大な Web サービスを扱っている必要はないでしょう。 例えば、大きなコードベースを組織的・持続的に成長させているというのは、 ローカルなサービスでも、デスクトップアプリにも組込みソフトウェアにも当てはまるはずです。 これから商業的に成功させるプロダクトを撃とうとしている若い企業には SEatGoogle は先の話に見えるかもしれませんが、 簡便化して取り入れ、目先や1年後に役立てることはできそうに思えます。

ただ、SEatGoogle は SEPA で言う「ソフトウェア構成マネジメント」を最も重視した構成になっていますが、 読者の扱うプロダクトが必要とするソフトウェアエンジニアリングにおいてもその構成が最適かというと複数の異論があるように思えます。 ゲームから見れば同じ構成マネジメントでもグラフィックスやサウンドやシナリオを扱うことが欠かせなかったり、 人命を扱う機器から見れば持続可能性よりも安全性から体系を組み立てるのではないかと想像します。 *5

SEatGoogle や、そのほか他社の包括的な実践事例を参考にするとしても、ゆくゆくは自社にとっての体系を作るはずです。 それを作る際には、一般的にソフトウェアエンジニアリングってどんなものなのかを知るリファレンスが盤石な土台になります。 SEatGoogle でも、過去50年にわたり著されてきたこれまでのソフトウェアエンジニアリングに関する文献の全集 を参照して 独特な観点 を加えています。

勘と運があれば、この種の重い本がなくても、ツール名やプラクティス名の検索結果である断片的な情報を思うまま組み合わせてなんとかなるかもしれません。 それに限界を感じたら選択肢に入る本だと思います。

*1:ここで「セガなんてだっせーよな?帰ってプレステやろーぜー」という構文を入れることを浮かべたが、公開寸前にポリコレ脳が機能し却下した。

*2:原著では、機械、土木、航空分野に discipline が存在する旨がソフトウェアエンジニアリングの定義より前に述べられている。

*3:特定の領域については書籍になっているものもあります

*4:モダン・ソフトウェアエンジニアリング のエッセンスを拡張するものか、ソフトウェア病理学における病気になりやすい条件として書けるかもしれない。

*5:ほか、受託開発で完成したら顧客企業にコードを納品しておしまいだったり、開発を外注して運用は塩漬け、みたいな場合には何の参考にもならないと思います。