More Related Content
Similar to enterprise agile lean modeling (20)
More from Kenji Hiranabe (20)
enterprise agile lean modeling
- 2. 関心の変遷 ソフトウエアエンジニアリングのビジネスの中で
2
いかにちゃんと作るか
• プログラム言語、アルゴリズム
• システムアーキテクチャ、システム構成
• 開発プロセス、開発環境
いかに役に立つものを作るか
• ビジネスモデリング
• 要求開発
• 業務とITの最適設計
いかにビジネス価値を継続的に高めるか
• システム複合体としてのエンタープライズシステ
ム・継続的リフォーム
• プログラムマネジメント
• ビジネスプレーヤーと開発者の協調開発
オージス総研(1989-‐2000)
米国オブジェクト指向調査
シリコンバレー駐在
オブジェクト指向ツール提携
日本ラショナル設立
オブジェクト指向での本格SI
ウルシステムズ(2000-‐2004)
UMLautフレームワーク構築
Javaによる基幹システム構築
ビジネスモデリング協議会設立
豆蔵(2004-‐2009)
要求開発アライアンス設立
enThology超上流プロセス
メソドロジック(2009-‐)
継続的リフォーム
エンタープライズアーキテクチャ
メガバンクの標準化(モデル、プロセス)
- 3. IT戦略とプロジェクトの発生
現在のTo-‐Be
IT
現在の
事業戦略
As-‐Is
IT
将来のTo-‐Be
IT
将来の
事業戦略
現在
XX年後
現実的目標のIT
現行システム
新規追加
機能的改修
時間軸
プロジェクト
プロジェクト
プロジェクト
改善
サーバ統合
セキュリティ強
化
クラウド適用
維持
保守切れ対応
OS変更
プロジェクト
プロジェクト
プロジェクト
破棄
事業戦略
への対応
現行IT人材
コスト削減
継続性確保
コンプライアン
ス
育成
採用
パートナ戦略
必要IT人材
例えば3カ年計画
各プロジェクトが上位目的に基づいて企画されているか
プログラムマネジメント視点とプロジェクトマネジメント視点
プロジェクト
- 4. モデリングとの出会い
• 現状よりも一段広いスコープ(結果的には上位の視点)
を意識する
– 同じスコープ内でやっていると数年で頭打ちになる
• 全体をとらえて、今の立ち位置を正しく理解する能力
– モデリング能力(空間認識力)
• 全体把握と正確な共通認識
– 空中戦を地上戦に持ち込む
• 一般化(抽象化)と具体化を切り分け、問題解決を図る
– プロジェクト推進能力(段取り・シナリオを作る能力)
• 仮説で作って、段階的(アジャイル的)に詳細化する
• プロセスをモデリングする
4
モデリング力とプロジェクト推進力は根本的なスキル
- 6. リーン(「これだけ」)モデリングの勧め
• こんなに役に立つのに使われていない
– どのぐらい役に立つかわかっていない
– 使い方を間違っている
– コストパフォーマンスをクリアする「これだけ」モデリング
• アジャイルではモデリングは不要なのか
– アジャイルにもタイプがある
• ジャストアイデアと実装のコラボ
– それでも言葉より手っ取り早くて正確に伝えるメモ的モデルは有効
• 複雑な企業システムをアジャイルのベロシティで
– ちゃんと地図をもって走らないとあらぬ方向に
6
それぞれの場面に適したレベルの「これだけ」モデリングがある
- 9. Bad
Smell
パターン
• 生真面目にやりすぎ
– 13種類のダイヤグラム
– ほどというものを知らない(抽象度、詳細度や表記法へのこだ
わり)
– すべてをモデリングする(全部シーケンス図書くとか)
– ソースコードと同程度の情報をもたせる
• 難しいこと言い過ぎ
– 国際語としての英語(スラングやネイティブな表現は通じない)
– 抽象度を上げすぎて、具体的なイメージを超えてしまう
• 何のためにモデリングをするのかはっきりした目的がない
- 10. モデリングの目的をはっきりさせる
• 全貌の理解
• 詳細(複雑なもの)の理解
• 伝達
• 記録
• スケッチ
• 設計書
• プログラム
• 書き捨てる
• 中間生成物として使う
• 最終成果物として残す
• 保守資料としてメンテナンスする
何を使うか
どの程度書くか
どう扱うか
目的に適う程度にスリムに
おのずと程よさが決まる
- 16. エンタープライズアジャイルの構造
• プログラムマネジメント(ポートフォリオマネジメント)こそが重要
• 工房とフィーダー間を取り持つのが、プロダクトバックログ
– 工房の生産リズムをエンジンにする
– 本当の意味で上位目的の共有はできないが相手が大きすぎるの
である程度いいか。(Plain
Old
Agile (POAGILE?)に比べて後
退?)
• 全体の構造を把握して細かくちぎる
– モデリングなしには成立しない
– 疎結合のシステム構成で適正範囲を絞れる
• リズムにはいるまでの段取りが必要
– 全体がでかい
– 関連システムなど生態系をなしている。
リソース・開発サイクル固定の最適化された開発エンジンとそれにユーザーストーリー
をフィードする構造が基本
- 17. エンタープライズアジャイルでのお薦めモデリング
• スプリント以前
– 要求モデル
– 業務をとらえる3種のモデル
• サービスモデル、概念モデル、業務フロー
– アーキテクチャモデリング
• 主要なパターン(設計クラス図とシーケンス図)とサンプルコーディング
– ユースケース一覧
• プロダクトバックログへの展開
• スプリント中
– 詳細設計のモデルは省略する
• 設計者と実装者が同じ
• 詳細レベルはコードの方が表現できる
– コミュニケーションのためのメモとしてモデルを多用する
• 使い捨て前提
• リリース後、運用準備
– ポリシーによる(紙の形式か情報として残ればいいか)
– 主要クラスと主要動作のシーケンス図、特殊なアルゴリズム
– ユーザーストーリーの集約
– ビジネスルールの整理だけは怠りなく
17
- 21. 最低限の設計モデル
• 似たようなシーケンス図は書く必要なし
– 主要なユースケースを実現する主要なクラス間の役割分
担を確認できればOK。主なメソッドの洗い出し。
– 代表的な10パターン(当然規模による)をまず書いてみる。
パターンとして不足と思ったら、あと、10パターンをあげ
てみる。さらに不足なら・・・・そんなには要らないはず
• 経験的には
– システム全体の動き(外枠・MVC的)を表現するものが数
パターン
– ドメイン層の動きやクラスの役割を表現するものが、10
パターンもあれば・・・
- 30. 使う記法「これだけ」
• クラス
• クラス間の関係
– 汎化関係
– 関連
• 普通の関連
• 集約(全体と部分)
• コンポジション(全体ともろともの部分:かなりオプション)
30
- 31. モデリングをやってみて(よくある感想)
• モデルを描こうとすることで不足情報を効率よく引き出せた
• それぞれ描いていた業務(この場合「履修管理」)の認識の
違いがよく理解できて、共通認識にまとめることができた
• 単なる話し合いでは詰められなかった曖昧なところを明確に
できた
• 曖昧に使っていた言葉がはっきりと定義できた
• 関係する業務を広めに議論してシステム化スコープの輪郭
がはっきりした
• システムに着手するまでに業務ではっきりさせておくべきこと
が認識できた
• システムイメージができあがった
• データベース構造がほぼ見えた
31