様々な駆動開発についてまとめてみた

はじめに

はじめまして、新入社員の大谷です。8月に現場配属され、普段の業務ではバックエンド開発を主に行っております。

配属されてから外部の勉強会に参加させてもらうことが何回かあり、その中でドメイン駆動設計について出会い、他にも振る舞い駆動開発やテスト駆動開発といったものが存在することを知りました。
そこで、他にどういったものがあるのか気になったので記事にしてみました。

はじめに
そもそも駆動開発とは？
主な駆動開発
その他の駆動開発
さいごに

そもそも駆動開発とは？

「駆動開発」とは英語でDriven Developmentと書き、何か特定の事象を中心に添えて開発を進めるというソフトウェア開発手法を指す言葉です。ドメインを中心に置くのであればドメイン駆動、テストを中心に置くのであればテスト駆動ということになります。
駆動開発には手法だった手順や用語などが決まっているものもありますが、「○○を使って開発する」ということを言い換えた程度のものもあります。
ここでは、手順などがある程度決まっているものを主に紹介したいと思います。

主な駆動開発

ドメイン駆動開発(設計)（DDD: Domain-Driven Design）

ドメイン駆動設計はソフトウェアの対象となるドメイン知識、つまり業務領域の知識を中心においてビジネス側の人間と開発者が協力して業務ロジックに忠実な設計・コードを目指すソフトウェア開発手法のことです。

ドメイン駆動設計は戦略的設計と呼ばれるシステム全体の構造に関する設計と、戦術的設計と呼ばれる実装パターンの設計という2つの設計に大きく分けられます。ここでは戦術的設計についてもう少し詳しくお話します。
戦略的設計については以下の記事で詳しく解説してありますので、ご参照ください。
tech.nri-net.com

ドメイン駆動設計の戦術的設計

ドメイン駆動設計の実装パターンである戦略的設計には以下のような概念があります。

値オブジェクト（ValueObject）：一意性を持たず、属性によって同一性が決まるオブジェクト。
エンティティ（Entity）：値によって一意に識別されるオブジェクト。
リポジトリ（Repository）：EntityをDBとのやり取りを行って永続化するためのもの。
ドメインサービス（Domain Service）：エンティティや値オブジェクトに属さないドメインロジック。
集約（Aggregate）：データの一貫性を保持する単位。一つ以上のエンティティを囲む境界線を定義する。

ドメイン駆動設計ではこういった実装パターンを使うことによって業務ロジックに忠実なコードを目指します。

テスト駆動開発（TDD: Test-Driven Development）

テスト駆動開発はテストをコードを書く前に書いて、そのテストに合格するようにコードを書いていく手法です。下記のワークフローに従って開発を行い、動くコードを維持しながら高品質なコードを目指していきます。

テスト駆動開発のワークフロー

テストリストを作成する
ひとつテストを書く
テストを成功させる
必要に応じてリファクタリングする
テストリストが空になるまで2.にもどって繰り返す

振る舞い駆動開発（BDD: Behavior-Driven Development）

振る舞い駆動は上記のテスト駆動開発を拡張した手法です。最大の特徴は開発者以外のステークホルダーも理解できる自然言語でシステムの仕様を記述することで、テスト駆動開発で対象としていたよりも上流からの工程が含まれる開発手法になっています。

BDDでの仕様の書き方

BDDではGherkinと呼ばれる以下の要素からなる形式で仕様を記述します。

Feature（機能）
Scenario（シナリオ）
Given（前提）
When（ユーザーのアクション）
Then（期待される結果）
And/But（Given-When-Thenの処理を複数つなげる時に使う）

BDDのワークフロー

ワークフローは以下のような順番で行います。

Discovery：振る舞いを定義する。ビジネス側と開発者側が協力してユーザーストーリーやシナリオを出します。
Formulation：シナリオをドキュメント化する。Given形式でシナリオを仕様として書き起こします。
Automation：仕様をコードで検証する。仕様をテストとして実行し、それが合格となるように実装していきます。この部分はTBBと同じです。

テスト駆動開発（TDD）との違い

上記にも書いたようにBDDはTDDの拡張ということもあり、TDDによく似ていますが、以下のような違いがあります。

	テスト駆動開発（TDD）	振る舞い駆動開発（BDD）
言語	技術的な言語	自然言語に近い言語
テストの焦点	どのようにテストするか	なにをテストするか
対象者	開発者	ビジネス関係者を含むステークホルダー
目的	コード品質の向上	ビジネス要件どおりの実装

モデル駆動開発（MDD: Model-Driven Development）

モデル駆動開発とはシステムの抽象的なモデルを作成し、そのモデルから自動的にコードを生成することで開発を行うというものです。具体的には下記のような抽象度の異なるモデルを使って段階的にビジネスモデルからコードへの変換を行っていきます。

モデル駆動開発の中で使うモデル

CIM（Computation Independent Model）：技術的な要素は取り扱わず、ビジネスプロセスやドメインの概念を表現するモデル
PIM（Platform Independent Model）：特定の実装技術には依存せず、システムの機能や構造を表現するモデル
PDM（Platform Description Model）：実装技術について記したモデル
PSM（Platform Specific Model）：実装技術を特定した上で詳細化するモデル

流れとしては、CIMでビジネス側の要求を書き込み、PIMで技術非依存のシステム仕様を書き込んで具体的な実装技術について書いたPDMとあわせてPSMを作り出します。そして最終的に出来上がったPSMを元にコードを自動生成して実装を行います。

ユーザー機能駆動開発（FDD: Feature-Driven Development）

ユーザー機能駆動開発とはユーザー目線で価値のある機能を小単位で開発し、短期間でリリースすることで顧客満足度を高める開発手法です。

ユーザー機能駆動開発のワークフロー

ユーザー機能駆動開発では5つのプロセスを踏んで開発を行います。

全体のモデルを作成する：プロジェクトメンバーで仕様や構成の問題点について話してシステム全体の理解を行います。
機能リストを作成する：1.で収集された理解を元に機能ごとにリストアップを行います。リストを作るときは2週間以内で開発できる小さな機能に分割します。
機能ごとに計画を立てる：ビジネスの優先度や機能の複雑さなどを考慮しながら担当者を割り当てます。
機能ごとに設計を行う：機能に関連するクラスの担当者と連携しながら機能ごとの詳細なシーケンス図を作成します。
機能ごとに実装を行う：機能のコーディング、テストを行います。

チケット駆動開発（TiDD: Ticket-Driven Development）

チケット駆動開発とは作業をタスクに分割し、BTS（Bug Tracking System）やタスク管理ツールでチケットに割り当てて管理を行う開発手法です。チケット駆動開発はなんと日本で2007年に発表された開発手法だそうです。

チケット駆動開発のワークフロー

要件をタスクに分割する
分割したタスクをチケットに割り当てる
イテレーション単位でタスクをまとめてイテレーション計画を作る
担当するチケットのタスクを実行する
変更をコミットしてチケットをクローズする

現代だとアジャイル開発手法で良く用いられている方式に思えますが、当時からするとバグ管理に使っていたシステムをそのまま開発タスクにも使うということが画期的だったのではなかと思います。

その他の駆動開発

ここまでで紹介したもの以外にもたくさんの駆動開発が存在しますが、すべて書き出すとキリがないので、比較的よく聞く駆動開発をあげてこの記事を終わろうと思います。

仕様駆動開発（SDD: Spec-Driven Development）：仕様駆動開発とは仕様を記述し、その仕様を軸に開発手法です。
AI駆動開発（AIDD: AI-Driven Development）：AI駆動開発とは主にLLMや生成系AIを使ってソフトウェア開発をする手法のことです。
データ駆動開発（Data-Driven Development）：データ駆動開発とはデータを中心に捉えたソフトウェア開発手法です。データを元に仮説を立て実験を行い、データ収集して検証するサイクルを繰り返すことで製品を継続的に改善するというものです。
コンポーネント駆動開発（CDD: Component Driven Development） コンポーネント駆動開発とは主にUI構築においてまず小さい部品を作り、それを組み合わせて画面を作るという手法です。

さいごに

今回は様々な駆動開発について調べて記事にしてみました。
筆者は初めて知ったのがドメイン駆動設計だったので、どの駆動開発もある程度、形のようなものが決まっているのかと思っていましたが、そうではなく名前だけあって抽象的なものもあるということが意外でした。
普段、何気なく開発業務の中で行っている設計手法も本記事の情報を調べる中で登場し、その恩恵を受けているということを再認識できました。より良い開発をするにはどのようにすれば良いか考えながら日々の業務に臨んでいきたいです。