CINXE.COM

<!DOCTYPE html> <html lang="ja" data-admin-domain="//blog.hatena.ne.jp" data-admin-origin="https://blog.hatena.ne.jp" data-author="mtx2s" data-avail-langs="ja en" data-blog="mtx2s.hatenablog.com" data-blog-host="mtx2s.hatenablog.com" data-blog-is-public="1" data-blog-name="mtx2s’s blog" data-blog-owner="mtx2s" data-blog-show-ads="1" data-blog-show-sleeping-ads="" data-blog-uri="https://mtx2s.hatenablog.com/" data-blog-uuid="26006613499892765" data-blogs-uri-base="https://mtx2s.hatenablog.com" data-brand="hatenablog" data-data-layer="{"hatenablog":{"admin":{},"analytics":{"brand_property_id":"","measurement_id":"G-H7L1QHXB4D","non_sampling_property_id":"","property_id":"","separated_property_id":"UA-29716941-25"},"blog":{"blog_id":"26006613499892765","content_seems_japanese":"true","disable_ads":"","enable_ads":"true","enable_keyword_link":"true","entry_show_footer_related_entries":"true","force_pc_view":"false","is_public":"true","is_responsive_view":"false","is_sleeping":"false","lang":"ja","name":"mtx2s\u2019s blog","owner_name":"mtx2s","uri":"https://mtx2s.hatenablog.com/"},"brand":"hatenablog","page_id":"entry","permalink_entry":{"author_name":"mtx2s","categories":"","character_count":20216,"date":"2024-11-11","entry_id":"6802418398301277587","first_category":"","hour":"20","title":"\u30a2\u30b8\u30e3\u30a4\u30eb\u3092\u5b9f\u8df5\u3059\u308b\u7d44\u7e54\u3067\u3042\u3063\u3066\u3082\u30a6\u30a9\u30fc\u30bf\u30fc\u30d5\u30a9\u30fc\u30eb\u3092\u5b66\u3076\u3053\u3068\u306b\u306f\u4fa1\u5024\u304c\u3042\u308b","uri":"https://mtx2s.hatenablog.com/entry/2024/11/11/204512"},"pro":"free","router_type":"blogs"}}" data-device="pc" data-dont-recommend-pro="false" data-global-domain="https://hatena.blog" data-globalheader-color="b" data-globalheader-type="pc" data-has-touch-view="1" data-help-url="https://help.hatenablog.com" data-page="entry" data-parts-domain="https://hatenablog-parts.com" data-plus-available="" data-pro="false" data-router-type="blogs" data-sentry-dsn="https://03a33e4781a24cf2885099fed222b56d@sentry.io/1195218" data-sentry-environment="production" data-sentry-sample-rate="0.1" data-static-domain="https://cdn.blog.st-hatena.com" data-version="b06a9d4929119667e7027e25c25079" data-initial-state="{}" > <head prefix="og: http://ogp.me/ns# fb: http://ogp.me/ns/fb# article: http://ogp.me/ns/article#"> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <meta name="robots" content="max-image-preview:large" /> <meta charset="utf-8"/> <meta http-equiv="X-UA-Compatible" content="IE=7; IE=9; IE=10; IE=11" /> <title>アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある - mtx2s’s blog</title> <link rel="canonical" href="https://mtx2s.hatenablog.com/entry/2024/11/11/204512"/> <meta itemprop="name" content="アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある - mtx2s’s blog"/> <meta itemprop="image" content="https://cdn.image.st-hatena.com/image/scale/22746db9dd919c83ed010f06efc44b2de9af03c2/backend=imagemagick;height=1300;version=1;width=1300/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmtx2s%2F20241111%2F20241111202606.png"/> <meta property="og:title" content="アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある - mtx2s’s blog"/> <meta property="og:type" content="article"/> <meta property="og:url" content="https://mtx2s.hatenablog.com/entry/2024/11/11/204512"/> <meta property="og:image" content="https://cdn.image.st-hatena.com/image/scale/22746db9dd919c83ed010f06efc44b2de9af03c2/backend=imagemagick;height=1300;version=1;width=1300/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmtx2s%2F20241111%2F20241111202606.png"/> <meta property="og:image:alt" content="アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある - mtx2s’s blog"/> <meta property="og:description" content="「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から…" /> <meta property="og:site_name" content="mtx2s’s blog"/> <meta property="article:published_time" content="1731325512" /> <meta name="twitter:card" content="summary_large_image" /> <meta name="twitter:image" content="https://cdn.image.st-hatena.com/image/scale/22746db9dd919c83ed010f06efc44b2de9af03c2/backend=imagemagick;height=1300;version=1;width=1300/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmtx2s%2F20241111%2F20241111202606.png" /> <meta name="twitter:title" content="アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある - mtx2s’s blog" /> <meta name="twitter:description" content="「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。そこに、ウォーターフォールを学ぶことに対する価値がある…" /> <meta name="twitter:app:name:iphone" content="はてなブログアプリ" /> <meta name="twitter:app:id:iphone" content="583299321" /> <meta name="twitter:app:url:iphone" content="hatenablog:///open?uri=https%3A%2F%2Fmtx2s.hatenablog.com%2Fentry%2F2024%2F11%2F11%2F204512" /> <meta name="twitter:site" content="@mtx2s" /> <meta name="description" content="「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から…" /> <script id="embed-gtm-data-layer-loader" data-data-layer-page-specific="{"hatenablog":{"blogs_permalink":{"is_author_pro":"false","blog_afc_issued":"false","has_related_entries_with_elasticsearch":"true","entry_afc_issued":"false","is_blog_sleeping":"false"}}}" > (function() { function loadDataLayer(elem, attrName) { if (!elem) { return {}; } var json = elem.getAttribute(attrName); if (!json) { return {}; } return JSON.parse(json); } var globalVariables = loadDataLayer( document.documentElement, 'data-data-layer' ); var pageSpecificVariables = loadDataLayer( document.getElementById('embed-gtm-data-layer-loader'), 'data-data-layer-page-specific' ); var variables = [globalVariables, pageSpecificVariables]; if (!window.dataLayer) { window.dataLayer = []; } for (var i = 0; i < variables.length; i++) { window.dataLayer.push(variables[i]); } })(); </script>  <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-P4CXTW');</script>  <link rel="shortcut icon" href="https://mtx2s.hatenablog.com/icon/favicon"> <link rel="apple-touch-icon" href="https://mtx2s.hatenablog.com/icon/touch"> <link rel="icon" sizes="192x192" href="https://mtx2s.hatenablog.com/icon/link"> <link rel="alternate" type="application/atom+xml" title="Atom" href="https://mtx2s.hatenablog.com/feed"/> <link rel="alternate" type="application/rss+xml" title="RSS2.0" href="https://mtx2s.hatenablog.com/rss"/> <link rel="alternate" type="application/json+oembed" href="https://hatena.blog/oembed?url=https%3A%2F%2Fmtx2s.hatenablog.com%2Fentry%2F2024%2F11%2F11%2F204512&format=json" title="oEmbed Profile of アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある"/> <link rel="alternate" type="text/xml+oembed" href="https://hatena.blog/oembed?url=https%3A%2F%2Fmtx2s.hatenablog.com%2Fentry%2F2024%2F11%2F11%2F204512&format=xml" title="oEmbed Profile of アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある"/> <link rel="author" href="http://www.hatena.ne.jp/mtx2s/"> <link rel="stylesheet" type="text/css" href="https://cdn.blog.st-hatena.com/css/blog.css?version=b06a9d4929119667e7027e25c25079"/> <link rel="stylesheet" type="text/css" href="https://usercss.blog.st-hatena.com/blog_style/26006613499892765/9363c9f0355695f631bb085a6705741e86e25c3f"/> <script> </script> <style> div#google_afc_user, div.google-afc-user-container, div.google_afc_image, div.google_afc_blocklink { display: block !important; } </style> <script src="https://cdn.pool.st-hatena.com/valve/valve.js" async></script> <script id="test-valve-definition"> var valve = window.valve || []; valve.push(function(v) { v.config({ service: 'blog', content: { result: 'adtrust', documentIds: ["blog:entry:6802418398301277587"] } }); v.defineDFPSlot({"lazy":1,"sizes":{"mappings":[[[320,568],[[336,280],[300,250],"fluid"]],[[0,0],[[300,250]]]]},"slotId":"ad-in-entry","unit":"/4374287/blog_pc_entry_sleep_in-article"}); v.defineDFPSlot({"lazy":"","sizes":[[300,250],[336,280],[468,60],"fluid"],"slotId":"google_afc_user_container_0","unit":"/4374287/blog_user"}); v.sealDFPSlots(); }); </script> <script type="application/ld+json">{"@context":"http://schema.org","@type":"Article","dateModified":"2024-11-12T09:41:09+09:00","datePublished":"2024-11-11T20:45:12+09:00","headline":"アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある","image":["https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241111/20241111202606.png"]}</script> <meta name="google-site-verification" content="-ggAavnEPzrRliqZaSP46C8MJ0InNh0MDAL0791yYqI" /> </head> <body class="page-entry globalheader-ng-enabled"> <div id="globalheader-container" data-brand="hatenablog" > <iframe id="globalheader" height="37" frameborder="0" allowTransparency="true"></iframe> </div> <nav class=" blog-controlls "> <div class="blog-controlls-blog-icon"> <a href="https://mtx2s.hatenablog.com/"> <img src="https://cdn.image.st-hatena.com/image/square/b1c5979b7977f3d148624e0a142dfbc70a05973c/backend=imagemagick;height=128;version=1;width=128/https%3A%2F%2Fcdn.user.blog.st-hatena.com%2Fblog_custom_icon%2F155726877%2F1630825902998259" alt="mtx2s’s blog"/> </a> </div> <div class="blog-controlls-title"> <a href="https://mtx2s.hatenablog.com/">mtx2s’s blog</a> </div> <a href="https://blog.hatena.ne.jp/mtx2s/mtx2s.hatenablog.com/subscribe?utm_campaign=subscribe_blog&utm_source=blogs_topright_button&utm_medium=button" class="blog-controlls-subscribe-btn test-blog-header-controlls-subscribe"> 読者になる </a> </nav> <div id="container"> <div id="container-inner"> <header id="blog-title" data-brand="hatenablog"> <div id="blog-title-inner" > <div id="blog-title-content"> <h1 id="title"><a href="https://mtx2s.hatenablog.com/">mtx2s’s blog</a></h1> <h2 id="blog-description">エンジニアリングをエンジニアリングする。</h2> </div> </div> </header> <div id="content" class="hfeed" > <div id="content-inner"> <div id="wrapper"> <div id="main"> <div id="main-inner">   <article class="entry hentry test-hentry js-entry-article date-first autopagerize_page_element chars-20000 words-800 mode-markdown entry-odd" id="entry-6802418398301277587" data-keyword-campaign="" data-uuid="6802418398301277587" data-publication-type="entry"> <div class="entry-inner"> <header class="entry-header"> <div class="date entry-date first"> <a href="https://mtx2s.hatenablog.com/archive/2024/11/11" rel="nofollow"> <time datetime="2024-11-11T11:45:12Z" title="2024-11-11T11:45:12Z"> <span class="date-year">2024</span><span class="hyphen">-</span><span class="date-month">11</span><span class="hyphen">-</span><span class="date-day">11</span> </time> </a> </div> <h1 class="entry-title"> <a href="https://mtx2s.hatenablog.com/entry/2024/11/11/204512" class="entry-title-link bookmark">アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある</a> </h1> </header> <div class="entry-content hatenablog-entry"> <p><figure class="figure-image figure-image-fotolife" title=""><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241111/20241111202606.png" width="1200" height="675" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></figure> 「すべてのライフサイクルモデルの祖は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>モデルである」とは、<a href="https://www.amazon.co.jp/dp/B0DHYGFVPX/">スティーブ・マコネルの言葉</a>だ<sup id="fnref:sm1-1"><a href="#fn:sm1" rel="footnote">1</a></sup>。また、ソフトウェア開発ライフサイクル（SDLC）に関する<a href="https://resources.github.com/ja/software-development/what-is-sdlc/">GitHubの文書</a>では、広く採用された最初のSDLCが<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>モデルであるとされている<sup id="fnref:gh1-1"><a href="#fn:gh1" rel="footnote">2</a></sup>。</p> <p>そこに、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>を学ぶことに対する価値がある。それは、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%E9%A5%E0">スクラム</a>を導入し、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>モデルであろうと、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>から派生したり、何らかの影響を受けていると考えられる。したがって、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>への理解から、自分達がやっていることの本質を見いだせるのではないだろうか。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>なんて誰でも知っていると思うかもしれないが、そうとも限らない。確かに<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>未経験のソフトウェア開発者は少ないだろう。しかし、そこで実践した手法は、組織ごとにカスタマイズされていたり、見よう見まねで実践されたものが多いのではないか。そして、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>を当たり前に利用する組織では、その採用理由について考えることもあまりない。</p> <p>本稿は、歴史的側面から<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の理解を深め、組織が現在採用している開発手法にその学びを活かせるようになることをテーマとしている。</p> <ul class="table-of-contents"> <li><a href="#ソフトウェア危機とボトムアップアプローチ">ソフトウェア危機とボトムアップ・アプローチ</a></li> <li><a href="#ボトムアップアプローチからトップダウンアプローチへ">ボトムアップ・アプローチからトップダウン・アプローチへ</a></li> <li><a href="#トップダウンアプローチを説明するためのウォーターフォールという概念">トップダウン・アプローチを説明するためのウォーターフォールという概念</a></li> <li><a href="#誤った理解に基づくウォーターフォール">誤った理解に基づくウォーターフォール</a></li> <li><a href="#ウォーターフォールの手戻り問題">ウォーターフォールの手戻り問題</a></li> <li><a href="#本来想定されていたウォーターフォールロイスのソフトウェア開発モデル">本来想定されていたウォーターフォール（ロイスのソフトウェア開発モデル）</a></li> <li><a href="#IEEEEIA-12207が挙げる3つの開発戦略とウォーターフォールの関係">IEEE/EIA 12207が挙げる3つの開発戦略とウォーターフォールの関係</a></li> <li><a href="#修正版ウォーターフォール">修正版ウォーターフォール</a><ul> <li><a href="#Sashimi-Waterfall-with-Overlapping-Phases">Sashimi (Waterfall with Overlapping Phases)</a></li> <li><a href="#Waterfall-with-Subprojects">Waterfall with Subprojects</a></li> <li><a href="#Waterfall-with-Risk-Reduction">Waterfall with Risk Reduction</a></li> </ul> </li> <li><a href="#リレー方式ウォーターフォールからサシミ方式修正版ウォーターフォールラグビー方式へ">リレー方式（ウォーターフォール）からサシミ方式（修正版ウォーターフォール）、ラグビー方式へ</a></li> <li><a href="#軽量級プロセスアジャイル系開発プロセスと重量級プロセスウォーターフォール">軽量級プロセス（アジャイル系開発プロセス）と重量級プロセス（ウォーターフォール）</a></li> <li><a href="#まとめ">まとめ</a></li> <li><a href="#参考文献">参考文献</a></li> </ul> <h2 id="ソフトウェア危機とボトムアップアプローチ">ソフトウェア危機と<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%DC%A5%C8%A5%E0%A5%A2%A5%C3%A5%D7">ボトムアップ</a>・アプローチ</h2> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/NATO">NATO</a><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%BD%A5%D5%A5%C8%A5%A6%A5%A7%A5%A2%B9%A9%B3%D8">ソフトウェア工学</a>会議がドイツのガーミッシュで開催された1968年当時は、「ソフトウェア危機」に瀕した時代だった。拡大を続けるソフトウェアの需要に対し、まだまだ未熟な分野であったソフトウェア開発の生産性が追いつかなかったのだ。「<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%BD%A5%D5%A5%C8%A5%A6%A5%A7%A5%A2%B9%A9%B3%D8">ソフトウェア工学</a>（software engineering）」という用語も、この会議によってようやく広まった時代である<sup id="fnref:br1-1"><a href="#fn:br1" rel="footnote">3</a></sup>。</p> <p>ソフトウェア危機は、ソフトウェア開発プロジェクトを進めるうえで、次のような症状として現れる<sup id="fnref:sc1-1"><a href="#fn:sc1" rel="footnote">4</a></sup>。</p> <ul> <li>品質が低い</li> <li>予算を超過する</li> <li>納期に遅れる/納品に至らない</li> <li>要求仕様を満たさない</li> <li>コードの保守が困難</li> <li>プロジェクトがコン<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%ED%A1%BC%A5%EB">トロール</a><a class="keyword" href="https://d.hatena.ne.jp/keyword/%C9%D4%C7%BD">不能</a>に陥る</li> </ul> <p>これらを見ると分かるように、残念ながらソフトウェア危機は今なお続いている。現在のソフトウェア業界でも、このようなプロジェクトを見聞きすることなど珍しくもない。</p> <p>しかし、当時は今より状況が酷かったようだ。ロバート・C・マーチン（Robert C. Martin）は、18歳だった1970年当時を振り返り、ソフトウェア開発の実情を次のように述べている。疲弊していた様子が伝わってくる。</p> <blockquote><p>我々はどのようなプロセスを使っていたのだろうか？　<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>ではなかったことは確実だ。詳細な計画に従うという概念など持っていなかった。毎日のように、ハックして、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B3%A5%F3%A5%D1%A5%A4%A5%EB">コンパイル</a>して、テストして、バグを修正していただけだ。構造を持たない無限ループだった。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>でもない。プレ・<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>でもなかった。我々の仕事のやり方に規律はなかった。テストスイートもなかった。決められた時間間隔もなかった。毎日のようにコードを書いて修正して、毎月のようにコードを書いて修正していた。</p></blockquote> <p><span style="font-size: 70%"><a href="https://www.kadokawa.co.jp/product/302007001102/">Robert C. Martin (著), 角征典 (翻訳), 角谷信太郎 (翻訳), "Clean Agile 基本に立ち戻れ", KADOKAWA, 2020, 第1章</a> より引用<sup id="fnref:rm1-1"><a href="#fn:rm1" rel="footnote">5</a></sup></span></p> <p>1960年代頃はまだ、「<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%DC%A5%C8%A5%E0%A5%A2%A5%C3%A5%D7">ボトムアップ</a>・アプローチ」によるソフトウェア開発が行われていた。当時のその手法の詳細は不明であるが、一般的には、小さな部品をまず設計・実装し、それらを組み合わせて徐々にシステム全体を構築する手法だろう。このやり方だけでは、全体像が最初に見えにくく、後から統合する際に不整合が生じやすい。この言葉は、トーマス・E・ベル（Thomas E. Bell）とT・A・セイヤー（T. A. Thayer）による1976年の論文 "Software requirements: Are they really a problem?" <sup id="fnref:bt1-1"><a href="#fn:bt1" rel="footnote">6</a></sup>に、過去のやり方として登場する。後述するが、この論文は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>とも関連が深いものだ。</p> <h2 id="ボトムアップアプローチからトップダウンアプローチへ"><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%DC%A5%C8%A5%E0%A5%A2%A5%C3%A5%D7">ボトムアップ</a>・アプローチから<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチへ</h2> <p>それまでの<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%DC%A5%C8%A5%E0%A5%A2%A5%C3%A5%D7">ボトムアップ</a>・アプローチより<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチの方が優れている、1970年前後の開発現場の多くでそう結論付けられた。ベルとセイヤーによる先述の論文で、そう述べられている。</p> <p>彼らが「<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチ」と呼んだソフトウェア開発は、システム全体の要件定義から始め、段階的に詳細化していくものだ。各フェーズの成果物はドキュメントとしてアウトプットされ、次のフェーズのインプットとなる。そうして実装・<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C7%A5%D0%A5%C3%A5%B0">デバッグ</a>フェーズやテストフェーズへと続いていく。ベルとセイヤーは、それをFigure 1として次のような図であらわした。</p> <p><figure class="figure-image figure-image-fotolife" title=""><blockquote><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241110/20241110141154.png" width="1200" height="953" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></blockquote><figcaption>ベルとセイヤーがFigure 1として示した<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチの各フェーズ<br /><span style="font-size: 70%">出典: <a href="https://dl.acm.org/doi/10.5555/800253.807650">T. E. Bell, T. A. Thayer, "Software requirements: Are they really a problem?", 1976, Figure 1</a></span></figcaption></figure></p> <p>フェーズは次のように分けられている。</p> <pre class="code" data-lang="" data-unlink>1. システム要件 2. ソフトウェア要件 3. 予備設計と詳細設計 5. 実装とデバッグ 6. 開発テスト 7. 公式テスト 8. 運用と保守</pre> <p>このアプローチが優れているとされたのは、はじめに全体像を描き、何をどう作るかについて、順を追って明らかにしようとする点だ。それ以前の主流であった<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%DC%A5%C8%A5%E0%A5%A2%A5%C3%A5%D7">ボトムアップ</a>・アプローチと違い、これなら不整合を生じさせにくい。理にかなっている、誰もがそう信じられるほどの説得力があった。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチは、ソフトウェア危機への対策となり得た。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%DC%A5%C8%A5%E0%A5%A2%A5%C3%A5%D7">ボトムアップ</a>だけに頼った行き当たりばったりなやり方では駄目だと、皆が気づいたのだ。</p> <h2 id="トップダウンアプローチを説明するためのウォーターフォールという概念"><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチを説明するための<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>という概念</h2> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチは、開発活動を<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>（滝）にたとえることでシンプルに説明できる。それを図として示したのが、ウィンストン・W・ロイス（Winston W. <a class="keyword" href="https://d.hatena.ne.jp/keyword/Royce">Royce</a>）による1970年の論文だった<sup id="fnref:wr1-1"><a href="#fn:wr1" rel="footnote">7</a></sup>。それが次の図であり、論文内ではFigure 2として登場する。フェーズの階層を水が落ちていくようにプロジェクトが進んでいくさまが、滝のように見えるのだ。</p> <p><figure class="figure-image figure-image-fotolife" title=""><blockquote><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241110/20241110142427.png" width="1200" height="764" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></blockquote><figcaption>ロイスがFigure 2として示した大規模コンピュータプログラムを開発するための実装ステップ<br /><span style="font-size: 70%">出典: <a href="https://dl.acm.org/doi/10.5555/41765.41801">Winston W. Royce, "Managing the development of large software systems", 1970, Figure 2</a></span></figcaption></figure></p> <p>ただし、この様子を「<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>（waterfall）」にたとえたのは、ベルとセイヤーだ。当のロイスの論文内にその単語は出てこない。彼らが1976年に書かれた先述の論文内で、参考文献として挙げたロイスの論文に対して使われた言葉であった。ロイスの論文の6年後のことである。ベルとセイヤーのFigure 1が、ロイスのFigure 2とそっくりなのはそのためだろう。なお、フェーズ分けは異なっており、ロイス版は次のように並んでいる。</p> <pre class="code" data-lang="" data-unlink>1. システム要件 2. ソフトウェア要件 3. 分析 5. プログラム設計 6. 実装 7. テスト 8. 運用</pre> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>という言葉は、ベルとセイヤーによるこの1976年の論文が初出ではないかとも言われているが<sup id="fnref:to1-1"><a href="#fn:to1" rel="footnote">8</a></sup>、その真偽は定かではない。マーチンは、それより4年早い1972年頃に、当時の業界誌で<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>をはじめて目にしたと述べている<sup id="fnref:rm1-2"><a href="#fn:rm1" rel="footnote">5</a></sup>。</p> <h2 id="誤った理解に基づくウォーターフォール">誤った理解に基づく<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a></h2> <p>マーチンによれば、当時広まり始めた<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>モデルは、誤った理解に基づくものだと言う<sup id="fnref:sm1-2"><a href="#fn:sm1" rel="footnote">1</a></sup>。ロイスの論文2ページめに現れるFigure 2だけを見て内容を推測した人たちの誤解によるものだと言うのだ。</p> <p>それは、どのようなモデルとして理解され、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>という言葉と紐づけられて広まったのだろうか。</p> <p>1996年に出版された書籍『<a href="https://www.amazon.co.jp/dp/B0DHYGFVPX/">Rapid Development</a>』の中で、マコネルが<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の特徴を説明している<sup id="fnref:sm1-3"><a href="#fn:sm1" rel="footnote">1</a></sup>。彼はこれを「純粋な<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>（pure waterfall）」と呼んだ。それを整理して要約すると次のようになる。これが、当時から今もなお続く、一般的な<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の理解だろう。ドキュメントを駆使することでプロセスを動かす前提であることがうかがえる。</p> <ul> <li><strong>段階的進行</strong>: ソフトウェアコンセプトから<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B7%A5%B9%A5%C6%A5%E0%A5%C6%A5%B9%A5%C8">システムテスト</a>まで、各フェーズを順番に進める</li> <li><strong>フェーズ完結型</strong>: 現フェーズのすべてのタスクが完了したとみなされるまで、次フェーズに進めない</li> <li><strong>ドキュメント駆動</strong>: 各フェーズのアウトプットはドキュメントであり、それが次フェーズのインプットとして引き継がれる</li> <li><strong>ドキュメントによる<a class="keyword" href="https://d.hatena.ne.jp/keyword/%BF%CA%C4%BD%B4%C9%CD%FD">進捗管理</a></strong>: ドキュメントが全体の進捗を示す指標として機能する</li> <li><strong>人員が不連続</strong>: フェーズごとに担当者が異なり、プロセス全体を通して人員の連続性がない（ドキュメントによってそれを繋いでいる）</li> </ul> <p>なお、ここでの<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の流れは、次のようにフェーズが分解されていることが前提とされている。</p> <pre class="code" data-lang="" data-unlink>1. ソフトウェアコンセプト 2. 要求分析 3. アーキテクチャ設計 4. 詳細設計 5. 実装とデバッグ 6. システムテスト</pre> <p>マコネルはまた、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>が適しているプロジェクトについても述べている。それを整理・要約したものが次の内容だ。最後の項目以外は総じて、不確実性が低く、予測可能性が高いプロジェクトに向いているということだろう。</p> <ul> <li><strong>要件が安定しているプロジェクト</strong>: プロジェクトの初期段階で要件が明確で変わることが少ないのであれば、計画的に進められる</li> <li><strong>既存システムのメンテナンスリリースプロジェクト</strong>: 既存システムの改修であれば、不確実性が低く、要件のぬけもれなどによる手戻りが生じにくい</li> <li><strong>別のプラットフォームへの移行プロジェクト</strong>: 既存システムを別のプラットフォームに移行する場合、要件が明確であるため、比較的に計画通り進めやすい</li> <li><strong>よく理解している技術的方法論を利用するプロジェクト</strong>: チームが十分に理解している技術や手法を用いるプロジェクトでは、比較的に精度の高い計画と設計で進められる</li> <li><strong>よく理解しているが複雑なプロジェクト</strong>: 複雑であっても要件が明確であるなら、その複雑性をフェーズごとに段階的に詳細化して進められる</li> <li><strong>未熟なメンバーがいるプロジェクト</strong>: 技術的に弱いスタッフや経験の浅いスタッフがいても、明確なフェーズと手順により、メンバーが作業しやすくなる</li> <li><strong>品質が最優先のプロジェクト</strong>: 品質が優先されるのであれば、コストや納期を超過しても、フェーズごとに十分な品質を担保しながら進められる</li> </ul> <p>マーチンは、当時を振り返り、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>をはじめて目にした時に、「天の恵み」だと感じたと言う<sup id="fnref:rm1-3"><a href="#fn:rm1" rel="footnote">5</a></sup>。しかし、実践したものの、このような<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>はうまくいかなかったようだ。</p> <p>それでは、ロイスが本来示そうとしたソフトウェア開発モデルとはどういったものだったのだろうか。それについて詳しく見る前に、ロイスも指摘する<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>的なソフトウェア開発に関する問題点について見てみることにする。</p> <h2 id="ウォーターフォールの手戻り問題"><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の手戻り問題</h2> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の代表的な問題点の1つは、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B2%BC%CE%AE">下流</a>のフェーズから上流のフェーズへの手戻りリスクが大きくなることだ。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>でのそれぞれのフェーズは、先行フェーズのアウトプットをインプットとして進められる。そこに欠陥があれば、原因を作ったフェーズまで差し戻して修正しなければならない。上流でのその修正の影響によって、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B2%BC%CE%AE">下流</a>で既に着手したり完了していた作業を台無しにするかもしれないのだ。この問題は、ロイスの論文でも指摘されている。</p> <p>これは、メタファとされる「滝」とは少々印象が異なる。滝というものは、下段に落ちた水が上段に戻ることがない。しかし、実際の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチでのソフトウェア開発では、どうしても上流のフェーズに戻ることがあるのだ。マーチンは、「天の恵み」であるはずの<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>がうまくいなかった様子を、次のように述べている<sup id="fnref:rm1-4"><a href="#fn:rm1" rel="footnote">5</a></sup>。</p> <blockquote><p>だが、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>はうまくいかなかった。それから30年間、私と同僚たちは、そして世界中の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D7%A5%ED%A5%B0%A5%E9%A5%DE%A1%BC">プログラマー</a>たちは、分析や設計が正しくできるように、何度も何度も何度も試行錯誤を重ねた。だが、どれだけ正しくやったと思っても、実装フェーズになると指の間からこぼれ落ちていく。マネージャーや顧客から厳しい眼差しを向けられるため、何か月もかけて慎重に計画を立ててみるが、それでも大幅に遅れてしまう。</p></blockquote> <p><span style="font-size: 70%"><a href="https://www.kadokawa.co.jp/product/302007001102/">Robert C. Martin (著), 角征典 (翻訳), 角谷信太郎 (翻訳),『Clean Agile 基本に立ち戻れ』, KADOKAWA, 2020, 第1章</a> より引用</span></p> <p>「それから30年間」と言うのは、彼が<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>を知った1972年から数えるとおおよそ2000年頃にあたる。1980年代後半から1990年代初頭に<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>改革が始まったが、<a href="https://agilemanifesto.org/iso/ja/manifesto.html">アジャイルソフトウェア開発宣言</a>が2001年だ<sup id="fnref:ag1-1"><a href="#fn:ag1" rel="footnote">9</a></sup>。おそらく、30年間というのは、そこまでの期間を指しているのではないか。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の手戻りについて、ロイスの論文内ではFigure 3として、次のような図が描かれている。隣り合うフェーズの間で反復が生じている様子が分かる。いったん次のフェーズに進んでも、そこで気付いた問題によって、前のフェーズで見直しが入ることを示しているのだ。</p> <p><figure class="figure-image figure-image-fotolife" title=""><blockquote><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241110/20241110144632.png" width="1200" height="737" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></blockquote><figcaption>ロイスがFigure 3として示した先行フェーズへの手戻り<br /><span style="font-size: 70%">出典: <a href="https://dl.acm.org/doi/10.5555/41765.41801">Winston W. Royce, "Managing the development of large software systems", 1970, Figure 3</a></span></figcaption></figure></p> <p>この図のように1つ前のフェーズに戻るだけなら理想的だ。影響は最小限にとどまる。</p> <p>しかし、実際には2つ以上前のフェーズに戻るリスクがあるとロイスは断言している。こうなると話は違ってくる。それが、Figure 4だ。</p> <p><figure class="figure-image figure-image-fotolife" title=""><blockquote><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241110/20241110145202.png" width="1200" height="689" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></blockquote><figcaption>ロイスがFigure 4として示したフェーズを越えた手戻り<br /><span style="font-size: 70%">出典: <a href="https://dl.acm.org/doi/10.5555/41765.41801">Winston W. Royce, "Managing the development of large software systems", 1970, Figure 4</a></span></figcaption></figure></p> <p>これについて、ロイスは次のように述べている。テストによって発見された問題が、設計変更を生じさせ、それが要件の変更にまで遡る可能性を示唆しているのだ。</p> <blockquote><p>The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.</p> <p>必要な設計変更は、設計のベースでありすべての根拠となるソフトウェア要件に違反するほど破壊的になる可能性がある。要件の修正か、設計の大幅変更が求められる。事実上、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>ははじめに戻り、スケジュールやコストは100％超過することが予想される。</p></blockquote> <p><span style="font-size: 70%"> <a href="https://dl.acm.org/doi/10.5555/41765.41801">Winston W. Royce, "Managing the development of large software systems", 1970</a> より引用（日本語訳は筆者によるもの）</span></p> <p>マコネルは、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>における手戻りを、「命がけ」での鮭の滝登りにたとえているが<sup id="fnref:sm1-4"><a href="#fn:sm1" rel="footnote">1</a></sup>、ロイスの指摘はまさにそれを説明したものだ。</p> <p>ベルとセイヤーの論文でも、特に要件の間違いを問題視している。初期に定義された要件は、不正確であったり、曖昧、矛盾、欠落することがある。それが、設計や実装の段階になって問題を生じさせるのだ。彼らの調査では、要件には以下のような欠陥のタイプがみられ、いずれのプロジェクトであってもその相対的な発生頻度は似通っていた。特に、4系の<code>Requirement Incorrect</code>や、3系の<code>Missing/Incomplete/Inadequate</code>, 7系の<code>Requirement Unclear</code>が多い。また、設計する段階になって初めて、これらの要件の欠陥を検出することが多かったようだ。</p> <p><figure class="figure-image figure-image-fotolife" title=""><blockquote><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241110/20241110145407.png" width="838" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></blockquote><figcaption><span style="font-size: 70%">出典: <a href="https://dl.acm.org/doi/10.5555/800253.807650">T. E. Bell, T. A. Thayer, "Software requirements: Are they really a problem?", 1976, Table 2</a></span></figcaption></figure></p> <p>実装を進める前に、完璧な要件や分析、設計を見出すことは難しい。それを実行するのが<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>の専門家であっても、ソフトウェア開発の専門家でもだ。単純な要件項目であっても、実際に動くソフトウェアを見るまでは、気付かないことも多い。膨大な時間をかけて要件をかため、分析し、設計したところで、おそらく状況は大きく変わらない。むしろ、要件や分析、設計が1度で完全になることなどない前提で、プロセスを組み立てた方が現実的なのだろう。</p> <h2 id="本来想定されていたウォーターフォールロイスのソフトウェア開発モデル">本来想定されていた<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>（ロイスのソフトウェア開発モデル）</h2> <p>前節の問題に対して、ロイスは論文内で5つの対策を提案している。これが、本来、彼が提示していたソフトウェア開発モデルだ。</p> <ol> <li><strong>プログラム設計を先に実施する</strong>: 分析に先だってプログラム設計者が予備的なプログラム設計を行い、その結果を分析に対する技術的制約として分析者に引き継ぐ</li> <li><strong>設計をドキュメント化する</strong>: ソフトウェアの管理は、非常に高度なドキュメントなしには不可能であり、徹底したドキュメント化が重要。それを関係者や顧客とのコミュニケーションの基盤とし、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A8%A5%D3%A5%C7%A5%F3%A5%B9">エビデンス</a>として利用する。納品時は、予備設計に関するドキュメント以外はすべて最新の状態にすること</li> <li><strong>2回実施する（do it twice）</strong>: 要件が固まった段階で<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D1%A5%A4%A5%ED">パイロ</a>ットプロジェクトを走らせ、初期バージョンのシステムを作って<a class="keyword" href="https://d.hatena.ne.jp/keyword/%C0%F8%BA%DF%C5%AA">潜在的</a>な問題を洗い出す。顧客に引き渡すシステムは、その結果を反映して開発したバージョンとする</li> <li><strong>テストを計画、管理、監視する</strong>: 1~3までで品質を十分に確保したうえで、テストの専門家による網羅的で明確な基準を持ったテストを計画・実施し、その進捗を管理する</li> <li><strong>顧客を巻き込む</strong>: ソフトウェア設計で何をやるかは事前の合意後も解釈に幅があるため、最終的な納品前の早い段階で顧客がコミットするよう、彼らを巻き込むことが重要である</li> </ol> <p><figure class="figure-image figure-image-fotolife" title=""><blockquote><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241110/20241110150326.png" width="1200" height="927" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></blockquote><figcaption>5つの対策を含めたロイスのソフトウェア開発モデル全体像<br /> （1の予備的プログラム設計は3番目のフェーズとして分析フェーズの前に挿入されている / 2のドキュメントは、図中に置かれた本のような図形を指す / 3の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D1%A5%A4%A5%ED">パイロ</a>ットプロジェクトは図の中央上段にある6つのフェーズのことであり、最後のusageフェーズは「試用」や「評価」を指す / 4は特にプログラム設計フェーズとテストフェーズから伸びているテスト仕様書への線付近を指す / 5での顧客の関与は図中の丸い画像でのレビューなど）<br /> <span style="font-size: 70%">出典: <a href="https://dl.acm.org/doi/10.5555/41765.41801">Winston W. Royce, "Managing the development of large software systems", 1970, Figure 10</a></span></figcaption></figure></p> <p>1で分析より先にプログラム設計を実施することで、プロセスが部分的に<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%DC%A5%C8%A5%E0%A5%A2%A5%C3%A5%D7">ボトムアップ</a>・アプローチになる。こうすれば、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>（<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチ）の弱点を補うことができる。</p> <p>3の「2回実施する（do it twice）」は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A5%C7%A5%EA%A5%C3%A5%AF">フレデリック</a>・P・<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D6%A5%EB%A5%C3%A5%AF%A5%B9">ブルックス</a> Jr.（Frederick P. Brooks, Jr.）の「一つは捨石にするつもりで（throw one away）」に似たア<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A4%A5%C7%A5%A2">イデア</a>だ<sup id="fnref:fb1-1"><a href="#fn:fb1" rel="footnote">10</a></sup>。最初に完成したシステムは使い物にならないから、先に<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D1%A5%A4%A5%ED">パイロ</a>ットシステムを作ってみる。そしてそれを破棄し、再度デザインして問題が解決したバージョンを正規版として提供する。これが、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D6%A5%EB%A5%C3%A5%AF%A5%B9">ブルックス</a>の主張だ。考えてみれば、これが書かれた書籍『人月の神話』の初版本の出版が1975年だから、時期的にはロイスの論文と同じ頃のものである。</p> <p>注意が必要なのは、ロイスの言う<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D1%A5%A4%A5%ED">パイロ</a>ットプロジェクトは、要件が固まり、予備的設計が終わったあとに開始される点だ。そこから、技術的な問題点を洗い出して、洗練させることがその主目的であると思われる。そこに割く時間は、本来のプロジェクト期間の4分の1から3分の1程度としている。</p> <p>5の「顧客を巻き込む」の必要性について、ロイスは次のように述べている。要件や設計は、顧客との間でどれだけ精緻に<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B8%C0%B8%EC%B2%BD">言語化</a>して事前合意していても、それだけでは不十分なのだ。</p> <blockquote><p>For some reason what a <a class="keyword" href="https://d.hatena.ne.jp/keyword/software%20design">software design</a> is going to do is subject to wide interpretation even after previous agreement.</p> <p>ソフトウェア設計が何をしようとしているかに対しては、事前に合意を得ていても、解釈が大きく分かれることがある。</p></blockquote> <p><span style="font-size: 70%"> <a href="https://dl.acm.org/doi/10.5555/41765.41801">Winston W. Royce, "Managing the development of large software systems", 1970</a> より引用（日本語訳は筆者によるもの）</span></p> <p>なお、顧客とプロジェクトマネージャーを除くと、ロイスの論文内には少なくとも次の役割が登場する。各フェーズごとに担当者が分かれていることを前提としているということだろう。2でドキュメント化を重視する理由には、フェーズ間での引き継ぎで利用する意図もあるのだ。</p> <ul> <li><strong>分析者</strong>: 分析フェーズを担当</li> <li><strong>プログラム設計者</strong>: 予備的プログラム設計とプログラム設計を担当</li> <li><strong><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D7%A5%ED%A5%B0%A5%E9%A5%DE">プログラマ</a></strong>: 実装を担当</li> <li><strong>テスト専門家</strong>: テストを担当</li> <li><strong>運用指向の人材</strong>: 運用を担当（ただし、優れたドキュメントがないなら、ソフトウェアを構築した人が運用も担当する方がましだとの記述あり）</li> </ul> <p>ロイスの改善案は、あくまでも1970年頃に書かれたものだという点を忘れてはならない。そのまま鵜呑みにせず、当時のソフトウェア開発環境を考慮すべきだろう。当然、ビルド、テスト、デプロイの自動化などの技術はまだ進んでいない。おそらく、テストを実施すること自体にも、計算機リソースを気にする必要もあっただろう。彼が極端にドキュメントに頼っているように感じるのも、そういった背景もあるのではないか。マーチンの書籍にもあるが、コーディング用紙に鉛筆でコードを書き、キーパンチオペレーターがそれをカードにパンチしていた時代である。</p> <h2 id="IEEEEIA-12207が挙げる3つの開発戦略とウォーターフォールの関係"><a class="keyword" href="https://d.hatena.ne.jp/keyword/IEEE">IEEE</a>/EIA 12207が挙げる3つの開発戦略と<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の関係</h2> <p>1998年に発行されたソフトウェア開発のプロセス標準である<a class="keyword" href="https://d.hatena.ne.jp/keyword/IEEE">IEEE</a>/EIA 12207の中で、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>という名が正式に登場した<sup id="fnref:ie1-1"><a href="#fn:ie1" rel="footnote">11</a></sup>。そこに至るまでの経緯は、次のブログ記事で既に詳しく解説されている。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%E1%A5%EA%A5%AB%B9%F1%CB%C9%C1%ED%BE%CA">アメリカ国防総省</a>が1985年に発行した<a class="keyword" href="https://d.hatena.ne.jp/keyword/DOD">DOD</a>-STD-2167や、その後継の2167Aからの変遷がよく分かるだろう。それらの文書がロイスの論文に強く影響を受けていることも感じられる。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2FYankeeDeltaBravo225%2Fitems%2F9f08c0eccd48f00b9f9e" title="ウォーターフォールを世に広めたとされる米軍がアジャイルに移行中という話 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://qiita.com/YankeeDeltaBravo225/items/9f08c0eccd48f00b9f9e">qiita.com</a></cite></p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/IEEE">IEEE</a>/EIA 12207.2の付録Iの中では、次の3つの開発戦略が比較されている<sup id="fnref:ie2-1"><a href="#fn:ie2" rel="footnote">12</a></sup>。プロジェクトの性質に合った開発戦略を選択しようという話だ。</p> <ul> <li><strong>Once-through</strong>: 開発サイクルを一回だけ実施する戦略。ユーザーニーズを把握し、要件を定義した後、設計、実装、テストを行い、修正を加えつつ最終的に納品する</li> <li><strong>Incremental</strong>: 最初にユーザーニーズとシステム全体の要件を定義した後、開発を段階的に進める戦略。最初の段階で一部の機能を実装し、次の段階でさらに機能を追加していき、最終的に全体を完成させる</li> <li><strong>Evolutionary</strong>: 初期の不完全なユーザーニーズや要件に基づいて開発を始め、段階的にシステムを洗練させていく戦略。各段階でユーザーニーズや要件を評価・調整しながら、完成形に向かって進化させる</li> </ul> <p>文書内では、開発サイクルを1回だけ実施するonce-through戦略の別名が「<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>」モデルだとしている。このことからも、当時の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>には、ロイスの開発モデルの特徴の1つである「2回実施する」が含まれていないことが分かる。</p> <p>「2回実施する」を発展させたものがincremental戦略に見えるかもしれないが、そうではないだろう。ロイスの開発モデルでは、先にプロトタイプを作ることで不確実性を削減し、そこで得た学びと経験によって最終プロダクトをあらためて確実に作るものであった。しかし、incrementalは、完成させるソフトウェアをいくつかに分け、それを段階的に積み上げながら全体を作り上げていくものだ。</p> <p>evolutionary戦略もincrementalと同様に開発サイクルを任意の回数繰り返すものだが、最初にすべての要件を定義しない点が大きく異なる。さらに、最終的なソフトウェアを完成させるまでのアプローチも違う。incrementalでは開発サイクルを繰り返すことで段階的に機能を追加していく。しかし、evolutionaryではユーザーニーズと要件をより明確にし、ソフトウェアシステムを洗練させていくことに主眼が置かれている。</p> <p><figure class="figure-image figure-image-fotolife" title="各開発戦略のイメージ"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241107/20241107072526.png" width="1200" height="675" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>各開発戦略のイメージ</figcaption></figure></p> <p>ところで、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%E9%A5%E0">スクラム</a>をはじめとする<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A1%BC%A5%E0%A5%EF%A1%BC%A5%AF">フレームワーク</a>は、incrementalとevolutionaryの特徴をかけ合わせた戦略とは言えないだろうか。スプリント（<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A4%A5%C6%A5%EC%A1%BC%A5%B7%A5%E7%A5%F3">イテレーション</a>）をまわしながらソフトウェアを段階的に作りあげる点ではincrementalだ。最初に要件をすべて定義せず、徐々に洗練・進化させていく点ではevolutionaryである。つまり、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発は、once-throughである<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>と明確に異なる特徴を持つということだろう。</p> <p>なお、同文書の中では、3つの開発戦略をどのようなケースで利用すべきであるか、その例をリスク項目と機会項目分け、Figure I.2 として示している。</p> <p>その内容を見ると、once-through戦略、つまり<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>は、要件が明らかで不確実性が低く、規模が大きすぎず、予算や人員に対する制限が厳しくないプロジェクトに向いているとされている。それはやはり、手戻りリスクを案じてのことではないだろうか。</p> <p>これだけを見ると<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の用途が限定的に見えてしまうが、本当にそうなのか。実際に<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>開発を実践する現場を見ると、プロジェクトを数回に分けて実施することも多い。「フェーズ・ワン」「フェーズ・ツー」などと呼んで分けるのがそれだ。そうすれば、個々のプロジェクトは小さくなり、扱いやすくなる。また、同付録I内にも、要求分析とシステム<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A1%BC%A5%AD%A5%C6%A5%AF%A5%C1%A5%E3">アーキテクチャ</a>設計の後に、プロジェクトを複数のサブプロジェクトに分けて開発を進めるア<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A4%A5%C7%A5%A2">イデア</a>も載せられている。</p> <p>つまり、開発現場では、プロジェクトが置かれる実情に合わせ、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>に改良が加えられているのだ。次の節では、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の弱点を改善した修正版<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>をいくつか見てみることにする。</p> <h2 id="修正版ウォーターフォール">修正版<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a></h2> <p>マコネルが<a href="https://www.amazon.co.jp/dp/B0DHYGFVPX/">自著</a>の中で3つの修正版<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>（modified waterfalls）について解説している<sup id="fnref:sm1-5"><a href="#fn:sm1" rel="footnote">1</a></sup>。これらは<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の問題点を補うために発展したものだろう。</p> <p>それぞれの修正版モデルを見ると分かるが、いずれも現在はそれと知らずに開発手法に取り込まれているものではないだろうか。</p> <h3 id="Sashimi-Waterfall-with-Overlapping-Phases">Sashimi (Waterfall with Overlapping Phases)</h3> <p>このモデルでは、1つのフェーズが開始すると、それが完了する前に次のフェーズも開始する。2つ以上のフェーズの実施時期がオーバーラップするようにして進行するのだ。これが、サシミと<a class="keyword" href="https://d.hatena.ne.jp/keyword/%CC%BF%CC%BE">命名</a>された理由である。フェーズが重なり合うさまが、サシミの盛り付けに似ている。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%C9%D9%BB%CE%A5%BC%A5%ED%A5%C3%A5%AF%A5%B9">富士ゼロックス</a>の新製品開発で用いられた。</p> <p><figure class="figure-image figure-image-fotolife" title=""><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241111/20241111202734.png" width="1200" height="675" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>フェーズ間のオーバーラップ</figcaption></figure></p> <p>たとえば、要求分析フェーズを進めている最中に、次フェーズである<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A1%BC%A5%AD%A5%C6%A5%AF%A5%C1%A5%E3">アーキテクチャ</a>設計が開始され、詳細設計も始まっているかもしれない。こうすることで、より詳細なフェーズで気付いた問題点や学びを、並行して進行中の上位フェーズに反映しやすくなる。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>が抱えていた、段階的に詳細化していくことの難しさを考えると、これは合理的なモデルである。</p> <p>純粋な<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>モデルでは、フェーズの重複をできる限り避け、段階的に詳細化を進めるので対称的だ。フェーズの完了や、アウトプットであるドキュメントの完成状況で進捗を測ることができなくなるという欠点もあるだろう。</p> <p>しかし、このモデルでは、そもそも作成すべきドキュメントの数が削減される。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>でのドキュメントの存在意義のひとつは、フェーズ間での仕様や設計の引き継ぎであった。先行フェーズと後続フェーズで担当者が異なることが想定されているからだ。しかし、フェーズをオーバーラップさせてフィードバックサイクルを回すなら、担当者に連続性を持たせる方が合理的だろう。そうすれば引き継ぎの必要すらない。</p> <h3 id="Waterfall-with-Subprojects">Waterfall with Subprojects</h3> <p>詳細設計がすべて終わるまですべての実装を待つ必要はない、というのが、このモデルのコンセプトである。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A1%BC%A5%AD%A5%C6%A5%AF%A5%C1%A5%E3">アーキテクチャ</a>設計が完了したら、各サブシステムごとに詳細設計からテストまでを並行して進める。そして、最後にすべてをつなぎ合わせて<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B7%A5%B9%A5%C6%A5%E0%A5%C6%A5%B9%A5%C8">システムテスト</a>を実施するのだ。</p> <p>このモデルでは、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A1%BC%A5%AD%A5%C6%A5%AF%A5%C1%A5%E3">アーキテクチャ</a>設計の時点でサブシステム間の依存関係をうまく整理した上でサブプロジェクトにスピンオフできなければ、プロジェクトが混乱をきたすリスクがあるだろう。</p> <h3 id="Waterfall-with-Risk-Reduction">Waterfall with Risk Reduction</h3> <p>要件や<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A1%BC%A5%AD%A5%C6%A5%AF%A5%C1%A5%E3">アーキテクチャ</a>が抱える不確実性に起因するリスクをプロジェクトの最初に低減することが、このモデルの特徴だ。そのため、要求分析より前に、それらを検証するためのスパイラルを配置する。例として、マコネルは次のような活動を通して学びを得ることを挙げている。</p> <ul> <li><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E6%A1%BC%A5%B6%A1%BC%A5%A4%A5%F3%A5%BF%A1%BC%A5%D5%A5%A7%A5%A4%A5%B9">ユーザーインターフェイス</a>のプロトタイプを開発</li> <li>システムストーリーボーディングを使用</li> <li>ユーザーインタビューを実施</li> <li>ユーザーが古いシステムを操作しているところを撮影</li> </ul> <h2 id="リレー方式ウォーターフォールからサシミ方式修正版ウォーターフォールラグビー方式へ">リレー方式（<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>）からサシミ方式（修正版<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>）、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%B0%A5%D3%A1%BC">ラグビー</a>方式へ</h2> <p>ロイスの論文が<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>の起源と呼ばれることに対し、竹内弘高と<a class="keyword" href="https://d.hatena.ne.jp/keyword/%CC%EE%C3%E6%B0%EA%BC%A1%CF%BA">野中郁次郎</a>が書いた1986年の論文は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%E9%A5%E0">スクラム</a>の原点と言われる。それが、"<a href="https://hbr.org/1986/01/the-new-new-product-development-game">The New New Product Development Game</a>" だ。この中で、1970年代から1980年代にかけて、新規プロダクトの開発に新手法を取り入れた日本および<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%E1%A5%EA">アメリ</a>カの企業6社の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>を分析している。</p> <p>竹内と野中は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>を従来の「リレー方式」と、新たな手法とする「サシミ方式」「<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%B0%A5%D3%A1%BC">ラグビー</a>方式」の3つに分類した。リレー方式は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>のようにフェーズからフェーズと順番に進む「昔ながらの逐次型」とされている。サシミ方式は修正版<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>でも挙げた<a class="keyword" href="https://d.hatena.ne.jp/keyword/%C9%D9%BB%CE%A5%BC%A5%ED%A5%C3%A5%AF%A5%B9">富士ゼロックス</a>が用いたモデルだ。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%B0%A5%D3%A1%BC">ラグビー</a>方式も、サシミ方式と同様にフェーズをオーバーラップさせながら進めるもので、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%CB%DC%C5%C4%B5%BB%B8%A6%B9%A9%B6%C8">本田技研工業</a>やキャノンに見られるモデルである。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%B0%A5%D3%A1%BC">ラグビー</a>方式がサシミ方式と区別されているのは、前者のオーバーラップの多重度が後者より高いからだ。それは、リレー方式と比較する形で次のように述べられ、素早く柔軟に新規プロダクトを開発したい企業にとって「絶対に必要である」とされている。</p> <blockquote><p>一方、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%B0%A5%D3%A1%BC">ラグビー</a>方式だと、各部門から選び出されたメンバーが最初から最後まで一つのチームを構成し、製品<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>は、こうしたチームの絶え間ない相互作用から生まれてくる。そのプロセスは、きちんと境界線のある高度に構造化された段階を進んでいくのではなく、チームメンバー同士の相互作用から生じるのだ。</p></blockquote> <p><span style="font-size: 70%">引用: <a href="https://www.diamond.co.jp/digital/478117657700.html">竹内弘高 (著), 野中郁次郎 (著), DIAMONDハーバード・ビジネス・レビュー編集部 (編集), "新たなる新製品開発の方法（DIAMOND ハーバード・ビジネス・レビュー論文）", ダイヤモンド社, 2023</a></span></p> <p><figure class="figure-image figure-image-fotolife" title=""><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241111/20241111202820.png" width="1200" height="675" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>リレー方式、サシミ方式、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%B0%A5%D3%A1%BC">ラグビー</a>方式</figcaption></figure></p> <p>リレー方式を用いるリスクは、競争の激しい市場の中で抜きん出るための「スピードと柔軟性」という目標と相容れないおそれがあることとされる。専門化された個々のフェーズで分業体制を取り、段階的に進めるより、一体型の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%B0%A5%D3%A1%BC">ラグビー</a>方式の方が激しい競争環境により対応しやすいからだ。たとえば、リレー方式では、1つのフェーズで遅れが生じると、それが後続プロセスすべてに波及するリスクもある。しかし、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%B0%A5%D3%A1%BC">ラグビー</a>方式なら、1つのフェーズが遅れても、オーバーラップする他のフェーズも何とか進めていくことができる。</p> <p>さらに、竹内と野中は、最先端企業の新規プロダクト<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>には、フェーズのオーバーラップも含め、次の6つの特徴が見られると言う<sup id="fnref:tn2-1"><a href="#fn:tn2" rel="footnote">14</a></sup>。</p> <ol> <li><strong>内在する不確定性</strong>: 経営陣が示すのは戦略的方向性と極めて難易度の高い目標であり、何をどうやるのかは開発担当チームに任せる</li> <li><strong>自己組織化する開発担当チーム</strong>: 情報ゼロの状況から、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>が独自の動的秩序を形成し、チームが次第にスタートアップのような動きになる。そして自律性、自己超越、異種共創という特徴を持つに至る</li> <li><strong>開発フェーズのオーバーラップ</strong>: <a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>の各フェーズを重複して進める、分業という昔ながらの概念を捨てた方式。チームメンバーが<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>のあらゆる側面に責任感を持つ</li> <li><strong>多重学習</strong>: 幅広い知識と多様なスキルを獲得するために、社内の各階層（個人、グループ、会社）を超えた学びと、専門を超えた学びの2つの次元で学びが生じる</li> <li><strong>さりげない管理</strong>: 自己管理とピアプレッシャーによる管理、愛による管理の3つでチームを管理する</li> <li><strong>学びの組織的な伝達</strong>: プロジェクトを通して得た学びや、成功事例から得られた教訓を、次のプロジェクトに活かせるよう伝達する。また、過去の成功事例に囚われすぎないよう、アンラーニングにも努める</li> </ol> <p>これら6つの特徴を見ると、そこに<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>やDevOpsに通じるものがある。また、分業制の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>とは違い、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>全体を、1つの「チーム」という単位で活動することが強調されている点も興味深い。ここが、フェーズのオーバーラップがもたらすものなのだろう。</p> <blockquote><p>チーム立ち上げ時点では「情報ゼロ」状態だが、そのうち市場に関する知識や技術者界隈の知識をメンバー間で共有するようになる。こうしてチーム全体が一つの単位として動き始める。同時に、個々のメンバーとチーム全体とが不可分になる。個人のリズムとチーム全体のリズムが重なり始め、まったく新しい鼓動が生まれる。この鼓動が推進力となり、チームを前進させる。</p></blockquote> <p><span style="font-size: 70%">引用: <a href="https://www.diamond.co.jp/digital/478117657700.html">竹内弘高 (著), 野中郁次郎 (著), DIAMONDハーバード・ビジネス・レビュー編集部 (編集), "新たなる新製品開発の方法（DIAMOND ハーバード・ビジネス・レビュー論文）", ダイヤモンド社, 2023</a></span></p> <p>なお、この論文と<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%E9%A5%E0">スクラム</a>の関係については、野中自身が登壇した下記イベントで述べられている。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.publickey1.jp%2Fblog%2F11%2F_innovation_sprint_2010.html" title="スクラムの生みの親が語る、スクラムとはなにか？たえず不安定で、自己組織化し、全員が多能工である～ Innovation Sprint 2011（前編）" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.publickey1.jp/blog/11/_innovation_sprint_2010.html">www.publickey1.jp</a></cite></p> <h2 id="軽量級プロセスアジャイル系開発プロセスと重量級プロセスウォーターフォール">軽量級プロセス（<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>系<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>）と重量級プロセス（<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>）</h2> <p><a href="https://agilemanifesto.org/iso/ja/manifesto.html">アジャイルソフトウェア開発宣言</a>が公開されたのは、2001年だ。同年2月に<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E6%A5%BF%BD%A3">ユタ州</a>スノーバードに集まった17名のソフトウェアの専門家によって原案が作成された。そこには、ロバート・C・マーチンも名を連ねている。また、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%E9%A5%E0">スクラム</a>の生みの親であるケン・シュウェイバー（Ken Schwaber）とジェフ・サザーランド（Jeff Sutherland）もだ。<sup id="fnref:ag1-2"><a href="#fn:ag1" rel="footnote">9</a></sup></p> <p>このスノーバードでの会合は、「軽量級プロセスのサミット（Light Weight Process Sumit）」と名付けられた点が興味深い。軽量級プロセスとはもちろん、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発を指す。では重量級プロセスはと言うと、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>がその代表であった。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>以前に主流であった、事前計画型でプロセス重視なやり方でのプロジェクト失敗の経験を積み重ねた人々が、軽量級プロセスに惹きつけられていったのだろう。<sup id="fnref:rm1-5"><a href="#fn:rm1" rel="footnote">5</a></sup></p> <p>宣言の冒頭は次のとおりだ。重量級プロセスと軽量級プロセスを比較するような形で、4つの中核価値が表現されている。</p> <blockquote><p>私たちは、ソフトウェア開発の実践<br/> あるいは実践を手助けをする活動を通じて、<br/> よりよい開発方法を見つけだそうとしている。<br/> この活動を通して、私たちは以下の価値に至った。</p> <p><strong>プロセスやツールよりも個人と対話を、</strong><br/> <strong>包括的なドキュメントよりも動くソフトウェアを、</strong><br/> <strong>契約交渉よりも顧客との協調を、</strong><br/> <strong>計画に従うことよりも変化への対応を、</strong></p> <p><strong>価値とする。</strong>すなわち、左記のことがらに価値があることを<br/> 認めながらも、私たちは右記のことがらにより価値をおく。</p></blockquote> <p style="text-align: center"><span style="font-size: 70%">引用: 『<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発宣言 - agilemanifesto.org』, <a href="https://agilemanifesto.org/iso/ja/manifesto.html">https://agilemanifesto.org/iso/ja/manifesto.html</a> （引用内の強調は筆者によるもの）</span></p> <p>前節までで、"純粋な" <a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>は、作り上げるソフトウェアシステムがプロジェクトの初期段階で明らかにできる場合に適していることが分かった。計画通りに作り上げれば、それが誰かに価値になるということだ。そして、計画通りに作るためには、プロジェクトの初期段階から不確実性が低いことが条件となる。この条件が成立しないまま<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>で進めると、計画通りにプロジェクトが進まないか、作り上げたソフトウェアシステムが誰の価値にもならないかのいずれかなのだ。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発では逆に、不確実性が高く、計画通りに進めても、作り上げたソフトウェアシステムが誰かの価値にならないかもしれないことを前提としている。ここに、純粋な<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>と<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発が目指すものに対する違いが読み取れる。その違いこそが、両者の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>に大きな違いを生んでいるのだ。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>側の視点にたって、両者を比較してみよう。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>では、顧客が実際にソフトウェアに触れられるのがプロジェクトの最後だ。ドキュメントであればプロジェクトの途中段階で確認できるものの、それは中間成果物でしかない。それだけでは価値とは言えず、最終成果物たるソフトウェアを待っている。顧客にとっては、待たされる間、ずっと不安だろう。本当にソフトウェアシステムができあがるのか、それが想定通りのものになっているのか分からないからだ。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発は、動くソフトウェアを重視する。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%E9%A5%E0">スクラム</a>を実践するプロジェクトであれば、プロジェクトの途中であっても、スプリントの度に、顧客は動くソフトウェアを目にできる。それを実際に触ってみることで、本当に価値のあるものになっているかどうかを見極められる。想定通りになっていなかったり、想定通りであってもそれが間違っていたと気付いたなら、その修正を以降の計画に組み込むことも可能だ。</p> <p><figure class="figure-image figure-image-fotolife" title=""><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241111/20241111202922.png" width="1200" height="675" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>顧客による動くソフトウェアのレビュー</figcaption></figure></p> <p>プロジェクト途中でのそのような計画変更は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>なら死活問題となる。たとえば要件が変わってしまったら、最上流の要件定義からやり直しとなるからだ。その変更が、要件定義より<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B2%BC%CE%AE">下流</a>に影響する。そうなれば、変更前に作り上げた成果物は台無しになる。そして、想定していたコストや期日までにプロジェクトが終わらなくなってしまう。だから、できる限り変化を受け入れたくないという心理が働く。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>であれば変化を受け入れる。計画通りにプロジェクトが終わらなくなる点は<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>と変わらない。では、なぜ変化を受け入れるのか。その理由は2つあるのではないか。1つは、プロジェクト初期段階ですべての要件を決めきらないこと。それが、変化を柔軟に受け入れやすい素地となる。もう1つは、計画通りに作りあげることが価値になると考えないこと。変化することが価値になるのであれば、計画を変えることもいとわない。</p> <p><figure class="figure-image figure-image-fotolife" title=""><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/mtx2s/20241111/20241111202948.png" width="1200" height="675" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>プロジェクト途中の計画変更</figcaption></figure></p> <p>変化を受け入れるという点で障壁となるのが顧客との契約だろう。変化によって、予算、期日、要件のいずれかが、契約違反となるかもしれない。これが、受託開発業務において<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発手法を導入しにくい理由ではないだろうか。顧客と協調し、プロジェクトを進めながら繰り返し計画を見直す<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>なアプローチは、従来型の契約では実践が困難なのだ。</p> <h2 id="まとめ">まとめ</h2> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>モデルは、1960年代頃の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%DC%A5%C8%A5%E0%A5%A2%A5%C3%A5%D7">ボトムアップ</a>・アプローチに代わって用いられた<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチであった。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C8%A5%C3%A5%D7%A5%C0%A5%A6%A5%F3">トップダウン</a>・アプローチを説明する簡易な図が滝に見えることで、そこから連想される一方向に進む開発モデルとして、世の中に広く知れ渡ることとなる。</p> <p>ロイスが本来伝えようとした<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>モデルは、手戻りリスクを最小化しようとするものだ。はじめにすべての要件を決定し、そこから段階的に詳細化していく進め方は、手戻りが生じやすい。それは特に、要件定義に関する問題が顕著であり、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B2%BC%CE%AE">下流</a>のフェーズで不正確であったり、曖昧、矛盾、欠落が見つけられることが多い。これが、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>と呼ばれるモデルが抱える代表的な問題点である。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/IEEE">IEEE</a>/EIA 12207での開発戦略の比較では、不確実性が高いプロジェクトには、once-through戦略、すなわち<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>モデルが不向きであるとしている。それは、上述の通り、手戻りリスクが大きくなるからだろう。</p> <p>また、竹内と野中は、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>のように各フェーズをリレー方式で繋ぐ<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>よりも、フェーズをオーバーラップさせるサシミ方式や<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%E9%A5%B0%A5%D3%A1%BC">ラグビー</a>方式のほうが、スピードと柔軟性に優れていると述べている。これは、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>とは対照的に、オーバーラップ方式が不確実性の高いプロジェクトに適していることを示している。それは、彼らの論文を原点とする<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%E9%A5%E0">スクラム</a>にも言え、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発全般にも当てはまる考え方だろう。</p> <p>ここで思い出すのは、<a href="https://mtx2s.hatenablog.com/entry/2021/10/17/134739">クネビンフレームワーク</a>だ。<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>は「煩雑（complicated）」な領域で役立ち、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発は「複雑（complex）」な領域で役立つ。前者は事前分析によって正しい答えが導きだせる領域である。後者は、探索的なアプローチがなければ何が正しいか不明な領域だ。</p> <p><a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>が対象とするプロジェクトは、計画通りにソフトウェアシステムを作り上げれば、それが誰かの価値になる場合ということになる。逆に、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発が対象とするのは、計画通りに作り上げても、それが誰の価値にもならないかもしれないことを前提としている。ここが大きく違うのだ。</p> <p>しかし、純粋な<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>を諦めて<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB">アジャイル</a>ソフトウェア開発のプロセス<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A1%BC%A5%E0%A5%EF%A1%BC%A5%AF">フレームワーク</a>が作り上げられていったように、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>も工夫を重ねて使いこなされている。実際、私もこれまで、様々な領域で、<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>を使って成功したプロジェクトをみてきた。それらはいずれも、純粋な<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>ではなく、マコネルが紹介した修正版<a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB">ウォーターフォール</a>に近いものだった。</p> <p>プロジェクトの性質によって<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>を使い分けるべきとは言うが、それはなかなかに難しい。同じ組織が、複数の<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>を起用に使い分け、使いこなすことなど本当に可能なのだろうか。1つの<a class="keyword" href="https://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>でさえ、なじませ、改善を重ねることに苦労する。結局のところ、なにか1つに定めて、それを組織の目的に合わせて調整し、改良し続けるのが一番なのではないだろうか。</p> <h2 id="参考文献">参考文献</h2> <ol> <li id="fn:sm1">Steve McConnell (著), <a href="https://www.amazon.co.jp/dp/B0DHYGFVPX/">"Rapid Development"</a>, <a class="keyword" href="https://d.hatena.ne.jp/keyword/%C6%FC%B7%D0BP">日経BP</a>, 1996, Chapter 7<a href="#fnref:sm1-1" rev="footnote">↩</a><a href="#fnref:sm1-2" rev="footnote">↩</a><a href="#fnref:sm1-3" rev="footnote">↩</a><a href="#fnref:sm1-4" rev="footnote">↩</a><a href="#fnref:sm1-5" rev="footnote">↩</a></li> <li id="fn:gh1"><a href="https://resources.github.com/ja/software-development/what-is-sdlc/">SDLC とは: ソフトウェア開発ライフサイクルの概要 - GitHub Resources</a><a href="#fnref:gh1-1" rev="footnote">↩</a></li> <li id="fn:br1"><a href="http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/index.html">NATO Software Engineering Conference 1968 - The NATO Software Engineering Conferences</a><a href="#fnref:br1-1" rev="footnote">↩</a></li> <li id="fn:sc1"><a href="https://en.wikipedia.org/wiki/Software_crisis#Causes">Software crisis - Wikipedia</a><a href="#fnref:sc1-1" rev="footnote">↩</a></li> <li id="fn:rm1">Robert C. Martin (著), 角征典 (翻訳), 角谷信太郎 (翻訳),<a href="https://www.kadokawa.co.jp/product/302007001102/">"Clean Agile 基本に立ち戻れ"</a>, <a class="keyword" href="https://d.hatena.ne.jp/keyword/KADOKAWA">KADOKAWA</a>, 2020, 第1章<a href="#fnref:rm1-1" rev="footnote">↩</a><a href="#fnref:rm1-2" rev="footnote">↩</a><a href="#fnref:rm1-3" rev="footnote">↩</a><a href="#fnref:rm1-4" rev="footnote">↩</a><a href="#fnref:rm1-5" rev="footnote">↩</a></li> <li id="fn:bt1">T. E. Bell, T. A. Thayer, <a href="https://dl.acm.org/doi/10.5555/800253.807650">"Software requirements: Are they really a problem?"</a>, 1976<a href="#fnref:bt1-1" rev="footnote">↩</a></li> <li id="fn:wr1">Winston W. <a class="keyword" href="https://d.hatena.ne.jp/keyword/Royce">Royce</a>, <a href="https://dl.acm.org/doi/10.5555/41765.41801">"Managing the development of large software systems"</a>, 1970<a href="#fnref:wr1-1" rev="footnote">↩</a></li> <li id="fn:to1">小椋俊秀, <a href="https://barrel.repo.nii.ac.jp/records/269">"ウォーターフォールモデルの起源に関する考察ウォーターフォールに関する誤解を解く"</a>, 2013<a href="#fnref:to1-1" rev="footnote">↩</a></li> <li id="fn:ag1"><a href="https://agilemanifesto.org/iso/ja/manifesto.html">アジャイルソフトウェア開発宣言</a><a href="#fnref:ag1-1" rev="footnote">↩</a><a href="#fnref:ag1-2" rev="footnote">↩</a></li> <li id="fn:fb1">Jr FrederickP.Brooks (著), Frederick P. Brooks,Jr. (原名), 滝沢徹 (翻訳), 牧野祐子 (翻訳), 富澤昇 (翻訳), <a href="https://www.maruzen-publishing.co.jp/item/?book_no=294733">"人月の神話【新装版】"</a>, <a class="keyword" href="https://d.hatena.ne.jp/keyword/%B4%DD%C1%B1%BD%D0%C8%C7">丸善出版</a>, 2010, 第11章<a href="#fnref:fb1-1" rev="footnote">↩</a></li> <li id="fn:ie1"><a class="keyword" href="https://d.hatena.ne.jp/keyword/IEEE">IEEE</a>, "12207.0-1996 - <a class="keyword" href="https://d.hatena.ne.jp/keyword/IEEE">IEEE</a>/EIA Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations", 1998<a href="#fnref:ie1-1" rev="footnote">↩</a></li> <li id="fn:ie2"><a class="keyword" href="https://d.hatena.ne.jp/keyword/IEEE">IEEE</a>, <a href="https://www.dote.osd.mil/Portals/97/docs/TEMPGuide/IEEE_EIA_12207.2_1997.pdf">"12207.2-1997 - IEEE/EIA Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations"</a>, 1998<a href="#fnref:ie2-1" rev="footnote">↩</a></li> <li id="fn:tn1">Hirotaka Takeuchi, Ikujiro Nonaka, <a href="https://hbr.org/1986/01/the-new-new-product-development-game">"The New New Product Development Game"</a>, 1986</li> <li id="fn:tn2">竹内弘高 (著), 野中郁次郎 (著), DIAMONDハーバード・ビジネス・レビュー編集部 (編集), <a href="https://www.diamond.co.jp/digital/478117657700.html">"新たなる新製品開発の方法（DIAMOND ハーバード・ビジネス・レビュー論文）"</a>, <a class="keyword" href="https://d.hatena.ne.jp/keyword/%A5%C0%A5%A4%A5%E4%A5%E2%A5%F3%A5%C9%BC%D2">ダイヤモンド社</a>, 2023<a href="#fnref:tn2-1" rev="footnote">↩</a></li> </ol> </div> <footer class="entry-footer"> <div class="entry-tags-wrapper"> <div class="entry-tags"> <span class="entry-tag"> <a href="https://d.hatena.ne.jp/keyword/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA" class="entry-tag-link"> <span class="entry-tag-icon">#</span><span class="entry-tag-label">ソフトウェア開発</span> </a> </span> <span class="entry-tag"> <a href="https://d.hatena.ne.jp/keyword/%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E9%96%8B%E7%99%BA" class="entry-tag-link"> <span class="entry-tag-icon">#</span><span class="entry-tag-label">プロダクト開発</span> </a> </span> <span class="entry-tag"> <a href="https://d.hatena.ne.jp/keyword/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0" class="entry-tag-link"> <span class="entry-tag-icon">#</span><span class="entry-tag-label">エンジニアリング</span> </a> </span> <span class="entry-tag"> <a href="https://d.hatena.ne.jp/keyword/%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88" class="entry-tag-link"> <span class="entry-tag-icon">#</span><span class="entry-tag-label">プロダクトマネジメント</span> </a> </span> <span class="entry-tag"> <a href="https://d.hatena.ne.jp/keyword/%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88" class="entry-tag-link"> <span class="entry-tag-icon">#</span><span class="entry-tag-label">プロジェクトマネジメント</span> </a> </span> <span class="entry-tag"> <a href="https://d.hatena.ne.jp/keyword/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9E%E3%83%8D%E3%83%BC%E3%82%B8%E3%83%A3%E3%83%BC" class="entry-tag-link"> <span class="entry-tag-icon">#</span><span class="entry-tag-label">エンジニアリングマネージャー</span> </a> </span> </div> </div> <p class="entry-footer-section track-inview-by-gtm" data-gtm-track-json="{"area": "finish_reading"}"> <span class="author vcard"><span class="fn" data-load-nickname="1" data-user-name="mtx2s" >mtx2s</span></span> <span class="entry-footer-time"><a href="https://mtx2s.hatenablog.com/entry/2024/11/11/204512"><time data-relative datetime="2024-11-11T11:45:12Z" title="2024-11-11T11:45:12Z" class="updated">2024-11-11 20:45</time></a></span> <span class=" entry-footer-subscribe " data-test-blog-controlls-subscribe> <a href="https://blog.hatena.ne.jp/mtx2s/mtx2s.hatenablog.com/subscribe?utm_medium=button&utm_source=blogs_entry_footer&utm_campaign=subscribe_blog"> 読者になる </a> </span> </p> <div class="hatena-star-container" data-hatena-star-container data-hatena-star-url="https://mtx2s.hatenablog.com/entry/2024/11/11/204512" data-hatena-star-title="アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある" data-hatena-star-variant="profile-icon" data-hatena-star-profile-url-template="https://blog.hatena.ne.jp/{username}/" ></div> <div class="social-buttons"> <div class="social-button-item"> <a href="https://b.hatena.ne.jp/entry/s/mtx2s.hatenablog.com/entry/2024/11/11/204512" class="hatena-bookmark-button" data-hatena-bookmark-url="https://mtx2s.hatenablog.com/entry/2024/11/11/204512" data-hatena-bookmark-layout="vertical-balloon" data-hatena-bookmark-lang="ja" title="この記事をはてなブックマークに追加"><img src="https://b.st-hatena.com/images/entry-button/button-only.gif" alt="この記事をはてなブックマークに追加" width="20" height="20" style="border: none;" /></a> </div> <div class="social-button-item"> <div class="fb-share-button" data-layout="box_count" data-href="https://mtx2s.hatenablog.com/entry/2024/11/11/204512"></div> </div> <div class="social-button-item"> <a class="entry-share-button entry-share-button-twitter test-share-button-twitter" href="https://x.com/intent/tweet?hashtags=%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA&hashtags=%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E9%96%8B%E7%99%BA&hashtags=%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0&hashtags=%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88&hashtags=%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88&hashtags=%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9E%E3%83%8D%E3%83%BC%E3%82%B8%E3%83%A3%E3%83%BC&text=%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%92%E5%AE%9F%E8%B7%B5%E3%81%99%E3%82%8B%E7%B5%84%E7%B9%94%E3%81%A7%E3%81%82%E3%81%A3%E3%81%A6%E3%82%82%E3%82%A6%E3%82%A9%E3%83%BC%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A9%E3%83%BC%E3%83%AB%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%93%E3%81%A8%E3%81%AB%E3%81%AF%E4%BE%A1%E5%80%A4%E3%81%8C%E3%81%82%E3%82%8B+-+mtx2s%E2%80%99s+blog&url=https%3A%2F%2Fmtx2s.hatenablog.com%2Fentry%2F2024%2F11%2F11%2F204512" title="X（Twitter）で投稿する" ></a> </div> </div> <div class="google-afc-image test-google-rectangle-ads"> <div id="google_afc_user_container_0" class="google-afc-user-container google_afc_blocklink2_5 google_afc_boder" data-test-unit="/4374287/blog_user"></div> <a href="http://blog.hatena.ne.jp/guide/pro" class="open-pro-modal" data-guide-pro-modal-ad-url="https://hatena.blog/guide/pro/modal/ad">広告を非表示にする</a> </div> <div class="customized-footer"> <div class="entry-footer-modules" id="entry-footer-secondary-modules"> <div class="hatena-module hatena-module-related-entries" >  <div class="hatena-module-title"> 関連記事 </div> <div class="hatena-module-body"> <ul class="related-entries hatena-urllist urllist-with-thumbnails"> <li class="urllist-item related-entries-item"> <div class="urllist-item-inner related-entries-item-inner"> <a class="urllist-image-link related-entries-image-link" href="https://mtx2s.hatenablog.com/entry/2024/02/12/210309"> <img alt="デプロイ頻度やリードタイムの正確な計測にこだわらなくていい（前提はあるが）" src="https://cdn.image.st-hatena.com/image/square/c4bfc10717a2509168357802f789f9a98fe9bbd7/backend=imagemagick;height=100;version=1;width=100/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmtx2s%2F20240212%2F20240212154641.png" class="urllist-image related-entries-image" title="デプロイ頻度やリードタイムの正確な計測にこだわらなくていい（前提はあるが）" width="100" height="100" loading="lazy"> </a> <div class="urllist-date-link related-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2024/02/12" rel="nofollow"> <time datetime="2024-02-12T12:03:09Z" title="2024年2月12日"> 2024-02-12 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2024/02/12/210309" class="urllist-title-link related-entries-title-link urllist-title related-entries-title">デプロイ頻度やリードタイムの正確な計測にこだわらなくていい（前提はあるが）</a> <div class="urllist-entry-body related-entries-entry-body">デプロイ頻度とリードタイムは、開発チームが自らのパフォーマ…</div> </div> </li> <li class="urllist-item related-entries-item"> <div class="urllist-item-inner related-entries-item-inner"> <a class="urllist-image-link related-entries-image-link" href="https://mtx2s.hatenablog.com/entry/2024/01/08/205454"> <img alt="チーム中心の組織作りのための6つのチーム設計原則" src="https://cdn.image.st-hatena.com/image/square/924837d70cee799514a97ac6e207a3f6f687c1bd/backend=imagemagick;height=100;version=1;width=100/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmtx2s%2F20240108%2F20240108183243.png" class="urllist-image related-entries-image" title="チーム中心の組織作りのための6つのチーム設計原則" width="100" height="100" loading="lazy"> </a> <div class="urllist-date-link related-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2024/01/08" rel="nofollow"> <time datetime="2024-01-08T11:54:54Z" title="2024年1月8日"> 2024-01-08 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2024/01/08/205454" class="urllist-title-link related-entries-title-link urllist-title related-entries-title">チーム中心の組織作りのための6つのチーム設計原則</a> <div class="urllist-entry-body related-entries-entry-body">近年のソフトウェアプロダクト開発組織の活動単位としてよく言…</div> </div> </li> <li class="urllist-item related-entries-item"> <div class="urllist-item-inner related-entries-item-inner"> <a class="urllist-image-link related-entries-image-link" href="https://mtx2s.hatenablog.com/entry/2023/09/04/220212"> <img alt="「アジャイルテストの4象限」はアジャイル開発を補完するソフトウェア開発手法である" src="https://cdn.image.st-hatena.com/image/square/5c9ca7b4246128a0ca31586c1b03bf45359dd9b0/backend=imagemagick;height=100;version=1;width=100/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmtx2s%2F20230903%2F20230903150524.png" class="urllist-image related-entries-image" title="「アジャイルテストの4象限」はアジャイル開発を補完するソフトウェア開発手法である" width="100" height="100" loading="lazy"> </a> <div class="urllist-date-link related-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2023/09/04" rel="nofollow"> <time datetime="2023-09-04T13:02:12Z" title="2023年9月4日"> 2023-09-04 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2023/09/04/220212" class="urllist-title-link related-entries-title-link urllist-title related-entries-title">「アジャイルテストの4象限」はアジャイル開発を補完するソフトウェア開発手法である</a> <div class="urllist-entry-body related-entries-entry-body">従来のプロジェクトにおける「テスト」は、リリースや納品前の…</div> </div> </li> <li class="urllist-item related-entries-item"> <div class="urllist-item-inner related-entries-item-inner"> <a class="urllist-image-link related-entries-image-link" href="https://mtx2s.hatenablog.com/entry/2022/11/15/220403"> <img alt=""Products not Projects"で比較される2つのモデルが開発チームを特徴づける" src="https://cdn.image.st-hatena.com/image/square/298058b2bffe422918ac5e915861b0c0839ae26b/backend=imagemagick;height=100;version=1;width=100/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png" class="urllist-image related-entries-image" title=""Products not Projects"で比較される2つのモデルが開発チームを特徴づける" width="100" height="100" loading="lazy"> </a> <div class="urllist-date-link related-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2022/11/15" rel="nofollow"> <time datetime="2022-11-15T13:04:03Z" title="2022年11月15日"> 2022-11-15 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2022/11/15/220403" class="urllist-title-link related-entries-title-link urllist-title related-entries-title">"Products not Projects"で比較される2つのモデルが開発チームを特徴づける</a> <div class="urllist-entry-body related-entries-entry-body">"Products not Projects" は、効果的なソフトウェアプロダクト…</div> </div> </li> <li class="urllist-item related-entries-item"> <div class="urllist-item-inner related-entries-item-inner"> <a class="urllist-image-link related-entries-image-link" href="https://mtx2s.hatenablog.com/entry/2022/06/11/131625"> <img alt="エンジニアリングマネージャーとしてのミッション" src="https://cdn.image.st-hatena.com/image/square/97b9c62d269cb4e820b38cfa4a8e00cefee6d850/backend=imagemagick;height=100;version=1;width=100/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmtx2s%2F20220605%2F20220605000411.png" class="urllist-image related-entries-image" title="エンジニアリングマネージャーとしてのミッション" width="100" height="100" loading="lazy"> </a> <div class="urllist-date-link related-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2022/06/11" rel="nofollow"> <time datetime="2022-06-11T04:16:25Z" title="2022年6月11日"> 2022-06-11 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2022/06/11/131625" class="urllist-title-link related-entries-title-link urllist-title related-entries-title">エンジニアリングマネージャーとしてのミッション</a> <div class="urllist-entry-body related-entries-entry-body">ソフトウェアプロダクト開発領域を預かるエンジニアリングマネ…</div> </div> </li> </ul> </div> </div> </div> </div> <div class="comment-box js-comment-box"> <ul class="comment js-comment"> <li class="read-more-comments" style="display: none;"><a>もっと読む</a></li> </ul> <a class="leave-comment-title js-leave-comment-title">コメントを書く</a> </div> </footer> </div> </article>   <div class="pager pager-permalink permalink"> <span class="pager-next"> <a href="https://mtx2s.hatenablog.com/entry/2024/07/29/194244" rel="next"> SPACEでの指標選びは網羅性ではなく関連性… <span class="pager-arrow"> »</span> </a> </span> </div> </div> </div> <aside id="box1"> <div id="box1-inner"> </div> </aside> </div> <aside id="box2"> <div id="box2-inner"> <div class="hatena-module hatena-module-profile"> <div class="hatena-module-title"> プロフィール </div> <div class="hatena-module-body"> <a href="https://mtx2s.hatenablog.com/about" class="profile-icon-link"> <img src="https://cdn.profile-image.st-hatena.com/users/mtx2s/profile.png?1580009140" alt="id:mtx2s" class="profile-icon" /> </a> <span class="id"> <a href="https://mtx2s.hatenablog.com/about" class="hatena-id-link"><span data-load-nickname="1" data-user-name="mtx2s">id:mtx2s</span></a> </span> <div class="profile-description"> <p>ソフトウェアエンジニアリングを対象領域とするマネージャー。競争力あるプロダクト開発組織を作り上げるにはどうすれば良いか、日々模索しています。</p> </div> <div class="hatena-follow-button-box btn-subscribe js-hatena-follow-button-box" > <a href="#" class="hatena-follow-button js-hatena-follow-button"> <span class="subscribing"> <span class="foreground">読者です</span> <span class="background">読者をやめる</span> </span> <span class="unsubscribing" data-track-name="profile-widget-subscribe-button" data-track-once> <span class="foreground">読者になる</span> <span class="background">読者になる</span> </span> </a> <div class="subscription-count-box js-subscription-count-box"> <i></i> <u></u> <span class="subscription-count js-subscription-count"> </span> </div> </div> <div class="hatena-follow-button-box"> <a href="https://twitter.com/mtx2s" title="X（Twitter）アカウント" class="btn-twitter" data-lang="ja"> <img src="https://cdn.blog.st-hatena.com/images/theme/plofile-socialize-x.svg?version=b06a9d4929119667e7027e25c25079" alt="X"> <span> @mtx2sをフォロー </span> </a> </div> <div class="profile-about"> <a href="https://mtx2s.hatenablog.com/about">このブログについて</a> </div> </div> </div> <div class="hatena-module hatena-module-links"> <div class="hatena-module-title"> リンク </div> <div class="hatena-module-body"> <ul class="hatena-urllist"> <li> <a href="https://twitter.com/mtx2s">Twitter @mtx2s</a> </li> <li> <a href="https://note.com/mtx2s">note @mtx2s</a> </li> <li> <a href="https://speakerdeck.com/mtx2s">Speaker Deck @mtx2s</a> </li> </ul> </div> </div> <div class="hatena-module hatena-module-search-box"> <div class="hatena-module-title"> 検索 </div> <div class="hatena-module-body"> <form class="search-form" role="search" action="https://mtx2s.hatenablog.com/search" method="get"> <input type="text" name="q" class="search-module-input" value="" placeholder="記事を検索" required> <input type="submit" value="検索" class="search-module-button" /> </form> </div> </div> <div class="hatena-module hatena-module-entries-access-ranking" data-count="5" data-source="total_bookmark" data-enable_customize_format="0" data-display_entry_image_size_width="100" data-display_entry_image_size_height="100" data-display_entry_category="0" data-display_entry_image="0" data-display_entry_image_size_width="100" data-display_entry_image_size_height="100" data-display_entry_body_length="0" data-display_entry_date="1" data-display_entry_title_length="20" data-restrict_entry_title_length="0" data-display_bookmark_count="1" > <div class="hatena-module-title"> <a href="http://b.hatena.ne.jp/entrylist?url=https%3A%2F%2Fmtx2s.hatenablog.com%2F&sort=count">注目記事</a> </div> <div class="hatena-module-body"> </div> </div> <div class="hatena-module hatena-module-recent-entries "> <div class="hatena-module-title"> <a href="https://mtx2s.hatenablog.com/archive"> 最新記事 </a> </div> <div class="hatena-module-body"> <ul class="recent-entries hatena-urllist "> <li class="urllist-item recent-entries-item"> <div class="urllist-item-inner recent-entries-item-inner"> <div class="urllist-date-link recent-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2024/11/11" rel="nofollow"> <time datetime="2024-11-11T11:45:12Z" title="2024年11月11日"> 2024-11-11 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2024/11/11/204512" class="urllist-title-link recent-entries-title-link urllist-title recent-entries-title">アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある</a> </div> </li> <li class="urllist-item recent-entries-item"> <div class="urllist-item-inner recent-entries-item-inner"> <div class="urllist-date-link recent-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2024/07/29" rel="nofollow"> <time datetime="2024-07-29T10:42:44Z" title="2024年7月29日"> 2024-07-29 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2024/07/29/194244" class="urllist-title-link recent-entries-title-link urllist-title recent-entries-title">SPACEでの指標選びは網羅性ではなく関連性と一貫性を持たせて絞り込むことが大切である、さらに……</a> </div> </li> <li class="urllist-item recent-entries-item"> <div class="urllist-item-inner recent-entries-item-inner"> <div class="urllist-date-link recent-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2024/02/12" rel="nofollow"> <time datetime="2024-02-12T12:03:09Z" title="2024年2月12日"> 2024-02-12 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2024/02/12/210309" class="urllist-title-link recent-entries-title-link urllist-title recent-entries-title">デプロイ頻度やリードタイムの正確な計測にこだわらなくていい（前提はあるが）</a> </div> </li> <li class="urllist-item recent-entries-item"> <div class="urllist-item-inner recent-entries-item-inner"> <div class="urllist-date-link recent-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2024/01/15" rel="nofollow"> <time datetime="2024-01-15T12:25:58Z" title="2024年1月15日"> 2024-01-15 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2024/01/15/212558" class="urllist-title-link recent-entries-title-link urllist-title recent-entries-title">チームの機能と配備を考えるための7つのチーム責務定義ガイドライン</a> </div> </li> <li class="urllist-item recent-entries-item"> <div class="urllist-item-inner recent-entries-item-inner"> <div class="urllist-date-link recent-entries-date-link"> <a href="https://mtx2s.hatenablog.com/archive/2024/01/08" rel="nofollow"> <time datetime="2024-01-08T11:54:54Z" title="2024年1月8日"> 2024-01-08 </time> </a> </div> <a href="https://mtx2s.hatenablog.com/entry/2024/01/08/205454" class="urllist-title-link recent-entries-title-link urllist-title recent-entries-title">チーム中心の組織作りのための6つのチーム設計原則</a> </div> </li> </ul> </div> </div> <div class="hatena-module hatena-module-archive" data-archive-type="default" data-archive-url="https://mtx2s.hatenablog.com/archive"> <div class="hatena-module-title"> <a href="https://mtx2s.hatenablog.com/archive">月別アーカイブ</a> </div> <div class="hatena-module-body"> <ul class="hatena-urllist"> <li class="archive-module-year archive-module-year-hidden" data-year="2024"> <div class="archive-module-button"> <span class="archive-module-hide-button">▼</span> <span class="archive-module-show-button">▶</span> </div> <a href="https://mtx2s.hatenablog.com/archive/2024" class="archive-module-year-title archive-module-year-2024"> 2024 </a> <ul class="archive-module-months"> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2024/11" class="archive-module-month-title archive-module-month-2024-11"> 2024 / 11 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2024/07" class="archive-module-month-title archive-module-month-2024-7"> 2024 / 7 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2024/02" class="archive-module-month-title archive-module-month-2024-2"> 2024 / 2 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2024/01" class="archive-module-month-title archive-module-month-2024-1"> 2024 / 1 </a> </li> </ul> </li> <li class="archive-module-year archive-module-year-hidden" data-year="2023"> <div class="archive-module-button"> <span class="archive-module-hide-button">▼</span> <span class="archive-module-show-button">▶</span> </div> <a href="https://mtx2s.hatenablog.com/archive/2023" class="archive-module-year-title archive-module-year-2023"> 2023 </a> <ul class="archive-module-months"> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2023/11" class="archive-module-month-title archive-module-month-2023-11"> 2023 / 11 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2023/09" class="archive-module-month-title archive-module-month-2023-9"> 2023 / 9 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2023/07" class="archive-module-month-title archive-module-month-2023-7"> 2023 / 7 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2023/06" class="archive-module-month-title archive-module-month-2023-6"> 2023 / 6 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2023/04" class="archive-module-month-title archive-module-month-2023-4"> 2023 / 4 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2023/03" class="archive-module-month-title archive-module-month-2023-3"> 2023 / 3 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2023/02" class="archive-module-month-title archive-module-month-2023-2"> 2023 / 2 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2023/01" class="archive-module-month-title archive-module-month-2023-1"> 2023 / 1 </a> </li> </ul> </li> <li class="archive-module-year archive-module-year-hidden" data-year="2022"> <div class="archive-module-button"> <span class="archive-module-hide-button">▼</span> <span class="archive-module-show-button">▶</span> </div> <a href="https://mtx2s.hatenablog.com/archive/2022" class="archive-module-year-title archive-module-year-2022"> 2022 </a> <ul class="archive-module-months"> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2022/11" class="archive-module-month-title archive-module-month-2022-11"> 2022 / 11 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2022/10" class="archive-module-month-title archive-module-month-2022-10"> 2022 / 10 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2022/09" class="archive-module-month-title archive-module-month-2022-9"> 2022 / 9 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2022/08" class="archive-module-month-title archive-module-month-2022-8"> 2022 / 8 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2022/07" class="archive-module-month-title archive-module-month-2022-7"> 2022 / 7 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2022/06" class="archive-module-month-title archive-module-month-2022-6"> 2022 / 6 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2022/05" class="archive-module-month-title archive-module-month-2022-5"> 2022 / 5 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2022/04" class="archive-module-month-title archive-module-month-2022-4"> 2022 / 4 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2022/03" class="archive-module-month-title archive-module-month-2022-3"> 2022 / 3 </a> </li> </ul> </li> <li class="archive-module-year archive-module-year-hidden" data-year="2021"> <div class="archive-module-button"> <span class="archive-module-hide-button">▼</span> <span class="archive-module-show-button">▶</span> </div> <a href="https://mtx2s.hatenablog.com/archive/2021" class="archive-module-year-title archive-module-year-2021"> 2021 </a> <ul class="archive-module-months"> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2021/12" class="archive-module-month-title archive-module-month-2021-12"> 2021 / 12 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2021/10" class="archive-module-month-title archive-module-month-2021-10"> 2021 / 10 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2021/09" class="archive-module-month-title archive-module-month-2021-9"> 2021 / 9 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2021/07" class="archive-module-month-title archive-module-month-2021-7"> 2021 / 7 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2021/06" class="archive-module-month-title archive-module-month-2021-6"> 2021 / 6 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2021/04" class="archive-module-month-title archive-module-month-2021-4"> 2021 / 4 </a> </li> </ul> </li> <li class="archive-module-year archive-module-year-hidden" data-year="2020"> <div class="archive-module-button"> <span class="archive-module-hide-button">▼</span> <span class="archive-module-show-button">▶</span> </div> <a href="https://mtx2s.hatenablog.com/archive/2020" class="archive-module-year-title archive-module-year-2020"> 2020 </a> <ul class="archive-module-months"> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2020/12" class="archive-module-month-title archive-module-month-2020-12"> 2020 / 12 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2020/08" class="archive-module-month-title archive-module-month-2020-8"> 2020 / 8 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2020/03" class="archive-module-month-title archive-module-month-2020-3"> 2020 / 3 </a> </li> <li class="archive-module-month"> <a href="https://mtx2s.hatenablog.com/archive/2020/01" class="archive-module-month-title archive-module-month-2020-1"> 2020 / 1 </a> </li> </ul> </li> </ul> </div> </div> </div> </aside> </div> </div> </div> </div> <footer id="footer" data-brand="hatenablog"> <div id="footer-inner"> <div style="display:none !important" class="guest-footer js-guide-register test-blogs-register-guide" data-action="guide-register"> <div class="guest-footer-content"> <h3>はてなブログをはじめよう！</h3> <p>mtx2sさんは、はてなブログを使っています。あなたもはてなブログをはじめてみませんか？</p> <div class="guest-footer-btn-container"> <div class="guest-footer-btn"> <a class="btn btn-register js-inherit-ga" href="https://blog.hatena.ne.jp/register?via=200227" target="_blank">はてなブログをはじめる（無料）</a> </div> <div class="guest-footer-btn"> <a href="https://hatena.blog/guide" target="_blank">はてなブログとは</a> </div> </div> </div> </div> <address class="footer-address"> <a href="https://mtx2s.hatenablog.com/"> <img src="https://cdn.image.st-hatena.com/image/square/b1c5979b7977f3d148624e0a142dfbc70a05973c/backend=imagemagick;height=128;version=1;width=128/https%3A%2F%2Fcdn.user.blog.st-hatena.com%2Fblog_custom_icon%2F155726877%2F1630825902998259" width="16" height="16" alt="mtx2s’s blog"/> <span class="footer-address-name">mtx2s’s blog</span> </a> </address> <p class="services"> Powered by <a href="https://hatena.blog/">Hatena Blog</a> | <a href="https://blog.hatena.ne.jp/-/abuse_report?target_url=https%3A%2F%2Fmtx2s.hatenablog.com%2Fentry%2F2024%2F11%2F11%2F204512" class="report-abuse-link test-report-abuse-link" target="_blank">ブログを報告する</a> </p> </div> </footer> <script async src="https://s.hatena.ne.jp/js/widget/star.js"></script> <script> if (typeof window.Hatena === 'undefined') { window.Hatena = {}; } if (!Hatena.hasOwnProperty('Star')) { Hatena.Star = { VERSION: 2, }; } </script> <div id="fb-root"></div> <script>(function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "//connect.facebook.net/ja_JP/sdk.js#xfbml=1&appId=719729204785177&version=v17.0"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'facebook-jssdk'));</script> <div class="quote-box"> <div class="tooltip-quote tooltip-quote-stock"> <i class="blogicon-quote" title="引用をストック"></i> </div> <div class="tooltip-quote tooltip-quote-tweet js-tooltip-quote-tweet"> <a class="js-tweet-quote" target="_blank" data-track-name="quote-tweet" data-track-once> <img src="https://cdn.blog.st-hatena.com/images/admin/quote/quote-x-icon.svg?version=b06a9d4929119667e7027e25c25079" title="引用して投稿する" > </a> </div> </div> <div class="quote-stock-panel" id="quote-stock-message-box" style="position: absolute; z-index: 3000"> <div class="message-box" id="quote-stock-succeeded-message" style="display: none"> <p>引用をストックしました</p> <button class="btn btn-primary" id="quote-stock-show-editor-button" data-track-name="curation-quote-edit-button">ストック一覧を見る</button> <button class="btn quote-stock-close-message-button">閉じる</button> </div> <div class="message-box" id="quote-login-required-message" style="display: none"> <p>引用するにはまずログインしてください</p> <button class="btn btn-primary" id="quote-login-button">ログイン</button> <button class="btn quote-stock-close-message-button">閉じる</button> </div> <div class="error-box" id="quote-stock-failed-message" style="display: none"> <p>引用をストックできませんでした。再度お試しください</p> <button class="btn quote-stock-close-message-button">閉じる</button> </div> <div class="error-box" id="unstockable-quote-message-box" style="display: none; position: absolute; z-index: 3000;"> <p>限定公開記事のため引用できません。</p> </div> </div> <script type="x-underscore-template" id="js-requote-button-template"> <div class="requote-button js-requote-button"> <button class="requote-button-btn tipsy-top" title="引用する"><i class="blogicon-quote"></i></button> </div> </script> <div id="hidden-subscribe-button" style="display: none;"> <div class="hatena-follow-button-box btn-subscribe js-hatena-follow-button-box" > <a href="#" class="hatena-follow-button js-hatena-follow-button"> <span class="subscribing"> <span class="foreground">読者です</span> <span class="background">読者をやめる</span> </span> <span class="unsubscribing" data-track-name="profile-widget-subscribe-button" data-track-once> <span class="foreground">読者になる</span> <span class="background">読者になる</span> </span> </a> <div class="subscription-count-box js-subscription-count-box"> <i></i> <u></u> <span class="subscription-count js-subscription-count"> </span> </div> </div> </div> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> <script src="https://b.st-hatena.com/js/bookmark_button.js" charset="utf-8" async="async"></script> <script type="text/javascript" src="https://cdn.blog.st-hatena.com/js/external/jquery.min.js?v=1.12.4&version=b06a9d4929119667e7027e25c25079"></script> <script src="https://cdn.blog.st-hatena.com/js/texts-ja.js?version=b06a9d4929119667e7027e25c25079"></script> <script id="vendors-js" data-env="production" src="https://cdn.blog.st-hatena.com/js/vendors.js?version=b06a9d4929119667e7027e25c25079" crossorigin="anonymous"></script> <script id="hatenablog-js" data-env="production" src="https://cdn.blog.st-hatena.com/js/hatenablog.js?version=b06a9d4929119667e7027e25c25079" crossorigin="anonymous" data-page-id="entry"></script> <script>Hatena.Diary.GlobalHeader.init()</script> <script id="valve-dmp" data-service="blog" src="https://cdn.pool.st-hatena.com/valve/dmp.js" data-test-id="dmpjs" async></script> </body> </html>