AI支援で開発は速くなったのか？開発者体験可視化の新時代、Atlassianの「DX」について

「AIコーディング支援を導入したけど、開発速度は上がったのか？」
本記事は、そう感じている人にこそ読んでほしい内容です。この問いに数値・データで答えるための基盤が、アプリ「DX（ディーエックス）」です。日本で DXというとデジタルトランスフォーメーションを連想されがちですが、この DXは違います。Atlassian社は「DX」という名称の生産性可視化ツールを買収したのです。そして、Atlassianの開発者向けアプリコレクションに加えました。既存の Atlassianツール「Compass」を DXに統合し、開発者向けアプリコレクション「Software Collection」内のツールとして提供していきます。
この記事では、DXが Atlassianに加わった背景と、既存の Compassユーザーは何をすべきかを整理します。

概要 -- DX社の買収

DXは、開発者の生産性と体験を計測する「エンジニアリングインテリジェンスプラットフォーム（Engineering Intelligence Platform）」です。Atlassianは2025年9月18日、DX社を約10億ドル（現金と譲渡制限付株式の組み合わせ）で買収すると発表し、同年11月10日に買収を完了しました。買収額はLoom（約9.75億ドル）と並ぶ、Atlassianにとって大きな投資案件です。

DX社は、買収時点で Dropbox（クラウドストレージ）、キャッシュレス決済 Block（日本では"Square"で知られるサービス）、Pinterest（画像コレクションサイト）、ファイザー（製薬大手）、Xero（クラウド会計）、BNY（金融）など、350社を超えるエンタープライズ企業に採用されていました。注目すべきは、その顧客の多くが、すでに Atlassian製品のユーザーだったという点です。両社の顧客基盤は最初から重なっていました。

2社の買収統合は、Atlassian社・DX社双方にメリットがあります。Atlassianは、SDLC全体を横断する計測能力を手に入れます。DX社は、多数の Atlassian顧客へのリーチを得ると同時に、Jira・Bitbucket・Pipelinesのデータと連携することで「計測→課題の特定→改善」のループを一気通貫で回せるようになります。

そして2026年4月13日、Atlassianは「The Next Chapter for Compass」を発表し、Compassの中核機能を「DX Fabric」としてDXプラットフォーム上に統合する方針を明らかにしました。DX社自身も同年5月6日、Fabricを正式に発表しています。

（出典：Atlassian + DX 発表／Introducing Fabric（DX公式）／Loom買収額は BusinessWire）

Compassの目的・意義

Compassは、Atlassianが開発し、2023年に一般公開された IDP（Internal Developer Portal：社内開発者ポータル）です。マイクロサービス（機能ごとに小さく分割して開発・運用するアーキテクチャ）が広がると、「自社が何のサービスを持っていて、どれを誰が所有し、それぞれがどの程度健全なのか」が見えにくくなります。Compassはこの課題に対し、コンポーネントカタログ（サービスの一覧と所有者の台帳）、ヘルススコアカード（健全性の採点表）、ソフトウェアテンプレート（新規サービスの雛形）といった機能を提供してきました。

このカテゴリには競合も多く、代表的なのは Spotifyが開発した OSSの Backstageで、ほかに CortexやPortといった製品があります。

Compassと DXの統合 -- なぜ Compassだけでは足りなかったのか

Compassが提供していたのは、いわば組織の地図です。どこに何があり、誰が持っているかを示す静的なカタログです。地図は、サービスが増えて見通しが悪くなった組織にとって価値があります。しかし地図そのものは、「その状態が良いのか悪いのか」「どこを改善すべきか」までは答えてくれません。

一方、AIコーディング時代に入り、開発組織が抱える問いは変わってきました。「開発は AIを導入して、実際に速くなったのか」「どの工程がボトルネックなのか」「投資した結果、開発者体験は改善したのか」。これらは静的なカタログでは答えられない、計測と分析を必要とする問いです。

DXは、まさにこの「計測する力」を持つプラットフォームでした。Atlassianは、Compassの「可視化する力」と DXの「計測する力」を一つに束ねることで、地図を眺めるだけでなく、地図の上で改善を回す基盤を目指しています。

統合後の DXプラットフォームは、基盤層と分析層で捉えると分かりやすくなります。

• 基盤層（DX Fabric）：Compassの後継にあたるものです。
  ソフトウェアカタログとスコアカードを中核に、コンポーネントデータを柔軟に取り込めるデータレイクの上に構築されます。単なる台帳にとどまらず、AIエージェントにアーキテクチャのコンテキストを提供し、スコアカードのシグナルをトリガーに改善ワークフロー（信頼性問題に対処するPRの自動起票など）を駆動する、次世代 IDPの基盤として設計されています。Terraformプロバイダーによる Config-as-Code管理に対応し、Bitbucket・GitHubからのリポジトリ自動インポートと継続的ディスカバリー（新規追加リポジトリの自動検出）を備えます。
  
  
• 分析層：基盤層の上で、2種類のデータを扱います。
  ひとつは開発者への調査（サーベイ）に基づく自己申告データで、後述の DXIなどの開発者体験指標がこれにあたります。（定期的に開発者に対してアンケートを行います）
  もうひとつは Jira・Gitなどのシステムから集める定量データ（サイクルタイム、変更失敗率など）で、DXのデータレイク（Data Cloud）が集約します。AIインパクトの計測は、この両者を組み合わせて行います。

（出典：The Next Chapter for Compass／Introducing Fabric（DX公式）／DX Platform Overview）

DXプラットフォームの2層構成 ―「可視化する力」と「計測する力」

製品「DX」の中身と強み

DXI スコア-- 開発者体験を数値化する

ひとつめの柱が DXI（Developer Experience Index）です。これは開発者体験を数値化する複合スコアで、エンジニアリング効率に関わる14の要素（標準化されたサーベイ）から算出されます。
測定する観点は、コード品質、集中している時間（ディープワーク）、ローカルでの反復速度、リリースプロセス、変更を加える際の自信など、いずれもマネージャーや組織のレベルで実際に改善できる項目に絞られています。

DXの調査では「DXIスコアが1ポイント改善するごとに、開発者1人あたり週に約13分（年間約10時間）の時間節約に相当する」という試算が示されています。また、DXIスコアが上位四分位のチームは、下位四分位のチームに比べて開発の速度と品質が4〜5倍に達するという分析もあります。体験という曖昧になりがちな対象を、投資判断に使える数字へ変換する点が、DXIの特徴です。

（出典：Developer Experience Index（DX公式リサーチ））

DXI（Developer Experience Index）の構造

DX Core 4 -- 生産性を4軸で捉えるフレームワーク

ふたつめの柱が DX Core 4です。これは開発生産性を Speed（速さ）、Effectiveness（効果）、Quality（品質）、Impact（事業への影響）の4軸で捉えるフレームワークで、DevEx研究を行っている Abi Noda（CEO）と Laura Tacho（元CTO）らが中心となり、それまで別々に語られてきた DORA・SPACE・DevExという3つの代表的な枠組みを統合したものです（DORAの提唱者である Nicole Forsgren氏らも協力しています）。

各軸には代表的な指標が定義されており、たとえば Speedはエンジニアあたりの差分数（diffs per engineer）、Qualityは DORA由来の変更失敗率（change failure rate）、Impactは新規価値の創出に費やされた時間の割合（innovation ratio）で測ります。先述の DXIは、このうち Effectivenessを測る指標として位置づけられます。Impact（事業への影響）を正面から扱う点と、個人ではなくチームレベルでの計測を原則とする点が、他のフレームワークとの違いとされています。DX社によれば、DX Core 4はすでに500社を超える企業で導入されています。

（出典：Measuring developer productivity with the DX Core 4（DX公式リサーチ） / https://getdx.com/research/benchmarks/ ）

データを届ける仕組み -- PulseとDX AI

DXには、計測した数値を「見に行く」のではなく「届ける」仕組みが備わっています。いずれも2026年4月に一般提供が始まりました。

Pulseは、チームの主要メトリクスやシグナルを週次で1本のアラートにまとめ、Slack・Microsoft Teams・Webexなどへ自動配信する、現場マネージャー向けの通知機能です。配信する指標・対象チーム・曜日や時刻は選択できます。

DX AIは、プラットフォームに組み込まれたAIアシスタントで、「先月デプロイ頻度が落ちたのはなぜか」といった自然言語の質問に対し、蓄積データの分析・要約と改善提案を返します。ダッシュボードを開かずにデータを参照でき、気になった数字はその場で掘り下げられます。「計測して終わり」にしないための設計です。

（出典：Introducing Pulse（DX公式）／Introducing the new DX AI（DX公式））

AIインパクトの計測

さらにDXは、AIインパクトの計測にも対応します。Copilotや Rovo Devといった AI支援が、サイクルタイムや品質、開発者体験にどう影響したかを可視化します。2026年4月に一般提供が始まった「AI Code Insights」は、翌月の Team '26でも DXの中核機能として紹介されました。AIが生成したコードをコミット単位で識別し、エージェントの利用実態（Agent Experience）や AI投資の金額換算（AI dollar impact）まで踏み込んで可視化します。

この機能が必要とされる背景には、DX社自身の問題意識があります。DX社の調査によれば、先進的な組織でも AIツールの実利用率は6割程度にとどまっています。さらに、開発者の時間のうちコーディングそのものに充てられるのは一部にすぎず、要件の明確化・会議・コードレビュー・情報収集などが大半を占めます。つまり、コード生成を AI化するだけでは開発全体は速くならない。だからこそ、SDLC全体を対象に「AI投資がどこで効いているか」を計測する物差しが必要になる、という論立てです。

この文脈で、DX社Deputy CTOの Justin Reock氏は Team '26で「AI Readiness（AI準備性）」の考え方を提唱しました。Reock氏は「人間にとって良いものは、AIエージェントや LLMにとっても良い」と述べています。明確で正確なドキュメント、関係性が直感的なデータ構造、保守しやすい標準化されたコード、高速で信頼できるCIと堅牢なテスト。これらは結局のところ、もともと「よい開発者体験」と呼ばれてきたものに他なりません。つまり DXが計測する「開発者体験の整備度」は、AI投資を本当に効かせるための土台の可視化でもある、という考え方です。

こうした計測領域そのものへの評価も進んでいます。2026年5月には、Gartnerが初めて公開した「Magic Quadrant for Developer Productivity Insight Platforms」で、Atlassian（DX）がリーダーに位置づけられました。開発者生産性の計測が、独立した製品カテゴリとして認知され始めたことを示す動きです。

（出典：Atlassian (DX) Named a Leader in the Inaugural Gartner Magic Quadrant for Developer Productivity Insight Platforms（DX公式））

（出典：Introducing AI Code Insights（DX公式）／Measuring AI code assistants and agents（DX公式））

「DX」が向く組織・向かない組織

DXの利用者は、立場によって関心が異なります。CTOや VPoEにとっては、開発組織全体の生産性を、感覚ではなくデータで経営に説明できる手段になります。とりわけ AI投資の効果を問われる場面で、計測の裏付けは有効です。エンジニアリングディレクターにとっては、複数チームの状態を横並びで比較し、どこに課題が集中しているかを把握できます。EM（エンジニアリングマネージャー）や PMにとっては、自チームのボトルネック（集中時間の不足、リリースプロセスの摩擦など）を具体的に特定する材料になります。そして開発者本人にとっては、調査への回答を通じて、日々感じている摩擦を組織に伝えるチャネルになりえます。

とはいえ、DXは万能ではありません。規模・エコシステム・業務特性の3つの軸で、向き不向きが分かれます。

• 規模の軸：DXの価値は、計測して初めて見える課題があることを前提とします。5〜10名程度の単一プロダクトチームでは、計測する前にやるべきことが見えている段階のことが多く、計測基盤は過剰になりがちです。DXが効くのは、複数チーム・複数サービスを抱え、全体像が個人の把握を超えた規模からです。
  
  
• エコシステムの軸：すでに別のツールチェーンで計測を回しており、運用が安定している組織なら、DXへの乗り換えコストが効果を上回ることがあります。逆に、Atlassian製品で SDLCを構成している組織は、計測基盤を同じ土俵に乗せやすくなります。
  
  
• 業務特性の軸：ソフトウェア開発が中心業務でない組織では、開発者体験の計測そのものの優先度が高くありません。この場合はDXより、Teamwork Collectionを起点に全社の働き方を整える方が先になります。

一言でまとめると、DXは「ある程度の規模の開発組織が、Atlassian基盤の上で開発者体験をデータで改善したいとき」に最も効きます。

Compass導入済みの組織はどうすればいいか

現在 Compassを使っている組織は、移行のスケジュールと選択肢を事前に把握しておきましょう。
新規顧客への提供は 2026年5月13日に終了しています。既存ユーザーのアクセスは、契約満了時、または 2027年12月31日に予定されているサポート終了のいずれか早いほうで失効します。

移行先は用途によって分かれます。カタログ・スコアカードといった IDP機能は、メインの移行先である DX Fabricへ引き継がれます。移行は、Atlassianのアカウント担当または DXチームに連絡して移行日を設定するところから始まります。Compassのコンポーネントを取り込む一度きりの移行同期と、Atlassianのチーム情報を日次で取り込むコネクタが用意されており、移行後は1か月間、CompassとDXの両方にアクセスできる併用期間が設けられます。

ただし、移行時に注意すべき点がいくつかあります。

• スコアカードは自動移行されません：DX上での再作成が必要です。
  
  
• Jiraからの双方向連携は未対応（片方向のみ）：DXのエンティティ（サービス等）から Jiraのワークアイテムへのリンクは可能ですが、Jiraのワークアイテム側から DXエンティティへ接続する機能は未サポートです。（2026年9月現在）
  
  
• アラート・オンコール等の運用機能は DXに含まれません：オンコール（障害対応の当番）・インシデント対応・アラートを目的に Compassを利用していたチームは、別ツール（Jira Service Management）への移行が必要です。
  
  
• チーム情報の同期に制約があります：DXでは1ユーザーが所属できるチームは1つのみで、各チームに Team Leadの設定が必須です。複数の Atlassian Teamsに所属しているユーザーは、移行時にいずれか 1チームへ割り当てられるため、移行後にチーム構成の確認が必要です。

（出典：Migrate from Compass to DX（Atlassian公式））

Compass から DX への移行ステップ

DXについてのお問い合わせはリックソフトへ

DXは、Atlassianが提供するアプリコレクション「Software Collection」の一製品です。Software Collectionに関心がある方、また Compassからの移行が必要な方は、リックソフトまでご相談ください。

まとめ

アプリ「DX」は、「開発者体験を計測する力」と、Compass由来の「ソフトウェアを可視化する力」を一つに束ねた、Atlassianの開発者基盤です。DXI・DX Core 4・AIインパクト計測といった指標は、開発者体験という曖昧な対象を、経営や改善に使える数字へと変換します。恩恵を受けやすいのは、一定規模を持ち、Atlassian基盤の上で開発を進める組織です。第1回で述べたとおり、DXはSoftware Collectionの「計測レイヤー」を担う製品であり、Bitbucket・Pipelinesが生み出す開発データを改善につなげる役割を持ちます。

リックソフトは、AtlassianのPlatinum Solution Partnerとして、Compassからの移行相談を含め、Software Collection導入のご検討をご支援しています。ご検討中の方はお気軽にお問い合わせください。

この記事の主な出典

• Atlassian + DX: Engineering Intelligence for the AI Era
• The Next Chapter for Compass
• Migrate from Compass to DX（Atlassianサポート）
• Developer Experience Index（DX）
• Measuring developer productivity with the DX Core 4（DX）
• Introducing Fabric（DX）