1. icoxfog417
Changes in title
-実践的要件定義手法 UnitTestを使用したコンテキスト駆動開発
+さらばExcelフローチャート UnitTestを活用した設計手法
Changes in body
Source | HTML | Preview
@@ -1,66 +1,67 @@
-要件なるものを文書にする」
-「文書をコードにする
+コーディングする前には設計書という文書がなくてはならない
-要件定義にはいろいろな手法がありますが、「文書にする」というこの一点は変わりません。そして文書をコードにするという後続の作業も。
-結局のところこれが色んな不幸と苛立ちと俺の残業・・・といったダークマターを生み出しているのではないかと思うわけです。
+多くのシステム開発におけるこの暗黙の不文律、苦痛と感じたことはないでしょうか(私はあります)。特にオフショアに出す時なんかはちゃんと書かないと危ないということでしっかり描くわけですが、夜なべしてExcelフローチャートを書きながら「いいよもう俺が開発するよ」なんてため息つくこともよくあるわけです。
-今回紹介するのは最近のプロジェクトで試した方法で、端的に言えば「動く要件定義書」を作るアプローチです。
+今回紹介するのは最近のプロジェクトで試した方法で、端的に言えばJUnitなどのUnitTestフレームワークを使用し、「動く設計書」を作るアプローチです。
-1. ビジネスロジック(コンテキスト)を洗い出す
-2. UnitTestのコードで、コンテキストを記述・検証する
-3. コメントをきっちり書き、UnitTest Classの自動生成ドキュメントを仕様書として使用する
+## 実施ガイド
+要件定義からUnitTest?コーディングかよ、というのに違和感もあるかと思います。
+実際行うときも、UnitTestのコードだけでやっていたわけではありません。具体的な手順は以下の通りです。
-※UnitTestはJUnit/MSTest/RSpec、自動生成ドキュメントはJavaDoc/SandCastle/RDoc etcに適宜読み替えください(他言語でも同様)
+1. システム化の背景と業務要件の把握
+そもそもなぜシステム化したいのか、について背景となっている課題と、現在の業務の進め方を確認。
+2. システム構成の設計
+必要な画面とその関連(動線)、データベーステーブル、バッチなど大まかな全体フローを設計。
+3. 詳細な仕様確認
+複雑な業務ルール、理屈ではわかるけどコード上での書き方が微妙なところをUnitTestで記載
-これで開発パートナーの方への引き継ぎや顧客への説明もスムーズに行き、なかなかうまくできるという手ごたえを感じました。
-具体的には以下のようなメリットがありました
+1、2は普通だと思います。3は、通常外部設計書/内部設計書と呼ばれる成果物を作成するところですが、ここをUnitTestを使用したコード/APIドキュメントに置き換えました、その方が効率が良かったです、というのが本文書の主張です
-* コードで説明ができて、引継ぎが楽だった(内部設計書よりも)。たぶん引き継がれる方も楽だと思う。
-* 実装上の難点や、簡単そうに聞こえるけど難しい要件が早めに把握できた
-* コーディング=要件定義書作成になり、(Excelで文書を書く)無駄な工数が省けた
+## メリット
+実際行ってみて、以下のようなメリットを感じました。
-はっきり言えば、UnitTestのコードを書く以外は普通の要件定義と変わりません。ただ、この1点は非常に大きいです。
-要件定義の段階でも「検証可能なサイズ(UnitTestなサイズ)に要件を落とし込んで考える」ことが意外と効果を発揮しますし、コード上での検証は見落としを防止してくれます。
-加えて、統合開発環境の力生かすことができるのです。
+* 実装上の難点や簡単そうに聞こえるけど難しい点が早めに把握でき、クラス設計などに反映できた
+* コードで説明ができて、引継ぎが楽だった。引き継いだパートナーさんからも好評。
+* API仕様書(JavaDocなどで生成するドキュメント)が設計書になり、無駄な工数が省けた。また、ソースコード中にしっかりしたコメントが残るようになった。
+
+コーディングを行うことで統合開発環境の力生かすことができるのも大きいです。
例として、ちょっと具体的なコードを書いてみました(作ったのは人事系のシステムだったので、それを元に)。
```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などのバージョン管理ツールが入っていれば差分管理を行うことができます。これによりいつ、どんな要件の変更がありそれにより機能がどう変わったのか、を追跡できます(チケット管理システムと連携させればより強力になります)。
-
-そして、上記のコードですがプログラマーでないと理解できない・・・というようなものでもないと思います。
+まず、コーディング中に発見した不明点などTODOコメントどで残しておくことで確認漏れが防げます。
+また仕様変更などがあった際、Subversion/Gitなどのバージョン管理ツールが入っていれば変更内容を差分管理できます(チケット管理システムと連携させればより強力になります)。システム内のロジックがTestメソッドとして並び、一覧として管理できるのも大きいです。
+これらはよくある仕様変更一覧(Excel)、課題管理一覧(Excel)より優秀に働いてくれる場面も多いわけです。
-これくらいなら顧客とコードを共有できると思いますし(逆に言えば共有できるサイズに分割すべきだと思います)、それにより未定義やエラーになるケースも共有できます。
-ビジネスロジックの数はUnitTestの数として把握できますし、実行結果がオールグリーンであれば問題し、というのも非常にわかりやすいです。
-
-また、きちんとコメントを書いておけば仕様書として成立します(※副次的な効果として、今回の開発でコードにきちんとコメントを書く文化が醸成されました)。
-Javaなら日本語クラス/メソッドが使えるので以下くらいにはわかりやすくなります。日本語名での実装はちょっと・・・という場合は、日本語でガラだけのテストクラス/メソッドを作成し、内部では英語名のクラスに処理を委譲するという手もあります。
+お、APIドキュメントについてはJavaなら日本語クラス/メソッドが使えるので以下くらいにはわかりやすくなります。日本語名での実装はちょっと・・・という場合は、日本語でガラだけのテストクラス/メソッドを作成し、内部では英語名のクラスに処理を委譲するという手もあります。
![shain.JPG](https://qiita-image-store.s3.amazonaws.com/0/25990/22d8adc9-3460-0769-3a4f-9ef49639d65c.jpeg)
-要件定義でもコードを書き、顧客ともコードでコミュニケーションをとる。合意で形成されたコードが開発につながる
-そんなコンテキスト駆動開発、ぜひお試しください
+## 結論
+適材適所の媒体を使用するのが良い、ということです。
+
+設計が適切な媒体で行われていることは、メンテナンスのしやすさにもつながると思います。
+コードの修正だけでも大変なのに、Excelで書かれたジャングルみたいなフローチャートも修正しないといけない、となったらはっきり言って二度手間なわけです
-※コンテキスト駆動開発というのは勝手に名づけたもので、世に広まっているものではありません。ただ、名前がどうであれこうした手法が開発に有効だと思うわけであります。
+効率の良い開発、ひいては運用保守を行っていくためにも、コーディング=開発と限定せずその表現力を使える場所では使っていくことが肝要ではないか・・・と思います。