先週の学び

要件定義

先週masuda220さん(http://masuda220.jugem.jp/)にいろいろとお話しをお聞きした。

masuda220さんは早くからRDRAに注目していただきRDRAを活用して頂いている。
昨年の大阪での３回のセミナーにも来て頂き、仕事上でも人を紹介して頂いたり　といろいろお世話になっている方です。

１点は要件定義ツールの評価をお願いし、２点目はICONIXについて教えて頂き、その中でドメインドリブンについても伺いました。

■要件定義ツール（KANAME）の評価

使い方の簡単な説明とそれに続いて実際に活用するとしたらどのようなシーンがあるかをディスカッションさせて頂きました。

RDRAの考え方等は熟知しているので、様々なアドバイスをいただきとても参考になりました。

masuda220さんのところでは普段はEnterpriseArchitect（EA）を使ってRDRAを実践しているので、KANAMEを使うとしたらメモ的な使い方になり、そこからEAを使って設計までもっていくことになりそうです。

その他にもRDRAとICONIXをコミュニケーションツールとしてうまく活用している話など、実践的な話も伺えました。

■ICONIXについて

RDRAを活用している方は不思議とICONIXとつなげて活用している方が多く、どうしてかな〜　という疑問を持っていました。

そしてある方から「RDRAの後はどうするの」という素朴な疑問を投げかけられ「コンサルではこうしています」という答え方しかできなかったので、もう少し一般的な答え方はないものかと考え、ICONIXを実践されているmasuda220さんにお聞きすることにしました。

私はICONIXについてロバストネス図がある程度のことしかしらず、詳しいことはよく知らなかったので丁度いい機会でした。

masuda220さんは昨年スパークシステムズ社が主催したダグ・ローゼンバーグさんのセミナーも受けておられるので、ICONIXの思想を深く理解していました。その思想がRDRAの思想と似ているということで親和性を感じておられたようです。
masuda220さん曰わく「RDRAをやってる人がICONIXをRDRAとつなぐのはよくわかる」と仰ってました。

ICNIXではレビューを重視しており、そのレビューのためのコミュニケーションツールとしてロバストネス図やシーケンス図、ユースケースを位置づけていていることをお聞きし、一気に理解が進みました。

レビューを主にしコミュニケーションを大事にすることを念頭にICONIXの各ドキュメントの役割を考えるとその関係性がよくわかります。

また、Satoruさん(http://satohru.blogspot.com/2010/01/blog-post_5549.html)がRDRAとICONIXの対応関係を示してくれています。

masuda220さんはRDRAの「システム価値」、「システム外部環境」までをRDRAのダイアグラムで整理し、ユースケース以降はICONIXでモデリングし、Springを使って実装までつなげていく、というやりかたをされています。
アーキテクチャをSpring中心で規定し、その上でRDRA、ICONIX　そして実装へと高速に回しているそうです。

上流から実装までをつなげてアジャイルに回す実践をされています。

■ドインドリブン

masuda220さんはDDDの投稿を沢山されています。
そして実践に裏打ちされた設計思想を述べられています。
そのまま読むと「なんでこう考えるの？」というところも有りますが、話を聞いていてなるほど　という点がいくつもありました。

私の印象ではユーザ企業の情報システム室長（正確にはわかりませんが）のようなポジションでユーザ企業内でも仕事をされています。
そして短期開発を実現するためにユーザ企業内の要員（ユーザ企業の社員ではない）で開発を行っています。

私自身は企業内もしくは情報子会社内でソフトウェアを開発する方がリスクが低くく、いいシステムができると考えているので、masuda220さんのアプローチは非常に合理的に感じました。

そしてmasuda220さんのところの開発で特徴的なのはユーザとブリッジ役（ユーザ部門出身）の方がいて、その方とソフトウェアのエンジニアがビジネス上の概念でコミュニケーションできるところまで来ていることです。

そのためのDDDであり、そのためのRDRA、ICONIXなのだと感じました。

それは、会社のドメインモデルを共有し、そこをベースに経験の浅いエンジニアとのコミュニケーションツールとしてRDRAやICONIXを使っています。

ドメインモデルを中心におくことでこの会社にとって最適なシステムはどういうものか　ということが議論でき、その議論を通して経験の浅いエンジニアにシステムのあり方を学ばせています。
そこでは現場担当者の目線に近いブリッジ役の方とエンジニアがビジネス用語を使ってシステムを実現することを可能にしています。

実際には様々な問題を克服しながら実現していると思いますが、迷走することの多いユーザ企業でのシステム化をmasuda220さんの強力なリーダーシップで着実に前進させています。



３時間ほどのディスカッションでしたが様々な発見と気づきがありました。

この場を借りてmasuda220さんに感謝します。