i*法におけるアクターとアクティビティ図のスイムレーンなどについて - ウィリアムのいたずらの、まちあるき、たべあるきーPART2

　i*法は、ゴール分析に使われるが、その際、i*法のアクターと、それ以降の工程で行われる業務分析で使う図のアクター（たとえば、アクティビティ図ならスイムレーン、ユースケース図ならアクター、DFDなら外部からの入出力を示す、外部）とは、粒度をあわせるべきだろう、というか、同じものにするべきだろう。

　i*法では、アクター間におけるゴール、ソフトゴールを記述し、明確化する。
　このゴールが、業務で実現できているかを確認するには、i*法のアクター、タスクが、アクティビティ図のスイムレーンやアクティビティ（DFDなら外部からの入出力とプロセス、ユースケース図ならアクターとユースケース）と関連付けられ、そこで行われているアクティビティが、ゴールを達成しているか、実現性のある話かを検証しなければならない。

　ところがここで、もし、i*のアクターと、アクティビティ図のスイムレーンがずれると、どれがどのアクティビティに対応しているのやらわからなくなり、ゴールが達成しているのかわからなくなる。

　たとえば、XMLコンソーシアムのビジネスイノベーション研究部会で作った気象庁の防災情報XML。
　これに関するi*法での図があるようだ（というのを見た。今日）。一方、Webサービス研究部会で実証実験しているのは、前に書いたとおり。

　ここで問題は、Webサービス研究部会ででてくる実証実験の二次プロバイダ、つまり気象庁データを受け取って、一般の人々に配信する会社＝アクターは、i*法で分析したビジネスイノベーション部会の何にあたるか？ということだ。

　もし、地方自治体がそれにあたるのなら、地方自治体のゴールは、自分の地域の安全を守ることだから、一般の人々（アンドロイド端末を持った人々）が、他の地域に行ってしまったら、その人たちの行動を追う必要はない。
　なので、実証実験で考えているような、端末を持っている人の情報すべてを二次プロバイダ（ここでは地方自治体）が持っていてくれる。。。
　というのはゴールにあわず、自分たちの地域に入ったら、その人だけ、情報を持っていたいということになる。

　また、もし、「気象何とか。。。（名前忘れた）」っていう気象データを配信する人だとしたら、その人たちはビジネスでお金を儲けるのが、ゴール。
　ということは、もし大災害になって、採算が会わなかったら、その地域に配信をしてくれないかもしれない。
　（っていうか、ゴールうんぬん以前に、災害があっても配信できる会社って、NTTなど、ごく限られた会社だけど）

　って考えると、「二次プロバイダ」は地方自治体なのか、気象何とか・・・っていうものなのか、それとも、ここに出てないアクター（たとえばネットワークプロバイダとか）があって、それが「二次プロバイダ」なのか？それによって、ゴールが違ってきて、開発すべきシステムも変わってくると思う。

　なので、アクターは合わせて、システムを考えたほうがいいと思う。

　XMLコンソーシアムの話は、たまたま今聞いて思ったので書いただけの話であって、一般的に、ゴール分析で出てくるアクターは、ワークフロー分析ででてくる誰のことかは、明確にして（できるだけ、同一名にして）議論したほうがいいと思う。