(Photo by：Roland Tanglao)
- アジャイルな開発手法をおさらいしたい。
- 最近のドリブン開発（xDD）を知りたい。
ユニットテストの概念から発展したアジャイルなソフトウェア開発手法として、TDD（テスト駆動開発）がありますが、他にもXドリブン開発と名前の入った開発手法があります。
本記事では各Xドリブン開発の要点をまとめて簡単に説明します。
1. TDD – テスト駆動開発（Test-Driven Development）
TDD – テスト駆動開発とは、実装の前にインターフェイス設計を行い、テストコードに合わせた実装を行う開発手法です。テストファーストによるリファクタリングを前提として、ムダの無い実装を目指します。
TDD – テスト駆動開発の特長
- 特徴1. 最初に失敗するユニットテストから書き始める。
- 特徴2. 最少の実装から初め、テストパターンを追加する事で実装を進める。
- メリット1. 実装前にテスト設計を行うため、必要とされる機能以外の実装をしないで済む。
- メリット2. メジャーな開発手法のためテスティングフレームワークが充実している。
ビジネスロジック等の単体テストに対しては効率的に機能するが、ウェブアプリケーションのMVCモデル等の、複合的な要素が加わったテストに対しては向かない評価が多いです。モックが複雑化しインターフェイス設計が冗長になり易いです。
(Photo by：ScratchEd Team)
アーキテクチャの変更のよってモックアップ時に作られたテストコードをメンテナンス出来なくなり、書き直す必要が発生し、工数を考慮した結果テストコードが捨てられる場合があります。組織によってはTDDによるユニットテストを過剰評価し、以後の品質管理が疎かになるデメリットが一時期話題になりました。
アジャイルなソフトウェア開発を行う上で、変更を柔軟に受け入れる基礎となっている効率的なユニットテストを支える開発手法として使われ続けています。
TDD – テスト駆動開発のツール
TDD – テスト駆動開発のツールとして、
- xUnitフレームワーク、JUnit（http://junit.org/）
があります。
2. BDD – ビヘイビア駆動開発 – Behavior Driven Development
BDD – ビヘイビア駆動開発とは、振る舞い（Behavior）の検証に焦点を当てた開発手法です。メソッドの振る舞いが正しいかを検証する仕様（スペック）をテストコードとして記述します。スペックファーストで開発を進めるのがBDDです。
要求仕様に近いテストの記述が可能なため、受け入れテスト駆動開発- ATDD（Acceptance Test Driven Development）としても利用されます。
BDD – ビヘイビア駆動開発の特長
- 特徴1. テストケースを自然言語に近い記述で行う。
- 特徴2. 連続したストーリーのテストを行う。
- メリット1. 結合テスト・ユーザー寄り受け入れテストを記述できる。
- メリット2. 汎用性が高いため、状況に合わせて広く利用できる。
Given（前提条件）、When（操作・インプット）、Then（結果・アウトプット）の3つを記述したテストコードになります。一連の文脈の中で連続したテストが行われるため、可読性が高く、特定の状況下にある事を前提としたテストコードである事が理解し易いです。
ユニットテストとしてのBDDは、TDDと同じ粒度で行われる事が多いです。受け入れテストのBDDは、ストーリーを作るのに時間がかかるため、開発がある程度まで進み、仕様がある程度確定してから実施する事が多いです。
振る舞いの検証にメソッド実行後オブジェクトのポストコンディション（事後条件）を含める事で、オブジェクト内部の状態異常により副作用が発生する不具合へのテストが可能です。
BDD – ビヘイビア駆動開発のツール
BDD – ビヘイビア駆動開発のツールとして、
- RSpec（http://rspec.info/）
- SpecFlow（http://www.specflow.org/）
- Cucumber（https://cukes.info/）
があります。
3. FDD – ユーザー機能駆動開発 – Feature-Driven Development
FDD – ユーザー機能駆動開発とはモデル駆動開発に含まれる開発手法で、ユーザー機能を軸に細かくイテレーションを繰り返し、開発を進めます。TDDやBDDはテストコードを軸に開発を進めますが、FDDでは価値が高い機能の実装を軸に開発を進めます。
アジャイルマニフェスト提唱の早期から、短期間のプロジェクトライフサイクル（イテレーション）、定期ビルド（継続的インテグレーション）、ユーザー価値の追求を軸としたレポーティングを含んだプロジェクトマネジメント手法として注目を集めました。設計とコードのインスペクション（精査したレビュー）を行った上でビルド対象に含める品質管理を行います。
テスティングフレームワークが存在するものではなく、特定の開発言語に依存したものでもありません。
4. TiDD – チケット駆動開発 （Ticket-Driven Development）
TiDD – チケット駆動開発とは、チケット型BTS（バグ管理システム）またはタスク管理ツールを利用し、チケット単位で分割された機能を逐次開発して行く開発手法です。
- 特徴1. BTS/タスク管理ツール等を軸に開発を進める。
- 特徴2. 全ての作業をチケットに分割してから作業を開始する。
- メリット1. ワークフロー/プロセス/個人タスクが明瞭になり電子カンバンとして機能する。
- メリット2. タスクが文書化されるため、属人性が下がり改善案が出易くなる
Trac、RedMine、JIRA、PivotalTracker等のツールのどれか1つをチケット管理ツールとして利用します。チーム全員が分割されたチケットを共有し、全員が作業の全体を把握しながら逐次開発を進めるため、コミュニケーションが活発で協調性の高い開発チームが求められます。
(Photo by：ScratchEd Team）
コーディングに関する開発手法としてTDDやBDD等を別途検討し採用します。実作業量（チケット消化量）の集計によって開発スケジュールの精度向上を期待できますが、あくまでチケット単位の工数収集結果からの着地予測の算出になるため、開発スケジュールと着地点がずれている事を解決できるものではありません。
チケット駆動開発をワークフローと一体化させる事も多く、アプリケーションのデプロイ、継続的インテグレーション等のDevOpsを含めた総合的なプロジェクトマネジメント手法としても活用されています。
TiDD – チケット駆動開発のツール
TiDD – チケット駆動開発のツールとして、
- Trac（http://trac.edgewall.org/）
- RedMine（http://redmine.jp/）
- PivotalTracker（http://www.pivotaltracker.com/）
があります。
5. MDD – モデル駆動型開発（Model-Driven Development）
MDD – モデル駆動型開発とは、ソースコードの記述よりもビジネスドメインの問題解決に注力したソフトウェア設計手法の1つで、各社によって解釈と実現方法が異なる開発手法です。一昔前は非現実的であり実用には信頼性が欠けるとの評価が多くありました。
- 特徴1. モデルからのソースコードを自動生成。
- 特徴2. UML/DSL等でビジネスモデリングを行う。
- メリット1. モデルのシミュレーションによって品質担保が可能。
- メリット2. 問題はモデルで解決されソースコードに依存しない。
意図や解釈が各社・各プロジェクトによって異なるため、汎用的に扱うのが難しいのがモデル駆動型開発です。特定のルールやDSLに則って記述されたメタ情報からソースコードを自動生成しソフトウェアを開発するケースもモデル駆動型開発の一種になります。
ビジネスドメインの課題を、ソースコードから切り離された抽象レイヤーであるモデル内で解決します。モデルから具体的な解決方法が記述されたソースコードを自動生成する事でソフトウェアを提供します。
MDD – モデル駆動型開発のツール
MDD – モデル駆動型開発のツールとして、
- Eclipse Modeling Framework（https://www.eclipse.org/modeling/emf/）
- Rational Rose（http://www-03.ibm.com/software/products/ja/ratirosefamily）
6. Xドリブン開発(xDD)のまとめ
Xドリブン開発（xDD）と共通した名称のため、近しい技術を扱っているように見えますが、それぞれソフトウェアという共通点はあるものの、異なる問題領域を解決するためのアプローチです。
どれが正しくて優れているという性質ではありませんので、開発する規模・状況・性質に合わせた開発手法を選択してもらえればと思います。
おまけ1: DDD – 締め切り駆動開発（Deadline Driven Development）
締め切りに合わせて開発を行う、ある意味で最もスケジュールに対し柔軟で、必要最小限なソフトウェアを実現できるアジャイル的な開発手法です。プロジェクトマネジメントの重要な課題であるスコープクリープに対し、万人が理解できる（ただし納得はしない）シンプルな答えを示します。
当初約束された締め切りを守る意思が無い事を前提する開発手法のため、クライアントに締め切りを守るために仕様を削減するか、締め切りを伸ばす事よって仕様を満たすかの意思決定を委ねるのが特徴です。
良く使われる手法として、クライアントに対し仕様と締め切りの妥当性を質問し、一考を促す事によってスケジュールと仕様を変更させる方法があります。
質問例1：「本当にその締め切りは正しいのですか？」
質問例2：「一ヶ月遅れる事でどのような影響が出るでしょうか？」
質問例3：「この機能がなければオンスケです。」
ただしクライアントが締め切りを守る意思決定にした場合、開発側は再度交渉（泣き落とし・土下座等）を行い意思変更してもらうか、自己犠牲によるプロジェクト完遂（デスマーチ）が求められます。
おまけ２: DDD – 文書駆動ドキュメンテーション（Document Driven Documentation）
DDD – 文書駆動ドキュメンテーションとは、waterfallカンファレンス2006（エイプリルフールのジョーク）で登場した開発手法です。
ドキュメントが正しいかを自動検証するドキュメントをWordUnit testsによって文書化します。
参照URL: http://www.waterfall2006.com/beck.html
本ブログは、Git / Subversionのクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
エンタープライズ向け Git / Subversion 導入や DevOps による開発の効率化を検討している法人様必見！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
No Comments