【サイバーエージェント×サイボウズ】専任チームによる開発生産性向上に向けたトライ
2023年4月27日、ファインディ株式会社が主催するイベント「【サイバーエージェント×サイボウズ】専任チームによる開発生産性向上に向けたトライ」がオンラインにて開催されました。
ファインディでは、エンジニア組織支援クラウド「Findy Team+(チームプラス)」をリリースし、エンジニア組織づくりや生産性の可視化を通じたパフォーマンスの最大化支援に取り組んでいます。
昨今では、開発生産性を定量化する指標として、GoogleのDevOps Research and Assessment（DORA）プロジェクトによる研究で提唱された、”Four Keys”指標がトレンドになりつつあり、開発生産性の維持や向上をミッションに掲げて取り組む組織が増えてきています。
本イベントでは、株式会社サイバーエージェントから山田明憲さん、サイボウズ株式会社から宮田淳平さんをお招きし、専任チームを立ち上げ、全社横断での開発生産性向上へトライしている先進的な取り組みについて、パネルディスカッション形式でお伺いしました。
■登壇者プロフィール
株式会社サイバーエージェント Developer Productivity室 室長 山田明憲さん @stormcat24
2012年サイバーエージェント中途入社。動画配信サービスのテックリード等を経て、2020年にDeveloper Productivity室(DP室)を設立し、アジリティある開発組織を実現するプロダクト提供やプラクティス実践を支援。『Docker/Kubernetes 実践コンテナ開発入門（技術評論社）』の著者。
サイボウズ株式会社 開発本部 生産性向上チーム 宮田淳平さん @miyajan
2009年サイボウズ株式会社に新卒入社。大規模向けグループウェア「ガルーン」やビジネスアプリ作成プラットフォーム「kintone」の開発を経験した後、2015年に生産性向上チームを立ち上げ。組織横断で開発基盤の整備と改善活動の支援を推進。『GitHub Actions 実践入門』の著者。
※本イベントのアーカイブ配信（無料）はこちら
目次
専任チームを置く両社の、チーム体制や立ち上げ背景
──本日はよろしくお願いいたします。まずは、お二人の略歴からご紹介いただけますでしょうか？
山田：株式会社サイバーエージェントで、Developer Productivity室（以下、DP室）の室長をしている、山田と申します。経歴としては、2012年にサイバーエージェントに入社して、動画配信サービスなどに携わったのち、2020年にDP室を設立しました。全社の事業開発において、アジリティの高い開発組織を実現するためのプロダクト提供や、プラクティス実践を支援しています。本日はよろしくお願いします。
宮田：サイボウズ株式会社の生産性向上チームに所属しております、宮田です。私は2009年にサイボウズに新卒入社し、最初はサービス開発をしていましたが、2015年に生産性向上チームを立ち上げ、今に至ります。組織横断での開発基盤の整備や、改善活動の支援を推進しています。よろしくお願いします。
──本日は7つのテーマをご用意しております。まずは、開発生産性向上チームの体制について。まだ日本で専任チームは珍しいと思いますので、現状の体制からお伺いできればと思います。
山田：DP室は現在7名で、都度インターン生や内定者アルバイトが入ったりしています。Developer Productivityは、“主語デカ”ワードだと思っているんですが、現在は継続的デリバリーやFeature Flagマネジメントなど、ソフトウェアのリリースサイクルに関わるところに注力して、チームを運営しています。
宮田：サイボウズの生産性向上チームは、現在7名。7月にキャリア採用が1名決まったので、人が増える予定です。今、生産性向上チームは組織内でサブチームなどに分けず、幅広い活動をすべて1つのチームとしてやっています。
──両社とも現在7名体制ということですが、今に至るまでの専任チーム立ち上げの背景についても教えていただけますでしょうか。
山田：サイバーエージェントには、さまざまな子会社や事業部が存在しているのですが、技術的な文化として、トップダウンで技術選定が行われることはなく、各事業部に任されています。とはいえ、今はエンジニア規模が1000名を超え、かつ異動もすごく多いんですね。そのなかで、各部署が使っているツールにバラつきがあったりして、オンボーディングコストが無視できなくなってきたことが背景にあります。
各事業部に任されている文化は、なるべく保ちたいと考える一方で、ソフトウェアデリバリーに関しては、ある程度勝ち筋が見えているところもあります。そのため、なるべく会社でそういった思想を統一していこうと、DP室が誕生しました。
もともとDP室ができる前に、各事業部で似たような取り組みがされていました。例えばFeature Flagマネジメントで言えば、最初に内製の基盤を作ったところから始まっています。そういったことに取り組んでいたメンバーを集めて、DP室を立ち上げ、Feature Flagや継続的デリバリーのシナジーを生める形で、プラクティスや基盤を仕上げていきたいという想いから、今の組織ができています。
──専任チーム立ち上げ背景について、宮田さんはいかがでしょうか？
宮田：もともと私が開発チームに所属していたころ、当時は継続的デリバリーなどが流行っていたので、開発チーム内でいろいろと改善活動をして、デプロイパイプラインを整備したりしていました。
ただ、やはり開発チームに所属していると、どうしても改善活動の緊急度が上がりづらく、片手間になってしまいます。例えば、当時CIツールにJenkinsを使っていたのですが、主管する担当が不在で全然管理されていない状態になっていて、信頼性に不安がありました。
他にも、複数チームにまたがる改善活動を進めたいときに、特定の開発チームに所属したままだとやりづらいといった問題もありました。そのため、専任チームがあった方が活動しやすくなると思い、提案してみたところ、生産性向上チームが立ち上がったという経緯があります。
開発生産性向上チームにおけるミッションやOKRの設計は？
──続いては、開発生産性向上チームにおけるミッションやOKRについて、それぞれお聞きしていきたいと思います。
山田：ミッションは、ソフトウェアデリバリーの根幹に関わる領域において、継続的デリバリーとFeature Flagマネジメントにより、仮説検証を早めることだと考えています。
継続的デリバリーの分野に関しては今、GitOpsをサポートできる「PipeCD」というプロダクトを開発しています。GitOpsというのは、例えばKubernetesなどのマニフェストファイルをGitで管理して、その状態を定義し、各クラスターにデリバリーできるといったスタイルです。
もう1つ、「PipeCD」を開発しているチームのほかに、「Bucketeer」というプロダクトの開発を担っているチームがあります。「Bucketeer」は、Feature Flagマネジメントを通じて、トランクベース開発のスタイルの定着に使えるプロダクトです。
OKRについては、最初の頃はこれらのプロダクトをどれだけの事業に導入できるかを、KPIとして置いていました。ただ、どうしても各事業部で使い方の程度に差があるので、数を追っていくのは本質的ではないなと感じました。
我々としては事業部の生産性を上げることがゴールなので、なるべく事業部側のニーズを聞きつつ、彼らができていない、かつインパクトの大きな部分を、我々のプロダクトやプラクティスで解決できるようにする。その状態目標が、1つのゴールなのかなと思っています。定量の数字も引き続きウォッチしていますが、今は定性を重視して活動しています。
──定量の数字としては、現状どういった部分を見られているのでしょうか。
山田：Feature Flagマネジメントでいうと、事業部が扱っているFeature Flagの数は、仮説検証の数に直接つながると思うので見ています。継続的デリバリーに関しては、デプロイの回数などですね。
──定性を重視することで、優先度の判断が難しくなることはありませんか？
山田：事業部の生産性を上げることを重視しているので、事業の要望に応える部分の優先度が高くなります。とはいえ、我々が作っている2つのプロダクトは既にOSS化しているので、ドメインスペシフィックな機能を作るよりは、なるべく大きな視野でオーダーに応えられる機能を作っていきたいと考えています。
場合によっては、我々のプロダクトとしてやるべきではない部分もあると思うので、そういったところはサードパーティのツールを別に作ったり、別のプラクティスを用意したり、といったコミュニケーションをしています。
──チームのミッションやOKRについて、宮田さんはいかがでしょうか？
宮田：生産性向上チームでは、多様で価値あるサービスを迅速に提供するための開発基盤整備、改善活動支援をミッションとしています。具体例としては、開発基盤であれば、例えばAWSのマルチアカウント管理をしたり、CI/CD基盤を構築して社内向けにサービスとして提供したりしています。
改善活動では、例えば「CI/CDのこういうところで困ってます」とか、「E2Eテスト自動化に取り組みたいけど、ノウハウがなくて困ってます」といった相談を受けて、一緒に手を動かしながら改善活動を支援しています。
OKRに関しては、今のところ定量的には追っていません。最終的なゴールは、顧客に提供する価値を最大化することですが、そこに至るまでの変数が多すぎて、どれか1つを定量的な目標にするのは難しい。そのため、現状では定量的な目標を設けていない状態です。
一方で、Four Keysのような定量的な指標があると、改善活動を推進するうえで、コミュニケーションの円滑化につながりそうだと感じているので、今後取り組んでいきたいと考えています。
どこまで支援している？具体的な開発支援のスコープ
──続いて、開発生産性向上チームの具体的な開発支援のスコープについて、それぞれお伺いしてもよろしいでしょうか？
宮田：まず大きな枠として開発基盤の提供があり、具体的にはAWSの管理・提供を行ったり、CircleCI ServerやGitHub Actionsセルフホストランナーなど、社内で手軽に使えるCI/CD基盤の構築を行ったりしています。これらの利用は強制ではなく、各チームで使ってもらってもいいし、自由に他サービスを選んでもいいという形にしています。
そして、改善活動の支援については、最終的には開発チームが自立して改善を進められるようにすることが目標です。なので、生産性向上チームで全部やってしまうのではなく、一緒に手を動かしたり、質問や相談に回答したりという形で支援することが多いですね。
また、ナレッジのインプットやアウトプットは業務時間内でできるようにしたいので、Productivity Weeklyという社内イベントを週1で開催しています。そこでは、生産性向上チームに限らず、プロダクティビティの話題に興味ある人がネタを持ち寄って共有して、最終的にはブログ記事にして社外に公開したりしています。
──これまで、開発チームから特に良い反応をもらった支援はどういったものでしたか？
宮田：やはりCI/CDの改善などは、喜ばれることが多かったですね。実行に数時間単位でかかっていたテストを上手く短縮して、数十分とか数分にできたりすると、かなり喜ばれていた印象です。
──開発支援のスコープについて、山田さんはいかがでしょうか？
山田：我々はベストプラクティスの開発が非常に重要だと考えています。ツールを2つ開発しているので、ツール開発がスコープだと思われがちなのですが、サードパーティのツールでもそれが実現できれば問題ありません。プラクティスを開発していて、その結果として内製ツールが生まれたという形ですね。
我々はプラクティス定着を支援していくために、事業部に直接導入を支援をしたり、相談しやすい環境づくりを行ったりしています。それから、弊社も社内で勉強会やカンファレンスが実施されているので、そういった場でメンバーが発表して、ナレッジの共有に努めています。
──プラクティス定着の支援をしていく意識は、当初からあったのでしょうか。それとも、ツールを開発していくなかで、必要だと感じられたのでしょうか？
山田：プラクティスの思想は最初から強かったと思います。もともと「PipeCD」を作るときも、事前にいろいろな部署の人たちにアンケートを取ったりヒアリングをしたりして、継続的デリバリーの部分に課題があるとわかり、最初はArgo CDを社内でマネージドして提供しようかといったところから始まりました。
ただ、Argo CDはKubernetesのデリバリーシステムなのですが、社内だとECSやLambdaなど、さまざまなプラットフォームでアプリケーションが作られているという事情があります。KubernetesやECS、Lambda、CloudRunなどいろいろありますが、それらすべてを同じ体験でソフトウェアデリバリーを行う仕組みが大事だという話になり、そういったツールがないので作ることになりました。
──先ほどOSS化のお話も出ていましたが、社内に閉じずOSSで公開していくことになったのは、どういった経緯だったのでしょうか？
山田：我々はいろいろと社内基盤を作っては消え、ということを繰り返していて、なぜそれが起きるのかを改めて考えたところ、中に閉じていることが原因ではないかと思ったんですね。最初は、何らかの課題を解決するために生まれたものですから、短期的には課題を解決できますが、市場ではどんどん競合するプロダクトが出てきます。すると、社内で2～3名で作っているような基盤では、太刀打ちできずに競争力を失ってしまいます。
そこで、初めからOSSとして出すことで、早めに市場認知を獲得しようと。そのうえで、オープンソースの開発コミュニティを広げていき、なるべく少ない人数でも市場価値を保ちつつ、競争力を発揮する。そういった点で、OSS化が1つの有効な手段だと思っています。
開発生産性向上の取り組みを通して、組織で起きた変化は？
──続いては、開発生産性向上への取り組みを通して、組織でどういった変化が起きたかをお聞きしたいと思います。
山田：これはOSSの良さの1つですが、実際に社内でツールを使ってくれている人たちが、足りない機能やバグがあったときに、ソースコードを見てパッチを当てるプルリクエストを送ってくれるようになりました。さらに、機能リクエストもどんどん上げてくれるようになったところが、良かったと思っています。
事業部側でツールを使い倒して、ファンになってくれる方もちらほらいて、そういった人たちが我々の知らないところで、どんどん普及させる活動をしてくれることが増えてきたのも、良い動きだなと思います。
──DP室の取り組みを通じた改善について、事業部側からは特にどういった声がありましたか？
山田：継続的デリバリーでいうと、プログレッシブデリバリーの機能などですね。閾値を設定しておいて、リリースしたことによってバグや障害が上がったら、勝手にロールバックするという賢いデリバリーの仕組みなのですが、それが簡単に実現できるようになって嬉しいという声をもらったりしています。
──宮田さんは、組織の変化についていかがでしょうか？
宮田：最初は、生産性向上チームが改善活動を請け負ってしまって、短期的にはそれで良くても、途中からその部分の改善を我々がやらないと進まなくなり、サイロ化してしまう問題がありました。
ただ、途中から開発基盤をサービス的に提供したり、各チームが自立して改善を進められる方向で支援したりするように変えていったところ、組織内にいる改善活動をやりたい人が積極的に進めてくれるようになりました。我々が抜けた後も、どんどん改善活動が進んでいくようになり、スケールする形に変わっていったと感じます。
──各チームが自立して改善するというのは、文化的なところまで変化が及んでいるように感じられますが、それが進んだ要因や背景はありましたか？
宮田：当初はあまりリリースのデリバリーサイクルを早めることに興味がなかった人も、世の中的にFour Keysなどが盛り上がり、徐々に機運の高まりがありました。そのような流れに上手く乗っていけると、スケールしやすいと感じますね。生産性向上チームが旗を振る役目をして、場を設けたりするだけでも、すごく意味があるなと思います。
──参加者の方からのご質問で、「内製ツールには、保守運用リソースや属人化などのデメリットも存在すると思いますが、苦労した点や工夫した点があれば知りたいです」といただいています。
山田：我々も少人数でやっているので、そこはまさに現在進行形の課題です。ただ、DP室以外にSREを担当している部署などもあるので、最近はそういった人たちにも運用をサポートしてもらっていて、サイバーエージェントのリソースを上手く活用できる体制になりつつあります。
──もう1ついただいている質問で、「サイボウズさんの各チームで自立して改善を進めるように支援するというのは、具体的にどのような形でしょうか？」とのことですが、いかがでしょうか。
宮田：単純な内容であれば、相談に乗って回答して、改善は各チームにやってもらうようにしています。難しいケースであれば、一緒に手を動かしながら改善の方向性を探っていきます。そして、ある程度まとまったら、定期的に話を聞くだけにして、生産性向上チームが必要なくなったらフェードアウトし、あとはそのチームだけで進めてもらうというケースが多いです。
取り組みのなかで、困難だったポイントと学びになったポイント
──ここまで取り組みについてお聞きしてきましたが、そのなかで困難だったポイントと、学びになったポイントについて、それぞれお伺いできればと思います。
山田：難しいポイントの1つとして、生産性向上に関する議論の難しさがあると思います。最近、全社の施策として開発生産性を上げていくことが決まり、DP室が牽引する活動のなかで「開発生産性のどんなところを上げたいですか？」というアンケートを取ったのですが、思ったよりバラバラな回答になったんです。
我々としては、ソフトウェアデリバリーが重要だと思っていたのですが、事業ドメインによっては全く違ったりするんですね。例えば、ゲームであれば最初のリリースまでのサイクルがすごく長いので、モックをいかにたくさん作るかに生産性を置いていたりします。
それから、組織ではなく個人としての開発生産性と捉える人もいて、そこまで行くともう“主語でかワード”なので、議論がすごく難しい。仕事量を開発生産性として捉える人もいれば、生産性向上活動によってどれだけの付加価値が出せるかに意識が向いている人もいて、そうしたレベルの違いによる議論の難しさもあると感じています。
加えて、もともとエンジニアとして「生産性を向上することは正しい」という先入観があったのですが、実はそれを重要視しない人もいる、ということがアンケートからわかりました。それ以外の困難だったポイントとしては、先ほどもお話していた事業開発の支援とOSS開発の両立ですね。
学びになったポイントとしては、我々が持っているツールやプラクティスをちゃんと使ってもらうために、適切に情報をばらまくという開発者マーケティングのところ。ドキュメントなどもそうですが、なるべくユーザーが意識せずに必要な情報にリーチできるような情報設計は、すごく重要だと思っています。
──生産性向上をあまり重要視しない方々というのは、開発やプロダクトのフェーズがバックグラウンドにあるケースが多いでしょうか？
山田：まさにそうです。リリースサイクルがビジネスベースで決まっているケースもあるので、そういった事業に関しては、「今できているからいいじゃないか」と言われてしまうと、何も言えません。
ただ最近、私が言い始めているのは、平時の生産性と有事の生産性の2つがあるということ。平時に関しては、「2週間のリリースサイクルで回っているからいいじゃないか」で通じますが、1年に1回くらい、ものすごく大きなセキュリティインシデントが起きたりしますよね。
そうしたときでも、リリースサイクルをちゃんと保てるかと言われると、おそらく保てない。そういったところも余裕があるときにちゃんと取り組んでいくべきだと考えているので、これから啓蒙していきたいと思っています。
──生産性向上の目線がなかなか合いにくいというお話がありましたが、目線をそろえるためにされた議論などがあれば教えてください。
山田：活動によってどれだけ付加価値が生まれるかという部分がすごく難しくて、変数がありすぎるので、なかなか定量化できません。そこを議論してくれる人もなかにはいますが、全員がそこに目を向けるわけではないですから、すべてのエンジニアに対して付加価値について問うのは少し違うのかなと思っています。
そのため、エンジニアに伝えるときは、シンプルに仕事量をどれだけ減らすかにフォーカスするのが良いのかなと。付加価値については、そこに興味がある人たちが上手く翻訳して、経営陣などに伝えていくことが大事なのではないかと思っています。
──困難だったポイントと学びになったポイントについて、宮田さんいかがでしょうか？
宮田：困難だったポイントの1つ目は、チームメンバーの採用です。当初は自分1人のチームで、かつ当時まだあまりプロダクティビティチームも存在しない時期だったので、いったいどこに行けばこうした活動に興味ある人に会えるのかと、難しく感じていました。
そのため、まず種まきとして行ったことが、情報のアウトプットですね。ブログ記事を書いたり、登壇したり、自分たちでイベントを開催したりなど、いろいろやりました。そうすると、活動を見て話を聞きに来てくれる人が増えますし、ファインディさんにもお世話になりながら、興味がありそうな人にこちらから話をしに行ったりして、少しずつ人を増やしてきました。
困難だったポイントの2つ目は、割り込みが多くなりがちなところ。やはり開発基盤を組織横断で運用していくとなると、何か問題が起きたらどんどん問い合わせが来るようになりますし、改善活動の支援でもいろいろな質問や相談が来ます。そのため、「今期はこれに注力するぞ」と思っても、割り込みが多くなって、なかなかやりたかったことを進めにくくなります。このあたりは、現在も試行錯誤中ですね。
学びになったポイントとしては、アウトプットの大事さです。採用においても、社内の改善活動支援においても、やはり情報をアウトプットしていると、「サイボウズって実は、こういう改善活動してたんだな」と伝わります。改善活動をするときも、「このブログ記事、参考になりました」と言ってもらえたりするので、地道なアウトプットはとても大事だと感じています。
加えて、開発生産性向上への意欲が強い開発者は、思った以上にいるということですね。そういう人にチームに入ってもらうことも大事なのですが、各組織内にいる意欲が高い人たちと、上手く連携を取りながらスケールする改善活動につなげていくことが重要です。そういう人たちのことを意識して、上手く働きかけたり場をつくったりして、取り組んでいけると良さそうだなと感じています。
今後の注力ポイントの1つは、Four Keysの共通基盤での可視化
──それでは最後に、両社の今後の注力ポイントについてお聞きしたいと思います。
山田：定量指標としてFour Keysが流行ってきて、我々の会社も各事業部でFour Keysを立てる動きがあるので、しっかり共通の基盤を用意してあげるところが、まず1つかなと思っています。
また、全社的な施策として生産性を上げていくことに今取り組んでいるので、GoogleのDORAが毎年出しているDevOpsにおけるケイパビリティのチェックリストを自社向けにカスタマイズして、各チームで今どういう状況にあるのかをチェックしてもらい始めています。
──Four Keysでの可視化を定量的に進めつつ、定性的にケイパビリティのチェックもして、両面から見ていくというイメージでしょうか。
山田：そうですね。Four Keysで数字を追っていくのもいいのですが、生産性活動でいうと目標を立てるのが難しいので、ケイパビリティのような定性的なものがあると、目標設定がしやすいと思っています。
──今後の注力ポイントについて、宮田さんはいかがでしょうか？
宮田：我々も同じく、共通基盤でのFour Keysの可視化に取り組んでいきたいと考えています。そして、可視化した後には、各チームが目標を達成するために今どういう問題があって、その問題を解消するためにどういう支援が必要か、組織横断でどのような開発基盤があったらいいかなど、改善活動が進んでいくコミュニケーションにつなげていきたいと思っています。
──もう1つ、参加者の方からご質問をいただいています。「Four Keysの取得基盤ができたとして、プロダクトの種類やクライアント、バックエンドなどの違いによって、有利・不利な指標が生じてしまう可能性があると思います。どのメトリクスをFour Keysにどう当てはめるかのカスタムも必要になるでしょうか？」とのことですが、いかがでしょうか？
宮田：Four Keysは、他チームと比べて相対的に評価するメリットは薄いと感じています。質問者様が書かれている通り、プロダクトの種類や使っている技術、コンテキストによって目指すものは変わってきますし、やりやすさも変わってきます。なので、それぞれの理想の状態を設定して、そのためにどういった活動が必要か、どの指標が理想かを考えていけるといいのかなと思います。
山田：コンテキストの違いがあるので、こうした可視化の施策を行うときに気をつけたいのは、他と比較しないということですね。大事なのは、過去の自分たちと比較してどう伸びているかです。可視化すると、経営陣が横並びにして見たがるところですが、それはさせないことが大事です（笑）。
──お時間となりましたので、本日のイベントは以上とさせていただきます。山田さん、宮田さん、ありがとうございました！
※本イベントのアーカイブ配信（無料）はこちら
登壇企業様からのお知らせ
ファインディからのお知らせ
ファインディでは、Four Keysの可視化や、開発生産性向上をサポートするサービス「Findy Team+」を提供しております。現在、2週間無料トライアルも受け付けております。
