1. icoxfog417

    No comment

    icoxfog417
Changes in body
Source | HTML | Preview
@@ -1,66 +1,66 @@
「要件なるものを文書にする」
「文書をコードにする」
要件定義にはいろいろな手法がありますが、「文書にする」というこの一点は変わりません。そして文書をコードにするという後続の作業も。
結局のところこれが色んな不幸と苛立ちと俺の残業・・・といったダークマターを生み出しているのではないかと思うわけです。
今回紹介するのは最近のプロジェクトで試した方法で、端的に言えば「動く要件定義書」を作るアプローチです。
1. ビジネスロジック(コンテキスト)を洗い出す
2. UnitTestのコードで、コンテキストを記述・検証する
3. コメントをきっちり書き、UnitTest Classの自動生成ドキュメントを仕様書として使用する
※UnitTestはJUnit/MSTest/RSpec、自動生成ドキュメントはJavaDoc/SandCastle/RDoc etcに適宜読み替えください(他言語でも同様)。
これで開発パートナーの方への引き継ぎや顧客への説明もスムーズに行き、なかなかうまくできるという手ごたえを感じました。
具体的には以下のようなメリットがありました。
-* コードで説明ができて、引継ぎが楽だった(内部設計書よりも)
+* コードで説明ができて、引継ぎが楽だった(内部設計書よりも)。たぶん引き継がれる方も楽だと思う。
* 実装上の難点や、簡単そうに聞こえるけど難しい要件が早めに把握できた
* コーディング=要件定義書作成になり、(Excelで文書を書く)無駄な工数が省けた
はっきり言えば、UnitTestのコードを書く以外は普通の要件定義と変わりません。ただ、この1点は非常に大きいです。
-要件定義の段階でも「検証可能なサイズ(UnitTestなサイズ)に要件を落とし込んで考える」ことが外と効果を発揮しますし、コード上での検証は見落としを防止してくれます。
+要件定義の段階でも「検証可能なサイズ(UnitTestなサイズ)に要件を落とし込んで考える」ことが外と効果を発揮しますし、コード上での検証は見落としを防止してくれます。
加えて、統合開発環境の力も生かすことができるのです。
例として、ちょっと具体的なコードを書いてみました(作ったのは人事系のシステムだったので、それを元に)。
```java
/**
* 転入してきた社員を登録します。<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なら日本語クラス/メソッドが使えるので以下くらいにはわかりやすくなります。日本語名での実装はちょっと・・・という場合は、日本語でガラだけのテストクラス/メソッドを作成し、内部では英語名のクラスに処理を委譲するという手もあります。
![shain.JPG](https://qiita-image-store.s3.amazonaws.com/0/25990/22d8adc9-3460-0769-3a4f-9ef49639d65c.jpeg)
要件定義でもコードを書き、顧客ともコードでコミュニケーションをとる。合意で形成されたコードが開発につながる。
そんなコンテキスト駆動開発、ぜひお試しください。
※コンテキスト駆動開発というのは勝手に名づけたもので、世に広まっているものではありません。ただ、名前がどうであれこうした手法が開発に有効だと思うわけであります。