はじめに

　食べログ開発本部、品質管理室で室長をしている荻野です。近年ITサービス業界では、ビジネスを取り巻く変化に迅速に対応するため、アジャイル開発やDevOpsなどの開発プラクティスが普及し、開発生産性に関する議論が活発化しています¹。

　このブログ記事では、開発生産性の歴史をアジャイル開発の源流である日本の製造業まで遡って振り返った上で、開発生産性Conference 2024の登壇発表を中心に現状のITサービス業界での開発生産性改善について議論します。

開発生産性の歴史

　2024年のITサービスの開発生産性の現在地を確認するため、このセクションではアジャイル開発プラクティスの源流である日本の製造業の品質管理から振り返ります。

アジャイル開発の歴史

こちらは、t_wadaさんの組織に自動テストを書く文化を根付かせる戦略でもたびたび引用していただいている私がまとめたアジャイル開発の歴史の2024年改訂版です。アジャイル開発の中心的なプラクティスであるリーンソフトウェア開発やスクラム開発は、日本の製造業のトヨタ生産方式(TPS)や総合品質管理(TQC)などの考え方から強く影響を受けています²　³。

　ここで面白いのは、日本の製造業では生産性と品質を切り離して考えておらず、特にTQCでは生産性をプロダクト品質に影響を与える経営要素の1つとして捉えられていることです⁴。アジャイル開発が世に広まる中で「アジャイル開発はスピードを重視するあまり品質を犠牲にしている」という声がたびたびあり、今日の開発生産性でも「スピードと品質はトレードオフなのか？」という議論があります。ですが、アジャイル開発の源流である日本の製造業、特にTQCでは、品質を上げていくための組織的な活動によって、"ムダが減り、効率が上がり"、"コストや納期が改善される"、つまり生産性が上がると考えられてきました。

　この品質と生産性の関係の変化は、コストと収益という経営視点での品質の意味するものが時代とともに変わってきたことに理由があります。このセクションでは、経営視点での品質の意味するものの変遷を日本の製造業での品質管理の歴史が始まった1950年代から、

工業製品のコスト管理 (1950~1970年代)
工業製品とサービス業の収益増加 (1980~2000年代)
ITサービスの開発生産性改善 (2010年代~)

の3つの時代ごとに、振り返っていきます。

開発生産性の歴史

工業製品のコスト管理 (1950~1970年代)

　日本での開発生産性改善の原点である品質管理の手法が普及した1950~1970年代は、コスト削減のための不良品管理が品質管理の中心でした⁵。この時代は三種の神器(白黒テレビ/洗濯機/冷蔵庫)や新三種の神器(カラーテレビ/クーラー/自動車)が世間一般に普及した頃であり、まだまだ製品のバリエーションが少なく標準的な製品のみを売っていたため、その標準的な工業製品をいかに不良品を少なく生産するかが重要でした。生産してしまった不良品はユーザーを困らせてしまうだけでなく、修理や交換、廃棄などの追加コストが発生し原価コストに上乗せされるため、結果的に製品の単価が高くなります。

　製造業における品質管理と生産管理の手法としては品質コストとトヨタ生産方式が一般的に知られています。品質コストでは、品質にまつわる活動の結果発生するコストを

予防コスト
評価コスト
内部コスト
外部失敗コスト

の4つに分類、計上します。品質の評価業務にかかるコストは評価コストに、また、市場に流出した不良品の修理や交換といったコストは外部失敗コストに計上され、原価コストの一部として取り扱われます。品質コストではこれら品質評価や不良品に関連するコストを最小化するように生産と品質管理活動を管理します。⁶。

　トヨタ生産方式は生産工程のコストだけでなく「流れ( フロー)」にも着目した生産性改善の経営手法であり、「自働化」と「Just in Time」を二本柱としています⁷。自働化は「ニンベンのついた自動化」と呼ばれており、フローの中で異常が発生したら機械自身がそれを自動で検知、停止することで、異常な状態での生産を継続しないようにします。また、Just in Timeでは、必要なものだけを流れるように生産していくことでムダな在庫の保管コストを削減するだけでなく、価値をタイムリーに顧客へと届けられるようになります。

　トヨタ生産方式ではこれら二本柱を通して、生産を開始してから製品が顧客に届くまでのフローのリードタイムも改善します。トヨタ生産方式におけるこのリードタイムの考え方は海外でリーンソフトウェア開発として発展し、近年のソフトウェア業界における開発生産性改善でも柱となっている重要なものです。

　ただし、製造業と近年のITサービスでは生産、開発されるアウトプットによって生み出されるアウトカムが一定かどうかについて大きな違いがあります。製造業で生産する工業製品では、アウトプットしての1製品にかかる生産コストやそれが生み出すアウトカムとしての収益は均一ですが、ITサービスでは1機能あたりの開発コストや生み出すアウトカムが均一ではありません。そのため、工業製品からITサービスへとプロダクトが変化していく中で、アウトプットとアウトカムの関係が複雑化していきます。

工業製品とサービス業の収益増加 (1980~2000年代)

　1980年代に入り、不良品管理によるコスト削減だけでなく、収益増加のための品質が製造業でも求められるようになりました。これは上述の三種の神器などの工業製品が消費者に行き渡り、顧客の嗜好に合わせて購買意欲に訴求する必要が出てきたからだと筆者は推察しています。

　この時代の代表的な手法は、魅力的品質で有名な狩野モデルです。狩野モデルでは、それまで一元的な認識だった品質の概念を物理的な充足状況と満足度の2つの軸で整理し、

魅力的品質
当たり前品質

などの品質に分離しています⁸。ここで魅力的品質が顧客の嗜好に合わせて購買意欲に訴求するための品質で、市場調査からこの魅力的品質を抽出し新しい品種としての新製品の企画へ適用します。

　この製造業における標準的な製品から顧客の嗜好に合わせた製品への流れは、現代ではスマホで考えるとわかりやすいです。登場当初スマホは一種類しかありませんでしたが、現在では「カメラ特化型スマホ」「折りたたみスマホ」「高齢者向けスマホ」「ゲーミングスマホ」など、様々なバリエーションのスマホが企画、生産されています。顧客のさまざまなニーズに特化するスマホをアウトプットとして生産、販売することで新しいニーズに対応し、アウトカムとしての収益増加に結びつけています。

　2000年代に入り、工業製品だけでなく、ホテルや飲食店、レンタカーなどのサービス業でも品質改善による収益増加の議論が活発になりました。工業製品とサービスの大きな違いとして、サービス業では人間が直接顧客とコミュニケーションをするということがあります。サービス業では、顧客の要望について直接コミュニケーションしながら少しずつサービスのカスタマイゼーションを実施します。

　また、サービスでは物理的な製品がないため製品の品質をあらわす物理的な指標がないことも工業製品との違いです。そのためサービス業では、顧客満足度を品質改善の指標とし、これを改善することで収益が増加することを期待しています。

　サービス業の顧客満足度向上の手法としてはReturn on Quality(ROQ)が有名です⁹。 ROQでは、サービス業の品質改善活動を利益拡大のための投資として捉え、収益増加やコスト削減につながるサービス品質改善のための投資をしていきます。

　面白いのは、ROQでも品質改善の目的は収益増加なのか？コスト削減なのか？という議論が行われており、ROQでも収益増加がより重要と結論づけられています¹⁰。 1980年代以降、アウトプットの不良品管理によるコスト削減だけでなく、アウトカムとしての収益増加にも比重を置いた品質改善が進められるようになりました。

ITサービスの開発生産性 (2010年代~)

　2010年代に入り、さまざまなITサービスが展開されるようになる中で開発生産性改善の議論が活発になりました。 ITサービスは、ソフトウェアの開発という製造業としての性格と、サービスの提供というサービス業としての性格を併せ持っていることが特徴です。そのため製造業としてのソフトウェア開発（アウトプット）のコスト削減と、サービス業としての顧客満足度向上(アウトカム)による収益増加の両者が開発生産性の効果として期待されています。

　ITサービスの開発生産性改善のための代表的な手法はFour Keysです¹¹。 Four Keysでは、不良品の割合を表す変更障害率だけでなく開発生産性を表す変更のリードタイムやデプロイの頻度を計測し、市場の変化や外部要因などに対応しやすい繰り返し型としての開発プロセスを評価します。

　評価された開発プロセスの改善は、リーン開発とDevOpsプラクティスが２軸となっています。リーン開発のプラクティスを適用し要求を小さく分割し優先順位をつけることで繰り返し開発プロセスで管理可能な形にし、DevOpsプラクティスを適用することで繰り返しプロセスの中のテストやインフラ構築などの手作業を自動化し、繰り返し開発をアジリティ高く進められるようにしていきます。

　ただしFour Keysはあくまでアウトプットのプロセス品質のみを表している指標である点については注意が必要です。 ITサービス業界では顧客価値につながる”アウトカム”と、顧客価値につながるかどうかまだ分からない機能製造段階での成果物であるアウトプットを明確に区別して使い分けていますが、Four Keysでは作るものが決まった実装以降の下流工程のプロセス品質だけを表しており、アウトカムに直結するような作るものについて企画する上流工程が含まれません。

　そのため、Four Keysを活用しアウトプットを改善しなければアウトカムは増えませんが、アウトプットを増やしたからといってそれがアウトカムとなって顧客価値につながるかどうかは分からない、というのがITサービスの開発生産性の複雑な点です。

2024年現在の開発生産性

　ここまで、1950年代から現在までの製造業での品質管理からITサービスでの開発生産性改善の変遷を「コスト」と「収益」の視点で振り返ってきました。ここからは、開発生産性Conference 2024でのさまざまな講演内容をご紹介しながら、2024年現在のITサービスの開発生産性についての議論を整理していきます。開発生産性Conference2024は、"LeanとDevOpsの科学"の著者のNicole Forsgrenさんの基調講演があったり、開発生産性の改善に取り組んでいる日本のさまざまな企業がハイブリッドで参加する1000名以上規模のカンファレンスです。このカンファレンスの講演内容から、2024年現在の開発生産性についての取り組みと議論を整理します。

開発生産性の経営視点での構造化

　開発生産性Conferenceでは、（オープニングセッションなどを除き）47本の発表がありましたが、公開資料が確認できた22本のうち5件が組織や経営に関するものでした。これらの講演では開発生産性の活動を、構造的なレイヤーや時間軸で分割し、PL(損益計算書)、BS(賃借対照表)などの経営上の会計方式から整理する試みをしています。

▶︎アウトプットの生産性とアウトカムの生産性

　Loglassさんの講演では、開発生産性をアウトカムに直接つながる本質的な業務の生産性と、そこに付随するアウトプット生産のための業務の生産性に整理しています。開発生産性を

仕事量の生産性
期待付加価値の生産性
実現付加価値の生産性

の3つのレイヤーに分割し、仕事量の生産性も重要とした上で、プロダクト開発組織としては期待付加価値の生産性が重要という考え方を紹介しています¹²。

　仕事量の生産性は開発/デリバリー工程の入力に対する出力を増やす生産性であり、アウトカムを増やすために付随する本質的ではない業務を効率化する生産性、すなわちアウトプットについての生産性です。期待付加価値の生産性と実現付加価値の生産性は、売上や利益などのいわゆるアウトカムを増やすための本質的な業務に対する生産性であり、アウトカムにつながるようなプロダクト要求開発やシフトレフトによる仕様の早期明確化が含まれています。

▶︎短期、中期、長期の時間軸から見た開発生産性

　BuySellさんは開発生産性を時間軸で捉え、短期的にアウトプットやアウトカムなどにつながるものと、中長期的な視点で計画、評価していくものがあることを紹介しています¹³。 VisionalさんのGP(総生産力)の考え方を導入した上で、テクノロジー戦略を時間軸で、

短期: SEO対策や社内のプロセス改善などにより、直接PLの利益やコスト削減などアウトカムにつながるもの
中期: ユーザー体験を改善させる機能開発による資産化や技術的負債の返却などBSを改善するもの
長期: DevOpsや開発プロセス改善、採用活動などのGPを改善するもの

と整理しています。

▶︎ソフトウェア開発とソフトウェア資産

　DMMさんの講演では、"開発生産性を上げる活動って儲かるの?"という問いに答えるため、PLとBSから開発生産性を説明しています¹⁴。ソフトウェア開発とPLとBSの関係を

ソフトウェア開発　→ ソフトウェア資産を作り、BSの資産に影響を与える時間軸の長い活動
ソフトウェア資産　→　PLの売り上げに直接的に影響を与える、時間軸の短いもの

とし、ソフトウェア開発はアウトカムを生むソフトウェア資産を作っていく時間軸の長い活動と整理しています。その上で、ソフトウェア開発の生産性を上げることで

無駄な開発コストの削減
売り上げ増加のためのビジネス面での仮説検証の回転数の増加とリードタイムの短縮
売り上げ損失の最小化

の影響をPLに与えることができるとしています。

　これら3つの講演を踏まえて、経営指標から見た2024年の開発生産性は以下のように整理できるのかなと個人的に考えたものが下の図です。

ITサービスの開発生産性改善の構造

整理のポイントとして、

開発生産性改善の効果のレイヤーを取り組みの改善対象である「アウトカム」「アウトプット」と、改善の最終結果である「経営指標」の3つで構造化していること
取り組みの改善対象が、アウトプットの改善か顧客満足を通したアウトカムの改善かを明確化していること
開発生産性改善の効果を「短期」から「長期」の時間軸の視点で整理していること
長期的な取り組みについてソフトウェア資産と技術的負債のアウトプットを定義した上で、そこからプロダクト仮説検証→アウトカムへの流れを整理していること

の4つがあります。

　この整理の中で開発生産性改善に関する各社の様々な取り組みを、①改善対象が「アウトカム」(図中の緑の取り組み/Aから始まるID)か「アウトプット」(図中のオレンジの取り組み/Bから始まるID)でまず区分けし、さらに時間軸と長期的な取り組みのアウトプットの種類で合計6つのカテゴリに区分けしました。それぞれのカテゴリの特徴と概要を以下の表で示します。

カテゴリ	改善対象	時間軸	長期的な取り組みのアウトプット	説明
A-1 SEO改善など	アウトカム	短期	N/A	売上などの事業指標に直接的に結びつくSEO対策などの活動マーケティングや販促に近いため、一般的には開発生産性活動には分類されない
A-2 プロダクト仮説検証	アウトカム	長期	N/A	アウトカムを増やすためのプロダクトの仮説検証を回す試行の回数(打席数)と精度(打率)を上げる取り組み　　ソフトウェア開発においてはアウトカムを直接増やすことは難しく、プロダクトの仮説検証を繰り返すことが重要開発生産性カンファレンスにおいて直接アウトカムで評価している発表はなかったが、ここを改善するための長期的な取り組みがB-2~B-4で紹介されている
B-1 プロセス改善	アウトプット	短期	N/A	ソフトウェア開発とデリバリー工程の単純作業の削減などによるプロセス改善短期的にFour Keysの変更のリードタイムと開発コストを削減する
B-2 ソフトウェア化	アウトプット	長期	資産	プロダクトの仮説検証の試行回数(打席数)を増やすための、開発プロセスのソフトウェア化による資産化。短期：資産化率の上昇 → 長期：収益の上昇
B-3 技術的負債返済	アウトプット	長期	負債	プロダクトの仮説検証の試行回数(打席数)を増やすための、ソフトウェアの技術的負債の返済　短期：技術的負債の減少　→ 長期：収益の上昇
B-4 開発者体験	アウトプット	長期	資産	プロダクトの仮説検証の試行精度(打席数)を増やすための、ソフトウェア技術者のスキルや開発者体験の向上　短期：開発者体験の向上 → 長期：収益の上昇

　次のセクションからはこの整理で開発生産性カンファレンスのその他の発表をご紹介していきます。 Aのアウトカムを直接的に向上しましたという発表はなかったのでここでは割愛し、アウトプットの量やコスト削減に取り組んでいるB-1からB-4の発表をそれぞれみていきます。

B-1 プロセス改善

　プロセス改善の事例では

変更のリードタイムをレビュー工程のリードタイムやテスト工程のリードタイムへと細分化し
Four Keysを活用したスピードと品質の両面からの改善

を短〜中期的に実施している事例が紹介されていました。

　Four Keysの変更のリードタイムにはコード変更のコミットから本番環境でのデリバリーまでのすべての工程が含まれてしまっており、ボトルネックとなっている工程の特定が困難だったり、品質担保のため本来必要な工程を削減してしまったりする課題があります。そういった課題に対し、これらの事例では変更のリードタイムをレビュー工程のリードタイムやテスト工程のリードタイムに分解し、さらに品質担保として本質的な作業のリードタイムと、待ち時間や単純作業のリードタイムに分解しています。

　SODA incさんの事例はレビュー工程に着目したプロセス改善事例です¹⁵。コードレビューのリードタイムを待ち時間であるPRオープンからレビューまでと、品質担保のための本質的な作業のリードタイムであるレビューからアプルーブまでのリードタイムに分割して集計し改善活動を実施することで、前者の待ち時間を25.5hrから7.3hrへと改善しています。

　食べログの事例ではテスト工程のリードタイムに着目した改善に加えて、Four Keysの変更障害率とデプロイ頻度に着目した中~長期の改善を紹介しています¹⁶。前者のテスト工程のリードタイムの改善では、テストデータの手作業による準備という単純作業のリードタイムを1800分から91分に自動化によって改善しています。また、後者では、開発プロセスの中に入り込むスタイルのインプロセスQAによって、2022年度から2023年度にかけてデプロイ頻度を同程度にキープしながら変更障害率を最大2.76%から0.76%へと改善しています。

　待ち時間や単純作業を計測しそれらを削減したり、Four Keysの変更障害率とデプロイ頻度など複数のメトリクスを計測することが、品質を犠牲にすることのないプロセス改善のコツと言えそうです。

B-2 ソフトウェア化

　開発プロセスのソフトウェア化による資産化に関する発表の中心はプラットフォームエンジニアリングであり、3件の事例発表がありました。プラットフォームエンジニアリングはDevOps以降普及したマイクロサービス・アーキテクチャ、KubernetesやIaCといったプロダクト開発の新技術に対する内部開発者向けのプラットフォーム(=ソフトウェア群)を提供する取り組みです¹⁷。

　経営指標視点で見ると、ソフトウェア開発に必要となる作業や知見をソフトウェア資産として構築することで、新サービスや機能を作る際にもそれらの資産を再利用し、車輪の再発明をせずとも迅速に打席に立てるようになります。

　カンファレンスでは3SHAKEさんがデプロイ作業を容易にするための仕組みをプラットフォームエンジニアリングで提供する取り組み¹⁸を、またGOさんがサービスに必要となる非機能要件を標準化しプラットフォームとして提供する取り組みを紹介しています¹⁹。

　プラットフォームエンジニアリングの事例発表の傾向として技術による開発生産性の改善として興味深い一方で、Four Keysを含む定量的指標による評価を実施している事例がなかったことがあります。これは前述のDMMさんの講演にあるように、資産化によるアウトカムの創出は長期的な取り組みであり、短期的なFour Keysなどのプロセス改善の指標だけでは測りきれないことが理由として考えられます。

B-3 技術的負債

　ソフトウェアの技術的負債の返済による試行回数(打席数)を増やすための事例発表としては、Chatworkさんの事例発表がドンピシャのものでした²⁰。こちらの事例発表もB-2と同様に、アウトカム向上のためのプロダクトの仮説検証の試行回数を増やしていくことを目的としています。

　B-2との違いは、B-2の手段は手作業や知見をソフトウェア化するのに対し、B-3の手段はプロダクトのシステムアーキテクチャ自体の保守性を向上したり、変更や拡張をしやすくしていくことです。 Chatworkさん(2024年7月に社名をkubellに変更)の事例では、開発速度の低下を招きかねないアーキテクチャ的な要因をアプリケーションモノリス、データベース結合モノリス、リリースモノリスの観点から分析した上で、根本原因はデータベース結合モノリスにあるとし今後の改善方針を紹介しています。

　また、カンファレンス最終日のt_wadaさんの基調講演「開発生産性の観点から考える自動テスト」も事例ではありませんが技術的負債の返済の観点から重要なトピックです²¹。技術的負債となりえるものはプロダクト自身のアーキテクチャ設計だけでなく、B-2の取り組みで資産化された自動テストも同様です。自動化されたテストでもテストレベルにより実行コストや実行時間に差があり、実行コストの高いE2Eレベルの自動テストが多いアイスクリームコーン型のテスト自動化ピラミッドは技術的負債化していると言えるでしょう。

　このカテゴリの開発生産性改善のトピックとして、技術的負債の定量化が依然難しいこと、またアウトカム向上の効果が出るまでの時間軸が長いことがあります。そのため、優秀なエンジニアなら感覚的に知っている技術的負債とアウトカムの因果関係について定量的な評価が難しいことがあり、今後の議論の発展が期待されます。

B-4 開発者体験

　ソフトウェア技術者のスキルや開発者体験の向上については、それ単体での事例発表はありませんでしたが、組織全体の開発生産性改善の指標計測の文脈で、Four Keysや経営指標だけでなく開発者体験に関する指標も集計している事例の紹介がありました。

　freeeさんでは開発生産性改善のフレームワークに対する定性的な評価をSPACEにもとづいたアンケートの計測で行なっています²²。これは、開発生産性を向上する要素として人間も大きな割合を占めているため、うまく改善活動を進めていくためには単に指標の数字だけをみてそれをよくするのではなく、改善活動に関わる人間の満足度も上げていくことの重要性が示しています。

　また、ビズリーチさんでは、事業の営業指標、マーケティング指標とFour Keysなどのプロダクト開発指標を構造化しSODA構想として定義しているなかで、従業員のエンゲージメントを表すe-NPSを集計しています²³。講演の中では、Four Keysの単体の指標だけに着目してしまうと数字を良くするためのハックや、逆に数値入力の精度の悪さを取りこぼしてしまう可能性があるため、アウトカムの指標や満足度などから総合的に判断することが重要と指摘しています。

　ソフトウェア技術者のスキルや開発者体験についての指標については、事例発表をしている先進的な企業も計測を始めたばかりであり、まだまだこれから発展していく分野であると言えそうです。ただ、開発者体験とアウトカムの因果関係などがわかるのであれば、今後面白い議論の展開が期待できる分野ですね。

2024年時点での開発生産性の現在地

　ここまでみてきたように開発生産性Conference 2024では、ITサービスのサービス業と製造業の両者の性格に対しアウトカムとアウトプットの2つの軸で開発生産性についての議論が展開されています。サービス業として顧客満足度やアウトカムを向上させることが一番重要ですが、それを短期的に直接劇的に改善する銀の弾丸はなく、プロダクトの仮説検証の試行回数と試行精度を改善する取り組みを

開発プロセスのソフトウェア化による資産化
技術的負債の返済
開発者体験の向上

によって向上させることを各社取り組んでいます。

　ソフトウェア開発にまつわる指標の問題点については、Four Keysの登場以前からマーチンファウラー²⁴やトム・デマルコ²⁵らによって指摘されてきました。ここでは「計測できないものは制御できない」で有名なソフトウェア工学の第一人者であるデマルコが自身の考えを改めた話が衝撃的かつ本質的なので、翻訳記事を引用します。

この記事のなかで、例えば、GoogleEarch や Wikipedia といったソフトウェアが、果たして計測と制御という管理で作られただろうか、と問うている。そして、２つの種類のプロジェクトを例にし、

Project A: 100万ドルのコストを使って 110 万ドルの価値を作る。

Project B: 100万ドルのコストを使って 5,000 万ドル以上の価値を作る。

「計測と制御」は、Project A の世界では有効だが、Project B の世界ではほとんど意味をなさない、と指摘している

　このトム・デマルコの指摘は、まさにソフトウェア開発のアウトカムがコストに対して一律ではなく、アウトプットの制御と比べてアウトカムの制御が難しいことをあらわしていると思います。

　アウトカムの質をあげていくためには、短期的にソフトウェアエンジニアリングを計測、制御するだけでなく、プロダクトの仮説検証の仕組みを長期的に作る必要があり、それが現在の開発生産性改善の「開発プロセスのソフトウェア化による資産化」「技術的負債の返済」「開発者体験の向上」の3つの議論なのだと考えられます。

まとめ

　このブログ記事では、開発生産性の歴史についてアジャイル開発の源流である日本の製造業の1950年代から2000年代のサービス業、2010年代のITサービス業まで振り返った上で、開発生産性の2024年の現在地について開発生産性Conference 2024の講演をもとに議論しました。開発生産の歴史が、品質も含めた生産プロセスコスト管理として始まり、時代と共に売上に展開され、今日のITサービスでのアウトカムとアウトプットの議論まで発展してきました。

　2024年現在、アウトカムを短期で直接的に改善する銀の弾丸はないものの、アウトカムを向上させるためのプロダクトの仮説検証の試行回数と試行精度をあげていくための「開発プロセスのソフトウェア化による資産化」「技術的負債の返済」「開発者体験の向上」の3つがITサービスにおける開発生産性改善の土台となっていると言えそうです。

　ただし、これらの取り組みは長期的な時間軸での改善活動であり、定量的な評価の仕組みが十分とは言えません。今後、長期的な時間軸の枠組みの中で、開発生産性の定量的な評価やアウトカムとの因果関係の説明の仕組みが発展していくことが期待されます。