Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

アジャイルによくきく?モデリング

1,217 views

Published on

2016/11/11 Modeling Forum 2016発表資料から抜粋

Published in: Software

アジャイルによくきく?モデリング

  1. 1. アジャイルに よく きく? モデリング 1
  2. 2. 自己紹介 はらだ いわお 原田 巌 Twitter:@iwaoRd • 認定スクラムマスター • 認定スクラムプロダクトオーナー • UMTP アジャイル開発部会メンバ 「人生、全速力で回り道」 モデモデ言ってるSIer勤務
  3. 3. 過去の発表 • 「アジャイル」界隈で「モデリング」絡みの発 表をしています。 • 最初に発表した「モデリングもしないでアジャ イルとは何事だ」は大きな反響を得ています。 2013年 DevLove甲子園 2014年 UMTPセミナー 2015年 要求開発アライアンス 2014年 DevLove甲子園 2014年 XP祭り(LT) 2015年 XP祭り(講演) 3
  4. 4. 内容は こんな感じ *「おお アジャイラーよ! しんでしまうとは なにごとだ! 4
  5. 5. モデル書いていますか? 5
  6. 6. 発表者の背景  SIerな中規模〜大規模な開発  DDDを始めとするモデルベース開発を実 践してみた(&勉強会で議論した)結果  自社だけでなくユーザー、協力会社も混 ざった異文化コミュニケーション(死 語?)な世界  既存のものをメンテナンスするよりは、 新しい未知の領域を相手にしている  アジャイル?な現場 6
  7. 7. 問題頻発! 7
  8. 8. Copyright © 2016特定非営利活動法人 UMLモデリング推進協議会 All rights reserved Agileとは ?
  9. 9. Agileとは(1) My Agile Master Cope said • Agileとは以下の事である 自己組織化 & フィードバック https://dk.linkedin.com/in/coplien
  10. 10. Agileとは(2) アジャイルマニフェストで規定されている • アジャイルの価値 • アジャイルの12原則 http://agilemanifesto.org/iso/ja/
  11. 11. Copyright © 2016特定非営利活動法人 UMLモデリング推進協議会 All rights reservedhttp://agilemanifesto.org/iso/ja/
  12. 12. Copyright © 2016特定非営利活動法人 UMLモデリング推進協議会 All rights reservedhttp://agilemanifesto.org/iso/ja/principles.html
  13. 13. どうでしょうか? http://agilemanifesto.org/iso/ja/principles.html
  14. 14. よく聞く失敗アジャイル開発の疑問 • 一向に決まらない仕様 →仕様が決められないからアジャイル? • 開発とユーザーの間の壁 →組織の壁。ドキュメントの投げ合い。 • 要件定義→設計→実装 →小さいWaterfall。 しかし、肝心のフィードバックがない。 次に向けての改善ができていない (組み込まれていない) • ドキュメント書かなくてイイ!(・∀・)イイ!! 14
  15. 15. そこでモデリングしてみた 15
  16. 16. ライブモデリング 全体モデリング コアモデリング フィードバック モデリング 今日話すこと 1. ライブモデリング 2. 全体モデリング 3. コアモデリング 4. フィードバックモデリング 16
  17. 17. ライブモデリング 全体モデリング コアモデリング フィードバック モデリング 今日話すこと 1. ライブモデリング 2. 全体モデリング 3. コアモデリング 4. フィードバックモデリング 17
  18. 18. ライブモデリング 話している内容をその場で「ホワイトボ ード」にモデリングする 設計で気が付くことをその場で解決する ため、意見をその場で見える形に表し、 開発者とユーザで認識を擦り合わせる 18
  19. 19. モデルの意義 モデルで得たいもの → 共通認識 19 それな (σ・ω・)σ
  20. 20. 認識齟齬による問題点 • ミーティング後に開発側が考えて整理した結果 (モデルや仕様書)を示されても、ユーザは自 分の意見が反映されているのか分からないこと が多い →結果として、動くソフトが見れるまで理解で きない。誤りや変更があった時に影響の大き さを理解することが難しい • クラスのように抽象化された概念を示された場 合に認識のズレが発生する →例外ケースや特殊な業務で土台から崩される (ちゃぶ台返し?(と開発者は感じる)) 20
  21. 21. モデルで認識を合わせる • 話している内容について認識を合わせる →繰り返し出てくる単語や文脈ごとの意味や 対話する相手の表情などから重要な情報を 抜き出す。 • 日本語の問題 →自分の言葉(とモデル)で再度説明する。 ストーリーとして話した時に気が付くモノと コト(関係)がある。 21
  22. 22. 牝牛のベッシー • 「抽象のはしご」による思考 • 抽象度を上げて話をすると見えてくる「性質や共 通点」 • 話す相手によって抽象度を行き来して認識を合わ せることが重要 (例:クラス図 ⇔ オブジェクト図) 22 「ベッシーは 牝牛である」 牝牛 家畜 資産 富
  23. 23. モデリングを通した「場」の形成 • 『場の理論とマネジメント』伊丹敬之 • アジェンダ • 解釈コード • 情報キャリアー • 連帯欲求 目的 場 23
  24. 24. 【技】物語 • 議論が止まる時には何か登場人物をイメージして、 生活を語ってみる。 • 登場人物は実在していれば尚よい – Aさんが会社に来て最初にxxして、次にxxする… この時、人は何に興味を示すのか? 24
  25. 25. 【技】モデルの罠 • 議論が活性化しないとき、わざと揺るがしてみよ う。 • 重要なもの、重要じゃないものを真ん中に書いた り、大きく書いたり、ハートだったり… – 時には洗脳だったり誘導尋問だったり… この時、人は何に興味を示すのか? 25 はぁと 重要 そうでもない
  26. 26. ライブモデリング 全体モデリング コアモデリング フィードバック モデリング 今日話すこと 1. ライブモデリング 2. 全体モデリング 3. コアモデリング 4. フィードバックモデリング 26
  27. 27. 全体モデリング 欲しいものは全体感(概念モデル) 開発者とユーザのユビキタスを作る 全体が見えることで得られるものは多い 1. 用語の理解・整理 2. サブシステムへの分解 3. コア(関心事)の抽出 27
  28. 28. アジャイル開発での問題点 • 「大きな泥団子」のまま進めてしまうことがある →分かっているつもりが大きな歪みとなって システムに打撃を与えてしまう • 自分の領域は詳しいが他の領域は無関心 →情報が分断されて良いやり方への糸口がない • 動かないと分からない? →動かす前に分かることもあるが、それを行わず 動かせる具象レベルの世界で理解しようとして も時間が足らない。作ってしまった後で、しか 学べないのでは、もったいない 28
  29. 29. なにより学習 • 言葉だけでは理解できない →業務をシステムに親和性のあるモデルで表現 することで業務を視覚的に学ぶことができる • 言葉だけでは感じられない →言葉でしか存在しないものをモデルで可視化 することで業務に触れて動かすことができる 29
  30. 30. イメージ ①全体を描画 ②領域の分割 ③各領域の詳細化 ④領域間の共通概念の明確化 30
  31. 31. • クラス図 – 属性はKeyとなるもののみ – 継承や集約、コンポジションは積極利用 – 関連の多重度は記述 – ノート重要 • オブジェクト図 – この抽象度だと難しいが必要に応じて 31 使うモデル あくまで概念レベルの記述と割り切って設 計や実装に無理に追いつこうとしない。 コンセプトをまとめるようなイメージ
  32. 32. 全体感 • 関連を持った用語集 →業務の言葉を明らかにしつつ、 言葉の関連に注目する。 (抽象度をあわせる。関連を見出す) • 問題領域ごとの分割 →用語を使われる業務毎に分割する。 • コンテクスト境界 →業務領域によって同音異義語や同義語 があり、その存在を明確にする • (ムダなもの判別)秘密だよ… 32
  33. 33. 【技】A3モデリング • A3用紙でまとめられるくらいにしといた方が良い – 電子化すると(余計な)細部が気になる – 保存されていると覚えていなくていいと思えてしまう安心感への アンチテーゼ • ホワイトボードのような揮発性の高いものは無く なるべきだし、そもそも忘れてしまうようなモデ ルは要らないと割り切って考えています(笑) = A3用紙分の情報なら書くのに時間不要 33
  34. 34. ライブモデリング 全体モデリング コアモデリング フィードバック モデリング 今日話すこと 1. ライブモデリング 2. 全体モデリング 3. コアモデリング 4. フィードバックモデリング 34
  35. 35. コアモデリング コアに対してシナリオを深掘りする (前提:全体観が共有されている) コアが崩れると全体が崩れるので先に認 識を合わせて合意しておく 35
  36. 36. モデリングへの覚悟 36 Red pill or Blue pill
  37. 37. アジャイル開発での問題点 • 動けばいいのだろうか? • より良いものとはなんだろうか? ここまで話した内容は抽象的に見れば、よくある システム開発方法論である。 別にアジャイルとかモデリングとか言わなくても終 着点としての違いはあまり無いと思っている。 しかし、モデルを使った開発には意味がある。 モデルを使用して得たいものがある。 37
  38. 38. 38 必要なのは Aha!!
  39. 39. 目的と解決策 • 目的と解決策を分けて考える – トップダウンアプローチ ○ ユーザのシステムへの要求から考える ○ 目的がはっきりすると解決策も出しやすい ✕ ただ目的は最初から分かる訳ではない – ボトムアップアプローチ ○ 要素間の性質から上位概念を探す ○ 必要な要素は簡単に集まる ✕ 上位概念まで昇華することは難しい 39
  40. 40. 視座・視点・視野 • 視座:モデルをどの立場から見るか • 視点:モデルをどのように見るか • 視野:モデルに表現する範囲はどこまでか 視点 視野 視座 視座 40
  41. 41. モデリングを実践して気付く点 • 作る対象の目的と価値 – 目的や前提を明らかにする • 特に視座の部分 – モデリングする範囲を合意する • どの視点の話をしているのか? • 関心事は何で、どこまでコストを掛けるのか? – 説明責任は開発者 – 設計のメリットとデメリットを示す – 見ることができる範囲は見ておく 41
  42. 42. イメージ ①中心となる概念の深掘り ②シナリオ↔モデル ※繰り返し重要 42
  43. 43. • クラス図 • 状態遷移図 • オブジェクト図 – ユーザーはこのレベルで話すので特に重要 • シーケンス図 ※基本的にこのレベルまで来ると私の現場ではクラス図のみを メンテナンスしています。 他の図法はあくまで実装するために用意していて、ソースが 書けると破棄してます。 電子化したくないくらい書き直します。。。 43 使うモデル 欲しいのは設計判断。しか し、その場合欲しいのはモデ ルよりアーキテクチャドキュ メントだったりする。 ソースで分かる事は捨てる!
  44. 44. デザイン問答 すべてのモノの形や仕組みには理由がある 画像引用:デザイン問答 http://www.nhk.or.jp/design-ah/design-mondou/ 44
  45. 45. 伝えるのは「質」の話 • パタンを見出すこと http://blog-imgs-47-origin.fc2.com/i/t/o/itokaya/IMG_5160-horz.jpg 45
  46. 46. [入口での転換(112)]より <より大きなパタンとの結合> …どんな建物や複合建物の場合でも、すで にその主入口の大まかな位置は分かっている -[大きな門口(53)]から敷地への門、[見分 けやすい入口の集まり(102)]から各建物への 玄関、そして玄関。いずれにしろ、入口は「外 部」-公的世界-からさほど公的でない内部 世界への転換をつくり出す。 モデルは捨像 この世の森羅万象は表せない。 しかし、「パタン」を見出すことで「木を見なが ら森を見ることができる」 Ex) 門 http://fashionjp.net/creatorsblog/fujita/2010/08/post-89.html 46
  47. 47. 【技】オブジェクト寸劇 • 責務が不明なとき、個人個人にオブジェクトの役 を割り当てて劇をしよう。 • 演者たちにとあるinputが与えられたとき、どのよ うに協力してoutputを出すのか考えてみる。 47 注文 商品 ユーザ
  48. 48. 【技】3分クッキング • コアモデリングが進むとその場で考えるライブ モデリングは厳しくなる場面が出てくる →ある程度は分析、想定を立ててモデルを 作って持っていく方が良い • 予想できなかったことを特に深掘り • 「ない」ことを確認 • fragileにしない 事前にxx分ほど 煮込んだモデルは こちらです 48
  49. 49. ライブモデリング 全体モデリング コアモデリング フィードバック モデリング 今日話すこと 1. ライブモデリング 2. 全体モデリング 3. コアモデリング 4. フィードバックモデリング 49
  50. 50. フィードバックモデリング ソースコードや動くソフトウェアで学ぶ 特に最初から正解が分からないコアモデ リングと組み合わせ必須 学んだことをモデルやシナリオへフィー ドバックして洗練する 50
  51. 51. 実装して気付く学びのループ 51
  52. 52. XP実践していますか? Amazon:http://www.amazon.co.jp/dp/4274217620/ 52
  53. 53. XPとモデリング アジャイルモデリング by Scott Ambler ❝モデリングはXPの1つの要素である❞ ❝リファクタリングとテストファースト開発という XPのプラクティスは、一般的に従来型のモデリン グプロセスに結び付けられている「きれいな設計 を促す」「コードを書く前に設計をよく考える」 という2つの重要な目的を達成するために役に立 ちます❞ アジャイルモデリング XPと統一プロセスを補完するプラクティス 第16章、第17章 http://www.amazon.co.jp/dp/4798102636 53
  54. 54. BigDesignUpFront “論点となるのは、設計をするかどうかではなく 設計をいつするかである” • LDUF/ENUF 設計の戦略と設計のシンプリシティ – 対象者に適している – 情報が伝わりやすい – うまく分割されている – 最小限である エクストリームプログラミング 第14章 設計:時間の重要性 54
  55. 55. 実装・TDDからの学び • クラス間の連携がイマイチ – 責務分割がキレイにいかない • テストコードが複雑 – Mockだらけで関心事が多過ぎる ユビキタスから得られる知識が解決の糸口 → 気付きを設計に取り込むと綺麗に 55 実装 テスト 別実装 別実装 別実装 実装 実装 実装Client より良い設計 新しいシナリオ 価値の判別
  56. 56. How Do We Know When We Are Done? Doneの定義 How Do We Know When We Are Done? https://www.scrumalliance.org/community/articles/2008/september/how-do-we-know-when-we-are-done 56 受け入れられる 最低限を素早く クリアする
  57. 57. 変化に適応する 変更のコストを一定に保つ 従来開発 XP開発 時間 コスト 書籍:エクストリーム・プログラミング ソフトウェア開発の究極の手法 P.23 図3 変更のコストは時間とともに劇的に上がらないことがある 57
  58. 58. 小さくそして速く 1. シナリオを探索する(理解) 2. モデルを小さく作る(発見) 3. モデルをコードにする(実現) 4. シナリオを実行する(検証) 5. 動くコードからフィードバックを得て、 小さくイテレーティブに開発することで 学んでいける 書籍:IMPACT MAPPING P28-29 反復デリバリによる改良 58
  59. 59. ライブモデリング 全体モデリング コアモデリング フィードバック モデリング 今日話したこと 1. ライブモデリング 2. 全体モデリング 3. コアモデリング 4. フィードバックモデリング 59
  60. 60. Copyright © 2016特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 問題領域を分割する ①全体を描画 ②領域の分割 ③各領域の詳細化 ④領域間の共通概念の明確化 60
  61. 61. コアを深掘りする ①中心となる概念の深掘り 61 ②シナリオ↔モデル ※繰り返し重要
  62. 62. 62 学びのループを回す
  63. 63. http://blog-imgs-47-origin.fc2.com/i/t/o/itokaya/IMG_5160-horz.jpg 63 パタンを発見する
  64. 64. 64 Models stay alive!!
  65. 65. ライブモデリング 全体モデリング コアモデリング フィードバック モデリング 今日話したこと 1. ライブモデリング 2. 全体モデリング 3. コアモデリング 4. フィードバックモデリング 65 以上!

×