在日本日系企業進行軟體系統開發，整個開發流程從規劃到上線整個流程會相當耗時，這可能也與日本人喜歡先寫文件再開發、注重細節到極致的個性有關係。
最近開始到日本的一間保險公司出差，從頭開始著手學寫基本設計書和詳細設計書文件。這也是難得的學習經驗，讓我了解到日本所謂的系統工程師（System Engineer , SE)的工作內容，就是逃恥中津崎平匡的職稱ＸＤ。本系列將介紹日本IT產業的軟體系統開發流程。這篇將紹從企劃到基本設計的開發過程：
一.企画（きかく）：這是公司為了達成經營目標、規劃系統開發的最階段，由非技術人員搜集準備預計要開發的要件（ようけん），即系統開發的需求，並透過商業分析與分析方法，分析此次系統開發的優缺點，並撰寫成企劃書，用來與技術人員溝通，使用的是非技術用語撰寫的提案。有時也稱為要求分析（ようきゅうぶんせき）、業務分析（ぎょうむぶんせき）。
二.要件定義（ようけんていぎ）：這是說明系統需求與討論結果的文件，會決定系統要實現的機能（きのう）與性能（せいのう），即系統開發時要有的功能、資料庫架構，以及相對應的開發時程，將需求書面化。英文也稱為需求定義文件（Requirements Definition Document, RDD）。
如果是系統前端的專案，設計師需要出UI設計的初稿。系統後端的專案則是會出資料庫架構的Schema初稿、預計使用的雲端方案或伺服器架構的infrastructure等等。
另外也會決定要使用的技術方法、程式語言，預計開發的時程與多少工程師人數、系統開發預算等等，對於任何系統未來的想像，都將在這個階段打合せ（うちあわせ）。這邊比較有趣的是，日本公司會將人力與預算「人月」化，並以每隻API程式碼預計撰寫的行數量化作為預算規劃。例如：4隻API或2000行程式碼，需要70萬/人月的系統設計費用，40萬/人月的開發費用。
三.基本設計（きほんせっけい）、外部設計（がいぶせっけい）：這是進到技術人員開發撰寫設計書的第一個階段。要撰寫的設計書成果物（せいかぶつ）自己大致將其分成兩大部分，系統整體概況與每個單獨功能的設計書，以下分別說明需要撰寫的設計內容：
１。系統整體概況，需要撰寫的內容通常包含：
(1)システム全体図: 整體系統架構的關聯圖，網路側包含網路架構如使用的port、IP。系統側的前端畫面、後端伺服器、資料庫之間的連動與運作方式、系統各個部分使用到的程式語言與實現方法。
(2)業務フロー: 即業務流程圖，各個業務需求，從使用者使用到結束的流程圖。例如購買保險、保險人員評估、系統試算、試算調整、保險明細顯示等一系列的業務執行流程。
(3)画面（帳票）レイアウト一覧: 細分所有使用者的操作畫面功能，作為索引，再從此一覽中去檢索相對應的功能畫面。
(4)API一覧: 細分所有系統操作的單隻API、程式，方便查找其對應的設計書。
(5) エラー一覧: 即錯誤訊息一覽，方便查找所有錯誤訊息
(6) データベース設計関連:即資料庫設計，包含各表之間的關聯係的ER Model/Diagram、各表之間根據業務實行CRUD時，各表之間的連動方式與圖型。
(7) 区分コード一覧: 各種分類的區分code，例如日本地址的區分號碼、信用卡種類區分的號碼。
(8) クラス一覧: 物件導向程式設計的基礎，會寫明所有系統中所有的class的功能說明、設計書與程式的使用的對應的索引，方便查找與理解class關聯。
2.每個單獨功能的設計書:
每個單獨功能的設計書的參照是來自API一覧、画面（帳票）レイアウト一覧，每一本設計書都會是單獨的一個Excel檔案，每個sheet內容會包含：
(1)修正履歷：會針對該本設計書做版本控制，詳列每次異動的內容，版本號從1.0.0開始，每次增修都需要改版號。
(2)記述要領：主要是介紹設計書內容常用的專有名詞與圖型符號代表的意思，算是每本設計書都會有的共通部分，讓第一次拿到設計書的人，也能看懂設計書用。
(3)機能定義書：這邊會有該功能的基本資料，如功能說明、功能名稱、調用的資料庫、輸入輸出的資料型態，以及需要繪製整個功能的流程圖。流程圖從輸入到輸出，中間經歷的階段，會從10編號開始編列，依序為20、30、40來標注流程圖。例如檢查權限、調用資料庫、timestamp日期顯示等等都會算是其中一個階段。
(4)処理仕様：針對（３）的機能定義書的每個階段定義做說明，例如調用資料庫，要取的table名、效能分析結果決定使用的sql、會使用的共通class、遇到錯誤需要丟出的エラー訊息等等，把會需要使用的整個商業邏輯用日文寫清楚，但還不需要定義變數、撰寫程式碼。
以上先介紹到撰寫基本設計的階段，後續會再繼續介紹剩下的開發流程：詳細設計、程式開發、単体テスト、結合テスト、総合テスト與運用保守的過程。
