アジャイルにモデリングは必要か

Transcript of "アジャイルにモデリングは必要か"

1. 1. アジャイルにモデリングは必要か 2015/7/23 株式会社ゼンアーキテクツ 岡 大勝 Is  “Modeling”  required  in  Agile? UMTPアジャイル開発事例セミナー 現場に学ぶ実践アジャイルモデリング
2. 2. ⾃自⼰己紹介 • 第⼀一勧銀情報システム（現：みずほ情報総研） • VOS3  COBOL＆MS-­‐Cプログラマ • ⽇日本ディジタルイクイップメント（⽇日本DEC） • 主に⽣生保・損保・銀⾏行行向けの資産運⽤用システムに携わる。 • Alpha  NT,  SQL  Server,  DECnet • ⽇日本ヒューレット・パッカード C&I-­‐Financial • ⾦金金融機関向けのシステムアーキテクチャ設計、開発プロセス設計、 運⽤用プロセス設計を⾏行行う。 • HP-­‐UX,  J2EE,  WebLogic,  Oracle  Database,  OO • ⽇日本ラショナルソフトウェア • 開発プロセス（RUP）およびオブジェクト指向分析設計⼿手法の導⼊入 コンサルティング。 • RUP,  Rose,  ClearCase,  Functional  Tester • ゼンアーキテクツ • 2003年年よりIT設計事務所として活動。お客さまのIT投資の最適化を ⽬目指し、アーキテクチャ中⼼心のプロセス改善を推進。 著作/翻訳 • 「要求」の基本原則（技術評論論社）2009 • 本当に使える開発プロセス（⽇日経BP社）2012 • ディシプリンド・アジャイル・デリバリー（翔泳社）2013 岡 ⼤大勝 株式会社ゼンアーキテクツ CEO/チーフアーキテクト プロフィール @okahiromasa
3. 3. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. UMLは、いまどうなのか？ •共通⾔言語として使えて当たり前。 •「読めない」「書けない」では話にならない。 •SWEBOKv3の5つのKAで“前提” • 要求・設計・実装・プロセス・モデルと⼿手法 3 http://www.computer.org/web/swebok
4. 4. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 1.  アジャイルでの「モデル」を 整理理する 2.  アジャイルプロジェクトで モデルを活⽤用する
5. 5. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルにモデリングは必要か？ •現実には、いつも、どんなアジャイルプロジェク トでも⾏行行われている。 • UMLだけがモデルではない • 「モデル」と「⽂文書」は異異なる • 精緻で正確でビジュアルに描かれたものだけが モデルではない • 意識識していない活動を含む アジャイルに限らず、知的⽣生産活動には モデリングは⽋欠かせない
6. 6. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルは組織活動を変⾰革した 予測型 （計画駆動） 適応型 （変化駆動/アジャイル） ジャストイン タイム Just-In-Time 成果物駆動 Document Driven ■ 計画管理理/要求管理理 ■ 開発⼯工程 詳しくは「企業システムにアジャイルは必要か」スライドを参照 http://www.slideshare.net/hiromasaoka/agile-­‐is-­‐really-­‐need-­‐to-­‐enterprise-­‐system-­‐49711192
7. 7. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 計画できることは、計画して実施する • 「正しい」ことが分かっている • よほど⼤大きな問題が発⽣生しない限り“うまくいく” • 事業者は「必要な時期」に「必要なもの」が⼿手に⼊入れば良良い。 • 定型反復復業務 • 確⽴立立された⼿手順 予測型 （計画駆動） Lv.1 確実な未来 Lv.2 選択的未来 PMBOK 5th
8. 8. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 計画できないことは、確認しながら進む • 何が「正しい」のか判断できない • 正しいものが変化する • 機能 • 技術 • ビジネス、マーケット • 変化への継続的な対応 • 「要求の変化」と「優先順位の変化」 • 要求の変化＝反復復型による継続的フィードバック • 優先順位の変化＝バックログによる動的要求管理理 反復型 Lv.3 一定の幅 適応型 （変化駆動/アジャイル） PMBOK 5th
9. 9. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. ジャストインタイム（JIT） • 作業の管理理を、テスト結果によって⾏行行う • 中間成果物は「それが必要な場合に」作成する 9 要求 分析 実装 テスト 要求 分析 実装 テスト 要求 分析 テスト 設計 実装設計 設計 チェック ポイント 要求 分析 設計 実装 テスト チェック ポイント チェック ポイント チェック ポイント チェック ポイント チェック ポイント タスクそのものを「必要に応じて」実施 チェック ポイント チェック ポイント 成果物駆動 ジャストインタイム データ 設計 テストデータ 作成
10. 10. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 反復 Iterative ジャストイン タイム Just-In-Time 適応型 Adaptive Lifecycle アジャイルの⾻骨格 アジャイルは、成果物や文書に影響されない つまり「何でもいい」
11. 11. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 反復 Iterative ジャストイン タイム Just-In-Time 適応型 Adaptive Lifecycle 価値駆動 バックログ管理 コードの 共同所有 リファクタリング 自動回帰テスト Living Document 安定した アーキテクチャ 継続的統合/ デリバリー アーキテクチャ スパイク ペアプログラミング BDD カンバン イテレーショ ン計画 マルチファンクショナル エンジニア（多能工） リスク駆動 タイムボックス ベロシティ ふりかえり Pull Request インセプション 日次ミーティング 100%専任バーンダウン チャート 自己組織的 チーム リスクリスト アジャイルは、成果物に依存しないよう うまく設計されている ビジョンドキュメント イテレーション デモ ※ゼンアーキテクツがお客さまの現場で実践している主要なプラクティスを表したものです
12. 12. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 「成果物」の意味が変わった 成果物駆動 ジャストインタイム 「次⼯工程の⼊入⼒力力」 → 「必要に応じて作るもの」 要求モデル 分析モデル 設計モデル 実装モデル コード コード 要求 ドキュメント 成果物を作成する活動（＝ドキュメンテー ション）は、成果物駆動型の主たる構造 コード不不要の世界を⽬目指していた • MDA/MDD • Executable  UML ジャストインタイムでは「ドキュメ ントはコードを補うもの」 「Collective  Code  Ownership  =   コードの共同所有」が根源的価値 • 開発⾔言語の抽象度度の⾼高まり • DSL
13. 13. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 何が起こったか •「⽂文書化」の⽬目的が変わった 成果物駆動 • 「ドキュメントの連続性」でプロジェクトを構築 • 検討し残しや書き残しのないように、すべきことを 「ドキュメント記載項⽬目」で表現する JIT • 「動作するコードの積み重ね」でプロジェクトを構築 • 事前に明らかにすべきことは確認する。 必要に応じて、適切切な⽅方法で伝える。
14. 14. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 「アジャイルモデリング」 • Agile  Modeling • 2002年年：英語版 • 2003年年：⽇日本語版 • スコット.W.アンブラー 著 • 他の著作 • Enterprise  Unified  Process • データベースリファクタリング • ディシプリンド・アジャイル・デリバリー • モデリングを“アジャイル”のコンテキス トに適⽤用するためのガイドブック。 • 「ソフトウェア開発プロジェクトで適⽤用でき る、効果的で⼿手軽にソフトウェアをモデリン グするための価値、原則、およびプラクティ スを集めたもの」「アジャイルなモデルは完 璧である必要はない」 14 http://www.ogis-­‐ri.co.jp/otc/swec/process/am-­‐res/am/
15. 15. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 「メモ書き」と「清書」の分離離 •成果物駆動では、メモ書きは捨てるもの • ⼤大事なことは「正式なドキュメント」として記載 •JITでは、「メモ書き」の⽐比率率率が⾼高まる • 本当にメモ書きを捨てていいのか？ • ⼤大事なことは、どこに書くのか？ メモ書き 清書
16. 16. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. モデルとは何か 「問題の1つ以上の側⾯面、その問題に対して考えられる 解決策を抽象的に記述したもの。図や⽂文章で⽰示される」 • 視覚的モデル • フローチャート,  状態マシン,  ER図,  DFD,  OMT,  Booch法,   UML(ユースケース図,  クラス図,  アクティビティ図,..),  BPMN,   Value  Stream  Map,  Lean  Canvas,  ユーザーストーリーマッ プ,  任意のアーキテクチャ図 • 任意のモデル • 要求⼀一覧,  機能⼀一覧,  業務ルール,  計算ロジック,  ユーザース トーリー,  CRCカード,インタフェース仕様,  ポンチ絵,  サンプ ルコード,  任意のメモ書き 「アジャイルモデリング」での定義
17. 17. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. モデル（一時モデル） モデルと⽂文書とモデリングの関係 文書（保管用モデル） 清書 下書き モデリングモデリング
18. 18. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. モデリングという活動 1. ありのままを表現する (これを“分析”と呼ぶ) 2. 作りたいもの(なりたい姿)を表現する (これを“設計”と呼ぶ) 分析 設計
19. 19. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 分析と設計 文書 モデル 分析モデル 設計モデル 分析 設計
20. 20. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. モデリングは多⾯面的である • 例例えば要求モデリング • プロダクトバックログに積まれたユーザーストーリー (ストーリー⼀一覧)だけで、要求が適切切に表現できるだ ろうか。 • 複数の軸で視覚的に分類して俯瞰したい • ユーザーストーリーマッピング • アクターを軸にグルーピングして俯瞰したい • ユースケース図で全体を把握 • 業務にマッピングして俯瞰したい • ビジネスプロセスマッピング • 全ての要求の優先順位を知りたい • プロダクトバックログ 自然に、複数のモデルを併用しているはず
21. 21. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 【AM】なぜドキュメントを作成するのか 1. プロジェクトの利利害関係者が要求しているため 2. 取り決めモデルを定義するため • インターフェイスを含むシステム間の相互作⽤用 3. 外部グループとのコミュニケーションをサポートするため • 書いたことは誤解されやすいが、補助的なメカニズムとしては優れている • 「話すためにモデリングしよう」 4. 何かについてじっくり考えるため • 「理理解するためにモデリングしよう」 【アジャイルモデリング 14.1  より引⽤用】 “モデリングは後続⼯工程のために⾏行行うものではない”
22. 22. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. ⽤用語を整理理する ü⽂文書（Document） • ⻑⾧長期間維持できる⽅方法で情報を伝える⽬目的を持つ。 üモデル（Model） • 問題の1つ以上の側⾯面、その問題に対して考えられる解決策を抽象的 に記述したもの。図や⽂文章で⽰示される。 üドキュメント（Documentation） • 他の⼈人のためにシステムについて記述した永続情報。⽂文書とコードの コメント両⽅方を含む。 üコード（Source  Code） • コンピュータシステムに対する⼀一連の命令令と、命令令について記述した コメント。 ü成果物（Artifact） • 納品物または⽣生産した製品。 【アジャイルモデリングでの定義】
23. 23. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. UMLモデルの位置づけ 文書 （保管用モデル） モデル （一時モデル） UMLモデル ER モデル BPMN 業務 フロー 要求 一覧 メモ書き、一時的 公開、永続的
24. 24. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルなモデルのライフサイクル 思いつき 思いつきを モデル化する 一時モデル 残す 保管用モデル バージョン 管理する 更新する更新する 一時的なものにする 廃棄する 捨てる 廃棄する アジャイルモデリング 図14.2より
25. 25. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. モデル、⽂文書、コード、ドキュメント モデル Model 文書 Document コード Code ドキュメント Documentation なる可能性がある。 または一部に含まれる （※清書） である 含む 記述する 可能性がある （※コメント） 記述する アジャイルモデリング 図14.1より
26. 26. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 1.  アジャイルでの「モデル」を 整理理する 2.  アジャイルプロジェクトで モデルを活⽤用する
27. 27. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルプロジェクトの⼀一⽣生 2つの期間 •「安定するまで」 •「安定してから」 よく耳にするのは「安定してから」の話 Image  source  by  Wikipedia
28. 28. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルは「安定するまで」が難しい
29. 29. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイル プロジェクト イニシエーション 29 • いきなり書けと⾔言われても • どんな技術を使うのか • いつ、何ができるのか • 誰が、何をすればいいのか • だれが決めるのか・・・ Agile  Project  Initiation で 安定させる
30. 30. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルの⽴立立ち上げを安定させる • アジャイル プロジェクト イニシエーション • Agile Project  Initiation • 安定したアジャイルライフサイクルへの助⾛走 ØIteration Zero • XP ØSprint  0 • Scrum Ø⽅方向付けフェーズ • ディシプリンド・アジャイル・デリバリー 見積りのベースライン づくり 安定した継続的活動 の確立
31. 31. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 何を安定させるのか アジャイルプロジェクトを安定させるための３つの観点 1. 要求を安定させる • たくさんの“やりたいこと”を、観点を合わせ、優先順位順に並べ、スコー プの⽬目星をつける • プロダクトバックログ：安定した⼊入⼒力力 2. アーキテクチャを安定させる • チームの試⾏行行錯誤を最⼩小化し、誰もが安定して開発（ジャストインタイ ム）が進められるよう、技術の組み合わせや書き⽅方のパターンを共有する • アーキテクチャドキュメント：安定した開発活動 3. 計画を安定させる • 個々の要求の実現コストが予測できる（⾒見見積基礎値）ようになってくると、 リリース時の要求実現状況のぶれ幅が⼩小さくなる • リリース計画：安定した計画と実績 31
32. 32. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. ディシプリンド・アジャイル・デリバリー（DAD） 32 引⽤用：ディシプリンド・アジャイル・デリバリー(2013/翔泳社)
33. 33. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. DADでのAPI（Agile  Project  Initiation）の位置 ＝アジャイルプロジェクトの⽴立立ち上げ 33 引⽤用：ディシプリンド・アジャイル・デリバリー(2013/翔泳社) アジャイル プロジェクト イニシエーション：API
34. 34. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. APIで⾏行行うべき３種類の活動 34 引⽤用：ディシプリンド・アジャイル・デリバリー(2013/翔泳社) 初期の要求モデリング 初期のリリース計画 初期のアーキテクチャモデリング
35. 35. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. DAD⽅方向付けフェーズのモデリング • 初期の要求モデリング • IRM：Initial  Requirement  Modeling • 初期のアーキテクチャモデリング • IAM：Initial  Architecture  Modeling • 初期のリリース計画（IRP） • IRP：Initial  Release  Planning • →またの機会に紹介します • ⽬目的は「Scrumを安定して運⽤用する」 • 安定したプロダクトバックログ運⽤用 • 安定したスプリント計画 • 安定した実装 • 安定したリリース • 安定した⾒見見積り アーキテクチャ ストー リー ストー リー ストー リー プロダクトバックログ 実装
36. 36. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルプロジェクト⽴立立ち上げ後の モデリング活動の推移 36 I1 I2 C1 C2 C3 C4 Inception (Agile Project Initiation) Construction (Stabled Agile Project) 要求モデリング アーキテクチャモデリング 注）本チャートはゼンアーキテクツ実施の事例例による推測です モデリング活動 多い 少ない
37. 37. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルプロジェクト⽴立立ち上げ後の モデリング活動の推移 37 I1 I2 C1 C2 C3 C4 Inception (Agile Project Initiation : API) Construction (Stabled Agile Project) 要求モデリング アーキテクチャモデリング 注）本チャートはゼンアーキテクツ実施の事例例による推測です コーディング アジャイルではリソース総量量は変わらない。 APIで”コーディングを最⼤大化できる環境をつくる”
38. 38. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルプロジェクト⽴立立ち上げ後の モデリング活動の推移 38 I1 I2 C1 C2 C3 C4 Inception (Agile Project Initiation) Construction (Stabled Agile Project) ビジョン ドキュメント 採⽤用技術選定 要求モデリング アーキテクチャモデリング ユーザー ストーリー テクニカル ストーリー 業務フロー UIプロトタイプ アーキテクチャ 設計 ATAMユーティ リティツリー 主要技術の PoC 主要な API設計 E2E 実装サンプル 次反復復⽤用 API設計 新たな実装 技術のPoC 新APIの 実装サンプル UIをアーキテク チャに適合 ユーザー ストーリー 実装⽅方式確認 初期の データモデル データモデルの 拡張 外部接続の PoC 外部接続の 実装サンプル テスト アーキテクチャ設計 プロジェクト ライフサイクル ・プロダクトバックログ ・Living Document ・ソースコードリポジトリ ユーザー ストーリー 実装⽅方式確認 注）本チャートはゼンアーキテクツ実施の事例例による推測です ・プロダクトバックログ運⽤用開始 ・アーキテクチャドキュメント初版リリース ・基本的なユーザーストーリー（US）を実装可能 ・基本的なUSが動作 ・補助的なユーザーストーリーを実装可能 ・補助的なUSも動作 ・別の補助的なユーザーストーリーを実装可能
39. 39. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 初期の要求モデリング To-­‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装方 式 初期のアーキ テクチャ アーキテクチャ ドキュメント 主要なストーリーを実装 （US、TS） 実現したい業務を ストーリーとして切り出して登録 受け入れられた 実装済ストーリーを、To-­‐Beにフィードバック SP 実装実績から 見積基礎値を設定 方式、パターン サンプルコード ２W 優先順位の高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ（業務カテゴリをエピックで 分類すると識別しやすい） ソース 管理 ビルド・デプロイ・テスト プロダクトバックログ 見積基礎値の フィードバック ドキュメントの追記・更新 Living Document イテレーション計画 IRM：初期の要求モデリング 自動回帰テスト 受入テスト リリース判定 Ops リリース 本番運用 インシデント管理 修正依頼 ユーザ 運用担当者
40. 40. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. IRMで利利⽤用可能なモデル（DADより） • ビジネスプロセス図 • データフロー図 • ビジネスルール • 制約事項 • コンテキスト図 • ドメインモデル • エピック • 機能⼀一覧 • フローチャート • マインドマップ • ⾮非機能要求（NFR） • ペルソナ • 要求事項 • UIフロー図 • UIプロトタイプ • UI仕様書 • UMLアクティビティ図 • UMLユースケース図 • ユースケース仕様書 • 利利⽤用シナリオ • 状態遷移図 • ユーザーストーリー • バリューストリームマップ 23種類のモデルを“適切切に組み合わせて”活⽤用し、 初期の要求モデルを構築する
41. 41. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. IRMで利利⽤用可能なモデル（DADより） • ビジネスプロセス図 • データフロー図 • ビジネスルール • 制約事項 • コンテキスト図 • ドメインモデル • エピック • 機能⼀一覧 • フローチャート • マインドマップ • ⾮非機能要求（NFR） • ペルソナ • 要求事項 • UIフロー図 • UIプロトタイプ • UI仕様書 • UMLアクティビティ図 • UMLユースケース図 • ユースケース仕様書 • 利利⽤用シナリオ • 状態遷移図 • ユーザーストーリー • バリューストリームマップ ユーザーストーリーマップ NEW   でも23種類にはこだわらない。 ⽬目の前の要求を適切切に扱うために、”適切切な道具”でモデリングする。 ATAMユーティリティツリー
42. 42. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. DAD新刊での ユーザーストーリーマップ活⽤用例例 42 DAD新刊：Introduction   to  Disciplined  Agile  Delivery ユーザーストーリーマップ NEW  
43. 43. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 【事例例】企業システム刷新時のIRM •新技術による次世代製造管理理システムの開発 43 プロダクトバックログ • 既存システム • 新システムへの 要求事項 インプット • UMLユースケース図 • ユースケースシナリオ （一部の主要UC） • UIプロトタイプ（一部） • ビジネスルール IRM • ユーザーストーリー （ユースケース名） 規模が大きく（数百機能）、既存システムが存在するため、UMLユースケース図で アクター観点で全体像の整理。粒度調整のため一部をシナリオ化。 ユースケース名をストーリーとしてプロダクトバックログに登録し、イテレーション内 で必要に応じて（JITで）詳細化する。
44. 44. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 初期のアーキテクチャ モデリング To-­‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装方 式 初期のアーキ テクチャ アーキテクチャ ドキュメント 主要なストーリーを実装 （US、TS） 実現したい業務を ストーリーとして切り出して登録 受け入れられた 実装済ストーリーを、To-­‐Beにフィードバック SP 実装実績から 見積基礎値を設定 方式、パターン サンプルコード ２W 優先順位の高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ（業務カテゴリをエピックで 分類すると識別しやすい） ソース 管理 ビルド・デプロイ・テスト プロダクトバックログ 見積基礎値の フィードバック ドキュメントの追記・更新 Living Document イテレーション計画 IAM：初期のアーキテクチャモデリング 自動回帰テスト 受入テスト リリース判定 Ops リリース 本番運用 インシデント管理 修正依頼 ユーザ 運用担当者
45. 45. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. IAMが早期安定化のカギ • 適切切なアーキテクチャ • 偶発的アーキテクチャ→ 創発的アーキテクチャ • 適切切なストーリー実装 • INVESTなストーリーをそのままシンプルに実装できる • 抽象度度の⾼高いドメインレベルAPI • ちょうど良良いバランスを「作る」 ストーリー実装 アーキテクチャ ストーリー実装 アーキテクチャ ガチガチ、 柔軟性なし 実装コストが⾼高す ぎ、 メンテ困難 バランス
46. 46. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 適切切なアーキテクチャをつくる 1. アーキテクチャ要求を識識別・収集 • 品質特性シナリオ（主たる機能＋⾮非機能） • 品質モデル（ISO/IEC25010等）での網羅羅性検証 2. アーキテクチャ設計 • 利利⽤用可能かつ適切切な技術を組み合わせる • ⾃自⼰己検証（モデル、実装） 3. 客観的な妥当性検証 • 第三者によるアーキテクチャの妥当性検証（実現性、リスク、コ スト、選定技術が適切切性、ストーリーの実装しやすさ） • ATAM(Architecture   Trade-‐‑‒Off  Analysis)によるトレードオフ分 析等を活⽤用する アーキテクチャを後から⼤大きく改修するのは困難 アジャイルでも変わらない
47. 47. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. Architecture  Description • 4+1  View • 静的ビューをシナリオで「振る舞わせる」=  ⾃自⼰己検証モデル
48. 48. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アーキテクチャで ストーリーの実装を安定させる • 複雑さの隠蔽 • パターンの提供 • 新規性の最⼩小化 • ドメインの⾔言葉葉で実装したい（OOAD/DDD） • ”ユーザーストーリーがそのまま実装できるアーキテクチャ” • シンプルなコード • 結果「コードの共同所有」を促進 テクノロジ抽象化レイヤ ドメイン抽象化レイヤ プリミティブ技術 US US
49. 49. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アーキテクチャをどうやって伝えるのか • 「アーキテクチャ設計書」と「アーキテクチャ説明書」 • アーキテクチャ設計書（Architecture  Description）は、内部の構造、 振る舞い、根拠、保守の観点を⽰示す「設計書」 • アーキテクチャドキュメント（Architecture  Document）は、アーキテ クチャ（API）の使い⽅方やサンプルを⽰示す「説明書」 • 「しっかり書く」 or  「徐々に積み上げていく」 • 「安定」までの戦略略次第。最⻑⾧長6〜～8週。 • 傾向として • アーキテクチャドキュメントと「ストーリー増加に応じて徐々に」 • アーキテクチャ設計書は「主要なテクニカルストーリーが通ることを 確認できるところまで」 • “Living  Document” • Wikiプラットフォーム • 「必要に応じて、必要なことを、伝える」
50. 50. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 【事例例】ソフトウェア製品開発でのIAM •新分野でのソフトウェア製品の初期開発 50 • 新システムへの要 求事項 （機能・非機能が 混在） インプット • アーキテクチャスタック図 • 論理クラス図（全体構造） • ATAMユーティリティツリー • 品質特性シナリオ • アプローチ分析シート • 論理クラス図 • 物理クラス図 • 物理シーケンス図 • サンプル実装（実現性、性能 評価用） IAM（4反復） 新分野における未知の製品開発。 要求事項の優先度と非機能のトレードオフを明確化するため、ATAMユーティリティツリーを 活用。妥当性の客観的評価のためアプローチ分析シートを用いて机上・実証両面で検証。 性能・保守性・拡張性・ストーリー実装性でバランスのとれたアーキテクチャを構築。 初期の アーキテクチャ アーキテクチャ ドキュメント API定義
51. 51. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 「安定してから」のモデリング • JITモデリング • 最⼩小で良良い • 「コードの共同所有」と、 それを⽀支えるアーキテクチャの安定 • “新しいこと”を扱うときに、軽く書く • 新しいテーブル • 新しい処理理⽅方式 • 新しいモジュール • 新しいタイプの要求 Image  source  by  Wikipedia
52. 52. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. スクラムの基本的な進め⽅方 52
53. 53. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. ⾦金金融機関中規模チームでのDAD適⽤用例例 • ツール • JIRA • Confluence • Bitbucket • Jenkins • SWAT • アーキテクチャ • SPA/HTML5/knockout.js • MSA/PHP/Laravel/MySQL • RHEL • プロセス • Disciplined  Agile  Delivery 53 http://www.smartekworks.com/ http://www.atlassian.com/ ツール Tools プロセス Process アーキ テクチャ Architecture
54. 54. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. PO (Product  Owner) システム部 Web企画部 デザイナー AO (Architecture  Owner) アーキテクチャ 担当デベロッパー UI担当デベロッパー プロダクト バックログ ドキュメント スプリント/タスク （計画・実績） ソース リポジトリ お客様 テスト 環境 TL (Team  Leader) <Scrum  Master> プロジェクト リリース 体制
55. 55. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. PO プロダクト バックログ <JIRA> DADの開発保守サイクル 課題 要望 制約 追加/ステータス変更/ 属性変更 スプリント 1 スプリント 2 スプリント 3 スプリント 4 スケジュール <JIRA> マイルストーン設定 仕様 優先度 タスク化して スプリントに割り当て 作業量 見積もり 将来 像 実装 コスト 適用 技術 実装方式・規約・ ルール等 <Confluence> アーキテクチャドキュメント サンプル コード サンプル コード 実装方式 （パターン）の 割り当て 協働 協働 協働 AO メンバーの 適性・熟練度 の把握 リポジトリ <Bitbucket> デザイナー TL 協働 サンプル コード デザイン実装方式の調整 デザイン案 HTML Web企画部 デザイン案 コミット アーキテクチャ担当Dev UI担当Dev コミット 自動テスト 作成 参照 把握 2W 2W 2W 2W ・バックログ作成、優先順位設定 ・マイルストーン設定 ・協働時の検討・判断 ・タスク設定、アサイン ・実装方式の検討と定義 ・作業量見積もり ・実装方式の習熟 ・成果物作成 ・テストの定義と実施 ・テクニカルバックログ ・PoC・サンプル作成
56. 56. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 【AM】アジャイル ドキュメンテーション戦略略 ü動かない仕様よりも実⾏行行可能な仕様を選ぶ üドキュメントを要求として扱う üドキュメントは情報を整理理する場であり、 思索索にふける場ではない ü簡潔さを保つ üドキュメントは、あなたの置かれた状況に合わせて⼗十分なもの を作ればよい ü情報を捕まえる「よりよいやり⽅方」を懸命になって探しなさい üドキュメントを書く正当な理理由を検討しなさい üプロジェクトの利利害関係者がそれを求めた üAPIを定義する ü外部のグループとコミュニケーションを円滑滑にする
57. 57. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 【AM】現実に「UMLをどう使うか」 1. UMLをモデリングの中核として使う(もちろん全てではない) 2. 表記法の重要な部分だけを採⽤用する (全て使おうとしない。重要な20%から取りかかる) 3. すべての開発者にUMLの教育を⾏行行う (コミュニケーションのための当たり前の道具) 【アジャイルモデリング 15.5   より引⽤用】 UML推進者が注意すべきこと 「〜～にUMLをどう適⽤用するか」ではなく「ここで〜～をモデリング (分析や設計)を活⽤用するにはどうすればいいか」と考えた⽅方が良良い。 つまり「アジャイルにUMLをどう適⽤用するか」ではなく 「アジャイルでどうモデリングを活⽤用するか (そのうちのどこで UMLが適切切なのか)」と考えていきたい。
58. 58. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 58 zenarchitects.co.jp facebook.com/zenarchitects