enterprise agile lean modeling
34 likes23,515 views
「エンタープライズアジャイル開発のリーンモデリング」 by 山岸理事 on 5/28, 2014 要求開発アライアンス定例
![要求開発とアジャイル開発の究極コラボ
14
スプリント
要求
要求
一定のリズムで継続的にアウトプットを出し続ける工房
非同期バッファ
リリース
新たな分業の始まりか
スプリント
スプリント
スプリント
スプリント
リリース
リリース
リリース
リリース
・ ・ ・ ・
個別システムを超えたポートフォリオ
マネジメント
外注業者購買担当者設計担当者営業担当者顧客
見積依頼書を作成
する
見積依頼
の送付
見積依頼
の受領
見積依頼の確認
引合案件の登録
社内見積依頼の
作成
設計する
見積条件を検討す
る
外注業者の選定を
する
見積依頼書を作成
する
見積依頼
の送付
見積依頼
を受領す
る
見積を実施する
見積書の
送付
見積書を
受領
見積内容を評価し
て候補を絞り込む
見積計算を行う
見積書を作成する
見積書の
送付
見積書の
受領
見積回答の評価
受注フローへ
購入中止
の連絡
購入中止
の連絡を
受ける
失注の登録を行う
[新規引合の場合]
[再見積の場合]
[外注委託加工が必要な場合]
[再見積依頼]
[発注]
[購入中止]
要求開発
プロダクト
バックログ
プロダクト
オーナー](https://image.slidesharecdn.com/extract-140605002355-phpapp01/85/enterprise-agile-lean-modeling-14-320.jpg)
enterprise agile lean modeling
- 2. 関心の変遷 ソフトウエアエンジニアリングのビジネスの中で 2 いかにちゃんと作るか • プログラム言語、アルゴリズム • システムアーキテクチャ、システム構成 • 開発プロセス、開発環境 いかに役に立つものを作るか • ビジネスモデリング • 要求開発 • 業務とITの最適設計 いかにビジネス価値を継続的に高めるか • システム複合体としてのエンタープライズシステ ム・継続的リフォーム • プログラムマネジメント • ビジネスプレーヤーと開発者の協調開発 オージス総研（1989-‐2000） 米国オブジェクト指向調査 シリコンバレー駐在 オブジェクト指向ツール提携 日本ラショナル設立 オブジェクト指向での本格SI ウルシステムズ（2000-‐2004） UMLautフレームワーク構築 Javaによる基幹システム構築 ビジネスモデリング協議会設立 豆蔵（2004-‐2009） 要求開発アライアンス設立 enThology超上流プロセス メソドロジック（2009-‐） 継続的リフォーム エンタープライズアーキテクチャ メガバンクの標準化（モデル、プロセス）
- 3. ＩＴ戦略とプロジェクトの発生 現在のTo-‐Be IT 現在の 事業戦略 As-‐Is IT 将来のTo-‐Be IT 将来の 事業戦略 現在 XX年後 現実的目標のIT 現行システム 新規追加 機能的改修 時間軸 プロジェクト プロジェクト プロジェクト 改善 サーバ統合 セキュリティ強 化 クラウド適用 維持 保守切れ対応 OS変更 プロジェクト プロジェクト プロジェクト 破棄 事業戦略 への対応 現行IT人材 コスト削減 継続性確保 コンプライアン ス 育成 採用 パートナ戦略 必要IT人材 例えば３カ年計画 各プロジェクトが上位目的に基づいて企画されているか プログラムマネジメント視点とプロジェクトマネジメント視点 プロジェクト
- 4. モデリングとの出会い • 現状よりも一段広いスコープ（結果的には上位の視点） を意識する – 同じスコープ内でやっていると数年で頭打ちになる • 全体をとらえて、今の立ち位置を正しく理解する能力 – モデリング能力（空間認識力） • 全体把握と正確な共通認識 – 空中戦を地上戦に持ち込む • 一般化（抽象化）と具体化を切り分け、問題解決を図る – プロジェクト推進能力（段取り・シナリオを作る能力） • 仮説で作って、段階的（アジャイル的）に詳細化する • プロセスをモデリングする 4 モデリング力とプロジェクト推進力は根本的なスキル
- 5. 5 ソフトウエアシステム特有の難しさ • プロジェクトは、建築プロジェクトのアナロジーで語られがち・・・ • ソフトウエアシステムは複雑な系 – 対象が見えない – 段取りに決まり手がない – 目標は刻々変化する 対象が見えない 段取りが決まっていない モデリングで可視化 プロセスを定義する 繰返し型で開発する目標が刻々変化する 困難を克服するための特徴的アプローチ ソフトウエア開発上の歴史的なアプローチ
- 6. リーン（「これだけ」）モデリングの勧め • こんなに役に立つのに使われていない – どのぐらい役に立つかわかっていない – 使い方を間違っている – コストパフォーマンスをクリアする「これだけ」モデリング • アジャイルではモデリングは不要なのか – アジャイルにもタイプがある • ジャストアイデアと実装のコラボ – それでも言葉より手っ取り早くて正確に伝えるメモ的モデルは有効 • 複雑な企業システムをアジャイルのベロシティで – ちゃんと地図をもって走らないとあらぬ方向に 6 それぞれの場面に適したレベルの「これだけ」モデリングがある
- 7. ＵＭＬのダイヤグラム構成 • １３のダイヤグラムで構成（ただし、パッケージ図はクラス図の１種） • 大きくは静的モデル（構造図）と動的モデル（振る舞い図）に分類される 静的モデル 動的モデル スケッチとしてのUML 設計ドキュメントとしてのUML プログラム言語としてのUML
- 8. よく使う利用シーンとダイヤグラム 取り扱う ベースとなる 概要 ダイヤグラム ダイヤグラム ビジネスユースケース図 ユースケース図 特定業務領域について対象業務を棚卸し、業務スコープを明らかにする システムユースケース図 システムが提供するサービスをユーザ視点で示し、システムのスコープを明ら かにする 概念クラス図 クラス図 特定業務領域を構成する概念（エンティティ）を抽出し、それらの間の関係を明 らかにする 設計クラス図 オブジェクト指向言語を用いたソフトウエア開発の設計段階でクラス構成とク ラス間の関係を定義する データ設計図 リレーショナルデータベースを利用した永続化を前提にデータモデルを構築す る 業務フロー図 アクティビティ図 業務の処理手順を可視化し、システムとのやりとりを明らかにする 処理フロー図 システムの機能を実現する処理手順、ロジック、アルゴリズムを表現する。関 数やメソッドのプログラム設計を行う。 設計シーケンス図 シーケンス図 利用者とシステム間のやりとり、システム間の連携、システム内部ロジックとし てのモジュール間のやりとりなどを設計する
- 9. Bad Smell パターン • 生真面目にやりすぎ – １３種類のダイヤグラム – ほどというものを知らない（抽象度、詳細度や表記法へのこだ わり） – すべてをモデリングする（全部シーケンス図書くとか） – ソースコードと同程度の情報をもたせる • 難しいこと言い過ぎ – 国際語としての英語（スラングやネイティブな表現は通じない） – 抽象度を上げすぎて、具体的なイメージを超えてしまう • 何のためにモデリングをするのかはっきりした目的がない
- 10. モデリングの目的をはっきりさせる • 全貌の理解 • 詳細（複雑なもの）の理解 • 伝達 • 記録 • スケッチ • 設計書 • プログラム • 書き捨てる • 中間生成物として使う • 最終成果物として残す • 保守資料としてメンテナンスする 何を使うか どの程度書くか どう扱うか 目的に適う程度にスリムに おのずと程よさが決まる
- 12. スクラムによる開発の進め方 • ソフトウェアに要求される機能とその優先度を 製品バックログとして定める • プロダクト・バックログからスプリントで実装する べき目標（ スプリントゴール ）を選択する • スプリントゴールをより詳細なタスクに分解した スプリント・バックログを作成し, タスクの割り当 てを行う • スプリントの間, 毎日決まった場所及び時間で 開発メンバーが参加するデイリースクラムとい うミーティングを開催する • 1 回のスプリントが終了すると, スクラムレ ビューミーティングを開催し, 作成されたソフト ウェアを評価する • 次回のスプリントに備えてプロダクトバックログ の内容と優先度の見直しを行う COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED. 12 スプリント計画 ビジネス要 求 プロダクトバッ クログ設定 スプリント ゴール設定 スプリントバッ クログ設定 スプリント実施 デイリー スクラム スプリントレビュー ミーティング ソフトウエア 評価 製品バックログ 見直し スプリント（約３０日） クロージャ ゴール スプリント繰返し
- 14. 要求開発とアジャイル開発の究極コラボ 14 スプリント 要求 要求 一定のリズムで継続的にアウトプットを出し続ける工房 非同期バッファ リリース 新たな分業の始まりか スプリント スプリント スプリント スプリント リリース リリース リリース リリース ・ ・ ・ ・ 個別システムを超えたポートフォリオ マネジメント 外注業者購買担当者設計担当者営業担当者顧客 見積依頼書を作成 する 見積依頼 の送付 見積依頼 の受領 見積依頼の確認 引合案件の登録 社内見積依頼の 作成 設計する 見積条件を検討す る 外注業者の選定を する 見積依頼書を作成 する 見積依頼 の送付 見積依頼 を受領す る 見積を実施する 見積書の 送付 見積書を 受領 見積内容を評価し て候補を絞り込む 見積計算を行う 見積書を作成する 見積書の 送付 見積書の 受領 見積回答の評価 受注フローへ 購入中止 の連絡 購入中止 の連絡を 受ける 失注の登録を行う [新規引合の場合] [再見積の場合] [外注委託加工が必要な場合] [再見積依頼] [発注] [購入中止] 要求開発 プロダクト バックログ プロダクト オーナー
- 15. 似て非なるRUPとアジャイル 比較項目 イテレーション開発 アジャイル 体制 特に規定はない。開発規模に合わ せて決める。作業ボリュームに合わ せて投入するリソースを調整する。 ７±２名程度を１チームとする。基本的 には開発リソースは、開発期間中一 定。プロダクトオーナーやスクラムマ スターのような特殊な役割がある。 イテレーションの期間 比較的長い （特に規定はないが１ヵ月～３ヵ月ぐ らい） 比較的短い （１～４週間ぐらい） イテレーションの考え方 各イテレーションに意味づけを与え、 それに応じて個々に期間を設定。イ テレーションの期間は一定とは限ら ない。 各イテレーションは期間を固定し、リ ズムを重視。見合うボリュームの作業 を優先順位に従いイテレーションにア サインする。 マネジメントコスト 開発組織が一定以上は、間接的コ ミュニケーションや全体統制のため のマネジメントコストが一定量発生 する 少人数の直接コミュニケーションを基 礎とするため、ドキュメントなどやマネ ジメントのオーバーヘッドを極小化す る 開発環境 一般的な生産性向上のための環境 整備を要する 短期間一定リズムで頻繁にリリース するため、継続的インテグレーション や自動テストなどオーバーヘッドを削 減する環境が望ましい 案件を主体に組み立てるか、人間のパフォーマンスを主体に組 み立てるか （変化を吸収するという目的は同じながら・・）
- 16. エンタープライズアジャイルの構造 • プログラムマネジメント（ポートフォリオマネジメント）こそが重要 • 工房とフィーダー間を取り持つのが、プロダクトバックログ – 工房の生産リズムをエンジンにする – 本当の意味で上位目的の共有はできないが相手が大きすぎるの である程度いいか。（Plain Old Agile （POAGILE？）に比べて後 退？） • 全体の構造を把握して細かくちぎる – モデリングなしには成立しない – 疎結合のシステム構成で適正範囲を絞れる • リズムにはいるまでの段取りが必要 – 全体がでかい – 関連システムなど生態系をなしている。 リソース・開発サイクル固定の最適化された開発エンジンとそれにユーザーストーリー をフィードする構造が基本
- 17. エンタープライズアジャイルでのお薦めモデリング • スプリント以前 – 要求モデル – 業務をとらえる３種のモデル • サービスモデル、概念モデル、業務フロー – アーキテクチャモデリング • 主要なパターン（設計クラス図とシーケンス図）とサンプルコーディング – ユースケース一覧 • プロダクトバックログへの展開 • スプリント中 – 詳細設計のモデルは省略する • 設計者と実装者が同じ • 詳細レベルはコードの方が表現できる – コミュニケーションのためのメモとしてモデルを多用する • 使い捨て前提 • リリース後、運用準備 – ポリシーによる（紙の形式か情報として残ればいいか） – 主要クラスと主要動作のシーケンス図、特殊なアルゴリズム – ユーザーストーリーの集約 – ビジネスルールの整理だけは怠りなく 17
- 19. オブジェクトモデルの考え方 • オブジェクトモデル – 役割をもったモノ（オブジェクト）が協調動作することによって特定の処理 （サービス）を実現するととらえるモデル – 銀行口座からの引出しは、役割分担した４人の連係プレーで実現される 窓口 顧客の要求受付、お金の引渡し アシスタント 処理のコントロール 口座管理係 口座管理データベースの更新 出納係 必要金額の出し入れと管理
- 21. 最低限の設計モデル • 似たようなシーケンス図は書く必要なし – 主要なユースケースを実現する主要なクラス間の役割分 担を確認できればOK。主なメソッドの洗い出し。 – 代表的な１０パターン（当然規模による）をまず書いてみる。 パターンとして不足と思ったら、あと、１０パターンをあげ てみる。さらに不足なら・・・・そんなには要らないはず • 経験的には – システム全体の動き（外枠・MVC的）を表現するものが数 パターン – ドメイン層の動きやクラスの役割を表現するものが、１０ パターンもあれば・・・
- 23. 要求獲得のためのダイヤグラム • ビジネスユースケース図（ユースケース図） • 業務フロー図（アクティビティ図） • 概念クラス図（クラス図） ビジネスユー スケース図 概念クラス図 業務フロー図 システムユー スケース図 設計クラス図 要求開発（BA) システム開発 サービスモデル 静的モデル 動的モデル 何をするか 何がどうあるか どう動くか データ設計 図
- 26. 「これだけ」概念クラス図の例
- 27. 引出しと共通理解のための概念モデル • 業務理解の概念モデルでアナリシスパターンを描かない – 抽象化しすぎるとかえって特徴がわからない • 概念モデルを引きずりすぎない – 使い捨ててもいい – プロセスが重要（引出しのツール） – 無理なトレーサビリティを求めない • 設計では別の概念が入ってきて折衷できないことが多い • 共通に認識している＆残像がある でOK
- 28. グループ演習 ～概念モデル作成～ • 各チーム（４～５名）で議論して１つの概念クラス図を作 成してください Ø 作成時間 ３０分 • 代表者１名を決めて、発表してください Ø １チーム５分程度 ü モデルの概要 ü 特に議論になったところ
- 29. 概念モデルの題材 • 高校の履修管理業務の概念クラス図を作成しましょう Ø 例えば、次のような情報を網羅してください ü 各生徒の履修している必須科目と選択科目 ü 各組に所属する生徒 ü 各組の担任 ü 教師と担当している講座 ※ 必要な情報を想像力で補ってモデルを完成させてください
- 30. 使う記法「これだけ」 • クラス • クラス間の関係 – 汎化関係 – 関連 • 普通の関連 • 集約（全体と部分） • コンポジション（全体ともろともの部分：かなりオプション） 30
- 31. モデリングをやってみて（よくある感想） • モデルを描こうとすることで不足情報を効率よく引き出せた • それぞれ描いていた業務（この場合「履修管理」）の認識の 違いがよく理解できて、共通認識にまとめることができた • 単なる話し合いでは詰められなかった曖昧なところを明確に できた • 曖昧に使っていた言葉がはっきりと定義できた • 関係する業務を広めに議論してシステム化スコープの輪郭 がはっきりした • システムに着手するまでに業務ではっきりさせておくべきこと が認識できた • システムイメージができあがった • データベース構造がほぼ見えた 31
- 32. 運用管理の負荷 増大 グループの情報システム、インフラの管理・運営を実施情報システム部 経営情報のリア ルタイム把握 グループの経営戦略立案経営戦略室 業務効率化、精 度向上、迅速化 経理業務に加え、法務、総務機能の実施財務・経理 統制事項の追加内部統制監査の運営内部統制監査室 監査情報の信頼 性向上 監査の実施監査役 監査情報の信頼 性向上 財務諸表が会計原則に準拠しており、企業の財政状態 や経営状態を適正に表示しているか否かについての監 査を実施 監査法人 経営指標の迅速 な把握。経営の 見える化 会社経営の実施経営 想定される影響 （メリット・デメリッ ト） 説明ステークホルダー名 ビジネスユースケース／業務フロー／システムユースケース 発送する 商品在庫を確 認する 注文を受け付 ける 請求書を送付 する 注文をクローズ する 納品を確認する 支払いを確認 する 商品を発注 する 入金を調べ る 在庫センター 営業 経理 システム 入金管理システム 取引顧客 32 注文を登 録する ・・・・・・・・ ・・・・・・・・ ・・・・・・・・・・・・・・・・ ・・・・ ・・・・・・・・ ・・・・・・・・ ・・・・・・・ ・・・・・・・・ ・ ・・・・・・・・ ・・・・・・・・ 機能一覧 ビジネスユースケース 業務フロー ユースケース記述 システムユースケース アジャイルだと • フィーチャー • ユーザストーリー