1つの変更は、8つの関門を通る：ジュニアエンジニアのための開発フロー地図【第1回】

「手元では動きました」と言った瞬間、レビューの指摘が3件返ってきて、テストで1件落ちて、リリース手順のどこで止まるかも分からない——この記事を読み終えると、あなたの書いた1行が「思いつき」から「本番で動き続ける状態」までに通る8つの関門と、関門ごとの出口条件を、1枚の地図として持てるようになります。ジュニアエンジニア向け開発フロー入門シリーズ（全8回）の第1回です。

🎯 テーマの主役：「開発フロー」——1つの変更が通る道

今回の主役は、特定のツールや言語ではなく開発フローという考え方そのものです。一言で言えば、開発フローとは「1つの変更を、思いつきから本番で動き続ける状態まで運ぶための、決められた手渡しの列」です。

日常の例えで言うなら、駅伝です。あなたは8区間のうちの1区間しか走りません。しかし、走る速さだけでは勝てません。たすきを渡す形式が決まっていない駅伝は、渡すたびに落とします。開発も同じで、あなたが書いたコードは、あなたの手を離れた後に要件・設計・レビュー・テスト・リリース・運用という別の走者へ渡されていきます。

ここで重要なのは、たすきの中身は「コード」ではないという点です。たすきの中身は「なぜこの変更をするのか」という意図と、その根拠です。コードだけ渡されても、受け取った人は「これは何のためにあるのか」を推測するしかありません。開発フローがうまく回っているチームでは、たすきの中身が毎回きちんと入っています。逆に詰まるチームは、どこかの区間でコードだけが渡され、意図が落ちています。

この地図を手に入れると、次の3つができるようになります。第一に、いま自分がどの区間を走っているのかを言えること（「実装中です」ではなく「設計の出口条件を確認中です」と言えます）。第二に、次の走者に渡すために何を準備すればよいかを自分で判断できること（レビュー依頼に何を添えるか等）。第三に、詰まったときに誰に何を聞けばよいかが分かることです。開発フローのトラブルの多くは、原因が別の区間にあるのに、いま走っている区間で悩み続けることで起きます。

動機：なぜ「書ける」のに「進まない」のか

ジュニアエンジニアとして最初に戸惑うのは、コードを書く能力と、開発が進む速度が別物だという点ではないでしょうか。研修では「動くものを作る」ことを学びます。ところが現場に出ると、動くものを作る時間より、動くものを作る前と後に費やす時間のほうが長かったりします。

あるあるなのは、こんな場面です。先輩から「この画面、エラーが出やすいから直しておいて」と頼まれ、半日で修正しました。レビューに出したら「この直し方だと、別の画面でも同じ問題が起きるよ」と言われ、修正し直し。テストを追加して、ようやくマージ。リリース後に「あれ、ログにエラーが増えてない？」と気づき、調査が始まる。あなたの書いたコードは文句なしに正しかったのに、3日かかったわけです。

この3日間の何が問題だったのかを「自分の実力不足」で片付けてしまうと、同じことが繰り返されます。実際に起きていたのは、区間のつなぎ目で情報が落ちていたという別の問題です。「エラーが出やすいから直して」という依頼には、「別の画面でも同じ問題が起きる」という情報が含まれていませんでした。あなたが悪いのではなく、たすきの中身が空だったのです。

この記事の仮説は、こうです。開発フローは「速く走るための装置」ではなく、「失敗を安く見つけるための装置」である。もしこれが正しければ、関門が増えることは遅くなることではなく、手戻りを消すことで総時間を縮めることになります。次のセクションから、この仮説を数字と実例で確かめていきます。

🔍 検証①：失敗は、見つける場所が遅いほど高くつく

まず、なぜ開発フローが「工程」に分かれているのかを、コストの面から確認します。ソフトウェア工学の古典的な調査では、同じ1つの欠陥でも、見つけて直す場所によって修正コストが桁で変わることが繰り返し報告されています。

バリー・ボーム（Barry Boehm）が1981年の著書『Software Engineering Economics』で示したコスト曲線は、よく引用されるものです。要件定義の段階で見つけた欠陥の修正コストを1とすると、設計段階では3〜8倍、実装中は10倍、納品後は100倍という幅で語られます。ボームとバシリは2001年の論文「Software Defect Reduction Top 10 List」でも、納品後に見つけた問題の修正は、要件・設計段階で見つけた場合の100倍になることが多いと述べています。

なぜこんなに差がつくのか。理由は「直す対象」ではなく「直すことの影響範囲」が増えるからです。

数値は文献により幅がありますが、桁が変わるという結論は一致しています。ここから導けるのは、シンプルな原則です。「早く見つけたほうが安い」。開発フローの工程は、この原則を実装した結果として生まれました。設計レビューがあるのは設計者が偉いからでも、テスト工程が独立しているのはテストが好きな人がいるからでもありません。後ろで見つけると高いから、前に見つける場所を用意しているのです。

🔍 検証②：8つの関門と、その出口条件

コストの話を踏まえると、開発フローの工程は「関門（ゲート）」として読み替えられます。各関門には「これを満たさないと次に進めない」という出口条件があります。出口条件は書類の枚数ではなく、答えられるべき問いです。

ここがジュニアエンジニアにとって最も実用的な部分です。自分のタスクが今どの関門にいて、次に進むために何が足りていないかを、自分で確認できるようになります。

この8つの並びを見ると、「書類を書く工程」は1つもないことに気づきます。要件定義書も設計書も、本質は書類ではなく「決まっていることの記録」です。逆に言えば、口頭で決まっていて全員が同じ理解を持てているなら、書類が薄くても関門は機能します。関門の本質は書類ではなく、問いに答えられる状態になっていることです。

🔍 検証③：関門ごとに、防いでいる失敗の種類が違う

「関門が多いと面倒だ」と感じる理由の1つは、同じことを何度も確認しているように見えるからです。しかし実際には、関門ごとに防いでいる失敗の種類が違います。これは重要な区別です。同じ欠陥を8回探しているのではなく、8種類の違う失敗を1つずつ潰しているのです。

たとえば「設計」と「レビュー」は、どちらもコードを読むので似て見えます。しかし設計が防ぐのは「変えられない構造になること」、レビューが防ぐのは「一人の思い込み」です。だから設計を丁寧にやっても、レビューは不要になりません。逆も同じです。関門は置き換え関係ではなく、積み上げ関係にあります。

🔍 検証④：関門は一直線ではない——戻ることを前提に設計する

ここまでの説明は「課題→要件→…→運用」という一直線の流れに見えたかもしれません。しかし実際の開発は、必ず戻ります。実装中に「この要件は矛盾している」と気づく。レビューで「設計を見直したほうがよい」となる。テストで「そもそも仕様が違う」と発覚する。戻ること自体は失敗ではありません。

重要なのは、戻る距離と回数です。開発プロセスのモデルは、この「戻り方」の設計が違うだけで、大きく2種類に分けられます。1つは大きなループを1回転させる進め方（要件を全部固めてから設計し、設計を全部固めてから実装する。一般にウォーターフォールと呼ばれます）。もう1つは小さなループを何回も回す進め方（機能を小さく区切り、要件・設計・実装・テストを1機能ずつ回す。アジャイルや反復型と呼ばれます）。

どちらが優れているかは、状況によります。変化が少なく、関係者が多く、後戻りが高くつく（例: 組込み機器の量産、法規制のあるシステム）なら、大きなループが合理的です。変化が速く、利用者に近い（例: Webサービス）なら、小さなループが合理的です。「どちらが正しいか」ではなく「何を犠牲にするかの選択」です。

なお、ウォーターフォールの原型とされるロイス（Winston W. Royce）の1970年の論文は、実は反復を推奨していました。「各工程を1回ずつ流すやり方はリスクが高い」と述べ、前の工程に戻ってやり直す前提の図を描いています。「ウォーターフォール＝ロイスの提案」という理解は、後世の単純化です。この話は、開発プロセスの名前を覚えるより、「なぜその順番なのか」を考えるほうが大事だという良い例になっています。

🔍 検証⑤：実は「関門を守るのはあなた自身」である

ここまで「関門」と言うと、チームや上司があなたをチェックする仕組みのように聞こえたかもしれません。しかし、実際にこの地図が効くのは逆方向です。あなたが自分の変更を次の人に渡すときに、何を添えるかを選ぶという場面で効きます。

具体例で考えます。レビュー依頼を出すとき、次のどちらが速くレビューされるでしょうか。Aは「修正しました。レビューお願いします」とだけ書かれた依頼。Bは「◯◯のエラー報告（チケット#123）に対して、①再現テストを追加し、②原因は△△だったので□□に変更しました。影響範囲はこの画面だけで、既存のテストは全て通っています。見てほしいのは□□の選択が妥当かどうかです」と書かれた依頼。

Bのほうが速いのは明白です。Bは、関門1〜6の出口条件を自分で確認し、その結果をたすきに入れているからです。レビュアーは「これは何の話か」を推測する必要がなく、判断すべき1点に集中できます。開発フローの速度は、たすきの中身の質でほとんど決まります。

結果：この地図で何が変わるか

ここまでの検証を整理します。開発フローを8つの関門として捉えると、次の3つが変わりました。

第一に、「自分のタスクがどこで詰まっているか」を特定できるようになりました。「なんか進まない」ではなく、「設計の出口条件（触る範囲）が決まっていないから進まない」と言えます。詰まりの名前が分かれば、聞くべき相手も分かります。

第二に、「省略してよい関門」と「省略できない関門」を判断できるようになりました。コストは後ろほど高いので、前の関門ほど軽く見えますが、前の関門の失敗は後ろで増幅されます。1行の誤解が設計を経て実装されると、修正は10倍です。逆に、影響が自分の中で完結し、すぐ戻せる変更なら、関門を軽く通してよい場合もあります。

第三に、「関門は監視ではなく、渡し方の設計だ」と理解できました。たすきの中身（意図と根拠）を自分で充実させることが、開発フロー全体の速度を上げます。

なお、このシリーズは全8回で、各回が1つの関門に対応します。第1回の今回は全体地図を作りました。以降、関門を1つずつ掘っていきます。

考察：関門は「手続き」ではなく「見つける場所の設計」である

ここからは、検証では扱いきれなかった解釈を述べます。私の考えでは、開発フローの誤解は「工程は作業の区切りである」という理解から生まれます。工程は作業の区切りではなく、「この種類の失敗は、この場所で見つける」という配置の設計です。だから、工程の名前を覚えることにはほとんど価値がありません。価値があるのは、「いま心配している失敗は、どの関門で捕まえるのか」を考えられることです。

この見方には、もう1つ副産物があります。関門は、省略の是非を自分で判断できるという点です。影響が小さく、すぐ戻せる変更（社内ツールの表示文言の修正など）に、重い設計レビューを要求するのは、コストの原則に反します。逆に、戻せない変更（データベースの削除、公開APIの仕様変更など）は、関門7の「戻す手順」を特に厚くする必要があります。関門の重さは、変更の戻しにくさに比例させるのが合理的です。

そして、この地図はAI時代に価値が上がると考えられます。生成AIが実装の速度を上げるほど、ボトルネックは実装以外の関門に移ります。何を作るべきか（関門1〜2）、何をもって正しいとするか（関門2・6）、出してよいか（関門7）の判断は、依然として人の仕事です。実装が速くなるほど、たすきの中身の質が速度を決めるという性質が強まります。

📌 注目ポイント

• 開発フローは「速く走る装置」ではなく「失敗を安く見つける装置」である。関門は後ろで見つけると高いものを、前に見つけるために置かれている
• 同じ欠陥でも、見つける場所で修正コストは1対100まで変わる（Boehm 1981、Boehm & Basili 2001）
• 8つの関門はそれぞれ違う種類の失敗を防いでいる。置き換えではなく積み上げ
• 関門の出口条件は書類の枚数ではなく、答えられる問い。「誰の何が変わるか」を1文で言えるか
• たすきの中身はコードではなく意図と根拠。開発フローの速度はたすきの中身の質でほとんど決まる
• 関門の重さは、変更の戻しにくさに比例させる。戻せない変更ほど「戻す手順」を厚くする

💡 活用事例：19項目のチェックリストが、手術の死亡率を半分にした

開発フローが「失敗を安く見つける装置」であることは、ソフトウェア以外の分野に、より劇的な形で現れています。WHO（世界保健機関）が2009年に導入した「手術安全チェックリスト」の話です。

2009年、アトゥール・ガワンデ（Atul Gawande）らは、世界8都市の病院で19項目のチェックリストを使う前後を比較する研究を実施しました。チェックリストの中身は、驚くほど当たり前に見えるものです。麻酔をかける前に「患者の名前と手術部位を確認したか」「アレルギーはないか」「出血量は想定されるか」。執刀前に「全員が名前と役割を名乗ったか」「抗生剤は1時間以内に投与されたか」。終了前に「器具の数は合っているか」「検体のラベルは正しいか」。

結果は、合併症率が11.0%から7.0%へ、死亡率が1.5%から0.8%へ低下しました（ニューイングランド・ジャーナル・オブ・メディシン誌、2009年）。参加したのは8施設で、研究デザインには前後比較という限界があります。それでも、新しい薬でも新技術でもない「手順の確認」だけで、これだけの差が出たという事実は重い意味を持ちます。

このチェックリストが効いた理由は、医学知識の不足を補ったからではありません。優れた外科医でも、手術中に名前を確認し忘れる、抗生剤の投与タイミングを失念する、器具の数を数え間違える——人間の注意力は、疲労と緊張の下では信頼できないからです。チェックリストは、失敗を人の注意力に依存させない場所を作りました。これは開発フローにおけるテストとCI（継続的インテグレーション）の役割と、本質的に同じです。人の記憶と注意力に頼らず、機械的に確認する場所を先に作る。第7回で扱う自動テストとCI/CDは、この考え方のソフトウェア版です。

なお、チェックリストは「導入すれば必ず効く」ものではありません。研究では、チームの自律性を尊重し、現場ごとに項目を調整した施設ほど定着し、形だけ導入した施設では効果が薄かったことも報告されています（2014年のBMJ Quality & Safety誌のレビューなど）。関門は、形骸化した瞬間に機能を失う——この教訓は、開発フローにもそのまま当てはまります。

✅ 要点まとめ

• 開発フローは、1つの変更を課題から運用まで運ぶたすきリレー。たすきの中身はコードではなく意図と根拠
• 関門は8つ：課題・要件・設計・実装・レビュー・テスト・リリース・運用
• 修正コストは見つける場所が遅いほど高く、本番後は要件段階の約100倍に達しうる（文献により1対10対100の幅）
• 各関門の出口条件は「書類」ではなく「答えられる問い」。例：設計なら「触る範囲と境界を即答できるか」
• 関門ごとに防ぐ失敗の種類が違うので、1つを厚くしても他は代替できない
• 関門は一直線ではない。戻る距離と回数を短くするようにプロセスを選ぶ
• 関門を守るのは監視される側ではなく、渡す側であるあなた自身。たすきの質が全体の速度を決める

🚀 取り込み方：明日から使う3段階

今日（5分でできること）：自分の作業を8つの関門に当てはめて、今どの関門にいるかを1回書いてみてください。ノートでもチャットの下書きでも構いません。「要件の出口条件がまだ曖昧」と気づくだけで、次にやるべきことが変わります。手元のタスク管理ツール（GitHub Issues、Jira、Backlog等）のチケットに「現在の関門」を1行メモする運用でも効果があります。

今週（小さく試す）：次に誰かに作業を渡すとき（レビュー依頼・質問・進捗共有）、上記の「良い例」の形式で意図と根拠を1つ添えてみてください。「課題は◯◯、原因は△△、迷っている点は□□」。相手の返信が速く、的を射るようになるかを観察します。GitHubのプルリクエストの説明欄や、Slackのメンションに書くのが手軽です。

今月（定着させる）：自分の担当範囲で「戻せない変更」を1つ選び、その変更にだけ関門7（戻す手順）を厚く適用してみてください。データを消す処理、公開インタフェースの変更、設定の切り替えなどが候補です。「戻し方を先に書いてから実装する」という順番を1回体験すると、関門の重さを変える感覚が身につきます。あわせて、チームの開発フローがどこで詰まりやすいかを1か月観察し、「どの関門が薄いか」を1つ特定してみてください。

🔥 ハマりポイント

その1：工程を増やすと遅くなると考える
「レビューも設計もテストも、挟むほど遅くなる」と感じがちですが、コストの原則は逆を示します。遅くなるのは、関門の運用が重すぎるとき（形だけの分厚い書類、目的のないレビュー会、何も検証しない確認会）です。関門の目的が「この種類の失敗を捕まえること」に絞られていれば、1つの関門は数分で終わります。重さの原因は関門の存在ではなく、目的の曖昧さです。

症状：会議と書類が増えたのに手戻りが減らない。原因：関門が「確認すること」自体を目的化している。対処：各関門に「ここで捕まえたい失敗は何か」を1行で書き、その1行に寄与しない作業を削る。

その2：出口条件を「書類の完成」だと考える
「設計書ができたら設計完了」という理解は、実務で最も事故を生む誤解です。設計書が分厚くても、触る範囲が読む人によって違うなら、設計は終わっていません。逆に、口頭とホワイトボードで全員が同じ理解を持てているなら、設計の関門は通っています。

症状：レビューで「それってどういう意味？」が繰り返される。原因：決まっていることと決まっていないことの区別がない。対処：「決めたこと」「決めていないこと（後で決める）」「決められないこと（前提待ち）」の3分類でメモを残す。

その3：関門を「他人が自分をチェックする仕組み」だと捉える
この捉え方だと、関門は脅威になり、本当の問題を隠す動機が生まれます。「テストは通っています」と嘘を書く、レビューで指摘されそうな箇所を小さく見せる——これが最も危険な状態です。関門は本来、あなたが次の走者に渡すための道具です。脅威として機能し始めたチームでは、失敗が早く共有されなくなり、結果として後ろで爆発します（第8回のポストモーテムで扱うテーマです）。

症状：レビュー前に「指摘されないか」が会話の中心になる。原因：関門が評価と結びついている。対処：関門を通過したかどうかではなく、どう早く失敗を見つけたかを話題にする。

🔄 代替技術との比較：開発プロセスのモデル

ここでは代表的な開発プロセスのモデルを比較します。どれが優れているかではなく、何を犠牲にするかの違いとして読んでください。

補足として、スクラムは「スプリント」と呼ばれる固定期間で機能を1つずつ完成させますが、その中でも要件・設計・実装・テストの関門は各スプリント内に存在します。モデルが変わっても関門は消えません。関門が回る周期が変わるだけです。また、カンバンは「WIP制限（同時に進行中の作業数の上限）」によって、関門で詰まっている作業を可視化するのが本質です。第5回で扱うレビューの滞留は、カンバン的な見方で発見しやすくなります。

📅 今後の展望：開発フローの物差しは「4つの鍵」へ

開発フローの良し悪しをどう測るか、という議論はここ10年で標準化が進みました。その代表がDORA（DevOps Research and Assessment）の4つの指標です。DORAはGoogle Cloudが継続している調査研究で、次の4つを測ります。デプロイ頻度（どれくらいの頻度で本番に出すか）、変更のリードタイム（コミットから本番まで何時間かかるか）、変更失敗率（出した変更のうち何％が問題を起こすか）、復旧までの時間（壊れたとき、どれくらいで戻せるか）。

重要なのは、この4つは互いにトレードオフではないという調査結果です。『Accelerate』（Forsgren、Humble、Kim、2018年）以降の調査では、デプロイ頻度が高い組織ほど、変更失敗率が低く、復旧も速い傾向が報告されています。これは「速く出すと雑になる」という直感に反します。理由は本記事のテーマそのものです。速く出せる組織は、関門を省略しているのではなく、関門を自動化して速く通しているからです。第7回で扱うCI/CDは、この「速さと安定性の両立」を実現する仕組みです。

もう1つの潮流は、プラットフォームエンジニアリングです。開発者が関門を通しやすいように、ビルド・テスト・デプロイの環境を内部プラットフォームとして整備する動きで、ThoughtworksのTechnology Radarなどで継続的に注目されています。そしてAIの進展により、実装（関門4）のコストが下がる一方で、要件・設計・検証の相対的な比重が上がるという変化が起きています。関門の地図を持っていることは、この変化の中で自分の価値をどこに置くかを考える道具にもなります。

まとめ

この記事を読んだあなたは、次に作業を始めるとき、「いま自分はどの関門を走っているのか」を最初に考えるようになります。そして、次に誰かに渡すとき、たすきに意図と根拠を入れるという選択ができるようになります。

開発フローは、あなたを縛る規則の集まりではありません。失敗を安い場所で見つけるために、先人たちが配置した観測所の一覧です。関門の名前や書類の形式は会社ごとに違いますが、問いは同じです。「誰の何が変わるのか」「何をもって完了とするのか」「壊れたらどう戻すのか」。この3つに答えた瞬間、あなたの変更は次の走者へ渡せる状態になります。

第2回では、最初の関門である「課題」と「要件」を掘ります。曖昧な依頼を、検証できる仕事に変える方法です。「いい感じに直して」と言われたとき、何をすればよいのかを具体的に決める手順を扱います。

参考文献

1. Barry W. Boehm, “Software Engineering Economics”, Prentice Hall, 1981（コスト曲線の原典） — https://www.pearson.com/
2. Barry Boehm, Victor R. Basili, “Software Defect Reduction Top 10 List”, IEEE Computer, Vol.34, No.1, 2001 — https://www.cs.umd.edu/~basili/publications/journals/J87.pdf
3. Winston W. Royce, “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON, 1970 — http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
4. Kent Beck et al., “Manifesto for Agile Software Development”, 2001 — https://agilemanifesto.org/
5. Ken Schwaber, Jeff Sutherland, “The Scrum Guide”, 2020 — https://scrumguides.org/
6. David J. Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”, Blue Hole Press, 2010 — https://www.djaa.com/
7. Jez Humble, David Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison-Wesley, 2010 — https://continuousdelivery.com/
8. Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate: The Science of Lean Software and DevOps”, IT Revolution Press, 2018 — https://itrevolution.com/
9. DORA, “Accelerate State of DevOps Report” — https://dora.dev/
10. Alex B. Haynes et al., “A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population”, New England Journal of Medicine, 360:491-499, 2009 — https://www.nejm.org/doi/full/10.1056/NEJMsa0810119
11. Atul Gawande, “The Checklist Manifesto: How to Get Things Right”, Metropolitan Books, 2009 — https://atulgawande.com/
12. NIST, “The Economic Impacts of Inadequate Infrastructure for Software Testing”, 2002 — https://www.nist.gov/publications/economic-impacts-inadequate-infrastructure-software-testing
13. ISO/IEC/IEEE 12207:2017, “Systems and software engineering — Software life cycle processes” — https://www.iso.org/standard/63712.html
14. Google, “Google’s Engineering Practices documentation” — https://google.github.io/eng-practices/
15. Taiichi Ohno, “Toyota Production System: Beyond Large-Scale Production”, Productivity Press, 1988（自働化とアンドンの原典） — https://www.routledge.com/
16. Thoughtworks, “Technology Radar”（プラットフォームエンジニアリングの動向） — https://www.thoughtworks.com/radar
17. 経済産業省, 「DXレポート 〜ITシステム『2025年の崖』の克服とDXの本格的な展開〜」, 2018 — https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/