RDRA リレーションシップ駆動分析から、いよいよ実装へ

求人と採用支援システムの開発案件で、3週間ほどかけて、基本的な要件を定義してきた。

基本の手法は、RDRA ( リレーションシップ駆動分析 )。
モデリングツールとして、Enterprise Architect 、コミュニケーションツールとして、オンラインは、37 signals のベースキャンプ、オフラインは、もちろん、ホワイトボード。

簡単な振り返りと、今後の進め方を、ここで立ち止まって、整理しておこう。

(1) RDRA:システム価値を明らかにする


コンテキストモデルで、アクタと外部システムを洗い出すところからスタート。
要求モデルは、ちょっと、つっこみが足りない。

総論というか、一般的な「ニーズ」で、このシステムのこだわりポイントとか、キモになるポイントの具体的な検討がもっと必要。

もっとも、「検索の軸」それと「選考業務支援の軸」について、それぞれの選択肢の中から、こだわりポイントがはっきり選べたので、方向感はでてきた。

また、サイトの運用についても、初期の段階の方針も決まったので、システム要件としては、だいぶ明確になった。

概念モデルも、この段階では、まあ、いい感じで、描けたと思う。

まあ、求人・採用ドメインで、いろいろな案件を、5年間も手を変え、品を変えやってきているので、この程度のことは、さくっとできないとまずい。

(2) RDRA:システムの外部環境の確認する


基本的な業務の流れは、比較的、単純だったので、この段階のモデリングは、さらっと、流した感じ。

ただし、「選考プロセス」が、かなりの問題。
大きな手順は、応募>書類審査>面接、なんだけど、ケースバイケースで、業務のやり方は、かなりバリエーションがでてくる。

ここは、「プロトコルモデル」と「イベントモデル」で、分析・モデリングすることで、なんとか、道筋が見えてきた。

「求職者」と「採用担当者」という、「人」と「人」との間の連絡プロトコルという視点で、モデリングをはじめて、ようやく突破口を見つけることができた。

<反省点>
この時点で、画面とか、サービスクラスやシーケンス図という、実装レベルに入りこみすぎて、2日程度、時間を浪費した感じ。

やはり、「関心事」の分離は、モデリングのやり方の鉄則。

RDRA や、ICONIX という方法論の良いところは、「このステップでは、この関心事に注力する」「この関心事は、先々、ここでやればよい」という、具体的なガイドラインがあること。

しかも、RDRA も ICONIX も、形式的ではなく、「必要なことを、必要な時、必要なだけ」やればよい、という、軽量化され、ひきしまった手法なので、実践的。 コストパフォーマンスが良い手法。

(3) RDRA:システム境界


先ほどのプロトコルモデルなども参考にしながら、全体のユースケース、キモになりそうな画面などの洗い出しを、今日の午前中で、いちおう達成した。

概念モデルは、初期に洗い出したもので、この段階までは、ほぼそのままでやれた。


A4の1枚に収めた、ユースケースモデルの全体図(パッケージ図)をみると、「選考業務の支援」だけが、突出して、ユースケースが多いのが一目了然。

この部分の概念クラスモデルは、かなり、検討の余地がある。

いずれにしても、今後の開発の主要課題のひとつが、この「選考業務の支援機能」のモデリング、設計・実装にあることは明確。

ユースケースモデルでは、仕事を探すためのユースケースパッケージは、現時点では、シンプル。これは、「軸になる検索・ナビゲーション」だけに、絞ってあるから。

プロジェクト全体では「検索・ナビゲーション」については、いろいろ、要望があとからでてくることを想定している。

この、「検索・ナビゲーション」の「後から要望」に、どう対応していくかも、プロジェクトのまわし方としては、大きなポイントだと思っている。

技術課題


携帯サイトおよびそのSEO対策に関する、要求と実装技術が、技術面では、大きな課題。
キャリアや端末ごとの端末特性の違い、セッション管理や文字コードなど、PCブラウザとは、ことなる世界。

ここは、テスト環境やテスト方法の問題もあり、経験者にサポートしてもらえる体制にはしているが、見えていないことが多く、かなりのリスクポイントだと思っている。

チームビルディング


携帯サイト固有の問題以外は、基本的なアーキテクチャや、モデリングの考え方は、ある程度、実績があるもの、その延長上のものを使う。

Spring 2.5 系から、 3.0 系に移行するところ、特に、 JSR-303 対応の アノテーション方式の Bean Validation と、Spring 3 MVC を使った、REST スタイルの Web MVC の実装は、このプロジェクトで、初めて、実戦配備する。

この点は、いままでも、いろいろ相談にのってもらっていた、Spring のエキスパートを確保できたので、まあ、リスクは小さいと思っている。

一番のリストは、開発チームが、今回はじめて、召集した、寄せ集めチームである点。

こちらは、今まで積み重ねてきた、手法や方式の延長上で、やっているけど、今回、初めて参加するメンバーたちに、その内容をキャッチアップしてもらうのが、目先では、かなり重要なリスク要因だと思っている。

キャッチアップにてこずるようだと、スケジュール面と、たぶん、品質面、それも、「変更容易性」に、だいぶインパクトがありそう。

リスクとの戦い方の方針


RDRA で、要件をある程度、固めたことで、ようやく明らかになった、上記の4つのリスク課題について、基本的な方針。

選考業務のモデリング、設計・実装


RDRA レベルの要件定義がいちおうできた。
ここから、先は、ICONIX の手法で、詳細を詰めていけば、なんとかなりそう。
担当者が私になるのが、リスクといえばリスク。(いろいろ兼任しちゃっていて、ここに集中できなそうだから)

RDRA の成果で、ユースケースモデルは、だいたい固まった。
それをさらに詳細化した、画面の紙芝居(画面・帳票モデル)と、要求事項を情報源にして、初期のドメインモデルと、ロバストネス分析から入る。

シーケンス図に進めためには、ドメインモデルやサービス層のクラスの設計パターンを、もうちょっと、詰める必要がある。

ここは、マーチン・ファウラーの Event Sourcing パターンと、エヴァンスの DDD ( Domain-Driven Desing ) のパターンを参考にして、アーキテクチャを固める必要がある。

とくに、「イベントオブジェクトの生成」「イベントのハンドリングサービス」「イベントに付随するデータの扱い(イベントデータ)」あたりの設計が、キモになりそう。

仕事の検索・ナビゲーション


ここは、要求事項をひっぱりだしながら、個別に、対応していくしかないと思っている。

手法としては、基本的には、データモデリングに、振り切ってしまおうかと思っている。
検索やナビゲーションの要求の実現手段としては、結局、

・検索キーの特定
・検索の高速化手法(アプリケーションレベルでのインデックスの設計・実装)
・多対多関係の解決(交差エンティティの設計・実装)

という、データベース系の、設計・実装が中心になるから。

ドメインモデルの観点では、「 Repository インタフェースの設計 」が関連するくらい。

ドメインモデルの実装オブジェクトのメモリー上での操作よりも、データアクセスレベルの SQL での解決が基本になると思っている。

ここは、いろいろノウハウもあるので、要求がいろいろでてきても、対処はできそう。
(開発パワーの余力が問題)

携帯サイト固有の技術課題


これは、基本的には、課題は、列挙できている。
というか、携帯サイト用のフレームワーク mobylet の仕様を理解して、使いこなすことが、唯一の解決策、とみている。(個別の調査・開発していては、まにあわないので、フレームワークのサポート範囲で、最大限の効果を狙う)

mobylet の機能リストの中ら、要求の重要度と、技術的な難易度(自分たちの不安の度合い)を、にらみながら、やばいネタ順に、やっていくしかないと思っている。

問題は、ここの担当メンバー。 かなり、レベルの高いメンバーをアサインすべきだが、ここにいつから、どの程度、集中できるかが、現時点では、明確でないのが、いちばんの不安。

逆にいえば、携帯の領域以外の、他の技術方式のスキルを、他のメンバーに、いかに、はやくスキルトランスファーできるかという、次の課題と密接に関連している。

スキルトランスファーとチームビルディング


現在、ドメインモデルと、データモデル、データアクセス(O-Rマッピング)という基本部分のスキルトランスファーを進めているところ。

モデリングのパターンや考え方と、Spring / MyBatis / JUnit DBUnit の実装技術と、両面から、実際にやってもらっている最中。

経験は豊富だし、発想も柔らかいメンバーなので、キャッチアップは、まずまず順調。

問題は、Spring MVC と、Spring Web Flow という、UI レベルの技術方式のトランスファーがこれからの点。

ここらへんは、全体モデルの一部をうまく取りだして、シンプルな構造と仕様にした、習得重視にミニプロジェクトを、8月の2週間くらいで、やれば、なんとか、なるんではないかと推測している。

そこがうまくいけば、先ほどの、携帯サイト固有技術の課題に、アーキテクトを振り向けられる。

うまくいかない、雨の日ケースの想定と対応


ある程度の経験と勘で、リストを織り込んだ上で、上記の戦い方で、なんとかなるかと思っている。

ただ、いろいろ、雨の日コースも想定しておこうとは思っている。

いざという時のためには、やはり、やばそうなところを、最初に集中して叩き潰したほうが良いとは思う。
目先、まわりから、目に見える成果が少ないけど、システム開発の勘所みたいな箇所が、確立したほうが、結局は、プロジェクト全体が安定するから。

なかなか成果が見えないことに対する、説明責任、関係者に信頼してもらえるようにするもの、私の大きな責任になりそう。

また、兼任の仕事が増えた。 一人がいろいろ兼任で担当する、という計画自体、かなり問題なんだけど、この程度のやり方でやらないと、プロジェクトはまわりませんからね。

業務のモデリング 【プロトコルモデリング】

採用支援システムを、RDRA(リレーションシップ駆動要件分析) のやり方で、実践中。

RDRA の基本のやり方


1.システムの価値を関係者で共有する
2.システムの外部環境(利用者の使い方や関連システムとの通信要求)を把握する
3.システム境界(画面、API,メールやファイル転送などの通信)インタフェース定義
4.システム(ドメインモデル、データモデル、機能モデルなど)

の4ステップ。

ウォータフォール(後戻りしない)式ではなく、先に進みながら、前のステップとの整合性を検証し、必要であれば、前のステップに立ち戻って、モデルの改善、を継続的に行う。

私たちの場合は、システム規模が小さく、関係者も少ないので、このまま設計・実装まで、ICONIX プロセスを使ってなだれ込む。

システム価値を明らかにする最初の段階で、主要な概念を洗い出した、概念モデルを作って、それを、そのままドメインクラスの実装まで一気に持ち込む。

実際、分析の初期の段階から、概念モデルを元に、ドメインクラス、テーブル、O-R マッピングを実装を、並行してはじめている。

ドメインクラスの設計の議論と、システムの主要概念の議論をいっしょにやっている。

いちばん最初にコードにするのは、「ドメイン層のクラス群」。 ドメイン層のクラスが、全体の実装を駆動するので、「ドメイン駆動設計」のスタイルを、 RDRA + ICONIX のやり方を参考にやっている。

システムの価値


そのシステムが、誰にとって、どんな価値を持つかを、みんなで共有するために、絵を描きながら、話をする。

主要な絵は、

・コンテキスト図
・要求モデル
・主要な概念モデル(これを、ここでやるのは、自己流。本来の RDRA ではない)

採用支援システムの場合、募集責任者、採用責任者、そして求職者がいて、「求人案件」が主要な概念。
この分野ばかり、5年以上やってきているので、この段階までは、わりとすんなり進む。

ただし、「このサイトの独自性」という意味づけ、価値観の共有が、まだ、あやしい状態。
来週からさ来週にかけて、ここらへんの共有度をたかめていきたい。

コンテキスト図や主要概念モデルだけだと、総論というか、議論に具体性が欠けるきらいがある。
要求モデルになると、今度は、枝葉の議論がはじまりがち。

「システム価値」の初期のモデリングは、ある程度のところで、切り上げて、次に進みながら、また、システム価値に立ち戻る。 いま、ちょうど、「初期の価値モデリング」から「次に進めてみる」あたりの段階。

システムの外部環境


次は、システムの外部環境のモデリング。

業務モデル(アクターごとにレーン分けしたアクティビティ図)とか、利用シナリオ(使うシーンを文章で書いてみる)という技法が中心。

この段階で、概念モデルは、かなり、具体的なドメインモデルの設計に近づいてくる。

やりはじめてみたが、どうも、うまくいかない。

「採用プロセス」といういい方は、あるけど、実は、「プロセス」と呼べるほど、構造化できないことが多い。
求職者と採用責任者という「人と人」とのやりとりとか、「人の感覚的な判断」とかが業務の根底にある。

業務モデル(アクティビ図)のように、時系列に、淡々と業務が進むわけではない。

面接の日程調整、面接日になってのドタキャン、他の候補者との比較のための保留状態...

いわゆる業務フローと呼べるようなステップ構造ではない。

で、トライアルしたのが、「イベント」モデルと、「プロトコル」モデルという、「状態遷移(ステートマシン)図」の技法。

神崎さんの RDRA では、「業務モデル」ではなく、次の「システム境界」を明らかにする技法として、登場する。
しかも、外部システムとのシステム間インタフェースの把握が主目的のモデル。

まあ、ここも、私の自己流で、「役に立つ」こと重視で、「採用業務」のモデリング技法として、「イベント」モデルと「プロトコル」モデルを使ってみた。

これがなかなかいい感じ。

考えてみれば、採用プロセスは、「求職者」と「採用者」の間のメッセージ交換でなりたっているので、「イベント」と「プロトコル」のモデリングが、ぴったりはまった感じ。

プロトコルモデル(ステートマシン図)で、まず、主要な「状態」、採用側が、関心のある「状態」を洗い出しながら、その状態間の遷移をイベントして、洗い出す、というステップではじめた。

最初は、状態とかサブ状態がかなり入り組んだモデルになりはじめた。
直感的におかしい。(業務では、そんなに細かい状態に興味はないから)

で、見直してみると、多くのサブ状態は、単純に「イベント」の発生として、モデル化したほうが、実際の業務に近いということがわかった。

しかも、そうやってモデリングしてみると、「イベント」が、見事に、「画面からのアクション」または「メールの送信/受信」のモデルになっていった。

これは、大きな収穫。業務を把握した手ごたえ。
いろいろモデリングのブレークスルーの瞬間は、稀だし、貴重なんですよねえ。

このモデルベースで、初期バージョンを開発して、実際に使ってもらいながら、「状態」や「イベント」の追加や変更を、安定してやり方でできそうな感じがしてきた。

基本の構造モデルが明確になると、ここを土台にして、ソフトウェアを繰り返し、発展、育成させていける予感。

実装レベルでも、前の記事に書いた「イベントソーシング」スタイルを、実装する技術パターン(アーキテクチャ)が、見えつつある。

なんか、いい感じになってきた。

モデリングツールの威力


私は、どちらかというと、最初のラフスケッチは、手書き(裏紙、ホワイトボード)派なんだけど、このイベント/プロトコルのモデリングでは、モデリングツールの威力を思い知らされた。

使っているもモデリングツールは、 スパークスシステムズジャパンのEnterprise Architect 。

もう3年以上つかっているけど、実は、ステートマシン図は、昔、手触りを確かめた程度しか、触っていなかった。
制御系のモデリング用かな、という感じで、それ以来、ぜんぜん使っていなかった。

今回、使ってみて、びっくり。

まず、「ステートマシン図」「状態遷移図」「イベントモデル」の三つのビューを、一つのモデルから、簡単に作れることに驚いた。

ステートマシン図と状態遷移図は、片方の変更が、双方向で自動的に反映される。
最初は、逆に、予想外の変更が起きて、ちょっととまどった。 状態を、ドラッグアンドドロップで、簡単にサブ状態にできるのは、便利すぎるというか、誤操作で、サブ状態にしちゃって、戻すコマンドを見つけるのに、ちょっと手間取った。

むしろ、状態の順番を並び変えるのを、ドラッグアンドドロップでやってもらえたほうがうれしい。
あと、S1 , S2 などのラベリングも、自動のリナンバリングとか、別名機能で表示できたりすると、うれしいかな。

という感じで、道具に慣れるのに、1,2時間かかった後は、ほんと、びっくりするくらい、状態遷移とイベントのモデリングが簡単にできちゃった。

初期のモデリングで、思いつくままに、状態も、イベントもたくさん作っちゃって、ひどい状態。

その状態の整理は、手書きでは、たぶんできなかったと思う。

ステートマシン図、状態遷移図、イベントの関連図、そして、プロジェクトブラウザ の4つのビューをいったりきたりしながら、モデルが洗練されていく様子は、われながら、ちょっと感動的だった。

それぞれが別のビューではなく、根底の一元管理された「モデル」への操作なので、たとえば、イベントの名前変更とか、削除や追加が、他のビューにも、素直に反映される。

ステートマシン図で、いい感じになってきたら、状態遷移図で、対応関係を論理的に検証してみる。

イベントの関連図で、それぞれのイベントを、

・採用担当者と求職者の間で発生するメッセージ交換イベント
・採用担当者のアクションとして発生するイベント
・期限切れとか、時間によって発生する「タイマーイベント」

として整理することで、業務の流れの中で発生するイベントの抜け漏れや重複を発見しやすくなる。

モデルの要素の一覧も簡単に作れるし、プロジェクトブラウザで、階層構造として把握できる。

どのダイヤグラムからも参照されていない、ゴミになっているモデル要素も、簡単にリストアップできる機能も付いている。

候補の洗い出しから、一連の整理のプロセスは、ツールなしには、まともな仕事ができなかったと思う。

ツールの威力に脱帽です。

リレーションシップ駆動要件分析(RDRA)の実践

採用支援の新サイトの構築プロジェクトが始まった。

* 仕事を探して応募するためのジョブサイト
* 求人情報を登録するアプリ
* 応募者と採用側の連絡アプリ
* 採用側の応募者管理アプリ
* サイト運営のための機能

こんな感じで、5つのコンテキストが、関連しあったシステム。

もしかしたら、採用企業側の採用関連システムとの連係も必要になるかもしれない。

コンテキストモデル


RDRA の基本ステップ。最初は、「システム価値」を明確にすること。

その中でも、第一歩は、コンテキスト図を描いて、「関連する人」「関連する外部システム」を洗い出して、関係者で共通理解にすること。

募集と採用は、密接に関係しているし、小規模な企業の採用であれば、募集情報をサイトに掲載する人と、それに対する応募に対応して、選考をする人は、同じ人(部門)。

ただ、この二つの業務は本質的に、別の業務。ここらへんの登場人物分けが、最初の検討テーマ。

あと「サイト運営」を、初期のコンテキストモデルでは、ひと固まりに「サイト運営者」にしちゃったけど、ここはかなり怪しい。

まあ、業務モデルくらいまで、落としながら、コンテキストモデルの見直し、特に登場人物の見直しを繰り返そう。

「リレーションシップ駆動」なので、コンテキスト図で把握した「登場人物」は、「要求モデル」のアクタ、「業務モデル」(アクティビティ図)のレーン、ユースケースモデルのアクタに、それぞれ、直接対応させるので、後続のモデリングをしながら、なんども、登場人物のとらえ方を改定することになる。

実践では、業務モデルのレーンと、コンテキストモデルのアクタが、ずれを発見。
どうやって整合させるか、今、検討中。

5つのサブの問題領域を、一つのコンテキストモデルでとりあえずは進めてみる。

要求モデル


コンテキストモデルと、アクタとシステム、外部システムとシステムとの間に引いた関連線をさらにブレークダウンしてみる。

線を引く、つまり、関連がある、という認識合わせは、コンテキストモデルのほうでやる。
それぞれの関連の意味(価値)を、具体的に考えてみるのが、要求モデル図。

ここの議論、整理の仕方は、たぶん、RDRAというか、上流工程のキモ。
教科書的な方法論を語っても、実践では、なかなかうまくいかなかった。
私流だけど、「大まかなユースケース」「重要なユースケース」という視点で、「中核機能の列挙」というような視点で、とりあえず進めている。

あと、でてきたニーズや要望は、とりあえずメモしておくべき。
ただし、これを、要求モデルに入れると、収拾がつかなくなるので、

* 中核な関心事(価値)の入れ物 (UMLの要求モデル図)
* それ以外の関心ごとの入れ物 (要望の箇条書きメモをノート形式で)

に使い分けて、その間を行ったりきたりしながら、整理をしている。

概念モデル


神崎さんの本来のやり方だと、概念モデルは、「システム価値を明らかにする」ための最初のステップではなく、次の「システムの外部環境を把握する」ステップでの作業。

私の「ドメイン駆動設計」こだわりで、「概念モデル」は、最初の「システム価値を明らかにする」モデルとして位置付けている。

というか、ドメインモデルの基本設計をやりながら、コンテキストモデル、要求モデルを発展させていく、「ドメイン駆動」でやっている感じ。

順番はともかく、「モデル間の関係、整合性のチェック」という神崎さんのRDRAの基本は、ちゃんと押さえてやっているつもり。ドメイン駆動だけど、リレーションシップの整合性には、とてもこだわている、ということ。

業務モデル


コンテキストで、登場人物を洗い出し、要求モデルで、システムに期待される、主要な関心事を明らかにし、それを、概念モデル(初期のドメインモデル)という形で、まず、だいたいのイメージをつかむ。

今日は、このイメージをもとに、次の「システムの外部環境を把握」するためのステップとして、「業務モデル」、いわゆる、業務フロー図を、描き初めてみた。

見事に、概念モデル、要求モデル、コンテキストモデルに立ち戻って、いろいろ改定することになった。
モデル間の関連性や整合性をいつも気にかける、これが、RDRA流なんだと思う。

アークテクチャ


並行して、アーキテクチャの設計も進めている。
要件を定義してから、アーキテクチャ、といのは、ちょっと遅すぎる感じ。
概念モデルといっても、最初から、ソフトウェアにするための作業なのだから、その概念を、どうやって実装するかの議論も並行して進めちゃうのが私流。

今のところ、主な技術ポイントは、こんな感じ。

Bean Validation の全面採用


Spring Framework 3.0 で、 JSR-303 のアノテーションベースの Bean Validation がサポートされた。
ドメインモデルの実装のための便利な実装技術。さっそく飛びついた。

今のところいい感じ。 ( Spring Web Flow で、ちょっと一工夫必要だけど、ここは、Spring Framework エキスパートの大野さんの、さくっと、かたをつけてもらえそう)

プロジェクトの分割とプロジェクト参照


システム全体のレイヤ構造、アプリケーション間の依存関係、ドメインモデル内部のドメインオブジェクト間の依存関係、...

概念的には、依存関係、参照関係を、すっきり整理し、可能な限り、単一方向で、必要最小限の依存関係にする。

設計レベルでは、パッケージ図でそれなりにきれい描ける。
でも、実装に入ると、結構、あちこちで、 好き勝手に参照を始める。
Public クラスと、Public メソッドであれば、結局、実装としては、どんな参照でも記述できてしまう。

なんのことはない、グローバル変数の悪夢、スパゲティコードアンチパターンへまっしぐら。

今回は、これを、概念レベルの設計や、お互いの設計モラル(?)に依存するのではなく、物理的に、制限をかける試みにチャレンジ。

まあ、大げさな話ではなく、 Eclipse のプロジェクトの分割と、プロジェクト参照の設定の決めごとの話。

レイヤ構造で、ちゃんと実装するために、レイヤごとに別プロジェクトにする。そして、下のレイヤのプロジェクトを、上のレイヤのプロジェクトが「プロジェクトで参照」する。

jar にして、ライブラリの参照にするのではなく、プロジェクトの参照にする。

こうすると、双方向の参照が実装しにくくなる。(やればできちゃう方法はある)

ドメインモデルを、依存関係を元に、プロジェクトを複数に分割することにした。
ドメイン駆動設計(DDD) の、ドメインのレイヤリングを参考にしてモデリング。

その結果を、プロジェクト分割として、実装する。

一つのドメインモデルプロジェクトにしてしまうと、意味的な依存関係を無視して、あるドメインオブジェクトは、ドメインモデル内の他の public な オブジェクト/メソッドを自由にアクセスできてしまう。

ドメインを意味のあるパッケージ単位にまとめ、パッケージの参照を、単一方向かつ最小限に設計する。

そのパッケージ単位に、Eclipse のプロジェクトにして、開発を進める。
プロジェクト参照にしておくことで、下のレイヤ(プロジェクト)のドメインオブジェクトは、上のレイヤ(プロジェクト)のドメインオブジェクトを参照できなくなる。

こうやって、依存関係をかなり厳しく制約することで、安定したドメインモデルの設計・実装ができると思っている。

この開発案件では、この方式にこだわってみようと思う。

実際には、パッケージレベルでは、双方向に参照したくなる、ケースもでてきそう。
その場合、その原因になっているドメインオブジェクトの再モデリング、設計の改善ネタを発見したということ。

まあ、双方向の参照を許したほうが、目先の設計・実装は簡単になることはわかっている。

でも、そこをがんばって、設計改善することが、グローバル変数の悪夢、スパゲティコードのアンチパターンから抜け出す、足がかりだと思う。

まあ、ここらへんも、やりながら、いろいろ設計・実装ノウハウをためていこうと思う。

RDRA の神崎さんのブログ 「神崎コンサルノート」で

RDRA ( リレーションシップ駆動要件分析 ) を提唱され、要件定義マニュアル の著者である、神崎さんのブログに、この日記のこと、紹介していただきました。

光栄です。

私たちは、要求分析の段階を、RDRA 、ユースケース記述以降の設計・実装を ICONIX (ユースケース駆動開発 ) で、モデリングや設計・実装をやっています。

両方とも、表現方法は、UML ベース。
どちらのやり方も「厳密な UML 表記ルール」には、こだわっていなくて、もっと実践的です。

ドメイン駆動設計(DDD)の「モデル駆動設計(MDD:Model-Driven Design)」パターンを、具体的にやるために、RDRA + ICONIX は、実践的で良いやり方だと思っています。

それぞの解説本は、具体例が多く、現場で陥りがちな落とし穴のチェックポイント、改善方法のアドバイスが、いろいろ参考になります。

DDD の視点では、RDRA の「概念モデル」、ICONIX の「ドメインモデル」を、オリジナルのやり方に比べ、特に、力を入れてやっています。

RDRA の最初から「概念モデル」を描き始め、それを、ICONIX の「ドメインモデル」につなげ、そのまま、「実装クラス」に落としていく、というやり方です。

まだまだ試行錯誤中ですが、RDRA を導入してから、「初期のドメインモデル」をどうやって開発するかの、考え方とやり方が、なんとなくわかってきた、という手ごたえを感じています。

RDRA (リレーションシップ駆動要件分析) の公式サイト

RDRA (リレーションシップ駆動要件分析) の公式サイトに、このブログへのリンクを追加していただけました。
光栄です。神崎さん、ありがとうございます。

RDRA は、上流工程での問題の整理や、要件定義のやり方に悩んでいた私たちにとって、ほんとうに、救いになった、考え方、やり方です。

同じような悩みを抱えていたり、上流工程や要件定義のやり方に興味がある方には、RDRA に触れてみることを、強くお薦めします。

・上流工程で、どの現場でも発生しがちな問題とその具体的な改善方法が明確
・UML 風(?)の図を中心に、誰でも、簡単に、わかりやすく始められる
・ドメイン駆動設計の考え方とぴったり
・タイムボックス式に、モデルの改善をを繰り返す、反復型なやり方
・レガシーシステムやレガシーな要件定義のやり方も、視野に入った、現実的な処方箋
・ツール(Enterprise Architect) を使って実践するためのテンプレートが無料で提供されているのですぐはじめられる
...

わたしが、RDRA に出会って、よしこれだ、と思ったのは、「実践的」という言葉につきます。

それまでも、上流工程・要件定義をなんとかしたい、とずっと思っていました。
でもいくら勉強しても、

× 形式的で大量のドキュメント作成が発生して、とても実践する気になれない
× 考え方はわかるけど、具体性がなく、現場で役に立たない

というようなものばかりでした。
あるいは、現場にどこから、どうやって導入しようという、筋道が見えなかった。

でも、RDRA は、具体的なやり方が明確で、かつ、短時間の反復を繰り返すという、実践的なやり方なのが気にいった。部分的に、ちょっとずつ導入しながら、だんだんレベルアップしていく、という導入シナリオでいけそうな感じがした。

そして、実際にやってみて、その第一印象がまちがっていなかったことが実感できました。

最近は、「システム価値」の確認からはじめて「システム外部環境」を把握し、「システム境界」を定義して、要件を固めていく、という RDRA のやり方が、だんだん自分たちの標準のやり方になってきた。
まだまだ RDRA ごっこみたいな気もしますが、

・技術者たちが、上流工程に興味をもって参加するようになった
・システムの目的や背景の理解が、格段に向上した

という効果は、はっきりでています。

ここらへんのRDRAの実践話しも、この日記でいろいろ書いていきたいと思います。

(システム価値を明らかにする、コンテキストのモデリングも、RDRA の実践の一部です)

calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM