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

DevOpsDays Tokyo 2025 Day 1 でお話しした資料です

Transcript

1. Findy Inc. ソフトウェア開発現代史: "LeanとDevOpsの科学"の「科学」とは何か？ - DORA Report 10年の変遷を追って - DevOpsDays Tokyo 2025 Day 1 ファインディ株式会社 CTO室 ⾼橋 裕之（2025/4/15）
2. ⾃⼰紹介 2
3. u 1989 株式会社ジェーシーイ SESとして⽇⽴通信システム株式会社に常駐。NTT交換機ソフトウェア開発や、TRONプロジェク トに参加し国産OSのCTRON開発に従事。その後、会社が倒産。 u 1993 フリーランス ⽇⽴通信システム株式会社と準委任契約を結び、NTT交換機開発プロジェクトに参画。基本OSや通 信プロトコルソフト開発に従事。 u 1995 株式会社メイテック SESとしてJUKI株式会社に常駐。ICチップマウンターの組み込み開発に従事。 u 1996 ⽇⽴通信システム株式会社（現‧株式会社⽇⽴情報通信エンジニアリング） 正社員として復帰。携帯電話のCDMA2000交換機やIPv6機器開発に従事。また、システムエンジニ アとしてJP1の導⼊⽀援を担当。 u 2002 ソニーデジタルネットワークアプリケーションズ株式会社 RTOSや組み込みLinuxの専⾨家として、主にコンシューマ向けカメラ開発に従事。 また、ソフトウェア開発の諸問題に取り組むため、組織横断型プロセス改善（SEPG）に従事。 u 2013 ウイングアーク１ｓｔ株式会社 プロセス改善コーチ兼アジャイルコーチとして活動。2018年よりソフトウェアプロセス＆品質改善 部部⻑、製品品質管理責任者、オープンソース管理責任者を務める。 u 2021 株式会社ビズリーチ プロセス改善コーチ兼アジャイルコーチとして活動。QAとプロセス改善部⾨のマネジャーとして、 DevOpsアプローチによる開発透明性向上とDORA(Four Keys)メトリクスを⽤いた開発⽣産性によ る改善活動を実施。SODA（Software Outcome Delivery Architecture）構想を⽴案し、プロダクト の事業影響を定量化‧可視化する組織変⾰をリード。 u 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. 会社紹介 4
5. © 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、等
6. © Findy Inc. ファインディが展開するエンジニアプラットフォーム サービス紹介 ToC / ToB SaaS / ToB マッチングサービス 組織分析SaaS ToC / ToB 開発ツールメディア ˞
   ֤छ਺஋͸ɺ೥݄࣌఺ͷ'JOEZస৬ɺ'JOEZ
   'SFFMBODFɺ'JOEZ
   5FBN ɺ'JOEZ
   (MPCBMͷαʔϏεͷྦྷܭͰͷࣾ਺ٴͼొ࿥ऀ਺Ͱ͢ɻ ͳ͓ɺࣾຢ͸໊ͷํ͕ෳ਺ͷαʔϏεʹొ࿥͍ͯ͠Δ৔߹͸ɺͦͷαʔϏεͷ਺ʹԠͯ͡ෳ਺ͷΧ΢ϯτΛ͍ͯ͠·͢ɻ β版 GitHubやJiraを解析し、エンジニア組織の ⾒える化と⽣産性向上をサポート。 エンジニア組織の⾒える化 5万⼈以上のフリーランスエンジニアの 成功報酬型の⼈材紹介サービス。 フリーランスエンジニアの採⽤ 約12万⼈のエンジニアと880社以上の テック企業をマッチング。 正社員エンジニアの採⽤ 実際に利⽤している企業の声を元に、 開発ツールの導⼊や検討に必要な情報を 集約。企業の技術選定をサポート。 開発ツールのレビューサイト 6
7. シリーズ：ソフトウェア開発現代史 7
8. シリーズ：ソフトウェア開発現代史 8 TECH PLAY: 今こそ考えたい「開発プロセスの品質視点」 製造業とソフトウェアは本当に共存できていたのか？ 品質とスピードを問い直す https://speakerdeck.com/takabow/zhi-zao-ye- tosohutoueahaben-dang-nigong-cun-dekiteitanoka-pin- zhi-tosupidowowen-izhi-su-dc76f0ad-2d4c-4f2a-bf4d- cecbceb7eb5e JaSST’25 Tokyo Day2 なぜ日本のソフトウェア開発は「滝」なのか？ 製造業の成功体験とのギャップ https://speakerdeck.com/takabow/sohutoueakai-fa-xian- dai-shi-nazeri-ben-nosohutoueakai-fa-ha-long-nanoka- zhi-zao-ye-nocheng-gong-ti-yan-tonogiyatupu-number- jassttokyo お客様向け資料 「モダンソフトウェア エンジニアリングとは」 本 ⽇ の 発 表
9. 9 ⽇本ソフトウェア産業が置かれた現状 l 1960年頃から、⽇本のものづくりは「品質管理」と いう武器を⼿に⼊れ躍進。⽇本製品が世界中で⼈気 となる l 1979年、⽶ハーバード⼤学のエズラ‧ヴォーゲル教 授が出版した『Japan as Number One: Lessons for America』がベストセラーに l 50年が経ちソフトウェア‧ファーストな現代。Big Techと呼ばれる企業は⽇本に1社も存在せず、その ほとんどは⽶国企業である l ものづくりで世界をリードしてきたはずの⽇本は、 ソフトウェア産業においては、実に50年近くも他国 の後塵を拝し続けている……なぜか？ “ウォークマン” 1号機 TPS-L2 （1979） Toyota Corolla Liftback SR5 001 （1980〜） ソニートリニトロンシリーズ （1968〜） 世界初のポータブル CDプレーヤー D-50（1984） Vogel, E. F. (1979). Japan as number one: Lessons for America. Cambridge, MA: Harvard University Press. Magnificent Seven
10. 10 50年近くも他国の後塵を拝し続けている理由 l 現代のソフトウェアが主体の「ものづくり」では、顧客への「完璧さ」よりも、 エンドユーザーへのスピードと柔軟な改善が求められる。 l しかし⽇本のソフトウェア産業は正しいと信じ続けた価値観から抜け出せず、ウ ォーターフォール開発や⼈⽉ビジネスといった旧来の慣習にとどまり続けた。 l その結果、世界のソフトウェア産業を牽引するBig Techの中に⽇本企業の姿は⾒ 当たらない。なぜ、こうなってしまったのか？ l さまざまな原因分析と解決策はこれまでも幾度となく提⾔されてきたはず。 l いま必要なのは、新しい解決策ではなく⸺ “なぜ今こうなっているのか？”という歴史を振り返る視点なのかもしれない。 私の仮説：「正しいと信じ続けた価値観は間違った歴史認識から来ている」
11. 10年前 20年前 30年前 40年前 50年前 2018：!マイクロソフト、GitHub を 75 億ドルで買収 2001/2/11：" アジャイルソフ トウェア開発宣⾔ 2005/10 1991〜：#バブル崩壊「失われた◦◦年」 1988〜：!⽇本を含む諸外国へ「通商法スーパー301条」発動 ソフトウェア開発現代史年表 Ver2.06 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 S O F T W A R E REQUIREMENTS: ARE THEY REALLY A PROBLEM? T. E. Bell and T. A. Thayer T R W Defense and Space Systems Group Redondo Beach, California ,Keywords and Phrases Ballistic Missile Defense Requirements Requirements Problems Software Engineering Software Requirements Software Requirements Engineering Software Requirements Problems S R E M SREP Abstract Do requirements arise naturally from an obvious need, or do they come about only through diligent effort -- and even then contain problems? Data on two very different types of software requirements were analyzed to determine what kinds of problems occur and whether these problems are important. The results are dramatic: software requirements are important, and their problems are surprisingly similar across pro- jects. New software engineering techniques are clearly needed to improve both the development and statement of requirements. I. Introduction Identifying the cause of a problem in a software system is often very easy -- if the cause is a problem in code. Typically, identified coding problems result in clearly incorrect answers or in abnormal termina- tions of the software. Similarly, problems in a soft- ware system caused by deficiencies in design are often easy to identify from unexpected software operation or from extreme difficulty in maintaining and modifying the system. Problems in the system caused by defi- ciencies in software requirements, on the other hand, are often not identified at all, or are thought to be caused by bad design or limitations of computing tech- nology. If there are problems in developing require- ments, however, the software system meeting those requirements will clearly not be effective in solving the basic need, even if the causes of the problems are incorrectly identified. The Ballistic Missile Defense Advanced Technology Center (BMDATC) is sponsoring an integrated software development research program Ill to improve the tech- niques for developing correct, reliable B M D software. Reflecting the critical importance of requirements in the development process; the Software Requirements Engineering Program (SREP) has been undertaken as a part of this integrated program by T R W Defense and Space Systems Group* to examine and improve the quality of requirements. One of the first efforts in SREP has been to characterize the problems with requirements so that techniques can be developed to improve the situation. Instead of pursuing philosophical discussions about what the problems might be, we have undertaken empiri- cal studies to determine what the problems actually are. A limitation on the number of Ballistic Missile Defense (BMD) systems currently being developed (there is only one) has led us to examine both B M D and more common data processing systems to ensure that our results are characteristic of software requirements in general, rather than just one particular project. This paper reports on initial results that have set much of the direction pursued in the Software Requirements Engineering Methodology [2], the Require- ments Statement Language [3], and the Requirements Engineering and Validation System [4]. The initial efforts were oriented to determine the magnitude and characteristics of the problems, and to indicate what types of techniques could correct the problems. The empirical study of software problems is continuing in parallel with technology development so that the technology can be refined and tested for effectiveness in solving the identified problems. II, What are Software Requirements? One school of thought maintains that software requirements arise naturally, and that they are correct by definition. If these requirements merely state a basic need (e.g., "do payroll"),then that's all that is needed. On the other hand, if the requirements state each subroutine's detailed characteristics, then those are the required characteristics, and the implementer should not question them. Adherents to this school of thought have grown fewer and fewer as the software industry has gathered experience with this approach to developing software. When every requirement ranging in detail from needs statements to subroutine specifications is considered in the same way, the resulting systems tend to be seriously deficient. If coding personnel are assigned the task of implementing a system with only a needs statement, the critical phase of software design will likely be skipped -- with disasterous results. On the other end of the scale, if detailed subroutine speci- fications are accepted without ever having been *Under Contract DASG60-75-C-O022 61 リリース （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が実装された。 Netflixが⽇本に上陸(2015/9/2) ※!では2007/1にサービスイン 2017/10/14 2003/9/1 2002/11/8 2009：!Flickrのエンジニアである John AllspawとPaul Hammondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：" クラウドファースト‧クラウドネイティブ時代に突⼊ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤ ★ ピ ア ソ ン シ ョ ッ ク 2017/7/31 2009/11/27 2008/12/30 2023/11/28
12. 12 1991〜：#バブル崩壊「失われた◦◦年」 1988〜：!⽇本を含む諸外国へ「通商法スーパー301条」発動 ソフトウェア開発現代史年表 Ver2.06 Linux 0.01 リリース UNIXが商業化‧断⽚化していく中、 Linuxはオープンソースの⼒で 統⼀的な開発基盤となり、 世界中の技術⾰新を⽀えた （1991/9/17） CVS 誕⽣ （1990） Java v1.0 正式リ Javaはオブジェ 仮想マシン技術 後の⾔語設計に （1996） 1980年代後半〜1990年代前半：" UNIX戦争 1970〜1980年代："多くの企業や政府機関が「ウォーターフォールモデル」を公式な開発プロセスとして採⽤。 同時に、Royceの思惑と違う、誤解された「ウォーターフォール」が広まる 1990〜2000：" 第⼀次ブラウザ戦争。Internet Explor Netscape Navigatorの消滅 1985〜1990：#国家プロジェクト 「Σ計画」が頓挫 19 件 1990年代：!ウォーターフォールのリスクを軽減する開 と誕⽣（インクリメンタル、スパイラル、RUP など） 1980年後半〜1990年前半：!⽶国防総省(DoD)の発注したソフトウェアに問題が多 発。⽶会計局でも多くの遅延∕途中での挫折が発⽣‵ 主 な 出 来 事 1980年〜：!⽶国防総省(DoD) がウォーターフォールを採⽤ Windows95 リリース コンシューマ向けOSに TCP/IPが標準搭載され ワークステーション並み （1995） !Point: ⽶国防総省(DoD)が与えた影響 1970年代後半〜1980年代末：#⽇本⾞と家電がアメリカ市場を席巻。これが、徐々に⽇⽶貿易摩擦の⽕種に…… "ウォークマン” 1号機 TPS-L2 （1979） 世界初のポータブル CDプレーヤー D-50（1984） Toyota Corolla Liftback SR5 001 （1980〜） “トリニトロン” ⽇本製品が欧⽶で⼈気 1979〜：!⽇本の製造業の⾼品質、ものづくりの強さを研究。 1974年：!「TCP/IP」の最初の仕様がRFC 675として公開 1982年〜：!⽶国防総省(DoD)は全ての軍⽤コンピュータ網のためにTCP/IP標準を作成。その後、コンピュー
13. 13 2018：!マイクロソフト、GitHub を 75 億ドルで買収 2001/2/11：" アジャイルソフ トウェア開発宣⾔ sionリリース 2000） （2005） GitHub リリース （2008） ugzilla リース 2000） Jira リリース （2002） AWS サービス開始 （2006） Jenkins 誕⽣ （2011） GitHub Actions （2018） ChatGPT ⼀般公開 （2022/11/30） GitHub Copilot （2021/6/29） Azure サービス開始 （2010） 2009〜2020：" 第⼆次ブラウザ戦争 Google Chromeの躍進、 Internet Explorerの衰退 （2018） （2004） Google Cloud サービス開始 （2008） 欧州の⾃動⾞メーカ が中⼼となって公開（2005） （2011） （2006） （2004） ⽶国防総省(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） Gemini 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 Hammondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：" クラウドファースト‧クラウドネイティブ時代に突⼊ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤
14. 14 30年前 40年前 50年前 1974 1976 1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 200 1975 1999 1977 1986 1995 1994/10/31 1989 1987 1970 1989/02/01 1982 1979 1992/3/13 1996/4/1 1996/8 1979 1978 1972 ソ フ ト ウ ェ ア 関 連 の 論 ⽂ ‧ ⽂ 献 PC/AT互換機が誕⽣（1981〜） ワークステーションの時代：Sun SPARCstation （1989〜1994） 初代iMac （1998〜） Apple Macintosh （1984〜） DynaBook （1994〜） ICT の 進 化 メインフレーム時代： IBM System 360とVT100（1970〜1980） 2000/12 1990/10/10 1978/5/1 1988/3/1 1984 1995/10/1 1976 S O F T W A R E REQUIREMENTS: ARE THEY REALLY A PROBLEM? T. E. Bell and T. A. Thayer T R W Defense and Space Systems Group Redondo Beach, California ,Keywords and Phrases Ballistic Missile Defense Requirements Requirements Problems Software Engineering Software Requirements Software Requirements Engineering Software Requirements Problems S R E M SREP Abstract Do requirements arise naturally from an obvious need, or do they come about only through diligent effort -- and even then contain problems? Data on two very different types of software requirements were analyzed to determine what kinds of problems occur and whether these problems are important. The results are dramatic: software requirements are important, and their problems are surprisingly similar across pro- jects. New software engineering techniques are clearly needed to improve both the development and statement of requirements. I. Introduction Identifying the cause of a problem in a software system is often very easy -- if the cause is a problem in code. Typically, identified coding problems result in clearly incorrect answers or in abnormal termina- tions of the software. Similarly, problems in a soft- ware system caused by deficiencies in design are often easy to identify from unexpected software operation or from extreme difficulty in maintaining and modifying the system. Problems in the system caused by defi- ciencies in software requirements, on the other hand, are often not identified at all, or are thought to be caused by bad design or limitations of computing tech- nology. If there are problems in developing require- ments, however, the software system meeting those requirements will clearly not be effective in solving the basic need, even if the causes of the problems are incorrectly identified. The Ballistic Missile Defense Advanced Technology Center (BMDATC) is sponsoring an integrated software development research program Ill to improve the tech- niques for developing correct, reliable B M D software. Reflecting the critical importance of requirements in the development process; the Software Requirements Engineering Program (SREP) has been undertaken as a part of this integrated program by T R W Defense and Space Systems Group* to examine and improve the quality of requirements. One of the first efforts in SREP has been to characterize the problems with requirements so that techniques can be developed to improve the situation. Instead of pursuing philosophical discussions about what the problems might be, we have undertaken empiri- cal studies to determine what the problems actually are. A limitation on the number of Ballistic Missile Defense (BMD) systems currently being developed (there is only one) has led us to examine both B M D and more common data processing systems to ensure that our results are characteristic of software requirements in general, rather than just one particular project. This paper reports on initial results that have set much of the direction pursued in the Software Requirements Engineering Methodology [2], the Require- ments Statement Language [3], and the Requirements Engineering and Validation System [4]. The initial efforts were oriented to determine the magnitude and characteristics of the problems, and to indicate what types of techniques could correct the problems. The empirical study of software problems is continuing in parallel with technology development so that the technology can be refined and tested for effectiveness in solving the identified problems. II, What are Software Requirements? One school of thought maintains that software requirements arise naturally, and that they are correct by definition. If these requirements merely state a basic need (e.g., "do payroll"),then that's all that is needed. On the other hand, if the requirements state each subroutine's detailed characteristics, then those are the required characteristics, and the implementer should not question them. Adherents to this school of thought have grown fewer and fewer as the software industry has gathered experience with this approach to developing software. When every requirement ranging in detail from needs statements to subroutine specifications is considered in the same way, the resulting systems tend to be seriously deficient. If coding personnel are assigned the task of implementing a system with only a needs statement, the critical phase of software design will likely be skipped -- with disasterous results. On the other end of the scale, if detailed subroutine speci- fications are accepted without ever having been *Under Contract DASG60-75-C-O022 61 1981 数字送信の開始による ポケベルブーム（⽇本） （1992〜1996） F501i HYPE iモード開始 （1999/2/22 テレホーダイ（1995〜2023） PC-9800シリーズ（1982〜2003） パソコン通信 携帯電話・PHSの普及、インターネ
15. 15 10年前 20年前 2005/10 2024 1998 2000 2002 2004 2006 2008 2010 2012 2014 2016 2018 2020 2022 1999 2018/11/22 2004/11/16 2006/10/19 2002 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 2001/5/18 2004/7/16 2013/8/1 2014/4/22 2019/9/30 2021/12/10 2024/9/13 2026 初代iPhone発表 (2007/1/9) Mac 8〜） 家庭向けADSL‧FTTHの普及、 ブロードバンド時代に突⼊ (2001〜) MacBook Pro M4 Max （2024） 2018/3/27 2000/12/1 2010/7/27 2016/10/6 2005/10/7 2021/8/1 2003/9/1 2021/12/1 2018/4/1 F501i HYPER iモード開始 （1999/2/22） ） 初代iPad発表 (2010/4/3) Samsung Galaxy S II (2011/5/2) ARMアーキテクチャのSoC Apple M1 ⽣産（2020） 2024/12/25 2013/1/10 2014/8/18 2023/11/21 普及、インターネット黎明期 携帯電話の多機能化、ブロードバンド時代 スマートフォン普及時代（2010年、モバイル端末利⽤率がパソコン利⽤率を超える） Netflixが⽇本に上陸(2015/9/2) ※!では2007/1にサービスイン 2017/10/14 2003/9/1 2002/11/8 ★ ピ ア ソ ン シ ョ ッ ク 2017/7/31 2009/11/27 2008/12/30 2023/11/28
16. 10年前 20年前 30年前 40年前 50年前 2018：!マイクロソフト、GitHub を 75 億ドルで買収 2001/2/11：" アジャイルソフ トウェア開発宣⾔ 2005/10 1991〜：#バブル崩壊「失われた◦◦年」 1988〜：!⽇本を含む諸外国へ「通商法スーパー301条」発動 ソフトウェア開発現代史年表 Ver2.06 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 S O F T W A R E REQUIREMENTS: ARE THEY REALLY A PROBLEM? T. E. Bell and T. A. Thayer T R W Defense and Space Systems Group Redondo Beach, California ,Keywords and Phrases Ballistic Missile Defense Requirements Requirements Problems Software Engineering Software Requirements Software Requirements Engineering Software Requirements Problems S R E M SREP Abstract Do requirements arise naturally from an obvious need, or do they come about only through diligent effort -- and even then contain problems? Data on two very different types of software requirements were analyzed to determine what kinds of problems occur and whether these problems are important. The results are dramatic: software requirements are important, and their problems are surprisingly similar across pro- jects. New software engineering techniques are clearly needed to improve both the development and statement of requirements. I. Introduction Identifying the cause of a problem in a software system is often very easy -- if the cause is a problem in code. Typically, identified coding problems result in clearly incorrect answers or in abnormal termina- tions of the software. Similarly, problems in a soft- ware system caused by deficiencies in design are often easy to identify from unexpected software operation or from extreme difficulty in maintaining and modifying the system. Problems in the system caused by defi- ciencies in software requirements, on the other hand, are often not identified at all, or are thought to be caused by bad design or limitations of computing tech- nology. If there are problems in developing require- ments, however, the software system meeting those requirements will clearly not be effective in solving the basic need, even if the causes of the problems are incorrectly identified. The Ballistic Missile Defense Advanced Technology Center (BMDATC) is sponsoring an integrated software development research program Ill to improve the tech- niques for developing correct, reliable B M D software. Reflecting the critical importance of requirements in the development process; the Software Requirements Engineering Program (SREP) has been undertaken as a part of this integrated program by T R W Defense and Space Systems Group* to examine and improve the quality of requirements. One of the first efforts in SREP has been to characterize the problems with requirements so that techniques can be developed to improve the situation. Instead of pursuing philosophical discussions about what the problems might be, we have undertaken empiri- cal studies to determine what the problems actually are. A limitation on the number of Ballistic Missile Defense (BMD) systems currently being developed (there is only one) has led us to examine both B M D and more common data processing systems to ensure that our results are characteristic of software requirements in general, rather than just one particular project. This paper reports on initial results that have set much of the direction pursued in the Software Requirements Engineering Methodology [2], the Require- ments Statement Language [3], and the Requirements Engineering and Validation System [4]. The initial efforts were oriented to determine the magnitude and characteristics of the problems, and to indicate what types of techniques could correct the problems. The empirical study of software problems is continuing in parallel with technology development so that the technology can be refined and tested for effectiveness in solving the identified problems. II, What are Software Requirements? One school of thought maintains that software requirements arise naturally, and that they are correct by definition. If these requirements merely state a basic need (e.g., "do payroll"),then that's all that is needed. On the other hand, if the requirements state each subroutine's detailed characteristics, then those are the required characteristics, and the implementer should not question them. Adherents to this school of thought have grown fewer and fewer as the software industry has gathered experience with this approach to developing software. When every requirement ranging in detail from needs statements to subroutine specifications is considered in the same way, the resulting systems tend to be seriously deficient. If coding personnel are assigned the task of implementing a system with only a needs statement, the critical phase of software design will likely be skipped -- with disasterous results. On the other end of the scale, if detailed subroutine speci- fications are accepted without ever having been *Under Contract DASG60-75-C-O022 61 リリース （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が実装された。 Netflixが⽇本に上陸(2015/9/2) ※!では2007/1にサービスイン 2017/10/14 2003/9/1 2002/11/8 2009：!Flickrのエンジニアである John AllspawとPaul Hammondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：" クラウドファースト‧クラウドネイティブ時代に突⼊ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤ ★ ピ ア ソ ン シ ョ ッ ク 2017/7/31 2009/11/27 2008/12/30 2023/11/28
17. DORAと「State of DevOps Report」の概要 17
18. 10年前 20年前 30年前 40年前 50年前 2018：!マイクロソフト、GitHub を 75 億ドルで買収 2001/2/11：" アジャイルソフ トウェア開発宣⾔ 2005/10 1991〜：#バブル崩壊「失われた◦◦年」 1988〜：!⽇本を含む諸外国へ「通商法スーパー301条」発動 ソフトウェア開発現代史年表 Ver2.06 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 S O F T W A R E REQUIREMENTS: ARE THEY REALLY A PROBLEM? T. E. Bell and T. A. Thayer T R W Defense and Space Systems Group Redondo Beach, California ,Keywords and Phrases Ballistic Missile Defense Requirements Requirements Problems Software Engineering Software Requirements Software Requirements Engineering Software Requirements Problems S R E M SREP Abstract Do requirements arise naturally from an obvious need, or do they come about only through diligent effort -- and even then contain problems? Data on two very different types of software requirements were analyzed to determine what kinds of problems occur and whether these problems are important. The results are dramatic: software requirements are important, and their problems are surprisingly similar across pro- jects. New software engineering techniques are clearly needed to improve both the development and statement of requirements. I. Introduction Identifying the cause of a problem in a software system is often very easy -- if the cause is a problem in code. Typically, identified coding problems result in clearly incorrect answers or in abnormal termina- tions of the software. Similarly, problems in a soft- ware system caused by deficiencies in design are often easy to identify from unexpected software operation or from extreme difficulty in maintaining and modifying the system. Problems in the system caused by defi- ciencies in software requirements, on the other hand, are often not identified at all, or are thought to be caused by bad design or limitations of computing tech- nology. If there are problems in developing require- ments, however, the software system meeting those requirements will clearly not be effective in solving the basic need, even if the causes of the problems are incorrectly identified. The Ballistic Missile Defense Advanced Technology Center (BMDATC) is sponsoring an integrated software development research program Ill to improve the tech- niques for developing correct, reliable B M D software. Reflecting the critical importance of requirements in the development process; the Software Requirements Engineering Program (SREP) has been undertaken as a part of this integrated program by T R W Defense and Space Systems Group* to examine and improve the quality of requirements. One of the first efforts in SREP has been to characterize the problems with requirements so that techniques can be developed to improve the situation. Instead of pursuing philosophical discussions about what the problems might be, we have undertaken empiri- cal studies to determine what the problems actually are. A limitation on the number of Ballistic Missile Defense (BMD) systems currently being developed (there is only one) has led us to examine both B M D and more common data processing systems to ensure that our results are characteristic of software requirements in general, rather than just one particular project. This paper reports on initial results that have set much of the direction pursued in the Software Requirements Engineering Methodology [2], the Require- ments Statement Language [3], and the Requirements Engineering and Validation System [4]. The initial efforts were oriented to determine the magnitude and characteristics of the problems, and to indicate what types of techniques could correct the problems. The empirical study of software problems is continuing in parallel with technology development so that the technology can be refined and tested for effectiveness in solving the identified problems. II, What are Software Requirements? One school of thought maintains that software requirements arise naturally, and that they are correct by definition. If these requirements merely state a basic need (e.g., "do payroll"),then that's all that is needed. On the other hand, if the requirements state each subroutine's detailed characteristics, then those are the required characteristics, and the implementer should not question them. Adherents to this school of thought have grown fewer and fewer as the software industry has gathered experience with this approach to developing software. When every requirement ranging in detail from needs statements to subroutine specifications is considered in the same way, the resulting systems tend to be seriously deficient. If coding personnel are assigned the task of implementing a system with only a needs statement, the critical phase of software design will likely be skipped -- with disasterous results. On the other end of the scale, if detailed subroutine speci- fications are accepted without ever having been *Under Contract DASG60-75-C-O022 61 リリース （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が実装された。 Netflixが⽇本に上陸(2015/9/2) ※!では2007/1にサービスイン 2017/10/14 2003/9/1 2002/11/8 2009：!Flickrのエンジニアである John AllspawとPaul Hammondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：" クラウドファースト‧クラウドネイティブ時代に突⼊ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤ ★ ピ ア ソ ン シ ョ ッ ク 2017/7/31 2009/11/27 2008/12/30 2023/11/28
19. 10年前 20年前 30年前 40年前 50年前 2018：!マイクロソフト、GitHub を 75 億ドルで買収 2001/2/11：" アジャイルソフ トウェア開発宣⾔ 2005/10 1991〜：#バブル崩壊「失われた◦◦年」 1988〜：!⽇本を含む諸外国へ「通商法スーパー301条」発動 ソフトウェア開発現代史年表 Ver2.06 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 S O F T W A R E REQUIREMENTS: ARE THEY REALLY A PROBLEM? T. E. Bell and T. A. Thayer T R W Defense and Space Systems Group Redondo Beach, California ,Keywords and Phrases Ballistic Missile Defense Requirements Requirements Problems Software Engineering Software Requirements Software Requirements Engineering Software Requirements Problems S R E M SREP Abstract Do requirements arise naturally from an obvious need, or do they come about only through diligent effort -- and even then contain problems? Data on two very different types of software requirements were analyzed to determine what kinds of problems occur and whether these problems are important. The results are dramatic: software requirements are important, and their problems are surprisingly similar across pro- jects. New software engineering techniques are clearly needed to improve both the development and statement of requirements. I. Introduction Identifying the cause of a problem in a software system is often very easy -- if the cause is a problem in code. Typically, identified coding problems result in clearly incorrect answers or in abnormal termina- tions of the software. Similarly, problems in a soft- ware system caused by deficiencies in design are often easy to identify from unexpected software operation or from extreme difficulty in maintaining and modifying the system. Problems in the system caused by defi- ciencies in software requirements, on the other hand, are often not identified at all, or are thought to be caused by bad design or limitations of computing tech- nology. If there are problems in developing require- ments, however, the software system meeting those requirements will clearly not be effective in solving the basic need, even if the causes of the problems are incorrectly identified. The Ballistic Missile Defense Advanced Technology Center (BMDATC) is sponsoring an integrated software development research program Ill to improve the tech- niques for developing correct, reliable B M D software. Reflecting the critical importance of requirements in the development process; the Software Requirements Engineering Program (SREP) has been undertaken as a part of this integrated program by T R W Defense and Space Systems Group* to examine and improve the quality of requirements. One of the first efforts in SREP has been to characterize the problems with requirements so that techniques can be developed to improve the situation. Instead of pursuing philosophical discussions about what the problems might be, we have undertaken empiri- cal studies to determine what the problems actually are. A limitation on the number of Ballistic Missile Defense (BMD) systems currently being developed (there is only one) has led us to examine both B M D and more common data processing systems to ensure that our results are characteristic of software requirements in general, rather than just one particular project. This paper reports on initial results that have set much of the direction pursued in the Software Requirements Engineering Methodology [2], the Require- ments Statement Language [3], and the Requirements Engineering and Validation System [4]. The initial efforts were oriented to determine the magnitude and characteristics of the problems, and to indicate what types of techniques could correct the problems. The empirical study of software problems is continuing in parallel with technology development so that the technology can be refined and tested for effectiveness in solving the identified problems. II, What are Software Requirements? One school of thought maintains that software requirements arise naturally, and that they are correct by definition. If these requirements merely state a basic need (e.g., "do payroll"),then that's all that is needed. On the other hand, if the requirements state each subroutine's detailed characteristics, then those are the required characteristics, and the implementer should not question them. Adherents to this school of thought have grown fewer and fewer as the software industry has gathered experience with this approach to developing software. When every requirement ranging in detail from needs statements to subroutine specifications is considered in the same way, the resulting systems tend to be seriously deficient. If coding personnel are assigned the task of implementing a system with only a needs statement, the critical phase of software design will likely be skipped -- with disasterous results. On the other end of the scale, if detailed subroutine speci- fications are accepted without ever having been *Under Contract DASG60-75-C-O022 61 リリース （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が実装された。 Netflixが⽇本に上陸(2015/9/2) ※!では2007/1にサービスイン 2017/10/14 2003/9/1 2002/11/8 2009：!Flickrのエンジニアである John AllspawとPaul Hammondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：" クラウドファースト‧クラウドネイティブ時代に突⼊ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤ ★ ピ ア ソ ン シ ョ ッ ク 2017/7/31 2009/11/27 2008/12/30 2023/11/28
21. LeanとDevOpsの科学: テクノロジーの戦略的活⽤が組織変⾰を加速する l 原書タイトルは「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」 l 2018年3⽉出版、⽇本語版は2018年11⽉に出版。 l 迅速かつ⾼品質なデリバリを実施している組織 とそうでない組織の違いに関する研究結果を DORAがまとめている。 21
23. DORAの科学的アプローチがもたらした影響 23
24. LeanとDevOpsの科学: テクノロジーの戦略的活⽤が組織変⾰を加速する l 原書タイトルは「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」 l 2018年3⽉出版、⽇本語版は2018年11⽉に出版。 l 迅速かつ⾼品質なデリバリを実施している組織 とそうでない組織の違いに関する研究結果を DORAがまとめている。 24 l この書籍がきっかけで有名になったり、その重要性 が広く認識されるようになったりした法則、概念 1. Four Keys（4つの主要指標） 2. 速度（スループット）と安定性はトレードオフではな い 3. 継続的デリバリー (Continuous Delivery / CD) の効果の 証明 4. 疎結合アーキテクチャの重要性 5. リーン（Lean）の原則の適⽤ 6. Westrum（ウェストラム）の組織⽂化類型 7. ケイパビリティモデル (Capability Model) 8. バーンアウト（燃え尽き症候群）と組織⽂化‧ツール の関係
25. 25 1. Four Keys（4つの主要指標） l ソフトウェアデリバリーのパフォーマンスを客観的に測定するために定義された、以下の4つの指標群です。 これらは DORA（DevOps Research and Assessment）の研究の中核であり、「DORA メトリクス」とも呼ば れます。 l DevOps の成果や組織のソフトウェアデリバリー能⼒を測定‧⽐較するためのデファクトスタンダードとなり ました。 指標 内容 Deployment frequency (デプロイ頻度) 変更を本番環境に push する頻度。 Lead time for changes (変更のリードタイム) コードの変更を commit してからデプロイするまでの時間。 Change failure rate (変更失敗率) デプロイにより障害が発⽣し、すぐに対処する必要が⽣じる頻度。 Failed deployment recovery time (失敗デプロイの復旧時間) デプロイの失敗時に復旧にかかる時間。
26. 2. 速度（スループット）と安定性はトレードオフではない 26 l Four Keys を⽤いた⼤規模な調査‧分析から導き出された、本書の最も重要な発⾒の⼀つです。従来信じられ ていた「速度を上げると安定性が犠牲になる」という考えは誤りであり、⾼パフォーマンスな組織では、速度 と安定性は両⽴し、むしろ互いに強化し合う関係にあることがデータで⽰されました。 l DevOps の価値を強⼒に裏付け、多くの組織が開発‧運⽤プラクティスを⾒直す⼤きな動機となりました。 スピードより 品質を重視 品質より スピードを重視 スピードと品質 の両⽴ 壊れやすい 厄介な状態 高品質 低品質 遅い 速い
27. (出典) Infrastructure as Code, 2nd Edition , Figure 1-2. Speed and quality map to quadrants 27 2. 速度（スループット）と安定性はトレードオフではない スピードより 品質を重視 品質より スピードを重視 スピードと品質 の両⽴ 壊れやすい 厄介な状態 高品質 低品質 遅い 速い 右下の象限: 品質よりスピードを重視 • いわゆる「早く作って壊す」という考え⽅です。 スピードを重視して品質を犠牲にするチームは、 乱雑で脆弱なシステムを構築します。その粗悪な システムによって作業が遅くなり、左下の象限に 滑り落ちていきます。このやり⽅を続けてきたス タートアップの多くが「勢い」を失ったと嘆きま す。以前なら素早く対応できた簡単な変更が、シ ステムが複雑に絡み合っているために、今では何 ⽇も何週間もかかるようになっています。 左上の象限: スピードより品質を重視 • 「私たちは重要な仕事をしているのだから、きちんとやらなければならない」という考え⽅です。しか し、納期のプレッシャーにより「場当たり的な対応」を強いられます。重厚なプロセスが改善の障壁とな り、技術的負債は「既知の問題」リストとともに増⼤します。これらのチームは左下の象限に落ち込みま す。改善が困難なため、結果として低品質なシステムになってしまいます。失敗への対応として更にプロ セスを追加します。このプロセスが改善をより困難にし、脆弱性とリスクを増⼤させます。これがさらな る失敗とプロセスの追加を招きます。特にリスクに敏感な業界では、このように働く組織の多くの⼈々 が、これが普通だと思い込んでいます。
28. 3. 継続的デリバリー (Continuous Delivery / CD) の効果の証明 28 l Four Keys で測定されるパフォーマンス（速度と安 定性の両⽅）を⾼める上で、バージョン管理、⾃動 テスト、⾃動デプロイといった CD の具体的なプラ クティスが直接的に貢献することを科学的に証明し ました。 l 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
29. 4. 疎結合アーキテクチャの重要性 29 l チームが独⽴してテストやデプロイを⾏える「疎結合アーキテクチャ」（例：マイクロサービス）が、CD を 容易にし、デリバリーパフォーマンス向上に⼤きく寄与することを⽰しました。 l 技術的なアーキテクチャ選択が、組織の俊敏性や DevOps 実践の効果に直接的な影響を与えるという考え⽅を データで補強しました。 https://cloud.google.com/architecture/microservices-architecture-introduction?hl=ja,CC BY 4.0 Google
30. 5. リーン（Lean）の原則の適⽤ 30 l WIP 制限、⼩さなバッチでの作業、フィードバックループの短縮といったリーン原則が、ソフトウェアデリバ リーのフローを改善し、リードタイム短縮や品質向上に有効であることを⽰しました。 l DevOps とリーンの考え⽅の親和性を裏付け、プロセス改善の具体的な指針を提供しました。
31. 6. Westrum（ウェストラム）の組織⽂化類型 31 l 組織⽂化を情報の流れ⽅で分類し（病的、官僚的、⽣成的）、情報共有、協⼒、学習を促す「⽣成的 (Generative) ⽂化」が、Four Keys で測られるような⾼いパフォーマンスと強く関連していることを⽰しまし た。 l DevOps 成功における健全な組織⽂化の構築が不可⽋であることをデータで⽰し、その重要性を広く認識させ ました。 特性 病理的（権⼒重視） 官僚的（ルール重視） ⽣成的（成果重視） 組織の価値観・指向性 権⼒と統制が重視される 規則と⼿続きが重視される ミッションや成果が重視される 協⼒の姿勢 協⼒はほとんど⾒られない 必要最低限の協⼒が⾏われる 積極的に協⼒し合う⽂化がある 問題を報告した⼈への対応 報告した⼈が責められる（処罰され る） 報告しても関⼼を持たれず無視される 報告が歓迎され、問題対応⼒が育てら れる 責任の取り⽅ 責任を押しつけあう（逃げる） 形式上の責任だけを取る チームで責任を共有し、積極的に対応 する 部⾨間の連携（橋渡し） 他部署との連携は妨げられる 最低限は許容される 積極的に部⾨を越えて連携する 失敗への対応 スケープゴートを探して責任追及する 誰が悪かったかを調査する 失敗から学び、次に活かす姿勢がある 新しいアイデアへの対応 新しいことは否定され、抑え込まれる 新しいことは規則に反するとして懸念 される 新しいことに挑戦し、積極的に取り⼊ れる
32. 7. ケイパビリティモデル (Capability Model) 32 l CDプラクティス、アーキテクチャ、リーン原則、組織⽂化などを含むパフォーマンス向上に統計的に有意な影 響を与えることが特定された具体的な技術的‧プロセス的‧⽂化的な「能⼒（Capability）」の集合体です。 l Four Keys で現状を測定した後、具体的にどの能⼒を開発‧強化すればパフォーマンスが向上するのかを⽰す 実践的なガイドを提供し、組織が改善活動を進める上でのロードマップとなりました。 LeanとDevOpsの科学[Accelerate] 図A.1 本研究の全体の構成 を元に筆者が作成
33. 7. ケイパビリティモデル (Capability Model) 33
34. 7. ケイパビリティモデル (Capability Model) 34
35. 8. バーンアウト（燃え尽き症候群）と組織⽂化‧ツールの関係 35 l デプロイの苦痛、責任の押し付け合いといったネガティブな⽂化や、不⼗分なツールがバーンアウトのリスク を⾼める⼀⽅、⽣成的⽂化や適切なツールはそれを低減しうることを⽰唆しました。 l 従業員のウェルビーイング（幸福感）が、組織の持続的なパフォーマンスにとっても重要であるという視点を 提供しました。
36. LeanとDevOpsの科学: テクノロジーの戦略的活⽤が組織変⾰を加速する l この書籍がきっかけで有名になったり、その重要性 が広く認識されるようになったりした法則、概念 1. Four Keys（4つの主要指標） 2. 速度（スループット）と安定性はトレードオフではな い 3. 継続的デリバリー (Continuous Delivery / CD) の効果の 証明 4. 疎結合アーキテクチャの重要性 5. リーン（Lean）の原則の適⽤ 6. Westrum（ウェストラム）の組織⽂化類型 7. ケイパビリティモデル (Capability Model) 8. バーンアウト（燃え尽き症候群）と組織⽂化‧ツール の関係 l 原書タイトルは「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」 l 2018年3⽉出版、⽇本語版は2018年11⽉に出版。 l 迅速かつ⾼品質なデリバリを実施している組織 とそうでない組織の違いに関する研究結果を DORAがまとめている。 36
37. 「科学」とは何か？ 37
38. 昔ばなし l 私の35年のエンジニア⼈⽣を振り返ると、かなりの 時間「意味のない計測データ」の収集と加⼯に時間 を費やしたと思います。なぜなら、（その時の）品 質保証部⾨がプロダクトの「出荷」をなかなか認め てくれないからです。 l いま思い出すと、私は被告側の弁護⼠のようであ り、品質保証部⾨はまるで検察側のようでした。 l 裁判⻑は、事業部のトップです。 l 私はプロジェクトを終わらせるために、ありとあら ゆるデータを集めて「そのプロダクトは動く。（き っと）問題ないはずだ！」を弁護する必要がありま した。 38
39. バグ曲線 39 l QA部⾨がプロダクト出荷可否を判断する際に使っていた「バグ曲線」 l 横軸：テスト経過時間（時間、⽇数、またはテストケースの進捗） l 縦軸：発⾒された累計バグ数（累計または⽇別） l ⼤抵、左記のような「発⾒バグ数」の累計グラフを描き、 l 最初は急増 l 中盤で減速 l 最終的には「バグ収束傾向」が⾒られるか という減衰カーブをもって「品質は安定した」と判断する⼿法です。 l 「信頼度成⻑曲線」「PB曲線」などとも呼びます。
40. バグ曲線 40 l QA部⾨がプロダクト出荷可否を判断する際に使っていた「バグ曲線」 l 横軸：テスト経過時間（時間、⽇数、またはテストケースの進捗） l 縦軸：発⾒された累計バグ数（累計または⽇別） l ⼤抵、左記のような「発⾒バグ数」の累計グラフを描き、 l 最初は急増 l 中盤で減速 l 最終的には「バグ収束傾向」が⾒られるか という減衰カーブをもって「品質は安定した」と判断する⼿法です。 l 「信頼度成⻑曲線」「PB曲線」などとも呼びます。
41. バグ曲線 41 「まだ発⾒数が減少トレンドに⼊っていませ んね。このままでは出荷は難しいです。」 「検出率が横ばいです。テスト範囲に漏れが ないか、もう⼀度洗い出してください。」 「ピークアウトしていない以上、潜在バグが まだ相当数あると⾒ています。」
42. バグ曲線 42 「まだ発⾒数が減少トレンドに⼊っていませ んね。このままでは出荷は難しいです。」 「検出率が横ばいです。テスト範囲に漏れが ないか、もう⼀度洗い出してください。」 「ピークアウトしていない以上、潜在バグが まだ相当数あると⾒ています。」 これは科学的と⾔えるでしょうか︖
43. バグ曲線 43 1. 発⾒バグ数≠品質の保証 l バグが出なくなったのは「テスト網羅率が低いから」「疲弊したから」「検証が 表⾯的だったから」かもしれません。 l ⾒つかっていないだけで、潜在的なバグは依然として残っている可能性が⾼い。 2. 観測バイアス（Observer bias） l 観察者が期待した結果を得たいときに、その結果だけを意識しすぎてしまう⼼理 効果 l 観測されたバグ数は「テスト範囲」「テストの質」「発⾒⼒」に強く依存しま す。 l 広く深いテストを⾏わなければ「収束したように⾒える偽陽性」になるリスク。 3. 反復型開発や継続的デリバリーには不向き l 品質は⼯程で作り込むものであり、出⼝で測る時代ではありません。（アジャイ ルやCI/CDに限らず、品質管理とはそうであったはずなのですが…） l 「最後の検問」としてのバグ曲線は現代のスピードが求められる開発の流れには 合いません。 「まだ発⾒数が減少トレンドに⼊っていませ んね。このままでは出荷は難しいです。」 「検出率が横ばいです。テスト範囲に漏れが ないか、もう⼀度洗い出してください。」 「ピークアウトしていない以上、潜在バグが まだ相当数あると⾒ています。」
44. Tom DeMarco (1940 - ) 44 l ソフトウェア‧エンジニア l コンサルタント l 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
45. Tom DeMarco (1940 - ) 45 l ソフトウェア‧エンジニア l コンサルタント l DFD（data flow diagram）の⽣みの親 l 彼は、1982年の論⽂(*2)で次のような⾔葉を発しま した。 l これは、当時のエンジニアにとって、しばらくのあ いだ呪⾔となりました。 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.”
46. 「測定できないものは制御できない｣は誤りだった？ 46 l 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)
47. 「測定できないものは制御できない｣は誤りだった？ 47 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) l この論⽂は当時、Tom DeMarco ⾃⾝が「測定でき ないものは制御できない」は誤りだった、と認め た！ということで業界に衝撃が⾛りました。 l しかし、Tom DeMarco が本当に⾔いたかったこと は、次の⽂章に含まれていると私は思います。
48. 「測定できないものは制御できない｣は誤りだった？ 48 https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf l この論⽂は当時、Tom DeMarco ⾃⾝が「測定でき ないものは制御できない」は誤りだった、と認め た！ということで業界に衝撃が⾛りました。 l しかし、Tom DeMarco が本当に⾔いたかったこと は、次の⽂章に含まれていると私は思います。 しかし、先ほども申し上げたように、これは決して⾄ 上命題ではありませんでした。 もっと重要なのは、世界を変えるような、あるいは企 業やビジネスのあり⽅を変えるようなソフトウェアを 作るという「変⾰」です。 (Tom DeMarco, 2009)
49. 「測定できないものは制御できない｣は誤りだった？ 49 https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf l これはTom DeMarco本⼈のパラダイムシフトだった のではないでしょうか？ l DeMarcoが指摘したように、時代は「裁判ごっこ」 よりも、もっとエンドユーザーとの関係性を重視す る⽅向に確実に変化してきました。 l それが、リーンであり、アジャイルでありDevOpsな のだと思います。 しかし、先ほども申し上げたように、これは決して⾄ 上命題ではありませんでした。 もっと重要なのは、世界を変えるような、あるいは企 業やビジネスのあり⽅を変えるようなソフトウェアを 作るという「変⾰」です。 (Tom DeMarco, 2009)
50. 10年前 20年前 30年前 40年前 50年前 2018：!マイクロソフト、GitHub を 75 億ドルで買収 2001/2/11：" アジャイルソフ トウェア開発宣⾔ 2005/10 1991〜：#バブル崩壊「失われた◦◦年」 1988〜：!⽇本を含む諸外国へ「通商法スーパー301条」発動 ソフトウェア開発現代史年表 Ver2.06 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 S O F T W A R E REQUIREMENTS: ARE THEY REALLY A PROBLEM? T. E. Bell and T. A. Thayer T R W Defense and Space Systems Group Redondo Beach, California ,Keywords and Phrases Ballistic Missile Defense Requirements Requirements Problems Software Engineering Software Requirements Software Requirements Engineering Software Requirements Problems S R E M SREP Abstract Do requirements arise naturally from an obvious need, or do they come about only through diligent effort -- and even then contain problems? Data on two very different types of software requirements were analyzed to determine what kinds of problems occur and whether these problems are important. The results are dramatic: software requirements are important, and their problems are surprisingly similar across pro- jects. New software engineering techniques are clearly needed to improve both the development and statement of requirements. I. Introduction Identifying the cause of a problem in a software system is often very easy -- if the cause is a problem in code. Typically, identified coding problems result in clearly incorrect answers or in abnormal termina- tions of the software. Similarly, problems in a soft- ware system caused by deficiencies in design are often easy to identify from unexpected software operation or from extreme difficulty in maintaining and modifying the system. Problems in the system caused by defi- ciencies in software requirements, on the other hand, are often not identified at all, or are thought to be caused by bad design or limitations of computing tech- nology. If there are problems in developing require- ments, however, the software system meeting those requirements will clearly not be effective in solving the basic need, even if the causes of the problems are incorrectly identified. The Ballistic Missile Defense Advanced Technology Center (BMDATC) is sponsoring an integrated software development research program Ill to improve the tech- niques for developing correct, reliable B M D software. Reflecting the critical importance of requirements in the development process; the Software Requirements Engineering Program (SREP) has been undertaken as a part of this integrated program by T R W Defense and Space Systems Group* to examine and improve the quality of requirements. One of the first efforts in SREP has been to characterize the problems with requirements so that techniques can be developed to improve the situation. Instead of pursuing philosophical discussions about what the problems might be, we have undertaken empiri- cal studies to determine what the problems actually are. A limitation on the number of Ballistic Missile Defense (BMD) systems currently being developed (there is only one) has led us to examine both B M D and more common data processing systems to ensure that our results are characteristic of software requirements in general, rather than just one particular project. This paper reports on initial results that have set much of the direction pursued in the Software Requirements Engineering Methodology [2], the Require- ments Statement Language [3], and the Requirements Engineering and Validation System [4]. The initial efforts were oriented to determine the magnitude and characteristics of the problems, and to indicate what types of techniques could correct the problems. The empirical study of software problems is continuing in parallel with technology development so that the technology can be refined and tested for effectiveness in solving the identified problems. II, What are Software Requirements? One school of thought maintains that software requirements arise naturally, and that they are correct by definition. If these requirements merely state a basic need (e.g., "do payroll"),then that's all that is needed. On the other hand, if the requirements state each subroutine's detailed characteristics, then those are the required characteristics, and the implementer should not question them. Adherents to this school of thought have grown fewer and fewer as the software industry has gathered experience with this approach to developing software. When every requirement ranging in detail from needs statements to subroutine specifications is considered in the same way, the resulting systems tend to be seriously deficient. If coding personnel are assigned the task of implementing a system with only a needs statement, the critical phase of software design will likely be skipped -- with disasterous results. On the other end of the scale, if detailed subroutine speci- fications are accepted without ever having been *Under Contract DASG60-75-C-O022 61 リリース （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が実装された。 Netflixが⽇本に上陸(2015/9/2) ※!では2007/1にサービスイン 2017/10/14 2003/9/1 2002/11/8 2009：!Flickrのエンジニアである John AllspawとPaul Hammondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：" クラウドファースト‧クラウドネイティブ時代に突⼊ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤ ★ ピ ア ソ ン シ ョ ッ ク 2017/7/31 2009/11/27 2008/12/30 2023/11/28
51. 51 2018：!マイクロソフト、GitHub を 75 億ドルで買収 2001/2/11：" アジャイルソフ トウェア開発宣⾔ sionリリース 2000） （2005） GitHub リリース （2008） ugzilla リース 2000） Jira リリース （2002） AWS サービス開始 （2006） Jenkins 誕⽣ （2011） GitHub Actions （2018） ChatGPT ⼀般公開 （2022/11/30） GitHub Copilot （2021/6/29） Azure サービス開始 （2010） 2009〜2020：" 第⼆次ブラウザ戦争 Google Chromeの躍進、 Internet Explorerの衰退 （2018） （2004） Google Cloud サービス開始 （2008） 欧州の⾃動⾞メーカ が中⼼となって公開（2005） （2011） （2006） （2004） ⽶国防総省(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） Gemini 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 Hammondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：" クラウドファースト‧クラウドネイティブ時代に突⼊ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤
52. 科学とは何か？ 52 l 天⽂学者であり⼩説家でもあった、20世紀屈指の科 学者カール‧セーガンは科学について次のような表 現をしていました。 Sagan in 1980 「科学は、思考の⽅法であり、 知識の集積ではない」 “Science is a way of thinking much more than it is a body of knowledge.”
53. 科学とは何か？ 53 科学とは「なぜだろう？」という疑問に対し て、実験と観察を重ねながら、誰でも同じ結 果を得られる答えを⾒つけ出す取り組み、と ⾔えます。
54. あるカレー店の⼈気の秘密 54 l あるカレー店の⼈気の秘密を科学的に考えてみまし ょう。 l 「このカレーが美味しいのはなぜか？」という問い に対して― l 「シェフの腕が良いから」：個⼈的な感想 l 「創業100年の伝統の味だから」：⾔い伝え これらは、科学的な説明とはいえません。
55. あるカレー店の⼈気の秘密 55 l あるカレー店の⼈気の秘密を科学的に考えてみまし ょう。 l 「このカレーが美味しいのはなぜか？」という問い に対して― l 「シェフの腕が良いから」：個⼈的な感想 l 「創業100年の伝統の味だから」：⾔い伝え これらは、科学的な説明とはいえません。 l 科学的なアプローチでは、次のような調査と実験を ⾏います。 l このような過程を経て、「このスパイスの配合で、 この温度で30分煮込むと、8割以上のお客さんが美味 しいと感じるカレーができる」と⾔った、誰でも確 認できる答えにたどり着けるのです。 ü 100⼈のお客さんに同じ条件で⾷べてもらい、評価を集める ü スパイスの配合を少しずつ変えて、味の変化を測定する ü 調理時間や⽕加減を細かく記録し、最適な条件を探る ü 異なる調理⼈が同じレシピで作っても、同じ味になるか確 認する
56. 「科学的リサーチ」⽅法とは 56 l 科学的リサーチとは、現象を体系的に調査し、新しい発⾒や理論を導き出す⼿法です。観察から始まり、概念 化、測定可能な変数への置き換え、モデル化という段階を経て、客観的なデータに基づいた結論を導きます。 向後, 千春. (2016). 18歳からの「⼤⼈の学び」基礎講座: 学ぶ, 書く, リサーチする, ⽣きる. 北⼤路書房. 図3-3に筆者が加筆
57. 科学的リサーチプロセスは次の4段階で進みます 57 向後, 千春. (2016). 18歳からの「⼤⼈の学び」基礎講座: 学ぶ, 書く, リサーチする, ⽣きる. 北⼤路書房. 図3-3に筆者が加筆 Step 説明 1 現象の観察 「DevOpsの実践は本当にビジネスの成果に繋 がるのか？」といった問いからDORAの研究が 始まりました。 2 概念の特定 DORAは、継続的デリバリー、継続的インテグ レーション、⾃動化テストの実施などを概念 として特定しました。 3 変数への変換 概念を測定可能な形に変換します。例えば、 デプロイ頻度、変更リードタイム、障害復旧 時間、変更失敗率などの具体的指標として定 義します。 4 モデルの構築 収集したデータを統計的に分析し、相関また は因果関係を明らかにします。DORAの研究で は、⾃動化テストの実施が変更リードタイム を短縮することや、チームの独⽴性がサービ スの信頼性向上につながることを実証しまし た。
58. 科学的リサーチプロセスは次の4段階で進みます 58 Step 説明 1 現象の観察 「DevOpsの実践は本当にビジネスの成果に繋 がるのか？」といった問いからDORAの研究が 始まりました。 2 概念の特定 DORAは、継続的デリバリー、継続的インテグ レーション、⾃動化テストの実施などを概念 として特定しました。 3 変数への変換 概念を測定可能な形に変換します。例えば、 デプロイ頻度、変更リードタイム、障害復旧 時間、変更失敗率などの具体的指標として定 義します。 4 モデルの構築 収集したデータを統計的に分析し、相関また は因果関係を明らかにします。DORAの研究で は、⾃動化テストの実施が変更リードタイム を短縮することや、チームの独⽴性がサービ スの信頼性向上につながることを実証しまし た。 バグ曲線は 科学的と⾔えるでしょうか︖
59. 科学的リサーチプロセスは次の4段階で進みます 59 Step 説明 バグ曲線で品質を⾒る場合 1 現象の観察 「DevOpsの実践は本当にビジネスの成果に繋 がるのか？」といった問いからDORAの研究が 始まりました。 ✔ 「バグが時間経過とともに減るかを観察」 → 観察はしている。ただし問いが「観察⽌まり」で深掘りしない。 2 概念の特定 DORAは、継続的デリバリー、継続的インテグ レーション、⾃動化テストの実施などを概念 として特定しました。 △ 「バグ数減少＝品質改善」 という単⼀概念に依存してはだめ → 他の成功要因（テスト網羅率、カバレッジ、リスク分析など） を概念として捉えていない。 3 変数への変換 概念を測定可能な形に変換します。例えば、 デプロイ頻度、変更リードタイム、障害復旧 時間、変更失敗率などの具体的指標として定 義します。 △ 「累積バグ数」や「検出ペース」だけで判断してはだめ → 指標はあるが、⾮常に限定的で不⼗分。リスクの分布や バグの深刻度など多変数で⾒る必要がある。 4 モデルの構築 収集したデータを統計的に分析し、相関また は因果関係を明らかにします。DORAの研究で は、⾃動化テストの実施が変更リードタイム を短縮することや、チームの独⽴性がサービ スの信頼性向上につながることを実証しまし た。 ？ データの観察はするが、相関または因果関係まで解明できない。 → なぜバグが減ったのか、他の変数がどう影響したのか検証しない （できない）まま「減ったから OK」としがち。
60. 科学的リサーチプロセスは次の4段階で進みます 60 Step 説明 バグ曲線で品質を⾒る場合 1 現象の観察 「DevOpsの実践は本当にビジネスの成果に繋 がるのか？」といった問いからDORAの研究が 始まりました。 ✔ 「バグが時間経過とともに減るかを観察」 → 観察はしている。ただし問いが「観察⽌まり」で深掘りしない。 2 概念の特定 DORAは、継続的デリバリー、継続的インテグ レーション、⾃動化テストの実施などを概念 として特定しました。 △ 「バグ数減少＝品質改善」 という単⼀概念に依存してはだめ → 他の成功要因（テスト網羅率、カバレッジ、リスク分析など） を概念として捉えていない。 3 変数への変換 概念を測定可能な形に変換します。例えば、 デプロイ頻度、変更リードタイム、障害復旧 時間、変更失敗率などの具体的指標として定 義します。 △ 「累積バグ数」や「検出ペース」だけで判断してはだめ → 指標はあるが、⾮常に限定的で不⼗分。リスクの分布や バグの深刻度など多変数で⾒る必要がある。 4 モデルの構築 収集したデータを統計的に分析し、相関また は因果関係を明らかにします。DORAの研究で は、⾃動化テストの実施が変更リードタイム を短縮することや、チームの独⽴性がサービ スの信頼性向上につながることを実証しまし た。 ？ データの観察はするが、相関または因果関係まで解明できない。 → なぜバグが減ったのか、他の変数がどう影響したのか検証しない （できない）まま「減ったから OK」としがち。 バグ曲線は観察の域を出ず、「科学的リサーチプロセスとしては不⼗分」（モデル化が不⼗分） 複数の指標を組み合わせた多⾓的な分析が不可⽋
61. 科学的リサーチプロセスは次の4段階で進みます 61 向後, 千春. (2016). 18歳からの「⼤⼈の学び」基礎講座: 学ぶ, 書く, リサーチする, ⽣きる. 北⼤路書房. 図3-3に筆者が加筆 Step 説明 1 現象の観察 「DevOpsの実践は本当にビジネスの成果に繋 がるのか？」といった問いからDORAの研究が 始まりました。 2 概念の特定 DORAは、継続的デリバリー、継続的インテグ レーション、⾃動化テストの実施などを概念 として特定しました。 3 変数への変換 概念を測定可能な形に変換します。例えば、 デプロイ頻度、変更リードタイム、障害復旧 時間、変更失敗率などの具体的指標として定 義します。 4 モデルの構築 収集したデータを統計的に分析し、相関また は因果関係を明らかにします。DORAの研究で は、⾃動化テストの実施が変更リードタイム を短縮することや、チームの独⽴性がサービ スの信頼性向上につながることを実証しまし た。
62. 62 DORAの研究では、科学的アプローチによってDevOpsの成 功要因を明らかにしました。 個⼈の経験や直感を超えて、数多くの組織のデータを分析 し、客観的な証拠に基づいて「何が効果的なのか」を⽰した のです。これは単なる成功事例の集積ではなく、科学的リサ ーチによって検証された信頼性の⾼い知⾒です。
63. 定量的データと統計分析がもたらす信頼性 63 l DORA Reportで⽤いられる科学的アプローチに対し て、「都合の良いデータ解釈をしているのではない か」という批判を⽬にすることがあります。 l しかし、この批判は科学的リサーチの本質を⼗分に 理解していないことから⽣じている可能性がありま す。科学的リサーチとは、単にデータを収集し結果 を得ることではなく、現象を客観的に理解し、実証 可能な⽅法で結果を導き出す「⽅法論」そのもので す。 l この考え⽅は、DORAの研究において左記のように 具体化されています。 n 思考の⽅法の適⽤ l DORAの研究では、特定の仮説（例えば「継続的デリバリーはパ フォーマンス向上に寄与する」）を⽴て、それを証明または反 証するために厳密な⼿法でデータを収集‧分析しています。こ れは、科学的な「疑う」姿勢と「検証する」姿勢の両⽴です。 n 透明性と再現性 l 測定⽅法や分析⼿順を厳密に⽂書化し、他の研究者が追試可能 な形で公開しています。これは、科学が単なる知識の蓄積では なく、「共有されるべきプロセス」であることを象徴していま す。 n 実践への応⽤ l 科学の思考⽅法をもとに導き出された成果が、現場での実践を 通じて再び検証されています。たとえば、継続的デリバリーや テストの⾃動化が現実の組織で具体的な効果をもたらすことが ⽰されています。
64. 定量的データと統計分析がもたらす信頼性 64 l DORAの研究は10年にわたり、理論と実践の両⾯で成果を⽰してきました。カール‧セーガンが述べたよう に、科学とは「知識の集積」ではなく「より良い問いを⽴て、より深く理解するための思考の道具」です。 l DORAはこの科学的アプローチを⽤いて、LeanやDevOpsの成功要因を信頼性の⾼い⽅法論として確⽴し、現 場の改善や組織変⾰に直接応⽤できる形で提供しています。毎年のクラスター分析結果の微細な変化も、この ような継続的なデータ分析の重要性を⽰しているのです。 とはいえ、最初から科学的なデータ分析が出来ていたわけではありません…… DORAの10年を、順を追って振り返ってみましょう
65. DORAレポートの10年の変遷 65
66. DORA Report 10年の変遷 l 2024 DORA Reportでは、 "A decade with DORA"（DORAと共に過ごした10年）という章があります。 DevOpsの起源から、State of DevOps Report誕⽣の背景、今⽇に⾄るまでの歴史が書かれています。 l 私は、その説明内容と書籍「LeanとDevOpsの科学[Accelerate]」に書かれている内容から、これまでの変遷 を1枚の画にまとめてみました。 66
68. State of DevOps Report のはじまり l 2011年、Puppet Labsで働いていたAlanna BrownはDevOpsについてより深く理解するための調査を開始しま した。この調査は、「'DevOps'的な働き⽅がITにおける新しいビジネスの⽅法として台頭している」というこ とを裏付ける助けとなりました。 l この調査の成功をベースに、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/ ） 68
69. State of DevOps Report のはじまり l Gene KimはTripwire, Inc.の創業者兼CTOとして13年間務めたあと、IT Revolutionを創業し出版活動、 DevOpsコミュニティへの貢献に尽⼒する⼈物でした。 l 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/ ） 69
70. l Gene Kimから応援を頼まれる形でJez Humbleも参画 l 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 ） 70
71. State of DevOps Report のはじまり 71 l Alanna Brown、Gene Kim、Jez Humbleらは、世界 の組織から4,000件の回答を集め、分析を⾏った。こ の種の調査では当時最⼤規模でした。 l 2013年 Puppet LabsとGene Kim⽒が率いるIT Revolution Pressが共同で、最初のState of DevOps Reportを発⾏しました。
72. なぜ2013年版はカウントされないのか？ 72 l しかし、ご覧の通り「この10年」の中に2013年版は含まれません。それはなぜか？ l ⼀⾔で⾔えば「調査⽅法が違う」からです。現在の統計的アプローチが取られたのは2014年以降となります。
73. 2013 State of DevOps Report 73 l 2013年当時のPuppet社は、ITインフラストラクチャ の⾃動化を⽀援するソフトウェアを開発‧提供して いる会社でした。 l その中⼼的なプロダクトは Puppet Enterpriseであ り、これはサーバーやクラウド環境、ネットワーク デバイスなどの管理を効率化し、DevOpsやインフラ 管理の⾃動化を推進するツールでした。 l 2013 State of Devops Report は、当時あまり知られ ていなかったDevOpsという概念を広め、Puppet Enterpriseの市場を開拓することが主な⽬的だった と思われます。 l 実際、2013年版の調査による【主要な発⾒】は、や や意図的な印象を受けます。 n 主要な発⾒ l DevOps導⼊状況 • 回答者の63%がDevOpsを導⼊（2011年から26%増加） • 導⼊期間が⻑いほど、⾼パフォーマンス達成の可能性が5倍 に上昇 l ⾼パフォーマンスを実現する共通実践 • バージョン管理システムの使⽤（89%） • コードデプロイの⾃動化（82%） l DevOpsスキルの需要 • コーディング/スクリプティング（84%） • コミュニケーションスキル（60%） • プロセス再構築スキル（56%）
74. 2013 State of DevOps Report 74 l また、このレポートでは、後のDORAメトリクスの 基礎となる4つの主要指標、デプロイ頻度‧変更のリ ードタイム‧変更の失敗率‧復旧までの平均時間、 いわゆるFour Keysが登場します。 l しかし、現在の観点とは異なる分析結果でした。下 記に、2013 State of DevOps Reportのパフォーマン ス指標の解説と、左記にグラフを転載します。 n ご覧の通り、4つの指標はそれぞれ、「DevOpsを導⼊しているか否か」で期間 分類されているのです。 n このレポートは回答者の多くが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ヶ⽉以上）
77. l 2014年、State of Devops Report に⼤きな転機が訪れます。 l 当時ユタ州⽴⼤学ハンツマンビジネススクールの教授であったDr. Nicole Forsgren（ニコール‧フォースグレ ン博⼠）の参画です。 l 彼⼥は、ITインパクト、ナレッジマネジメント、ユーザー体験の専⾨家でした。 2014 State of DevOps Report Nicole Forsgren, PhD（ニコール‧フォースグレン博⼠） ニコール‧フォースグレン博⼠は、Microsoft Research のパートナーです。シンゴ賞を受賞した著書 『Accelerate』の著者であり、これまでで最⼤規模の DevOps 調査の主任研究者として広く知られて います。これまでに、起業家（Google への売却を経験）、⼤学教授、パフォーマンスエンジニア、 システム管理者としての経歴を持ちます。彼⼥の研究は複数の査読付き学術誌にも掲載されていま す。 （参照： https://itrevolution.com/author/nicole-forsgren/ ） 77
78. 2014 State of DevOps Report l 「LeanとDevOpsの科学[Accelerate] 」の「謝辞」に は、Nicole Forsgrenの次のようなコメントがありま す。 l この謝辞から読み取れるように、Dr. Nicole Forsgren は2014年以降のState of Devops Reportに 科学的厳密性をもたらした重要な⼈物です。それま での調査⼿法に対して建設的なフィードバックを し、その結果、2014年のレポートから、より体系的 で科学的なリサーチがもたらされます。 l そして、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（アラナ‧ブラウン） 78
79. 2014 State of DevOps Report 79 l Dr. Nicole Forsgrenの参加は、リサーチプログラム に科学的な厳密さをもたらしました。 l このことで、最初のFour Keysは統計学的有意（＝確 率的に偶然とは考えにくく、意味があると考えられ る）が検証されるようになります。 l このことで、Change Failure Rate（変更失敗率） は、他の3つの指標とは有意な相関が⾒られなかった ため、ITパフォーマンスの定義から除外されていま す。 l つまり、最初はFour Keysじゃなかったし、Eliteも居 なかったのです。 l ⼀⽅で「発⾒」もありました。 n 2014 パフォーマンス指標 n 発⾒ 指標 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）
80. 2014 State of DevOps Report 80 l 2014 State of Devops Reportは、Nicole Forsgrenの「科学的リサーチ」によって次第にデータは説得⼒のあ るものに変わっていきました。 ところが、ここにきて⼤きな壁が⽴ちふさがります。 l それが、ソフトウェア界の巨匠Martin Fowler（マーティン‧ファウラー）でした。
81. l ソフトウェア設計やアジャイル開発の分野で世界的に影響⼒を持つスーパーエンジニアです。 l 「マイクロサービス」の提唱者であり、彼の著書『リファクタリング』は、コードの品質を向上させる⽅法論 としてエンジニアのバイブルとなりました。 巨匠の不満 Martin Fowler（マーティン‧ファウラー） マーティン‧ファウラーは、著者であり講演者であり、ソフトウェアに⻑年にわたって有⽤な機能 を柔軟に追加できるよう、どのように設計すべきかに強い関⼼を持っています。 これまでに『リファクタリング』や『エンタープライズアプリケーションアーキテクチャパター ン』など、ソフトウェア開発に関する多くの書籍を執筆してきました。2001年には「アジャイルソ フトウェア開発宣⾔」の策定に参加し、アジャイルソフトウェア開発の先駆者のひとりとしても知 られています。世界中のソフトウェアカンファレンスで講演を⾏う⼀⽅で、マサチューセッツの⾃ 宅で記事の執筆に取り組む時間がもっとも幸せです。⾃⾝のウェブサイト「martinfowler.com」で は、実践者向けの詳しい技術記事を発信しています。 （参照： https://www.thoughtworks.com/profiles/leaders/martin-fowler ） 81
82. 巨匠の不満 Alistair CockburnのFacebookより(https://www.facebook.com/TotherAlistair/posts/10156214284634035) 82
83. 巨匠の不満 83 l Martin Fowler 本⼈によって、書籍「LeanとDevOps の科学[Accelerate] 」*1の冒頭では、次のようなエ ピソードが寄稿されています。 l なかなか苛烈な⽂章です。 本書に寄せて 2、3年前、あるレポートを読んでいたら、こんな⽂に出くわ したーー「今や我々は⾃信をもって断⾔できる。IT部⾨のパフ ォーマンスの⾼さには、⽣産性、収益性、そして市場占有率 を⾼める効果があり、組織全体の業績と⾼い相関をもつ」。 この⼿のレポートは即、ゴミ箱に投げ捨てるのが私の通常の 反応である。⼤抵は「科学」を装ったたわごとにすぎないか らだ。しかしそのとき読んでいたのは『2014 State of DevOps Report （DevOpsの現況に関するレポート2014年版）』であっ たため、私はためらった。著者の1⼈が私の同僚であり友⼈で もあるJez Humble⽒で、私に負けず劣らずこの種のたわごと を嫌う⼈物であることを知っていたからだ（もっとも、正直 ⾔ってゴミ箱に投げ捨てなかった理由はもう1つある。あのレ ポートはiPadで読んでいたのだった）。
84. 巨匠の不満 84 l Martinは、さっそくNicole ForsgrenとJez Humble と3⼈で話す機会（電話会議）を作ります。 Forsgren⽒は根気強く丁寧に研究の論拠を説明してくれた。そ の説明は、そういった調査‧分析⽅法には詳しくない私にと っても⼗分な説得⼒があり、通常をはるかに上回るレベルの （学術論⽂で発表される研究さえ凌ぐ）厳密な分析が⾏われ ている、ということが理解できた。 そのため、私はその後もState of DevOpsレポートを興味深く 読み続けていたが、その⼀⽅で不満も募ってきた。どの年度 のレポートも研究の成果を公表するばかりで、Forsgren⽒が 電話で私にしてくれたような説明が⼀切ないのである。おか げでレポートの信頼性が⼤きく損なわれていた。推測だけに 基づいた研究ではないことを⽰す根拠がほぼ皆無なのだ。 そこで私も含めて内情を知る者が3⼈を説得し、研究の調査‧ 分析⼿法を紹介‧解説する本を執筆してもらった。
85. 巨匠の不満から誕⽣した"LeanとDevOpsの科学" 85 l このように、Martin Fowlerの不満があったからこそ「LeanとDevOpsの科学[Accelerate] 」が存在すると⾔っ ても過⾔ではありません。 l 「LeanとDevOpsの科学[Accelerate] 」が技術者からすると慣れない⽂体で書かれているのは、あれが技術書 ではなく「研究の調査‧分析⼿法を紹介‧解説する本」だからだと思われます。統計⼿法の解説本なのです。 l 実際に書籍が出版されるのは、あの電話会議から4年後（2018年）になります…
88. 2015 State of Devops Report l 前年と⽐べ分析に苦慮していた様⼦が伺えます。 l まず、Change Failure Rate（変更失敗率）は、あい かわらずITパフォーマンスの主要な構成要素 （construct）からは除外されています。のちの 「LeanとDevOpsの科学[Accelerate] 」には次のよう な記述がありました。 l ちょっと分かりにくい⽂章なので整理すると、ソフ トウェアデリバリーのパフォーマンスを正確に測定 するには、 l 「リードタイム」「リリース頻度」「サービス復旧まで の所要時間」の3つの尺度だけなら信頼性⾼く妥当な評 価ができる。 l 変更失敗率も重要な指標であり、これら3つの尺度と強 い相関はある。が、独⽴した構成概念として扱うには適 していない。 l 「変更失敗率」は予測しずらい異質な指標であり、 分析や予測の際には補⾜的な要素として考慮する必 要がありそうです。昨年の2024 DORA Reportでも 「変更失敗率」はイレギュラーな結果を残していま す（後ほど触れます）。 クラスター分析では「ハイパフォーマー」「ローパフォーマー」「ミ ディアムパフォーマー」のいずれの集団についても、この4つの尺度 で有意な分類と差別化（チームのカテゴリー化）が⾏えた。ところ が、この4つの尺度で1つの構成概念を得ようとすると問題が⽣じた。 妥当性と信頼性を検証するための統計的仮説検定にパスしないのであ る。分析の結果、リードタイム、リリース頻度、サービス復旧までの 所要時間の3つの尺度だけを使えば、妥当で信頼性のある構成概念が 得られることが判明した。 88
89. 2015 State of Devops Report 89 l 2015年のパフォーマンス‧クラスターはSuper High、High、Medium、Lowに分けられ、それぞれ「4段階の スピード」で集計されました。しかし、パフォーマンスの傾向を特定するまでには⾄っていません。
90. DORAの設⽴へ 90
93. DORAの設⽴へ l 2016年10⽉、Nicole ForsgrenとJez HumbleはDevOps Research and Assessment (DORA)を⽴ち上げます。 これは、誰からの⽀援（投資）を受けずに⽴ち上げた会社だったそうです。 l そもそも、なぜ会社設⽴に⾄ったのか？Jez Humbleのブログ* をもとに解き明かしたいと思います。 Nicole Forsgren, PhD Jez Humble * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667 93
94. DORAの設⽴へ 94 l State of DevOps Reportの研究は地道に成果を上げ始め、その取り組みが実際のビジネス成果を改善すること も証明し、多くの企業からデータを集めることにも成功していました。 l ⼀⽅で、組織が抱える2つの⼤きな問題も⾒えてきたそうです。その2つとは―
95. 95 n ビッグバン型変⾰の問題 多くの組織が陥った失敗パターンの代表例が「ビッグ バン型変⾰」でした。これは、アジャイル⼿法と成熟度 モデルを⼀度に導⼊しようとしたアプローチです。「ど んな組織にも当てはまるテンプレート」として導⼊され たものの、実際の組織の状況とは相容れないことが多 く、持続可能な改善にはなかなかつながりませんでし た。 特に⼤きな問題は、現場で働く実務者の関与が不⾜し ていたことでした。⽇常業務の中で原則や実践を少しず つ試しながら改善していくプロセスが⽋如しており、こ のことが変⾰の成功率を⼤きく下げる要因となっていま した。 n コンサルタントモデルの問題 多くの組織は改⾰のためにコンサルタントを採⽤し、 現状分析と改善策の提案を求めました。しかし、このア プローチにも課題がありました。コンサルタントが話を 聞けるのは、実際に作業を⾏っている現場の⼈々のほん の⼀握りに過ぎません。さらに、改善提案はコンサルタ ント個⼈の専⾨知識に⼤きく依存することになり、客観 的に進捗状況を追跡することも難しくなりました。 実は、このやり⽅はコンサルティング会社にとっても 理想的なビジネスモデルとは⾔えませんでした。なぜな ら、優秀な⼈材を現場に配置しなければならないにもか かわらず、継続的な仕事が保証されているわけではなか ったからです。また、このアプローチは規模の拡⼤も難 しく、ビジネスとしての成⻑にも限界がありました。 * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667
96. 96 n ビッグバン型変⾰の問題 多くの組織が陥った失敗パターンの代表例が「ビッグ バン型変⾰」でした。これは、アジャイル⼿法と成熟度 モデルを⼀度に導⼊しようとしたアプローチです。「ど んな組織にも当てはまるテンプレート」として導⼊され たものの、実際の組織の状況とは相容れないことが多 く、持続可能な改善にはなかなかつながりませんでし た。 特に⼤きな問題は、現場で働く実務者の関与が不⾜し ていたことでした。⽇常業務の中で原則や実践を少しず つ試しながら改善していくプロセスが⽋如しており、こ のことが変⾰の成功率を⼤きく下げる要因となっていま した。 n コンサルタントモデルの問題 多くの組織は改⾰のためにコンサルタントを採⽤し、 現状分析と改善策の提案を求めました。しかし、このア プローチにも課題がありました。コンサルタントが話を 聞けるのは、実際に作業を⾏っている現場の⼈々のほん の⼀握りに過ぎません。さらに、改善提案はコンサルタ ント個⼈の専⾨知識に⼤きく依存することになり、客観 的に進捗状況を追跡することも難しくなりました。 実は、このやり⽅はコンサルティング会社にとっても 理想的なビジネスモデルとは⾔えませんでした。なぜな ら、優秀な⼈材を現場に配置しなければならないにもか かわらず、継続的な仕事が保証されているわけではなか ったからです。また、このアプローチは規模の拡⼤も難 しく、ビジネスとしての成⻑にも限界がありました。 * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667
97. 97 n ビッグバン型変⾰の問題 多くの組織が陥った失敗パターンの代表例が「ビッグ バン型変⾰」でした。これは、アジャイル⼿法と成熟度 モデルを⼀度に導⼊しようとしたアプローチです。「ど んな組織にも当てはまるテンプレート」として導⼊され たものの、実際の組織の状況とは相容れないことが多 く、持続可能な改善にはなかなかつながりませんでし た。 特に⼤きな問題は、現場で働く実務者の関与が不⾜し ていたことでした。⽇常業務の中で原則や実践を少しず つ試しながら改善していくプロセスが⽋如しており、こ のことが変⾰の成功率を⼤きく下げる要因となっていま した。 n コンサルタントモデルの問題 多くの組織は改⾰のためにコンサルタントを採⽤し、 現状分析と改善策の提案を求めました。しかし、このア プローチにも課題がありました。コンサルタントが話を 聞けるのは、実際に作業を⾏っている現場の⼈々のほん の⼀握りに過ぎません。さらに、改善提案はコンサルタ ント個⼈の専⾨知識に⼤きく依存することになり、客観 的に進捗状況を追跡することも難しくなりました。 実は、このやり⽅はコンサルティング会社にとっても 理想的なビジネスモデルとは⾔えませんでした。なぜな ら、優秀な⼈材を現場に配置しなければならないにもか かわらず、継続的な仕事が保証されているわけではなか ったからです。また、このアプローチは規模の拡⼤も難 しく、ビジネスとしての成⻑にも限界がありました。 * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667
98. DORAの設⽴へ l これらの問題認識から、NicoleとJezは、アルゴリズ ムを活⽤して組織の改善領域を特定し、具体的な改 善戦略を提案できるプラットフォームの必要性を認 識しました。 l 特に注⽬すべきは、変⾰や改善を「どこから始める べきか？」という組織からの本質的な問いに、デー タとアルゴリズムを⽤いて客観的に答えられる仕組 みを作ろうとした点です。 l 2016年にDORAは設⽴されました。同年10⽉には Nicoleがフルタイムでの経営を開始し、DevOps Enterprise Summitでは最初の顧客となったCapital One（⽶⼤⼿⾦融持株会社）とともに、DORAの正式 な「お披露⽬」が⾏われています。 * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667 この話題が出た時、Nicoleの⽬が輝きました。 「ねえ、もしソフトウェアデリバリーのプロセス全体 から何⼗⼈もの⼈々のデータがあれば、その問いに答 えられるはずだよ。どのアルゴリズムを使うべきか、 それをどう修正すべきかも分かる。これは制約理論 （TOC）の問題に過ぎない。最も賢く効率的に戦略を ⽴てる⽅法を伝えられる。」 私は⼀瞬考えて⾔いました。 「待って、本当に？それならば作ってみよう！」そし て、そこからDORAは誕⽣したのです。私たちは翌⽇ からモックアップの作成に取り掛かりました。 Jez Humbleのブログ*から
99. DORAの設⽴へ l これらの問題認識から、NicoleとJezは、アルゴリズ ムを活⽤して組織の改善領域を特定し、具体的な改 善戦略を提案できるプラットフォームの必要性を認 識しました。 l 特に注⽬すべきは、変⾰や改善を「どこから始める べきか？」という組織からの本質的な問いに、デー タとアルゴリズムを⽤いて客観的に答えられる仕組 みを作ろうとした点です。 l 2016年にDORAは設⽴されました。同年10⽉には Nicoleがフルタイムでの経営を開始し、DevOps Enterprise Summitでは最初の顧客となったCapital One（⽶⼤⼿⾦融持株会社）とともに、DORAの正式 な「お披露⽬」が⾏われています。 * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667 この話題が出た時、Nicoleの⽬が輝きました。 「ねえ、もしソフトウェアデリバリーのプロセス全体 から何⼗⼈もの⼈々のデータがあれば、その問いに答 えられるはずだよ。どのアルゴリズムを使うべきか、 それをどう修正すべきかも分かる。これは制約理論 （TOC）の問題に過ぎない。最も賢く効率的に戦略を ⽴てる⽅法を伝えられる。」 私は⼀瞬考えて⾔いました。 「待って、本当に？それならば作ってみよう！」そし て、そこからDORAは誕⽣したのです。私たちは翌⽇ からモックアップの作成に取り掛かりました。 Jez Humbleのブログ*から
100. 100 30年前 40年前 50年前 1974 1976 1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1975 1977 1986 1995 1994/10/31 1989 1987 1970 1989/02/01 1982 1979 1992/3/13 1996/4/1 1996/8 1979 1978 1972 ソ フ ト ウ ェ ア 関 連 の 論 ⽂ ‧ ⽂ 献 PC/AT互換機が誕⽣（1981〜） DynaBook （1994〜） ICT の 1990/10/10 1978/5/1 1988/3/1 1984 1995/10/1 1976 S O F T W A R E REQUIREMENTS: ARE THEY REALLY A PROBLEM? T. E. Bell and T. A. Thayer T R W Defense and Space Systems Group Redondo Beach, California ,Keywords and Phrases Ballistic Missile Defense Requirements Requirements Problems Software Engineering Software Requirements Software Requirements Engineering Software Requirements Problems S R E M SREP Abstract Do requirements arise naturally from an obvious need, or do they come about only through diligent effort -- and even then contain problems? Data on two very different types of software requirements were analyzed to determine what kinds of problems occur and whether these problems are important. The results are dramatic: software requirements are important, and their problems are surprisingly similar across pro- jects. New software engineering techniques are clearly needed to improve both the development and statement of requirements. I. Introduction Identifying the cause of a problem in a software system is often very easy -- if the cause is a problem in code. Typically, identified coding problems result in clearly incorrect answers or in abnormal termina- tions of the software. Similarly, problems in a soft- ware system caused by deficiencies in design are often easy to identify from unexpected software operation or from extreme difficulty in maintaining and modifying the system. Problems in the system caused by defi- ciencies in software requirements, on the other hand, are often not identified at all, or are thought to be caused by bad design or limitations of computing tech- nology. If there are problems in developing require- ments, however, the software system meeting those requirements will clearly not be effective in solving the basic need, even if the causes of the problems are incorrectly identified. The Ballistic Missile Defense Advanced Technology Center (BMDATC) is sponsoring an integrated software development research program Ill to improve the tech- niques for developing correct, reliable B M D software. Reflecting the critical importance of requirements in the development process; the Software Requirements Engineering Program (SREP) has been undertaken as a part of this integrated program by T R W Defense and Space Systems Group* to examine and improve the quality of requirements. One of the first efforts in SREP has been to characterize the problems with requirements so that techniques can be developed to improve the situation. Instead of pursuing philosophical discussions about what the problems might be, we have undertaken empiri- cal studies to determine what the problems actually are. A limitation on the number of Ballistic Missile Defense (BMD) systems currently being developed (there is only one) has led us to examine both B M D and more common data processing systems to ensure that our results are characteristic of software requirements in general, rather than just one particular project. This paper reports on initial results that have set much of the direction pursued in the Software Requirements Engineering Methodology [2], the Require- ments Statement Language [3], and the Requirements Engineering and Validation System [4]. The initial efforts were oriented to determine the magnitude and characteristics of the problems, and to indicate what types of techniques could correct the problems. The empirical study of software problems is continuing in parallel with technology development so that the technology can be refined and tested for effectiveness in solving the identified problems. II, What are Software Requirements? One school of thought maintains that software requirements arise naturally, and that they are correct by definition. If these requirements merely state a basic need (e.g., "do payroll"),then that's all that is needed. On the other hand, if the requirements state each subroutine's detailed characteristics, then those are the required characteristics, and the implementer should not question them. Adherents to this school of thought have grown fewer and fewer as the software industry has gathered experience with this approach to developing software. When every requirement ranging in detail from needs statements to subroutine specifications is considered in the same way, the resulting systems tend to be seriously deficient. If coding personnel are assigned the task of implementing a system with only a needs statement, the critical phase of software design will likely be skipped -- with disasterous results. On the other end of the scale, if detailed subroutine speci- fications are accepted without ever having been *Under Contract DASG60-75-C-O022 61 1981 数字送信の開始による ポケベルブーム（⽇本） パソコン通信 携帯電話・PHSの普
101. 101 10 20年前 30年前 2005/10 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 2014 1999 2004/11/16 2006/10/19 2002 1995 2010〜 1994/10/31 1989 1989/02/01 1992/3/13 1996/4/1 2010/10/12 2011/7/16 2011/10/18 2001/5/18 1996/8 2004/7/16 2013/8/1 2014/4/2 DynaBook （1994〜） 2000/12/1 2010/7/27 2005/10/7 1990/10/10 1988/3/1 1995/10/1 2003/9/1 数字送信の開始による ポケベルブーム（⽇本） 2013/1/10 2014/8 パソコン通信 携帯電話・PHSの普及、インターネット黎明期 携帯電話の多機能化、ブロードバンド時代 スマートフォン普 2003/9/1 2002/11/8 ★ ピ ア ソ ン シ ョ ッ ク 2009/11/27 2008/12/30
102. 102 10年前 20年前 2005/10 2024 00 2002 2004 2006 2008 2010 2012 2014 2016 2018 2020 2022 2018/11/22 2004/11/16 2006/10/19 2002 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 2001/5/18 2004/7/16 2013/8/1 2014/4/22 2019/9/30 2021/12/10 2024/9/13 2026 2018/3/27 2/1 2010/7/27 2016/10/6 2005/10/7 2021/8/1 2003/9/1 2021/12/1 2018/4/1 2024/12/25 2013/1/10 2014/8/18 2023/11/21 ネット黎明期 携帯電話の多機能化、ブロードバンド時代 スマートフォン普及時代（2010年、モバイル端末利⽤率がパソコン利⽤率を超える） 2017/10/14 2003/9/1 2002/11/8 ★ ピ ア ソ ン シ ョ ッ ク 2017/7/31 2009/11/27 2008/12/30 2023/11/28
103. 103 2018：!マイクロソフト、GitHub を 75 億ドルで買収 2001/2/11：" アジャイルソフ トウェア開発宣⾔ sionリリース 2000） （2005） GitHub リリース （2008） ugzilla リース 2000） Jira リリース （2002） AWS サービス開始 （2006） Jenkins 誕⽣ （2011） GitHub Actions （2018） ChatGPT ⼀般公開 （2022/11/30） GitHub Copilot （2021/6/29） Azure サービス開始 （2010） 2009〜2020：" 第⼆次ブラウザ戦争 Google Chromeの躍進、 Internet Explorerの衰退 （2018） （2004） Google Cloud サービス開始 （2008） 欧州の⾃動⾞メーカ が中⼼となって公開（2005） （2011） （2006） （2004） ⽶国防総省(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） Gemini 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 Hammondが初めてDevOpsに繋がる伝説的な講演を⾏う 2000年代後半〜：" クラウドファースト‧クラウドネイティブ時代に突⼊ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタートアップはクラウドファーストで事業を⽴ち上げ、初期からアジャイル⼿法を採⽤
106. 2016 - 2017 State of DevOps Report 106 l Puppet + DORA の連名で発表された2016年と2017年のState of DevOps Reportは、制約理論をベースにした アルゴリズムを活⽤し、数千の組織から得られたデータを統計的に分析することでDevOpsの実践と組織のパ フォーマンスの関係性を客観的に実証しました。 n 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% n 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% * ローパフォーマーは概して（統計的に有意なレベルで）成績が悪かったが、中央値はミディアムパフォーマーと 変わらなかった。 * ローパフォーマーは概して（統計的に有意なレベルで）成績が悪かったが、中央値はミディアムパフォーマーと 変わらなかった。
107. DORA激動の2018年 107
110. DORA激動の2018年 l 2018年は、DORAにとって激動の年でした。 l まず、2018年3⽉27⽇、かねてより進めていた新し い書籍が発売となります。 l Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations（邦題「LeanとDevOps の科学」）です。 l この本の出版でMartin Fowlerと約束を果たしたこと になります。この本はDORAの「研究の調査‧分析 ⼿法を紹介‧解説する本」として⽣まれました。
111. DORA激動の2018年 l 発⾏はIT Revolution Pressで、DORAの⼆⼈Nicole Forsgren、Jez Humble、そしてIT Revolutionの Gene Kimの名前で発⾏されました。 l しかし、ここにPuppet Labsのメンバーはいませ ん。（謝辞の中には出てきますが） そして「LeanとDevOpsの科学」が出版された翌⽉―
112. DORA激動の2018年 112 l 書籍名 "Accelerate" を冠した Accelerate State of DevOps Report という、新しいプログラムを発表します。 l これは、⻑年共に歩んできたPuppet社とのパートナ ーシップ解消を意味しました。DORAは、次のパー トナーとしてGoogle Cloudを選択したのです。* l 新しい 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（ジェズ‧ハンブル）
113. 2018 Accelerate State of DevOps Report 113 l 肝⼼の中⾝ですが、2018年のパフォーマンスの指標とレベルにはちょっとした変化が⽣じます。 l それは、MTTRが"Time to restore service"という⾔い⽅に変わったことと、レベルに初めてEliteが登場したこ とです。 n 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%
114. DORAの終焉 114 l リサーチは順調であったようですがDORAのCEO兼主任研究員であったDr. Nicole Forsgrenには⼤きな重圧が かかっていたようです。 l この頃のことをJez Humbleはブログで次のように振り返っています。 * https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667 経費を抑えた⾃⼒での会社運営には⼤きな代償がありました。それは燃え尽き症候群です。スタートアップは創 業者を疲弊させることで有名ですが、私たちも例外ではありませんでした。特に最も⼤きな負担を背負っていた のはNicoleでした。CEOとして彼⼥は、会社の戦略、財務、そして事業運営全般に責任を負っていました。それ だけではありません。CEOとして市場戦略の⽴案と実⾏をほぼ⼀⼈で担うだけでなく、State of DevOpsレポート の主任研究者、『Accelerate』の主執筆者、そして買収交渉の責任者も務めていました。彼⼥が⾔うように、こ れらの成果はすべて何年もかけて築き上げたものですが、驚くべき仕事の処理能⼒を持っていた彼⼥でさえ、膨 ⼤な時間の労働なしにはこれらを実現することはできなかったでしょう。これこそが投資を受けなかったことの 代償でした - より⼤きなチームを雇って、この重荷を分散することができなかったのです。 Jez Humbleのブログ*から
115. DORAの終焉 115 l 2018年12⽉、Nicole ForsgrenはDORAをGoogleに売却する決断をしたのでした。
118. Puppet版State of DevOps Report l ⼀⽅、Puppet社も2018年は独⾃のState of DevOps Reportを発⾏します。 l しかし、これはDORA版とは異なるポリシーで編集 されたものでした。2013年版に原点回帰するかの如 く、DevOpsの進化の段階を特定し、DevOpsへの変 ⾰プロセスの定量化に舵を切っています。 l Puppet版 2018 State of DevOps Reportについて語 る⼈物は、あのAlanna Brownでした。 l Puppet社は、2022年4⽉にソフトウェア開発ツール ⼤⼿Perforce Software, Inc. に買収されましたが、 現在もState of DevOps Reportはシリーズを継続中 であり、主にDevOpsに取り組む現場での実⽤性に重 点を置いています。
119. Googleになってからの State of DevOps Report 119
120. ⼊れ替わる著者陣 l 2019年にGene Kim、2021年にはDr.Nicole ForsgrenとJez HumbleがDORAを去りました。 l 現在は、新たなDORAメンバーやGoogleのリサーチャーを中⼼に研究が引き継がれています。
121. ⼊れ替わる著者陣 l Gene Kim は現在もIT Revolutionの代表であり、執 筆活動や講演を精⼒的にこなしています。 l 2019年に来⽇しており、DevOpsDays Tokyo 2019のキ ーノートセッションに登壇しています。（私は現地で拝 聴できました） l Jez Humble は現在もGoogleに席を置きSRE(Site Reliability Engineering)のエンジニアとして活躍す る傍ら、カリフォルニア⼤学バークレー校（UC Berkeley）の教員も続けている。 Jez Humble Gene Kim
122. ⼊れ替わる著者陣 122 l Dr.Nicole Forsgrenは現在Microsoft Research のパー トナーとして Developer Experience Lab を率いてお り、ACM Queue の取締役も務めています。 l 最近は、科学を活⽤しソフトウェア開発者をより楽 しくする研究を実践しています。DevExやSPACEフ レームワークに関する研究論⽂を発表し、精⼒的に 活動中です。 l 昨年6⽉に来⽇し当社主催の「開発⽣産性 Conference 2024」にて基調講演をご担当頂きまし た。 Dr. Nicole Forsgren （開発⽣産性Conference 2024にて）
123. ⼊れ替わる著者陣 123 l 2022年と2023年の2年間だけ、著名なエンジニア David(Dave) Farley（デイビッド（デイブ）‧ファ ーリー）が加わっていました。 l 彼は、Jez Humbleと共にベストセラー 「Continuous Delivery」を書いた⼈物です。 l 書籍「Modern Software Engineering（継続的デリ バリーのソフトウェア⼯学）」の筆者でもあり、⽂ 中、Dr. Nicole Forsgrenにまつわるエピソードや DORAの研究成果が引⽤されています。 David(Dave) Farley (Image source: InfoQ.com)
126. Eliteが消えたり現れたり l 2022年の分析では、パフォーマンスレベルからEliteが消滅します。これは、最もパフォーマンスの⾼いクラス タが、2021年のEliteの特徴を⽰していなかったためと述べられています。翌年2023年は復活しました。 n 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%以上 n 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%
127. Eliteが消えたり現れたり l これは、クラスター分析の特性として仕⽅のない現象でもあります。クラスター分析は、データの分布やその 年の回答者の特性に基づいて⾃然に分類を形成する⼿法であり、事前にクラスター数やその特徴を固定するも のではありません。 l そのため、特定のパフォーマンス層が少数であったり、他の層と重なりがある場合、ある年には明確なクラス ターとして現れず、翌年に再び明確化することがあります。この柔軟性こそがクラスター分析の利点であり、 データに忠実であることを意味しています。
128. 2023年からFour Keyの⼀部名称と定義が変更 128 指標 2023年の定義 2022年までの定義 変更点 Deployment frequency (デプロイ頻度) 変更を本番環境に push す る頻度。 主なアプリケーションまたはサービスで、組 織が本番環境にコードをデプロイする頻度、 またはエンドユーザーにリリースする頻度は どのくらいか。 定義が簡潔化され、本番環境への変更適 ⽤に焦点が絞られています。 Lead time for changes (変更のリードタイム) コードの変更を commit してからデプロイするま での時間。 主なアプリケーションまたはサービスで、変 更のリードタイム（commit されたコードが 本番環境で正常に実⾏されるまでの時間）は どのくらいか。 定義が簡潔化され、コミットからデプロ イまでの具体的な⼯程に限定。「本番環 境で正常に実⾏される」という表現が省 かれています。 Change failure rate (変更失敗率) デプロイにより障害が発 ⽣し、すぐに対処する必 要が⽣じる頻度。 主なアプリケーションまたはサービスで、本 番環境に変更を加えた、またはユーザーに変 更をリリースしたとき、サービスの低下（サ ービス障害、サービスの停⽌など）が発⽣し て、対策（修正プログラム、ロールバック、 フィックス フォワード、パッチなど）が必 要になった割合はどのくらいか。 「デプロイにより障害が発⽣し」という 表現に変更され、障害の発⽣原因がデプ ロイに限定。具体的な対策例が削除され ました。 Failed deployment recovery time (失敗デプロイの復旧時間) (旧名称: Time to restore service (サービス復旧時間)) デプロイの失敗時に復旧 にかかる時間。 主なアプリケーションまたはサービスで、サ ービスのインシデントや、ユーザーに影響を 与える障害（計画外のサービス停⽌やサービ ス障害など）が発⽣した場合、サービスの復 旧に通常どれくらいの時間がかかるか。 指標名が変更され、定義が「デプロイの 失敗」に絞られました。例として挙げら れていた「計画外のサービス停⽌やサー ビス障害」が削除されました。
129. リフレクション：DORA Reportを正しく読み解くために 1. DORA Report は単なるサーベイの結果ではなく、 2014年以降、統計学を⽤いた「科学的リサーチ」 に基づいて分析されている。 2. 「科学的リサーチ」の具体な内容は書籍『Leanと DevOpsの科学』で解説されている。 3. Four Keysを元にしたパフォーマンスレベルは統計 的な分析⼿法（クラスター分析）が⽤いられ、調査 年ごとに変化する。 4. DORA はこのレポートを⽤いて、各組織（企業）が 独⾃の実験や仮説を⽴てることを望んでいる。
132. 2024 Accelerate State of DevOps Report
134. 2024 パフォーマンス指標 134 n 2024 パフォーマンス指標 指標 Elite High Medium Low Deployment frequency オンデマンド（1⽇複数回） 1⽇1回以上週1回未満 週1回以上⽉1回未満 ⽉1回以上6ヶ⽉に1回未満 Change lead time 1⽇未満 1⽇以上週1回未満 1週間以上1ヶ⽉未満 1ヶ⽉以上6ヶ⽉未満 Failed deployment recovery time 1時間未満 1⽇未満 1⽇未満 1週間以上1ヶ⽉未満 Change failure rate 5% 20% 10% 40%
135. 2024 パフォーマンス指標 135 n 2024 パフォーマンス指標 指標 Elite High Medium Low Deployment frequency オンデマンド（1⽇複数回） 1⽇1回以上週1回未満 週1回以上⽉1回未満 ⽉1回以上6ヶ⽉に1回未満 Change lead time 1⽇未満 1⽇以上週1回未満 1週間以上1ヶ⽉未満 1ヶ⽉以上6ヶ⽉未満 Failed deployment recovery time 1時間未満 1⽇未満 1⽇未満 1週間以上1ヶ⽉未満 Change failure rate 5% 20% 10% 40% Change failure rate (変更失敗率) のHighレベルとMediumレベルが逆転している
136. 2024 パフォーマンス指標 136
137. 本当に優れたチームとは「Eliteな改善」を実現するチーム 137 l 「パフォーマンスレベルを上げましょう」「Eliteを⽬指しましょう」といったスローガンは、本質的な⽬的を ⾒失わせる危険性をはらんでいます。真に重要なのは、品質とスピードを同時に追求するマインドです。この 両⽴を実現するためには継続的な改善活動が不可⽋だと⾔えます。 私たちは、より⾼速なチームを「High パフォーマー」、 より遅いが安定しているチームを「Medium パフォーマー」 と呼ぶことにしました。この決定は、これらのパフォーマン スレベルを使⽤する際の潜在的な落とし⽳の⼀つを浮き彫り にしています。つまり、特定のパフォーマンスレベルに到達 することよりも、改善を続けることの⽅がチームにとって重 要であるという点です。 本当に優れたチームとは、「Eliteなパフォーマンス」を達 成するチームではなく、「Eliteな改善(elite improvement)」 を実現するチームなのです。
138. 「⼿戻り率」の登場 138 l 変更失敗率は当初から予測しづらい異質な指標として認識されてきました。 l DORAは、変更失敗率という指標がチームに求められる⼿戻り作業量の代替指標として機能するという⻑年の 仮説を持っています。デリバリーが失敗すると、チームはその変更を修正する必要があり、おそらく別の変更 （修正コミット）を加えることになります。 l そこでDORAは、⻑年の仮説であった「⼿戻り率」を追加することにしました。
139. 「⼿戻り率」の登場 139
140. ユーザー中⼼の開発がDevExを向上させる 140 l DevExを向上させるにはまず、エンドユーザーエク スペリエンス（UX）を向上させることが重要である という点が強調されています。エンドユーザーのニ ーズを深く理解し、それを開発プロセスの中核に据 える組織では、開発者の⽣産性が向上するととも に、組織全体の成⻑が促進されることが調査で⽰さ れています。 l ユーザーのニーズを軸に開発を⾏うことで、開発者 の仕事の満⾜度が⾼まり、結果的に組織全体のパフ ォーマンス向上につながる可能性があります。ユー ザー中⼼（User-Centric）のマインドセットを実践 している開発者には、次のような特徴が⾒られま す。 • より⾼い⽣産性を発揮する（⽬的意識が明確になり、不 要な作業が減る） • バーンアウトのリスクが低下する（仕事の意義を感じや すく、ストレスが軽減される） • より⾼品質な製品を⽣み出す（ユーザーの課題に直結し たソリューションを提供できる）
141. ユーザー中⼼の開発がDevExを向上させる 141 l DevExを向上させるにはまず、エンドユーザーエク スペリエンス（UX）を向上させることが重要である という点が強調されています。エンドユーザーのニ ーズを深く理解し、それを開発プロセスの中核に据 える組織では、開発者の⽣産性が向上するととも に、組織全体の成⻑が促進されることが調査で⽰さ れています。 l ユーザーのニーズを軸に開発を⾏うことで、開発者 の仕事の満⾜度が⾼まり、結果的に組織全体のパフ ォーマンス向上につながる可能性があります。ユー ザー中⼼（User-Centric）のマインドセットを実践 している開発者には、次のような特徴が⾒られま す。 • より⾼い⽣産性を発揮する（⽬的意識が明確になり、不 要な作業が減る） • バーンアウトのリスクが低下する（仕事の意義を感じや すく、ストレスが軽減される） • より⾼品質な製品を⽣み出す（ユーザーの課題に直結し たソリューションを提供できる）
142. ユーザー中⼼の開発がDevExを向上させる 142
143. 質の⾼いドキュメントがユーザー中⼼開発を増幅する 143 l 2021年からドキュメントの調査を開始したDORAで すが、2024年のレポートでは、質の⾼いドキュメン トとユーザー中⼼のアプローチを組み合わせると、 製品パフォーマンスが向上することが明らかになり ました。 l 質の⾼いドキュメントの評価には、内容の⾒つけや すさや信頼性といった要素が含まれます。 l DORAは、アジャイルマニフェスト（アジャイルソフ トウェア開発宣⾔）を引⽤して次のように述べてい ます。 アジャイルマニフェストは「包括的なドキュメントよりも動 くソフトウェアを」を提唱しています。 しかし、私たちは依然として、質の⾼いドキュメントが動く ソフトウェアの重要な構成要素であることを認識していま す。 「包括的なドキュメント」という表現は、ドキュメントを含 む不健全な慣⾏を表しているのかもしれません。 問題のあるドキュメントには、官僚的な⽬的だけのために作 成されたドキュメントや、経営陣と従業員の間の不信感を取 り繕うためのドキュメントが含まれます。不健全なドキュメ ント⽂化には、ドキュメントを作成するものの、維持や整理 を⾏わないことも含まれます。
144. 144 2001/2/11：" アジャイルソフ トウェア開発宣⾔ 1991〜：#バブル崩壊「失われた◦◦年」 1988〜：!⽇本を含む諸外国へ「通商法スーパー301条」発動 Linux 0.01 リリース UNIXが商業化‧断⽚化していく中、 Linuxはオープンソースの⼒で 統⼀的な開発基盤となり、 世界中の技術⾰新を⽀えた （1991/9/17） CVS 誕⽣ （1990） Subversionリリース （2000） （2005） GitHub リリース （2008） Bugzilla リリース （2000） Jira リリース （2002） AWS サービス開始 （2006） Jenkins 誕⽣ （2011） Java v1.0 正式リリース Javaはオブジェクト指向と 仮想マシン技術を普及させ、 後の⾔語設計にも影響を与えた （1996） 1990年代前半：" UNIX戦争 Azure サービス開始 （2010） 1990〜2000：" 第⼀次ブラウザ戦争。Internet Explorerの躍進、 Netscape Navigatorの消滅 2009〜2020：" 第⼆次ブラウザ戦争 Google Chromeの躍進、 Internet Explor （2004） Google Cloud サービス開始 （2008） 欧州の⾃動⾞メーカ が中⼼となって公開（2005） （2011） 国家プロジェクト （2006） （2004） 1997〜2010年代：!⽶国防総省(DoD)が CMMレベル3以上を防衛関連のソフトウェア調達条 件として要求し始める。 2000年代〜：!⽶国を中⼼にでアジャイル⼿法が急速に広まり、ウォーターフォールは特にWeb系‧スター 1990年代：!ウォーターフォールのリスクを軽減する開発⼿法が次々 と誕⽣（インクリメンタル、スパイラル、RUP など） 90年前半：!⽶国防総省(DoD)の発注したソフトウェアに問題が多 も多くの遅延∕途中での挫折が発⽣‵ 2010年〜：!⽶国議会は2010会計 の実施」(第804条)をDoDに命じ、 Windows95 リリース コンシューマ向けOSに TCP/IPが標準搭載され ワークステーション並みに （1995） リリース （2004/2） 2000年代〜：#⽇本は⼤企業を中⼼に、ウォータフォールモデルを採⽤し続ける。 究。 2000/3〜：!ITバブル崩壊 は全ての軍⽤コンピュータ網のためにTCP/IP標準を作成。その後、コンピューター産業に開放され、4.2 BSD UNIXを⽪切りにほとんどの商⽤OSにTCP/IPが実装された。 2009：!Flickrのエンジニアである John Hammondが初めてDevOpsに繋がる伝説 2000年代後半〜：" クラウドファースト‧クラウドネイティブ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタート
145. 145 2001/2/11：" アジャイルソフ トウェア開発宣⾔ 1991〜：#バブル崩壊「失われた◦◦年」 1988〜：!⽇本を含む諸外国へ「通商法スーパー301条」発動 Bugzilla Jira リリース （2002） AWS サービス開始 （2006） Java v1.0 正式リリース Javaはオブジェクト指向と 仮想マシン技術を普及させ、 後の⾔語設計にも影響を与えた （1996） 1990年代前半：" UNIX戦争 Azure サービス開始 （2010） （2004） Google Cloud サービス開始 （2008） 国家プロジェクト （2006） 1997〜2010年代：!⽶国防総省(DoD)が CMMレベル3以上を防衛関連のソフトウェア調達条 件として要求し始める。 2000年代〜：!⽶国を中⼼にでアジャイル⼿法が急速に広まり、ウォーターフォールは特にWeb系‧スター 1990年代：!ウォーターフォールのリスクを軽減する開発⼿法が次々 と誕⽣（インクリメンタル、スパイラル、RUP など） 90年前半：!⽶国防総省(DoD)の発注したソフトウェアに問題が多 も多くの遅延∕途中での挫折が発⽣‵ 2010年〜：!⽶国議会は2010会計 の実施」(第804条)をDoDに命じ、 初代iPhone発表 (2007/1/9) クステーションの時代：Sun SPARCstation （1989〜1994） 初代iMac （1998〜） DynaBook （1994〜） 家庭向けADSL‧FTTHの普及、 ブロードバンド時代に突⼊ (2001〜) リリース （2004/2） 2000年代〜：#⽇本は⼤企業を中⼼に、ウォータフォールモデルを採⽤し続ける。 数字送信の開始による ポケベルブーム（⽇本） （1992〜1996） F501i HYPER iモード開始 （1999/2/22） テレホーダイ（1995〜2023） 初代iPad発表 (2010/4/3) Samsung Galaxy S II (2011/5/2) 究。 2000/3〜：!ITバブル崩壊 パソコン通信 携帯電話・PHSの普及、インターネット黎明期 携帯電話の多機能化、ブロードバンド時代 スマートフォン普 は全ての軍⽤コンピュータ網のためにTCP/IP標準を作成。その後、コンピューター産業に開放され、4.2 BSD UNIXを⽪切りにほとんどの商⽤OSにTCP/IPが実装された。 Netflixが⽇本 ※!では2007 2009：!Flickrのエンジニアである John Hammondが初めてDevOpsに繋がる伝説 2000年代後半〜：" クラウドファースト‧クラウドネイティブ 2008/9〜：!リーマンショック 2010年以降〜：#⽇本のスタート
146. 質の⾼いドキュメントがユーザー中⼼開発を増幅する 146 l 当時の多くの開発では詳細な仕様書作成が前提とさ れ、要件変更が発⽣するたびに仕様書の修正に追わ れ、実際の開発よりもドキュメント管理に多⼤な時 間を費やしていました。⼤量の紙にプリントして製 本、そのドキュメントを納品、といった⾵習もまだ 残っていた時代です。 l また、現代に⽣きる私たちは忘れがちですが、2001 年頃の技術的な制約も⼤きく影響していました。 l ツールはWordやWiki、Lotus Notes/Dominoが主流 でしたが、当時のツールはバージョン管理機能が貧 弱で、複数⼈での同時編集が不可能、変更履歴の追 跡も困難でした。 l また、⼤きなドキュメントは頻繁にクラッシュし、 図や表の扱いも現在より遥かに制限されていまし た。さらに、ストレージは現在と⽐べて容量が⼩さ く⾼価であり、ネットワーク速度も遅いという環境 でした。 l クラウド中⼼の現代ではNotionやConfluence、 GitHub Wikiなど、協働作業に適したドキュメント管 理ツールが普及し、リアルタイム共同編集や変更履 歴の⾃動管理が当たり前となっています。 l DORAレポートによれば、現代におけるドキュメン トの役割は「ユーザーの声やフィードバックをチー ム全体に共有し、それを製品に反映させる」とい う、より価値創造に直結したものへと進化していま す。
147. 常に変わる優先事項の危険性 147 l DORAの調査で最も注⽬すべき発⾒の1つは、組織の 優先事項が頻繁に変わることによる悪影響です。 l データによれば、優先事項が不安定な組織では、 • ⽣産性に⼩さいながらも確実な低下が⾒られる • バーンアウトが⼤幅に増加する l 興味深いことに、強⼒なリーダーシップや質の⾼い ドキュメント、ユーザー中⼼のアプローチがあって も、優先事項が不安定であれば従業員はバーンアウ トのリスクにさらされ続けることが明らかになりま した。DORAは、これが慢性的なストレスによるも のと推測しています。 l ⼀⽅で興味深いことに、優先事項が安定すると、逆 にソフトウェアデリバリーのスピードと安定性が低 下するという予想外の結果も報告されています。こ れについてDORAは、安定した組織では変更が少な くなるか、推奨されるよりも⼤きなバッチでの出荷 が⾏われるためではないかと仮説を⽴てています。 この感覚は誰もが経験したことがあるでしょう。数か⽉かけ て新しい機能の開発に取り組んできて、それがユーザーにと って必要なものであると確信し、集中し、モチベーションも ⾼い状態です。ところが、突然、あるいは突然のように感じ るほど急に、経営陣が組織の優先事項を変更します。する と、あなたのプロジェクトが⼀時停⽌されるのか、中⽌され るのか、別の形に変わるのか、それとも全く違うものになる のかが分からなくなります。
148. 開発現場におけるAIの浸透 l DORAの調査に対する回答者の⼤多数（81%）が、⾃社が アプリケーションやサービスへのAIの導⼊を強化するため に優先順位を変えたと報告しています。さらに、49.2%の 回答者は、この変化の規模を「中程度」または「⼤きな変 化」と表現しています。 l ソフトウェア開発業務におけるAIの最も⼀般的な使⽤例は コードの作成と情報の要約であり、これらのタスクを職務 に含む回答者のうち、それぞれ74.9％と71.2％が少なくと も⼀部でAIに依存していると回答しました。 l 職種別の分析では、データサイエンティストと機械学習ス ペシャリストで特にAI依存度が⾼い傾向にありました。⼀ ⽅、ハードウェアエンジニアのAI依存度は最も低くなって います。これは、ハードウェアエンジニアの業務内容がAI の⼀般的な活⽤領域と異なる性質を持つためと考えられま す。 148
149. ⽣産性向上の実態 149 l ⽣産性への影響に対する回答は次の通りでした。 • 10%が「極端に向上」 • 25%が「中程度に向上」 • 40%が「わずかに向上」 l 「極端」と「中程度」を合わせて、回答者の３分の １以上となっており、AIが開発者の⽇常業務に実質 的な価値を提供していることを裏付けています。 l なお、AIがコード作成能⼒を阻害したと報告した回 答者はわずか5%でした。67%の回答者はAI⽀援のコ ーディングツールによってコード作成能⼒が少なく とも何らかの向上を⾒せたと報告し、約10%はAIに よって「極端な」改善が⾒られたと述べています。
150. デリバリーパフォーマンスへの悪影響 150 l DORAにとって予想外の発⾒もされています。それ は、ソフトウェアデリバリーのパフォーマンスへの 影響です。DORAはここ数年の調査から、ソフトウ ェアデリバリーにおける⽣産性（スループット）と 安定性の指標が、互いに独⽴した動きを⽰し始めて いることが分かってきたのです。 l 従来、この2つの指標には相関関係があるとされてき ました。しかし、最新のデータは、それぞれが独⽴ した要因として機能していることを⽰唆しており、 個別の評価が必要になってきています。 l この調査結果はAI導⼊がソフトウェアデリバリーパ フォーマンスに悪影響を与えていることを⽰してい ます。 ü デリバリースループットへの影響は⼩さいものの、ネガティブな傾向（AI導⼊が25% 増加するごとに推定1.5%の減少） ü デリバリー安定性への悪影響は⼤きく、AI導⼊が25%増加するごとに推定7.2%の減少
151. 速度（スループット）と安定性はトレードオフではない 151 l Four Keys を⽤いた⼤規模な調査‧分析から導き出された、本書の最も重要な発⾒の⼀つです。従来信じられ ていた「速度を上げると安定性が犠牲になる」という考えは誤りであり、⾼パフォーマンスな組織では、速度 と安定性は両⽴し、むしろ互いに強化し合う関係にあることがデータで⽰されました。 l DevOps の価値を強⼒に裏付け、多くの組織が開発‧運⽤プラクティスを⾒直す⼤きな動機となりました。 スピードより 品質を重視 品質より スピードを重視 スピードと品質 の両⽴ 壊れやすい 厄介な状態 高品質 低品質 遅い 速い
152. デリバリーパフォーマンスへの悪影響 152 l DORAにとって予想外の発⾒もされています。それ は、ソフトウェアデリバリーのパフォーマンスへの 影響です。DORAはここ数年の調査から、ソフトウ ェアデリバリーにおける⽣産性（スループット）と 安定性の指標が、互いに独⽴した動きを⽰し始めて いることが分かってきたのです。 l 従来、この2つの指標には相関関係があるとされてき ました。しかし、最新のデータは、それぞれが独⽴ した要因として機能していることを⽰唆しており、 個別の評価が必要になってきています。 l この調査結果はAI導⼊がソフトウェアデリバリーパ フォーマンスに悪影響を与えていることを⽰してい ます。 ü デリバリースループットへの影響は⼩さいものの、ネガティブな傾向（AI導⼊が25% 増加するごとに推定1.5%の減少） ü デリバリー安定性への悪影響は⼤きく、AI導⼊が25%増加するごとに推定7.2%の減少
153. デリバリーパフォーマンスへの悪影響 153 ü デリバリースループットへの影響は⼩さいものの、ネガティブな傾向（AI導⼊が25% 増加するごとに推定1.5%の減少） ü デリバリー安定性への悪影響は⼤きく、AI導⼊が25%増加するごとに推定7.2%の減少 過去の調査結果に基づき、AIによる⽣産性とコード⽣ 成速度の根本的なパラダイムシフトが、DORAの最も基 本的な原則の⼀つである「⼩さなバッチサイズの重要 性」を⾒落とさせている可能性があると仮定していま す。 つまり、AIによって同じ時間内により多くのコー ドを⽣成できるため、変更リストが⼤きくなっている 可能性があります。 DORAの調査では⼀貫して、⼤きな変更は遅く、より不 安定になりやすいことが⽰されています。 総合的に⾒ ると、デベロップメントプロセスの改善は、必ずしも ソフトウェアデリバリーの改善に直結しないことを⽰ 唆しています。少なくとも、⼩さなバッチサイズや堅 牢なテスト機構といった、成功するソフトウェアデリ バリーの基本を適切に守らなければなりません。
154. コード⽣成AIが書くコードは信頼されにくい？ 154 l 開発業務で使⽤されるAI⽣成コードの信頼性に対する参加 者の認識は劣っていました。 l ⼤多数の回答者（87.9%）がAI⽣成コードの品質にある程 度の信頼を寄せているとするものの、信頼の程度は全体的 に低く「やや信頼」（39.2%）、「少し信頼」（27.3%） または「全く信頼せず」（11.9%）と報告しました。 l 開発者がAIを急速に導⼊し、それに依存し、パフォーマン ス向上に貢献すると認識している⼀⽅で、AIに対する信頼 は薄いということになります。 l しかし、興味深いのは、この「不信感」がAIの活⽤を妨げ ていないという点です。 l 開発者たちはAI⽣成コードを「完璧」なものとしてではな く、「改善が必要な出発点」として捉えている実態が明ら かになっています。
155. AIがチームや組織のパフォーマンスに与える影響とは 155 l 組織のパフォーマンス向上 l 研究によれば、AIの導⼊が25%増加すると、組織のパフォーマ ンスが約2.3%向上することが分かりました。この「組織のパフ ォーマンス」とは、収益性、市場シェア、業務効率、顧客満⾜ 度など、複数の要素を総合的に評価したものです。 AIは、業務 の効率化や意思決定の迅速化、⽬標達成能⼒の向上といった⾯ で組織にプラスの影響を及ぼしていると考えられます。 l チームのパフォーマンスにも効果 l チームのパフォーマンスもAIの導⼊によって約1.4%向上すると いう結果が出ています。この「チームのパフォーマンス」に は、メンバー間の協⼒、イノベーション、効率的な作業、適応 ⼒などが含まれます。 特に、AIはチーム内でのコミュニケーシ ョンや知識共有の促進、意思決定プロセスの効率化といった課 題を解消し、チーム全体の⽣産性を⾼める役割を果たしている ようです。
156. AIがチームや組織のパフォーマンスに与える影響とは 156 l 製品のパフォーマンスとの関連性は限定的 l ⼀⽅で、製品のパフォーマンス（使いやすさ、機能性、価値、 セキュリティなど）については、AIの導⼊による明確な影響は確 認されませんでした。これは、製品の成功にはAI以外の要素、 たとえば開発プロセスやクリエイティビティ、ユーザー体験の デザインなどが深く関係しているためと考えられます。 l チーム、組織、製品のパフォーマンスが互いに密接な関連 を持つことも⽰しています。例えば、優れたチームは⾼品 質な製品を⽣み出す可能性が⾼い⼀⽅で、低品質な製品を 扱うとチームの⼒が⼗分に発揮されないことがあります。 また、良い組織は適切なリソースやプロセスを提供するこ とで優れたチームを育てますが、逆に組織の問題がチーム の⼒を制限するケースも⾒られます。
157. AIが個⼈に与える影響：利点と課題 157 l AIの導⼊で得られる明確な利点 l DORAの調査によると、AIの導⼊が個⼈の「フロー（集中⼒）」「⽣産性」「仕事の満⾜度」を向上させることが分かり ました（下表）。たとえば、AIの導⼊が25%増加すると次のような効果が予想されます。 l このような効果の背景には、AIによる情報の統合と効率的な作業環境の提供があります。従来は多くの時間を要した作業 の効率化により、フロー状態に⼊りやすくなり、結果として仕事の満⾜度も向上します。 アウトカム 予想される%の変化 (推定値) フロー +2.6% 仕事の満⾜度 +2.2% ⽣産性 +2.1% バーンアウト -0.6%
158. AIが個⼈に与える影響：利点と課題 158 l AIによる潜在的な課題‧トレードオフ l ⼀⽅で、AI導⼊による課題も浮かび上がっています。特に、価値ある作業に費やす時間の減少という予想外の結果が観察 されました。 l AIは、価値ある作業（たとえばコーディング）を迅速に進めることで効率化を実現しますが、単調で繰り返しの多い労苦 的な作業（たとえば会議や事務処理）にはほとんど影響を与えていません。これにより、余った時間が新たなタスクで埋 められる「真空現象（vacuum hypothesis）」が起きている可能性があります。 アウトカム 予想される%の変化 (推定値) 苦労する作業の時間：⻑期的な価値がほとんどない反復的な⼿作業に費やした時間の割合を測定する単⼀の項⽬ +0.4% 価値ある作業の時間： 価値があると考えるタスクに費やした時間の割合を測定する単⼀の項⽬ -2.6% n vacuum hypothesis（真空仮説/空席仮説）⽣態系において「空いている場所には必ず何かが⼊る」という考え⽅を⽰す仮説 です。例えば⽕⼭噴⽕後の新しい⼟地や、⼤量絶滅後の⽣態系の空⽩地帯には、時間の経過とともに必ず⽣物が進出し、その 環境に適応した種が定着していきます。この仮説は特に、ガラパゴス諸島のフィンチ類（⽂⿃のような⼩⿃の類）のように、 新しい環境で⽣物が多様化していく「適応放散」という現象を説明する際によく⽤いられます。名称の由来は、物理学におけ る真空（vacuum）が必ず何かによって埋められようとするのと同様に、⽣態的な空⽩も必ず埋められていくという類推から 来ています。
159. DORAが⽰す、AIのこれから 159 l DORAは今回の回答者に、今後1年、5年、10年のAIの影響についての⾒解や期待を尋ねています。 l まず、楽観的な⾒⽅としては、AIによって製品の品質が引き続き向上すると予想しています。 l ⼀⽅で、AIが⾃⾝のキャリア、⾃然環境、そして社会全体に対して純粋にマイナスの影響を与えると予想して おり、これらの悪影響が約5年後に完全に顕在化すると考えています。 l 「⾃然環境」が唐突に思われるかもしれませんが、DORAレポートの前半ではAIの環境負荷についての懸念が ⾔及されており、具体的には、 • 2030年までにAIによってデータセンターの電⼒需要が160%増加する可能性 • AIモデルの学習に、⽶国の1,000世帯以上の年間電⼒消費量に相当する電⼒が必要 • 回答者の30%以上がAIは⾃然環境に有害と考えている といった情報が添えられていました。
160. DORAが⽰す、AIのこれから 160 本レポートは、『Accelerate State of DevOps Report』 で発表された DORA の研究を基盤とし、それをさらに 発展させています。現在の AI 導⼊状況を概観し、開発 者や組織への影響を探るとともに、AI の成功する統 合、測定、継続的改善のためのフレームワークと実践 的なガイダンスを提⽰しています。 新しいテクノロジーの導⼊は、短期的には⽣産性や影 響⼒の低下を伴うことがあるという点も忘れてはなり ません。持続的で⻑期的な改善を優先することで、⽣ 成 AI 導⼊の恩恵をしっかりと享受できるようになるで しょう。 https://cloud.google.com/resources/content/dora-impact-of-gen-ai-software-development?hl=ja
161. おわりに 161
162. ソフトウェア開発は、今も昔も、どこか実験的である 162 l Tom DeMarcoは左記記事の最後で、こう締めくくっ ています。 l 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
163. "Applying insights from DORA"（DORAの知⾒を実践に活かすために） l DORAの研究成果は決して⼀時的なトレンドではありません。Four Keysなどを単なる「流⾏り」と捉えるのは 誤りです。しかし、その⼀⽅で、すべてを鵜呑みにする必要もありません。 l 2024年で10周年を迎えたDORA Reportには、この取り組みが成熟してきたことを⽰す重要なメッセージが随 所に⾒られます。その代表例が"Applying insights from DORA"（DORAの知⾒を実践に活かすために）という 章です。 私たちの調査結果は、皆様が独⾃の実験や仮説を⽴てる際の参考にしていただけま す。チームや組織に最適なアプローチを⾒出すために、変更による影響を測定しなが ら実験を重ねることが重要です。それにより、私たちの調査結果の検証にもつながり ます。結果は組織によって異なることが想定されますので、ぜひ皆様の取り組みを共 有していただき、その経験から互いに学び合えればと思います。
164. シリーズ：ソフトウェア開発現代史 164 TECH PLAY: 今こそ考えたい「開発プロセスの品質視点」 製造業とソフトウェアは本当に共存できていたのか？ 品質とスピードを問い直す https://speakerdeck.com/takabow/zhi-zao-ye- tosohutoueahaben-dang-nigong-cun-dekiteitanoka-pin- zhi-tosupidowowen-izhi-su-dc76f0ad-2d4c-4f2a-bf4d- cecbceb7eb5e JaSST’25 Tokyo Day2 なぜ日本のソフトウェア開発は「滝」なのか？ 製造業の成功体験とのギャップ https://speakerdeck.com/takabow/sohutoueakai-fa-xian- dai-shi-nazeri-ben-nosohutoueakai-fa-ha-long-nanoka- zhi-zao-ye-nocheng-gong-ti-yan-tonogiyatupu-number- jassttokyo お客様向け資料 「モダンソフトウェア エンジニアリングとは」 本 ⽇ の 発 表
165. シリーズ：ソフトウェア開発現代史 165 TECH PLAY: 今こそ考えたい「開発プロセスの品質視点」 製造業とソフトウェアは本当に共存できていたのか？ 品質とスピードを問い直す https://speakerdeck.com/takabow/zhi-zao-ye- tosohutoueahaben-dang-nigong-cun-dekiteitanoka-pin- zhi-tosupidowowen-izhi-su-dc76f0ad-2d4c-4f2a-bf4d- cecbceb7eb5e JaSST’25 Tokyo Day2 なぜ日本のソフトウェア開発は「滝」なのか？ 製造業の成功体験とのギャップ https://speakerdeck.com/takabow/sohutoueakai-fa-xian- dai-shi-nazeri-ben-nosohutoueakai-fa-ha-long-nanoka- zhi-zao-ye-nocheng-gong-ti-yan-tonogiyatupu-number- jassttokyo 💡【⼤好評につき再放送実施】 【ヤマハ発動機×SUBARU×三菱電機】今こそ考えたい「開発プロセスの品質視点」 2025/04/24(⽊)12:00 〜 13:45 開催 お客様向け資料 「モダンソフトウェア エンジニアリングとは」 本 ⽇ の 発 表