業務分析について（2）
■はじめに
前回の業務分析について（1）で要求の源泉を顕にすることがシステムを創る上で重要なことであると述べました。
今回から数回に分けてその具体的な方法についてお話していきたいと思います。
■動的モデル（アクティビティ図で表現）
要求の源泉とは何かを認識するための例として、為替の約定（ヤクジョウ）を取り消すというアクティビティに触れました。アクティビティとはUMLのアクティビティ図で表現されるアクティビティ（横長の丸）のことです。
以下に図示します。
※約定の取り消しというアクティビティは、それ単体では意味を成しません。約定ができる前提として、注文を発注しなければならないし、約定自体がないと取り消しすることはできないため。よって、注文や約定についても図示しています。
■機能モデル（ユースケース図で表現）
続いて、ユースケース図を使って機能モデルを表現しています。以下に図示します。
アクティビティ図のアクティビティとユースケース図のユースケースは、わたしは同じモノとして捉えています。
上図を見比べてみるとアクティビティ図の縦長の枠（レーン）とユースケース図の人型（アクタ）の名前が一致しています。誰（レーンやアクタ）がその機能を使う主体者なのかを明示することは、システムの使われ方（機能的な優先度）や性能要件を明確にするという観点で重要です。
動的モデルは、ある時点（状況）で、関係者同士（レーン間）が、各ユースケースをどのような順番で使用するのかを表現しています。
機能モデルは、誰（アクタ）が、何を（ユースケース）、どうやって（アクタとユースケースの関連線）、作業をするのかを表現しています。
要するに、動的モデルはアクタの関連や順序関係を表現することが目的で、機能モデルはどうやって使うかを表現することが目的なわけです。
■静的モデル（クラス図で表現）
これに加えて、モノ事を静的な側面で表現した静的モデルもクラス図で図示しておきます。
静的モデルは、ユースケースを抽象化したコトをクラスとして表現し、ユースケースを操作（メソッド）に関連付けるイメージです。
静的モデルは、時間に余裕がある場合にしかわたしは作らず、後でじっくり分析するようにしています（動的モデルと機能モデルがあればその場の要件にはコト足りるので）。
■モデル化のメリット
わたしは、約定を取り消すという断片的な機能を実装する際にも上記の動的モデル、機能モデル、静的モデルの3つの軸で捉える作業をします。
地道にこれらのモデルをブラッシュアップすることで業務についてもシステムについても本質的な理解に繋がり、あの人はわかっている！と一目置かれる存在になります。
また、モデルを作成すること自体のメリットを示しておきます。
- 動的モデルを作成すると、関連するユースケースが具体的に把握できるので考慮モレが減ったり、優先度決めの基準（複数の図に何度も登場するユースケースは重要）になる。
- 機能モデルを詳細化していくとBCE（Boundary/Controll/Entity）の境界毎に機能の共通化がしやすくなり、役割分担が最適化できる。
- 静的モデルを作成すると、今回の要件（ユースケース）を抽象化して本質的なコトを炙り出せるので考慮モレを可能な限り減らせたり、制約事項やルールの定義を一元的に可視化できるため、将来の要件を適用する際に重宝します。
補足として、動的モデルと機能モデルはどういう考え方に基づいて実装するかのインプット（設計資料）になります。静的モデルは、どういう設計にすべきかのインプットになります。これは、何を信じて実装すればよいかの解となるので重要なことです。
■おわりに
次回以降、上記のメリットの1～3や補足事項について具体的にプロジェクトで使える形でまとめていきたいと思います。
コメント
xeren
大変興味深く拝見しました。
業務分析においてユースケース図を使うのは割とよくある手法ですが、
静的モデルとしてクラス図を用いるのは目から鱗でした。
動的モデルについても、アクターで整理すると分かり易いですね。
ちなみに、アクティビティ図を活用されている方を初めて見たのですが、
フローチャートではなくアクティビティ図を用いる利点等はあるのでしょうか？
（フローチャートは使い古されている分、年配の方にもウケがいいので…）
"UMLで統一させる"以外に理由があれば教えていただきたいです。
ビガー
xerenさん、コメントありがとうございます。
>ちなみに、アクティビティ図を活用されている方を初めて見たのですが、
>フローチャートではなくアクティビティ図を用いる利点等はあるのでしょうか？
お客様からウケの良いモノ(図など)を使うことが一番よいと私も思います。
フローチャートと比較してアクティビティ図にする利点は、
1. レーン間のインタフェースを明示できる
2. 図の粒度を揃えやすい
3. 並列性や非同期の表現がしやすい
と考えています。
1. については、今回はレーンをアクタと紐付けましたが、レーン間のデータインタフェース(注文情報や約定情報)を図の中である程度表現することでデータインタフェース仕様書と紐付けると説明がしやすくなります。
2. については、今回の例ではあるユースケース(約定を取り消す)を軸に考えましたが、本来であれば、トップダウンで整理するのが常套だと考えています。(実際の現場では、ある単一のユースケースがフォーカスされて実装依頼されることが多いと思うのでボトムアップちっくにしています)
アクティビティ図をネストする形にして、アクティビティをサブアクティビティで表現して段階的に詳細化させていくイメージで、仮に「不正取引を排除する」というアクティビティが上位にあったとした場合に、「注文を取り消す」というサブアクティビティと今回の「約定を取り消す」というサブアクティビティで「不正取引を排除する」というアクティビティを表現することで図の粒度を保つことが容易になるということです。
3. については、システム化方式の検討で性能担保の選択肢として並列性や非同期度合いをどうするかを図の中で明示できることは、手戻りの観点で考えると結構大きいです。
また、アクタ一覧を作るインプットとしても役立ちます。
アクタ一覧の意味や上述1～3については、今後のコラムで明確にしていきたいと思っています。
補足する機会をいただきありがとうございます。
インドリ
おはようございますビガーさん。
この質問は、少しこのコラムの内容とずれていると思いますが温かい眼で見てください。
この段階では他業種の方の仕事内容を知るために、書籍類のお世話になると思います。
この時どれぐらいの程度まで調べますか？
余りにも学びすぎると先入観が邪魔をしてしまいますし、かといってお客様が使用する業界用語を知らないようでは要求の源泉を理解する事は出来ません。
曖昧な質問で申し訳ないのですが、その辺のバランスを教えて頂ければ幸いです。
xeren
ビガーさん、丁寧なご回答ありがとうございます。
なるほど…フローチャートでは粒度や同期に焦点を当てることはあまりないですね。
仰るとおり、同期の考慮漏れをやらかそうものなら影響大です。
最初は「大抵の観点はフローチャートにも応用できる」と思っていたのですが、
これらを全て取り入れると煩雑になる上、既にフローチャートではなくなりますね…
設計等に落とし込む前段階のモデルとしてはアクティビティ図の方が向いている、
というところでなんとなく納得がいきました。
フローチャートとは用途を分けるのが良さそうです。
今後のコラムにも期待しています。
ビガー
インドリさん、コメントありがとうございます。
>この段階では他業種の方の仕事内容を知るために、書籍類のお世話になると思います。
>この時どれぐらいの程度まで調べますか？
私なりのやり方で恐縮ですが、未経験業種の導入アプローチは以下のような手順です。
1. 業界の概要確認(よくわかるxx業界みたいは本を数冊ペラペラと拾い読み)
2. 仕事のターゲット業務領域確認(会計業務とか発注業務レベルの本を絞って1冊をある程度じっくり)
3. お客様の実際の業務がわかる資料確認(じっくり読んで、モデル化してみる)
1.は1日くらい、2.は2,3日、3.は3,4日のトータル1週間くらいですかね。急ぎ具合や求められるコトの具合で変わりますけど。
インドリ
ビガーさん返信有難うございます。
大分参考になりました。
高橋秀典
ビガーさん、
高橋です。
私の方は、まだ要求分析のところですが、ようやく夏休みしている間に、追い抜かれてしまいました。
基礎の話をしているので、ビガーさんの実践形式のお話に先行しているとうまくクロスできて丁度いいのですが、今から追いかけますので、よろしくお願いします。
ビガーさんがインドリさんのコメントに応えられていましたが、未経験業種のクライアント対応は、私の場合ERモデルを使います。
コラムでのこれからのシナリオとして考えている内容ですが、コンサルとして客の業務プロセスを、事細かに聞いていきにくいし時間がかかることもあり、データモデリングを進める中で、データの構成を元に全体をつかんでいくという形です。
もちろん、ビガーさんのように客と話ができる最低限のベースは確保しておくことは、必須だと思います。
お互い何の目的のためにシステム作りをするかという、根本的な話に踏み込む内容にできればいいですね。
ビガー
高橋さん、コメントありがとうございます。
私のコラムでは、現場目線で直近のプロジェクトで「エンジニア」が使えそうながアプローチを紹介しようかと考えています。高橋さんのコラムでは、主に「コンサルタント」がターゲットになっているかなと考えていました。また、高橋さんのコラムではトップダウン、私のコラムではボトムアップを軸にみたいな感じであまり被らない感じにできればと思っています。
>ビガーさんがインドリさんのコメントに応えられていましたが、未経験業種の
>クライアント対応は、私の場合ERモデルを使います。
私は、上記の3.のモデル化してみるで主要データの洗い出しをします。で、主要データは、静的(概念)モデルで整理します。静的モデルは、将来に備えてとコラムで書いていますが、データの観点で将来的に業務上変更が多い部分、変更が少ない部分を整理するのにも役立ちます。
その後、動的モデルや機能モデルでそれらのデータを関連付けて表現していきます。
ですが、導入(プロジェクト参画の準備)段階では、ここまでできることは少ないので走りながら進めていきます。
>お互い何の目的のためにシステム作りをするかという、根本的な話に踏み込む
>内容にできればいいですね。
そうですね、結局いいたいのはソレなんですが、うまく整合性をとりながら活動するのは経験や勘が必要ですよね。私自身の整理にもなって、よい勉強になっています。