「コーディングする前には設計書という文書がなくてはならない」
多くのシステム開発におけるこの暗黙の不文律、苦痛と感じたことはないでしょうか(私はあります)。特にオフショアに出す時なんかはちゃんと書かないと危ないということでしっかり描くわけですが、夜なべしてExcelフローチャートを書きながら「いいよもう俺が開発するよ」なんてため息つくこともよくあるわけです。
今回紹介するのは最近のプロジェクトで試した方法で、端的に言えばJUnitなどのUnitTestフレームワークを使用し、「動く設計書」を作るアプローチです。
実施ガイド
要件定義からUnitTest？コーディングかよ、というのに違和感もあるかと思います。
実際行うときも、UnitTestのコードだけでやっていたわけではありません。具体的な手順は以下の通りです。
- システム化の背景と業務要件の把握
そもそもなぜシステム化したいのか、について背景となっている課題と、現在の業務の進め方を確認。 - システム構成の設計
必要な画面とその関連(動線)、データベーステーブル、バッチなど大まかな全体フローを設計。 - 詳細な仕様確認
複雑な業務ルール、理屈ではわかるけどコード上での書き方が微妙なところをUnitTestで記載。
1、2は普通だと思います。3は、通常外部設計書/内部設計書と呼ばれる成果物を作成するところですが、ここをUnitTestを使用したコード/APIドキュメントに置き換えました、その方が効率が良かったです、というのが本文書の主張です。
メリット
実際行ってみて、以下のようなメリットを感じました。
- 実装上の難点や簡単そうに聞こえるけど難しい点が早めに把握でき、クラス設計などに反映できた
- コードで説明ができて、引継ぎが楽だった。引き継いだパートナーさんからも好評。
- API仕様書(JavaDocなどで生成するドキュメント)が設計書になり、無駄な工数が省けた。また、ソースコード中にしっかりしたコメントが残るようになった。
コーディングを行うことで統合開発環境の力を生かすことができるのも大きいです。
例として、ちょっと具体的なコードを書いてみました(作ったのは人事系のシステムだったので、それを元に)。
/**
* 転入してきた社員を登録します。<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などのバージョン管理ツールが入っていれば変更内容を差分管理できます(チケット管理システムと連携させればより強力になります)。システム内のロジックがTestメソッドとして並び、一覧として管理できるのも大きいです。
これらはよくある仕様変更一覧(Excel)、課題管理一覧(Excel)より優秀に働いてくれる場面も多いわけです。
なお、APIドキュメントについてはJavaなら日本語クラス/メソッドが使えるので以下くらいにはわかりやすくなります。日本語名での実装はちょっと・・・という場合は、日本語でガラだけのテストクラス/メソッドを作成し、内部では英語名のクラスに処理を委譲するという手もあります。
結論
適材適所の媒体を使用するのが良い、ということです。
設計が適切な媒体で行われていることは、メンテナンスのしやすさにもつながると思います。
コードの修正だけでも大変なのに、Excelで書かれたジャングルみたいなフローチャートも修正しないといけない、となったらはっきり言って二度手間なわけです。
効率の良い開発、ひいては運用保守を行っていくためにも、コーディング=開発と限定せずその表現力を使える場所では使っていくことが肝要ではないか・・・と思います。