国内最大のビジネススクール「グロービス経営大学院」やビジネスを学べるオンライン動画サービス「GLOBIS 学び放題」を展開する、グロービス。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。

今回は、グロービスでVPoEを務める末永さんと、エンジニアリングマネージャーを務める大沼さんにインタビュー。開発チームにおける課題や取り組み、「Findy Teams」導入のきっかけなどについて伺っていきます。

開発組織の初期メンバーとして、グロービスへ入社

ーーまず最初に、お二方のこれまでの主な経歴を教えていただけますか？

末永さん：前職では、教育系のスタートアップにいました。実力不足もありますが小さい組織で世の中に与えれる影響力をあまり高くできなかったことに課題を感じて、大きな会社でスタートアップに近い動きができれば、もっと大きなことが実現できるのではないかという思いから、グロービスに入社しました。

入社したのは、2016年。当時のグロービスにはエンジニアがおらず、1人目のエンジニアとして入社しました。「GLOBIS 学び放題」というプロダクトの開発から、徐々にマネジメントの役割に移り、現在はVPoEとして開発組織全体のマネジメントを担っています。

大沼さん：もともといくつかのベンチャーで働いていて、その中で課題に感じていた効果検証や技術負債の解消に課題を感じていました。組織拡大するためにはどのような問題を解決すべきかを知りたいと思い、グロービスにジョインしました。入社したのは、組織が拡大していくタイミングの2017年で、エンジニアとしては5～6人目でした。

ーー御社の開発チームの特徴について教えてください。

末永さん：事業会社として、ユーザーとしっかり向き合ってプロダクトを開発しているところが特徴です。開発チームとユーザーの皆さんとのユーザーコミュニティがあるので、ユーザーの声を聞きながら近い距離で開発ができるのは、すごく面白いと思っています。

開発のスタイルとしては、スクラムを全般的に導入しています。スクラムチームの数は、現在6チームほど。スクラムは1チームごとの運用になるので、組織全体としては、Scrum@Scaleという大規模スクラムのフレームワークも取り入れています。

大沼さん：組織全体をメトリクスで見て、早期に課題発見する取り組みを大事にしています。「Findy Teams」導入のきっかけにも関わるところですが、組織全体でDevOps指標などを見える化していく動きがあります。

0人から120人へ、6年で大きく拡大してきた組織

ーーここ数年で大きく組織が拡大されたと思いますが、現在の規模はどれくらいですか？

末永さん：僕が入社した6年前、エンジニアは0人でしたが、今はデザイナーなどを含めたテクノロジー職全体で、120人くらいになっています。拡大していく中で、いわゆる30人の壁、50人分の壁を感じる場面もありました。

ーー現在の120人という規模の組織で、意識して取り組まれていることはありますか？

末永さん：今感じているのは、100人の壁です。チームに分かれていくほど、その中で起きている問題に気づきにくくなるので、いかに早く問題を発見するかが肝になります。 各チームが改善に向けて動くだけでなく、大規模スクラムのフレームワークの中で、そのナレッジを横に伝播させていけるような情報共有の仕組みも大事だと思っています。

大沼さん：組織が拡大していくと、2～3人の規模でやっていた開発スタイルとは大きく変わってきました。2～3人で開発しているときは絶対に1日に数回はデプロイしていましたね。

ところが規模が大きくなってくると、リリース当番ができたりする。リリース当番ができるとリリース頻度が週に1回以下になり、リリース作業自体の負荷・リリースへの心理的障壁が上がってしまうためエンジニアとしては自分のプロダクトをコントロールできないような印象を持ってしまいます。

そうした方向性に行かないように、スタートアップのような開発スタイルを、今の規模に適応していくことを意識しています。

デプロイ頻度を上げることで、精神的な負荷を下げる

ーー開発チームにおける課題や、それに対する取り組みについて教えてください。

大沼さん：一番大きな課題だったのは、デプロイが週に1回だったことです。それが約2年前で、例えばお正月明けになると、休み前にコードフリーズしていたこともあり1回のデプロイでFile Changedが300オーバーのリリースPRがデプロイされていたんです。そうなるとエラーが起きても何が原因かわかりづらいですし、デプロイするときに胃が痛くなるんですよね。なので、都度デプロイにしていくための取り組みを始めました。

ただ、中にはQAプロセスをしっかりと通して、週に1回デプロイした方が良いと考える人もある程度いたんです。なので、しんどい作業ほど多くこなし、負荷を分散していくというDevOpsの考え方を言語化して、もし問題が起きたらロールバックして、その影響を最小限にすべきだということを伝えていきました。

※Qiita：胃が痛いビッグバンリリースはもう嫌なので、デプロイを日常にする

ーー現在のデプロイ頻度はどれくらいですか？

大沼さん：指標としては、1日あたりのデプロイ回数を開発者数で割った「d/d/d」（deploys / a day / a developer）を1ヶ月単位で追っていて、その数値が0.1から0.2あたりになっています。0.1以上で健全と言われているので、今はこれをキープしていきたいですね。

ーー週に1回のデプロイが良いと考えるメンバーもいた中で、どのように取り組みを進めていったのでしょうか？

大沼さん：リポジトリを触っているチームは2～3チームありますが、いきなり全体に適用せず、まずは自分チーム内から進めました。そして、実際に運用が回ってきたところで、他チームの人と今起きている問題について話し、復元力の高いシステムを作っていく方向で認識を揃えていきました。

あと、スプリントレビューが週に1回あるんですが、スプリントレビューで通らないとリリースしにくい雰囲気だったんです。この条件があると週に1回でデプロイが固定されてしまうので、POレビューでOKだったらリリースするフローに変えていきました。

ーーデプロイ頻度が高くなったことで、組織的に変わったと感じる部分はありますか？

末永さん：デプロイ頻度が高まったことで、開発が活性化している雰囲気がすごく出たと思います。リリースの通知が日常的にSlackに流れてきて、開発がどんどん進んでいることが見えるようになりました。

やはり組織が大きくなるほど、何かを変えようとする動きがなかなか取りにくくなります。でも、小さなチームで意思決定して、それが良い形に進めば、横のチームに広がっていく。大沼さんにファーストペンギン的に飛び込んでもらったおかげで、他のチームも動いていく流れができたのは、組織としてすごく良いことだと思っています。

生産性を可視化し、ビジネスサイドや経営陣にも共有

ーー取り組みを進めたことで、ビジネスサイドとの関係性が変化した部分はありましたか？

大沼さん：半年から1年くらい前までは、仕様は詰まっているのに、開発が追いつかない状況がありました。ところが最近は、要求定義や要件定義が間に合わないことが増えてきています。グロービスはステークホルダーが多く、いろいろな意見を集めて仕様を決めるのは大変な作業なのですが、そこにボトルネックが移動してきたんですね。

僕としては、それはすごく良いことだと思っています。そこにボトルネックが移動したのであれば、今後もっとエンジニアだけで仕様が決められる領域を増やすとか、ふわっとした要望から仕様に落とす仕組みを作っていくことなどを検討していけると考えています。

末永さん：とはいえ、エンジニアの生産性に対する疑問も、出てくることはあります。やはり組織が大きくなってきたときに、少し離れたチームから眺めると、なかなか動きが見えづらかったりするものなんですよね。

ただ、開発スピードが速いか遅いかというのは感覚論で、人によって基準が違います。ここをしっかり可視化して共通認識を持つことがすごく大事だと思っていて、「Findy Teams」の数値は今かなり活用させてもらっています。

例えば、月に1回ある部門全体の共有会で、開発のリードタイムがどれくらい短くなったかを報告したり。大沼さんのチームでは、この間5倍くらい短くなったという話もありました。そうやって、しっかり可視化して伝えていくことが重要だと思っています。

ーー経営陣の方々に、数字で伝えやすくなった部分もありますか？

末永さん：そうですね。先日、「Findy Teams」の勉強会を開いていただいて、その場に経営チームの方々にも出席してもらったんです。経営チームからも、いろいろなコメントが出てきて非常に良かったです。

「Findy Teams」を活用し、良い取り組みを横へ広げていく

ーー「Findy Teams」を導入いただいた、きっかけを教えてください。

末永さん：指標としてd/d/dを追っていましたが、ウォッチはできても、具体的な改善に繋げるのが難しくて。大沼さんのチームでは、d/d/dを上げることができていましたが、他のチームは十分に上がりきっていない状態でした。 そこで、もっと使いやすく改善に繋げやすいサービスがあればと思っていたところ、既にサービスを使っている会社さんの話を聞く機会があり、無料トライアルを経て導入することを決めました。

ーー「Findy Teams」の主な活用方法について教えてください。

末永さん：週次の開発マネージャーが集まる場などで、「Findy Teams」のスコアを見ています。最近面白かったのは、サイクルタイム分析で、全チームをプロットすると、チームの特色が出てくるんですよ。

例えば、新規事業のチームはPOの意識決定が速いので、そのプロセスが速かったりとか。安定的なチームやスピードを大事にするチームなど、さまざまな比較が出るので、そういった部分も見ながら、マネージャーの方々と改善を進めていこうとしています。

大沼さん：「何をやったら、どれくらい良くなった」という内容を、共有していくことが大事だと思っています。DevOpsのベストプラクティスを見ると、レビューを出したらすぐに見るようにするといった文化的なことが7割くらい、CI/CD関連が3割くらいだと思います。

そういった内容を、SoS（スクラムオブスクラム）、SoSoS（スクラムオブスクラムオブスクラム）の場（大規模スクラムにおけるスクラムマスターの横連携の場）や全体会議などで共有することで、どんどん横へ広げていきたいと考えています。

顕著だった例でいうと、ペアプロをやっているチームは、レビュータイムがかなり速いということが明確に見えたりしていましたね。

チームが自ら課題を発見・改善するために活かしたい

ーー今後の「Findy Teams」の活用イメージがあれば教えてください。

末永さん：「Findy Teams」を導入したとき、最初は3チームで導入しました。そこから使っているチームがかなり増えてきている状況です。導入する際は、使いたいチームから声が上がってくる流れの方がより使い込んでくれると思っています。

もし全チームが使う状態になれば、「Findy Teams」を中心にいろいろなコミュニケーションが進んでいくと思いますし、数値的にも良い取り組みだとわかってくると思うので、今後より横に広がっていったら良いなと思っています。

大沼さん：健康診断のような感じで、「Findy Teams」を使って、チームが課題を発見していけると理想ですね。そうすると、チームで自ら改善していけると思うので。ボトルネックが何なのかを、自分たちで把握することに活用できると良いと思っています。

ーー今後の「Findy Teams」に期待することはありますか？

末永さん：僕らが導入した当初は、Four Keysもサイクルタイムもありませんでしたが、今ではそのあたりが網羅できているので、本当にリリース頻度が高くてすごいなと思います。

今後は他社のデータとの比較が、より見えてくると良いですね。僕らは強い開発組織をつくっていきたいので、世の中の平均よりも、Four Keysのエリートやハイパフォーマーくらいのトップ層と比較したいと思っています。

また、メンバーの自発性を大事にしたい僕らとしては、トップダウンで目指す数値を決めたり、それを評価に繋げたりもあまりしたくありません。なので、そういう比較できるものがあって、それぞれに自分たちで目指すところを決められるサービスになると理想的です。

日本発、世界をリードするEdtechカンパニーになる

ーーそれでは最後に、今後目指していきたい開発チームの姿について教えてください。

末永さん：僕らは「日本発、世界をリードするEdtechカンパニーになる」というビジョンを掲げています。なので、世界クラスのテックカンパニーに相応しい開発力を持つチームをつくっていきたいと考えています。

今年は採用にもかなり力を入れているので、規模もさらに拡大していく見込みです。規模を拡大するとアジリティが落ちてしまうという課題感はよく聞きます。規模を拡大しつつも、生産性を維持できる組織を「Findy Teams」も活用しながら考えていきたいですね。

大沼さん：よくスクラムで「スケールする前に、まずは2つ良いチームをつくる」と言われますが、中途半端な状態で拡大するとパワーが低いまま、それが横展開されてしまいます。そうすると、規模が大きくなっても十分な効果が出ないので、採用で人を増やすことと両軸で、もっとチームを良い状態にしていくことが大事だと考えています。

そのためには、DevOpsを当たり前にしていくことが重要で、健全な状態として目指すべき指標の認識を合わせながら横展開していきたい。それによって、人が増えても生産性を維持できる組織を実現していきたいと考えています。

ーー末永さん、大沼さん、ありがとうございました！

※Findy Teamsのサービス詳細は以下よりご覧いただけます。 https://findy-teams.com/service_introduction