エンジニア1人から始めた開発生産性改善が、組織100名、経営をも巻き込んだ話

2023年7月13日、ファインディ株式会社が主催するイベント「開発生産性Conference」が、開催されました。本カンファレンスは、KABUTO ONE（東京）のオフライン会場にて実施され、一部のセッションはオンライン配信も行われました。

本記事では、オンラインでも配信されたセッションのうち、株式会社グロービスの末永さんと大沼さん、株式会社レクターの広木さんによる「エンジニア1人から始めた開発生産性改善が、組織100名、経営をも巻き込んだ話」の内容をお届けします。

このセッションでは、グロービスでの事例をもとに、開発生産性への取り組みを推進するにあたって、経営層やビジネスサイドをどのように巻き込み、合意形成していくのかについて、パネルディスカッションが行われました。なお、本セッションは、昨年に開催された『週1デプロイを都度デプロイに変え、100人の壁に挑戦中のグロービスのエンジニア組織作り』から1年がたった株式会社グロービスの取り組みを元にしています。

■登壇者
株式会社グロービス VP of Engineering
末永昌也（すえながまさや）/ @sue738
東京工業大学大学院情報理工学研究科修了。グロービス経営大学院経営学修士課程修了。Startup Weekend世界大会入賞を機にEdTechサービスを手がける株式会社LOUPE（現ARROWS）を共同創業。CTOとしてプロダクトの新規立ち上げ、技術リードを行う。グロービスに入社後は定額制動画学習サービス「GLOBIS 学び放題」等の立ち上げに携わり、現在はグロービス・デジタル・プラットフォームにおける開発全般の統括を行う。

株式会社グロービスエンジニアリングマネージャー
大沼和也（おおぬまかずや）/ @technuma
6年間、3社のベンチャー企業でインフラからフロントエンドまでシステム開発に従事した後、株式会社グロービスに入社。「GLOBIS 学び放題」「GLOBIS Unlimited」などオンライン学習サービスの開発に携わる。バックエンドエンジニアとして入社し、チームの課題を解決するためにスクラムマスターを経て、現在はエンジニアリングマネージャーを務める。

株式会社レクター代表取締役
広木大地（ひろきだいち）/@hiroki_daichi
2008年に株式会社ミクシィに入社。同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。株式会社レクターを創業。技術経営アドバイザリー。著書『エンジニアリング組織論への招待』がブクログ・ビジネス書大賞、翔泳社技術書大賞受賞。一般社団法人日本CTO協会理事。朝日新聞社社外CTO。

■モデレーター
ファインディ株式会社 CTO
佐藤将高 / @ma3tk

グロービスの開発生産性における、これまでの取り組みと現在

――皆さんこんにちは、ファインディCTOの佐藤です。本日は、グロービス社での事例をもとに、エンジニア組織を超えてどのように合意形成し、開発生産性を高める動きをしてきたのかについて聞いていきたいと思います。まずは、登壇者の皆さんの自己紹介からお願いいたします。

末永：グロービスの末永と申します。私はVPoEとして、経営に近い立場を担っています。今回の「エンジニア1人から始めた」という話の主人公は大沼なのですが、どういった連携をしてきたかなど、お話できればと思っています。よろしくお願いします。

大沼：グロービスのエンジニアリングマネージャーをしております、大沼と申します。経営サイドを末永さんに見ていただいて、僕は現場寄りのエンジニアリングマネージャーとして働いています。自分としては、1人から動けるところが結構多いなと感じているので、そういったところを今日はご紹介できればと思います。よろしくお願いします。

広木：広木です。レクターという会社をやっています。今日はさまざまな会社のなかで見てきた開発組織の生産性の話と絡めつつ、グロービスさんの事例についてコメントしながら盛り上げられたらと思います。よろしくお願いします。

――本題のパネルディスカッションに入る前に、これまでのグロービスさんの開発生産性に関する取り組みについてお伺いしたいと思います。

大沼：グロービスでは、まずデプロイ頻度の計測と改善から始めて、それからリードタイムの計測や改善も進めました。以前は、週に1回のデプロイが普通だったのですが、それによって変更するファイルの量や行数が、どんどん溜まってしまう状況がありました。

1つのリリースに複数の変更が溜まると、何か問題があったときに、エラーが発生している箇所の特定が難しくなります。そういった背景から計測を始め、改善を進めていったことで、1週間に30回くらい、1日に複数回のデプロイを行えるようになりました。

リードタイムは、コミットしてからプルリクエストを作成し、マージされるまでを定義しています。これにもともと127時間ほどかかっていたのですが、32時間に短縮。今はさらにリードタイムを短くできていて、より高速に開発できる状況がつくれています。

大沼：そして、現在の取り組みとしては、さらに品質面にもしっかり取り組んでいこうと考えています。今取り組んでいるのが、MTTRや変更失敗率の計測と改善です。それから、SLOプロジェクトですね。ここはSREチームがすごく課題感を持っているところだったので、あわせて取り組んでいます。

全体としては、今はリクエストが500ミリ秒以内を8割というのを定義しています。そこからサービスの重要なアクション、例えばログインや動画の再生といったアクションごとに、SLOを設定しようとしています。

また、障害対応のフローが人によるなど、フローの画一化ができていないので、障害対応フローの整備も行っています。最終的にはbotなどに落として、誰でもこのフローであればだいたい間違いない、というところを目指しています。

経営陣とのコミュニケーションにおける課題と取り組み

――続いて、経営まわりについても、これまでの取り組みを伺いたいと思います。どういったコミュニケーションの課題があったか、どう乗り越えたいったのかについて、末永さんからお願いします。

末永：経営陣とのコミュニケーションのなかで、まずよく出てきたのが「開発が遅い」という内容です。開発チームには強いメンバーがそろっているし、僕は開発が遅いとは全然思っていないんですよ。でも、優先度が落ちたものがなかなかリリースされないことが結構あるので、外から見ると開発が遅いという印象になってしまうことがある。ここのマインドを変えていくところがすごく大事だったなと思っています。

また、こうしたイベントではどこでも、小さく作ることが正義だと話されていると思いますが、経営陣からは「小さく作ってほしくない」と言われたり。これは、計画がよくわからなくなるから、という話ですね。

あと、やっぱり「デプロイ頻度を上げるという意味あいがわからない」んですよね。デプロイ頻度を高めたら、経営上の意味合いとしてどう影響するのかを理解するのが難しい。大きくこの3つは、経営陣とのコミュニケーションの課題として、ずっとあったのではないかと思っています。

末永：これを踏まえて、どんなことに取り組んできたかというと、まず1つは経営チームのアジャイルマインド強化。この取り組みで1つ大きかったのが、プロダクト内のPO研修に経営チーム全員を派遣したことです。やはり知識として知っていることと、体験として知ってることは全然違いました。

それから、広木さんが書かれた『エンジニアリング組織論への招待』という本がありますが、実際にその本で経営チームと読書会をしたりもしました。また、OKRにもフロー効率向上を入れています。皆さんであれば、リソース効率とフロー効率についてわかると思いますが、こうした言葉の説明もしっかりと行っていきました。

次に、横にナレッジが伝播する仕組みです。このセッションのタイトルにも近いですが、やはり1つのチームが小さく実績を出し、それを横につなげていくことが、経営に対してインパクトを与えていくうえで大事だと考えています。僕たちは、Scrum@Scaleという大規模スクラムのフレームワークを取り入れていて、スクラムマスター同士が集まるスクラムオブスクラムを行っています。そうした場で大沼さんのチームがやってきたことが、隣のチームにどんどん伝わっていく。このことが、非常に大きかったと感じています。

そして、最後に本当に大きかったと感じるのは、昨年「Findy Team+ Award」を受賞できたこと。やはり経営陣になかなか意味合いが伝わりづらいなかで、アワードという形で対外的に、しかもGitHubのようなファクトベースのところから評価されたことは、とても意味があったと思います。

小さく試して実績をつくる、経営サイドを巻き込む工夫

――それでは、パネルディスカッションに移りたいと思います。1つ目のテーマは、「経営サイドを巻き込んだ開発生産性の可視化と合意形成」です。まずはいろいろな会社をサポートされている広木さんから、こちらについていかがでしょうか？

広木：まず、可視化して合意形成しなければならないとき、説明しなければならないから生産性の話が出てくるのだと思うので、どこか信頼関係が崩れていたり、コミュニケーションがうまくいっていなかったりする状況があると思うんですね。そのため、その課題に対して向き合って答えていく下準備が必要かなと思います。

思い返してみると、開発生産性というフレーズは比較的長い期間、明確な指標がなかったために、エンジニアとしてもなかなか触れづらい時代が続いていました。でも、ここ数年で生産性に関して、「世の中的にはこういう考え方がある」とか、「こういうものを見える化すればいい」というコンセンサスができてきました。

そうした「世の中的にこうなんです」という説得は、通しやすい部分があると思っています。ただ一方で、先ほどもお話があったように、難しくて伝わりづらい部分もあるので、「まず入口としてこういうものがある」というコミュニケーションができることが一番大事なのかなと。生産性に関する共通言語ができてきた昨今、それをトライする良いチャンスだと思っています。

末永： 共通言語ができたことは大きいですよね。これまでは生産性と言っても、おそらく各社いろいろだったと思います。ただ、僕らも社内で「Googleが提唱している◯◯」と言ったりしますが、経営チームに対して話すとき、他社でそういう指標があるから、というのはあまり理由にならないんですよね。

そこは実績や意味合いをしっかりと具体例を出して示していく必要がある。なので、まずは1つ実績をつくっていくという、大沼さんがしてきたような活動が、すごく大事だなと感じています。

大沼：そうですね。実際「これがデファクトだ」と言ったとしても、「それってうちの組織に当てはまるの？」と返ってきてしまうことが多いのかなと感じます。それが自分たちにフィットするのかを、小さく試すことが大事だと思っています。

単にデプロイ頻度という言葉だけを聞いて、その数字が上がったと言われても、あまり実感がわかないと思うんですよ。でも、デプロイ頻度を上げる過程で、ちゃんと足回りが固まってきて、開発がどんどん進んでいる感覚がわかってくると、広まっていきやすいのかなと感じます。

――先ほど、経営チーム全員をPO研修に派遣したというお話がありました。忙しいであろう経営チームが全員参加するというのは、なかなかすごいことだと思うのですが、苦戦したポイントはありましたか？

末永：いや、経営層の方々になると「アジャイルという言葉は気になっているけど、よくわからない」という感じで、PO研修というものがあると伝えたら、案外すんなり参加してもらえました。

広木：そこはグロービスさんだから、学ぶことをおろそかにするわけにはいかないという、そういう文化もありそうですよね。

末永：あるかもしれません。でも、全員でなくとも、何人かだけでもいいと思っていて。5人くらい行ってもらったなかで、1人の方が経営チームをアジャイル化しようという提案を出してくれたんですよ。僕1人で進めようとすると、なかなか難しいですが、2人いると話を通しやすくなる。そういう仲間をつくっていくことは、すごく大事な気がします。

広木： たしかに、我々のマインドだと誰かを説得しようというときに、資料をばっちり用意して、理屈を説明したら納得してくれるだろうと算段を立てがちなところがあります。でも、もう少しウェットなところから理解や信頼を積み上げていった方が、実際には早く進むことが多いように思いますね。

「世の中的にはこうです」も入口としてはありつつ、本当に問題解決したいという思いがあって、根底となる価値観や目指したい方向性の味方ができたら、話を聞いてもらえる瞬間がくる。でも、その前に理屈を言ってしまうと、訳がわからなくなってしまうんですよね。そこは経営だけでなく、いろいろな人とコミュニケーションするときのポイントかなと思います。

ビジネスサイドを巻き込むうえで、重要なのは“信頼関係”

――続いてのテーマは、「PdM・ビジネスサイドを巻き込む開発生産性の可視化と合意形成」です。例えば、ビジネス側から機能開発を要望されることはあっても、技術的負債の解消を提案されることはなかなかないと思います。そういったリソース配分の面について、コミュニケーション上の課題や工夫などはありますか？

大沼：もともと20%くらいは技術的負債の解消に割り当てていこうと旗を振っていて、どちらかというとPdMやビジネスサイドの方には、「20%ください」ということで話は通せていました。

ただ、別のところで問題があって、スクラムでは今のスプリントゴールに対して全力疾走しているので、みんなその達成に目が向いているんですね。なので、その20%をやるくらいだったら、スプリントゴールの達成のために動きたいというマインドの人が、僕のケースでは多かったんです。

なので、負債解消に1日取ったりしようとしていたのですが、あまり上手くいかず、結局今はDeveloper Experienceチームを別で立てています。『チームトポロジー』で言われている、プラットフォームチームやイネーブリングチームに近いものですね。ストリームアラインドチームはデリバリーだけを重視して、そこと切り分けてチームをつくっています。

ただ、例えばFlaky Testがあると、ちょっと足回りが良くないなという感じになりますが、Flaky Testがなぜ生まれたかがストリームアラインドチームにフィードバックされないと、ストリームアラインドチームが新たなFlaky Testを書いてしまいます。なので、そこのフィードバックサイクルだけは担保しつつ、別チームでやってしまおうという力技で今のところやっています。

――広木さんは、エンジニア組織を超えた取り組みにおいて大事だと思うポイントなどありますか？

広木：ビジネス組織と言ってもいろいろあって、事業の何を作るかというWhatを考える人たちもいれば、例えばセールスの人たちもいるじゃないですか。そのなかで、セールス組織の生産性にあたるような数値の、新しい概念についてキャッチアップすることって、あまりないですよね。

例えば、SFAのツールのなかで今これが流行っているとかはセールス組織としてはあ流と思います。でも、エンジニアがそこに興味を持つことって、そんなにないと思うんですよ。それでも、実はある一定の組織の生産性を測る手段をくわしく知らなくても、お互いリスペクトしていたら十分なんです。

ビジネス側には2階層あって、Whatを考えている人たちからすると、それによって何か目標達成したいときに、計画を立てたいと思っています。自分のWhatを実現するために、欲しいデータがあるわけです。それを開発生産性といった別の言い方にしているだけなので、デプロイ頻度を教えられても「え？」という感じなんですよ。

本当は今我々が議論しているような開発生産性の話って、たぶんそんなに知らなくていいんです。なので、相手が計画を立てたり、成果を出したりするときに必要な情報が、何なのかを聞いてから話すべきなんですよね。

僕らもセールスの組織に、「アポイントメントあたりに対して、商談成立率が低いんじゃないですか？」と言わないじゃないですか。それと同じように、実は開発生産性というものは、我々のなかでちゃんと管理できていたらいい。だから、本当に知りたいことは何なのか、ということに踏み込んでいかないと、あまり良い議論にはならないと思います。

末永：経営が知りたいのは、「うちの開発チームはイケてるのか、イケてないのか？」ということなのかなと思いますね。

広木：それはあると思います。身近にあるものは、イケてないと思いがちじゃないですか。判断基準はシンプルで、経営者がよそから「あなたの会社の開発チーム、最近イケてるよね」と言われたら、イケてると思えるわけです。

それがゴールだと考えると、しっかりと実績や見え方を意識しなければならないという話になってきますよね。逆に、そういう議論になるということは、どこかで「イケてないかも？」と思われた瞬間があるから。

末永：信頼関係ですね。

広木：そうです。なので、本当に求められているものが生産性であることは稀だと、意識しておいた方がいいでしょう。ただ、自分たちのチームを見るために、例えば「Findy Team+」を使って開発生産性を測る。それで、自分たちが自信を持って、どんどん良いチームになっていると言える状況になったら、おそらくそれはちゃんと信頼として伝わるし、コミュニケーションできる素地が生まれると思います。

――どれだけ信頼できる組織になっているかが、このテーマではすごく大事だということですね。大沼さんから補足などありますか？

大沼：自己管理というところが近いかなと思います。先ほどの広木さんのセールスの例で、エンジニアの僕が「セールスのファネルのなかで、ここが弱くないですか？」と突っ込みを入れたとします。あまりないことだと思いますが、もし仮にそれが的を射たもので、セールスの人が認識していなかったとしたら、こちらからするとすごく不安になりますよね。

ですが、「ここまでちゃんと管理していますよ」と伝えられる内容が多くあって、しっかり自己管理しているんだなと思ってもらえれば、外から見たときにも安心できます。スクラムでいうと自己組織化という言葉がありますが、その材料の1つとして使うといいのではないかなと思いました。

参加者の方々からの質問に答える、Q＆Aタイムへ

――ここからは参加者の皆さんからのご質問に答えていきたいと思います。質問をお待ちする間に、広木さんからここまででお伝えしたい内容などありますか？

広木：いろいろ話してきて結局は信頼関係か、と思われるかもしれないのですが、結構ここは強調しても強調し足りない部分だと思っています。数字でつまびらかにしなければならないとき、それはどんなビジネスでもモニタリングのコストをかけるということで、信頼できない対象に対してのモニタリングって無駄が発生しやすいですよね。

それだけのために、我々が生産性を測らなければいけないのだとしたら、すごくナンセンスで、信用できないから監視するという話から抜け出せません。数字を測ることは、先ほど大沼さんがおっしゃったように、あくまで自己管理することが一番にあって、それによって信頼関係が得られる。このステップを忘れないことが大事かなと思いますね。

――ありがとうございます。では、いただいた質問の1つ目、「d/d/dを取るためのおすすめのツールはありますか？」ということですが、いかがでしょうか？

広木：d/d/d/とは、deploys / a day / a developerのことで、僕が過去にツイートしたものです。デプロイ回数だけで追いかけると、人数が増えたらデプロイできるエンジニアが増えていくから、ちゃんとエンジニアの数で補正して、維持すべきラインを見えるようにしましょう、というものですね。

デプロイ回数がわかれば、あとはエンジニア人数で割ればいいので、ツールとしては「Findy Team+」もそうだと思いますが、デプロイ回数を追えるものであればいいと思います。

末永：広木さんがツイートされたのが、2019年くらいですよね。あのツイートを見て、ものすごく良い指標だと思って僕らもやり始めました。

――次の質問です。「経営側からすると、売上達成するためにいつリリースできるの？くらいの粒度感だと思います。そこでエンジニア組織の開発生産性の数値はどう響きますか」という内容ですが、末永さんいかがでしょうか？

末永：そこから少し進んで、組織が100人超えてくると「いつリリースできるの？」は経営側では、あまり語られなくなってくると思っています。どちらかというと、「その人数必要なんですか？」という観点の方が強くなってきて、そこが生産性とリンクするところだったりするんですよね。

やはり僕らは対外的にも高く評価されたことが大きかったですが、中で見ていても指標が高いチームの盛り上がり感は、目に見えて経営にも届くレベルで良くなっているんですよ。エンゲージメントにもすごくつながってくると思いますし、経営側としては今そういった観点で見ているかなと思います。

――続いては、「1人から始めた開発生産性改善というところで、一番最初に着手したのはどんなことだったのでしょうか」という質問です。大沼さんいかがでしょうか？

大沼：デプロイ頻度が一番始めやすい指標だと思っていて、Gitコマンドでさっと取ることができます。僕がやったこととしては、まずGitログでコミッターの一覧を取ります。1ヶ月ごとに集計したいと思ったので、コミットログのコミットが入った日付と人の名前を取ってきて、それをスプレッドシートに貼り付けます。

あとは、リリース時にタグを打っていたので、Gitタグでタグを取ってきて、そうすると1ヶ月当たりのデプロイ数が出ます。Gitログの方は月でまとまっているので、重複排除すれば、その月に何人いたかわかります。なので、それで割れば数字が出るといった形ですね。1時間くらいでつくれるので、最初にやる分にはスプレッドシートがおすすめです。

末永：なので、d/d/dを測るのにおすすめのツールは、まずはスプレッドシートから。

大沼：そうですね。本格的にやっていくとなったら、「Findy Team+」のようなツールを使ったりすると、より良いのではないかと思います。

――続いての質問は、「SREチーム起点でSLO設定を進めているとありましたが、ビジネスサイドの巻き込み方で工夫や苦労された点はありますか？」という内容です。こちらも大沼さんいかがでしょうか？

大沼：SREチームがSLO勉強会を開催して、Slack上でその呼びかけがあったとき、「SLOというのはエンジニアが追う指標ではない」と書かれていたんですね。サービスやプロダクトの話なので、エンジニアもビジネスサイドも関係なく、組織一体となって追っていく指標だという、強いメッセージを伝えてくれていました。

そうやってSLOの勉強会が行われ、全員でディスカッションしたりして、ビジネスサイドも巻き込んでいった形ですね。苦労した点はあまりなく、意外とみんな理解してくれていました。組織全体で追うものだということがしっかり認識されれば、すんなり入ってもらえるように思います。

末永：SREチーム起点という言葉の通りで、あくまで起点なんですよね。今は結構ビジネスサイドの方が、オーナーシップを持ちながらやってくれています。SREチームがオーナーシップを持つのではなく、ちゃんと組織全体でオーナーシップを持てる状態がつくれていて、これがすごく大事だなと見ていて感じます。

――お時間が迫ってまいりましたので、次が最後の質問とさせていただきます。「ROIについてと、開発生産性の間にあるギャップについてどう思いますか？」という内容です。やや抽象度の高い質問ですが、末永さんいかがでしょうか？

末永：難しい質問ですね（笑）。ROIというと、わかりやすいところでは、僕らが出した価値と開発者数になるのかなと思います。なので、何人採用すべきかなどが問われるような部分ですね。

開発生産性もいろいろな観点がありますが、先ほどセッションがあったGitHubの例でいうと、僕らはCopilotを入れて、その後に実施したアンケートで一定数が「生産性が2倍以上向上した」と回答しています。そうやってちゃんと定期的に振り返りながら、個々の事例に対して、どうあるべきか会話をしていくことが大事なのではないかと思います。

――それでは最後に、グロービスさんからのお知らせをお願いします。