ソフトウェア開発現代史: "LeanとDevOpsの科学"の「科学」とは何か？ - DORA Report 10年の変遷を追って - #開発生産性_findy

Findy Inc. ソフトウェア開発現代史: "LeanとDevOpsの科学"の「科学」とは何か？ - DORA Report 10年の変遷を追って - 開発生産性Conference
2025 予習会版ファインディ株式会社 CTO室高橋裕之（2025/4/15）

自己紹介 2

◆ 1989 株式会社ジェーシーイ SESとして日立通信システム株式会社に常駐。NTT交換機ソフトウェア開発や、TRONプロジェクトに参加し国産OSのCTRON開発に従事。その後、会社が倒産。 ◆ 1993 フリーランス日立通信システム株式会社と準委任契約を結び、NTT交換機開発プロジェクトに参画。基本OSや通信プロトコルソフト開発に従事。
◆ 1995 株式会社メイテック SESとしてJUKI株式会社に常駐。ICチップマウンターの組み込み開発に従事。 ◆ 1996 日立通信システム株式会社（現・株式会社日立情報通信エンジニアリング）正社員として復帰。携帯電話のCDMA2000交換機やIPv6機器開発に従事。また、システムエンジニアとしてJP1の導入支援を担当。 ◆ 2002 ソニーデジタルネットワークアプリケーションズ株式会社 RTOSや組み込みLinuxの専門家として、主にコンシューマ向けカメラ開発に従事。また、ソフトウェア開発の諸問題に取り組むため、組織横断型プロセス改善（SEPG）に従事。 ◆ 2013 ウイングアーク１ｓｔ株式会社プロセス改善コーチ兼アジャイルコーチとして活動。2018年よりソフトウェアプロセス＆品質改善部部長、製品品質管理責任者、オープンソース管理責任者を務める。 ◆ 2021 株式会社ビズリーチプロセス改善コーチ兼アジャイルコーチとして活動。QAとプロセス改善部門のマネジャーとして、 DevOpsアプローチによる開発透明性向上とDORA(Four Keys)メトリクスを用いた開発生産性による改善活動を実施。SODA（Software Outcome Delivery Architecture）構想を立案し、プロダクトの事業影響を定量化・可視化する組織変革をリード。 ◆ 2024 ファインディ株式会社ソフトウェアプロセス改善コーチ兼アジャイルコーチとして活動。チームトポロジー(Team Topology)の思想に則り、自組織全体の新技術・方法論導入支援のイネーブルメントを担当。 1989年より組込みエンジニアとして、OS開発、通信プロトコル開発、RTOSや組込みLinuxを基盤としたガジェット開発に16年携わる。2005年、それまでの経験を活かし、エンジニア人材と組織の課題解決に特化したSPI（ソフトウェアプロセス改善）の専門家へ転身。現在は、SPIコーチおよびアジャイルコーチとして活動し、DORAメトリクスを活用したプロセス改善活動を得意とする。ソフトウェアエンジニアリングの潜在能力向上支援（イネーブルメント）に注力し、組織のパフォーマンス最適化に貢献している。高橋裕之 / Hiroyuki Takahashi ファインディ株式会社 CTO室 Software Engineer, SPI Coach, Agile Coach @Taka_bow takabow hiroyukitakah 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、等

© 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社以上のテック企業をマッチング。正社員エンジニアの採用実際に利用している企業の声を元に、開発ツールの導入や検討に必要な情報を集約。企業の技術選定をサポート。開発ツールのレビューサイト 6

シリーズ：ソフトウェア開発現代史 7

仮説 8 ポルトガルの宇宙誌家・地図製作者バルトロメウ・ヴェーリョ（？-1568年）による、プトレマイオスの地球中心的宇宙観を描いた彩色図解。1568年にフランスで制作された彼の著作『宇宙誌』より（パリ、フランス国立図書館所蔵）。地球の中心からの天体の距離（左側）と公転周期（年単位、右側）に注目。最外縁のテキストには「天の帝国、神と全ての選ばれし者の住まい」と記されている。(public domain)

仮説 9 私の仮説：「正しいと信じ続けた価値観は、実は間違った歴史認識から来ている」

これまでの「ソフトウェア開発現代史」 10 2024/8/8 お客様向け資料「モダンソフトウェアエンジニアリングとは」本日の発
表

10年前 20年前 30年前 40年前 50年前 2018：マイクロソフ
ト、 GitHub を 75 億ドルで買収 2001/2/11：アジャイルソフトウェア開発宣⾔ 2005/10 1991〜：バブル崩壊「失われた◦◦年」 1988〜：⽇本を含む諸外国へ「通商法スーパー301条」発動ソフトウェア開発現代史年表 Ver2.08 © 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 Chrom eの躍進、 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） Window s95 リリースコンシューマ向けOSに TCP/IPが標準搭載されワークステーション並みに（ 1995）初代iMac （ 1998〜） Apple Macintosh （ 1984〜） DynaBook （ 1994〜）家庭向け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） Gem ini 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) Sam sung 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 Ham m ondが初めて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にサービスイン © The Deming Institute

12 1991〜：バブル崩壊「失われた 1988〜：⽇本を含む諸外国へ「通商法スーパー301条ソフト
ウェア開発現代史年表 Ver2.08 © 2025 ファインディ株式会社. All rights reserved. （写真および他社ロゴを除く）本資料はファインディ株式会社が独⾃に編集‧ 作成したものです（⼀部、パブリックドメイン素材を含みます）。 Findy™ および Team +™ はファインディ株式会社の商標です。使⽤されている写真や他社ロゴは、各権利者に帰属し、説明⽬的でのみ使⽤しています。その他の商品名やロゴは、各社の商標または登録商標です。 Linux 0.01 リリース UNIXが商業化‧ 断⽚化していく中、 Linuxはオープンソースの⼒で統⼀的な開発基盤となり、世界中の技術⾰新を⽀えた（ 1991/9/17） CVS 誕⽣（ 1990） 1980年代後半〜1990年代前半： UNIX戦争 1970〜1980年代：多くの企業や政府機関が「ウォーターフォールモデル」を公式な開発プロセスとして採⽤。同時に、 Royceの思惑と違う、誤解された「ウォーターフォール」が広まる 1990〜2000：第⼀次ブラウザ戦争。 Netscape Navigatorの消滅 1985〜1990：国家プロジェクト「 Σ 計画」が頓挫 1990年代：ウォーターフォールのリスと誕⽣（インクリメンタル、スパイラル発。⽶会計局でも多くの遅延∕ 途中での挫折が発⽣‵ 主な出来事がウォーターフォールを採⽤ Window コンシュ TCP/IPがワークス（ 1995） Point: ⽶国防総省(DoD)が与えた影響 1970年代後半〜1980年代末：⽇本⾞と家電がアメリカ市場を席巻。これが、徐々に⽇⽶貿易摩擦の⽕種に…… "ウォークマン” 1号機 TPS-L2 （ 1979）世界初のポータブル CDプレーヤー D-50（ 1984） Toyota Corolla Liftback SR5 001 （ 1980〜） “トリニトロン” ⽇本製品が欧⽶で⼈気 1979〜：⽇本の製造業の⾼品質、ものづくりの強さを研究。 © The Deming Institute

13 2018：マイクロソフト、 GitHub を
75 億ドルで買収 /11：アジャイルソフア開発宣⾔（ 2005） GitHub リリース（ 2008） a ース 2） AWS サービス開始（ 2006） Jenkins 誕⽣（ 2011） GitHub Actions （ 2018） ChatGPT ⼀般公開（ 2022/11/30） GitHub Copilot （ 2021/6/29） Azure サービス開始（ 2010） 2009〜2020：第⼆次ブラウザ戦争 Google Chrom eの躍進、 Internet Explorerの衰退（ 2018）（ 2004） Google Cloud サービス開始（ 2008）欧州の⾃動⾞メーカが中⼼となって公開（ 2005）（ 2011）（ 2006）（ 2004）⽶国を中⼼にでアジャイル⼿法が急速に広まり、ウォーターフォールは特にWeb系‧ スタートアップ企業ではほぼ使われなくなる。の実施」 (第804条)をDoDに命じ、事実上アジャイル型開発の原則を法制化 * リリース（ 2004/2） 2025/1/3： Agile AllianceがPMBOK などを策定するPMIに加盟 Claude 1 （ 2023/3/14） Team + （ 2021/10） Gem ini 1 （ 2023/12/6） Devin （ 2024/3/12） Cline （ 2024/7） 2021〜： AI（ GenAI）が前提の時代へ⽇本は⼤企業を中⼼に、ウォータフォールモデルを採⽤し続ける。 2020/3〜2023/5： COVID-19 ITバブル崩壊 2009： Flickrのエンジニアである John Allspaw と Paul Ham m ondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：クラウドファースト ‧ クラウドネイティブ時代に突⼊ 2008/9〜：リーマンショック 2010年以降〜：⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤

14 1975 1977 1986 1995 1994/10/31 1989 1987 1970 1989/02/01
1982 1979 1992/3/13 19 1979 1978 ソフトウェア関連の論⽂ ‧ ⽂献 PC/AT互換機が誕⽣（ 1981〜） Dyna （ 19 ICT の進化メインフレーム時代： 1990/10/10 1978/5/1 1988/3/1 1984 1995/10 1976 1981 数字送信の開始によるポケベルブーム（⽇本）（ 1992〜1996）パソコン通信携帯電

15 2005/10 2018/11/22 2004/11/16 2006/10/19 2 2010〜 2017/6/22 2024/7/11 2019/9/17
2010/10/12 2011/7/16 2022/12/17 2011/10/18 2021/3/15 2004/7/16 2013/8/1 2014/4/22 2019/9/30 2021/12/10 2024/9/13 2018/3/27 2010/7/27 2016/10/6 2005/10/7 2021/8/1 2003/9/1 2021/12/1 2018/4/1 Sam sung 2024/12/25 2013/1/10 2014/8/18 2023/11/21 携帯電話の多機能化、ブロードバンド時代スマートフォン普及時代（2010年、モバイル端末利⽤率がパソコン利⽤率を超える） 2017/10/14 2003/9/1 11/8 2012/3/15 2009/11/27 2008/12/30 2023/11/28

17 これまでの「ソフトウェア開発現代史」 ⚫ 1960年頃、日本のものづくりは「品質管理」という武器を手に入れ躍進。日本製品が世界中で人気となる ⚫ 1979年、米ハーバード大学のエズラ・ヴォーゲル教授が出版した『Japan as Number One: Lessons
for America』がベストセラーに “ウォークマン” 1号機 TPS-L2 （1979） Toyota Corolla Liftback SR5 001 （1980〜）ソニートリニトロンシリーズ（1968〜） Vogel, E. F. (1979). Japan as number one: Lessons for America. Cambridge, MA: Harvard University Press. W.E.Deming博士(1900〜1993) 世界初のポータブル CDプレーヤー D-50（1984）

18 これまでの「ソフトウェア開発現代史」 ⚫ 1960年頃、日本のものづくりは「品質管理」という武器を手に入れ躍進。日本製品が世界中で人気となる ⚫ 1979年、米ハーバード大学のエズラ・ヴォーゲル教授が出版した『Japan as Number One: Lessons
for America』がベストセラーに “ウォークマン” 1号機 TPS-L2 （1979） Toyota Corolla Liftback SR5 001 （1980〜）ソニートリニトロンシリーズ（1968〜） Vogel, E. F. (1979). Japan as number one: Lessons for America. Cambridge, MA: Harvard University Press. W.E.Deming博士(1900〜1993) 世界初のポータブル CDプレーヤー D-50（1984）戦後日本は愚直に学び、品質を鍛え抜いて世界を驚かせた。そして50年が経った・・・

20 ◼ 50年が経ちソフトウェア・ファーストな現代。 Big Techと呼ばれる企業は日本に1社も存在せず、そのほとんどは米国企業である ◼ ものづくりで世界をリードしてきたはずの日本は、ソフトウェア産業においては、実に50年近くも他国の後塵を拝し続けている……なぜか？

21 ウォーターフォール ⚫ Winston W. Royce による“Managing the Development of
Large Software Systems(1970)” Winston W. Royce （ウィンストン・W・ロイス）

22 ウォーターフォール ⚫ Winston W. Royce による“Managing the Development of
Large Software Systems(1970)” 図3 顧客に引き渡すための大規模プログラムを開発するための実現ステップ図4 反復（後戻り）は隣り合うステップに限定されない

犯人 ⚫ 「Software Requirements: Are They Really a Problem?」というT.E. Bellと
T.A. Thayerによる論文では、Winston W. Royceの1970年の論文を参照し、「開発活動のウォーターフォール（滝）」という表現を用いて、ソフトウェア開発プロセスの段階的なアプローチを説明しています。この際、Royceの提案を、各フェーズが順番に進む線形で非反復的なプロセスとして解釈しています。 ⚫ Royce自身は、元の論文で反復的なフィードバックと改善の必要性を強調していましたが、この論文では、ソフトウェア要件の問題の重要性を強調し、要件の不備が設計や実装段階での失敗につながると述べています。その結果、要件の不備を防ぐために「トップダウン型で進む厳密なプロセス」が必要であるとの主張が間接的にウォーターフォールの誤解に結びつきました。 ⚫ さらに、この概念が広く普及した背景には、Barry Boehm氏（COCOMOやスパイラルモデルを提唱した人物）が1981年の著書「Software Engineering Economics」でRoyce氏のモデルをウォーターフォール型として紹介したことも影響しています。これにより、ウォーターフォールモデルの誤解が強固なものとなり、業界全体でそのイメージが固定化されました。 Bell, T. E., & Thayer, T. A. (1976). Software requirements: Are they really a problem? Proceedings of the 2nd International Conference on Software Engineering (ICSE '76), 61–68. https://doi.org/10.5555/800253.807650

35年前に痛い目にあっている 24 ⚫ 1970〜1980年代：多くの企業や政府機関が「ウォーターフォールモデル」を公式な開発プロセスとして採用。同時に、Royceの思惑と違う、誤解された「ウォーターフォール」が広まる ⚫ 1980年〜：米国防総省(DoD)がウォーターフォールを採用 ⚫
1980年後半〜1990年前半：米国防総省(DoD)の発注したソフトウェアに問題が多発。米会計局でも多くの遅延／途中での挫折が発生

1980年後半〜1990年前半：米国防総省(DoD)の発注したソフトウェアに問題が多発。米会計局でも多くの遅延／途中での挫折が発生 1992/3/13 ※ただ自慢したいだけの写真 Edward Nash Yourdon これはエドワード・ギボンの古典的名著「ローマ帝国衰亡史」（The History of the Decline and Fall of the Roman Empire, 1776-1788）を模したタイトルと思われる。

1980年後半〜1990年前半：米国防総省(DoD)の発注したソフトウェアに問題が多発。米会計局でも多くの遅延／途中での挫折が発生 ⚫ 1990年代：ウォーターフォールのリスクを軽減する開発手法が次々と誕生（インクリメンタル、スパイラル、RUP など）ソフトウェアで復活を遂げたアメリカ 1992/3/13 1996/4/1 僅か4年後アメリカ人プログラマーの台頭と復活

35年前に痛い目にあっている 27 ソフトウェアで復活を遂げたアメリカ 1992/3/13 1996/4/1 僅か4年後アメリカ人プログラマーの台頭と復活研究しつくされる日本の製造業 1990/10/10 1988/3/1
1979 米国は、日本製造業の良いところを、ソフトウェア開発へ応用しまくった

20年前にあった有識者からの警告日経bizTech『日本のソフトウエア産業、衰退の真因』2005年10月 ⚫ 松原友夫氏（トム・デマルコ本の翻訳でおなじみ）による寄稿 ⚫ https://xtech.nikkei.com/it/article/COLUMN/20070306/264055/ ⚫ 要約 ① 背景と警告
1990年代、アメリカではエド・ヨードンがソフトウェア産業の危機を警告し、日本を模範的な存在として称賛しましたが、その後、アメリカはオブジェクト指向やアジャイルなどの新しい開発手法により復活を遂げました。 ② 日本の遅れ日本は、90年代においてメインフレームからクライアントサーバーへの移行に乗り遅れ、ソフトウェア開発における国際競争力を失いました。また、技術伝承の断絶や不十分なプロジェクト管理が原因で、開発の質が低下しました。 ③ 産業構造の問題日本のソフトウェア産業には多重下請け構造が蔓延し、派遣プログラマーに依存する状況が問題視されています。これにより、ソフトウェア開発の品質と効率が損なわれ、さらに低賃金の海外労働力に仕事が流れる懸念が高まっています。 ④ 提言日本のソフトウェア産業の再生には、「自立」が必要であると述べています。これは、ソフトウェア企業や技術者が自主的に技術と経営の自立を目指し、プロジェクトマネジメント力を高めることで達成されるべきです。また、政府やユーザー企業も、この自立を支援する役割を果たすべきであると提案しています。松原友夫氏（写真）http://www.kumikomi.net/archives/2005/02/04jasst.php

仮説 31 ⚫ 現代のソフトウェアが主体の「ものづくり」では、顧客への「完璧さ」よりも、エンドユーザーへのスピードと柔軟な改善が求められる。 ⚫ しかし日本のソフトウェア産業は正しいと信じ続けた価値観から抜け出せず、ウォーターフォール開発や人月ビジネスといった旧来の慣習にとどまり続けた。 ⚫ その結果、世界のソフトウェア産業を牽引するBig
Techの中に日本企業の姿は見当たらない。なぜ、こうなってしまったのか？ ⚫ さまざまな原因分析と解決策はこれまでも幾度となく提言されてきたはず。 ⚫ いま必要なのは、新しい解決策ではなく—— “なぜ今こうなっているのか？”という歴史を振り返る視点なのかもしれない。私の仮説：「正しいと信じ続けた価値観は、実は間違った歴史認識から来ている」

ソフトウェア開発現代史: "LeanとDevOpsの科学"の「科学」とは何か？ - DORA Report 10年の変遷を追って - 32

2018：マイクロソフト、 GitHub を 75
億ドルで買収 2001/2/11：アジャイルソフトウェア開発宣⾔ 2024 998 2000 2002 2004 2006 2008 2010 2012 2014 2016 2018 2020 2022 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）リースクト指向とを普及させ、も影響を与えた Azure サービス開始（ 2010） rの躍進、 2009〜2020：第⼆次ブラウザ戦争 Google Chrom eの躍進、 Internet Explorerの衰退（ 2018）（ 2004） Google Cloud サービス開始（ 2008）欧州の⾃動⾞メーカが中⼼となって公開（ 2005）（ 2011）（ 2006）（ 2004） 2026 7〜2010年代：⽶国防総省(DoD)が CMMレベル3以上を防衛関連のソフトウェア調達件として要求し始める。 2000年代〜：⽶国を中⼼にでアジャイル⼿法が急速に広まり、ウォーターフォールは特にWeb系‧ スタートアップ企業ではほぼ使われなくなる。発⼿法が次々 2010年〜：⽶国議会は2010会計年度国防権限法(NDAA 2010)において「迅速なITシステム獲得のための新たな取得プロセスの実施」 (第804条)をDoDに命じ、事実上アジャイル型開発の原則を法制化 * にリリース（ 2004/2） 2025/1/3： Agile AllianceがPMBOK などを策定するPMIに加盟 Claude 1 （ 2023/3/14） Team + （ 2021/10） Gem ini 1 （ 2023/12/6） Devin （ 2024/3/12） Cline （ 2024/7） 2021〜： AI（ GenAI）が前提の時代へ 2000年代〜：⽇本は⼤企業を中⼼に、ウォータフォールモデルを採⽤し続ける。 2020/3〜2023/5： COVID-19 2000/3〜： ITバブル崩壊ー産業に開放され、 4.2 BSD UNIXを⽪切りにほとんどの商⽤OSにTCP/IPが実装された。 2009： Flickrのエンジニアである John Allspaw と Paul Ham m ondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：クラウドファースト ‧ クラウドネイティブ時代に突⼊ 2008/9〜：リーマンショック 2010年以降〜：⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤ ★ピアソンショック（ 2013年8⽉1⽇）

DevOps誕生以前（〜2000年代前半） 35

DevOps誕生以前（〜2000年代前半） ⚫ 2000年代前半までのソフトウェア開発では、開発と運用は完全に分断され、しばしば対立関係にありました。開発チームの目標は「新機能を素早くリリース」、運用チームの目標は「システムの安定性維持」であり、この2つの目標はしばしば衝突していました。 ⚫ 開発チームは「とにかく早くリリースしたい」 → 変更を加えたがる ⚫
運用チームは「安定稼働が最優先」 → 変更を嫌う ⚫ 結果として、開発は「リリース遅延」に苛まれ、運用は「障害対応」に追われる ⚫ 変更のリスクを最小限にするために、厳格なリリースプロセスが敷かれ、開発者は運用チームから「勝手にデプロイするな」と釘を刺されていました。その結果、リリースサイクルは長期化し、開発の俊敏性が犠牲になっていったのです。 ⚫ 特に、大規模なリリースでは手作業によるデプロイが行われることが多く、設定ミスや環境差異が原因で障害が頻発していました。こうした問題を解決し、開発と運用のギャップを埋める新たなアプローチが強く求められていました。

10年前 20年前 30年前 40年前 50年前 2018：マイクロソフト、GitHub を 75 億ドルで買収
2001/2/11：アジャイルソフトウェア開発宣言 2005/10 1991〜：バブル崩壊「失われた◦◦年」 1988〜：日本を含む諸外国へ「通商法スーパー301条」発動ソフトウェア開発現代史年表 Ver2.08 © 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〜） DynaBook （1994〜）家庭向け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

38 Extreme Programming Explained: Embrace Change（1999） Kent Beck 1. 反復的な開発:
短期間のイテレーション（通常1〜2週間）を繰り返し、各イテレーションで動作するソフトウェアを提供する。 2. 顧客の関与: 顧客が開発チームの一員として積極的に関与し、要求を直接伝え、フィードバックを提供する。 3. ペアプログラミング: 2人のプログラマーが1台のコンピューターで共同作業を行い、コードの品質を向上させる。 4. テスト駆動開発（TDD）: コードを書く前にテストを作成し、そのテストに合格するコードを書くことで品質を保証する。 5. リファクタリング: コードの機能を変えずに内部構造を改善し、コードの保守性を向上させる。 6. シンプルな設計: 必要最低限の機能を持つシンプルな設計を行い、後で必要に応じて機能を追加する。 7. 継続的インテグレーション(CI): 新しいコードを頻繁に統合し、自動化されたビルドとテストを実行して問題を早期に発見する。 8. 持続可能なペース: 開発チームが過労にならないように、持続可能なペースで作業を進める。 9. コレクティブオーナーシップ: チーム全員がコードの責任を共有し、誰でもコードを変更できるようにする。 10. メタファーの使用: プロジェクト全体の理解を助けるために、共通のメタファーや比喩を使用する。 11. コードの共有: すべての開発者がコードを共有し、どの開発者も任意のコードを改善できるようにする。 Martin Fowler

39 Extreme Programming Explained: Embrace Change（1999） 1. 反復的な開発: 短期間のイテレーション（通常1〜2週間）を繰り返し、各イテレーションで動作するソフトウェアを提供する。 2.
顧客の関与: 顧客が開発チームの一員として積極的に関与し、要求を直接伝え、フィードバックを提供する。 3. ペアプログラミング: 2人のプログラマーが1台のコンピューターで共同作業を行い、コードの品質を向上させる。 4. テスト駆動開発（TDD）: コードを書く前にテストを作成し、そのテストに合格するコードを書くことで品質を保証する。 5. リファクタリング: コードの機能を変えずに内部構造を改善し、コードの保守性を向上させる。 6. シンプルな設計: 必要最低限の機能を持つシンプルな設計を行い、後で必要に応じて機能を追加する。 7. 継続的インテグレーション(CI): 新しいコードを頻繁に統合し、自動化されたビルドとテストを実行して問題を早期に発見する。 8. 持続可能なペース: 開発チームが過労にならないように、持続可能なペースで作業を進める。 9. コレクティブオーナーシップ: チーム全員がコードの責任を共有し、誰でもコードを変更できるようにする。 10. メタファーの使用: プロジェクト全体の理解を助けるために、共通のメタファーや比喩を使用する。 11. コードの共有: すべての開発者がコードを共有し、どの開発者も任意のコードを改善できるようにする。現在“モダン”と言われる開発プラクティスはほぼ、ここで出尽くしたと言っても過言ではないあとは実践研究と発展の歴史である Kent Beck Martin Fowler

40 アジャイルソフトウェア開発宣言(2001) 私たちは、実際にソフトウェアを開発し、他の人々がそれを実践するのを助けることによって、より良い開発方法を発見しています。この作業を通じて、次のような価値を見出しました： ⚫ プロセスやツールよりも個人と対話 ⚫ 包括的なドキュメントよりも動作するソフトウェア
⚫ 契約交渉よりも顧客との協力 ⚫ 計画に従うことよりも変化への対応つまり、左側の項目にも価値はありますが、私たちは右側の項目により価値を置きます。 ※日本語訳ページもあるのですが、表現が硬いので勝手に柔らかく訳し直しました https://agilemanifesto.org/iso/ja/manifesto.html ⚫ アジャイルソフトウェア開発宣言（Agile Manifesto）は、2001年2月にアメリカ・ユタ州のスノーバードスキーリゾートで開発された。この宣言は、17人のソフトウェア開発の専門家たちが集まって、ソフトウェア開発プロセスの改善について議論し、アジャイルというアプローチが生まれたことから発表された。 ⚫ その中で主要な貢献者として知られているのは、ケント・ベック、マーティン・ファウラー、ロン・ジェファリーズ、ジム・ハイスミス、ジョン・カーンズ、ウォード・カニンガム、ジョン・ハント、アンドリュー・ハント、ブライアン・マリック、ロバート・マーティン、デイブ・トーマス、マイク・ビードル、アリスター・コーバーン、ジェームズ・グレニング、ジェフ・サザーランド、ケン・シュワイバー、ジョン・ブラント ⚫ これらの人々は、それぞれ異なるソフトウェア開発手法（例：Scrum、Extreme Programming）を提唱・開発していたが、アジャイル宣言を通じて、共通の価値観と原則に基づいてソフトウェア開発を行うことで合意した。

41 アジャイルソフトウェア開発宣言(2001) ボブ・マーティンの思い出：（略） 2000年の春、Kent Beckがオレゴン州メドフォードにある自宅近くのRogue River Lodgeで会議を開きました。彼はこれをExtreme Programming
Leadership Conferenceと名付けました。出席者には私、Ron Jeffries、Ken Auer、Martin Fowler、そしてXP運動の立ち上げに尽力した他の数名がいました。（略） Alistairは事実上のオーガナイザーになりました。彼は開催地をアンギラからソルトレイクシティのスノーバードに変更することを提案しました。ほとんどの他の招待者がフライトが簡単になるため同意しました。 AlistairとJim Highsmithが部屋、食事、アクティビティの手配を行いました。物事は急速に進展しました。会議には約20人の招待者のうち17人が出席しました（出席者のリストはwww.agilemanifesto.orgを参照）。残念ながらGrady BoochとBig Dave Thomasは参加できませんでしたが、彼らの影響はその後の議論に強く感じられました。（略） Martin FowlerとWard Cunninghamは事実上のファシリテーターになりました。彼らの助けを借りて、私たちは2日間のアジェンダと意思決定の方法をすぐにまとめました。実際に、これらの異なるアイデアを持つ人々が非常によく協力しているのを見るのは本当にスリルがありました。私は、これほどポイントに集中し、目標を簡単に達成し、ほとんど争いのない会議に参加したことがありませんでした。それはまるでピースがなんとなく一緒に収まったかのようでした。初期の議論の一つは名前についてでした。誰も Lightweight という用語を気に入りませんでした。Leanや Adaptiveなどの他のオプションも提案されましたが、Agileという名前が勝ちました。マニフェストの構造は相互に合意されました。私はWardが相対的価値のペアのアイデアをフレーミングする上で大きな役割を果たしたことを覚えていますが、そのアイデアを思いついたのはMartinとPragmatic Dave Thomasかもしれません。PragDaveの回想は次のとおりです：実際、それはMartinと私が昼食時にホワイトボードで考えを練っていた時のことです。最初の三つを思いついたと思います。その後、グループが五つに増やし、それが四つに絞られました。実際、Wardは現在彼のマニフェストサイトに飾られている、アイデアを議論している皆の写真を撮りました。（略）スノーバードでの二日間の終わりまでに、マニフェストは完成し、原則が概説され、Agile Allianceが誕生しました。 https://www.facebook.com/TotherAlistair/posts/10156214284634035 https://sites.google.com/site/unclebobconsultingllc/the-founding-of-the-agile-allianc

2009年：DevOpsのはじまり 42

Flickrの伝説的講演「10+ Deploys Per Day」 ⚫ 2009年のO'Reilly Velocity 09 Conferenceで行われた、Flickrのエンジニアによる伝説的な講演です。
⚫ 当時Flickrのエンジニアだったジョン・オールスパウ（John Allspaw）とポール・ハモンド（Paul Hammond）が「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」のタイトルで発表し、業界に衝撃を与えました。 ⚫ この講演で彼らは、当時としては驚異的な「1日に10 回以上のデプロイ」を実現している事実を明らかにしました。多くの企業が月に1回や四半期に1回のリリースサイクルに苦しんでいた時代に、これは革命的な実践だったのです。

Flickrの伝説的講演「10+ Deploys Per Day」 ⚫ 彼らが強調したのは次のポイントです。 1. 開発と運用の協力関係 - 両チームが共通の目標（ユーザー価値の提供）に向かって協力する
2. 小さな変更の頻繁なデプロイ - 大きな変更を一度にリリースするのではなく、小さな変更を頻繁にリリースする 3. 自動化の徹底 - テスト、デプロイ、モニタリングなど、あらゆる工程を自動化する 4. 「失敗は避けられない」前提 - 失敗を防ぐのではなく、素早く検知して回復する能力を高める ⚫ この講演により「高頻度デプロイは可能」との認識が広まり、多くの企業がFlickrの実践に触発されて自社のデプロイプロセスを見直すきっかけとなりました。この講演は、YouTubeで「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」として今でも視聴可能であり、DevOpsを学ぶ人々にとって必見の資料となっています。

パトリック・ドボアと「DevOps」という言葉の誕生 ⚫ 先述のFlickrの講演「10+ Deploys Per Day」に触発されたドボアは、エンジニアのナスラット・ナサー（Nasrat Nassar）からの「ベルギーで独自のVelocityイベントを開催してはどうか」というツイートをきっかけに行動を起こします。彼は「DevOpsDays」というイベントを開催することを決意しました。 ⚫
2009年10月30日に開催されたこのカンファレンスには、開発者、システム管理者、ツール開発者など多様な参加者が集まりました。カンファレンス終了後、議論はTwitterに移り、より覚えやすいハッシュタグとして、ドボアは名前を「#DevOps」に短縮しました。これが「DevOps（Development + Operations）」という言葉の誕生であり、それ以来、このムーブメントはDevOpsとして知られるようになりました。 Patrick Debois （パトリック・ドボア） 2009年、彼は最初のdevopsdaysイベントを主催することで「devops」という言葉を生み出しました。彼は世界各地で会議を開催し、新しいアイデアを収集・普及させました。パイオニアとして、彼は常に実装・探求すべき新しいアイデアを探し求めています。現在はメディア業界で活動しており、放送事業者が視聴者との閉じたフィードバックループによる対話に参入する移行を指導しています。（参照： https://itrevolution.com/author/patrick-debois/ ） 45

2010年代前半：継続的インテグレーション（CI）から継続的デリバリー（CD）への発展 46

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 ） 47 David(Dave) Farley（デイビッド（デイブ）・ファーリー） Dave FarleyはContinuous Delivery Ltdの創設者兼マネージングディレクター。30年以上にわたってコンピューターに関わる仕事をしており、ファームウェア、オペレーティングシステム、デバイスドライバー、ゲーム開発、商用アプリケーションなど、あらゆる種類のソフトウェア開発に携わってきました。約30年前から大規模分散システムの開発に取り組み始め、疎結合でメッセージベースのシステム開発の研究を行っていました。これは今日のマイクロサービスアーキテクチャの先駆けとなるものでした。（参照： https://www.amazon.com/stores/author/B003VSTZ72/about ）

2001/2/11：アジャイルソフトウェア開発宣言 2005/10 1991〜：バブル崩壊「失われた◦◦年」 1988〜：日本を含む諸外国へ「通商法スーパー301条」発動ソフトウェア開発現代史年表 Ver2.08 © 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〜） DynaBook （1994〜）家庭向け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

2010年代前半：ジェズ・ハンブルとCIから継続的デリバリー（CD）への発展 49 ⚫ CIが「コードの統合と検証の自動化」に焦点を当てているのに対し、継続的デリバリー（CD）はその先の「デプロイメントまでの自動化」にまで範囲を広げた概念です。この概念を体系化したのが、ジェズ・ハンブルとデビッド・ファーリー（David Farley）による「Continuous Delivery: Reliable Software
Releases through Build, Test, and Deployment Automation」（2010年、日本語訳は2012年）の書籍でした。 ⚫ ジェズ・ハンブルとデビッド・ファーリーは、この書籍で継続的デリバリーを実現するために次のような実践を提唱しています。 ✓ デプロイメントパイプライン - コードの変更が自動的にビルド、テスト、デプロイされる一連のプロセス ✓ 自動化されたテスト - 単体テスト、統合テスト、受け入れテストなど、あらゆるレベルのテストを自動化 ✓ 本番環境と一致したステージング環境 - 「開発環境では動くのに本番では動かない」問題を解消 ✓ ブルーグリーンデプロイメント - ダウンタイムなしでのデプロイを可能にする手法

2010年代中盤：ジーン・キムとDevOpsの理論体系化 50

2010年代中盤：ジーン・キムとDevOpsの理論体系化 ⚫ 2010年代中盤、DevOpsムーブメントの中心人物として台頭したのがジーン・キム（Gene Kim）です。彼は優れた技術者であると同時に、複雑な概念を分かりやすく伝える稀有な才能を持ち合わせていました。それまで現場レベルの実践知として広がっていたDevOpsの考え方を、組織全体で取り組むべき体系的な方法論として確立した功績は計り知れません。彼の著作は技術書の枠を超え、多くの組織でDevOps変革の指南書となっています。 Gene Kim（ジーン・キム）
ジーン・キムは、1999年からハイパフォーマンスなテクノロジー組織の研究を続けてきました。彼はエンタープライズ向けセキュリティソフトウェア企業である Tripwire, Inc. の創業者兼 CTO を務め、13年間にわたり在籍しました。著書の累計販売部数は100万部を超え、『Wiring the Winning Organization』や『The Unicorn Project』ではウォール・ストリート・ジャーナルのベストセラー作家に名を連ねています。また、『The Phoenix Project』『The DevOps Handbook』、そしてシンゴ賞を受賞した『Accelerate』の共著者でもあります。2014年以降は DevOps Enterprise Summit （現在の Enterprise Technology Leadership Summit）の主催者として、大規模かつ複雑な組織におけるテクノロジー変革を研究し続けています。（参照： https://itrevolution.com/author/gene-kim/ ） 51

2010年代中盤：ジーン・キムとDevOpsの理論体系化 53 ⚫ 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の本質的な考え方を分かりやすく伝え、多くの読者に影響を与えました。

2010年代中盤：ジーン・キムとDevOpsの理論体系化 54 ⚫ 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は単なる技術的プラクティスではなく、組織文化の変革として広く認識されるようになりました。

DORAと「State of DevOps Report」の概要 56

60 DORA Metrics ⚫ 原書は「Accelerate: The Science Behind Devops: Building
and Scaling High Performing Technology Organizations」 ⚫ 2018年3月出版、日本語版は2018年11月に出版。 ⚫ 迅速かつ高品質なデリバリを実施している組織とそうでない組織の違いに関する研究結果をDORAがまとめている。 https://book.impress.co.jp/books/1118101029 https://www.oreilly.com/library/view/accelerate/9781457191435/ この調査結果はチームや組織のサイズ、業種は無関係である

DORAの成果と影響 63

LeanとDevOpsの科学: テクノロジーの戦略的活用が組織変革を加速する ⚫ 原書タイトルは「Accelerate: The Science Behind Devops: Building and
Scaling High Performing Technology Organizations」 ⚫ 2018年3月出版、日本語版は2018年11月に出版。 ⚫ 迅速かつ高品質なデリバリを実施している組織とそうでない組織の違いに関する研究結果を DORAがまとめている。 64 ⚫ この書籍がきっかけで有名になったり、その重要性が広く認識されるようになったりした法則、概念 1. Four Keys（4つの主要指標） 2. 速度（スループット）と安定性はトレードオフではない 3. 継続的デリバリー (Continuous Delivery / CD) の効果の証明 4. 疎結合アーキテクチャの重要性 5. リーン（Lean）の原則の適用 6. Westrum（ウェストラム）の組織文化類型 7. ケイパビリティモデル (Capability Model) 8. バーンアウト（燃え尽き症候群）と組織文化・ツールの関係

65 1. Four Keys（4つの主要指標） ⚫ ソフトウェアデリバリーのパフォーマンスを客観的に測定するために定義された、以下の4つの指標群です。これらは DORA（DevOps Research and
Assessment）の研究の中核であり、「DORA メトリクス」とも呼ばれます。 ⚫ DevOps の成果や組織のソフトウェアデリバリー能力を測定・比較するためのデファクトスタンダードとなりました。指標内容 Deployment frequency (デプロイ頻度) 変更を本番環境に push する頻度。 Lead time for changes (変更のリードタイム) コードの変更を commit してからデプロイするまでの時間。 Change failure rate (変更失敗率) デプロイにより障害が発生し、すぐに対処する必要が生じる頻度。 Failed deployment recovery time (失敗デプロイの復旧時間) デプロイの失敗時に復旧にかかる時間。

2. 速度（スループット）と安定性はトレードオフではない 66 ⚫ Four Keys を用いた大規模な調査・分析から導き出された、本書の最も重要な発見の一つです。従来信じられていた「速度を上げると安定性が犠牲になる」という考えは誤りであり、高パフォーマンスな組織では、速度と安定性は両立し、むしろ互いに強化し合う関係にあることがデータで示されました。 ⚫
DevOps の価値を強力に裏付け、多くの組織が開発・運用プラクティスを見直す大きな動機となりました。スピードより品質を重視品質よりスピードを重視スピードと品質の両立壊れやすい厄介な状態高品質低品質遅い速い

(出典) Infrastructure as Code, 2nd Edition , Figure 1-2. Speed
and quality map to quadrants 67 2. 速度（スループット）と安定性はトレードオフではないスピードより品質を重視品質よりスピードを重視スピードと品質の両立壊れやすい厄介な状態高品質低品質遅い速い右下の象限: 品質よりスピードを重視 • いわゆる「早く作って壊す」という考え方です。スピードを重視して品質を犠牲にするチームは、乱雑で脆弱なシステムを構築します。その粗悪なシステムによって作業が遅くなり、左下の象限に滑り落ちていきます。このやり方を続けてきたスタートアップの多くが「勢い」を失ったと嘆きます。以前なら素早く対応できた簡単な変更が、システムが複雑に絡み合っているために、今では何日も何週間もかかるようになっています。左上の象限: スピードより品質を重視 • 「私たちは重要な仕事をしているのだから、きちんとやらなければならない」という考え方です。しかし、納期のプレッシャーにより「場当たり的な対応」を強いられます。重厚なプロセスが改善の障壁となり、技術的負債は「既知の問題」リストとともに増大します。これらのチームは左下の象限に落ち込みます。改善が困難なため、結果として低品質なシステムになってしまいます。失敗への対応として更にプロセスを追加します。このプロセスが改善をより困難にし、脆弱性とリスクを増大させます。これがさらなる失敗とプロセスの追加を招きます。特にリスクに敏感な業界では、このように働く組織の多くの人々が、これが普通だと思い込んでいます。

3. 継続的デリバリー (Continuous Delivery / CD) の効果の証明 68 ⚫ Four
Keys で測定されるパフォーマンス（速度と安定性の両方）を高める上で、バージョン管理、自動テスト、自動デプロイといった CD の具体的なプラクティスが直接的に貢献することを科学的に証明しました。 ⚫ CD が単なる理想論ではなく、ビジネス成果に繋がる実践であることの説得力を高め、その普及を後押ししました。 Grégoire Détrez, original by Jez Humble, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0>, via Wikimedia Commons

4. 疎結合アーキテクチャの重要性 69 ⚫ チームが独立してテストやデプロイを行える「疎結合アーキテクチャ」（例：マイクロサービス）が、CD を容易にし、デリバリーパフォーマンス向上に大きく寄与することを示しました。 ⚫ 技術的なアーキテクチャ選択が、組織の俊敏性や DevOps
実践の効果に直接的な影響を与えるという考え方をデータで補強しました。 https://cloud.google.com/architecture/microservices-architecture-introduction?hl=ja,CC BY 4.0 Google

5. リーン（Lean）の原則の適用 70 ⚫ WIP 制限、小さなバッチでの作業、フィードバックループの短縮といったリーン原則が、ソフトウェアデリバリーのフローを改善し、リードタイム短縮や品質向上に有効であることを示しました。 ⚫ DevOps とリーンの考え方の親和性を裏付け、プロセス改善の具体的な指針を提供しました。

6. Westrum（ウェストラム）の組織文化類型 71 ⚫ 組織文化を情報の流れ方で分類し（病的、官僚的、生成的）、情報共有、協力、学習を促す「生成的 (Generative) 文化」が、Four Keys で測られるような高いパフォーマンスと強く関連していることを示しました。
⚫ DevOps 成功における健全な組織文化の構築が不可欠であることをデータで示し、その重要性を広く認識させました。特性病理的（権力重視）官僚的（ルール重視）生成的（成果重視）組織の価値観・指向性権力と統制が重視される規則と手続きが重視されるミッションや成果が重視される協力の姿勢協力はほとんど見られない必要最低限の協力が行われる積極的に協力し合う文化がある問題を報告した人への対応報告した人が責められる（処罰される）報告しても関心を持たれず無視される報告が歓迎され、問題対応力が育てられる責任の取り方責任を押しつけあう（逃げる）形式上の責任だけを取るチームで責任を共有し、積極的に対応する部門間の連携（橋渡し）他部署との連携は妨げられる最低限は許容される積極的に部門を越えて連携する失敗への対応スケープゴートを探して責任追及する誰が悪かったかを調査する失敗から学び、次に活かす姿勢がある新しいアイデアへの対応新しいことは否定され、抑え込まれる新しいことは規則に反するとして懸念される新しいことに挑戦し、積極的に取り入れる

7. ケイパビリティモデル (Capability Model) 72 ⚫ CDプラクティス、アーキテクチャ、リーン原則、組織文化などを含むパフォーマンス向上に統計的に有意な影響を与えることが特定された具体的な技術的・プロセス的・文化的な「能力（Capability）」の集合体です。 ⚫
Four Keys で現状を測定した後、具体的にどの能力を開発・強化すればパフォーマンスが向上するのかを示す実践的なガイドを提供し、組織が改善活動を進める上でのロードマップとなりました。 LeanとDevOpsの科学[Accelerate] 図A.1 本研究の全体の構成を元に筆者が作成

7. ケイパビリティモデル (Capability Model) 73

7. ケイパビリティモデル (Capability Model) 74

8. バーンアウト（燃え尽き症候群）と組織文化・ツールの関係 75 ⚫ デプロイの苦痛、責任の押し付け合いといったネガティブな文化や、不十分なツールがバーンアウトのリスクを高める一方、生成的文化や適切なツールはそれを低減しうることを示唆しました。 ⚫ 従業員のウェルビーイング（幸福感）が、組織の持続的なパフォーマンスにとっても重要であるという視点を提供しました。

LeanとDevOpsの科学: テクノロジーの戦略的活用が組織変革を加速する ⚫ この書籍がきっかけで有名になったり、その重要性が広く認識されるようになったりした法則、概念 1. Four Keys（4つの主要指標） 2. 速度（スループット）と安定性はトレードオフではな
い 3. 継続的デリバリー (Continuous Delivery / CD) の効果の証明 4. 疎結合アーキテクチャの重要性 5. リーン（Lean）の原則の適用 6. Westrum（ウェストラム）の組織文化類型 7. ケイパビリティモデル (Capability Model) 8. バーンアウト（燃え尽き症候群）と組織文化・ツールの関係 ⚫ 原書タイトルは「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」 ⚫ 2018年3月出版、日本語版は2018年11月に出版。 ⚫ 迅速かつ高品質なデリバリを実施している組織とそうでない組織の違いに関する研究結果を DORAがまとめている。 76

「科学」とは何か？ 77

昔ばなし ⚫ 私の35年のエンジニア人生を振り返ると、かなりの時間「意味のない計測データ」の収集と加工に時間を費やしたと思います。なぜなら、（その時の）品質保証部門がプロダクトの「出荷」をなかなか認めてくれないからです。 ⚫ いま思い出すと、私は被告側の弁護士のようであり、品質保証部門はまるで検察側のようでした。
⚫ 裁判長は、事業部のトップです。 ⚫ 私はプロジェクトを終わらせるために、ありとあらゆるデータを集めて「そのプロダクトは動く。（きっと）問題ないはずだ！」を弁護する必要がありました。 78

バグ曲線 79 ⚫ QA部門がプロダクト出荷可否を判断する際に使っていた「バグ曲線」 ⚫ 横軸：テスト経過時間（時間、日数、またはテストケースの進捗） ⚫ 縦軸：発見された累計バグ数（累計または日別） ⚫ 大抵、左記のような「発見バグ数」の累計グラフを描き、
⚫ 最初は急増 ⚫ 中盤で減速 ⚫ 最終的には「バグ収束傾向」が見られるかという減衰カーブをもって「品質は安定した」と判断する手法です。 ⚫ 「信頼度成長曲線」「PB曲線」などとも呼びます。

バグ曲線 80 ⚫ QA部門がプロダクト出荷可否を判断する際に使っていた「バグ曲線」 ⚫ 横軸：テスト経過時間（時間、日数、またはテストケースの進捗） ⚫ 縦軸：発見された累計バグ数（累計または日別） ⚫ 大抵、左記のような「発見バグ数」の累計グラフを描き、
⚫ 最初は急増 ⚫ 中盤で減速 ⚫ 最終的には「バグ収束傾向」が見られるかという減衰カーブをもって「品質は安定した」と判断する手法です。 ⚫ 「信頼度成長曲線」「PB曲線」などとも呼びます。

バグ曲線 81 「まだ発見数が減少トレンドに入っていませんね。このままでは出荷は難しいです。」「検出率が横ばいです。テスト範囲に漏れがないか、もう一度洗い出してください。」「ピークアウトしていない以上、潜在バグがまだ相当数あると見ています。」

バグ曲線 82 「まだ発見数が減少トレンドに入っていませんね。このままでは出荷は難しいです。」「検出率が横ばいです。テスト範囲に漏れがないか、もう一度洗い出してください。」「ピークアウトしていない以上、潜在バグがまだ相当数あると見ています。」これは科学的と言えるでしょうか？

バグ曲線 83 1. 発見バグ数≠品質の保証 ⚫ バグが出なくなったのは「テスト網羅率が低いから」「疲弊したから」「検証が表面的だったから」かもしれません。 ⚫ 見つかっていないだけで、潜在的なバグは依然として残っている可能性が高い。 2.
観測バイアス（Observer bias） ⚫ 観察者が期待した結果を得たいときに、その結果だけを意識しすぎてしまう心理効果 ⚫ 観測されたバグ数は「テスト範囲」「テストの質」「発見力」に強く依存します。 ⚫ 広く深いテストを行わなければ「収束したように見える偽陽性」になるリスク。 3. 反復型開発や継続的デリバリーには不向き ⚫ 品質は工程で作り込むものであり、出口で測る時代ではありません。（アジャイルやCI/CDに限らず、品質管理とはそうであったはずなのですが…） ⚫ 「最後の検問」としてのバグ曲線は現代のスピードが求められる開発の流れには合いません。「まだ発見数が減少トレンドに入っていませんね。このままでは出荷は難しいです。」「検出率が横ばいです。テスト範囲に漏れがないか、もう一度洗い出してください。」「ピークアウトしていない以上、潜在バグがまだ相当数あると見ています。」

Tom DeMarco (1940 - ) 84 ⚫ ソフトウェア・エンジニア ⚫ コンサルタント
⚫ DFD（data flow diagram）の生みの親 Photo of Tom DeMarco by Hans-Rudolf Schulz (*1) *1: https://www.oreilly.com/library/view/peopleware-productive-projects/9780133440706/pref02.xhtml

Tom DeMarco (1940 - ) 85 ⚫ ソフトウェア・エンジニア ⚫ コンサルタント
⚫ DFD（data flow diagram）の生みの親 ⚫ 彼は、1982年の論文(*2)で次のような言葉を発しました。 ⚫ これは、当時のエンジニアにとって、しばらくのあいだ呪言となりました。 Photo of Tom DeMarco by Hans-Rudolf Schulz (*1) *1: https://www.oreilly.com/library/view/peopleware-productive-projects/9780133440706/pref02.xhtml *2: ”Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982) 「計測できないものは制御できない」 “You can’t control what you can’t measure.”

「測定できないものは制御できない｣は誤りだった？ 86 ⚫ 2009年7月、Tom DeMarco がIEEE Software誌7月8 月合併号に、衝撃的な記事を寄稿しました。タイトルは ”Software
Engineering: An Idea Whose Time Has Come and Gone?（ソフトウェアエンジニアリング：その考えは、もう終わったことなのか？）” https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf 「計測できないものは制御できない」 “You can’t control what you can’t measure.” このセリフには本当の真実が含まれているのですが、私はこのセリフを使うことに違和感を覚えるようになりました。 (中略)例えば、過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算通りに終わらせることができないことで自らを苦しめてきました。 (Tom DeMarco, 2009)

「測定できないものは制御できない｣は誤りだった？ 87 https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf 「計測できないものは制御できない」 “You can’t control what you can’t
measure.” このセリフには本当の真実が含まれているのですが、私はこのセリフを使うことに違和感を覚えるようになりました。 (中略)例えば、過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算通りに終わらせることができないことで自らを苦しめてきました。 (Tom DeMarco, 2009) ⚫ この論文は当時、Tom DeMarco 自身が「測定できないものは制御できない」は誤りだった、と認めた！ということで業界に衝撃が走りました。 ⚫ しかし、Tom DeMarco が本当に言いたかったことは、次の文章に含まれていると私は思います。

「測定できないものは制御できない｣は誤りだった？ 88 https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf ⚫ この論文は当時、Tom DeMarco 自身が「測定できないものは制御できない」は誤りだった、と認めた！ということで業界に衝撃が走りました。 ⚫
しかし、Tom DeMarco が本当に言いたかったことは、次の文章に含まれていると私は思います。しかし、先ほども申し上げたように、これは決して至上命題ではありませんでした。もっと重要なのは、世界を変えるような、あるいは企業やビジネスのあり方を変えるようなソフトウェアを作るという「変革」です。 (Tom DeMarco, 2009)

「測定できないものは制御できない｣は誤りだった？ 89 https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf ⚫ これはTom DeMarco本人のパラダイムシフトだったのではないでしょうか？ ⚫ DeMarcoが指摘したように、時代は「裁判ごっこ」よりも、もっとエンドユーザーとの関係性を重視す
る方向に確実に変化してきました。 ⚫ それが、リーンであり、アジャイルでありDevOpsなのだと思います。しかし、先ほども申し上げたように、これは決して至上命題ではありませんでした。もっと重要なのは、世界を変えるような、あるいは企業やビジネスのあり方を変えるようなソフトウェアを作るという「変革」です。 (Tom DeMarco, 2009)

科学とは何か？ 90 ⚫ 天文学者であり小説家でもあった、20世紀屈指の科学者カール・セーガンは科学について次のような表現をしていました。 Sagan in 1980 「科学は、思考の方法であり、
知識の集積ではない」 “Science is a way of thinking much more than it is a body of knowledge.”

科学とは何か？ 91 科学とは「なぜだろう？」という疑問に対して、実験と観察を重ねながら、誰でも同じ結果を得られる答えを見つけ出す取り組み、と言えます。

あるカレー店の人気の秘密 92 ⚫ あるカレー店の人気の秘密を科学的に考えてみましょう。 ⚫ 「このカレーが美味しいのはなぜか？」という問いに対して― ⚫ 「シェフの腕が良いから」：個人的な感想
⚫ 「創業100年の伝統の味だから」：言い伝えこれらは、科学的な説明とはいえません。

あるカレー店の人気の秘密 93 ⚫ あるカレー店の人気の秘密を科学的に考えてみましょう。 ⚫ 「このカレーが美味しいのはなぜか？」という問いに対して― ⚫ 「シェフの腕が良いから」：個人的な感想
⚫ 「創業100年の伝統の味だから」：言い伝えこれらは、科学的な説明とはいえません。 ⚫ 科学的なアプローチでは、次のような調査と実験を行います。 ⚫ このような過程を経て、「このスパイスの配合で、この温度で30分煮込むと、8割以上のお客さんが美味しいと感じるカレーができる」と言った、誰でも確認できる答えにたどり着けるのです。 ✓ 100人のお客さんに同じ条件で食べてもらい、評価を集める ✓ スパイスの配合を少しずつ変えて、味の変化を測定する ✓ 調理時間や火加減を細かく記録し、最適な条件を探る ✓ 異なる調理人が同じレシピで作っても、同じ味になるか確認する

「科学的リサーチ」方法とは 94 ⚫ 科学的リサーチとは、現象を体系的に調査し、新しい発見や理論を導き出す手法です。観察から始まり、概念化、測定可能な変数への置き換え、モデル化という段階を経て、客観的なデータに基づいた結論を導きます。向後, 千春. (2016). 18歳からの「大人の学び」基礎講座: 学ぶ,
書く, リサーチする, 生きる. 北大路書房. 図3-3に筆者が加筆

科学的リサーチプロセスは次の4段階で進みます 95 向後, 千春. (2016). 18歳からの「大人の学び」基礎講座: 学ぶ, 書く, リサーチする, 生きる.
北大路書房. 図3-3に筆者が加筆 Step 説明 1 現象の観察「DevOpsの実践は本当にビジネスの成果に繋がるのか？」といった問いからDORAの研究が始まりました。 2 概念の特定 DORAは、継続的デリバリー、継続的インテグレーション、自動化テストの実施などを概念として特定しました。 3 変数への変換概念を測定可能な形に変換します。例えば、デプロイ頻度、変更リードタイム、障害復旧時間、変更失敗率などの具体的指標として定義します。 4 モデルの構築収集したデータを統計的に分析し、相関または因果関係を明らかにします。DORAの研究では、自動化テストの実施が変更リードタイムを短縮することや、チームの独立性がサービスの信頼性向上につながることを実証しました。

科学的リサーチプロセスは次の4段階で進みます 96 Step 説明 1 現象の観察「DevOpsの実践は本当にビジネスの成果に繋がるのか？」といった問いからDORAの研究が始まりました。 2
概念の特定 DORAは、継続的デリバリー、継続的インテグレーション、自動化テストの実施などを概念として特定しました。 3 変数への変換概念を測定可能な形に変換します。例えば、デプロイ頻度、変更リードタイム、障害復旧時間、変更失敗率などの具体的指標として定義します。 4 モデルの構築収集したデータを統計的に分析し、相関または因果関係を明らかにします。DORAの研究では、自動化テストの実施が変更リードタイムを短縮することや、チームの独立性がサービスの信頼性向上につながることを実証しました。バグ曲線は科学的と言えるでしょうか？

科学的リサーチプロセスは次の4段階で進みます 97 Step 説明バグ曲線で品質を見る場合 1 現象の観察「DevOpsの実践は本当にビジネスの成果に繋がるのか？」といった問いからDORAの研究が始まりました。
「バグが時間経過とともに減るかを観察」 → 観察はしている。ただし問いが「観察止まり」で深掘りしない。 2 概念の特定 DORAは、継続的デリバリー、継続的インテグレーション、自動化テストの実施などを概念として特定しました。 △ 「バグ数減少＝品質改善」という単一概念に依存してはだめ → 他の成功要因（テスト網羅率、カバレッジ、リスク分析など）を概念として捉えていない。 3 変数への変換概念を測定可能な形に変換します。例えば、デプロイ頻度、変更リードタイム、障害復旧時間、変更失敗率などの具体的指標として定義します。 △ 「累積バグ数」や「検出ペース」だけで判断してはだめ → 指標はあるが、非常に限定的で不十分。リスクの分布やバグの深刻度など多変数で見る必要がある。 4 モデルの構築収集したデータを統計的に分析し、相関または因果関係を明らかにします。DORAの研究では、自動化テストの実施が変更リードタイムを短縮することや、チームの独立性がサービスの信頼性向上につながることを実証しました。？データの観察はするが、相関または因果関係まで解明できない。 → なぜバグが減ったのか、他の変数がどう影響したのか検証しない（できない）まま「減ったから OK」としがち。

科学的リサーチプロセスは次の4段階で進みます 98 Step 説明バグ曲線で品質を見る場合 1 現象の観察「DevOpsの実践は本当にビジネスの成果に繋がるのか？」といった問いからDORAの研究が始まりました。
「バグが時間経過とともに減るかを観察」 → 観察はしている。ただし問いが「観察止まり」で深掘りしない。 2 概念の特定 DORAは、継続的デリバリー、継続的インテグレーション、自動化テストの実施などを概念として特定しました。 △ 「バグ数減少＝品質改善」という単一概念に依存してはだめ → 他の成功要因（テスト網羅率、カバレッジ、リスク分析など）を概念として捉えていない。 3 変数への変換概念を測定可能な形に変換します。例えば、デプロイ頻度、変更リードタイム、障害復旧時間、変更失敗率などの具体的指標として定義します。 △ 「累積バグ数」や「検出ペース」だけで判断してはだめ → 指標はあるが、非常に限定的で不十分。リスクの分布やバグの深刻度など多変数で見る必要がある。 4 モデルの構築収集したデータを統計的に分析し、相関または因果関係を明らかにします。DORAの研究では、自動化テストの実施が変更リードタイムを短縮することや、チームの独立性がサービスの信頼性向上につながることを実証しました。？データの観察はするが、相関または因果関係まで解明できない。 → なぜバグが減ったのか、他の変数がどう影響したのか検証しない（できない）まま「減ったから OK」としがち。バグ曲線は観察の域を出ず、「科学的リサーチプロセスとしては不十分」（モデル化が不十分）複数の指標を組み合わせた多角的な分析が不可欠

科学的リサーチプロセスは次の4段階で進みます 99 向後, 千春. (2016). 18歳からの「大人の学び」基礎講座: 学ぶ, 書く, リサーチする, 生きる.
北大路書房. 図3-3に筆者が加筆 Step 説明 1 現象の観察「DevOpsの実践は本当にビジネスの成果に繋がるのか？」といった問いからDORAの研究が始まりました。 2 概念の特定 DORAは、継続的デリバリー、継続的インテグレーション、自動化テストの実施などを概念として特定しました。 3 変数への変換概念を測定可能な形に変換します。例えば、デプロイ頻度、変更リードタイム、障害復旧時間、変更失敗率などの具体的指標として定義します。 4 モデルの構築収集したデータを統計的に分析し、相関または因果関係を明らかにします。DORAの研究では、自動化テストの実施が変更リードタイムを短縮することや、チームの独立性がサービスの信頼性向上につながることを実証しました。

100 DORAの研究では、科学的アプローチによってDevOpsの成功要因を明らかにしました。個人の経験や直感を超えて、数多くの組織のデータを分析し、客観的な証拠に基づいて「何が効果的なのか」を示したのです。これは単なる成功事例の集積ではなく、科学的リサーチによって検証された信頼性の高い知見です。

定量的データと統計分析がもたらす信頼性 101 ⚫ DORA Reportで用いられる科学的アプローチに対して、「都合の良いデータ解釈をしているのではないか」という批判を目にすることがあります。 ⚫ しかし、この批判は科学的リサーチの本質を十分に理解していないことから生じている可能性がありま
す。科学的リサーチとは、単にデータを収集し結果を得ることではなく、現象を客観的に理解し、実証可能な方法で結果を導き出す「方法論」そのものです。 ⚫ この考え方は、DORAの研究において左記のように具体化されています。 ◼ 思考の方法の適用 ⚫ DORAの研究では、特定の仮説（例えば「継続的デリバリーはパフォーマンス向上に寄与する」）を立て、それを証明または反証するために厳密な手法でデータを収集・分析しています。これは、科学的な「疑う」姿勢と「検証する」姿勢の両立です。 ◼ 透明性と再現性 ⚫ 測定方法や分析手順を厳密に文書化し、他の研究者が追試可能な形で公開しています。これは、科学が単なる知識の蓄積ではなく、「共有されるべきプロセス」であることを象徴しています。 ◼ 実践への応用 ⚫ 科学の思考方法をもとに導き出された成果が、現場での実践を通じて再び検証されています。たとえば、継続的デリバリーやテストの自動化が現実の組織で具体的な効果をもたらすことが示されています。

定量的データと統計分析がもたらす信頼性 102 ⚫ DORAの研究は10年にわたり、理論と実践の両面で成果を示してきました。カール・セーガンが述べたように、科学とは「知識の集積」ではなく「より良い問いを立て、より深く理解するための思考の道具」です。 ⚫ DORAはこの科学的アプローチを用いて、LeanやDevOpsの成功要因を信頼性の高い方法論として確立し、現場の改善や組織変革に直接応用できる形で提供しています。毎年のクラスター分析結果の微細な変化も、このような継続的なデータ分析の重要性を示しているのです。とはいえ、最初から科学的なデータ分析が出来ていたわけではありません……
DORAの10年を、順を追って振り返ってみましょう

DORAレポートの10年の変遷 103

DORA Report 10年の変遷 ⚫ 2024 DORA Reportでは、 "A decade with
DORA"（DORAと共に過ごした10年）という章があります。 DevOpsの起源から、State of DevOps Report誕生の背景、今日に至るまでの歴史が書かれています。 ⚫ 私は、その説明内容と書籍「LeanとDevOpsの科学[Accelerate]」に書かれている内容から、これまでの変遷を1枚の画にまとめてみました。 104

State of DevOps Report のはじまり ⚫ 2011年、Puppet Labsで働いていたAlanna BrownはDevOpsについてより深く理解するための調査を開始しました。この調査は、「'DevOps'的な働き方がITにおける新しいビジネスの方法として台頭している」というこ
とを裏付ける助けとなりました。 ⚫ この調査の成功をベースに、2012年に新たな調査を開始、2013年 Puppet LabsとGene Kim氏が率いるIT Revolution Pressが共同で、最初のState of DevOps Reportを発行しました。 Alanna Brown（アラナ・ブラウン）ハイパーグロース（急成長）スタートアップのスケールアップを手がけたプロダクトマーケティングのリーダー。受賞歴のある「State of DevOps Report」（DevOpsとハイパフォーマンスなIT組織に関する10年にわたる研究）の創設者兼著者。（参照： https://itrevolution.com/author/alanna-brown/ ） 106

State of DevOps Report のはじまり ⚫ Gene KimはTripwire, Inc.の創業者兼CTOとして13年間務めたあと、IT Revolutionを創業し出版活動、
DevOpsコミュニティへの貢献に尽力する人物でした。 ⚫ DevOpsDays Tokyo 2019 開催時には、キーノートセッション講演者として来日 Gene Kim（ジーン・キム）ジーン・キムは、1999年からハイパフォーマンスなテクノロジー組織の研究を続けてきました。彼はエンタープライズ向けセキュリティソフトウェア企業である Tripwire, Inc. の創業者兼 CTO を務め、13年間にわたり在籍しました。著書の累計販売部数は100万部を超え、『Wiring the Winning Organization』や『The Unicorn Project』ではウォール・ストリート・ジャーナルのベストセラー作家に名を連ねています。また、『The Phoenix Project』『The DevOps Handbook』、そしてシンゴ賞を受賞した『Accelerate』の共著者でもあります。2014年以降は DevOps Enterprise Summit （現在の Enterprise Technology Leadership Summit）の主催者として、大規模かつ複雑な組織におけるテクノロジー変革を研究し続けています。（参照： https://itrevolution.com/author/gene-kim/ ） 107

⚫ Gene Kimから応援を頼まれる形でJez Humbleも参画 ⚫ Jez Humble は、カルフォルニア大学バークレー校で教鞭も執っているDevOpsの研究者でした。現在は Google でサイトリライアビリティエンジニア（SRE）として勤務しながら、教鞭を執っています。
State of DevOps Report のはじまり 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 ） 108

State of DevOps Report のはじまり 109 ⚫ Alanna Brown、Gene Kim、Jez
Humbleらは、世界の組織から4,000件の回答を集め、分析を行った。この種の調査では当時最大規模でした。 ⚫ 2013年 Puppet LabsとGene Kim氏が率いるIT Revolution Pressが共同で、最初のState of DevOps Reportを発行しました。

なぜ2013年版はカウントされないのか？ 110 ⚫ しかし、ご覧の通り「この10年」の中に2013年版は含まれません。それはなぜか？ ⚫ 一言で言えば「調査方法が違う」からです。現在の統計的アプローチが取られたのは2014年以降となります。

2013 State of DevOps Report 111 ⚫ 2013年当時のPuppet社は、ITインフラストラクチャの自動化を支援するソフトウェアを開発・提供している会社でした。
⚫ その中心的なプロダクトは Puppet Enterpriseであり、これはサーバーやクラウド環境、ネットワークデバイスなどの管理を効率化し、DevOpsやインフラ管理の自動化を推進するツールでした。 ⚫ 2013 State of Devops Report は、当時あまり知られていなかったDevOpsという概念を広め、Puppet Enterpriseの市場を開拓することが主な目的だったと思われます。 ⚫ 実際、2013年版の調査による【主要な発見】は、やや意図的な印象を受けます。 ◼ 主要な発見 ⚫ DevOps導入状況 • 回答者の63%がDevOpsを導入（2011年から26%増加） • 導入期間が長いほど、高パフォーマンス達成の可能性が5倍に上昇 ⚫ 高パフォーマンスを実現する共通実践 • バージョン管理システムの使用（89%） • コードデプロイの自動化（82%） ⚫ DevOpsスキルの需要 • コーディング/スクリプティング（84%） • コミュニケーションスキル（60%） • プロセス再構築スキル（56%）

2013 State of DevOps Report 112 ⚫ また、このレポートでは、後のDORAメトリクスの基礎となる4つの主要指標、デプロイ頻度・変更のリードタイム・変更の失敗率・復旧までの平均時間、
いわゆるFour Keysが登場します。 ⚫ しかし、現在の観点とは異なる分析結果でした。下記に、2013 State of DevOps Reportのパフォーマンス指標の解説と、左記にグラフを転載します。 ◼ ご覧の通り、4つの指標はそれぞれ、「DevOpsを導入しているか否か」で期間分類されているのです。 ◼ このレポートは回答者の多くがDevOpsに関心の高い層に偏っている可能性を検証しておらず、バイアスの制御が十分でないという問題も抱えていました。 DevOpsの成熟度（未導入から12ヶ月以上前に導入）に基づいて、デプロイ頻度、変更のリードタイム、変更の失敗率、復旧までの平均時間という4つの主要なDevOpsパフォーマンス指標を分析しました。DevOpsの導入が成熟している組織は、まだDevOpsを導入していない組織と比較して、すべての指標において著しく高いパフォーマンスを示しました。 2013 State of DevOps Report, p5 1. Not Implemented（未導入） 2. Currently Implementing（導入中） 3. Implemented <12 Months（導入後12ヶ月未満） 4. Implemented >12 Months（導入後12ヶ月以上）

⚫ 2014年、State of Devops Report に大きな転機が訪れます。 ⚫ 当時ユタ州立大学ハンツマンビジネススクールの教授であったDr. Nicole Forsgren（ニコール・フォースグレ
ン博士）の参画です。 ⚫ 彼女は、ITインパクト、ナレッジマネジメント、ユーザー体験の専門家でした。 2014 State of DevOps Report Nicole Forsgren, PhD（ニコール・フォースグレン博士）ニコール・フォースグレン博士は、Microsoft Research のパートナーです。シンゴ賞を受賞した著書『Accelerate』の著者であり、これまでで最大規模の DevOps 調査の主任研究者として広く知られています。これまでに、起業家（Google への売却を経験）、大学教授、パフォーマンスエンジニア、システム管理者としての経歴を持ちます。彼女の研究は複数の査読付き学術誌にも掲載されています。（参照： https://itrevolution.com/author/nicole-forsgren/ ） 115

2014 State of DevOps Report ⚫ 「LeanとDevOpsの科学[Accelerate] 」の「謝辞」には、Nicole Forsgrenの次のようなコメントがあり
ます。 ⚫ この謝辞から読み取れるように、Dr. Nicole Forsgren は2014年以降のState of Devops Reportに科学的厳密性をもたらした重要な人物です。それまでの調査手法に対して建設的なフィードバックをし、その結果、2014年のレポートから、より体系的で科学的なリサーチがもたらされます。 ⚫ そして、2014年から2017年までの間、State of Devops Report は次のメンバーによって調査・研究がなされました。私が初めて皆さんのところへお邪魔して、「ここは違っています」などと指摘させていただいたとき（そのときの私の口調、失礼じゃなかったですよね、ハンブルさん？）、皆さんは私を部屋から蹴り出したりしなかった。おかげで私はその後、忍耐力と共感力を養い、冷めかけていたテクノロジーへの愛を再燃させることができた。また、「あともう1回だけ、分析やってみて！」が口癖であるキム氏の無尽蔵の熱意と気合いは、我々の仕事を堅牢で大変興味深いものにしてくれている。 1. Nicole Forsgren Velasquez（ニコール・フォースグレン・ベラスケス） 2. Gene Kim（ジーン・キム） 3. Jez Humble（ジェズ・ハンブル） 4. Nigel Kersten（ナイジェル・カーステン）：Puppet LabsのCIO 5. Alanna Brown（アラナ・ブラウン） 116

2014 State of DevOps Report 117 ⚫ Dr. Nicole Forsgrenの参加は、リサーチプログラム
に科学的な厳密さをもたらしました。 ⚫ このことで、最初のFour Keysは統計学的有意（＝確率的に偶然とは考えにくく、意味があると考えられる）が検証されるようになります。 ⚫ このことで、Change Failure Rate（変更失敗率）は、他の3つの指標とは有意な相関が見られなかったため、ITパフォーマンスの定義から除外されています。 ⚫ つまり、最初はFour Keysじゃなかったし、Eliteも居なかったのです。 ⚫ 一方で「発見」もありました。 ◼ 2014 パフォーマンス指標 ◼ 発見指標 High Medium Low Deployment Frequency 1日に複数回週1回〜月1回月1回〜6ヶ月に1回 Lead Time for Changes 数分単位 1日〜1週間 1週間〜6ヶ月 MTTR 分単位時間単位日単位「高パフォーマンスのITチームを持つ上場企業は、低パフォーマンスのIT組織を持つ企業と比較して、 3年間で市場価値の成長率が50%高かった」 (2014 State of Devops Report）

2014 State of DevOps Report 118 ⚫ 2014 State of
Devops Reportは、Nicole Forsgrenの「科学的リサーチ」によって次第にデータは説得力のあるものに変わっていきました。ところが、ここにきて大きな壁が立ちふさがります。 ⚫ それが、ソフトウェア界の巨匠Martin Fowler（マーティン・ファウラー）でした。

⚫ ソフトウェア設計やアジャイル開発の分野で世界的に影響力を持つスーパーエンジニアです。 ⚫ 「マイクロサービス」の提唱者であり、彼の著書『リファクタリング』は、コードの品質を向上させる方法論としてエンジニアのバイブルとなりました。巨匠の不満 Martin Fowler（マーティン・ファウラー）マーティン・ファウラーは、著者であり講演者であり、ソフトウェアに長年にわたって有用な機能を柔軟に追加できるよう、どのように設計すべきかに強い関心を持っています。
これまでに『リファクタリング』や『エンタープライズアプリケーションアーキテクチャパターン』など、ソフトウェア開発に関する多くの書籍を執筆してきました。2001年には「アジャイルソフトウェア開発宣言」の策定に参加し、アジャイルソフトウェア開発の先駆者のひとりとしても知られています。世界中のソフトウェアカンファレンスで講演を行う一方で、マサチューセッツの自宅で記事の執筆に取り組む時間がもっとも幸せです。自身のウェブサイト「martinfowler.com」では、実践者向けの詳しい技術記事を発信しています。（参照： https://www.thoughtworks.com/profiles/leaders/martin-fowler ） 119

巨匠の不満 Alistair CockburnのFacebookより(https://www.facebook.com/TotherAlistair/posts/10156214284634035) 120

巨匠の不満 121 ⚫ Martin Fowler 本人によって、書籍「Leanと DevOpsの科学[Accelerate] 」*1の冒頭では、次のようなエピソードが寄稿されています。 ⚫
なかなか苛烈な文章です。本書に寄せて 2、3年前、あるレポートを読んでいたら、こんな文に出くわしたーー「今や我々は自信をもって断言できる。IT部門のパフォーマンスの高さには、生産性、収益性、そして市場占有率を高める効果があり、組織全体の業績と高い相関をもつ」。この手のレポートは即、ゴミ箱に投げ捨てるのが私の通常の反応である。大抵は「科学」を装ったたわごとにすぎないからだ。しかしそのとき読んでいたのは『2014 State of DevOps Report （DevOpsの現況に関するレポート2014年版）』であったため、私はためらった。著者の1人が私の同僚であり友人でもあるJez Humble氏で、私に負けず劣らずこの種のたわごとを嫌う人物であることを知っていたからだ（もっとも、正直言ってゴミ箱に投げ捨てなかった理由はもう1つある。あのレポートはiPadで読んでいたのだった）。

巨匠の不満 122 ⚫ Martinは、さっそくNicole ForsgrenとJez Humble と3人で話す機会（電話会議）を作ります。 Forsgren氏は根気強く丁寧に研究の論拠を説明してくれた。その説明は、そういった調査・分析方法には詳しくない私にとっても十分な説得力があり、通常をはるかに上回るレベル
の（学術論文で発表される研究さえ凌ぐ）厳密な分析が行われている、ということが理解できた。そのため、私はその後もState of DevOpsレポートを興味深く読み続けていたが、その一方で不満も募ってきた。どの年度のレポートも研究の成果を公表するばかりで、Forsgren氏が電話で私にしてくれたような説明が一切ないのである。おかげでレポートの信頼性が大きく損なわれていた。推測だけに基づいた研究ではないことを示す根拠がほぼ皆無なのだ。そこで私も含めて内情を知る者が3人を説得し、研究の調査・分析手法を紹介・解説する本を執筆してもらった。

巨匠の不満から誕生した"LeanとDevOpsの科学" 123 ⚫ このように、Martin Fowlerの不満があったからこそ「LeanとDevOpsの科学[Accelerate] 」が存在すると言っても過言ではありません。 ⚫ 「LeanとDevOpsの科学[Accelerate] 」が技術者からすると慣れない文体で書かれているのは、あれが技術書
ではなく「研究の調査・分析手法を紹介・解説する本」だからだと思われます。統計手法の解説本なのです。 ⚫ 実際に書籍が出版されるのは、あの電話会議から4年後（2018年）になります…

2015 State of Devops Report ⚫ 前年と比べ分析に苦慮していた様子が伺えます。 ⚫ まず、Change Failure
Rate（変更失敗率）は、あいかわらずITパフォーマンスの主要な構成要素（construct）からは除外されています。のちの「LeanとDevOpsの科学[Accelerate] 」には次のような記述がありました。 ⚫ ちょっと分かりにくい文章なので整理すると、ソフトウェアデリバリーのパフォーマンスを正確に測定するには、 ⚫ 「リードタイム」「リリース頻度」「サービス復旧までの所要時間」の3つの尺度だけなら信頼性高く妥当な評価ができる。 ⚫ 変更失敗率も重要な指標であり、これら3つの尺度と強い相関はある。が、独立した構成概念として扱うには適していない。 ⚫ 「変更失敗率」は予測しずらい異質な指標であり、分析や予測の際には補足的な要素として考慮する必要がありそうです。昨年の2024 DORA Reportでも「変更失敗率」はイレギュラーな結果を残しています（後ほど触れます）。クラスター分析では「ハイパフォーマー」「ローパフォーマー」「ミディアムパフォーマー」のいずれの集団についても、この4つの尺度で有意な分類と差別化（チームのカテゴリー化）が行えた。ところが、この4つの尺度で1つの構成概念を得ようとすると問題が生じた。妥当性と信頼性を検証するための統計的仮説検定にパスしないのである。分析の結果、リードタイム、リリース頻度、サービス復旧までの所要時間の3つの尺度だけを使えば、妥当で信頼性のある構成概念が得られることが判明した。 126

2015 State of Devops Report 127 ⚫ 2015年のパフォーマンス・クラスターはSuper High、High、Medium、Lowに分けられ、それぞれ「4段階のスピード」で集計されました。しかし、パフォーマンスの傾向を特定するまでには至っていません。

DORAの設立へ 128

DORAの設立へ ⚫ 2016年10月、Nicole ForsgrenとJez HumbleはDevOps Research and Assessment (DORA)を立ち上げます。これは、誰からの支援（投資）を受けずに立ち上げた会社だったそうです。
⚫ そもそも、なぜ会社設立に至ったのか？Jez Humbleのブログ* をもとに解き明かしたいと思います。 Nicole Forsgren, PhD Jez Humble * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667 131

DORAの設立へ 132 ⚫ State of DevOps Reportの研究は地道に成果を上げ始め、その取り組みが実際のビジネス成果を改善することも証明し、多くの企業からデータを集めることにも成功していました。 ⚫ 一方で、組織が抱える2つの大きな問題も見えてきたそうです。その2つとは―

133 ◼ ビッグバン型変革の問題多くの組織が陥った失敗パターンの代表例が「ビッグバン型変革」でした。これは、アジャイル手法と成熟度モデルを一度に導入しようとしたアプローチです。「どんな組織にも当てはまるテンプレート」として導入されたものの、実際の組織の状況とは相容れないことが多く、持続可能な改善にはなかなかつながりませんでした。
特に大きな問題は、現場で働く実務者の関与が不足していたことでした。日常業務の中で原則や実践を少しずつ試しながら改善していくプロセスが欠如しており、このことが変革の成功率を大きく下げる要因となっていました。 ◼ コンサルタントモデルの問題多くの組織は改革のためにコンサルタントを採用し、現状分析と改善策の提案を求めました。しかし、このアプローチにも課題がありました。コンサルタントが話を聞けるのは、実際に作業を行っている現場の人々のほんの一握りに過ぎません。さらに、改善提案はコンサルタント個人の専門知識に大きく依存することになり、客観的に進捗状況を追跡することも難しくなりました。実は、このやり方はコンサルティング会社にとっても理想的なビジネスモデルとは言えませんでした。なぜなら、優秀な人材を現場に配置しなければならないにもかかわらず、継続的な仕事が保証されているわけではなかったからです。また、このアプローチは規模の拡大も難しく、ビジネスとしての成長にも限界がありました。 * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667

DORAの設立へ ⚫ これらの問題認識から、NicoleとJezは、アルゴリズムを活用して組織の改善領域を特定し、具体的な改善戦略を提案できるプラットフォームの必要性を認識しました。 ⚫ 特に注目すべきは、変革や改善を「どこから始めるべきか？」という組織からの本質的な問いに、データとアルゴリズムを用いて客観的に答えられる仕組
みを作ろうとした点です。 ⚫ 2016年にDORAは設立されました。同年10月には Nicoleがフルタイムでの経営を開始し、DevOps Enterprise Summitでは最初の顧客となったCapital One（米大手金融持株会社）とともに、DORAの正式な「お披露目」が行われています。 * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667 この話題が出た時、Nicoleの目が輝きました。「ねえ、もしソフトウェアデリバリーのプロセス全体から何十人もの人々のデータがあれば、その問いに答えられるはずだよ。どのアルゴリズムを使うべきか、それをどう修正すべきかも分かる。これは制約理論（TOC）の問題に過ぎない。最も賢く効率的に戦略を立てる方法を伝えられる。」私は一瞬考えて言いました。「待って、本当に？それならば作ってみよう！」そして、そこからDORAは誕生したのです。私たちは翌日からモックアップの作成に取り掛かりました。 Jez Humbleのブログ*から

1975 1977 1986 1989 1987 1970 1989/0 1982 1979 1979
1978 ソフトウェア関連の論⽂ ‧ ⽂献 1 1978/5/1 1988/3/1 1984 1976 1981

2005/10 1999 2004/11/16 2002 1995 1994/10/31 1989 1989/02/01 2001/5/18 1996/8
2000/12/1 2005/10/7 1988/3/1 1995/10/1 2003/9/1 2003/9/1

2016 - 2017 State of DevOps Report 142 ⚫ Puppet
+ DORA の連名で発表された2016年と2017年のState of DevOps Reportは、制約理論をベースにしたアルゴリズムを活用し、数千の組織から得られたデータを統計的に分析することでDevOpsの実践と組織のパフォーマンスの関係性を客観的に実証しました。 ◼ 2016 パフォーマンス指標指標 High Medium Low Deployment Frequency オンデマンド（1日複数回）週1回〜月1回月1回〜6ヶ月に1回 Lead Time for Changes 1時間未満 1週間〜1ヶ月 1ヶ月〜6ヶ月 MTTR 1時間未満 1日未満 1日未満* Change Failure Rate 0-15% 31-45% 16-30% ◼ 2017 パフォーマンス指標指標 High Medium Low Deployment Frequency オンデマンド（1日複数回）週1回〜月1回週1回〜月1回* Lead Time for Changes 1時間未満 1週間〜1ヶ月 1週間〜1ヶ月* MTTR 1時間未満 1日未満 1日〜1週間 Change Failure Rate 0-15% 0-15% 31-45% * ローパフォーマーは概して（統計的に有意なレベルで）成績が悪かったが、中央値はミディアムパフォーマーと変わらなかった。 * ローパフォーマーは概して（統計的に有意なレベルで）成績が悪かったが、中央値はミディアムパフォーマーと変わらなかった。

DORA激動の2018年 143

DORA激動の2018年 ⚫ 2018年は、DORAにとって激動の年でした。 ⚫ まず、2018年3月27日、かねてより進めていた新しい書籍が発売となります。 ⚫ Accelerate: The Science
of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations（邦題「LeanとDevOps の科学」）です。 ⚫ この本の出版でMartin Fowlerと約束を果たしたことになります。この本はDORAの「研究の調査・分析手法を紹介・解説する本」として生まれました。

DORA激動の2018年 ⚫ 発行はIT Revolution Pressで、DORAの二人Nicole Forsgren、Jez Humble、そしてIT Revolutionの Gene Kimの名前で発行されました。
⚫ しかし、ここにPuppet Labsのメンバーはいません。（謝辞の中には出てきますが）そして「LeanとDevOpsの科学」が出版された翌月―

DORA激動の2018年 148 ⚫ 書籍名 "Accelerate" を冠した Accelerate State of DevOps
Report という、新しいプログラムを発表します。 ⚫ これは、長年共に歩んできたPuppet社とのパートナーシップ解消を意味しました。DORAは、次のパートナーとしてGoogle Cloudを選択したのです。* ⚫ 新しい Accelerate State of DevOps Reportは2018年 8月29日にリリースされました。筆者としてクレジットされたメンバーは3人だけでした。 * https://www.infoq.com/news/2018/04/DORA-Google-Cloud-New-Research/ 1. Nicole Forsgren PhD（ニコール・フォースグレン博士） 2. Gene Kim（ジーン・キム） 3. Jez Humble（ジェズ・ハンブル）

2018 Accelerate State of DevOps Report 149 ⚫ 肝心の中身ですが、2018年のパフォーマンスの指標とレベルにはちょっとした変化が生じます。 ⚫
それは、MTTRが"Time to restore service"という言い方に変わったことと、レベルに初めてEliteが登場したことです。 ◼ 2018 パフォーマンス指標指標 Elite High Medium Low Deployment Frequency オンデマンド（1日複数回） 1日1回〜週1回週1回〜月1回月1回〜6ヶ月に1回 Lead Time for Changes 1時間未満 1日〜1週間 1週間〜1ヶ月 1ヶ月〜6ヶ月 Time to restore service 1時間未満 1日未満 1日未満 1週間〜1ヶ月 Change Failure Rate 0-15% 0-15% 0-15% 46-60%

DORAの終焉 150 ⚫ リサーチは順調であったようですがDORAのCEO兼主任研究員であったDr. Nicole Forsgrenには大きな重圧がかかっていたようです。 ⚫ この頃のことをJez Humbleはブログで次のように振り返っています。
* https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667 経費を抑えた自力での会社運営には大きな代償がありました。それは燃え尽き症候群です。スタートアップは創業者を疲弊させることで有名ですが、私たちも例外ではありませんでした。特に最も大きな負担を背負っていたのはNicoleでした。CEOとして彼女は、会社の戦略、財務、そして事業運営全般に責任を負っていました。それだけではありません。CEOとして市場戦略の立案と実行をほぼ一人で担うだけでなく、State of DevOpsレポートの主任研究者、『Accelerate』の主執筆者、そして買収交渉の責任者も務めていました。彼女が言うように、これらの成果はすべて何年もかけて築き上げたものですが、驚くべき仕事の処理能力を持っていた彼女でさえ、膨大な時間の労働なしにはこれらを実現することはできなかったでしょう。これこそが投資を受けなかったことの代償でした - より大きなチームを雇って、この重荷を分散することができなかったのです。 Jez Humbleのブログ*から

DORAの終焉 151 ⚫ 2018年12月、Nicole ForsgrenはDORAをGoogleに売却する決断をしたのでした。

Puppet版State of DevOps Report ⚫ 一方、Puppet社も2018年は独自のState of DevOps Reportを発行します。 ⚫
しかし、これはDORA版とは異なるポリシーで編集されたものでした。2013年版に原点回帰するかの如く、DevOpsの進化の段階を特定し、DevOpsへの変革プロセスの定量化に舵を切っています。 ⚫ Puppet版 2018 State of DevOps Reportについて語る人物は、あのAlanna Brownでした。 ⚫ Puppet社は、2022年4月にソフトウェア開発ツール大手Perforce Software, Inc. に買収されましたが、現在もState of DevOps Reportはシリーズを継続中であり、主にDevOpsに取り組む現場での実用性に重点を置いています。

Googleになってからの State of DevOps Report 155

入れ替わる著者陣 ⚫ 2019年にGene Kim、2021年にはDr.Nicole ForsgrenとJez HumbleがDORAを去りました。 ⚫ 現在は、新たなDORAメンバーやGoogleのリサーチャーを中心に研究が引き継がれています。

入れ替わる著者陣 ⚫ Gene Kim は現在もIT Revolutionの代表であり、執筆活動や講演を精力的にこなしています。 ⚫ 2019年に来日しており、DevOpsDays Tokyo
2019のキーノートセッションに登壇しています。（私は現地で拝聴できました） ⚫ Jez Humble は現在もGoogleに席を置きSRE(Site Reliability Engineering)のエンジニアとして活躍する傍ら、カリフォルニア大学バークレー校（UC Berkeley）の教員も続けている。 Jez Humble Gene Kim

入れ替わる著者陣 158 ⚫ Dr.Nicole Forsgrenは現在Microsoft Research のパートナーとして Developer Experience
Lab を率いており、ACM Queue の取締役も務めています。 ⚫ 最近は、科学を活用しソフトウェア開発者をより楽しくする研究を実践しています。DevExやSPACEフレームワークに関する研究論文を発表し、精力的に活動中です。 ⚫ 昨年6月に来日し当社主催の「開発生産性 Conference 2024」にて基調講演をご担当頂きました。 Dr. Nicole Forsgren （開発生産性Conference 2024にて）

入れ替わる著者陣 159 ⚫ 2022年と2023年の2年間だけ、著名なエンジニア David(Dave) Farley（デイビッド（デイブ）・ファーリー）が加わっていました。 ⚫ 彼は、Jez Humbleと共にベストセラー「Continuous
Delivery」を書いた人物です。 ⚫ 書籍「Modern Software Engineering（継続的デリバリーのソフトウェア工学）」の筆者でもあり、文中、Dr. Nicole Forsgrenにまつわるエピソードや DORAの研究成果が引用されています。 David(Dave) Farley (Image source: InfoQ.com)

Eliteが消えたり現れたり ⚫ 2022年の分析では、パフォーマンスレベルからEliteが消滅します。これは、最もパフォーマンスの高いクラスタが、2021年のEliteの特徴を示していなかったためと述べられています。翌年2023年は復活しました。 ◼ 2022 パフォーマンス指標指標 ― High
Medium Low Deployment Frequency ― オンデマンド週1回〜月1回月1回未満 Lead Time for Changes ― 1日未満 1日〜1週間 1ヶ月〜6ヶ月 Time to restore service ― 1日未満 1日〜1週間 1週間以上 Change Failure Rate ― 0%〜15% 16%〜30% 30%以上 ◼ 2023 パフォーマンス指標指標 Elite High Medium Low Deployment frequency オンデマンド（1日複数回） 1日1回〜週1回の間週1回〜月1回の間週1回〜月1回の間 Change lead time 1日未満 1日〜1週間の間 1週間〜1か月の間 1週間〜1ヶ月の間 Failed deployment recovery time 1時間未満 1日未満 1日〜1週間の間 1ヶ月〜6か月の間 Change Failure Rate 5% 10% 15% 64%

Eliteが消えたり現れたり ⚫ これは、クラスター分析の特性として仕方のない現象でもあります。クラスター分析は、データの分布やその年の回答者の特性に基づいて自然に分類を形成する手法であり、事前にクラスター数やその特徴を固定するものではありません。 ⚫ そのため、特定のパフォーマンス層が少数であったり、他の層と重なりがある場合、ある年には明確なクラスターとして現れず、翌年に再び明確化することがあります。この柔軟性こそがクラスター分析の利点であり、データに忠実であることを意味しています。

2023年からFour Keyの一部名称と定義が変更 164 指標 2023年の定義 2022年までの定義変更点 Deployment frequency (デプロイ頻度)
変更を本番環境に push する頻度。主なアプリケーションまたはサービスで、組織が本番環境にコードをデプロイする頻度、またはエンドユーザーにリリースする頻度はどのくらいか。定義が簡潔化され、本番環境への変更適用に焦点が絞られています。 Lead time for changes (変更のリードタイム) コードの変更を commit してからデプロイするまでの時間。主なアプリケーションまたはサービスで、変更のリードタイム（commit されたコードが本番環境で正常に実行されるまでの時間）はどのくらいか。定義が簡潔化され、コミットからデプロイまでの具体的な工程に限定。「本番環境で正常に実行される」という表現が省かれています。 Change failure rate (変更失敗率) デプロイにより障害が発生し、すぐに対処する必要が生じる頻度。主なアプリケーションまたはサービスで、本番環境に変更を加えた、またはユーザーに変更をリリースしたとき、サービスの低下（サービス障害、サービスの停止など）が発生して、対策（修正プログラム、ロールバック、フィックスフォワード、パッチなど）が必要になった割合はどのくらいか。「デプロイにより障害が発生し」という表現に変更され、障害の発生原因がデプロイに限定。具体的な対策例が削除されました。 Failed deployment recovery time (失敗デプロイの復旧時間) (旧名称: Time to restore service (サービス復旧時間)) デプロイの失敗時に復旧にかかる時間。主なアプリケーションまたはサービスで、サービスのインシデントや、ユーザーに影響を与える障害（計画外のサービス停止やサービス障害など）が発生した場合、サービスの復旧に通常どれくらいの時間がかかるか。指標名が変更され、定義が「デプロイの失敗」に絞られました。例として挙げられていた「計画外のサービス停止やサービス障害」が削除されました。

リフレクション：DORA Reportを正しく読み解くために 1. DORA Report は単なるサーベイの結果ではなく、 2014年以降、統計学を用いた「科学的リサーチ」に基づいて分析されている。 2. 「科学的リサーチ」の具体な内容は書籍『Leanと
DevOpsの科学』で解説されている。 3. Four Keysを元にしたパフォーマンスレベルは統計的な分析手法（クラスター分析）が用いられ、調査年ごとに変化する。 4. DORA はこのレポートを用いて、各組織（企業）が独自の実験や仮説を立てることを望んでいる。

2024 Accelerate State of DevOps Report

DORAが示す、AIのこれから 196 本レポートは、『Accelerate State of DevOps Report』で発表された DORA の研究を基盤とし、それをさらに発展させています。現在の
AI 導入状況を概観し、開発者や組織への影響を探るとともに、AI の成功する統合、測定、継続的改善のためのフレームワークと実践的なガイダンスを提示しています。新しいテクノロジーの導入は、短期的には生産性や影響力の低下を伴うことがあるという点も忘れてはなりません。持続的で長期的な改善を優先することで、生成 AI 導入の恩恵をしっかりと享受できるようになるでしょう。 https://cloud.google.com/resources/content/dora-impact-of-gen-ai-software-development?hl=ja

おわりに 197

ソフトウェア開発は、今も昔も、どこか実験的である 198 ⚫ Tom DeMarcoは左記記事の最後で、こう締めくくっています。 ⚫ DORAが日々の実践と実験の中から何が本当にチームを強くし、ソフトウェアをより良いものにするのかを探求し続けたその姿勢、まさにDeMarcoが語っ
た「ここに焦点」を当て続けた挑戦そのものだと感じます。ソフトウェア開発は、今も昔も、どこか実験的である。実際のソフトウェアの構築はそれほど実験的ではありませんが、その構想は実験的です。そして、この点にこそ私たちの焦点が当てられるべきでしょう。私たちは常にここに焦点を当てるべきでした。 (Tom DeMarco, 2009) Photo of Tom DeMarco by Hans-Rudolf Schulz (*1) *1: https://www.oreilly.com/library/view/peopleware-productive-projects/9780133440706/pref02.xhtml *2: https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf

"Applying insights from DORA"（DORAの知見を実践に活かすために） ⚫ DORAの研究成果は決して一時的なトレンドではありません。Four Keysなどを単なる「流行り」と捉えるのは誤りです。しかし、その一方で、すべてを鵜呑みにする必要もありません。 ⚫ 2024年で10周年を迎えたDORA
Reportには、この取り組みが成熟してきたことを示す重要なメッセージが随所に見られます。その代表例が"Applying insights from DORA"（DORAの知見を実践に活かすために）という章です。私たちの調査結果は、皆様が独自の実験や仮説を立てる際の参考にしていただけます。チームや組織に最適なアプローチを見出すために、変更による影響を測定しながら実験を重ねることが重要です。それにより、私たちの調査結果の検証にもつながります。結果は組織によって異なることが想定されますので、ぜひ皆様の取り組みを共有していただき、その経験から互いに学び合えればと思います。

ソフトウェア開発現代史: "LeanとDevOpsの科学"の「科学」とは何か？ - DORA ...

ソフトウェア開発現代史: "LeanとDevOpsの科学"の「科学」とは何か？ - DORA Report 10年の変遷を追って - #開発生産性_findy

More Decks by Hiroyuki TAKAHASHI

Other Decks in Technology

Featured

Transcript