← エピソード一覧に戻る Episode 176 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 週8時間のムダは誰の責任か
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発における開発者体験、いわゆる DevEx を扱います。実はこれは現場の気分の話ではなく、採用、出荷速度、障害対応まで左右する、かなり経営ど真ん中のテーマなんです。
ミカ
ミカです。開発者体験って聞くと、働きやすさとか、ツールが快適かどうかみたいな柔らかい話に見えます。でも経営ど真ん中と言われると、急に重みが変わりますね。現場の感想ではなく、どこまで数字で見えるものなんでしょうか。
タカシ
Atlassian と DX の 2025 年調査では、69 パーセントの開発者が非効率のせいで週 8 時間以上を失っていると答えました。1 日分の労働時間が、権限待ちや情報探索やレビュー待ちで消えているわけです。
ミカ
週 8 時間ってかなり大きいですね。しかも SaaS だと、機能追加も障害対応も毎週続くから、そのムダが積み上がるほど、リリースも採用もじわじわ苦しくなりそうです。今日はその正体を分解していきたいです。
Chapter 2 原則 ― DevEx はご機嫌取りではなく複雑さの設計である
タカシ
まず定義です。開発者体験とは、必要な情報がすぐ見つかり、環境をすぐ立ち上げられ、変更にすぐフィードバックが返り、安全に本番へ届けられる状態です。つまり『前に進むまでの摩擦』をどれだけ減らせているかを見る概念なんですね。
ミカ
なるほど。快適な椅子や高性能マシンも大事だけれど、本丸はそこじゃないと。知らない設定を探す、レビューが返ってこない、障害の手順が見つからない、そういう詰まりを日常的に減らせるかが本質なんですね。そこが毎日の差になると。
タカシ
その通りです。Team Topologies は、内部プラットフォームの主目的は開発者の cognitive load、つまり認知負荷を下げることだと説明しています。難しさを個人の努力で飲み込ませず、仕組み側へ移す発想ですね。
ミカ
認知負荷って、頭のメモリ残量みたいなものですかね。機能を考える前に、まず社内の仕組みを解読しないといけない会社だと、優秀な人でも本来の仕事にエネルギーを使えなくなりそうですし、学習も遅くなりそうです。
タカシ
まさにそのイメージです。DORA 研究では、高品質な内部ドキュメントがあるチームほど team performance が 25 パーセント高く、コードレビューが速いチームは software delivery performance が 50 パーセント高いと示されています。DevEx はちゃんと成果に返ってくるんです。
Chapter 3 具体例 ― 良い DevEx は満足度と速度を同時に上げる
ミカ
ここまで聞くと、DevEx は開発組織の裏テーマじゃなくて、売上を支える基盤投資に見えてきます。実際に SaaS 企業はどんな手を打っているんでしょう。できれば、経営判断に結びつく数字つきの例で見てみたいです。
タカシ
まず Atlassian です。彼らは DevEx を会社レベルの OKR に置き、社内の開発者満足度を 2 年で 49 パーセントから 74 パーセントへ引き上げました。しかも CTO は、shared services の変更サイクルを 90 パーセント削減する目標で改善を進めていると述べています。
ミカ
面白いですね。満足度を上げる話と、変更を早く届ける話を別部署の論点にしなかったわけだ。『開発者が気持ちよく働ける』を、ちゃんと事業側の出荷速度の改善として回収しにいっている感じがします。かなり経営的です。
タカシ
次に GitLab です。2024 年の案内では、AI を使う回答者の 43 パーセントが、オンボーディングは 1 カ月未満だと答え、非利用者の 20 パーセントを上回りました。重要なのは AI 単体ではなく、標準化された環境やドキュメントが前提だと明言している点です。
ミカ
つまり、AI に何とかしてもらう前に、会社の知識が整理されていないと効果も薄いんですね。散らかった倉庫に案内係を 1 人足しても、倉庫が散らかっていたらやっぱり迷う、そんな話に聞こえます。土台の整理が先ですね。
タカシ
さらに GitLab は 2025 年、初参加コントリビューターの導線改善も公開しています。2023 年の調査では 6 人中 1 人しか初回マージに成功しませんでしたが、README の見つけやすさや自動フォローを改善した後、2025 年は 10 人全員が成功しました。
ミカ
6 分の 1 が 10 分の 10 ですか。それはかなり劇的ですね。しかも派手な新機能というより、README の置き場所、メンテナーの反応速度、自動の追いかけ方みたいな運用改善が効いているのが現実的です。
タカシ
そうなんです。GitLab は直近 3 カ月の first response time を 46 分、権限承認を平均 1 時間まで短縮し、コミュニティ fork の貢献者総数も 9 カ月で 2 倍になったと報告しています。DevEx は導線設計と応答速度で改善できる好例です。
Chapter 4 失敗パターン ― ツールを足しても摩擦が減らない会社
ミカ
逆に、DevEx 改善に投資しているのに現場が楽にならない会社は、どこで外しているんでしょう。便利そうなツールは増えているのに、なぜかみんな忙しそう、という光景にはかなり見覚えがあります。ここは知っておきたいです。
タカシ
典型例は四つあります。第一に、ツール導入だけで解決しようとすること。第二に、経営が開発者の痛みを聞かずに正解を決めること。第三に、ドキュメントをコードや運用から切り離すこと。第四に、満足度を測っても速度や品質と結び付けないことです。
ミカ
二つ目は耳が痛いですね。リーダーは『AI が足りない』『人手が足りない』と思っているのに、現場は『古い README とレビュー待ちがつらい』と言っている、みたいなズレがあると、予算を使っても摩擦が残り続けそうです。
タカシ
その通りです。DevEx は抽象語に見えますが、観測すべき点は具体的です。初回コミットまで何日か、レビューは何時間待つか、障害時に runbook へ何分で到達できるか。ここを見ないと、改善が『なんとなく良さそう』で終わってしまいます。
Chapter 5 クロージング ― 迷わない設計が、強い開発組織をつくる
ミカ
今日の話を聞いて、開発者体験って『エンジニアを甘やかす施策』じゃなくて、『普通の人が早く戦力化して、長く価値を出せる仕組み』なんだと見えました。SaaS みたいに継続改善が前提の事業ほど、効き目が大きそうです。
タカシ
その理解で大丈夫です。今日のポイントは三つ。第一に DevEx は認知負荷の設計であること。第二に docs、レビュー速度、自己サービス環境が成果へ直結すること。第三に、採用や定着まで含めて経営投資として扱うべきことです。
ミカ
明日からやるなら、環境構築、権限取得、最初のデプロイ、レビュー待ち、障害時の情報探索、この五つの詰まりを洗い出すところからですね。次回は SaaS デザインの新しいセクションに入って、また別の角度から事業づくりを見ていきましょう。