[jfriends-ml 11459] Re: 俗流オブジェ クト指向 (Re: UML)

[Takeshi Ito <linus@xxxxxxxxxxxx>]

高橋様

伊藤です。

ご返答おそくなりました。

> 高橋（徹）です。
> 
>    "Takeshi Ito <linus@xxxxxxxxxxxx>"さんは書きました：
> 
>>私はUML活用してます。RFPで機能が羅列されてるだけで、
>>誰のための機能かわかりにくいかったりするのを
>>ユースケース図で整理したり、ビジネスフローをお客様業務
>>に詳しい自社エンジニアからヒアリングすることによって、
>>アクティビティ図で書いたり。概念モデル図もかけるところまで
>>書いてます。提案書つくるときには非常に役に立ってます。
> 
> 
> 今回(9/18)の読書会で、ビジネスモデリングの章が丁度登場しました。
> “UMLはそもそもソフトウェアの設計のための表記法であり、ビジネス
> モデリングは視野に入れていない。・・・”(p.158)
> また、UMLに先行してIDEF0などのビジネスモデリング手法（と表記法）
> があるとのことです。UMLをビジネスモデリングに拡張するための取り組み
> として、書籍ではマーシャル氏の考案したもの、エリクソン・ペンカー両氏
> の考案したものの2種類を紹介しています。

そうですね。エリクソン＆ペンカー記法は、大学院でならった
ときにIDEF0を参考にしているなとすぐわかりました。

> 一方、ビジネスモデリングではオブジェクト指向よりもDAOが適用される
> ことも多いのではないかと思います。

恐れ入ります。DAOとは初めて聞きましたが、どういう
ものなのでしょうか？
調べてみましたが、MS AccessのDAOとは全然関係がないことぐらい
しかわかりませんでした(^^;

> ユースケース記述も分析者によって粒度が大きくばらついてしまったり、
> 書き方の差異が大きすぎたりと、過去の読書会でもいろいろと悩んでいる
> 発言がある部分です。

そうですよね。むずかしいですよね。しかし、少なくとも
・内部の動きにまで立ち入らない。　
・アクターとの情報のやりとりがなければならない。
　by オージス総研インターンシップの経験
は基本だと思います。結構、システムの中身のほうまで楕円を
書いてしまうことはあるようです。
＃FPを算出したいなら擬似ユースケース図みたいな意味合いで
＃それもありだと思いますが。

それでも、粒度は難しいですよね。他のユースケースとの
バランスなどを吟味しないと理解がむずかしくなりますし。

ユースケース専門の書物を読んだことがないので、
そのあたりに関して、記述されている文献をご存知の方
がいらっしゃったら、教えていただきたいです。
＃とりあえず、社内で読書研修がありまして、その
＃候補にいれようかなと考えております。

> RFP段階だと、業務の分析やシステム化範囲の定義に関わる段階（要求定義）
> と認識していますが、ここに現行のUMLを使うことはまだまだ難しいのでは
> ないかなと思ってしまいます。要求定義においてUMLを活用して効果を上げて
> いるとのことですので、是非うまくいくための工夫やポイントを紹介して
> 頂けるとうれしいです。

じゃんじゃんUML利用しているように書いてしまって申し訳なく
思います。私はソフトウェア工学専攻で博士出身の新米社員です。
社内で提案書作成のお手伝いをすることになったとき、
先輩社員にUML（特にユースケース図）を見せたら、
ほぅ、結構、使えるねということになりまして、では、部内に
提案時にUML利用を拡販しよう、勉強会を立ち上げようというところ
まで話が進んでいる程度です。

RFPには、ピンキリだと思いますが、ほんとに大まかな
要件が記載されている程度だと認識しています。たとえば、
既設システムDBのテーブル構造といったような内部の仕様は
まったくといっていいほど公開されていない場合が多いと
認識しております。

それでも、規模の大きな案件ですと、RFPの枚数がかなりに
なりますので、どこを作って欲しいのか、
誰のためのどういう機能がほしいのか、などの現状把握に
結構時間をとってしまい、かつ、RFPの書類ベースで
議論しているとメンバー内で現状の認識にずれがあったりして、
それを修正する議論に時間をとられて、提案部分の検討議論
に時間を割く時間が少ないというのが私の少ない経験での
印象です。

ですので、そうならないために、ほんとにお絵かき程度の
UML図（ユースケース図、アクティビティ図）でもあると
本題の議論に時間を注ぐ時間が増すと考えておりますし、
効果があったと認識しております。

ですので、たとえば、根本さんが

> UMLはコミュニケーションツールだと思っているので、
> 相手との会話がはかどればそれで充分な価値があると思います。

とおっしゃっていることに賛同します。ですので、村山さんの

> だから役に立っていないと．
> いくら雑談がはかどっても，ソフトウエアは作れません．

の発言には一切、賛同できません。無駄な雑談なんてしません。
目的を達成することための議論に注力したいと思っているのは
どの会社でもいっしょだと思います。

ちょっとお話がかわりますが、同じ業種ドメインを
業務内容にしている部署での提案活動では、UMLやIDEF0を
用いた、ビジネスモデリングもやるべきだと考えます。
私の部署では、お客様業務はベテランの先輩社員の頭の中に
しかなく、私のような新米社員は提案書作成する際、
わけがわからなくて、非常に困りましたし、
別の業種ドメインのSEの方で移ってこられた方や
.NETやJ2EEのプラットフォーム系に
強い、メンバーの方も結構、困惑されてました。

この辺は、ユーザ企業の情報部門と協力して
ビジネスモデルとか概念モデルを構築しておくと
Win-Winになるんじゃないでしょうか？

うーん、甘いですかね？諸先輩方のご意見を伺いたいです。

長文になりまして、申し訳ありません。以上です。

--
Takeshi Ito      linus@xxxxxxxxxxxx