要件定義セミナーに参加
と、梯子してバリューソースの神崎さんの開催する要件定義セミナーに参加です。神崎さんとは去年のJavaFestaで知り合うきっかけとなり、その後Enterprise Artchetectのセミナーでお会いしたり、やはりコミュニティや勉強会をきっかけに知り合いとなった方です。吉岡さんの話に戻ってしまいますが、このような繋がりも、今回のイベントを知れた事もすべてコミュニティがベースです。参加していなければ今回のセミナーにも参加できなかったと思うと、社内にひきこもっては駄目だなと思います。
要件定義の問題と解決方法
内容としては神崎氏の書いた「要件定義マニュアル」のダイジェスト的な紹介、それから実際に適用する場合に陥る問題や要件定義の具体的なスケジューリング方法などの２点でした。
要件定義マニュアルの内容は、ざっと目を通していることもあり、復習的な感じで良かったです。本では解らない部分、例えばどの辺りが特に重要だとか、どうしてそんなことをするのかなど、生で神崎氏の話を聞くと見えてくる部分も多いです。また吉岡さんの話になってしまいますが、「要件定義マニュアル」の内容は本を読んで理解すれば理解できます。ですけど、神崎さんの話す言葉のイントネーションや感情的なもの、これは言語化できない情報ですね。
内容としてはUMLをベースにした図を書いていくことで、文章ではなく論理的な構造で要件を定義していくという方法です。この方法をそのまま適用する必要は全くありませんが、考え方の１つとして読んでみると面白いと思います。特に要件定義に関する本は意外と少なく、あったとしても「で、具体的にどうすんのさ？」って本が多いのでオススメです。
ガントチャート禁止
今回、非常に興味深かったのが要件定義をアジャイル風にやるというスタイルでした。要件定義は要件を決めることがゴールなわけで、不確定であることは自明なわけです。ですから、工程管理をしてガントチャートを作って…とやる事自体が無理な話ということです。開発に関しては、ある程度はガントチャートで管理できますが、要件定義は工程分割できるわけでもなく、成果物を積み上げていくわけでもない（はず）なのです。
したがって、イテレーティブに要件を収束させ、ゴールを軌道修正しながら作っていくという考え方です。質問もしてみたのですが、やはり製造はアジャイルにすることにはお客さんも抵抗があるけど、要件定義だと比較的に納得して導入してくれるようです。そりゃそうですよね、まだ何を作りたいか解っていない状態ですから、一ヶ月を目標に1週間づつ詳細になっていくように進めましょうと提案しても通る可能性は高いです。
具体的なやり方としては、As-is（現状の分析／今はどうなの？）、分析（じゃあどうする？）、to-be（どのようにシステム化する？）という段階を踏んでいくようです。この考えはお客さんに提案するような立場であれば今後使えるメソッドなので、是非活用していきたいですね。
