「要件なるものを文書にする」
「文書をコードにする」

要件定義にはいろいろな手法がありますが、「文書にする」というこの一点は変わりません。そして文書をコードにするという後続の作業も。
結局のところこれが役立たずな設計書(・・・と残業)を生み出しているのではないかと思うわけです。

今回紹介するのは最近のプロジェクトで試した方法で、端的に言えば「動く要件定義書」を作るアプローチです。

1. ビジネスロジック(コンテキスト)を洗い出す
2. UnitTestのコードで、コンテキストを記述する
3. コメントをきっちり書き、UnitTest ClassのJavaDoc的ドキュメントを仕様書として使用する

※JavaDocはRDocやSandCastleでつくるmsdnドキュメントetcに読み替えてください。

これで開発パートナーの方への引き継ぎや顧客への説明もスムーズに行き、なかなかうまくできるという手ごたえを感じました。
具体的には以下のようなメリットがありました。

• コードで説明ができて、引継ぎが楽だった(内部設計書よりも)
• 実装上の難点や、簡単そうに聞こえるけど難しい要件が早めに把握できた
• コーディング＝要件定義書作成になり、(Excelで文書を書く)無駄な工数が省けた

例として、ちょっと具体的なコードを書いてみました(作ったのは人事系のシステムだったので、それを元に)。

/**
 * 転入してきた社員を登録します。<br/>
 * 社員番号は原則3始まりですが、関連会社からの転入の場合関連会社の社員番号を引き継ぎます。
 */
@Test
public void newEmployee() {
    //新入社員
    Employee newCommer = new Employee("社員　太郎");

    //社員番号は、3で始まる
    assertTrue(newCommer.No.startsWith("3"));

    //関連会社からの転入の場合、既にある社員番号をセットします。
    //TODO 関連会社の社員番号の体系は?DBの項目長などに影響あり。
    Employee transferred = new Employee("関連　太郎","11220011");

}

まず、テスト中に発見した不明点などをTODOコメントどで残しておくことで、要件の聞き漏れが防げます。
また要件が変わった際、Subversion/Gitなどのバージョン管理ツールが入っていれば差分管理を行うことができます。これによりいつ、どんな要件の変更がありそれにより機能がどう変わったのか、を追跡できます。

そして、上記のコードですがプログラマーでないと理解できない・・・というようなものでもないと思います。

これくらいなら顧客とコードを共有できると思いますし(逆に言えば共有できるサイズに分割すべきだと思います)、それにより未定義やエラーになるケースも共有できます。
ビジネスロジックの数はUnitTestの数として把握できますし、実行結果がグリーンであれば問題なし、というのも非常にわかりやすいです。

また、きちんとコメントを書いておけば仕様書として成立します。
Javaなら日本語クラス/メソッドが使えるので以下くらいにはわかりやすくなります。日本語名での実装はちょっと・・・という場合は、日本語でガラだけのテストクラス/メソッドを作成し、内部では英語名のクラスに処理を委譲するという手もあります。

要件定義でもコードを書き、顧客ともコードでコミュニケーションをとる。合意で形成されたコードが開発につながる。
そんなコンテキスト駆動開発、ぜひお試しください。

※コンテキスト駆動開発というのは勝手に名づけたもので、世に広まっているものではありません。ただ、名前がどうであれこうした手法が開発に有効だと思うわけであります。