開発生産性、なぜ測れない？指標不在の現状と実践的指標導入の鍵

「開発スピードが落ちてきた」「AIを入れたけど効果が測れない」「品質とスピードが両立できない」
そんな課題を抱えていませんか？
日本のITエンジニア798名の調査で明らかになったのは、開発の生産性を阻害している大きな要因は技術力不足ではなく、要件定義の不明確さや会議の多さといった組織運営の問題でした。
多くのチームが「改善の必要性は感じているが、何から手をつければいいか分からない」という状態に陥っています。
本セミナーでは、この調査結果をもとに、

・技術課題以上に影響を与える“本当のボトルネック”の特定方法
・「何を測るべきか」から始める生産性改善の第一歩
・他社の事例から学ぶ、スピードと品質を両立する施策

などを背景の歴史や事例を交えて詳しく解説します。
生成AIや新しいツールを導入しても成果が見えにくい方、また改善の根拠や説得材料を探している方にもおすすめの内容です。

Transcript

1. Findy Inc. 開発生産性、なぜ測れない？ 指標不在の現状と実践的指標導入の鍵 [2025/8/26 火曜日] ファインディ株式会社 CTO室 高橋 裕之
2. ◆ 1989年 株式会社ジェーシーイ ◆ 1993年 フリーランス ◆ 1995年 株式会社メイテック ◆ 1996年 日立通信システム株式会社（現・株式会社日立情報通信エンジニアリング） ◆ 2002年 ソニーデジタルネットワークアプリケーションズ株式会社 コンシューマ向けカメラ開発、組織横断型プロセス改善（SEPG）に従事 ◆ 2013年 ウイングアーク１ｓｔ株式会社 プロセス改善コーチ兼アジャイルコーチとして活動。2018年よりソフトウェアプロセス＆ 品質改善部部長、製品品質管理責任者、オープンソース管理責任者を務める。 ◆ 2021年 株式会社ビズリーチ プロセス改善コーチ兼アジャイルコーチとして活動。QAとプロセス改善部門のマネジャー として、DevOpsアプローチによる開発透明性向上とDORA(Four Keys)メトリクスを用いた 開発生産性による改善活動を実施。SODA（Software Outcome Delivery Architecture） 構想を立案し、プロダクトの事業影響を定量化・可視化する組織変革をリード。 ◆ 2024年 ファインディ株式会社 ソフトウェアプロセス改善コーチ兼アジャイルコーチとして活動。 エンジニア組織への新技術・方法論導入支援のイネーブルメントを担当。 1989年より組込みエンジニアとして、電話網の交換機開 発携わり国産OS CTRONをスクラッチで開発。また、 BSD UNIXベースのTCP/IPプロトコル開発に従事。その 後、メーカーでRTOSや組込みLinuxを基盤としたテレビ、 デジタルカメラ、ビデオカメラなどの開発に16年携わる。 2005年からソフトウェア開発で起きるさまざまな問題に 向き合うことを決意しSPI（ソフトウェアプロセス改善） の専門家へ転身。 問題を抱える開発チームに向き合いながら、計測エビデ ンスをもとにしたケイパビリティモデルに基づくプロセ ス改善活動を得意とする。 Findy Tech Blog 編集長。 高橋 裕之/ Hiroyuki Takahashi ファインディ株式会社 CTO室 Software Engineer, SPI Coach, Agile Coach @Taka_bow takabow hiroyukitakah
3. 会社紹介 3
4. © 2024 Findy Inc. 会社概要 挑戦するエンジニアの プラットフォームをつくる。 ビジョン つくる人がもっとかがやけば、 世界はきっと豊かになる。 経営理念 会社名 ファインディ株式会社 / Findy Inc. 代表取締役 山田 裕一朗 設立 2014 年 2 月 ※ 本格的な事業開始は2016年7月 社員数 297 名 資本金 18 億 5,043 万円 ※ 資本準備金含む 住所 東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー 5階 事業許可番号 13-ユ-308478 サービス ・ スカウト型リクルーティングサービス「Findy」 ・ ハイスキルな業務委託エンジニア紹介サービス「Findy Freelance」 ・ 外国籍エンジニア紹介サービス「Findy Global」 ・ エンジニア組織支援SaaS「Findy Team+」 ・ 開発ツールに特化したレビューサイト「Findy Tools」 投資家 グローバル・ブレイン、ユナイテッド、SMBCベンチャーキャピタル、 KDDI、JA三井リース、みずほキャピタル、博報堂ＤＹベンチャーズ、 Carbide Ventures、等
5. © Findy Inc. ファインディが展開するエンジニアプラットフォーム サービス紹介 ToC / ToB SaaS / ToB マッチングサービス 組織分析SaaS ToC / ToB 開発ツールメディア ※ 各種数値は、2024年6月時点のFindy転職、Findy Freelance、Findy Team+、Findy Globalの4サービスの累計での社数及び登録者数です。 なお、1社又は1名の方が複数のサービスに登録している場合は、そのサービスの数に応じて複数のカウントをしています。 β 版 GitHubやJiraを解析し、エンジニア組織の 見える化と生産性向上をサポート。 エンジニア組織の見える化 5万人以上のフリーランスエンジニアの 成功報酬型の人材紹介サービス。 フリーランスエンジニアの採用 約12万人のエンジニアと880社以上の テック企業をマッチング。 正社員エンジニアの採用 実際に利用している企業の声を元に、 開発ツールの導入や検討に必要な情報を 集約。企業の技術選定をサポート。 開発ツールのレビューサイト 5
6. ソフトウェア開発における「開発生産性」 に関する実態調査レポート ⚫ 調査対象： ソフトウェア開発（組み込み開発を含 む）に直接関わるエンジニア、プロダクトマネージ ャー、プロジェクトマネージャー、エンジニアリン グマネージャー、開発責任者など ⚫ 調査方法： インターネット調査 ⚫ 調査期間： 2025年4月2日(水)～2025年5月21日(水) ⚫ 調査主体： ファインディ株式会社 ⚫ 実査委託先： GMOリサーチ&AI株式会社 ⚫ 有効回答数： 798名 ※本調査はファインディ株式会社の利用ユーザーに 対する調査ではないことをご留意ください。 ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
7. 調査回答者の属性分析 7
8. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
9. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
10. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
11. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
12. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
13. WF 36.8% よくわからない 18.2% ハイブリッド 13.2% アジャイル 31.1％ ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
14. 開発フレームワーク利用状況 開発フレームワーク 回答者数 利用率 統計的有意性 分類 ウォーターフォール 294名 36.8% p < 0.001 従来型手法 開発フレームワークはよくわからない 145名 18.2% p < 0.001 組織課題 ウォーターフォールとアジャイルのハイブリッド 105名 13.2% p < 0.001 混合手法 【アジャイル開発】決まったフレームワークはない 105名 13.2% p < 0.001 アジャイル系 【アジャイル開発】スクラム 54名 6.8% p < 0.001 アジャイル系 【アジャイル開発】XPのプロセス 30名 3.8% p < 0.001 アジャイル系 【アジャイル開発】大規模スクラム：LeSS 19名 2.4% p < 0.05 アジャイル系 【アジャイル開発】大規模スクラム：SAFe 10名 1.3% p < 0.05 アジャイル系 【アジャイル開発】大規模スクラム：Nexus 10名 1.3% p < 0.05 アジャイル系 【アジャイル開発】大規模スクラム：Scrum@Scale 6名 0.8% n.s. アジャイル系 【アジャイル開発】大規模スクラム：その他 6名 0.8% n.s. アジャイル系 リーン 3名 0.4% n.s. アジャイル系 カンバン 2名 0.3% n.s. アジャイル系 その他 8名 1.0% n.s. その他 ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
15. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
16. 単純な比較はできませんが… 16 ⚫ The 17th State of Agile Report(2023) ⚫ 調査回答者の71%が、ソフトウェア開発ライフサイクル（SDLC）でアジャイルを使用している ⚫ アジャイルと組み合わせたハイブリッドモデルを使用している組織は42% （*複数回答とのこと） https://digital.ai/resource-center/analyst-reports/state-of-agile-report/
17. 単純な比較はできませんが… 17 ⚫ PMI Pulse of the Profession 2023: Power Skills for Project Success ⚫ 左の図はPMの主要なアプローチ（予測型、ハイブリッド、アジャイル）の利用頻度の変化を時系列で示しています ⚫ 金融サービス業界（58%）、IT（53%）、ヘルスケア（41%）、政府（40%）、通信（38%）、建築（25%）などがアジ ャイルを常にまたは頻繁に利用している。 https://www.pmi.org/learning/thought-leadership/future-of-project-work
18. 単純な比較はできませんが… 18 ⚫ PMI Pulse of the Profession 2023: Power Skills for Project Success ⚫ 左の図はPMの主要なアプローチ（予測型、ハイブリッド、アジャイル）の利用頻度の変化を時系列で示しています ⚫ 金融サービス業界（58%）、IT（53%）、ヘルスケア（41%）、政府（40%）、通信（38%）、建築（25%）などがアジ ャイルを常にまたは頻繁に利用している。 https://www.pmi.org/learning/thought-leadership/future-of-project-work
19. 「ウォーターフォールとアジャイルのハイブリッド」という課題の本質的考察 19 ⚫ ハイブリッドの課題（13.2%） ⚫ アジャイルとウォーターフォールは本質的に相反 ⚫ 安易な混合は強みを希薄化し非効率化 ⚫ 背景に「アジャイル理解不足」の可能性 ⚫ 真の実践には文化・プロセス全体の見直しが必要
20. 開発生産性への認識は前向き でも実践にはギャップが
21. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
22. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0. ポジティブ派が44.3％なのに…
23. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
24. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
25. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
26. 「何を測るべきか」の共通認識の欠如
27. 開発生産性指標の認知度と活用率 ⚫ 今回の調査では、開発生産性の指標について「認知度」と「活用状況」の2つの観点から質問しました。具体 的には、広く知られる用語や指標について「知っているか」と「実務で活用しているか」を調べました。 ⚫ 調査の包括性を担保するため、あえて適切でない指標や重複する用語も選択肢に含めました。これにより、単 なる認知度だけでなく、指標に対する理解度や認識の正確性も測定できる設計としました。 1. 以下の指標やフレームワークのうち、あなたが「知っている（名前を聞いたことがある、概 要を知っている等）」ものをすべて選んでください。 [複数回答] 2. 以下の指標やフレームワークのうち、あなたの組織やチームで「実際に活用している」もの をすべて選んでください。 [複数回答]
28. 開発生産性にふさわしい指標（14項目） 28 ⚫ 現代的な開発生産性測定において科学的根拠を持つ 指標群 1. Four Keys / DORAメトリクス – 実証研究に基づく包括 的生産性指標 2. 変更リードタイム – 要求から価値提供までの時間効率 3. デプロイ頻度 – 継続的価値提供能力の測定 4. 平均復旧時間（MTTR） – システム回復力と運用効率 5. 変更失敗率 – 品質と速度の最適バランス 6. SPACEフレームワーク – 多次元的生産性評価手法 7. デベロッパーエクスペリエンス（DevEx） – 開発者効 率性の統合指標 8. DX Core 4 – 複数フレームワークの統合測定 ⚫ リソース効率ではなく、作業の流れ（フロー）に焦 点を当てた指標群 9. Flow Metrics – 開発プロセス全体の流れの可視化と最 適化 10. プルリクエストサイクルタイム – コード統合プロセス の効率性 11. コードレビュー効率 – 品質担保における時間効率 12. バグ修正のスピード – 問題解決プロセスの効率性 ⚫ 長期的な生産性維持に関わる指標 13. 技術的負債の定量評価 – 将来の生産性への影響度測定 14. コードのリワーク率 – プロセス品質と手戻り作業の削 減度
29. 開発生産性としてはふさわしくない指標（11項目） 29 ⚫ 作業量と開発量を測定する指標 ⚫ これらは結果のみに着目しており、開発プロセスの効率 や価値創出を正しく評価できない 1. コードの行数 – 1000行のコードを書くより10行で解決でき る方が生産的な場合が多い 2. コミット数 – 活動量を示すのみで、品質や生み出される価 値とは無関係 3. ベロシティ（ストーリーポイントの消化速度） – チーム内 の作業量予測ツールであり、生産性指標としては適切では ない ⚫ リソースの使用効率を測る指標 ⚫ 真の生産性向上には結びつかないことが多い 4. 残業時間 – 投入時間の増加は生産性の低下を示唆する場合 が多い 5. タスクの完了数 – 量的成果であり、価値や効率性を反映し ない 6. タスクの割り当て数（比率） – リソース効率重視は、必要 な"ゆとり"（Slack）を排除する ⚫ 品質や満足度を測る指標 ⚫ 重要な指標ではあるが、生産性を直接測るものではない 7. バグの数 – 品質指標であり、生産性とは異なる概念 8. テストカバレッジ – 品質管理手法の一つ 9. チームの幸福度（eNPS） – 生産性に影響するが間接的指標 10. 顧客からのフィードバック – 価値検証の手段であり生産性 測定ではない 11. PSP（Personal Software Process） – 個人レベルのプロセ ス改善手法
30. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
31. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
32. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
33. グッドハートの法則 “測定が目標になると、それは良い測定ではなく なります。システムにプレッシャーをかけると、 規則性は消えます。それよりも悪いことに、物事 を良くするためにその規則性にプレッシャーをか けると、最初にその規則性を作り出したシステム を破壊してしまうのです” Kent Beck 開発生産性Conference 2025 基調講演にて
34. 測定を「コントロール」ではなく「認識」のツールとして 34 1. Observe later（後で観察する） 価値連鎖の早い段階（努力やコード量）ではなく、後の段 階（アウトカムや影響）を観察することを推奨しています。 「開発者1人あたりの利益を見てください」と彼は例を挙 げています。 2. Encourage awareness（認識を促す） 「システムを高速化する最良のテクニックの1つは、シス テムがどれだけ速いかをグラフ化することです」と述べ、 可視化によって自然な改善を促すことを提案しています。 3. Avoid pressure（プレッシャーを避ける） 「リーダーとしてプレッシャーをかけないことは最も難し いことです。しかし、プレッシャーをかけると、システム の歪みが生じます」と警告しています。 4. Instill purpose（目的を植え付ける） 「今のような頻度で本番環境のインシデントが発生しない 世界は素晴らしいと思いませんか？」という形で、プレッ シャーではなく共通の目標として提示することの重要性を 語っています。 Kent Beck 氏（開発生産性Conference 2025）
35. ソースコード管理ツールとAI活用の関係
36. ファインディ株式会社 (2025). 「ソフトウェア開発における『開発生産性』に関する実態調査」.CC BY-SA 4.0.
37. ソースコード管理ツール利用状況 37 ⚫ 従来型ツールの利用は「古い」以上に重大なリスクです。Visual SourceSafeは2005年に更新終了しています が、126人（15.8%）が依然使用していました。 ⚫ これらの利用者やSubversion（13.7%）、CVS（3.6%）の組織は、CopilotなどAI時代の支援ツールを活用で きず、競争力格差拡大のリスクに直面しています。 ツール 利用率 サポート状況 最終更新 セキュリティリスク Visual SourceSafe (VSS) 15.8%(126人) サポート完全終了 2005年10月 極めて高い CVS 3.6%(29人) 事実上の開発停止 2008年5月8日 高い Subversion (SVN) 13.7%(109人) 限定的メンテナンス 2024年12月8日 中程度
38. 従来型ツールの利用による技術的制約とは 38 ◼ API仕様の違いによる機能制限 • Visual SourceSafe: COM APIベースのアクセス方式（2005年設計のため、現代的なREST API仕様には非対応） • Subversion: WebDAV/HTTP APIを実装（一部のJSON形式APIには対応しているが、現代的なWebhook機能は制限的） → 結果: AIツールによるプログラム的なアクセスにおいて、一部機能が制限される場合があります ◼ メタデータ構造の違いによるAI学習への影響 • 従来型ツール: ファイル変更履歴を中心とした情報構造（コミット単位の情報は限定的） • モダンツール: コミット意図、レビュー履歴、イシュー関連付けなどの豊富なコンテキスト情報を構造化 → 結果: AIによるコードコンテキストの理解において、活用できる情報量に制約が生じる場合があります ◼ 開発エディタとの統合における制約 • VS Code、JetBrains IDEs: Git統合を前提とした拡張機能エコシステムが充実 • Cursor: Gitリポジトリ構造に最適化されたAI機能を提供 → 結果: 従来型ツールでは最新の開発環境の一部機能を十分に活用できない場合があります
39. DevOpsムーブメントが来ないまま GenAIムーブメントが来てしまった日本
41. 主な出来事（アメリカと日本の対比） 誕生したソフトウェア（アプリ・サービス） ICTの進化 ソフトウェア関連の論文・文献
43. （参考）ソフトウェア開発現代史シリーズ https://speakerdeck.com/takabow 43 2024/8/8 お客様向け資料(非公開) 「モダンソフトウェア エンジニアリングとは」 ◼モダンなソフトウェアエ ンジニアリングを導入す ることの具体的なメリッ トを把握する ◼戦後日本の製造業とソフトウェ アエンジニアリングの歴史を振 り返り、世界と日本の進化にな ぜ差ついたのかを理解する ◼なぜ日本のソフトウェア開発は 「ウォーターフォール」を受け入 れ続けているのか？の謎に迫る。 ◼DevOpsが未定着な日本の謎と DORA10年の歴史を振り返り、ソフト ウェア開発マネージメントに持ち込ま れた「科学的」とは何か？を解説 ◼日米のソフトウェア産業を比較し、日 本特有の停滞要因を歴史的・組織的視 点から分析
45. 45 The New New Product Development Game (1986) 竹内弘高 氏 ハーバード大学経営大学院シニ アフェロー、一橋大学名誉教授、 学校法人国際基督教大学理事長 故 野中郁次郎 氏 一橋大学名誉教授、カリフォル ニア大学バークレー校特別名誉 教授、日本学士院会員 Abstract： 新しい製品開発において、特にそのスピードと柔軟性の向上 が重要であることがますます認識されるようになってきまし た。本論文では、日本の企業がどのようにしてこれらの特性 を達成しているかを分析します。具体的には、製品開発プロ セスを従来の「リレー・レース型」から「ラグビー型」に移 行させることに焦点を当てます。「ラグビー型」では、プロ ジェクトチームが一体となって連携し、反復的かつ漸進的に 作業を進めていきます。この方法により、企業は市場の変化 に迅速に対応し、より効率的に製品を開発することが可能と なります。
47. Manufactur ing Industry in Japan The New New Product Developm ent Game (1986) SCRUM Development Process （1995） XP Explained : Embrace Change （1999） アジャイル ソフトウェア 開発宣言 (2001) The Scrum Guide （2010～） Agile
48. Manufactur ing Industry in Japan The New New Product Developm ent Game (1986) SCRUM Development Process （1995） XP Explained : Embrace Change （1999） アジャイル ソフトウェア 開発宣言 (2001) The Scrum Guide （2010～） Agile DevOps (2009～)
49. Manufactur ing Industry in Japan The New New Product Developm ent Game (1986) SCRUM Development Process （1995） XP Explained : Embrace Change （1999） アジャイル ソフトウェア 開発宣言 (2001) The Scrum Guide （2010～） Agile DevOps (2009～) GenAI (2021～)
51. Manufactur ing Industry in Japan The New New Product Developm ent Game (1986) SCRUM Development Process （1995） XP Explained : Embrace Change （1999） アジャイル ソフトウェア 開発宣言 (2001) The Scrum Guide （2010～） Agile DevOps (2009～) GenAI (2021～)
52. GenAI Waterfall （1976～）
54. GenAI Waterfall （1976～）
56. Flickrの伝説的講演「10+ Deploys Per Day」 ⚫ 伝説の講演（Velocity 2009） ⚫ Flickrのエンジニアが「10+ Deploys Per Day」を発表 ⚫ 1日10回以上のデプロイを実現 ⚫ 月1回～四半期1回が主流の時代に革命的実践
57. Flickrの伝説的講演「10+ Deploys Per Day」 ⚫ 彼らが強調したのは次のポイントです。 1. 開発と運用の協力関係 - 両チームが共通の目標（ユーザー価値の提供）に向かって協力する 2. 小さな変更の頻繁なデプロイ - 大きな変更を一度にリリースするのではなく、小さな変更を頻繁にリリースする 3. 自動化の徹底 - テスト、デプロイ、モニタリングなど、あらゆる工程を自動化する 4. 「失敗は避けられない」前提 - 失敗を防ぐのではなく、素早く検知して回復する能力を高める ⚫ この講演は「高頻度デプロイは可能」という認識を広め、多くの企業がデプロイプロセスを見直す契機となり ました。現在もYouTubeで視聴可能で、DevOps学習の必見資料です。
58. パトリック・ドボアと「DevOps」という言葉の誕生 ⚫ Flickr講演に触発されたドボアは、エンジニアのナスラット・ナサーの「ベルギーでVelocityを」というツイ ートをきっかけに、DevOpsDaysの開催を決意しました。 ⚫ 2009年10月30日のカンファレンスには多様な参加者が集結。終了後、議論はTwitterに移り、ドボアがハッシ ュタグを「#DevOps」に短縮。これが「DevOps」という言葉の誕生となりました。 Patrick Debois （パトリック・ドボア） 2009年、彼は最初のdevopsdaysイベントを主催することで「devops」という言葉を生み出しました。 彼は世界各地で会議を開催し、新しいアイデアを収集・普及させました。パイオニアとして、彼は 常に実装・探求すべき新しいアイデアを探し求めています。現在はメディア業界で活動しており、 放送事業者が視聴者との閉じたフィードバックループによる対話に参入する移行を指導しています。 （参照： https://itrevolution.com/author/patrick-debois/ ） 58
59. 2010年代前半：ジェズ・ハンブルとCIから継続的デリバリー（CD）への発展 Jez Humble（ジェズ・ハンブル） ジェズ・ハンブルは、『Accelerate』（シンゴ賞受賞）、『The DevOps Handbook』、『Lean Enterprise』、およびジョルト賞受賞の『Continuous Delivery』など、ソフトウェアに関する複数 の著書を共著した人物です。彼は20年にわたるキャリアの中で、3大陸にわたるさまざまな規模の企 業でコード、インフラ、プロダクト開発に携わってきました。オバマ政権下のテックサージの一環 として、米国連邦政府の 18F チームで働いたほか、DevOps Research and Assessment LLC （DORA）を共同創業し、同社は 2018 年 12 月に Google に買収されました。現在は Google でサイ トリライアビリティエンジニア（SRE）として勤務しながら、カリフォルニア大学バークレー校の情 報学部で教鞭を執っています。 （参照： https://www.ischool.berkeley.edu/people/jez-humble ） 59 David(Dave) Farley（デイビッド（デイブ）・ファーリー） Dave FarleyはContinuous Delivery Ltdの創設者兼マネージングディレクター。30年以上にわたって コンピューターに関わる仕事をしており、ファームウェア、オペレーティングシステム、デバイス ドライバー、ゲーム開発、商用アプリケーションなど、あらゆる種類のソフトウェア開発に携わっ てきました。 約30年前から大規模分散システムの開発に取り組み始め、疎結合でメッセージベースのシステム開 発の研究を行っていました。これは今日のマイクロサービスアーキテクチャの先駆けとなるもので した 。 （参照： https://www.amazon.com/stores/author/B003VSTZ72/about ）
60. 2010年代前半：ジェズ・ハンブルとCIから継続的デリバリー（CD）への発展 60 ⚫ CIは「コード統合と検証の自動化」に焦点を当てるのに対し、CDは「デプロイまでの自動化」へ範囲を拡大 しました。この概念を体系化したのが、ジェズ・ハンブルとデビッド・ファーリーによる名著 Continuous Delivery（2010年、日本語訳2012年）です。 ⚫ ジェズ・ハンブルとデビッド・ファーリーは『Continuous Delivery』で以下の実践を提唱しました。 • デプロイメントパイプライン：コード変更を自動でビルド・テスト・デプロイ • 自動化テスト：単体～受け入れまであらゆるレベルを自動化 • 本番一致のステージング：「開発では動くが本番で動かない」問題を防止 • ブルーグリーンデプロイ：ダウンタイムなしのデプロイを実現
61. 2010年代中盤：ジーン・キムとDevOpsの理論体系化 61 2010年代中盤、DevOpsムーブメントの中心人物とし て台頭したのがジーン・キム（Gene Kim）です。彼は 優れた技術者であると同時に、複雑な概念を分かりや すく伝える稀有な才能を持ち合わせていました。それ まで現場レベルの実践知として広がっていたDevOpsの 考え方を、組織全体で取り組むべき体系的な方法論と して確立した功績は計り知れません。彼の著作は技術 書の枠を超え、多くの組織でDevOps変革の指南書とな っています。 Gene Kim 氏（開発生産性Conference 2025）
62. 2010年代中盤：ジーン・キムとDevOpsの理論体系化 62 ⚫ 2013年、ジーン・キムは、ケビン・ベア（Kevin Behr）、ジョージ・スパッフォード（George Spafford）と共に「The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win（邦題：The DevOps 逆転だ!）」を出版しまし た。 ⚫ この小説形式の書籍は、架空の自動車部品メーカー 「Parts Unlimited」のIT部門が、DevOpsの原則を 採用することで危機を乗り越える物語を描いていま す。物語形式でありながら、DevOpsの本質的な考 え方を分かりやすく伝え、多くの読者に影響を与え ました。
63. 2010年代中盤：ジーン・キムとDevOpsの理論体系化 63 ⚫ 2016年には、ジェズ・ハンブル、パトリック・ドボ ア、ジョン・ウィリス（John Willis）と共に「The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations」を出版し、DevOpsの実践をより体 系的にまとめあげました。 ⚫ この書籍では、DevOpsの三つの原則（Three Ways） が提唱されています： ✓ フロー（Flow） - 開発からデプロイまでの流れを最適 化する ✓ フィードバック（Feedback） - 問題を早期に発見し、 素早く修正する ✓ 継続的学習と実験（Continual Learning and Experimentation） - 失敗から学び、継続的に改善する ⚫ ジーン・キムの貢献により、DevOpsは単なる技術 的プラクティスではなく、組織文化の変革として広 く認識されるようになりました。
64. 10年前 20年前 30年前 40年前 50年前 2018： マイクロソフト、GitHub を 75 億ドルで買収 2001/2/11： アジャイルソフ トウェア開発宣言 2005/10 1991～： バブル崩壊「失われた◦◦年」 1988～： 日本を含む諸外国へ「通商法スーパー301条」発動 ソフト ウェア開発現 代史年表 Ver2.09 © 2025 ファ インデ ィ株式 会社. All rights reserved. （写真 および 他社ロ ゴを除 く） 本資 料はフ ァイン ディ株 式会社 が独自 に編集 ・作成 したも のです （一部 、パブ リック ドメイ ン素材 を含み ます） 。 Findy およ び Team+ はフ ァイン ディ株 式会社 の商標 です。 使用 されて いる写 真や他 社ロゴ は、各 権利者 に帰属 し、説 明目的 でのみ 使用し ていま す。そ の他の 商品名 やロゴ は、各 社の商 標また は登録 商標で す。 1974 2024 1976 1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 2014 2016 2018 2020 2022 Linux 0.01 リリース UNIXが商業化・断片化していく中、 Linuxはオープンソースの力で 統一的な開発基盤となり、 世界中の技術革新を支えた （1991/9/17） CVS 誕生 （1990） Subversionリリース （2000） （2005） GitHub リリース （2008） Bugzilla リリース （2000） Jira リリース （2002） AWS サービス開始 （2006） Jenkins 誕生 （2011） GitHub Actions （2018） ChatGPT 一般公開 （2022/11/30） GitHub Copilot （2021/6/29） Java v1.0 正式リリース Javaはオブジェクト指向と 仮想マシン技術を普及させ、 後の言語設計にも影響を与えた （1996） 1980年代後半～1990年代前半： UNIX戦争 1970～1980年代： 多くの企業や政府機関が「ウォーターフォールモデル」を公式な開発プロセスとして採用。 同時に、Royceの思惑と違う、誤解された「ウォーターフォール」が広まる Azure サービス開始 （2010） 1990～2000： 第一次ブラウザ戦争。Internet Explorerの躍進、 Netscape Navigatorの消滅 2009～2020： 第二次ブラウザ戦争 Google Chromeの躍進、 Internet Explorerの衰退 （2018） （2004） Google Cloud サービス開始 （2008） 欧州の自動車メーカ が中心となって公開（2005） （2011） 1985～1990： 国家プロジェクト 「Σ計画」が頓挫 （2006） （2004） 1975 1999 2018/11/22 2004/11/16 2006/10/19 1977 1986 2002 1995 2010～ 2017/6/22 1994/10/31 1989 2024/7/11 1987 1970 1989/02/01 1982 1979 2019/9/17 1992/3/13 1996/4/1 2010/10/12 2011/7/16 2022/12/17 2011/10/18 2021/3/15 2001/5/18 1996/8 1979 2004/7/16 2013/8/1 2014/4/22 2019/9/30 2021/12/10 1978 2024/9/13 1972 2026 1997～2010年代： 米国防総省(DoD)が CMMレベル3以上を防衛関連のソフトウェア調達 条件として要求し始める。 2000年代～： 米国を中心にでアジャイル手法が急速に広まり、ウォーターフォールは特にWeb系・スタートアップ企業ではほぼ使われなくなる。 1990年代： ウォーターフォールのリスクを軽減する開発手法が次々 と誕生（インクリメンタル、スパイラル、RUP など） 1980年後半～1990年前半： 米国防総省(DoD)の発注したソフトウェアに問題が多発。 米会計局でも多くの遅延／途中での挫折が発生 主 な 出 来 事 ソ フ ト ウ ェ ア 関 連 の 論 文 ・ 文 献 2010年～： 米国議会は2010会計年度国防権限法(NDAA 2010)において「迅速なITシステム獲得のための新たな取得プロセス の実施」(第804条)をDoDに命じ、事実上アジャイル型開発の原則を法制化* 1980年～： 米国防総省(DoD) がウォーターフォールを採用 初代iPhone発表 (2007/1/9) PC/AT互換機が誕生（1981～） ワークステーションの時代： Sun SPARCstation （1989～1994） Windows95 リリース コンシューマ向けOSに TCP/IPが標準搭載され ワークステーション並みに （1995） 初代iMac （1998～） Apple Macintosh （1984～） 家庭向けADSL・FTTHの普及、 ブロードバンド時代に突入 (2001～) ICT の 進 化 メインフレーム時代： IBM System 360とVT100（1970～1980） MacBook Pro M4 Max （2024） 2018/3/27 2000/12/1 2010/7/27 2016/10/6 2005/10/7 1990/10/10 1978/5/1 1988/3/1 1984 2021/8/1 1995/10/1 2003/9/1 1976 リリース （2004/2） Point: 米国防総省(DoD)が与えた影響 1981 2021/12/1 2025/1/3： Agile AllianceがPMBOK などを策定するPMIに加盟 Claude 1 （2023/3/14） Team+ （2021/10） Gemini 1 （2023/12/6） Devin （2024/3/12） Cline （2024/7） 2021～： AI（GenAI）が前提の時代へ 2000年代～： 日本は大企業を中心に、ウォータフォールモデルを採用し続ける。 2018/4/1 数字送信の開始による ポケベルブーム（日本） （1992～1996） F501i HYPER iモード開始 （1999/2/22） テレホーダイ （1995～2023） PC-9800シリーズ（1982～2003） 初代iPad発表 (2010/4/3) Samsung Galaxy S II (2011/5/2) 2020/3～2023/5： COVID-19 ARMアーキテクチャのSoC Apple M1 生産（2020） 1970年代後半～1980年代末： 日本車と家電がアメリカ市場を席巻。これが、徐々に日米貿易摩擦の火種に…… "ウォークマン” 1号機 TPS-L2 （1979） 世界初のポータブル CDプレーヤー D-50（1984） Toyota Corolla Liftback SR5 001 （1980～） “トリニトロン” 日本製品が欧米で人気 1979～： 日本の製造業の高品質、ものづくりの強さを研究。 2024/12/25 2013/1/10 2014/8/18 2023/11/21 2000/3～： ITバブル崩壊 パソコン通信 携帯電話・PHSの普及、インターネット黎明期 携帯電話の多機能化、ブロードバンド時代 スマートフォン普及時代（2010年、モバイル端末利用率がパソコン利用率を超える） 1974年： 「TCP/IP」の最初の仕様がRFC 675として公開 1982年～： 米国防総省(DoD)は全ての軍用コンピュータ網のためにTCP/IP標準を作成。その後、コンピューター産業に開放され、4.2 BSD UNIXを皮切りにほとんどの商用OSにTCP/IPが実装された。 2017/10/14 2003/9/1 2002/11/8 2009： Flickrのエンジニアである John AllspawとPaul Hammondが初めてDevOpsに繋がる伝説的な講演を行う 2000年代後半～： クラウドファースト・クラウドネイティブ時代に突入 2008/9～： リーマンショック 2010年以降～： 日本のスタートアップはクラウドファーストで事業を立ち上げ、初期からアジャイル手法を採用 ★ピアソンショック（2013年8月1日） 2012/3/15 2009/11/27 2008/12/30 2023/11/28 西 暦 Netflixが日本に上陸(2015/9/2) ※ では2007/1にサービスイン © T he Deming In stitute 2025/6/25
66. （2010年、日本語訳は2012年）
67. まとめと提言
68. まとめ – 日本の潜在力と課題 ⚫ 日本の強み ⚫ 高い専門性と革新意欲 ⚫ 生産性向上に前向き：44.3% ⚫ 「開発生産性は持続的な価値がある」と認識：58.5% ⚫ 明らかになった課題 ⚫ 技術環境に格差（約3割） ⚫ 不明確な要件（53.5%） ⚫ 会議が多い（38.7%） ⚫ コミュニケーション上の課題（33.6%）
69. 提言 – 戦略的施策と未来 69 ◼ 即時実施可能な施策 1. 要件定義プロセスの最適化 ⚫ 対話の体系化、プロトタイピング、段階的な要件確定 2. 会議運営の効率化 ⚫ 正しい会議設計 ⚫ AI活用（アジェンダ整理・議事録）、非同期ツール活用、 20%削減目標 3. CI/CDパイプラインの整備 ⚫ 自動化レベルの標準化 ⚫ レガシーツールからの移行 ⚫ 開発速度と品質を両立する基盤の構築 4. DORA指標の体系的導入 ⚫ リードタイム・デプロイ頻度を測定、改善サイクル確立 ◼ 日本の強みを活かす ⚫ 品質へのこだわり ⚫ 協調的な文化 ⚫ 継続的改善の姿勢 ◼ 結論 ⚫ 現場の専門性と実証データに基づく改善を組み合わせれ ば、日本の開発組織はAI時代に確かな競争優位を築け る。 現場の専門性と実証データに基づく改善を組み合わせれば、 日本の開発組織はAI時代に確かな競争優位を築ける。
70. ファインディができるご支援・サービスについて 70 要件定義プロセスの最適化 会議運営の効率化 CI/CDパイプラインの整備 DORA指標の体系的導入 AI Accelerate by 課題 ファインディのソリューション