中嶋悟
名前：中嶋 悟（なかじま さとる） ニックネーム：サトルン 年齢：28歳 性別：男性 職業：会社員（IT系メーカー・マーケティング部門） 通勤場所：東京都千代田区・本社オフィス 通勤時間：片道約45分（電車＋徒歩） 居住地：東京都杉並区・阿佐ヶ谷の1LDKマンション 出身地：神奈川県横浜市 身長：175cm 血液型：A型 誕生日：1997年5月12日 趣味：比較記事を書くこと、カメラ散歩、ガジェット収集、カフェ巡り、映画鑑賞（特に洋画）、料理（最近はスパイスカレー作りにハマり中） 性格：分析好き・好奇心旺盛・マイペース・几帳面だけど時々おおざっぱ・物事をとことん調べたくなるタイプ 1日（平日）のタイムスケジュール 6:30 起床。まずはコーヒーを淹れながらニュースとSNSチェック 7:00 朝食（自作のオートミールorトースト）、ブログの下書きや記事ネタ整理 8:00 出勤準備 8:30 電車で通勤（この間にポッドキャストやオーディオブックでインプット） 9:15 出社。午前は資料作成やメール返信 12:00 ランチはオフィス近くの定食屋かカフェ 13:00 午後は会議やマーケティング企画立案、データ分析 18:00 退社 19:00 帰宅途中にスーパー寄って買い物 19:30 夕食＆YouTubeやNetflixでリラックスタイム 21:00 ブログ執筆や写真編集、次の記事の構成作成 23:00 読書（比較記事のネタ探しも兼ねる） 23:45 就寝準備 24:00 就寝
はじめに：BDDとCDDの基本的な意味と目的
BDDは Behavior-Driven Development の略で、ソフトウェアが「どのように振る舞うべきか」を具体的な状況文と例で表す開発手法です。開発者だけでなくテスターやビジネスの人も同じ用語で話せるよう、共通の言語を作ることを目指します。挙動を Given/When/Then の形式で分解し、自然言語に近い表現で仕様を記述します。これにより、要件の不明確さが減り、テストケースと仕様書が同じ生きた資料になります。実運用では、仕様が常に最新の状態に保たれ、ドキュメントの自動生成と更新が容易になる点が魅力です。
一方、CDDは Customer-Driven Development の略として使われ、ここでは「顧客の課題解決を中心に据える開発」を意味します。顧客のニーズを最優先し、機能の優先度を決め、顧客の成功指標を組織の判断基準に組み込みます。BDDが内部の挙動を言語化するのに対し、CDDは市場や顧客の価値を最終的な成果として捉える考え方です。
この二つは同じ目的を持つ場面もありますが、焦点が異なるため使い分けが重要です。共通言語の重要性と 顧客価値の最大化の二点を押さえましょう。
実務での焦点の違いと使い方
BDDの実務では、ビジネス側と開発側の間の会話を一本化することが最初の課題です。仕様を具体的な例で共有することで、誤解を減らせます。Gherkin風の Given/When/Then は、誰が読んでも意味が通る「共通言語」を作る道具です。テスト自動化との相性も良く、テストと仕様の同義性を保つことで、リファクタリング時にも安全性が高まります。CDDの視点では、顧客の声を取り入れるループを設計に組み込みます。顧客インタビュー、プロトタイプ、A/Bテストなどを回して、阻害要因と成功指標を絞り込みます。部品主導のCDDなら、再利用可能な部品設計を先に固め、変更の波及を最小化します。
- 仕様の共有を最優先にする
- 多様なステークホルダーと対話する
- 顧客価値を指標化して判断材料にする
- 部品設計を先行して柔軟性を高める
こうした違いを理解すると、プロジェクトの初期設計が変わってきます。目的に応じた手法選択を心がけることが大切です。
比較表と選び方のガイド
下の表は、特徴を一目で比較し、どちらを選ぶべきかの目安を示しています。
この表を見れば、どちらを優先するべきかのヒントがつかめます。状況に応じて両方を併用することも可能で、実務では混在させる場面が多いです。表の外にも、環境や組織文化によって適切な組み合わせを探すことが重要です。
最後に、継続的な学習と小さな実験を繰り返すことが、実践での成功につながります。
放課後のカフェで友だちとBDDとCDDの話をしていたとき、僕はまず“挙動をどう説明するか”が大事だと強調した。友達は顧客の声をどう拾うかに興味を持ち、私は部品の再利用性が現実の設計を軽くする点を例に出した。結局、大事なのは互いの言葉をすり合わせて、何を作るのか、どう動くのかを同じ言葉で語ることだと結論づけた。もし学校の課題でも、BDDのように“こう動くべき理由”を具体的な場面で示せば、先生もチームも納得しやすい。
ITの人気記事
