<< イベントソーシングスタイルを実装する | main | 状態遷移(プロトコルモデル)の実装 【パターン】 >>

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

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

RDRA の基本のやり方


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

の4ステップ。

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

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

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

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

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

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

システムの価値


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

主要な絵は、

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

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

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

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

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

システムの外部環境


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

モデリングツールの威力


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
<< September 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM