【ボトルネック移行】コードがほぼ無料になったとき、ソフトウェア工学のボトルネックはどこへ行ったのか AI時代のソフトウェア工学変革——ゆっくり学ぶAI173
コードの生産がほぼ無料になったら、瓶頸はどこへ?
コードの生産がほぼ無料になったら、ソフトウェアの配布の瓶頸は「コードを書く」から別のところへ移動する。問題を定義する、部分を組み合わせて動作する全体を作る、実際に正しいことを検証する、組織を調整する。 これは、ソフトウェア業界における制約理論（Theory of Constraints）の再現である。製造業は40年前からこの道を歩いてきた：一つの工程が安くなったら、瓶頸は消えない。代わりに、次の最も高いコストの工程に移る。ここで理解できるのは、普遍的な困惑の解決法である。AIプログラミングツールが全社に敷き詰められたら、コードの生産は速くなったが、配布の速度はあまり変わりなかった。
製造業グループのCIOが私に半年間のデータを示した。ITチームは80人以上で、AIプログラミングツールを全面的に導入した。単にコードの生産をみると、人均の提出量とマージ速度は3倍以上増加した。しかし、ビジネスサイドの感覚はまったく異なる。1つのスマートな生産計画の機能から立案から上線まで、3ヶ月かかった。彼はツールが2倍のスピードアップをもたらすと期待していたが、実際には「コードを書くのが速いだけ」というものを買っただけだった。彼の言葉は簡潔で、「私は数百万のライセンス料を支払って、開発者が忙しくなり、ビジネスが急がるだけを買った。
AI 技術の瓶頸はどこにあるのか
彼は、瓶頸の位置を間違っていた。彼の本当の瓶頸は別のものであった：新機能を追加するたびに、MES、ERP、品質検査システム、車間端末、監査報告基準など、多くのシステムを通過しなければならず、集成と連携が大部分の作業時間を占めていた。AI によって生成されたコードは、正式な検査基準が存在しないため、生産環境と間には障壁がない。コードを書く速度が速くても、間違った瓶頸の後ろに列を形成するだけであった。
# 一、製造業は40年前から知っていた：瓶頸は動く
現在を理解するには、製造業の40年前の経験を借りる必要がある。
1984年、物理学者の出身であるイスラエルのアドバイザーEliyahu Goldrattは、破産寸前の工場長が如何に工場を救うかを描いた小説《目標》（The Goal）を著した。小説の核心は一句话であった：あらゆるシステムの出力は、最も狭いリング（約束、つまり瓶頸）によって決まる。瓶頸以外のリングを拡張しても、総出力には影響がない。瓶頸自体を拡張するだけが、全体を速くする。瓶頸を拡張すると、すぐに瓶頸は次の最も狭いリングに移動する。このことが約束理論（Theory of Constraints、TOC）である。
自動化による瓶頸の移動の旅
製造業に続く40年の自動化の歴史は、ほぼ「瓶頸の引っ越しの歴史」である。数值制御機械が切削を安くすると、瓶頸は段取り替えと品質検査に移った。柔性生産ラインが段取り替えを速くすると、瓶頸は生産計画とサプライチェーンの連携に移った。MESが生産計画を正確にすると、瓶頸は需要予測と工場間調整に移った。一段階を自動化するたびに、次の段階が浮かび上がる。自動化は瓶頸を消滅させることはなく、瓶頸の場所を変えるだけである。
この法則は製造業だけの専売特許ではない。2026年7月、a16zのポッドキャスト『Software in the Age of Agents』で、元マイクロソフトWindows社長のSteven Sinofskyが企業ソフトウェアの事例を用い、独自に同じ結論に達した。彼の原話は次の通りである。
“The long tail got no shorter. It just got longer in a different way.”（長い尻尾は少しも短くならず、別の形でより長くなっただけだ。）
自動化の法則
彼はAmazonのカスタマーサポートを例に挙げた。電話をなくし、チャットボットに商品を直接再発送させれば、人的コストを節約できるように見えるが、バックエンドではすぐに「同じ問題の再発をどう防ぐか」という根本原因分析のニーズが立ち上がり、電話に応対するよりも複雑だ。経費精算のプロセスも同様である。OCRで自動的に記帳されるようになった後、財務がやるべきことは、出張パフォーマンスの最適化や動的価格比較に変わった。仕事は消滅せず、「入力」から「分析・意思決定」へと上流に移っただけである。あるマイクロソフトの古参兵でありa16zパートナーである彼は、Goldrattの理論を使わずに、製造業が40年前に到達したのと同じ判断を下した。一方は工場の現場から、もう一方は企業ソフトウェアから。二つの独立した道が同じ法則を指し示している。
ただし、この法則を絶対的な真理として読まれないよう、一つの限定を補っておく。実際に永久に消滅した瓶頸もある。タイピスト、電話交換手、活字植字工——これらの職種は「上流に移動」したのではなく、文字通り消え去った。ある仕事が引っ越しするのか消滅するのかを判断するには、自動化が解放した生産能力が新たな需要を生み出したのか（経済学ではジェボンズのパラドックスと呼ぶ）、それとも単にその需要を萎縮させたのかを見るのが鍵である。企業のコアシステムを巡る仕事の大半は前者に属する。会計が速くなるほど、経営者が見たがる分析はより多く、より細かくなる。だからここでの結論は「自動化でどれだけの作業を削減できるか」ではなく、「人と予算を、自動化された層から、新たに立ち上がった層へ移すこと」である。（企業ソフトウェアの視点からの長尾の引っ越しについては、番外編『企業ソフトウェアの粘性』で完全に展開している。）
ソフトウェアの距離に比べると、IT技術の話は近い。2013年、Gene KimはGoldrattの工場の話をほぼそのままIT運用に持ち込んで、IT運用を救うためにCIOがどのようにして制約理論を使うかを書いた「フェニックス・プロジェクト」（The Phoenix Project）：IT部門が会社を潰すところを救うためにCIOがどのようにして制約理論を使うかを書いた。なので、「ソフトウェアの瓶頸を考える」というのは既に検証されたパスではなく、臨時で使う比喩ではありません。
2、ソフトウェアに戻る：コードを書くことが最も安い部分に変わっている
三つの数字で、「コードの生産コストがゼロに近づいている」ということを説明する。
コード生成コストのゼロへの接近
- Copilot：GitHub自社の研究によれば、Copilotを有効にしたファイル内では、約46%のコードがCopilotによって記述されている。口径に注意。これは「有効化されたファイル内」の比率であり、GitHub全体のコードの46%という意味ではない。
- Stripe：社内で開発したcoding agent「Minions」は、毎週1,300件以上のPRを生成しマージしている（初期は1,000件、継続的に増加）。ここで覚えておくべき重要な詳細がある。すべてのPRは人工レビューを経てマージされる。Stripeは「書く」ことを自動化し、「検収」を人間に残した。この点は第4節で使う。
- NVIDIA：ジェンスン・フアンは公に、100%のNVIDIAエンジニアがCursorなどのAIプログラミングツールを使っていると述べ、「AIを使わずに働くこと」はNVIDIAではもはや受け入れられないと語った。
三つの数字を重ね合わせると、結論は硬い。一行のコードを生産する単位コストは、急速にゼロに近づいている。
鋭い問いが随即浮かぶ。コードを書くことがほぼ無料になったのに、なぜソフトウェアは依然としてこんなに高く、こんなに遅く、こんなに納品しにくいのか。答えはまさに制約理論が与えるものである。あなたは「コードを書く」という工程を広げたが、瓶頸はただ移動しただけだ。それはどこへ移ったのか。
3. 四个瓶颈
この回では、4つのプロセスで瓶頸が発生している。
1. 問題の定義。
AIは数秒で「機能」というものを書くことができるが、「実際に必要な機能」は書くことができない。多くのソフトウェアプロジェクトは、作り上げたものが誰も使わないこと、最初から何を解決しようとしているのかを考えていないことから始まっている。コード生成が安価になったことで、「不明なビジネス問題を、明確で解決可能で価値がある規格に分解する」（問題の定義）が最も不足している、かつ最も高価なスキルになっている。製造業の同僚は、これに馴染んでいる。工芸路線や設計図を間違えると、車間で効率よく作業しても、大量生産で品物が不良になる。
2. システムの統合。
AIは「一つのコード」、「一つの関数」、「一つのページ」を生成するのが得意。しかし、実際に稼働するシステムは、数百の要素を統合し、それらがデータを共有し、境界を処理し、一致を保ち、エラーを耐えることができる。要素を生成するのは安価だが、要素を統合して、信頼性の高いシステムを作ることは高価である。このコストは、組織とアーキテクチャが一致すること、つまりコンウェイの法則とチームトポロジーに関わる問題である。製造業の CIO に戻ると、彼はコードを書く時間を費やしていない。MES、ERP、品質検査、報告などのシステムを連携する時間を費やしている。
第三の関：検証。 コード量が増加し、信頼性が低下している。誰が「これは正解だ」と決定するのか？テスト、コードレビュー、可観測性、グレイリリースなど、検証作業の負担は増加している。これは最も過小評価されている瓶頸であり、製造業の事例との類似も深い。このテーマは別稿で詳しく扱う。
第四の関：組織の調整。 チームに AI エージェントが増えると、誰が何をするか、誰がチェックするか、誰が結果に責任を負うか？これはコンウェイの法則とチームトポロジーの延長であり、組織の調整自体が瓶頸になる。シリーズ第 11 篇では、組織のノードがすべて人間でない場合、ガバナンスがどのように中核の競争力になるかを説明する。
四、最も深い切断：検証、およびトヨタの「自働化」が教えること
四つのバッテンリミットの中で、最も容易に誤解されるのは検証である。多くの人は、「AI が速いので、さらにテストを実行してみましょう」ということを理解している。ただし、これは一方しかない。検証が高価になる理由を理解するには、トヨタの概念である「自働化」（Jidoka）を正しく説明する必要がある。
先に広く流布している誤解を正す。自働化は、「AI または機械を人間に代わりに」や、「人間を機械のように、いつまでも働くようにする」ことではない。両方の方向が逆である。
自動化の真髄
自動化という字面に答えが隠されている。日本語では「自動化」は通常の自動化を指すが、トヨタ自動織機は特に「自働化」と書き表す。この「働」には人偏があり、人間の関わりを強調しているのだ。
自動化の正確な意味は、機器や生産ラインが異常を検知すると、自動的に停止し、人間が介入し、原因を解決し、再び生産を開始することです。自動化には2つのメカニズムが並行して動作します。機器自体に異常検知機能が搭載され、機器が停止するだけでなく、生産ライン上の誰でも異常を検知すると、安灯の糸を引くことで、全線が即座に停止します。
品質は末端検査ではなく、各工程に埋め込まれて、即座に解決します。
ここには反直感的な結論があります。正確に、自動化が深まるほど、品質基準と人間の介入の負担は増加するだけです。自働化は人間を「繰り返し作業」から解放し、異常を検知し、停止し、原因を解決するという位置に配置します。豊田は一線の労働者に全線の停止権限を与え、自動化が強くても、問題が生じたときに人間が停止する能力を与えることを、「機械に人間の知能を与える」という言葉の本当の意味です。人間は常に存在し、原因を解決します。
ソフトウェアはこの道を再歩み、しかも急いでいる。GitClear の AI によるコード品質に関する研究では、重複コードブロックの増加や短期的な churn コードの増加が観察されている：AI は速くコードを書くが、そのコードは「見た目は正しい」だけだ。大量のコードが誰も一行ずつ手で書かれていない状況では、従来の「開発者が心の中で把握している」という信頼メカニズムは機能しなくなる。そのとき必要になるのは、ソフトウェア版のアンダン绳とラインストップメカニズムだ：
- テスト（ユニット、インテグレーション、エンドツーエンド）は「できるだけ行う」から「ハードル」として昇格し、通過しないとマージを許可しない；
- コードレビューの焦点は「書き方のチェック」から「意図と境界条件の確認」へ移行する：このコードは一体何を解決しようとしているのか、境界条件は十分にカバーされているか；
- 可観測性（モニタリング、ログ、トレーシング）が標準装備となり、オンラインでの挙動がコードそのものよりも問題の本質をより明確に示すからだ；
- グレーディッドリリース／フィーチャーフラグにより、AI が生成したコードをまず小規模で検証し、問題がないことを確認した後に本番展開する。
振り返れば、第2節のStripeの1,300件のPR：コードはエージェントが書くが、マージという最終チェックはすべて人間のレビューに残された。これがソフトウェアにおける「自働化」の生きたモデルだ：生産は自動化し、検収は人間の手に残し、人間に「それを止める」権限を与える。生産は安くなり、品質管理は高価になる——これは40年間変わらない法則だ。
五、「問題定義」のプレミアム：プロンプトより価値のある能力
検証が過小評価されたボトルネックだとすれば、「問題定義」はさらに過小評価されている能力である。
プロンプトエンジニアリングは一時的に注目されたが、多くの人が「プロンプトが書けること」が核心能力だと誤解した。しかし、プロンプトとはあくまで「問題を表現する」ためのテクニックにすぎない。真に希少なのは、その一歩先にある問題定式化（problem formulation）——曖昧なビジネス上の課題を、明確で解ける価値のある問題に分解する能力だ。このステップは、AIが短期間で代替できない。なぜなら、AIはまず「問題が何か」をあなたが教えてくれるのを待たなければならないからだ。
製造業のベテランは、このステップの重みを最も実感している。エンジニアリング図面や製造プロセスが間違えば、下游の加工や組立がどれほど効率的でも、大量の誤った製品を生産するだけだ。ソフトウェアも同様だ。要件仕様が間違っていれば、AIは10倍のスピードで、誰も必要としない製品を次々と生み出す。
判断基準は明確だ：「コードを書く速度」を競うのではなく、「問題を分解する明確さ」を磨け。
組織内では、これを意味する。つまり、「要件定義」と「検証・受入」を正式な職位として設け、開発者が片手間でやるのをやめよ。AIが実装を安価にした今、この二つの職位のリターンが最も急激に上昇している。
六、四つの業界の実際のボトルネックは何か
「ボトルネックの移動」を四つの業界に当てはめると、それぞれのボトルネックは「コードを書くこと」にはない。
製造業。中心人物は冒頭で触れたCIOである。スマート生産計画、品質トレーサビリティ、エネルギー消費最適化などの機能は、技術的には難しくなく、既製品のモデルも多い。瓶頸はMES/ERP/検査/報告など複数のシステムの統合デバッグと、現場端末での実検証にある。この種のプロジェクトのコードは概して速く書けるが、MES/ERPなどのシステムの統合デバッグにかかる時間はしばしばコードを書く時間の数倍に達する。検収の工程を現場端末と統合段階に前倒ししてこそ、欠陥をその場で捕捉でき、稼働開始時になって初めて露見するのを防げる。
電信/キャリア。一つのプラン変更や法人専用線の開通プロセスは、チャネル、課金、CRM、ネットワーク開通、工事・保守スケジューリングなど複数の領域を横断する。AIは各領域の開発速度を大幅に引き上げるが、領域を跨ぐエンドツーエンドの統合デバッグと整合性検証こそが工期の本体である。キャリアにはもう一つ独自の瓶頸がある。コンプライアンスと照合である。課金が一銭違っても事故になり、検証の比重は他のどの業界をも大きく上回る。法人専用線の開通を例にとると、AIが各領域の開発を加速させても、エンドツーエンドの統合デバッグに課金照合を加えれば、依然として総工期の大部分を占めることが多い。
金融。クレジットリスク管理やマネーロンダリング対策のルールを調整する場合、アプリ間、コアシステム、リスクエンジン、データプラットフォーム、監督当局への報告までを跨ぐ。ここで検証される重みは極めて高く、1件のミスでもコンプライアンス事故になる。ボトルネックは説明可能性、監査可能性、追跡可能性にある：AIが書いたルールがどれほど正確でも、監督当局から「なぜその判断を下したのか」と問われて答えられなければ、リリースは許可されない。マネーロンダリングルールの改善は典型的な例だ：AIはルール作成を高速化するが、モデルの説明可能性審査と監督当局への対応を合わせると、全体のサイクルのほぼ半分を消費してしまう。
EC。プロモーションや大型セール機能は、商品、取引、マーケティング、倉庫、カスタマーサポートまでを跨ぐ。AIはページやAPIの作成を劇的に高速化するが、ボトルネックは負荷テスト、在庫一貫性、不正利用防止、精算に移った。セールの夜にダウンするのは、コードが遅かったからではなく、検証し漏れた境界条件だ。セール準備はその縮図だ：プロモーションページはAIが瞬時に生成できるが、エンドツーエンドの負荷テストと在庫一貫性の検証に、準備期間のほぼ半分が費やされる。
4つの業界に共通する点は明確だ：AIは「書く」ことを加速し、「つなげる」「検証する」「整合させる」ことで詰まる。節約した開発リソースをこの3つに投資することが、真の生産性向上につながる。
七、間違えた場合の影響：最も一般的な3つのミスマッチ
第一种：コードの書き方を速くする というのは、最も一般的な誤解だ。コードは、交付チェーンの一部にすぎない。加幅すると、チェーン全体が速くなるのではなく、瓶頸の後ろに半成品が溜まるだけだ。制約理論では、これを「ストック」と呼び、ソフトウェアでは未承認のPRと未連携のブランチを指す。結果は、開発者が忙しくなる、ビジネスが急迫する、出力が変化しないということだ。前述のCIOの状況と同じだ。
第二種：生産を速めることと、品質のチェックを省略する というのは、自働化の典型的な誤りだ。誰かが「AIでコードを書くことが速くて良くなるので、コードレビューを簡略化し、テストを省略できる」と思っているかもしれないが、実際は逆だ。生産が速くなると、品質のチェックがより重要になる。品質のチェックを省略すると、未検証のPRと未連携のブランチが増えて、欠陥が生産環境に急増することになる。
第三種：非瓶頸に資源を投入する というのは、制約理論がすでに明確に述べていることだ。集成が瓶頸であれば、AIのライセンスを購入するのではなく、集成に資源を投入することだ。検証が瓶頸であれば、開発者を増やすのではなく、検証に資源を投入することだ。非瓶頸に資源を投入すると、総生産量に影響を与えず、しかも会計が混乱するだけだ。正しい順序は、まず瓶頸を特定し、次に資源を瓶頸に投入することだ。
八、対決策者の提言
啓示一：ツールを買う前に、まず瓶頸図を描く。 最近３回のデリバリを分解してみて、時間はどこに費やしたのか。コードを書くことができない、組み立てられない、誰もチェックしなかった、要求がまだまだ明確でない。明確にできないものは、技術的な層面でただの推測にしかならない。瓶頸図は、どんなツールの購入リストよりも価値がある。それが大企業の無駄IT投資の半分を防ぐ。
啓示二：浮いた能力を、要件と検証に投入する。 AIにより、開発が速くなった。人手が余った。人を正式に「要求定義」と「検証検収」のポジションに据え、コードを書くことを止める。AI時代で最も成長するのは、この２つのポジションの収益だ。
啓示三：ソフトウェアに安全装置を設ける。 自動化の最も直接的な実装は、CI/CDにハードドアを設置すること。テストが通過しないとマージを許さない、レビューは意図と境界をチェックする、グレイデプロイは小規模で先行、可観測性は必須。生産が自動化されるほど、安全装置はより厳しくなる。これは、「コードが無料」が「事故が無料」になるのを防ぐため。
啓示四：人の配置を変えるのであって、人を排除するのではない。 自動化は、同じ結論を導く。自動化が深まるほど、人は「判断、検証、原因の解明」に配置される。人を繰り返し作業から解放し、検証と調整に配置する。これは、AI時代の組織設計の核心であり、本シリーズの後半で詳しく説明する内容だ。
９、質問されるかもしれない
「試験的試点は、本当に瓶頸の部分を確認する必要がある」
試点も、まずは瓶頸の部分を確認する必要がある。試点のこの段階で、本当に瓶頸の部分を確認しているかどうかを確認する必要がある。実際に瓶頸の部分は、集成や検証にあり、その場合、「コードを書く」段階でAIを試点することは、非瓶頸の部分に資金を投入することになる。正確に第7章で説明されている3つの不適合のうちの1つを踏み込むことになる。まずは小規模な瓶頸診断を実施し、ツールの費用が値打ちがあるかどうかを確認する。
「検証の段階が、交付を遅らせる可能性はあるか？」
短期的には摩擦が生じるかもしれないが、長期的には加速する。検証の段階がなければ、「速い」とは、欠陥を生産環境に送り出す速さであり、返却コストは10倍以上になる。自動化の経験から、欠陥を直すコストは、欠陥を流し下流に送り出すコストに比べてゼロに近い。
「これは、AIの転換とは何の関係がある？」
関係は非常に直接的。AIの転換の最もよく踏み込む罠は、瓶頸が「コードを書く / 産能」にあり、そこにツールを購入して幅を広げることである。まず瓶頸の診断を実施し、資金を投入する場所を決定する。正確に、能力評価と価値シナリオの認識を《AIの転換 7ステップ教練枠組み》の先頭に配置した理由が、このためである。
AI 時代ソフトウェアエンジニアリングの変革 シリーズの第3回です。
反省：最近のデリバリで止まったとき、時間はコードを書くのに費やしたか、または組み立て、検証、調整に費やしたか？あなたのAIツールは、安定してデプロイされ、ユーザーが実際に使用できるコードを出しているか？あなたのCI/CDには、「テストに合格しないとマージしない」という厳しい条件があるか？3つの質問のうち1つに心配な答えがあれば、すぐにAIツールを買うのではなく、自分の瓶ネックを探すことから始めましょう。
次のステップ
このシリーズの第15回の「AI 時代ソフトウェアエンジニアリングの変革」シリーズの3回目です。コンウェイ（組織が決定するアーキテクチャ）、チームのトポロジー（組織をどう設計するか）、瓶ネックの移行（コードがほとんど無料で、瓶ネックはどこに移ったか）を通じて、次の回（第4回）では、より実践的な視点で主流のAIプログラミングツールを選択する方法について説明します。結論は反直感的かもしれませんが、選択は組織の決定であり、成熟度と治理レベルに応じて選びましょう。
シリーズの概要：このシリーズでは、AIプログラミングツール、組織アーキテクチャ、ソフトウェアエンジニアリングのパラダイムの最新の進化を追跡します。2026年のコンウェイ定理のAIエージェント時代の新しい変化、最新のツール生態系の成熟度など。シリーズをフォローすると、継続的に更新される洞察を得ることができます。
このシリーズについて
AI 時代のソフトウェアエンジニアリングの変革
「AI 時代のソフトウェアエンジニアリングの変革」は、電信、金融、製造、電商などの業界の CIO/CDO/CTO および数字化責任者のための深い研究シリーズであり、全 15 篇です。200+ の学術論文と業界レポートに基づいて、証拠に基づく決定を参考にするためのレベル付きマークアップが提供されます。
私は、前 IBM のエンジニアであり、ICF 認定コーチでもあり、運営者や大企業の AI / 数字化プロジェクトの実装に携わった経験があります。ここに書かれているのは、企業が坑を踏んだ実戦判断です。
参考来源（均已核实）
- a16z (2026). Software in the Age of Agents. The a16z Podcast.（元マイクロソフトWindows社長Steven Sinofskyの名言「The long tail got no shorter, it just got longer in a different way」は、企業ソフトウェアの視点からTOCの瓶頸移動の法則を独自に裏付ける。一次ソース——ポッドキャスト原音。立場表記：a16zパートナー／元マイクロソフト高管、VC立場。ゲスト確認済み：a16z企業チームパートナーSeema Amble、元マイクロソフトWindows社長Steven Sinofsky（board partner）、a16z寄稿Elena Burger。2026年7月放送。）
- Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement.（制約理論TOCの原典、一次ソース。製造業の工場を舞台とした小説）
- Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press.（GoldrattのTOCをそのままIT運用に持ち込み、製造業→ソフトウェアの橋渡しをする。一次ソース）
- Toyota. Toyota Production System — Jidoka（自働化）. toyota-global.com（自働化＝人偏のついた自動化、異常時のライン停止＋人が介入して根本原因を解決。アンドンシステム。一次ソース）
- GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle.（Copilotが有効化ファイル内で約46%のコードを記述。口径は「有効化ファイル内」。一次ソース）
- Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog；InfoQ報道では毎週1,300+ PR、全量人工レビュー（一次＋二次ソース）
- NVIDIA / ジェンスン・フアン. 100%のエンジニアがCursor等のAIプログラミングツールを使用するとの公開発言（一次発言）
- GitClear (2025). AI-Assisted Code Quality Research.（AIアシスト下で重複コード／短期churnの上昇を観察、「検証のコスト上昇」を裏付け。二次ソース）
- Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press.（デリバリーパフォーマンスは文化、流動性、フィードバックによって決まり、個人のコーディング速度ではない。一次ソース）
buymeacoffee
