研修先の会議に同席していたとき、参加者の方が小声で聞いてきました。「BDって何の略ですか」。
配られた資料には工程が略語で並んでいて、社内では当然のように通じている。でも中途で入った人には読めない。私も別の現場で同じ目に遭っています。
答えを先に書くと、BDは Basic Design の頭文字で、日本語では基本設計と呼ばれる工程です。ただこの対応が会社によって違うのが今回の本題です。
同じ工程に4つの名前が付いていた
私が関わったある案件で、同じ設計工程を指す言葉が4つ出てきました。発注側の資料には「基本設計」、開発会社の見積書には「外部設計」、進捗表には「BD」、そして議事録では「方式設計」。
全部同じものでした。気づくまでに2週間かかっています。会議で「外部設計はいつ終わりますか」と聞かれたのに、自分は基本設計の話をしていると思って答えていた。噛み合っていないのに、双方が噛み合っていると思っている状態が続きました。
これは私の不注意でもありますが、そもそも用語が揺れやすい構造になっています。
規格が決めているのはプロセスで、工程名ではない
システム開発の進め方には国際規格があります。ソフトウェアが ISO/IEC/IEEE 12207:2017、システム全体が ISO/IEC/IEEE 15288:2023。日本の規格では JIS X 0160:2021 と JIS X 0170:2025 が対応します。番号は覚える必要はありません。そういうものが存在するという点だけ押さえてください。
ここで押さえておきたいのが、規格が定めているのはプロセスであって、工程の呼び名ではないということです。プロセスは「何を達成する活動なのか」を規定します。それを自社の流れにどう当てはめて、どんな名前を付けるかは各組織に委ねられている。
具体的に言うと、規格には「必要なことを明らかにする活動が必要だ」という趣旨が書いてあります。それを要件定義と呼ぶのか、RDと呼ぶのか、そこは書いてありません。活動の中身は決めるが、名札は決めないという建て方です。
だから会社ごとに違って当たり前です。ばらついているのは誰かがサボった結果ではなく、規格の設計がそうなっている。
日本では、IPAが出している共通フレームも参照されます。これは日本の開発現場に向けて、工程の中身をより細かく書いた解説書のようなものです。国際規格では割愛されたソフトウェア固有のプロセスが解説されているため、ソフトウェア開発を重視する場面でいまも参照されています。
ただし土台にしているのは1世代前の規格です。紙の書籍は終売しているので、いま買うなら電子版になります。
よく並ぶ工程を、順番で覚える
名前は揺れますが、並び順はそれほど揺れません。上から下へ、だいたいこの順で進みます。
要件定義で「何を作るか」を決める。基本設計で画面に何が出るか、ボタンを押すと何が起きるかを決める。詳細設計でそれをどういう仕組みで実現するかを決める。実装でコードを書く。
そのあとテストが段階的に上がります。ここは名前だけ見ても違いが分からないので、確認する対象で並べます。単体テストは部品ひとつ、結合テストは部品同士のつなぎ目、システムテストはシステム全体、運用テストは業務として使えるかを見ます。範囲がだんだん広くなっていく形です。
最後に移行して運用に入ります。移行というのは、いま使っているものから新しいものへ切り替える作業のことです。
覚え方としては、設計は外側から内側へ下がっていき、テストは内側から外側へ上がっていくと捉えると迷いません。この対応関係にはV字モデルという呼び名があって、別記事で詳しく書きました。
略語は文脈で判断するしかない
工程の略語も現場でよく飛んでいます。先に言っておくと、これは覚える必要がありません。 理由はあとで書きます。
私がこれまで見かけたものを挙げると、要件定義がRD、基本設計がBD、詳細設計がDD、実装がPGやCD、単体テストがUTやPT、結合テストがIT、システムテストがST、運用テストがOTやUATあたりです。もとは英語の頭文字で、基本設計なら Basic Design、詳細設計なら Detailed Design が元になっています。
SPという略語も見ますが、これは要件定義ではなくSystem Planningで、その一段上流にあたるシステム企画の工程を指します。要件定義と同じものだと思って読むと、決める内容がずれます。
ただしこれは辞書ではありません。 同じ略語が別の工程を指す例を実際に見ています。いちばん危ないのがPTで、Program Testとして単体テストを指す場合と、Product Testとして総合テストを指す場合の両方が流通しています。テスト工程の両端なので、取り違えると確認する範囲がまるごとずれます。
ITも結合テストと読む会社と統合テストと読む会社があり、指す範囲がずれる。UATはユーザー受入テストの略なので運用テストと重なりますが、責任を持つ人が違う場合があります。
なので、略語は覚えるものではなく確認するものだと思っています。参加初日に「工程の定義はどこに書いてありますか」と聞く。無ければ、いま自分が理解している対応を書き出して関係者に見せ、違うところを指摘してもらう。これが最短でした。
紙が無い現場のほうが多いのが正直なところです。
実装が速くなると、上のあいまいさが表に出る
ここが最近いちばん変わった部分です。
Claude Codeのようなツールで実装を任せると、コードが出てくるまでの時間が短くなります。私が試したときは、画面1つ分の実装が30分ほどで動く状態になりました。速い。ただそのあと、作り直しています。
理由は単純で、要件定義の段階で決めていなかったことが実装に現れたからです。入力を間違えたときにどう振る舞うのか、権限のない人が開いたら何が見えるのか。以前は実装に数日かかっていたので、その間に気づいて相談できていた。30分になると、気づくタイミングも消えます。
つまり実装が速くなるほど、要件定義と設計の粗さがそのまま手戻りになる。工程の重心が上に移った感覚があります。要件定義の詰め方については、別で手順をまとめています。
仕様を先に固める進め方も選択肢です。
工程表を読むときに私が見る2箇所
最後に実務的な話をします。プロジェクトの工程表を渡されたとき、私は2箇所だけ先に見ます。
テストが何段階あるか。 3段階なのか4段階なのかで、品質にかける前提が読めます。単体とシステムしか無い工程表を見たときは、結合の部分を誰がいつ見るのかを必ず聞いています。
要件定義に割いてある日数の比率。 全体の1割しか無い場合、後半で必ず膨らみます。私は膨らんだ側にいたことがあるので、ここは反射的に見るようになりました。
工程の名前を全部覚える必要はありません。並び順と、自分の現場での呼び方の対応。この2つが手元にあれば会議で迷わなくなります。
