プロダクト品質を高め、よりスピーディに事業成長させていくために重要となるのが、開発生産性の向上である。

非IT企業でありながら2018年にプロダクト開発の内製化に取り組み、ゼロから100人規模のエンジニア組織の構築に成功した株式会社リンクアンドモチベーション​​。

同社では、 組織改善プロダクト「モチベーションクラウド」をリリースした2016年からわずか6年で、「モチベーションクラウドシリーズ」のMRRを約12.7倍となる3.28億円（2022年末）へと成長させた。

しかし、内製化に着手した当時は障害やバグが多発する状況で、高品質なプロダクト開発をするためには開発生産性の向上が鍵となるフェーズだったことから、2020年にSRE（※）チームを発足。

※Site Reliability Engineering。Webサイトやサービスの品質を向上させ、その信頼性を高める取り組み

まず開発パフォーマンスの指標「Four Keys」に則って現在地を可視化し、そのメトリクス改善を目標として掲げた上で、なぜその活動が必要なのかという目的を確認しながら組織横断でプロジェクトを推進してきたという。

結果として、リリースまでのリードタイムを16日→2日に短縮、デプロイ頻度は週1、2回→1日1回以上に増加させるなど、Four Keysの各メトリクスにおいて大幅に生産性を高めることに成功した。

今回は同社で執行役員 兼 開発責任者を務める柴戸 純也さんと、SREチームのリーダーとして本プロジェクトを牽引する川津 雄介さんに、開発生産性向上の取り組みについて詳しくお話を伺った。

開発生産性の向上を目指し、専門部隊「SREチーム」を発足

柴戸　僕は、前職でアドテク系ベンチャー企業の執行役員兼VPoEを務めた後、2018年にリンクアンドモチベーションに入社しました。現在はモチベーションクラウドシリーズの開発責任者と、グループ全体のDX推進を担っています。

弊社は非IT企業でありながら、2018年にプロダクト開発の内製化にゼロから取り組み、これまでに100名規模のエンジニア組織（開発室）を構築してきました。

▼執行役員 / 開発責任者 柴戸 純也さん

内製化前はどういう状況だったかと言うと、社内にはプログラミングを理解できる人材が全くおらず、開発のすべてを複数の開発パートナーに分散委託する体制でした。

そのため、当時は障害やバグが発生しても要因特定ができないカオスな状況だったんです。加えて、プロダクトのリリースが最優先の目標だったため、その裏側で蓄積されていた技術的負債については、みんなで解消しなければいけないと分かっていながらも後回しになっていました。

とはいえ、いずれはそれに対峙しなくてはいけません。そこで、開発チームにおける負債やメトリクスなどを「期待度」と「満足度」の2軸で整理して見える化し、当時弱みとなっていた項目の一つひとつに四半期で目標を設定しました。

▼開発チームの弱み（左上）をフォーカスポイントとして、四半期ごとに目標設定を実施

ただ、各項目を改善しようとしても、最初はなかなかうまく進まなくて。そこで、2020年に開発室全体の生産性向上を目的とした専門のエンジニア部隊「SREチーム」を立ち上げました。

※同社が2018年から取り組んだ開発内製化と組織づくりの具体は、こちらの記事もご参考ください
非IT企業がゼロから100人の開発組織を構築。MRR9.3倍、2.4億円を5年で達成した組織戦略とは​​

Four Keysで基準を統一し、信頼性を高めるためにデータ更新を自動化

川津　僕は、新卒で入社したリコーITソリューションズにて、エンジニアとして各種開発に携わった後、2021年9月にリンクアンドモチベーションに入社しました。

現在はSREチームのリーダーとして、インフラのアーキテクチャ設計・開発や、サービス開発における生産性の向上を目指した活動を主導しています。

▼SREチームリーダー 兼 プロジェクトマネジャー 川津 雄介さん

弊社のSREチームは2名からスタートして、現在は11名（内6名はアプリケーション改善）のチームになっています。柴戸さんが言うように、チーム発足当初の開発室はプロダクトをスピーディにリリースしたり、既存のプロダクトを成長させたりする観点で、他のIT企業と比べてまだまだ生産性に課題がありました。

そこで、開発室全体の生産性を向上させて、高品質かつ圧倒的な量をリリースできる体制を築くべく、大きく三つの取り組みを実施しました。

一つ目は、「開発生産性・メトリクス基準の統一」です。

まず、このような活動をする時に必ず出てくるのが「そもそも、開発生産性って何？」という話です。当時は人によってその定義や基準がバラバラで、全員で共通認識を持つことができていませんでした。なので、「僕らって生産的じゃないよね」と言っても、他社と比較して何がどのくらい低いのかが具体的に伝えられない状況だったんです。

そのため、開発メンバー全員が共通のものさしを持って改善に取り組めるように、Googleの研究チームであるDORAが提唱したFour Keysを用いて、メトリクス基準を統一しました。それによって、組織の現在地を正しく掴めるようになりました。

▼DORAが提唱した開発パフォーマンスの指標「Four Keys」（※こちらを参照し編集部が作成）

その上で重要だったのが、Four Keysにおける各項目のデータ更新を完全に自動化することです。

というのも、それまでも開発室では似たようなメトリクスを置いていて、自主的にそのデータをまとめてくれるメンバーもいましたが、他のメンバーから「このデータって最新の正しい情報ですか？」と問われることが多くて。

つまり、特に頻繁にアップデートされる項目に関しては、せっかくFour Keysで現在地を可視化をしてもそれを信じられない、という事態が起きていたんです。

そこで、Google SheetsとLooker Studioというツールを使って、各メトリクスの状態を可視化したダッシュボードが毎日自動で更新される仕組みを作りました。

▼自動でメトリクス数値を取得し、ダッシュボード化する仕組み（イメージ）

企業によっては、開発環境がGitHubではなかったり、弊社とは異なるツールで障害管理していたりすると思いますが、この仕組みならどの環境でも汎用的にダッシュボードを構築できると思います。

▼実際に作成したダッシュボードのイメージ

改善活動はボランティアではない。全員の目標にして推進力を高める

川津　二つ目の取り組みとして、みんなに自分ごととして捉えてもらうために、この改善活動が開発に携わる全員の目標であることを明確にしました。

というのも、弊社のメンバーは非常に目的意識が強くて。各チームの目標達成に向けてまっすぐ突き進む突破力が強みですが、その一方で、自チームの目標以外のことにはプライオリティを割けていないという傾向がありました。

今回の活動で言えば、「開発生産性を向上させるのはSREチームの役割で、その他のチームの役割ではないよね」といったように、組織内でセクショナリズムが起きてしまっていましたね。

加えて、全員で協力しようとは言っても、エンジニアは当然ながらそれぞれの業務に追われているわけで。「なぜ改善活動にきちんと取り組んでくれないの？」と考えるのは、僕らSREチームのエゴでしかありません。

こういった背景から、エンジニアの自律心に任せるやり方ではなかなか上手くいかないので、この改善活動をボランティアではなく、きちんと彼らの目標や仕事にするということが一番重要だと思います。

その上で、SREメンバーと各開発チームの代表者が集結する形で組織横断のプロジェクトチームを組み、その他のエンジニアの協力も得ながら、各メトリクスの改善活動を本格的に進めていきました。

また、SREメンバーが「Embedded SRE」として1ヶ月や四半期単位で各チームの一員としてジョインすることで、チームの生産性課題の直接的な改善を試みました。

これによって、当時色々なプロダクトで障害が頻発していた共通の要因を見つけることもできたので、効果的なアプローチだったなと思います。

数値達成がゴールではない。背景にあるビジョンを伝えることが重要

川津　三つ目の取り組みとして、あらためて「数値を上げる意味・目的の共有」を行いました。

これは改善活動の中で、実際に起きたある出来事がきっかけです。まず前提として、活動前は開発を始めてから本番環境にリリースされるまでのリードタイムが16日で、それを徐々に縮めていました。その上で、みんなの目標としてリードタイムを2022年末時点の9日から3日へと、さらに縮めようとしていたんですね。

そして何が起きたかと言うと、「リードタイムを3日にする」ことが目的になって、一度ブランチを作ってから時間が経ってしまった場合は、一旦それを削除して再度ブランチを作り直すことで、表面上はリードタイム3日を達成させるという現象が起きてしまって…（笑）。

よく勘違いされがちですが、リードタイムを短くするということは、一つの機能をとにかく速く作ることだけではなく、全体の工程を細かく区切ってスモールリリースを繰り返すということでもあります。

それによって、細部のレビューやテスト、開発スケジュールの調整がしやすくなり、プロダクト開発の品質が上がる。あくまでも「リードタイム3日」は目標値であって、目的ではないということがポイントです。

なので、メンバーに対しては「僕らが本当に上げたかったのは品質です。バグが起きないとか、みんなが障害におびえないで開発できる環境を作りたい。そのためにリードタイムを短くしていこう」と、目指すビジョンも含めて伝え直しました。

これは「目標数値よりも、その先にある目的をきちんと伝える」という、すごく当たり前の話なんですが、あらためて重要なことだと実感しましたね。

リードタイムは16→2日、デプロイ頻度は週1回→1日1回以上に向上

川津　これらの働きかけの結果として、活動前後で比較すると開発リードタイムは16日→2日に短縮、本番環境へのデプロイは週1、2回→毎日1回以上に増加し、開発室全体の生産性を向上させることができました。

また、日本CTO協会が定めているDX Criteriaに当てはめると、組織の評価ポイントが38.5→42.5に向上しました。

▼日本CTO協会が監修するDX Criteria（HPより一部抜粋）

特に効果が高かったと感じているのは、生産性向上の活動を始める時に、Four Keysの項目に沿って何をどこまで上げるかが事業部目標として明確に置かれたことです。

企業として成長する上では、プロダクトのリリースがトッププライオリティになりやすい傾向にあります。ですが、それ以外の障害率やサービス復元時間といった、プロダクトの基盤を支える部分も事業部目標として置かれることは、なかなか無いのではと思います。

やっぱりこの効果はすごく大きかったです。みんなが目標を意識して、それを達成しようと一丸となって動いてくれるので、活動自体も推進しやすかったですね。

柴戸　僕たちは、「Will・Can・Must（やりたいこと・できること・やるべきこと）」のフレームワークに則って、それぞれの重なりが大きければ大きいほどモチベーションが最大化されると考えています。

それは個々人のメンバーに関してだけではなく、組織全体や今回のような取り組みも一人の人格として見立てて、モチベーションが最大化されるように取り組んでいくことがすごく重要だと思っています。

今回の開発生産性を向上させる取り組みにおいては、まずCanとして「感覚ではなく可視化」して、次にMustとして「依頼ではなく協働すること」を働きかけ、Willとして「目標だけでなく、目的である目指すビジョンの共有」を大事にしてきました。

一つひとつの取り組みは小さなものに見えます。しかし、このような「Will・ Can・ Must」の観点で全員のモチベーションが高まるように工夫したことが、愚直な改善活動に繋がりました。それが、結果的に大きな成果の違いに繋がったと感じています。

「イケてるSaaS開発の成長企業」という第一想起を作っていきたい

川津　弊社の開発組織は、内製化に着手した2018年から現在に至るまで、大きく成長してきたと思いますが、まだまだこれで満足しているわけではありません。

僕らSREとしては、「リンクアンドモチベーション」という社名を聞いただけで「イケてるSaaS開発の会社」「開発者として成長できる、働いてみたい会社」といった第一想起をしてもらえるような組織にすることが、今後目指していきたいところですね。

柴戸　僕らが今、会社や組織のテーマにしているのは、テクノロジー×人についての最適解を作っていくことです。

リンクアンドモチベーショングループには「OpenWork」という「プラットフォーム」や、従業員エンゲージメント向上を支援するSaaSといった「テクノロジー」、また創業から20年以上にわたり提供し続けてきた「組織人事コンサルティングのナレッジ」といった、魅力的なアセットがあります。

それらを掛け合わせて、まずはテクノロジー×組織人事コンサルティングナレッジの最適解を作っていくことが直近の目標です。

その実現のために重要なことは、「競争」と「共創」だと思っています。まずは、今まで人が担っていたことの一部をテクノロジーが代替して、機械にはできないところをさらに人が高めていくという健全な競争。そして、テクノロジーと人の双方の強みを生かして融和し、影響を与え合いながら新しい価値を生み出していくという共創を目指したいと考えていました。

これが、ChatGPTの登場によって一気に現実的になったと思っています。3月には「モチベーションクラウド」、4月には「ストレッチクラウド」で、ChatGPTを活用した新機能をリリースしました。

After GPTの時代では、毎日世の中のニューノーマルが更新されていくので、きちんと今を捉えて素早く対応しながらも、将来に向けて最適解を作り続けていくことが我々の現在のチャレンジになります。

もちろん足元では、GPT駆動やAI駆動開発といったように開発プロセスもトランスフォーム中ですし、このような変化においては組織の痛みも伴うので、SREチームと共に「誰でも楽しく、生産的に誇りを持って開発できるような状態」を作り続けていきたいと思っています。（了）