Tfpモデリングスペキュレーション

1,301 views

Published on

2007年9月の要求開発アライアンス定例会で発表したスライドです。

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,301
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Tfpモデリングスペキュレーション

  1. 1. TFPモデリングスペキュレーション mixiのQAネタから、ITPro 原稿作成を巡って • セントラルソフト株式会社 • システム2部 システム開発課 課長 • 林 栄一 Requirement Development Alliance 1
  2. 2. スペキュレーションとは?あーでもないこーでもないと、 いろいろ検討すること。 Requirement Development Alliance 2 /36 2
  3. 3. 目的TFPモデリングについてみんなであーでもない、こーでもないをやりたい!普通の人が迷っている過程をそのまま表現したい。 新しい可能性? こうしたらもっとわかりやすいかも? こうしたらもっと簡単にまとめられるかも? あーでもない、こーでもないをとおしてTFPないし はモデリングって自分でもできるかも! Requirement Development Alliance 3 /36 3
  4. 4. 自己紹介 東京工芸大学 工学部電子工学課 卒 楽器メーカー 4年半ほど在籍 NYに1年、現地の会社と共同開発 陶磁器の卸 父の会社を継ぐ 2年ぐらい 会社を整理 フリー時代 1年ぐらい JR関係の研究開発の会社 2年ぐらい ネットワーク保守業務 1年ほど セントラルソフト入社 ただいま11年目 初めてのIT業界 Requirement Development Alliance 4 /36 4
  5. 5. やってきたもの(開発) 電子楽器の開発 ドラムマシン、エフェクター、某P社カラオケアンプ JR関連 デジタルATS、山梨リニアモーターカー運行システム →OMTで設計 フレームワークの開発 10年ほどまえ、IOCコンテナをベースとしたJavaとVBをシームレスにつ なくコンポーネントフレームワークの開発。萩本さんのDROPを参考に。 マルチスレッド環境とシングルスレッド環境をつなぐしくみ 業務アプリ 大規模基幹業務のEJB化PJの共通チームでフレームワークの開発 物流系、薬局関連、製造業関係 音響制御系 サラウンドミキサー装置 →愛地球博NHKパビリオンで上映 Requirement Development Alliance 5 /36 5
  6. 6. やってきたもの 物作り大好きです。 オブジェクト大好き です。 Requirement Development Alliance 6 /36 6
  7. 7. やってきたもの(教育制度)IT業界に入って、あまりにもモノ作りの喜びやチームワークの醍醐味が少ない環境に愕然としたことから、まず現場を横断した研修制度から作ろうと思った。当初は業務のかたわら、直接新人研修をリード。研修組織を、8年かけてこつこつと大きくしていって現在40名ほどの現場横断の組織に成長させた。現在は複数の研修組織ワーキンググループのとりまとめをやっています。 Requirement Development Alliance 7 /36 7
  8. 8. 最近 今年ぐらいから表にではじめてます。 要求開発アライアンス オブジェクト倶楽部でライトニングトークス 「ドラムサークルとプロジェクトファシリテーション」 萩本さんには怒られぱなし。(笑) 勉強しなさい! Requirement Development Alliance 8 /36 8
  9. 9. 本題です。 原稿作成と今回の発表のきっかけ TFP分割の復習 最初のお題 モデリングの目的によるサービスの違い 価値提供者と受給者の整理 システムの目的を再設定 「物理的な場」から「抽象的な場」へ Requirement Development Alliance 9 /36 9
  10. 10. きっかけ牛尾さんや佐々木さんのMLでのメッセージ 「ITProの原稿を書いてみませんか」いっちょやったるか!とは言え、ネタがなかったんで、mixiの「要求開発アライアンスコミュ」でのQAを題材に、 宮原さんや佐々木 さんや牛尾さんなどのご協力をいただきつつ記事を検討。  Requirement Development Alliance 10 /36 10
  11. 11. 作ってみたはいいけど、、ちょっと公開するにはつっこみどころがおおいなぁ。(萩本さん談)勉強会でみんなで考えてみるというのもいいトレーニングだろう・・(萩本さん談)要は没原稿ですわ。(爆)※関西弁でおねがします。 Requirement Development Alliance 11 /36 11
  12. 12. ともかくTFPモデリングをあれこれ考える機会として提供したい。できれば、みなさんのお知恵を拝借して、公開できる原稿として完成させたい! Requirement Development Alliance 12 /36 12
  13. 13. ですから つっこみと ご意見は 大歓迎! Requirement Development Alliance 13 /36 13
  14. 14. TFP分割の復習 萩本さんの資料「TFP分割の狙 い」から抜粋させていただきます。 「TFP分割の狙い OpenThology1.0」より抜粋 Requirement Development Alliance 14 /36 14
  15. 15. TFP分割の復習 234526789$:;<526=>? ! 234526 " @A ! B7CDE)FGH1IAJ*234KLMNO)PHQ=R= STUV)WXYHZ[]/R^I " _A ! `abcde7=fg/hiIcdjk=lmn/oR1! #$%$&7pqrPH1psR^I ! 89$:;<b;t&e526 " @A ! `aOR;t&MuvH1wx)T`almMyzD{|Rlm }~MrPS•1I " €• ! lm=‚)`aOR;t&/ƒ„H17T`a=‚)f…/†‡ ˆqp‰ŠwXT`a=‹vŒfg7T•Q=Ž7•Q=Ž7=fg/ •„H1•7)RXUV)[)R1I 0102345 !"#$%&()*&+ ,#-&+.$)"#$%&()*&+/ Requirement Development Alliance 15 /36 15
  16. 16. TFP分割の復習!"#$%&!"#$%& !"#$)*+( !"#$)*+( !"#$%&( !"#$%&( ,!"#$-450123 !"#$-450123 ,!"#$-./0123 !"#$-./0123 +,-(.1 1 &$()#*$1 1 !"#$%1 1 !"#$% &$()#*$ !"#$% +,-(. !"#!"#"$% !"#!"#"$% &$()#*$ !""&() !""&() !"#*#+,-. !"#*#+,-."/0 56786789 234 >?@A 9:6;<=:;0:;0<=>?@>?@( LMNODE FGHI<JKDE FGHI<JKDE BCDE BCDE 0102345ABCD:;!"#$EFGHIJKL CD:;!"#$EFGHIJKL !"#$EFGHI !"#$%&()*&+ ,#-&+.$)"#$%&()*&+/ Requirement Development Alliance 16 /36 16
  17. 17. TFP分割の復習!"#()* ! +,-./(0123455 " +,-./(67289:*; ! <=>?@ABCDEDFGHIJ " +,-.KCL DMN:*; " OPQ<=>?@ABCRST2UVWEXYZ[MF]ZY; ! ^_(`abc=deRfg4:-./2hi4:* " #$%QBjklmnjoakK ! 8pJ-.KCLEqr " sC`K=mC?J&()*+,(t-.+(/2uvwx ! aKys`z{J+,-.KCL2f| " 67(}~2•€•G-.KCL 0102345 !"#$%&()*&+ ,#-&+.$)"#$%&()*&+/ Requirement Development Alliance 17 /36 17
  18. 18. TFP分割の復習!"#$%&!"#$%& !"#$)*+( !"#$)*+( !"#$%&( !"#$%&( ,!"#$-450123 !"#$-450123 ,!"#$-./0123 !"#$-./0 123 +,-(.1 1 &$()#*$1 1 !"#$%1 1 !"#$% &$()#*$ !"#$% +,-(. !"#!"#"$% !"#!"#"$% &$()#*$ !""&() !""&() !"#*#+,-. !"#*#+,-."/0 45 DE !"#$ %& 01023456789:;!"#$<=>?@ABC 89:;!"#$<=>?@ABC !"#$<=>?@ !"#$%&()*&+ ,#-&+.$)"#$%&()*&+/ Requirement Development Alliance 18 /36 18
  19. 19. TFP分割の復習!"#()*+ $ ,-./01$2 345678,./019:;<5=;>?@ #%&(A BCDEFGHI./01J$KL@ ")*+,-*A M")*+,-*AJEFN@!.,*/9OPQL@ !.,*/A $ RSTUV/$2 3TUV/WX(YZ[]^9_7@ !.,*/A BTUV/WX()`a+9bcL@A9d*>?@ ")*+,-*A MTUV/efghVfi(jk96l`m>?@0F47:123[4 #%&(A 0102345 !"#$%&()*&+ ,#-&+.$)"#$%&()*&+/ Requirement Development Alliance 19 /36 19
  20. 20. TFP分割の復習 !"#$%&!"#$%&(^_ !"#$ +$./ +$./ ` !"#$%& !"#$%& 23ab ()*+,- 01 45678 45678 9*!$678 <=>$678 9*!$678 C34745 45 C!"#$ CEFG=* EFG=* C+$./H*$ QR< H*$I*$ I*$ C8!STU STU QR< 01678 01678 J*K.LMN678 C<="VLP C01O$P 01O$P W*8XYZ W*8XYZ C/0121323 23 :;678 :;678 CJ*K.LMN678 !"#?@AB C456678 678 C!$%&D D C"(&)*%+&D D C#,-).D D01[GV*] cd ef 7gh- +GP 0102345 ij01[!"#$67O-klmn 01[!"#$67O-klmn !"#$67O-k !"#$%&()*&+ ,#-&+.$)"#$%&()*&+/ Requirement Development Alliance 20 /36 20
  21. 21. モデリングに対しての不安?2名づつペアになって話しをします。一人2分ずつ、片方ずつ話してください。聞いている方は言いたいことがあっても、途中で口を挟まずに相手の話を引き出す意図で聞いてください。話す内容は、「モデリングに関してうまくいっていないこと、不安」です。モデリングに関して、業務でバリバリやっている方は、ご自分のもっているモデリングに関するビジョンを話してください。 Requirement Development Alliance 21 /36 21
  22. 22. さて、最初のお題Mさんはサッカーの試合の運営を効率化するためにシステム化するよう上司から指示されました。Mさんはまず、このための現状分析を要求開発のTFP分割手法を使って行おうとしました。 Mさん自身アマチュアのサッカーチームに所属して活躍するぐらいサッカー大好きなので、意気揚々とモデリングを行いました。 Requirement Development Alliance 22 /36 22
  23. 23. 最初のモデル Requirement Development Alliance 23 /36 23
  24. 24. 問題点?このモデルの問題点がなにかわかりますか? Requirement Development Alliance 24 /36 24
  25. 25. 第1のポイント知っていることを全部書くのがモデリングではない。目的を明確に。 Requirement Development Alliance 25 /36 25
  26. 26. ユースケース再考 Requirement Development Alliance 26 /36 26
  27. 27. 第2のポイントモデリングの目的によるサービスの違い  特にサービスを明確にするためのビジネスモデリングは、何を 目的として書くかよって、記述するサービスが大きく異なりま す。  はじめから目的が明確ならいいのですが、目的が不明確あるいは、目的の本質が不明確なときには、このことがモデリングによって明確になることを意識することが重要です。  サッカーゲームそのものをモデル化するなら、観戦するとかチケットの購入は不要ですし、サッカーリーグ盛り上げることを目的としてモデル化するなら、プレイヤーや審判をモデル化するのはあまり意味がありません。 Requirement Development Alliance 27 /36 27
  28. 28. 目的はどっち? ?←どっち?→? ? Requirement Development Alliance 28 /36 28
  29. 29. 価値提供者と受給者の整理 Requirement Development Alliance 29 /36 29
  30. 30. システムの目的を再設定•すばらしい試合を見たい。•運営コストを削減したい。•みたい試合を逃さずにみてほしい。•チケット販売を効率よくしたい。モデリングの目的は、これらの目的が関係する構造を「見える化」することである。 Requirement Development Alliance 30 /36 30
  31. 31. システムの目的を再設定BSC戦略マップにしてみると Requirement Development Alliance 31 /36 31
  32. 32. 第3のポイント 価値の提供者と受給者を明確にすることによって、目的を明確にすることができる。(仮説) モデリングの目的はビジネスの価値を生み出すことですから、一つの方法として現在あるサービスを誰が提供し、誰が受け取るかを意識することで目的を明確にしていくことができます。 Requirement Development Alliance 32 /36 32
  33. 33. 価値と目的?さて、本当に価値の提供者と受給者の関係を明確にすることで、目的が明確にできるでしょうか?同じように2づつペアになって一人ずつ話してください。 Requirement Development Alliance 33 /36 33
  34. 34. 作り直したモデル Requirement Development Alliance 34 /36 34
  35. 35. 第4のポイント「物理的な場」から「抽象的な場」へ物理的な「場」の設定が必ずしも、ビジネス上の「場」とは一致しないものです。観客席やフィールドなどの物理的な「場」を認識した後に、それらを資源として使うビジネス上の「場」とはなにかを考察することが重要です。(仮説) Requirement Development Alliance 35 /36 35
  36. 36. 第4のポイント「物理的な場」から「抽象的な場」へ最初の図: 後の図:・観客席 ・チケット売買・フィールド ・試合運営 ・試合企画 Requirement Development Alliance 36 /36 36
  37. 37. 補足 今回はあくまでTFP分割図のサンプルという意味合いで「サッカーの試合」を題材として取り上げています。 本来の業務においてはどこかをシステム化するために分析していると思いますので要求開発では、どこを「システム化」するか?ということを念頭において、モデル化する部分を絞り込みます。 Requirement Development Alliance 37 /36 37
  38. 38. さいごにご意見ご希望は反省会で。ありがとうございました。 Requirement Development Alliance 38 /36 38

×