近年、多くの企業においてDXの取り組みが加速する一方で、エンジニア人材を十分に確保することは難しく、開発チームの生産性向上に課題感を持つ企業の声が多く聞かれます。

そのような背景から、経営層や開発に携わる人々の中で注目されているのが「開発者体験」という概念です。

その注目度の高さを表す一例として、現在630名以上のCTO職経験者が会員となっている日本CTO協会では、企業のデジタル変革を示すDX（Digital Transformation）と、開発者体験の向上を示すDX（同協会ではDeveloper eXperience表記）という「2つのDX」の推進を活動内容として掲げています。

また、同協会は2022年に633名の技術者に対してアンケート調査を実施。「エンジニアが選ぶ開発者体験が良いイメージのある企業」として上位30社のランキングを発表し、話題となりました。

▼「Developer eXperience Award 2022」ランキング上位30社（出典：日本CTO協会）​​

世界に目を向けると、多くの海外企業がその重要度に着目して早くから取り組みを開始しており、今後は国内企業でも開発者体験を向上させるための取り組みが広がっていくと予想されます。

そこで今回は、「開発者体験とは何か」といった基礎知識から、国内企業7社の取り組み事例までをご紹介します。ぜひご参考ください。

＜目次＞

• 【まずは定義から】開発者体験（Developer Experience​​）とは？
• 今、開発者体験が重視されるワケは？
• 開発者体験を向上させるために重要となるポイント4つ
• 【事例7選】開発者体験の向上に取り組む企業

• • 偏見・不明・断絶という組織的負債の返済を図る / リンクアンドモチベーション
  • バリューストリーム体制で、各チームが独立して開発を進める / SODA
  • 寄り道しない開発ロードマップ「地図とコンパス」で方針を示す / LayerX
  • 開発生産性を高める精鋭チーム「遊撃チーム」も活躍 / ヤプリ
  • 「アウトカム」が全て。プロダクトマネジメントの考え方を刷新 / Gaudiy
  • 営業不在のPLGモデルを採用。データを軸とするPdMの意思決定 / ベーシック
  • 開発者の待遇格差や人材不足などの課題を解決すべくPJを始動​​ / ユーザベース

【まずは定義から】開発者体験（Developer Experience​​）とは？

「開発者体験」とは、その名の通りシステム開発の業務を行う中で経験する一連の体験のことで、多くの場合は「開発者にとって働きやすい環境や組織文化があり、担当するソフトウェア（システム）を気持ちよく開発・保守できるかどうか」を指します。

開発者体験という言葉自体には「良い」「悪い」の両面がありますが、企業として優れたソフトウェアを開発できるか否かと、それに携わる開発者自身の満足度・幸福度が高いかどうかは連動していると言われています。

例えば、長年蓄積し続けた技術的負債によって改修コストが増加していたり、開発に必要な最新のドキュメントが揃っていなかったり、社内の意思決定ルートが複雑だったり、レガシーで非効率な開発環境だったりした場合はどうでしょうか。

このような開発者にとって障壁が多く、安心して開発業務が行えないような環境では、開発プロセスが長引き、フラストレーションが溜まることで早期離職に繋がる可能性も高まります。

一方、開発者体験が「良い」組織の一例としては、コミュニケーションパスがスムーズな組織文化によって心理的な安全性が担保され、技術的負債が適切に解消・管理されていて、テストやデプロイを高速に行うことができるなど、迷うことなく開発に専念できる環境が整っています。

そういった環境であれば、開発者はより良いソフトウェアの開発を追求でき、緊急ではないものの重要な第二領域のタスクにも着手しやすくなるでしょう。

このように、開発者体験の良し悪しが、ゆくゆくは製品の品質そのものにも繋がるということを認識し、自社の開発組織の状態を注視することが重要になっています。

「技術的負債」に関しては、こちらの記事もご参考ください：

• 【事例5選】「技術的負債」は「悪」なのか？ その定義や歴史、各社の向き合い方を徹底解説
• 技術的負債は「手抜き」の結果ではない。スタートアップ3社が語る、負債への向き合い方

今、開発者体験が重視されるワケは？

冒頭で触れたように、昨今はエンジニアをはじめとするIT人材不足が顕著で、それらの人材の求人倍率は非常に高く、全国的に採用難易度が高まっています。また、スキルの高い開発者はより優れた環境やプロジェクトへ移ることが容易で、離職へのハードルも低くなります。

そのような状況下では、人材が定着しないことでノウハウが流出するだけでなく、開発に携わる人々が頻繁に入れ替わることで技術的負債が積み重なり、解消が難しくなる恐れもあります。

そういった事態を未然に防いで、今いる人材を大切にしながら新たな人材を良い環境へと迎え入れ、チームの生産性を高めるべく、各企業では開発者体験の向上やその取り組みの情報発信に力を注ぎ始めているというわけです。

実際に、日本CTO協会がまとめた調査資料でも、成長スピードの速い企業では、経営におけるDXの実現と共に、開発者体験や開発環境への投資も積極的に行なわれていると発表されています。

出典：2つのDXから考える ソフトウェア経営 – Google Cloud

開発者体験を向上させるために重要となるポイント4つ

2020年にマッキンゼー・アンド・カンパニーが発表した調査結果によると、開発におけるパフォーマンスに最も大きな影響を与えるポイントとして「ツール、文化、製品管理、人材管理」の4つが挙げられています。

We found the four with the greatest impact on business performance are tools, culture, product management, and talent management.

出典：Developer Velocity: How software excellence fuels business performance / マッキンゼー・アンド・カンパニー

調査対象となったソフトウェア企業のうち、これらの4つのポイントを満たす上位25%の企業は、その他の企業と比較して約2倍の速さで収益を伸ばしていたそうです。

ここでは、その4つのポイントについて解説していきます。

1、最先端の優れた「ツール」で開発者を支援する

ソフトウェア開発の計画段階から開発業務、関係各所との情報連携、プロダクトのデリバリー・保守までと、一連の開発体験の中で使用する開発ツールやシステムは多岐に渡ります。

開発者にとって、それらのあらゆるシーンで高品質かつ可能な限り自動化されたツールを利用できる環境があるかどうかは、製品の品質や完成までのスピードにも大きく関わってきます。

また、ノーコード・ローコードツールへの投資によって非エンジニア人材が一部の開発に携わるという体制も構築できるため、経験豊富な開発者は最も難易度の高い開発タスクに専念することもできるでしょう。

2、心理的安全性を育む「文化」を醸成する

近年多くの企業で取り組まれているように、リスクや失敗を恐れずに実践・学習することが奨励され、継続的に環境改善がなされ、個人やチームの貢献を積極的に賞賛するような心理的安全性の高い組織文化こそが、チームの生産性を向上させる上でも非常に重要だと言われています。

下図でも表されるように、目には見えない「心理的なコスト」までを意識してチームをマネジメントすることが、製品の品質を高めることにも繋がっていきます。

出典：https://developerexperience.io/articles/good-developer-experience

3、魅力的な顧客体験を提供するまでの一貫した「製品管理」

ここで言う「製品管理」とは、単に定められた期間内・予算内でのリリースを厳守することを指すわけではありません。

チーム全員が一体となって魅力的な顧客体験を提供するために、共通のゴールイメージをクリアに描くことができていて、要件定義から実開発、デリバリー、保守までのサイクルが適切に管理されていることが重要となります。

また、ビジネスサイドと開発スケジュールや予算などを合意する際には、プロジェクトとチームの規模などをしっかりと考慮した実現可能な計画を組むことも、大切な製品管理の要素のひとつです。

4、長期的な活躍と貢献に繋げる「人材管理（タレントマネジメント）」

前述の3つのポイントが満たされていることに加えて、インセンティブや学習プログラム、継続的な人材採用、コミュニケーションを円滑にする良好な人間関係、明確に定義されたキャリアパスなどが揃っているかどうかは、メンバーの満足度に大きく影響します。

開発チームに限った話ではありませんが、定期的なサーベイによってチームの健康状態を測定し、企業として主体性を持ってより良い環境を実現することで長期的に活躍する人材が増え、将来的な事業成長へも繋がっていくことでしょう。

【事例7選】開発者体験の向上に取り組む企業

ここからは、開発者体験の向上に取り組む国内企業の事例として厳選7社をご紹介します。

技術的負債の解消、意思決定をスムーズにするためのデータ整備、チームで成果を創出するためのマインドチェンジなど、各社ともに様々な軸で取り組みをされているので、ぜひ参考にしていただければと思います。

① 偏見・不明・断絶という組織的負債の返済を図る / リンクアンドモチベーション

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

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

そのため、障害やバグが多発しても要因特定ができず、開発チーム内やビジネスサイドとの間には分断が生まれ、組織として非常にリスクが高い状態だったそうです。

そこで、一人目のエンジニアとして入社し、開発責任者を務める柴戸さんは、 「偏見・不明・断絶の壁」という三つの組織的負債の返済を実施。その後、開発チームを拡大する過程で生じる「20人・50人・100人の壁」に対しても、採用と組織の両面で先手を打ちながら、計画的に組織を拡大してきました。

これらの三つの壁に対する取り組みの結果、テストカバレッジが0％→90％に向上したり、2万行のデットコードの削除に成功したりと様々な開発メトリクスが改善し、組織状態の偏差値を示すサーベイスコアにおいては、危険水域の43.1から、最も高い水準の77にまで回復させることができたとのことです。

▼同社の2年間の取り組みによる開発メトリクスの変化

こちらの記事ではより詳しくリンクアンドモチベーション社の取り組みをお読みいただけます：
非IT企業がゼロから100人の開発組織を構築。MRR9.3倍、2.4億円を5年で達成した組織戦略とは

② バリューストリーム体制で、各チームが独立して開発を進める / SODA

世界進出も果たしたCtoCフリマアプリ「SNKRDUNK」を運営するスタートアップ企業SODA社は、2018年の創業から3年で100億円以上の資金調達を達成し、企業評価額は380億円を超える急成長を遂げています。

その事業成長を支える開発チームにおいては、従来のフロントエンド、バックエンドエンジニアなどの技術領域で分ける形ではなく、近年増えてきている「バリューストリームに沿った開発体制」を採用。

各チームにPdMやWeb担当、Flutter担当が所属するという、職能横断のようなクロスファンクショナルな独立したチーム体制なので、機能開発のすべてをチーム内で完結できるようになっているそうです。

▼SODA社の開発チームの組織構造「ユーザーバリューストリームとチーム」

また、「各チームに裁量を持たせて自分たちに合ったやり方で改善する」というスタイルで進めていることから、チームによって開発に使うツールも一部異なっていたり、アジャイル開発におけるスプリントレビューは特定のチームしかやっていなかったりするように、それぞれが開発を最適化するという風土が根付いているとのこと。

加えて、週に1回は全員で各チームの取り組みを共有したり、定期的に交流を深める場を設けたり、隔週の1on1でキャリアや具体的なアクションについて話したりする形で、個々人のサポートやチームビルディングをしているといいます。

実は、少し前までは今と体制が異なっていて、エンジニアチームとは別の独立したPdMチームがあり、そこでチーム間の連携をしながらプロダクト開発を進めていました。

しかし、エンジニア一人ひとりがリソース効率を優先して、チケット駆動で開発を進めていたために、担当者しか開発内容の具体を把握しておらず属人化してしまったり、人によって開発スピードが異なっていてスケジュールの予測がしづらかったりといった不安定さがあったんですね。

それによって無駄なコミュニケーションコストが発生し、ドメイン知識がチームになかなか定着せず、PdMも施策ごとに毎回違うチームとすり合わせを行う必要が出ていました。そういった状況を解決するために、新たにアジャイル開発のプロセス導入を進めていき、現在のような体制に移行したという経緯があります。

現在の体制になったことで、スケジュールの予測が安定してきましたし、チーム全員で開発の具体を把握して属人化を防ぐという効果も生まれています。

こちらの記事ではより詳しくSODA社の取り組みをお読みいただけます：
「スニダン」で100億超の調達！SODA社のエンジニア組織が2名→20名に急拡大した裏側とは

③ 寄り道しない開発ロードマップ「地図とコンパス」で方針を示す / LayerX

SaaS事業「バクラク」シリーズをはじめ、三つの軸で事業を展開しているLayerX社。同社が得意とする「爆速開発」は、業界認知度も高く注目を集めています。

各事業のプロダクトマネージャーは、それぞれの担当領域を持ちながらも全社での「爆速開発」を実現するため、「地図とコンパス」と呼ばれる同じフォーマットを使って開発ロードマップを描き、開発チームとして進むべき道を指し示しているといいます。

また、開発においては「やらないことを決める」「要望通りの仕様で作らない」「仕様をシンプルにする」という三つのポイントを重視し、ユーザーの真のニーズを十分に拾い上げながらも、開発スピードを緩めない工夫を行っているそうです。

こちらの記事ではより詳しくLayerX社の取り組みをお読みいただけます：
「爆速開発×ユーザー体験向上」を実現するLayerX。その鍵となる「地図とコンパス」とは

④ 開発生産性を高める精鋭チーム「遊撃チーム」も活躍 / ヤプリ

アプリ開発・運用・分析をノーコードで提供するアプリプラットフォーム「Yappli」を展開するヤプリ社。

事業と組織の継続的な成長のために数多の取り組みを実施してきた同社では、一例として創業初期から急成長フェーズを支えたYappliのCMS（コンテンツ管理画面）を、PHPからGoに全て刷新するという一大プロジェクトを2018年に実施しました。

また、同社の特徴として、プロダクト改善を全社で仕組み化していることが挙げられます。以下のような取り組みを行うことで、POやPdMだけではなく全社でプロダクトをより良くすることに関われる体制を構築しているといいます。

• 月に2回、好きな改善に集中できる「Yappdateday（ヤップデートデイ）」
• 誰でも改善アイデアをプレゼンできる「ヤプリク」
• 開発生産性を高めるために課題全般を解決する精鋭エンジニア「遊撃チーム」

こちらの記事ではより詳しくヤプリ社の取り組みをお読みいただけます：
誰もがプロダクト改善に参加する組織を。巨大な技術的負債も乗り越えたヤプリの現在地

⑤「アウトカム」が全て。プロダクトマネジメントの考え方を刷新 / Gaudiy

国内のWeb3.0企業の中でも成長著しく、事業成長に合わせてプロダクトマネジメントの考え方や、プロセスを大きく進化させてきたGaudiy社。

同社で2022年からプロダクトオーナーを務める宮田さんは、それまで顧客の要望を中心としたアウトプット重視の考え方から、「アウトカム（成果）の創出が最重要」とする考え方へシフトするべく、チームの一人ひとりに働きかけを行ったそうです。

さらに、プロダクト開発における「不確実性の段階を下げる」プロセスを、「In Sense / In Discovery / In Delivery」の三つのフローに分化して定義。

エンジニア、デザイナーなど様々な役割を持った人から構成される「フィーチャーチーム」が、個人ではなくチームとして一連のプロセスを担うことで、全員がアウトカムの創出に向かって全プロセスのオーナーシップを持ちながらも、個々のスキルを高める意識を持てる体制を構築したといいます。

現在はこの体制をさらに進化させ、プロダクトマネージャーを職種関係なくチーム内の投票で決める仕組みの導入へと動いているそうです。

こちらの記事ではより詳しくGaudiy社の取り組みをお読みいただけます：
アウトプットではなくアウトカムを生み出せ。Gaudiyのプロダクトマネジメント変革の全貌

⑥ 営業不在のPLGモデルを採用。データを軸とするPdMの意思決定 / ベーシック

セールスによってプロダクトを売るモデルである「SLG：Sales-Led Growth」に対し、プロダクト自体の力によってユーザーの購入を促すというSaaSプロダクトの新しい成長モデル「PLG：Product-Led Growth」。

その成功事例としては「Slack」や「Zoom」が挙げられますが、このPLGモデルを採用し、順調な成長を続けている国内プロダクトのひとつが、ベーシック社が展開するフォーム作成管理ツールの「formrun（フォームラン）」です。

同プロダクトでは、「営業がいない」PLGモデルならではの組織体制づくりや、意思決定の仕組みを構築しています。

具体的には、初期段階でのユーザーの離脱を防ぐためのフレームワークの導入や、ユーザーの行動ログを徹底的に集めて可視化することで、データドリブンな意思決定を可能にしているそうです。

各領域の意思決定については、私たちの場合は営業がいないので、日々のユーザーの行動ログを可視化することで、データドリブンな意思決定を行っています。

具体的には、専任のチームがTableau（ダッシュボードツール）を使って、欲しいデータやモニタリングしたいデータを一覧化しています。例えば、どのプランのユーザーが、いつどんな機能をどのくらい利用しているのか、といった推移も追うことができるので、このデータを元に、現場で意思決定をしていくイメージです。

▼実際に活用されているダッシュボードの一例

実際にPdMが行う意思決定のプロセスとしては、①顧客の課題をマクロ・ミクロに分析する、②ロードマップに落とし込む、③各部署とのシームレスに連携し、プロダクトを継続的に磨き続ける、という形になります。

その中で、例えば①のステップでは、カスタマーサポートから上がってくるユーザーの声なども見ながら優先度づけを行い、開発を行っていきますが、特徴的なのはやはりデータの活かし方だと思います。

例えば、プロダクトアウトの方向性でカンバン機能を進化させていく場合には、まずカンバン機能を分析するダッシュボードを作り、細かく使われ方を見ていきます。カンバン機能を使っているユーザーのプランや企業規模、業種、持っているフォームの数、ペルソナ等、各種データの抽出によってユーザーの解像度を高めていきます。

その上で、新しい機能が本当にユーザーに使われるか、リリースすることでどのくらいのインパクトがあるか、ということを細かく出して意思決定を行います。これはPLG型ならではの特徴かなと思いますね。

こちらの記事ではより詳しくベーシック社の取り組みをお読みいただけます：
4年でMRRが950％成長！「formrun」に学ぶPLGモデルのプロダクトマネジメントとは

⑦ 開発者の待遇格差や人材不足などの課題を解決すべくPJを始動​​ / ユーザベース

「誰もがエンジニアリングを楽しめる世界」を目指して、2022年4月に新プロジェクト「Play Engineering」を始動したユーザベース社。

同社の代表取締役 Co-CEO/CTOを務める稲垣さんは、「今、ビジネスとエンジニアリングの間には分断が起きている。技術者はもっとビジネスシーンをリード出来るはずだ」と語ります。

具体的には、国内企業において経営レベルの話で技術に関する会話をすることは稀で、社内受発注のような分断の構図があることや、同等スキルのエンジニアであっても居住地によって待遇の差が生まれていることに課題を感じていたといいます。

そういった課題感から、「Play Engineering」の第一弾では、エンジニアか否かを問わず、特定の技術スキルの保有者に対して手当を付与する新制度や、全社員を対象にしたエンジニアリング研修、コーポレートメンバーによる「業務効率化自慢コンテスト」などを実施しました。

本プロジェクトは第二弾、第三弾…と続々と打ち出されており、非エンジニアだけでなく全社・業界全体で開発体験を盛り上げる取り組みとして、多くの企業からも注目されています。

こちらの記事ではより詳しくユーザベース社の取り組みをお読みいただけます：
全社員対象のエンジニアリング研修も！ユーザベースが描く技術とビジネスが融合する未来

今回は、「開発者体験」をテーマに、その定義から開発者体験を向上させるためのポイント、各社の事例までをご紹介させていただきましたが、いかがでしたでしょうか？

当媒体SELECKでは、引き続き開発者体験に関する取り組みの取材記事や、各社の事例から学べるイベントを開催していきますので、ぜひチェックしていただけますと幸いです。

最後までお読みいただき、ありがとうございました！