ソフトウェア開発の共通言語をチームで持つために「Googleのソフトウェアエンジニアリング」勉強会をしました

この記事はClassi developers Advent Calendar 2022の21日目の記事です。

こんにちは。データAI部 Pythonエンジニアの工藤( id:irisuinwl )です。最近は、ポケモンSVとぼっちざろっくとDwarf Fortressにはまってます。一日48時間くらいほしいです。

さて、最近、自分が主催していた「Googleのソフトウェアエンジニアリング」勉強会を終えました。ソフトウェアエンジニアだけでなく、データサイエンティスト、ディレクター、プロダクトマネージャーを巻き込んで行い、13人もの参加者が集まりました。

今回の記事では、「Googleのソフトウェアエンジニアリング」勉強会で得られた学びや、方法をお伝えできればと思います。

わぁ牛 pic.twitter.com/ANC37dzSfG
— いりす (@irisuinwl) 2022年12月16日

これは打ち上げの肉

Googleのソフトウェアエンジニアリングとは？

「Googleのソフトウェアエンジニアリング」とは、O’Reillyから出版されたSoftware Engineering at Google(通称 swe-book ) が日本語に訳された本です。 GoogleのSRE Bookと同様に Webに公開されている英語版であれば無料で閲覧することができます。

内容としては、Googleが実践しているソフトウェア開発のプラクティスが解説されています。まず、第一章ではソフトウェアエンジニアリングとは何なのか？　を定義し、時間に対するスケーラビリティと、トレードオフという観点で解説します。そして、第二章からソフトウェアエンジニアリングを実践するための方法を第2部文化、第3部プロセス、第4部ツール`のそれぞれの観点から解説しています。

前半の部ほど普遍的な題材であり、ソフトウェア開発に携わる人間であれば誰にでもおすすめ出来る内容です

ところで、そもそものソフトウェアエンジニアリングとは何でしょうか？ソフトウェアエンジニアリングはソフトウェア工学とも呼ばれ、ソフトウェア開発の工学的なアプローチ とwikipediaには記載されております。

ざっくりいうと、ソフトウェア開発を上手く実行できるためのプラクティスから共通項を抽出し体系化された方法論と言えます。そして、要求工学、設計、テスト、運用、プロジェクトマネジメントといった各分野についての方法論が述べられることがソフトウェアエンジニアリングの教科書では一般的です。

一方で、「Googleのソフトウェアエンジニアリング」ではソフトウェアエンジニアリングを

ソフトウェアエンジニアリングとは時間で積分したプログラミングである

という言葉を引用し、コードの生産に至るまでから保守・運用の時間経過を伴ったソフトウェア開発のことと捉えています。

大枠は同じでも、「Googleのソフトウェアエンジニアリング」では、Googleの開発経験に基づいてソフトウェアエンジニアリングを体系化しているのが特徴と言えます。内容も、一般的な開発の方法論というより、Googleでの開発ナレッジから得られたプラクティスと、ソフトウェア組織生成にフォーカスが当たってます。

例えば、「Googleのソフトウェアエンジニアリング」では要求工学やプロジェクトマネジメントの記述はなく、一方で、一般的なソフトウェアエンジニアリングでは言及されていない文化という観点や、4章の公平性、7章の生産性計測、10章のドキュメンテーション、15章の廃止はこの本のユニークな内容となっていると感じます。

モチベーション

何故「Googleのソフトウェアエンジニアリング」勉強会を開いたのか、というモチベーションについて説明します。

きっかけとしては Classi Adaptive Learning Engine (CALE) 開発が終わり、様々なステークホルダーが関わる開発プロセスを顧みたとき、ソフトウェア開発の方法論を見直しつつ、共通言語を持ちたいと思ったことです。

その中で最近出版されたソフトウェアエンジニアリングの本で、内容がわかりやすそうな「Googleのソフトウェアエンジニアリング」の勉強会を開くのが良いのではないかと考えました。そして、チームで話題に出したところ同様のモチベーションがありそうだったので、勉強会開催へと至りました。

そして、キックオフで設定した勉強会の目的としては以下としました: - Googleのソフトウェアエンジニアリングにおける考え方やプラクティスをインプットする - Googleのソフトウェアエンジニアリングに対して、現在自分たちが行っているソフトウェアエンジニアリングを俯瞰し、評価できるようになりたい。 - 章の内容に対して、自分たちはどうなのかを考えて、現状整理して課題認識できればOK という感じにしたい

方法

どのように勉強会を実施したかについて解説します。

具体的な勉強会の進行方法は以下です。

毎回1章ずつ進める
時間: 章のまとめを発表する+ディスカッションで1時間目安
- まとめの発表 (20~30分)
- ワーク・ディスカッション(30~分)
ディスカッションする内容
- 章の内容に対して身近なことを中心にMappingしていくような形式:
  - Classiや自分のプロジェクトではどうか？
  - これまでの開発経験ではどうだったか？
  - こうしていきたい
担当者
- 各回担当者を決める
- 担当者は章のまとめを作成して、ファシリテーションを行う
- とりあえずやってみる！　やばかったら悲鳴をあげる！

前述した通り「Googleのソフトウェアエンジニアリング」は、Googleの開発プロセスに特化した内容であり、勉強会の目的は知識のインプットと自分たちの現状整理と課題認識です。

単純に「Googleのソフトウェアエンジニアリング」を読むだけでは実践することは難しいと考え、自分たちの開発プロセスと比較することで以下を明らかにしたほうが良いと考えました。

現状はどうなっているか
どこにギャップがあるか
どこに課題があるか

毎回の勉強会では各自が読んできた内容について、以下の項目について事前にMiroに書いておき、ディスカッションする形式としました。

マッピング（自分たちのソフトウェアエンジニアリングとの比較）
気になりポイント（疑問点）
感想・共感（学び）

第一章のディスカッション内容をピックアップしたキャプチャを掲載します。

ソフトウェアエンジニアリングは実学のため、インプットだけでなく、現状比較と応用を意識したディスカッションパートは、現状とギャップを把握することに上手く働いたと思います。

実施した学び

勉強会を実施した振り返りから参加者の学んだこと・実践していること・実践したいことを抜粋します:

コードレビュー時や実装時に「一貫性」の観点も意識するようになった
PRのdescriptionに仕様書などの全体像がわかるリンクを貼るようになった。チーム内でも貼るのが当たり前になってきた。リンク貼ってなかったら指摘する風潮も最近出来ている
希望は戦略ではない。こうしたいっていう希望をもった後は、どうすれば実現できるか具体的なタスクにする姿勢を学んだ
本で学んだこと（PR・テスト）をまずは個人で試して、チーム、他のチームなどなど波及していきたい
機能が価値をもたらすのだという価値観を全人類に広める

ソフトウェアエンジニアやそれ以外の職種、ジュニアからミドルといった幅広い参加者がいた中で、ソフトウェアエンジニアリングというナレッジを体系化出来たと感じました。また、読んで終わりではなく、「Googleのソフトウェアエンジニアリング」で出てきた概念（例えばバス係数、希望は戦略ではない）が会話の中で出てくることが増えたと感じます。

元々の目的であった、ソフトウェアエンジニアリングのインプット（共通言語化）と自分たちの開発プロセスの比較は達成できたのではないかと感じております。