💪

生産性向上チームを全人類に伝えたい

2024/08/20に公開

こんにちは! サイボウズ 24 卒 開発本部 生産性向上チーム所属の佐々木(@ajfAfg)です。奇しくも Newcomer Stage のトリを飾ることになって緊張です。

突然ですが、僕は日々の業務でこんな悩みを抱えています。
_人人人人人人人人人人人人人人人人人人_
> 生産性向上チームの説明ムズすぎ! <
 ̄ Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y  ̄
生産性向上チームは社内の開発者の生産性爆上げを目標に活動しているため、生産性向上チームの業務理解には社内の開発事情から理解しなければならない点が難しさの原因だと考えているのですが、それでもズバッと説明したいところです。特に、ビジネス職の方に対しても、どんな課題があって、どんなアプローチでそれを解決しようとしているのか答えられるようになりたいです。

そこで本稿では、全人類[1]をターゲットとして、生産性向上チームとは何なのか紹介します。本稿の執筆を通して、全人類に伝わる説明方法をしっかり言語化したり、この記事をポンと渡して説明できるようにすることが狙いです。

本稿の構成は次の通りです。まずはじめに、チームの成り立ちを見ながら生産性向上チームのミッションを説明します。次に生産性向上チームが主に開発・運用している 3 つの開発基盤を紹介します。また、生産性向上チームはその他にも色々と生産性向上に繋がる活動をしているため、そちらも併せて紹介します。最後に、生産性向上チームをもっと知りたい人に向け、各種資料へのリンクを示し本稿を閉じます。

生産性向上チームのミッション

生産性向上チームのミッションは、「多様で価値あるサービスを迅速に提供するため、部署やプロダクトを横断して、生産的でオープンな開発基盤を整備する」です。長いので一言にまとめると、「サイボウズの開発者がつらいと思っている部分を最高にしていく 💪」ことがミッションです。

なぜ部署やプロダクトを横断して開発生産性を高める必要があるのか、各チームごとに高めたらよいのではないか、という疑問に対しては、生産性向上チームの成り立ちを見るとわかりやすいです。生産性向上チームが爆誕したのは 2015 年なので、それ以前は各チームで生産性向上の取り組みが行われていました。その結果、当時は各チームで改善の知見が閉じてしまい、あるチームでは生産性が高い状態を保てている一方で、他のチームではそうではない状況が生まれていました[2]。また、開発チームの主業務はお客様向けのプロダクト開発であるため、時間も労力もかかりがちな根本解決を狙った改善活動は取り組みづらい状況でもありました。これらの課題を解決するため、@miyajan が生産性向上チームを爆誕させました。生産性向上チームはチームを横断して支援するため、改善の知見を他チームに共有しやすいです。また、開発チームの辛みの改善に生産性向上チームが取り組めるため、開発チームは主業務のプロダクト開発に集中できます。

……と言ってもすべて上手くいっている訳ではなく、いくつか課題もあります。やや古いですが、その辺の課題が以下のスライドで語られているので、興味のある方はご覧ください:
https://www.docswell.com/s/korosuke613/59Y1MK-2022-07-21-fighting-the-problems-that-come-with-developer-productivity-support

3 つのレーン

生産性向上には以下の 3 つのレーン(サブチーム)が存在し、それぞれのレーンで異なる開発基盤を開発・運用しています:

  • Four Keys 基盤
  • GitHub Actions セルフホストランナー
  • AWS 開発基盤

ここからは、各レーンが取り組んでいる課題とアプローチを見ていきます。

Four Keys 基盤

Four Keys [3]とは開発チームの生産性を測る 4 つの指標で、以下の指標が含まれます:

  • デプロイの頻度
    • デプロイ(開発した機能をお客様が使える状態にすること)した回数
    • 高いほどよい
  • 変更のリードタイム
    • 機能を開発してからデプロイまでにかかる時間
    • 短いほどよい
  • 変更障害率
    • プロダクトに障害が発生する割合
    • 低いほどよい
  • サービス復元時間
    • プロダクトに障害が発生してから復元するまでの時間
    • 短いほどよい

開発活動の改善に使える指標は他にも色々ありますが、Four Keys のえらいところは、この 4 つの指標で本当に開発生産性を測れるとの研究結果がある点です。説得力が段違いですね。研究なので、その結果に納得がいかない場合は反証できる点も最高です。

さて、自分のチームの生産性を客観的に見られると、より生産性を上げるために改善すべき課題がわかります。また、組織やプロダクトが大きくなっても継続して高速に開発するため、弊社の開発本部の目標として「製品進化スピード 10 倍!インパクト 10 倍!」が掲げられており(2024/8/20 現在)、この目標を達成できているか測る必要があります。そこで、弊社では生産性を測る機運が高まり、その指標として Four Keys が採用されました。
Four Keys の計測にあたって、まずはじめに Four Keys を計測可能な他社 SaaS の導入が検討されました。検討の結果、社内ネットワークからのみアクセス可能な社内システムとの相性の悪さや、利用のためには検討当時の開発手法を大きく変える必要性といった点が懸念されました。そのため、他社 SaaS は導入せず、弊社の開発事情に適した Four Keys 基盤を自社開発することになり、その役割を生産性向上チームの Four Keys 基盤レーンが担うことになりました。現在、Four Keys 基盤レーンは、計測した Four Keys をグラフとして可視化する開発基盤を社内向けに提供しています。

Four Keys 基盤レーンの詳細は以下のスライドを参照してください:
https://www.docswell.com/s/r4mimu/KEN6J6-2024-06-29-164917?utm_source=twitter&utm_medium=social&utm_campaign=singlepage

GitHub Actions セルフホストランナー

このレーンの説明が特に難しいです。前提知識が多すぎ。

誤解を恐れず超絶ざっくり説明すると次の通りです。GitHub Actions とはクラウド上で任意のプログラム[4]を実行可能なサービスで、開発プロセスの一部を自動化する目的で利用されます。自動化する開発プロセスの具体例としては、プロダクトのビルド[5]やテストの一部などが挙げられます。このビルドやテストといった処理の中で社内システムにアクセスしたい場合があるのですが、社内システムは社内ネットワーク内からのみアクセス可能で、残念ながら GitHub Actions 上からは通常社内ネットワークに入れません。そこで、生産性向上チームでは、セルフホストランナーという仕組みを利用して、GitHub Actions 上からも社内ネットワークに入れる開発基盤を開発・運用しています。

セルフホストランナーでこの課題を解決できる最も本質的な要因は、ビルドやテストの実行場所を GitHub Actions 側の実行環境から自前の実行環境に移せる点にあります。GitHub Actions 側の実行環境は好き勝手に変更できませんが、自前の実行環境なら可能です。社内ネットワークにアクセスできるよう作ることも可能です。

GitHub Actions セルフホストランナーレーンの詳細は以下の記事やスライドを参照してください:
https://blog.cybozu.io/entry/2022/12/01/102842
https://www.docswell.com/s/miyajan/ZW1XJX-large-scale-github-actions-self-hosted-runner-by-philips-terraform-module
https://www.docswell.com/s/Kesin11/5YDWD9-2024-08-09-reduce-gha-self-hosted-runner-cost

AWS 開発基盤

このレーンも GitHub Actions セルフホストランナーと並んで説明が難しいです。

またもや誤解を恐れず超超絶ざっくり説明すると次の通りです。AWS とはパブリッククラウドと呼ばれるものの一種で、Amazon が提供するクラウド上にプロダクトのインフラを構築できます。弊社は自社クラウド(i.e. プライベートクラウド)上にプロダクトのインフラを構築していますが、プロダクトの一部で AWS も活用しています。さて、AWS を利用するためには、一般的なプロダクトと同様に、AWS 上にユーザーを作成する必要があります。ユーザーを作成可能なのは管理者だけなので、AWS の利用者の増加につれ管理者の負担が増えます。また、社員が退職した場合、管理者は Entra ID と AWS 両方のユーザーを漏れなく削除する必要があります。つまり、二重管理となります。ここで、弊社では、各種サービスへのログイン手法として、Entra ID を用いた SSO を積極的に採用しています。この点に着目し、Entra ID を用いて AWS に SSO ログインできる仕組みを、AWS 開発基盤レーンでは開発・運用しています。管理者目線ではなく利用者目線で見ても、AWS のログインに必要なユーザー情報を特に覚えなくても SSO ログインできる点が嬉しい仕組みになっています。

という業務が主のレーンだったのですが、その開発基盤の開発は終了したので、最近はまた異なる開発基盤を開発しています。具体的には、社内のある開発基盤を新しく作り直しています。式年遷宮みたいなノリです。こちらの取り組みは本当に最近始まったばかりなのでまだ情報が公開されていませんが、乞うご期待です。

AWS 開発基盤レーンの詳細は以下の記事やスライドを参照してください:
https://zenn.dev/cybozu_ept/articles/cybozu-aws-sso-2024
https://www.docswell.com/s/naotama/524DJ1-2024-04-09-aws-sso-migration

他にも色々やってる生産性向上チーム

開発基盤の開発・運用の他にも、生産性向上に関する様々な活動に取り組んでいます。

生産性向上チームは開発基盤を社内に提供しているだけでなく、他のチームに入って生産性向上を支援することもあります。例えば、GitHub Actions に関する辛みの呟きを社内 SNS で発見したメンバーが、その人に突撃して並走した事例があります[7]。他チームから GitHub Actions や AWS 周辺の相談を受けることも多いです。その他に、いわゆる情シス的な業務がいくつかあり、例えば最も強い権限を持つ AWS アカウントの管理などがあります。

やや毛色が異なりますが、以下のイベントをはじめとして、社外イベントを企画・運営することも多いです。
https://cybozu.connpass.com/event/328524/

雑誌に記事を寄稿したりも!
https://x.com/gihyosd/status/1802904736037011849

なんとマスコットキャラクターまでいます。セイサンシャイン君と言います。かわいいね。

太陽をデフォルメ化したキャラクターが、トロピカルなジュースを片手にビーチでくつろいでいる。「ビーチへ行く余裕をあなたに」という文字列が目を惹く。

なお、「ビーチへ行く余裕をあなたに」というのは、生産性向上チームのスローガンです。ミッションより引用されがち。

もっと生産性向上チームを知りたいあなたへ

生産性向上チームを説明する最新(2024/8/20 時点)のスライド資料は以下です:
https://www.docswell.com/s/cybozu-tech/5R2X3N-engineering-productivity-team-recruitment-information

Zenn の Publication も必見です。生産性向上に関する話題をまとめた Productivity Weekly が毎週投稿されていたりします。
https://zenn.dev/p/cybozu_ept

まとめ

本稿では、全人類[1:1]をターゲットとして、サイボウズの生産性向上チームを紹介しました。生産性向上チームでは主に 3 つの開発基盤を開発・運用しており、他にも生産性向上に関する様々な活動に取り組んでいました。生産性向上チームは積極的に外部発信しているため、そのウォッチは欠かせないものでした。

本稿を通して生産性向上チームが 2000%伝わっていれば本望です!!
ビーチへ行く余裕をあなたに……🏖️

脚注
  1. 今回は僕の力不足により、IT 分野の素養がある人類とさせていただきます。 ↩︎ ↩︎

  2. なお、2015 年当時、サイボウズの開発本部の人数は 200 人ほどでした。 ↩︎

  3. エリート DevOps チームであることを Four Keys プロジェクトで確認する ↩︎

  4. ただし、GitHub Actions の利用規約に従っている必要はあります。 ↩︎

  5. ビルドとは、プロダクトを構成する複数のプログラムを、機械が実行できる形式に変換すること。 ↩︎

  6. Microsoft Entra ID とは、複数のサービスで使用可能なアカウントを提供するサービスです。詳細は「Microsoft Entra ID (旧称 Azure Active Directory) | Microsoft Security」を参照してください。 ↩︎

  7. レアめな支援の入り方です。 ↩︎

GitHubで編集を提案
サイボウズ 生産性向上チーム 💪

Discussion