2023年6月14日から15日にかけて、日本CTO協会が主催するカンファレンス「Developer eXperience Day 2023」が開催されました。さまざまなテーマのセッションがおこなわれたなかで、本記事では「開発者体験を高める文化と手法」をテーマにしたセッションの内容をお届けします。
セッションには、グーグル・クラウド・ジャパン合同会社の頼兼 孝幸氏が登壇。
ソフトウェアエンジニアリングの課題に対する解決策として、Google が実践している7つのことを紹介してくれました。
頼兼 孝幸さん
グーグル・クラウド・ジャパン合同会社 カスタマー エンジニアリング / アプリケーション モダナイゼーション スペシャリスト。メディア企業にて、アプリケーションのクライアント、API 開発からインフラ構築まで幅広く担当。その後、グローバルな EC システムの開発やインフラ構築の自動化などを担当。現在は、Google Cloud 上でのコンテナ開発、アーキテクチャ設計、CI / CD などの技術支援をおこなっている。
目次
開発者体験＝ソフトウェアエンジニアリング
「開発者体験」という言葉を言い換えると「ソフトウェアエンジニアリング」になると、わたしは考えています。ですので、ソフトウェアエンジニアリングをGoogleがどのように考えているのかをベースにお話ししていきます。
本日お話しする内容は、オライリー・ジャパンから出版されている『Google のソフトウェアエンジニアリング』を参考に、一部構成しました。
みなさんはソフトウェアエンジニアリングと聞いて、まずなにを思い浮かべるでしょうか？
単なる概念であったり設計であったり、プログラミンであったりなど、いろいろな考え方があると思います。
『Google のソフトウェアエンジニアリング』では、ソフトウェアエンジニアリングとは「時間で積分したプログラミング」と書かれています。
いろいろな開発がおこなわれるなかで、特定の実装は単なる開発です。この”積分”というのは、点ではなく面で考えることを意味します。
開発だけではなく、保守や運用を考慮した形でおこなうことがソフトウェアエンジニアリングと置き換えられます。
仕事で得たソフトウェアエンジニアリングにおける課題
わたしは「Tech Acceleration Program（TAP）」というワークショッププログラムをおこなっています。
TAP は、お客さまの内製化を促進できるよう、実際のアプリケーションをベースにして、アーキテクチャ設計やプロトタイプ開発を支援するものです。
この2年弱の間に、TAP を50件以上実施したなかで、ソフトウェアエンジニアリングにおける課題がいくつか見えてきました。見えてきた課題は、大きく分けて3つです。
- 文化に課題がある
- プロセスが形式的
- システム的でない
これらのソフトウェアエンジニアリングにおける課題に対しては、Google が実践している次の7つが解決のポイントとして挙げられると思います。
- 文化
- チームリーダー
- プロセス
- コードレビュー
- ドキュメンテーション
- テスト
- CI/CD
それぞれ説明していきます。
ポイント1:「文化」大事なポイントは「謙虚、尊敬、信頼」
文化をつくることは、Google も非常に大切にしているポイントです。この文化がないと、残りの6個を達成しづらいので、一番大事な基盤となっています。
「謙虚、尊敬、信頼」という3つのキーワードが、文化を形成するうえでの大事なポイントとなってきます。
ソフトウェアエンジニアリングは、チームで取り組んでいるはずです。1人で悩んでいてもなかなか解決できないものを、チームだと解決できることは多いと思います。
早期に失敗して、高速に失敗して、そして頻繁に失敗する。うまく失敗すると、チームの開発においては失敗もポジティブに捉えられることが多くなります。
1人で悩むよりもチームでレビューを頻繁にしてもらい、チーム開発を素早くおこなう。それが健全なシステムであって、開発者体験に紐づいていくと考えています。
チームで開発をするうえで、衝突もたまにあるはずです。衝突の原因は、さきほどの3つのキーワード「謙虚、尊敬、信頼」のいずれかが欠けているから起こるとされています。
「謙虚、尊敬、信頼」を実現するためには、誹謗中傷しない心理的安全性のある環境が大事になります。
建設的な意見を言い合えるのが健全なチームです。具体的には、「AじゃなくてBだね。間違っているよ」と直球で伝えるのではなく、「これはAよりもBのほうがこういう観点でいいと思うけど、どう思う？」と伝えます。言い方を変えるだけですが、印象は結構変わると思うんですよね。
こういった建設的な意見を頻繁に言い合うことが、開発者体験を高める文化のために必要な心理的安全性につながると考えています。
ポイント2:「チームリーダー」マイクロマネジメントするべきではない
チームリーダーは、テックリードやマネジャーのような方々です。こうした方々は、マイクロマネジメントをするべきではないとされています。『Google のソフトウェアエンジニアリング』では、「伝統的なマネージャーは物事をやり遂げる方法を気にする一方で、優れたマネージャーはどんな物事がやり遂げられるのかを気にする（そして、やる方法を見つけるのはチームに任せる）。」と述べられています。
ただ、目指すゴールや、なぜやるべきかといった点は明確に伝えてください。
たとえば、「売上を2倍にするため、朝9時に出社しよう」という文章があったとします。
「売上を2倍にする」という目標は、チームが共通のゴールを持つために重要なポイントですし、これは伝えるべきです。しかし、「朝9時に出社しましょう」という部分は、マイクロマネジメントなので伝えるべきではないと思います。
売上を2倍にするために、みんなでディスカッションをして正しい方法を見つけていく。リーダーは、そのためのサポーターとしてどう動けるのかにフォーカスするべきだと考えています。
ポイント3:「プロセス」スタイルガイドのルールを決める
プロセスのよくある課題として、次の3つが挙げられると思います。
- チームごとに命名規則がバラバラ（e.g.関数名、変数など）
- 可読性、保守性が悪い（e.g.改行位置が変、文字数が多いなど）
- コードの意図が分からない（なぜその動作が必要なのかが明瞭でない）
コードによって命名規則がバラバラだと分かりづらいので、ルールをしっかり決めていきましょう。
命名規則は、可読性や保守性にも関連します。コードの改行位置が変だったり文字数が多かったりすると、可読性が悪くて理解しづらくなってしまいます。
関数を見ただけでは、なぜこの関数を実行する必要があるのかという意図が分からないことが結構あるはずです。そこは、しっかりとコメントを残すといった仕組みづくりが必要です。これらの課題に対しては、スタイルガイドのルールを決めることが解決策となります。
ポイント4:「コードレビュー」なぜ？を説明する
コードレビューのよくある課題として、次の4つが挙げられると思います。
- 詳細な説明がなく、変更した背景が把握できない
- コードの正しさの評価が主観的
- 批判的で、代案や知識共有ができていない
- レビューするコードの変更量が多い
1つめは、詳細な説明がなく、変更した背景が把握できないことです。プルリクエストが来たときに変更した背景が把握できないと、良いか悪いかの判断ができません。
2つめは、コードの正しさの評価が主観的なことです。評価するときにはレビューでOKかNGかを決めると思いますが、評価が主観的になることは多いと思います。そこはルールとして決めたものが適用されるべきだと考えています。
3つめは、批判的で、代案や知識共有ができていないことです。プルリクエストには知識の共有という意味合いもあると思いますが、「ダメだ」というコメントだけ書いて、代案や知識共有をできていないことがあります。
最後は、レビューするコードの変更量が多いことです。プルリクエストを投げる段階で、差分が1000行とかになった場合、レビュー者からしたら、なにを見ればいいのか分からないですよね。しっかり確認するには、数日かかってしまうと思います。なるべく1回あたりの変更量は小さくして、レビューサイクルを速く回すようにしたほうがいいです。
ポイント5:「ドキュメンテーション」意図された役目を果たす
ドキュメンテーションのよくある課題として、次の3つが挙げられると思います。
- 途中からチームにジョインした人などが、仕様や設計上の決定などの背景について明瞭でない
- 誰かに説明したことを違う人に何度も説明する
- 動いているコードについて、過去になぜそのやり方で実装したのかの理由が分からない（そして業務への影響が怖いので塩漬け）
これらの課題を解決するためにも、ドキュメントに落として背景などを見返しやすいようにしていくのがポイントです。
Google では、ソフトウェア設計のときには、必ず「Design Doc（デザインドック）」をつくるようにしています。新しい製品だけではなく、新しい機能ができたときにもDesign Docをつくっています。
Design Docに記載する項目は、次の5つです。
- 背景とスコープ
- 目標と非目標
- 実際のデザイン
- 考慮された代替案
- 横断的な懸念事項
ドキュメントはコードのようなものとして、Google は捉えています。なので、コードだけで何か機能開発することは、まずありえません。
Google では、コードとセットでドキュメントを残すことを開発タスクとして落とし込んでいます。ドキュメントがない場合は、ワークフローが満たせていないのでリリースできません。
ドキュメンテーションは完璧でなくても大丈夫です。意図された役目をはたしていることが重要です。
ポイント6:「テスト」変化に迅速に適応できる
テストのよくある課題として、次の4つが挙げられると思います。
- 開発速度を上げるためにテストは後回し
- とりあえずデプロイして画面から見て確認
- テストケースがないから、コードが変更できない
- 実行タイミング次第で成功しない（不確実）
しっかりとしたテストのプラクティスがあれば、技術や市場や顧客などの変化に対して、より迅速に適応可能です。
E2Eテストのような広い範囲のテストもあれば、ユニットテストのような狭い範囲のテストもあります。Google で推奨しているのは、ユニットテストの割合を高めることです。ユニットテストを多く、高速にやることで失敗原因の分析が迅速におこなえます。当然ながら自動化は必須です。
E2Eテストは、適切なオーナーをアサインしたうえでおこなうようにしています。
ポイント7:CI/CD 直接的に開発者体験を高めることにつながる
CI/CDでよくある課題として、次の5つが挙げられると思います。
- 手動実行でビルドやテストを実施している
- 脆弱性が検知されないまま、本番までデプロイ
- ビルドサーバが集約されており、実行に詰まる
- アジリティが低い（リリース頻度が遅い）
- デプロイしたら致命的なバグや手順漏れによって全ユーザーが一斉にサービス利用不可に…
迅速なCI/CDを実現させるためには、セキュアで安定した運用を実現することも考慮したうえで、CI/CDの仕組み化を考えるべきです。
CIは頻繁にソフトウェア開発をおこなうプラクティスであると同時に、セキュリティの検知もここでおこなうべきだと考えています。
CDは迅速な開発というよりは、安定した運用につながってくると思います。ソフトウェアを早期にデプロイして、迅速にフィードバックを得て、なにか問題があったときにはすぐにロールバックするなどが可能です。
製品の安定性を高めるとともに、幸福度の高い開発文化につながります。ですので、CI/CDはかなり直接的に開発者体験を高めることにつながると思います。
開発者体験を高めるために取り入れたいこと
Google が実践している7つのことを紹介してきましたが、すべてを適用できるわけではないと思っています。また、Google のソリューションがすべて万能な解だとも思っていません。
ただ、基盤にある「文化」は大事なポイントとなっていますので、エッセンスとして取り組んでいただければと思います。
（取材／文：川崎博則）
