enterprise agile lean modeling

34
エンタープライズアジャイル時代の リーンモデリング 株式会社 メソドロジック 山岸 耕二 1

Upload: kenji-hiranabe

Post on 10-May-2015

5.503 views

Category:

Software


4 download

DESCRIPTION

「エンタープライズアジャイル開発のリーンモデリング」 by 山岸理事 on 5/28, 2014 要求開発アライアンス定例

TRANSCRIPT

Page 1: enterprise agile lean modeling

エンタープライズアジャイル時代の  リーンモデリング

株式会社 メソドロジック  山岸 耕二  

1

Page 2: enterprise agile lean modeling

関心の変遷 ソフトウエアエンジニアリングのビジネスの中で

2

いかにちゃんと作るか

• プログラム言語、アルゴリズム  • システムアーキテクチャ、システム構成  • 開発プロセス、開発環境

いかに役に立つものを作るか

• ビジネスモデリング  • 要求開発  • 業務とITの最適設計

いかにビジネス価値を継続的に高めるか

• システム複合体としてのエンタープライズシステム・継続的リフォーム  • プログラムマネジメント  • ビジネスプレーヤーと開発者の協調開発

オージス総研(1989-­‐2000)   米国オブジェクト指向調査   シリコンバレー駐在   オブジェクト指向ツール提携   日本ラショナル設立   オブジェクト指向での本格SI    

ウルシステムズ(2000-­‐2004)   UMLautフレームワーク構築   Javaによる基幹システム構築   ビジネスモデリング協議会設立    

豆蔵(2004-­‐2009)   要求開発アライアンス設立   enThology超上流プロセス    

メソドロジック(2009-­‐)   継続的リフォーム   エンタープライズアーキテクチャ   メガバンクの標準化(モデル、プロセス)

Page 3: enterprise agile lean modeling

IT戦略とプロジェクトの発生

現在のTo-­‐Be  IT 現在の  事業戦略

As-­‐Is  IT

将来のTo-­‐Be  IT 将来の  事業戦略

現在 XX年後

現実的目標のIT

現行システム

新規追加

機能的改修

時間軸

プロジェクト

プロジェクト

プロジェクト

改善 サーバ統合  セキュリティ強化  クラウド適用

維持 保守切れ対応  OS変更

プロジェクト プロジェクト

プロジェクト

破棄

事業戦略への対応

現行IT人材

コスト削減  継続性確保  コンプライアンス

育成 採用 パートナ戦略

必要IT人材

例えば3カ年計画

各プロジェクトが上位目的に基づいて企画されているか

プログラムマネジメント視点とプロジェクトマネジメント視点

プロジェクト

Page 4: enterprise agile lean modeling

モデリングとの出会い

•  現状よりも一段広いスコープ(結果的には上位の視点)を意識する  –  同じスコープ内でやっていると数年で頭打ちになる  

•  全体をとらえて、今の立ち位置を正しく理解する能力  –  モデリング能力(空間認識力)  

•  全体把握と正確な共通認識  –  空中戦を地上戦に持ち込む  

•  一般化(抽象化)と具体化を切り分け、問題解決を図る  

–  プロジェクト推進能力(段取り・シナリオを作る能力)  •  仮説で作って、段階的(アジャイル的)に詳細化する  •  プロセスをモデリングする  

4

モデリング力とプロジェクト推進力は根本的なスキル

Page 5: enterprise agile lean modeling

5  

ソフトウエアシステム特有の難しさ

•  プロジェクトは、建築プロジェクトのアナロジーで語られがち・・・  •  ソフトウエアシステムは複雑な系

–  対象が見えない

–  段取りに決まり手がない

–  目標は刻々変化する

対象が見えない

段取りが決まっていない

モデリングで可視化

プロセスを定義する

繰返し型で開発する目標が刻々変化する

困難を克服するための特徴的アプローチ

ソフトウエア開発上の歴史的なアプローチ

Page 6: enterprise agile lean modeling

リーン(「これだけ」)モデリングの勧め

•  こんなに役に立つのに使われていない  –  どのぐらい役に立つかわかっていない  –  使い方を間違っている  –  コストパフォーマンスをクリアする「これだけ」モデリング  

•  アジャイルではモデリングは不要なのか  –  アジャイルにもタイプがある  

•  ジャストアイデアと実装のコラボ  –  それでも言葉より手っ取り早くて正確に伝えるメモ的モデルは有効  

•  複雑な企業システムをアジャイルのベロシティで  –  ちゃんと地図をもって走らないとあらぬ方向に  

6

それぞれの場面に適したレベルの「これだけ」モデリングがある

Page 7: enterprise agile lean modeling

UMLのダイヤグラム構成

•  13のダイヤグラムで構成(ただし、パッケージ図はクラス図の1種)  •  大きくは静的モデル(構造図)と動的モデル(振る舞い図)に分類される  

静的モデル 動的モデル

スケッチとしてのUML  設計ドキュメントとしてのUML  プログラム言語としてのUML

Page 8: enterprise agile lean modeling

よく使う利用シーンとダイヤグラム

取り扱う ベースとなる 概要

ダイヤグラム ダイヤグラム

ビジネスユースケース図

ユースケース図

特定業務領域について対象業務を棚卸し、業務スコープを明らかにする

システムユースケース図 システムが提供するサービスをユーザ視点で示し、システムのスコープを明らかにする

概念クラス図

クラス図

特定業務領域を構成する概念(エンティティ)を抽出し、それらの間の関係を明らかにする

設計クラス図 オブジェクト指向言語を用いたソフトウエア開発の設計段階でクラス構成とクラス間の関係を定義する

データ設計図 リレーショナルデータベースを利用した永続化を前提にデータモデルを構築する

業務フロー図

アクティビティ図

業務の処理手順を可視化し、システムとのやりとりを明らかにする

処理フロー図 システムの機能を実現する処理手順、ロジック、アルゴリズムを表現する。関数やメソッドのプログラム設計を行う。

設計シーケンス図 シーケンス図 利用者とシステム間のやりとり、システム間の連携、システム内部ロジックとしてのモジュール間のやりとりなどを設計する

Page 9: enterprise agile lean modeling

Bad  Smell  パターン

•  生真面目にやりすぎ  –  13種類のダイヤグラム  –  ほどというものを知らない(抽象度、詳細度や表記法へのこだ

わり)  –  すべてをモデリングする(全部シーケンス図書くとか)  –  ソースコードと同程度の情報をもたせる  

•  難しいこと言い過ぎ  –  国際語としての英語(スラングやネイティブな表現は通じない)  –  抽象度を上げすぎて、具体的なイメージを超えてしまう  

•  何のためにモデリングをするのかはっきりした目的がない  

Page 10: enterprise agile lean modeling

モデリングの目的をはっきりさせる

•  全貌の理解  •  詳細(複雑なもの)の理解  •  伝達  •  記録  

•  スケッチ  •  設計書  •  プログラム  

•  書き捨てる  •  中間生成物として使う  •  最終成果物として残す  •  保守資料としてメンテナンスする

何を使うか  どの程度書くか  どう扱うか

目的に適う程度にスリムに  おのずと程よさが決まる

Page 11: enterprise agile lean modeling

エンタープライズアジャイルとモデリング

11

Page 12: enterprise agile lean modeling

スクラムによる開発の進め方

• ソフトウェアに要求される機能とその優先度を製品バックログとして定める

• プロダクト・バックログからスプリントで実装するべき目標( スプリントゴール )を選択する

• スプリントゴールをより詳細なタスクに分解したスプリント・バックログを作成し,  タスクの割り当てを行う

• スプリントの間,  毎日決まった場所及び時間で開発メンバーが参加するデイリースクラムというミーティングを開催する

• 1  回のスプリントが終了すると,  スクラムレビューミーティングを開催し,  作成されたソフトウェアを評価する

• 次回のスプリントに備えてプロダクトバックログの内容と優先度の見直しを行う

COPYRIGHT  (C)  MethodoLogic,Inc.  ALL  RIGHTS  RESERVED.   12

スプリント計画

ビジネス要求

プロダクトバックログ設定

スプリントゴール設定

スプリントバックログ設定

スプリント実施 デイリー  スクラム

スプリントレビュー  ミーティング

ソフトウエア評価

製品バックログ見直し

スプリント(約30日)

クロージャ  ゴール

スプリント繰返し

Page 13: enterprise agile lean modeling

現実的なエンタープライズアジャイル

RDn

ちゃんと地図は描く たまに地図を見る

RD0

保守・運用のための整備

Page 14: enterprise agile lean modeling

要求開発とアジャイル開発の究極コラボ

 

 

 

 

 

 

14

スプリント

要求 要求

一定のリズムで継続的にアウトプットを出し続ける工房

非同期バッファ

リリース

新たな分業の始まりか

スプリント スプリント スプリント スプリント

リリース リリース リリース リリース

・  ・  ・  ・

個別システムを超えたポートフォリオマネジメント

外注業者購買担当者設計担当者営業担当者顧客

見積依頼書を作成する

見積依頼の送付

見積依頼の受領

見積依頼の確認

引合案件の登録

社内見積依頼の作成

設計する

見積条件を検討する

外注業者の選定をする

見積依頼書を作成する

見積依頼の送付

見積依頼を受領する

見積を実施する

見積書の送付

見積書を受領

見積内容を評価して候補を絞り込む

見積計算を行う

見積書を作成する

見積書の送付

見積書の受領

見積回答の評価

受注フローへ

購入中止の連絡

購入中止の連絡を受ける

失注の登録を行う

[新規引合の場合]

[再見積の場合]

[外注委託加工が必要な場合]

[再見積依頼][発注]

[購入中止]

要求開発

プロダクト  バックログ

プロダクト  オーナー

Page 15: enterprise agile lean modeling

似て非なるRUPとアジャイル

比較項目 イテレーション開発 アジャイル

体制

特に規定はない。開発規模に合わせて決める。作業ボリュームに合わせて投入するリソースを調整する。

7±2名程度を1チームとする。基本的には開発リソースは、開発期間中一定。プロダクトオーナーやスクラムマスターのような特殊な役割がある。

イテレーションの期間 比較的長い  (特に規定はないが1ヵ月~3ヵ月ぐらい)

比較的短い  (1~4週間ぐらい)

イテレーションの考え方

各イテレーションに意味づけを与え、それに応じて個々に期間を設定。イテレーションの期間は一定とは限らない。

各イテレーションは期間を固定し、リズムを重視。見合うボリュームの作業を優先順位に従いイテレーションにアサインする。

マネジメントコスト

開発組織が一定以上は、間接的コミュニケーションや全体統制のためのマネジメントコストが一定量発生する

少人数の直接コミュニケーションを基礎とするため、ドキュメントなどやマネジメントのオーバーヘッドを極小化する  

開発環境

一般的な生産性向上のための環境整備を要する

短期間一定リズムで頻繁にリリースするため、継続的インテグレーションや自動テストなどオーバーヘッドを削減する環境が望ましい

案件を主体に組み立てるか、人間のパフォーマンスを主体に組み立てるか (変化を吸収するという目的は同じながら・・)

Page 16: enterprise agile lean modeling

エンタープライズアジャイルの構造

•  プログラムマネジメント(ポートフォリオマネジメント)こそが重要  •  工房とフィーダー間を取り持つのが、プロダクトバックログ  

–  工房の生産リズムをエンジンにする  –  本当の意味で上位目的の共有はできないが相手が大きすぎるの

である程度いいか。(Plain  Old  Agile (POAGILE?)に比べて後退?)  

•  全体の構造を把握して細かくちぎる  –  モデリングなしには成立しない  –  疎結合のシステム構成で適正範囲を絞れる  

•  リズムにはいるまでの段取りが必要  –  全体がでかい  –  関連システムなど生態系をなしている。

リソース・開発サイクル固定の最適化された開発エンジンとそれにユーザーストーリーをフィードする構造が基本

Page 17: enterprise agile lean modeling

エンタープライズアジャイルでのお薦めモデリング

•  スプリント以前  –  要求モデル  –  業務をとらえる3種のモデル  

•  サービスモデル、概念モデル、業務フロー  –  アーキテクチャモデリング  

•  主要なパターン(設計クラス図とシーケンス図)とサンプルコーディング  –  ユースケース一覧  

•  プロダクトバックログへの展開  

•  スプリント中  –  詳細設計のモデルは省略する  

•  設計者と実装者が同じ  •  詳細レベルはコードの方が表現できる  

–  コミュニケーションのためのメモとしてモデルを多用する  •  使い捨て前提  

•  リリース後、運用準備  –  ポリシーによる(紙の形式か情報として残ればいいか)  –  主要クラスと主要動作のシーケンス図、特殊なアルゴリズム  –  ユーザーストーリーの集約  –  ビジネスルールの整理だけは怠りなく  

17

Page 18: enterprise agile lean modeling

システム設計におけるモデリング

18

Page 19: enterprise agile lean modeling

オブジェクトモデルの考え方 •  オブジェクトモデル

–  役割をもったモノ(オブジェクト)が協調動作することによって特定の処理(サービス)を実現するととらえるモデル

–  銀行口座からの引出しは、役割分担した4人の連係プレーで実現される

窓口    顧客の要求受付、お金の引渡し アシスタント   処理のコントロール 口座管理係   口座管理データベースの更新 出納係     必要金額の出し入れと管理

Page 20: enterprise agile lean modeling

オブジェクトモデルの表現方法

サービスモデル

静的モデル 動的モデル

システムユースケース図

設計クラス図

設計シーケンス図

何をするか

何がどうあるか どう動くか

システムを構成するクラス群 それらのクラス(オブジェクト)がどのように協調し合うか

利用者と提供するサービス

Page 21: enterprise agile lean modeling

最低限の設計モデル

•  似たようなシーケンス図は書く必要なし  –  主要なユースケースを実現する主要なクラス間の役割分

担を確認できればOK。主なメソッドの洗い出し。  –  代表的な10パターン(当然規模による)をまず書いてみる。

パターンとして不足と思ったら、あと、10パターンをあげてみる。さらに不足なら・・・・そんなには要らないはず  

•  経験的には  –  システム全体の動き(外枠・MVC的)を表現するものが数

パターン  –  ドメイン層の動きやクラスの役割を表現するものが、10

パターンもあれば・・・  

Page 22: enterprise agile lean modeling

要求開発・要件定義におけるモデリング

22

Page 23: enterprise agile lean modeling

要求獲得のためのダイヤグラム

•  ビジネスユースケース図(ユースケース図)  •  業務フロー図(アクティビティ図)  •  概念クラス図(クラス図)    

ビジネスユースケース図

概念クラス図 業務フロー図

システムユースケース図

設計クラス図

要求開発(BA)

システム開発

サービスモデル

静的モデル 動的モデル

何をするか

何がどうあるか どう動くか

データ設計図

Page 24: enterprise agile lean modeling

「これだけ」ビジネスユースケース図の例

サブジェクト

ビジネスアクター

ビジネスユースケース

関連

汎化関係

包含関係  include

Page 25: enterprise agile lean modeling

「これだけ」業務フロー図の例

アクション

初期ノード

最終ノード

フォーク

ジョイン

分岐

マージ

Page 26: enterprise agile lean modeling

「これだけ」概念クラス図の例

Page 27: enterprise agile lean modeling

引出しと共通理解のための概念モデル

•  業務理解の概念モデルでアナリシスパターンを描かない  –  抽象化しすぎるとかえって特徴がわからない  

•  概念モデルを引きずりすぎない  –  使い捨ててもいい  –  プロセスが重要(引出しのツール)  –  無理なトレーサビリティを求めない  

•  設計では別の概念が入ってきて折衷できないことが多い  •  共通に認識している&残像がある でOK  

Page 28: enterprise agile lean modeling

グループ演習 ~概念モデル作成~

•  各チーム(4~5名)で議論して1つの概念クラス図を作成してください  Ø 作成時間 30分  

•  代表者1名を決めて、発表してください  Ø 1チーム5分程度  

ü モデルの概要  ü 特に議論になったところ

Page 29: enterprise agile lean modeling

概念モデルの題材

•  高校の履修管理業務の概念クラス図を作成しましょう  

Ø 例えば、次のような情報を網羅してください  ü 各生徒の履修している必須科目と選択科目  ü 各組に所属する生徒  ü 各組の担任  ü 教師と担当している講座  

※ 必要な情報を想像力で補ってモデルを完成させてください  

 

Page 30: enterprise agile lean modeling

使う記法「これだけ」

•  クラス  •  クラス間の関係  

–  汎化関係  –  関連  

•  普通の関連  •  集約(全体と部分)  •  コンポジション(全体ともろともの部分:かなりオプション)  

30

Page 31: enterprise agile lean modeling

モデリングをやってみて(よくある感想)

•  モデルを描こうとすることで不足情報を効率よく引き出せた  •  それぞれ描いていた業務(この場合「履修管理」)の認識の

違いがよく理解できて、共通認識にまとめることができた  •  単なる話し合いでは詰められなかった曖昧なところを明確に

できた  •  曖昧に使っていた言葉がはっきりと定義できた  •  関係する業務を広めに議論してシステム化スコープの輪郭

がはっきりした  

•  システムに着手するまでに業務ではっきりさせておくべきことが認識できた  

•  システムイメージができあがった  •  データベース構造がほぼ見えた  

31

Page 32: enterprise agile lean modeling

運用管理の負荷増大

有馬2 3 グループの情報システム、インフラの管理・運営を実施情報システム部

経営情報のリアルタイム把握

大石2 2 グループの経営戦略立案経営戦略室

業務効率化、精度向上、迅速化

川端4 3 経理業務に加え、法務、総務機能の実施財務・経理

統制事項の追加 田辺1 3 内部統制監査の運営内部統制監査室

監査情報の信頼性向上

相沢3 1 監査の実施監査役

監査情報の信頼性向上

OO監査法人1 1 財務諸表が会計原則に準拠しており、企業の財政状態や経営状態を適正に表示しているか否かについての監査を実施

監査法人

経営指標の迅速な把握。経営の見える化

吉沢社長4 3 会社経営の実施経営

想定される影響(メリット・デメリッ

ト)

具体例人数重要度説明ステークホルダー名

ビジネスユースケース/業務フロー/システムユースケース

発送する

商品在庫を確 認する

注文を受け付 ける

請求書を送付 する

注文をクローズ する

納品を確認する

支払いを確認 する

商品を発注する

入金を調べる

在庫センター 営業 経理 システム

入金管理システム

取引顧客

32

注文を登録する

・・・・・・・・ ・・・・・・・・  ・・・・・・・・・・・・・・・・  ・・・・ ・・・・・・・・ ・・・・・・・・  ・・・・・・・ ・・・・・・・・ ・

・・・・・・・・  ・・・・・・・・

機能一覧

ビジネスユースケース

業務フロー

ユースケース記述

システムユースケース

アジャイルだと  • フィーチャー  • ユーザストーリー

Page 33: enterprise agile lean modeling

概念クラス図/設計クラス図/データ設計図

システムスコープに絞り込み

概念クラス図 (分析)クラス図 設計クラス図

永続化対象をテーブル化

実装に必要なクラスの追加

データ設計図

Page 34: enterprise agile lean modeling

モデルによる業務とシステムの連携

ビジネスモデリング

システムモデリング