最近、会社のVirtualプロジェクトにて宿泊予約管理システムのモデルを考えております。
そこで学んだことを書こうと思います。
このシステムで予約者アクターさんの使うユースケース「新規で宿泊予約をする」に注目します。
この【宿泊予約】てものに対する認識の曖昧さを定義せずにモデリングすると
結構分析の段階でもモデルが劇的に変わったりします。
なぜなら、
a. その宿泊予約とは、１回の予約で１部屋しか予約できないようなものを指すのか？
b. それとも１回の予約で複数の部屋を予約できるものなのか。
最低でもこの２通りあります。（モデルの図は見切れてます）
予約詳細や宿泊詳細といったものがあるかないかで結構違います。
「え？ そんなん１回の予約で複数の部屋を予約できるに決まってんじゃん」て？
実はそこが落とし穴であり、このモデリングの楽しいとこだったりします。
まずはa.なのかb.なのか曖昧さをきちんと定義せずにモデリングしたうえでの発見を聞いてください。
aの一回の予約で一部屋しか予約できない場合、
作るものはbよりもシンプルなため開発者目線では嬉しいけども、
予約者の目線では複数の部屋を予約したくても、その都度予約を何度もしないといけなくて面倒くさい。
すなわち品質特性の項目の使用性の低下につながります。
（非機能要求と ISO9126 | オブジェクトの広場 (ogis-ri.co.jp)を参照）
対してbのように、一回の予約で複数の部屋を予約して大人数を分けたりできる場合は、
予約者目線では上記のaの場合みたいに
複数の部屋を予約したくても、その都度予約を何度もしないといけない、みたいなストレスなく便利な反面、
予約詳細というaにはなかった新たな概念が必要になり、
モデルが先程よりも複雑になるから、開発者側からしたら嬉しくないてことになります。
すなわち品質特性の項目の保守性の低下につながる。
ここで重要なのはそもそものステークホルダーの予約に対する関心事でどれを優先させるのか、です。
ドメインモデリングをするときに経験やなんとなくだけでモデリングをするだけでは
そのモデルは価値のないものになってしまいます。
これではせっかくみんなで丹精込めてつくったモデルアートが台無しでかわいそう、、、。
だからステークホルダーの視点での議論を必ずしなくてはいけません。
このシステムを物語るうえで、何人ものステークホルダーが存在します。
ちょっと何人かあげてみましょう。
まずはシステムを使う予約者ユーザーさん。
あとは開発を依頼してきた依頼者さん。
開発を請け負うPMさん、開発者さん。(ここではPMさんも含めて開発側の人たち、ってくくりに入れてしまいましょうか)
その他にもフロントで予約内容のチェックをしたりする宿泊ホテルの従業員さんなど。
今回は簡単のために、ユーザーさんと開発者だけの２種類に厳選して話を進めてみます。
便利で見やすいツールだと個人的に思いますので、
今回はastahプラグインの匠methodのステークホルダーモデルを使用しました。
図の中の赤の付箋はは嬉しくないこと、青はこんなだったら嬉しいなと思うことです。
いかがでしょうか？？
いまは一回の予約で一部屋しか予約できなくてもいいとしても、
それは開発者にとっては【今この瞬間は】楽できてうれしいかもしれませんが、
「一回の予約で複数の部屋予約したい」とユーザーさんが思ったときに
低い使用性を感じ ⇒ このシステム使わなくなる ⇒ 開発者たちの信用に響きますね。
もしも仮に複数の部屋予約できるように仕様変更しようものなら、
アーキテクチャを大幅に変えないといけなそうですね。
これは保守性の低下につながり開発者泣かせです。
てことは、開発者たちは初回ちょっと大変な思いしてでも、
最初から予約者目線を優先した方が良さげだと、ステークホルダーモデルを通して論理的にわかりました。
結果、上記のaよりもbのドメインモデルの方がよいとわかりましたね。8888888
つまり何が言いたかったかっていうと、
ドメインモデルを通して
ユーザーにとっての嬉しいことの品質特性の使用性と、開発者にとっての嬉しいことの保守性は
ときに相反関係になり得ることをこのモデルを作っている中で学べたのです。
まさかそのトレードオフ分析を、分析フェーズのドメインモデル作る段階で考慮することで
劇的にモデルが洗練されるとは思ってませんでした。
複数のステークホルダーさんたちのどの要望を優先するか、トレードオフしたうえで、
できあがるドメインモデルを作り上げることで、
つくったモデルは価値のあるアートになりえます。
これって結構な感動じゃないですか？？
機能要求を満たすための実現手段だったドメインモデルに、
品質を考慮した論理性やひとの思いがのってるモデルなわけですから。
ということで、今後ドメインモデルを作る際には、
充分にステークホルダーモデルで、各ステークホルダーの関心事を整理したうえで
それをモデルに反映させていきたいと強く思いました。