1 瀑布式开发和日企的相爱

瀑布式开发是一种阶段严格分离、顺序推进、强调文档与审查的开发方式。瀑布式开发 = 一步一步往下走，不能回头，像瀑布一样，流下去就流不回来了。瀑布式开发又可以被分为6大关卡，搞需求，做设计，详细设计，写代码，测试，交付。

典型流程为：要件定義 → 基本設計 → 詳細設計 → 製造 → テスト → リリース

日企和瀑布模型的强联系

日企看重：稳定 不出错 责任清楚 文档齐全

瀑布式模型：流程死 好管理 好追责 不容易乱

尤其在 银行、保险、制造、政府系统等强监管行业，瀑布式或瀑布为主的混合模式依然是主流。

需要客观说明的是，日本互联网企业（如 楽天、LINE）在部分业务中采用更接近敏捷或DevOps模式。但在传统大型SI行业（如 富士通、日立製作所、NEC、野村総合研究所），瀑布或日式瀑布 + 局部敏捷仍然占据主导地位。所以更准确的说法是，日本传统SI行业以瀑布为主导，部分环节融合敏捷实践，而非完全纯瀑布。

日企+瀑布：极度规范、文档驱动、阶段严格、不可回溯、责任清晰、质量优先

1.1 日式瀑布模型的标准流程

（固定 6 步，一步都不能少）

① 要件定義（ようけんていぎ） = 需求分析

• 写死所有需求、功能、规则、界面
• 输出：要件定义书（几十上百页）
• 原则上冻结需求（变更需走正式流程）

② 基本設計（きほんせっけい） = 概要设计

• 架构、模块、接口、数据库设计
• 输出：基本设计书
• 评审通过才能进下一步

③ 詳細設計（しょうさいせっけい） = 详细设计

• 每个函数、逻辑、界面细节、甚至代码框架
• 输出：详细设计书（程序员照着写代码）
• 评审通过才能开发

④ 製造（せいぞう） = 编码

• 程序员严格按设计书写代码，几乎不自己设计
• 强调 “忠实实现”，不允许自由发挥

⑤ テスト= 测试

• 单元测试 → 结合测试 → 系统测试 → 验收测试
• 每个阶段都有测试报告、问题票、回归测试
• 问题不闭环不能上线

⑥ リリース + 運用保守（うんようほしゅ） = 上线 + 运维

• 上线后持续维护、bug 修复、小版本迭代
• 大改 = 重新走一遍瀑布流程

2 日式瀑布为主 + 敏捷为辅

日企互联网里的敏捷，核心不是照搬西方 “极致灵活、完全自组织、快速试错” 那套范式，而是在日式组织文化与互联网速度之间找平衡的折中方案—— 可以理解为：带 “日式约束” 的轻量化迭代开发。

要件定義 → 基本設計 → 【Scrum/Kanban 開発】 → 结合テスト → リリース

敏捷开发阶段位于中间：把详细设计 + 开发 + 单元测试，放进 2 周 Sprint；每个 Sprint 输出：可演示、可测试的小版本；不再等全部设计完才开发。

2.2 Scrum 仪式如何融入瀑布

① Sprint 計画会

融入点：瀑布的「詳細設計開始前」

• 做什么：从已经定好的基本設計里，挑出这 2 周要做的功能变成 Sprint Backlog
• 日式特色：计划必须文档化，不能口头定

② 每日スクラム（15 分）

融入点：开发过程中的全程执行

• 做什么：全员站立发言，不展开讨论细节、不争论解决方案，只同步关键信息。昨天完成了什么？今天要做什么？遇到了什么阻碍？
• 作用：让瀑布式的大项目不跑偏、不延期、风险早发现

③ Sprint レビュー（デモ）

融入点：每 2 周代替传统的「進捗報告会」 

• 做什么：给上司 / 関係者看实际画面早确认、早修正避免最后才发现不符合需求

④ Sprint ふりかえり（回顾会）

融入点：开发阶段持续优化流程

• 做什么：改善瀑布里常见的：手戻り多、コミュニケーション不足、仕様のズレ

前半：瀑布（要件・設計）

• 确保需求不漏、设计不乱、文档齐全
• 符合日式的「慎重・確実」

中間：Scrum / Kanban（開発）

• 快速迭代
• 进度可视化
• 早デモ・早フィードバック（feedback）

后半：瀑布（テスト・リリース）

• 品質重視
• 手順遵守
• リスク回避

3 日企的外包开发

绝大多数外包公司，拿到的不是详细设计，而是「基本设计」，然后自己做详细设计 + 制造 + 测试。

日企 IT 外包的真实层级（从上到下）

1. 元請け（もとうけ） —— 总包（日立、富士通、NEC、野村総研等）
2. 一次請け —— 一级外包
3. 二次請け —— 二级外包
4. 三次請け —— 底层外包（很多中国人在这层）

3.1元請け（总包）做什么？

元請け负责控制预算与客户关系，只做 要件定義 和 基本設計，然后把下面的活全部外包出去。总包绝对不会把详细设计做完再给出去，原因：详细设计工作量巨大，成本高，总包要赚差价。

3.2 一次請け / 二次請け（大多数中国公司所在层）

拿到的是 基本設計書 然后中国外包公司要做是 詳細設計 製造（编码）結合テスト / システムテスト，也就是说中国外包公司要从基本设计推导出详细设计。

3.3 三次請け

三次請け才有可能拿到完整的详细设计书

这类外包公司只需要做，照着写代码，简单的单元测试。这就是所谓的 「コーダー」—— 纯码农，不用动脑，不用设计。多数技术外包企业，拿到的是基本設計，必须自己做詳細設計，真正能拿到「详细设计」直接写代码的，极少极少。

总结日企的it外包开发来看，主要分为三个层级：元請け：画大纲（基本設計）；外包（中国外包公司）：写细节 + 写代码 + 测试；底层外包：只写代码。

所以总结来看如何从「基本設計書」推导出「詳細設計書」这是中国人在日企外包最核心、最赚钱的技能。

4 AI驱动的新开发模型如何影响日企外包

AI 对日式瀑布模型的冲击不是颠覆，是内部被掏空，外壳还活着。流程还是瀑布，但里面的活儿，正在被 AI 吃掉。

4.1  日式瀑布的本质不会死

因为日式瀑布的根不是技术，更多的是日企文化：

• - 責任の明確化（责任明确）
• - 手順の遵守（遵守流程）
• - 品質重視（质量优先）
• - 監査・記録（审计、留痕）

这些AI 改不了。 所以要件定義 → 基本設計 → 詳細設計 → 製造 → テスト → リリース这个6段階的模式会保留下来。

4.2 被冲击的是人做的工作

AI 进来后，每个阶段的工作量、岗位价值全变了。接下去按着日式瀑布模型的六大阶段进行探讨。

1. 要件定義（需求分析）

变化不大。客户要什么、业务规则、业务流程，这是人客户自己对业务的理解，AI 只能辅助整理，不能替代。

影响：小

2. 基本設計（基本设计）

被辅助，但还是人主导，数据表设计、页面跳转、功能拆分，AI 可以给建议，自动生成表结构草案，但最终决策、责任、整合必须是人。

影响：中

3. 詳細設計（详细设计）

第一个被 AI 暴打的环节。 以前的基本設計由人编写详细设计（最耗费人力和时间），现在的 AI 已经能够理解基本设计书的内容 ，自动生成处理流程图、自动生成项目定义，自动生成错误模式、自动生成详细设计书的草稿。 未来几年趋势很可能是，详细设计由“人工编写”为主，转向“AI生成 + 人类审核”为主

影响：中

4. 製造（コーディング）

AI对编码效率提升已被多项研究验证。

• GitHub Copilot 实验显示部分任务效率提升 30%-55%

• 多个行业报告指出 AI 可承担重复性代码生成与重构工作

---

以前： 详细設計書 → PG 写代码

现在： 详细設計書 → AI → コード自動生成

Bug 修复靠 AI，代码重构也靠 AI。只会纯手写代码的程序员岗位将会大量消失。但也需要客观分析，对于复杂系统架构，跨模块整合，性能优化，安全合规，仍需高级工程师。

影响程度：高，但非完全替代。

5. テスト

AI可以从需求生成测试用例到自动生成测试脚本，然后分析日志定位问题。趋势将是测试人员从“写用例”转向“设计覆盖策略与判断质量”。

影响：高

6. 发布・运维

进一步自动化 CI/CD + AI 故障分析，人的工作变成監督と判断，但审批与风险承担仍在组织。

影响：中

5 展望

3-5年后的日式软件开发模型其流程外壳依然是日式瀑布 6 段階，客户、元請け、外包、文档、審査、承認一切形式都在。但内部变成：

• 1. 人：要件定義 + 基本設計
• 2. AI主导：详细設計 自動作成
• 3. AI主导：コード 自動生成
• 4. AI主导：テスト 自動実行
• 5. 人：最終確認 + リリース

流程形态保留，人力结构重组。瀑布流程不死，但「详细設計～制造～测试」这三段的人力岗位，会被AI吃掉一大半。

危险的不是“写代码的人”，而是只会执行、不会判断的人。

① 只做「详细設計 + 写代码」的人 最危险，最先被替代，会「从基本設計 → 用AI生成详细設計 + 审核」的人将变成新的主流岗位；② 能做「上流工程」的人 ，从要件定義 → 基本設計 → 业务理解 → 客户调整将最安全、最值钱 。所以总结来看AI 不会干掉日式瀑布， 但会干掉瀑布里「中间层的人力」。

未来价值排序更可能是：

1. 上流工程（业务理解 + 架构能力）

2. AI协作能力（Prompt设计 + 评审能力）

3. 纯实现能力（code能力）