Google Cloudに学ぶ、開発者体験を高める7つのアプローチ【Developer eXperience Day 2023#1】

エンジニアの生産性向上は組織の永遠の課題ともいえる。近年では技術スタック、企業文化、エンジニアを取り巻く労働環境を広く含んだ「開発者体験」の向上に取り組む企業も増えつつある。

この記事では、グーグル・クラウド・ジャパン合同会社の頼兼 孝幸氏(@tyorikan)が、Googleが提唱する開発者体験を高める文化のつくり方について紹介する。なお、頼兼氏のセッションはオライリー・ジャパンから出版されている『Google のソフトウェアエンジニアリング』を参考に一部構成されている。

• keyboard_arrow_down カスタマー向けワークショップで見えた3つの課題
• keyboard_arrow_down アプローチ1：ポストモーテムを活用し、心理的安全性の高い組織文化を醸成する
• keyboard_arrow_down アプローチ2：リーダーはゴールを示す役割に集中する
• keyboard_arrow_down アプローチ3：開発組織全体でルールを設け、プロセスの改善を図る
• keyboard_arrow_down アプローチ4：共同認識を図る手段としてのコードレビュー
• keyboard_arrow_down アプローチ5：「開発と一体」で行うべきドキュメンテーション
• keyboard_arrow_down アプローチ6：狭い範囲にユニットテストを定期的行う
• keyboard_arrow_down アプローチ7：製品の安定性&開発者文化につながるCI/CD

イベント全体のテーマとして設定されている「開発者体験」を、「ソフトウェアエンジニアリング」というワードに言い換えられるという頼兼氏。Google では、ソフトウェアエンジニアリングを「時間で積分したプログラミング」と表現している。これは開発だけではなく、「開発、保守、運用」を含めた工程全体を俯瞰して、包括的に考えた開発を行うべきという姿勢だ。

頼兼氏は「Tech Acceleration Program（TAP）」というカスタマーの内製化に向けて、アーキテクチャ設計やプロトタイプ開発を支援するワークショップを行っている。2年間にわたる支援のなかで、カスタマーからご相談いただく内容として以下の 3 つがあった。

・不健全な組織文化

上司が部下に指示をしても、部下が「どうぜこれで組織は変わらない」「自分の評価につながらない」と諦めてしまっている状態になっている。さらに他社や他部署に対して興味や尊敬をなくしてしまい、他社や他部署の働きがどうビジネスにつながるか意識しないという文化が形成されてしまっている。

・形式的なプロセス

あまり意味のない定型的なワークフローを実施し、リリース頻度が下がっている状態。また、与えられた業務や開発の背景・意義・目的を誰も説明できず、組織はモチベーションが下がっている。

・非システム的な運用

運用が属人的になっていたり、システムにテストコードがなく動作性の保証ができなかったりする状態。また、アラートがない、もしくはアラートがあってもその後どう対応すべきかアクションフローが定義されていない。

こうした課題を解決するためのポイントとして、頼兼氏は Google が実践している以下の7つのアプローチを提示した。

Google では、文化をつくることを重要視しており、すべてのアプローチは文化という土台の上に成り立つものだという。

ソフトウェア開発はチームによる取り組みであり、チーム文化を醸成するうえで、以下の3つのキーワードが重要であるとしている。

・謙虚：自分は全知全能ではなく、誤らないということはない
・尊敬：ともに働く他者を心から思いやる
・信頼：他者を信じ、適切なケースでかじ取りを任せる

頼兼氏は、チーム開発で起こりうるさまざまな衝突は「謙虚・尊敬・信頼のいずれかが欠けていることに起因する」とし、「謙虚・尊敬・信頼」を実現できれば、建設的な意見を頻繁に交わすことができ、開発体験を高める「文化」の根本となる、心理的安全性の高い職場環境につなげられるとした。

さらに、開発で壁にぶつかった際に「早期に失敗し、高速に失敗し、頻繁に失敗せよ」を意識することも非常に重要だという。挑戦する文化はソフトウェアエンジニアリングにおいて非常に重要なポイントだが、失敗をフィードバックとして開発サイクルに落とし込むことが不可欠だ。

そのための仕掛けのひとつとして、頼兼氏は「ポストモーテムの活用」を提示している。

ポストモーテムとは、障害や失敗が発生した際にその失敗を個人に帰結させず、「何がうまくいかなかったのか」「なぜうまくいかなかったのか」を振り返ってチーム内で建設的に議論するプロセスであり、原因の特定と解消のためのアクションプランを策定する手法だ。どうやったら改善できるかに焦点を当てることで、同じ過ちを防ぎ、品質の向上につなげることができる。

チームリーダーは、チームとして目指すべきゴールを示す役割であって、ゴールにたどり着くまでどの手段を選ぶのかは、チームに任せるべきだという。『Google のソフトウェアエンジニアリング』では、リーダーの行動として、以下のようなアンチパターンと建設的パターンに分けられる。

さらに、頼兼氏はスケールするリーダーの条件として以下の3つの要件を挙げた。

・いつでも決定せよ

何かを決定することで得られるもの、失うものの正しい組み合わせを見つけて決定できる。

・いつでも立ち去れ

マネージャーやリーダーがいなくても、エンジニアが自立して開発できる文化や環境をつくれる。

・いつでもスケールせよ

自分のリソースを超えるタスクに対して、他者に移譲できるチーム文化を形成できる。

開発者体験を高める手法のひとつとして、開発プロセスの改善が挙げられる。開発組織によくある課題として以下の3点が挙げられている。

・チームごとに関数名・変数の命名規則がバラバラ
・ソースコードの改行位置がずれていたりすることで可読性、保守性が悪い
・なぜその動作が必要なのかの説明がなく、コードの意図が不明瞭

頼兼氏はこうした課題に対して、「まずはコードのフォーマットや命名規則、パターン、例外、スレッドなどのルールを設けることで、保守性の高いコードを実現できる」と語る。Google が公開しているスタイルガイドを参考に、以下の3つのカテゴリーのルールを設ける必要があると考えられている。

・危険を避けるためのルール

技術的理由をもとに、保守性のある言語利用をサポートする。セキュリティに直結するルールであるため、しっかりとルールを定めてシステム的に検知できるようにしておく必要がある。

・ベストプラクティスを強制するためのルール

やり方がある程度決まっている手段を言語化して、ベストプラクティスの実行をシステム化することで、その方法について詳しくないメンバーでも理解できるようにする。新しいメンバーにもベストプラクティスを強制できる仕組みづくりが求められる。

・一貫性を保証するためのルール

こうしたルールは定期的に見直して、組織事情に即した内容に更新していく必要がある。さらにルールを適用する際に、ポイントのレビューや横断的なガイダンス、トレーニングも実行しなければならない。そのうえで、システム的に組織全体がルールに準拠するような仕組みを段階的につくりあげていくことが求められる。

頼兼氏はコードレビューがチームに与えるメリットとして、コードの正しさを保証すると同時に、コード変更時に他のエンジニアが随時把握できて、コードベース全体での一貫性を保つことに寄与できる点が挙げられる。さらに、レビューを通してチーム全体に知識共有し、コードに対して責任を持つというオーナーシップを浸透させることができるという。

そして、コードレビューを実施する時に起こりやすい問題点として以下が挙げられる。

・レビュー依頼者から詳細な説明がなく、レビュー者は変更の背景が把握できず良し悪しの判断ができない。
・コードの評価が主観的でルールがない。
・批判に終始しており、具体的な代案の提案や知識の共有ができていない。

そのほか、レビューするコードの変更量が多いことも、コードレビューの質を下げる要因のひとつとして挙げられる。プルリクを投げる段階で差分が1,000行ある場合は数日かけて判断することになってしまう。フィードバックのサイクルを早くするために、1回あたりのコードの変更を小さくすることを心がけるべきだという。

これらの課題を解決するために、レビューをする側も受ける側も以下を意識することが必要だという。

・コードの1行目に変更全体の要約として、なぜ変更されるのかの説明を入れる。それによりレビューする側は変更の目的と内容を事前に把握できるので、コードを見てなぜそうなるのか理解しやすくなる。
・レビュアーにレビュー依頼する前に、まず自分自身でそのコードが動くかどうかを確認できる仕組みをつくる。修正を作者に強制することで、プロセスを改善することができる。
・自分がやったことの理由をレビュアーが理解しないのなら、コードの構造やコメントを改善する必要がある。

ドキュメンテーションの不備により起きる課題として以下の3点が挙げられる。

・途中からジョインしたメンバーが、書いてあるコードや設計の仕様・背景が明瞭に理解できない
・同じことを違う人に何度も説明するという手間がかかる
・動いているコードについて、なぜそのやり方で実装したのかという理由が不明

これらの課題は、実装の背景までしっかり落とし込んだドキュメントをつくることで解決できるといえる。

Google ではソフトウェアの設計時に必ず「Design Doc」というドキュメントを作成しているという。主な内容として記されているのは以下の5点。

・背景とスコープ（この機能／製品は何のためにつくられるのか、スコープはどこか）
・目標と非目標（この機能／製品でやるべきこととやらないこと）
・実際のデザイン（どういうオープンソースを使うかといった実際のアーキテクチャや実装）
・考慮された代替案（デザインなどの採択時に考慮された他の選択肢。なぜこのやり方なのかを明確にする）
・横断的な懸念事項

Google ではドキュメントをコードのようなものとして捉えていると頼兼氏は語る。バージョン管理などオーナー的な領域の管理を効率的に行うべく、コードとセットでドキュメントを残すことを開発タスクとして落とし込んでいる。そのため、ドキュメントがなければリリースまで行なえない仕組みとなっている。

また以下のような「5W」をドキュメンテーションで忘れがちなポイントとして挙げており、これらをドキュメンテーションで一番大事な部分として示した。

頼兼氏は「ドキュメントは意図された役目を果たしていることが正解であり、文書として完璧・正確なものを作る必要はない」としたうえで、「対象の読者に向けて書くことを意識してほしい」とした。

テストを行うことでデバッグ回数を減少させることはもちろん、レビューの単純化やドキュメンテーションの改善を実現することができる。長期的な観点からは高速かつ高品質なリリースも可能になるので、技術・市場・顧客の変化に対してより迅速に適応できるというメリットがあるという。

ただ、実際の現場では、テストにおいては「とりあえずデプロイしてから画面を見て確認」のような形でGUIをチェックするなど、開発速度を上げるためにテスト自体を後回しにするケースが見受けられるという。さらに、テストケースがないためコードが変更できないといった組織もあるし、「テストが実行タイミング次第で成功しない」という、テストの意図をなしていないテストを実行してしまっているケースもあると振り返る。

Google では失敗原因の分析を迅速に行うために、狭い範囲のユニットテストをなるべく多く行うことを推奨している。E2Eやインテグレーションテストの立ち位置は「ユニットテストが扱えないものを扱う」というところにあり、その分非常に複雑なものになる。「適切なオーナーをアサインして、必要な時に実行される形で行なわれるような配慮が必要」だと頼兼氏は語った。

最後に示されたのがCI/CD領域で、手動実行でビルドやテストが行われているケースだ。ほかにも、脆弱性を含むソースが検知されないままデプロイしてしまうというケースが課題として挙げられた。ビルドサーバーが集約されているため、実行に詰まってしまいアジリティが下がったり、致命的なバグなどで一斉にサービス利用不可になったりといった例も紹介された。

頼兼氏は「迅速なCI/CDを実現するためには、安全かつ安定した運用を実現することを考慮したうえでCI/CDを仕組化することも考えるべき」とした。CIは迅速にソフトウェア開発を行う方法であると同時にセキュリティ検知も行なうべきステージであり、CDは問題があったときにすぐロールバックするなど安定した運用にもつながるという。

製品の安定性とともに幸福度の高い開発者文化にもつながるため、頼兼氏は「CI/CDはかなり直接的に開発者体験の向上につながると思う」としている。

また Google Cloud では CI/CD を含む一連のサイクルとして「ソフトウェア サプライチェーン」という言葉を使用しており、ワークステーションで開発したものを Cloud Run などのランタイムで動かすという一連の処理をマネージドで提供できる。「各課題も、こうしたマネージドの製品を使うことで解決しやすくなる」と頼兼氏は胸を張った。

講演の最後に、頼兼氏は「7つのアプローチを紹介したが、全部が全部適用できるわけではないと思うし、Google のソリューションがすべてでもないと考えている」とした。ただ、謙虚・尊敬・信頼というキーワードから築かれる文化については「必ず大事なポイントになってくるので、エッセンスとして取り組んでほしい」として講演を締めた。

文・中島佑馬