アジャイルで

1

不確実性に対応する

〜アジャイルプラクティスとモデリングの有用性〜

自己紹介

はらだ いわお

原田 巌 オージス総研株式会社 技術部 アドバンストテクノロジーセンター

兼 アジャイル開発センター

• 認定スクラムマスター

• 認定スクラムプロダクトオーナー

• 認定スクラムプロフェッショナル

• SAFe Agilist（習得中）

• LeSS Practisionar

• UMTP アジャイル開発部会メンバ プログラム委員会（Modeling Forum）

過去の発表

3

• アジャイル、UMTP関連で「モデリング」絡みのアジャイル開発の発表をしています。

• 最初に勉強会で発表した「モデリングもしないでアジャイルとは何事だ」は大きな反響を得ていろいろな場所で発表しています。

2013年 DevLove甲子園 2014年 UMTPセミナー 2015年 要求開発アライアンス

2014年 DevLove甲子園 他、Domain Driven Designで UMTPなどで発表

2014年 XP祭り（LT） 2015年 XP祭り（講演）

http://www.slideshare.net/iwaoRd/ss-2807525 http://www.slideshare.net/iwaoRd/xp-20150912 http://www.slideshare.net/iwaoRd/modelingtddddd

発表者の背景

SIerな中規模〜大規模な開発

DDDを使用したモデルベース開発を実践してみた（＆勉強会で議論した）結果

自社だけでなくユーザー、協力会社も混ざった異文化な世界

既存のものをメンテナンスするよりは、新しい未知の領域を相手にしている

その為、事例は「学習」を中心に「役に立つソフトウェア」をユーザーに提供し、新しい知識からソフトウェアを進化させる事を行ったことを話します

4

今日、話そうとしていること

1. 突きつけられた現実について • 欲しいものができない

• 正解を誰も知らない

• これで本当に良いのか分からない

2. アジャイルで解決してみた

3. モデリングを活用したアジャイル開発の実践例

5

突きつけられた現実 • ビジネスは想像以上に早く変わっている

• 今、上手くやっていることは、もう正しくないかもしれない

• 大きな会社でさえ、間違うこともあれば潰れてしまうこともある

本当にやりたい事は分かっているのだろうか？

欲しいものができない • 作ったソフトウェアは役に立たない

2002年Standish Groupのレポートでは64%がほとんど使用されない結果が出ていた →データ自体は古いが感覚値は同じ

7 https://theagileexecutive.com/2010/01/11/standish-group-chaos-reports-revisited/

欲しいもの≠手に入るもの

• 欲しいものより作れるものは圧倒的に少ない

8 https://www.slideshare.net/kawaguti/jikkan-kudo

共通認識がそもそも無い

• 対話があっても認識が違えば意味をなさない

脳内イメージは常に食い違う

10

たいていは 「親切心が裏目」に出るという真実

正解は誰にも分らない

• 動くソフトウェアでユーザーは本気になる。逆を返せば、それまでは誰も正解が分からない チキンゲームの繰り返し…

11 https://www.slideshare.net/kawaguti/jikkan-kudo

これで良いのか分からない

• 「価値」の答えは常に現場にある

• ただ、答えがあることに気が付いていない場合が多い

• 出来上がってきたものをどのように判断すればいいのか分からない

• 動くものを見ても良いか悪いか判断がつかない

12

欲しいものができない →必要なものをみんなで理解する

例えば、ユーザーとの会話

「あの基本情報はいつ展開されますか？」

「枠取りで順番が決定されます」

「ファイリングによって出来たモノは割付してから統合した方がいいです」

お客様の業務で使われる専門用語。 それを一緒に使う日常会話からユーザーが欲しいものを理解する。

共通認識

共通認識＝ユビキタス言語

• ユビキタス言語とは、Eric Evansが『Domain Driven Design』において、開発者とユーザーとの間で共通の厳格な意味を持つ用語を構築するというプラクティスを表すために使用した用語である。ユビキタス言語はソフトウェアにおけるドメインモデルに基づいている。ソフトウェアは曖昧さをうまく扱うことができないため、厳格さが必要となるのである。 Evansは、ドメイン専門家との会話においてユビキタス言語を使用することが、ユビキタス言語およびドメインモデルを検証できる重要な部分であると明言している。

15 http://bliki-ja.github.io/UbiquitousLanguage/

正解は誰にも分らない →エンジニアリングの利用 • 価値・実現可能性・有用性 →ユーザーだけでは既に問題を解決できない。 本当に必要なものはいろいろな側面から見る ことで始めて見えてくる。

16

Value

Feesible Usable

エンジニアリングの有効利用

ユーザーのシステムに関する知識を補完して、共により良いソフトウェアを築けなければ、この先、勝てない。 • デジタル能力としての要素技術

UX（サービスデザイン思考）、データサイエンス、IoT、AI、クラウド、モバイル

• アーキテクチャーガバナンスとモデル 複雑化したシステム機能を統合したり、データの抽出を早く行える必要がある

• アジャイル開発 これらを用いたビジネスとITの密な連携で成果を生み出すためにアジャイル開発が必要になる

17

素早く実験

正解がわからない今日において、論理的に考え出すことは難しい。 素早く実験し、その結果から次の一歩を考える事が重要である。 しかし、闇雲に実験ばかり行っても右往左往するだけで、一向に正解の方向性すら見つけることができない。

よって、対象の「全体性」を持ちながら次の一歩の「仮説」を立てて、「実験」の結果から「学習」することが一番の近道である。

18

仮説と検証

• ユーザーのインタビューや業務の観察から対象となる業務の全体とそこにある「問題領域（ドメイン）」を洗い出す

• より重要な「問題領域」から掘り下げていって、コアとなる業務から周囲の関心事を明らかにする

• 「動くソフトウェア」で検証し、新たに発見した事柄を「問題領域」にフィードバックして新しい「動くソフトウェア」を作成する

19

実現方法

１）全体感、目的、知識の共有

ビッグピクチャとして全体を捕えること。

システムの背骨を築くこと。

そしてなによりユビキタス言語を築くこと。

２）設計・実装を素早く行う

「素早く」設計を手に入れること。

なにより良いコードを書き上げること。

フィードバックから設計↔実装を見直すこと。

人はそれを 「アジャイル」と呼ぶ

21

Agileとは ?

Agileとは（１）

My Agile Trainer Cope said • Agileとは以下の事である

自己組織化 ＆ フィードバック

https://dk.linkedin.com/in/coplien

チーム

による学習の活用

Agileとは（２）

アジャイルマニフェストで規定されている

• アジャイルの価値

• アジャイルの12原則

http://agilemanifesto.org/iso/ja/

http://agilemanifesto.org/iso/ja/

http://agilemanifesto.org/iso/ja/principles.html

どうでしょうか？

http://agilemanifesto.org/iso/ja/principles.html

モデリングを活用したアジャイル開発の実践例

28

ライブモデリング

全体モデリング

コアモデリング

フィードバック モデリング

現場でのモデリング実用例

1. ライブモデリング

2. 全体モデリング

3. コアモデリング

4. フィードバックモデリング

29

ライブモデリング

全体モデリング

コアモデリング

フィードバック モデリング

現場でのモデリング実用例

1. ライブモデリング

2. 全体モデリング

3. コアモデリング

4. フィードバックモデリング

30

ライブモデリング

31

話している内容をその場で「ホワイトボード」にモデリングする

設計で気が付くことをその場で解決するため、意見をその場で見える形に表し、 開発者とユーザで認識を擦り合わせる

モデルの意義

モデルで得たいもの →

32

共通認識

それな

(σ･ω･)σ

認識齟齬による問題点

• ミーティング後に開発側が考えて整理した結果（モデルや仕様書）を示されても、ユーザは自分の意見が反映されているのか分からないことが多い →結果として、動くソフトが見れるまで理解で きない。誤りや変更があった時に影響の大き さを理解することが難しい

• クラスのように抽象化された概念を示された場合に認識のズレが発生する →例外ケースや特殊な業務で土台から崩される （ちゃぶ台返し？（と開発者は感じる））

33

モデルで認識を合わせる

• 話している内容について認識を合わせる →繰り返し出てくる単語や文脈ごとの意味や 対話する相手の表情などから重要な情報を 抜き出す。

• 日本語の問題 →自分の言葉（とモデル）で再度説明する。 ストーリーとして話した時に気が付くモノと コト（関係）がある。

34

現場でのモデリング

1. ホワイトボードの前にペンを持って立つ

2. 話を聞く

3. とにかく図を書く 時にモデルが書けない場合は図解で書く

4. 客の話を繰り返しながら図を説明する

5. 「そんなんじゃない」と言われる

6. ２に戻る

36

【技】物語

• 議論が止まる時には何か登場人物をイメージして、生活を語ってみる。

• 登場人物は実在していれば尚よい • Aさんが会社に来て最初にxxして、次にxxする…

この時、人は何に興味を示すのか？

37

共通認識の抽象度に気を付ける

• 「抽象のはしご」による思考

• 抽象度を上げて話をして始めて「性質や共通点」が分かる、見えてくる

• 話す相手によって抽象度を行き来して認識を合わせることが重要 （例：クラス図 ⇔ オブジェクト図）

「ベッシーは 牝牛である」 牝牛

家畜

資産

富

経営層

現場

モデリングを通した「場」の形成

• 「場」を形成するために情報としての「モデル」を中心に置き、対話の結果を可視化する

• 『場の理論とマネジメント』伊丹敬之 • アジェンダ

• 解釈コード

• 情報キャリアー

• 連帯欲求

38

目的

場

39

【技】モデルの揺さぶり

• 議論が活性化しないとき、決まったモデルが納得いかないとき、わざと揺るがしてみよう。

• 重要なもの、重要じゃないものを真ん中に書いたり、大きく書いたり、ハートだったり…

• 今のモデルを破壊するシナリオの確認や解決できないような問題を取り上げて、モデルが壊れる可能性を示唆する

この時、人は何に興味を示すのか？

はぁと 重要

そうでもない

ライブモデリング

全体モデリング

コアモデリング

フィードバック モデリング

40

現場でのモデリング実用例

1. ライブモデリング

2. 全体モデリング

3. コアモデリング

4. フィードバックモデリング

全体モデリング

41

欲しいものは全体感（≒概念モデル）

開発者とユーザのユビキタスを作る

全体が見えることで得られるものは多い

1. 用語の理解・整理

2. サブシステムへの分解

3. コア（関心事）の抽出

アジャイル開発での問題点

• 「大きな泥団子」のまま進めてしまうことがある →分かっているつもりが大きな歪みとなって システムに打撃を与えてしまう

• 自分の領域は詳しいが他の領域は無関心 →情報が分断されて「全体」として「より良い」 やり方への糸口がない

• 動かないと分からない？ →動かせる具象レベルの世界で理解しようとして も時間が足らない。作ってしまった後で、しか 学べないのでは、もったいない。 人の認識力はもっと深い。

42

43

モデルを使用した学習

• 言葉だけでは理解できない →業務をシステムに親和性のあるモデルで表現 することで業務を視覚的に学ぶことができる

• 言葉だけでは感じられない →言葉でしか存在しないものをモデルで可視化 することで業務に触れて動かすことができる

イメージ

44

①全体を描画

②領域の分割

③各領域の詳細化 シナリオ毎の用語表現

④領域間の共通概念の明確化

• クラス図 • 属性はKeyとなるもののみ

• 継承や集約、コンポジションは積極利用

• 関連の多重度は記述

• ノート重要

• オブジェクト図 • この抽象度だと難しいが必要に応じて

45

使うモデル

46

全体感

• 関連を持った用語集 →業務の言葉を明らかにしつつ、 言葉の関連に注目する。 （抽象度をあわせる。関連を見出す）

• 問題領域ごとの分割 →用語を使われる業務毎に分割する。

• コンテクスト境界 →業務領域によって同音異義語や同義語 があり、その存在を明確にする

• （ムダなもの判別）秘密だよ…

47

【技】A3モデリング

• 「最初のモデルは一番よくないモデルである」 • A3用紙でまとめられるくらいにしといた方が良い

• 電子化すると（余計な）細部が気になる

• 保存されていると覚えていなくていいと思えてしまう安心感へのアンチテーゼ

• ホワイトボードのような揮発性の高いものは無くなるべきだし、そもそも忘れてしまうようなモデルは要らないと割り切って考えています（笑） ＝ A3用紙分の情報なら書くのに時間不要

ライブモデリング

全体モデリング

コアモデリング

フィードバック モデリング

48

現場でのモデリング実用例

1. ライブモデリング

2. 全体モデリング

3. コアモデリング

4. フィードバックモデリング

コアモデリング

49

コアに対してシナリオを深掘りする （前提：全体観が共有されている）

コアが崩れると全体が崩れるので先に認識を合わせて合意しておく

50

モデリングへの覚悟

Red pill or Blue pill

アジャイル開発での問題点

• 動けばいいのだろうか？

• より良いものとはなんだろうか？

ここまで話した内容は抽象的に見れば、よくある システム開発方法論である。 別にアジャイルとかモデリングとか言わなくても終着点としての違いはあまり無いと思っている。

しかし、モデルを使った開発には意味がある。 モデルを使用して得たいものがある。

51

必要なのは Aha!!

52

目的と解決策

• 目的と解決策を分けて考える

• トップダウンアプローチ

○ ユーザのシステムへの要求から考える

○ 目的がはっきりすると解決策も出しやすい

✕ ただ目的は最初から分かる訳ではない

• ボトムアップアプローチ

○ 要素間の性質から上位概念を探す

○ 必要な要素は簡単に集まる

✕ 上位概念まで昇華することは難しい

53

視座・視点・視野

• 視座：モデルをどの立場から見るか

• 視点：モデルをどのように見るか

• 視野：モデルに表現する範囲はどこまでか

54

視点

視野

視座

視座

モデリングを実践して気付く点

• 作る対象の目的と価値

• 目的や前提を明らかにする

• 特に視座の部分

• モデリングする範囲を合意する

• どの視点の話をしているのか？

• 関心事は何で、どこまでコストを掛けるのか？ • 説明責任は開発者

• 設計のメリットとデメリットを示す

• 見ることができる範囲は見ておく

55

イメージ

56

①中心となる概念の深掘り 用語にはない関連や

意味・責務の抽出・発見

②シナリオ↔モデル ※繰り返し重要

• クラス図

• 状態遷移図

• オブジェクト図 • ユーザーはこのレベルで話すので特に重要

• シーケンス図

※基本的にこのレベルまで来ると私の現場ではクラス図のみを メンテナンスしています。

他の図法はあくまで実装するために用意していて、ソースが 書けると破棄してます。

電子化したくないくらい書き直します。。。

57

使うモデル

設計の深淵→デザイン問答

58

すべてのモノの形や仕組みには理由がある 画像引用：デザイン問答 http://www.nhk.or.jp/design-ah/design-mondou/

伝えるのは「質」の話

• パタンを見出すこと →モノゴトの性質や特性

59 http://blog-imgs-47-origin.fc2.com/i/t/o/itokaya/IMG_5160-horz.jpg

［入口での転換（112）］より

<より大きなパタンとの結合>

…どんな建物や複合建物の場合でも、すでにその主入口の大まかな位置は分かっている－［大きな門口（53）］から敷地への門、［見分けやすい入口の集まり（102）］から各建物への玄関、そして玄関。いずれにしろ、入口は「外部」－公的世界－からさほど公的でない内部世界への転換をつくり出す。

モデルは捨像 この世の森羅万象は表せない。

しかし、「パタン」を見出すことで「木を見ながら森を見ることができる」

Ex) 門

60 http://fashionjp.net/creatorsblog/fujita/2010/08/post-89.html

61

【技】オブジェクト寸劇

• 責務が不明なとき、個人個人にオブジェクトの役を割り当てて劇をしよう。

• 演者たちにとあるinputが与えられたとき、どのように協力してoutputを出すのか考えてみる。

注文

商品 ユーザ

【技】3分クッキング

• コアモデリングが進むとその場で考えるライブモデリングは厳しくなる場面が出てくる →ある程度は分析、想定を立ててモデルを 作って持っていく方が良い

• 予想できなかったことを特に深掘り

• 「ない」ことを確認

• fragileにしない

62

事前にxx分ほど 煮込んだモデルは

こちらです

ライブモデリング

全体モデリング

コアモデリング

フィードバック モデリング

63

現場でのモデリング実用例

1. ライブモデリング

2. 全体モデリング

3. コアモデリング

4. フィードバックモデリング

フィードバックモデリング

64

ソースコードや動くソフトウェアで学ぶ

コアは一発で理解・実装できない

学んだことをモデルやシナリオへフィードバックして洗練する

65

実装して気付く学びのループ

実装からの学び

• クラス間の連携がイマイチ • 責務分割がキレイにいかない

• テストコードが複雑 • Mockだらけで関心事が多過ぎる

ユビキタスから得られる知識が解決の糸口

→ 気付きを設計に取り込むと綺麗に

66

実装 テスト

別実装

別実装

別実装

実装

実装

実装 Client

より良い設計

新しいシナリオ

価値の判別

設計は重要:XPとモデリング

アジャイルモデリング by Scott Ambler ❝モデリングはXPの1つの要素である❞

❝リファクタリングとテストファースト開発というXPのプラクティスは、一般的に従来型のモデリングプロセスに結び付けられている「きれいな設計を促す」「コードを書く前に設計をよく考える」という２つの重要な目的を達成するために役に立ちます❞

67

アジャイルモデリング XPと統一プロセスを補完するプラクティス 第16章、第17章 http://www.amazon.co.jp/dp/4798102636

BigDesignUpFront

“論点となるのは、 設計をするかどうかではなく 設計をいつするか／どのようにするか だけである”

• LDUF／ENUF 設計の戦略と設計のシンプリシティ • 対象者に適している

• 情報が伝わりやすい

• うまく分割されている

• 最小限である エクストリームプログラミング 第14章 設計：時間の重要性

68

変化に適応する

変更のコストを一定に保つ

69

従来開発

XP開発

時間

コスト

書籍：エクストリーム・プログラミング ソフトウェア開発の究極の手法 P.23 図３ 変更のコストは時間とともに劇的に上がらないことがある

How Do We Know When We Are Done?

70

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

受け入れられる

最低限を素早くクリアする

まじめと本気

• プロダクトの生まれから終わりまでを考える

• 「本気」になる必要がある人は全員集合！ 問い「プロダクトリリースまでに必要な人は 全員チームの一員であるか？」

71 https://www.slideshare.net/kawaguti/jikkan-kudo

小さくそして速く 1. シナリオやストーリーを探索する（理解）

2. モデルを小さく作る（発見）

3. モデルをコードにする（実現）

4. シナリオを実行する（検証）

5. 動くコードからフィードバックを得て、 小さくイテレーティブに開発することで

学んでいける

72

書籍：IMPACT MAPPING P28-29 反復デリバリによる改良

ライブモデリング

全体モデリング

コアモデリング

フィードバック モデリング

73

現場でのモデリング実用例（まとめ）

1. ライブモデリング

2. 全体モデリング

3. コアモデリング

4. フィードバックモデリング

問題領域を分割する

74

①全体を描画

②領域の分割

④領域間の共通概念の明確化

③各領域の詳細化 シナリオ毎の用語表現

コアを深掘りする

75

②シナリオ↔モデル ※繰り返し重要

①中心となる概念の深掘り 用語にはない関連や

意味・責務の抽出・発見

76

学びのループを回す

77

「場」の中心にモデルを置く

目的

場

ヒト

ドキュメント

コード

78

Models stay alive!!

最後に一言

• 全て「対話」とザックリ切ってはいけない

• 「Value」「Feesible」「Usable」の判断は、確かな知識と実践の上に成り立っている

• 先人の築いた知恵は通じない／不要になったわけではなく、「当たり前」になっているということを忘れてはいけない！

• その上で、自分たちの答えは自分たちで見つけなければならない。隣の芝は常に青い！

79

ライブモデリング

全体モデリング

コアモデリング

フィードバック モデリング

今日話したこと

活用事例

1. ライブモデリング

2. 全体モデリング

3. コアモデリング

4. フィードバックモデリング

80

以上！ はじめに 今直面する問題 アジャイルにすべきこと