アジャイル開発を可能にするEA
•
8 gefällt mir•3,846 views
オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2012年12月定例会発表資料です。 Open Community "Requirement Development Alliance" 2012/12 regular meeting of the presentation materials.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie アジャイル開発を可能にするEA
Ähnlich wie アジャイル開発を可能にするEA (20)
Mehr von Kent Ishizawa
Mehr von Kent Ishizawa (16)
アジャイル開発を可能にするEA
- 1. アジャイル開発を可能にするＥＡ （エンタープライズ・アーキテクチャ） 2012. 9.26 Ｅ-AGILITYカンファレンス E-AGILITY協議会理事 中山嘉之 要求開発アライアンス理事 2012年 9月 26日 1
- 2. 前回までのおさらい -1 •１９９０年代後半～今日で大企業のＥＲＰ導入が一段落 早い企業で２，３回目、遅いところでも初回のＶｕｐを迎える ↓ •ＥＲＰは財務処理統制の強化や業務プロセスの標準化と いったガバナンス面や効率化で企業に価値もたらした ↓ •しかし事業競争力の強化には必ずしも貢献できていない ↓ •企業のオリジナリティ溢れる業務は、パッケージシステム では難しく、“手組み”による構築が必要 ↓ •生産性と品質向上をとことん追求した“次世代手組２．０” 注）問題認識の中心は年商数百億円超のいわゆる大企業だが、中小企業に当て はまらないわけではない。（寧ろ制約条件が少ないので問題は小さい） 2
- 3. ※手組み“２．０”を適用する領域 属人的ノウハウを企業のノウハウにす 変更が多い 属人的ノウハウ多い。⇒企業のノウ る為にシステム化（コアは業種、企業 によって若干異なる部分あり） ハウにする為にシステム化！ カスタム・パッケージ 手組み２．０の領域 規制 受注・出荷 対応 製造、研究 営業支援 のコア業務 生産管理 人材 管理 ﾏｽﾀ・ﾒﾝﾃﾅ Ｉ／Ｆ、 バ 品質 ﾝｽ・ｼｽﾃﾑ ＨＵＢ フ ッ 管理 購買 ロ ク オフィス支援 ン オ ｺﾐｭﾆ ト 管理 ｹｰｼｮﾝ フ エ 給与計算 会計 ン ィ ス 非構造化データ ド ＢＩ 制度会計 ＳＮＳ 文書管理 一体成型・パッケージ 汎用ツール 変更が少ない 3
- 4. 前回までのおさらい -2 •エンタープライズな手組み２．０では、より高い生産性、継 続性、品質（特にデータ品質）が求められる ↓ •要求開発＋アジャイルによりビジネス的価値を実証 •クラウド環境で生産性、可用性、信頼性を確保 •アーキテクチャ重視の設計で品質、保守性を担保 ↓ 案件毎に、①開発方法論がフィットしているか ②プロ ジェクト体制は適切か ③開発スコープが妥当か 等をチ ェックし上流工程から品質を作り込む ↓ •日本特有の課題（多重請負契約の構造、ユーザ企業の ベンダー丸投げ体質等）をクリアーする必要あり 4
- 5. 本題：大規模アジャイルのリスク回避策 過大なスコープのアジャイル開発は、ビジネスニーズの発 散・矛盾、部品点数の増大等で確かにリスクは増す ↓ ウオータフォールで、作り手優位に開発すればリスク は軽減するが、ビジネス的価値創造が犠牲になり易い （Project は成功するがProduct が残念なケース） ↓ •ならば開発単位を“大規模にしない”ことを考える ↓ •複数の小さな開発単位に分割する方法を考えよう！ （前回Ｅアジ寺子屋でメアリーの話に登場した“毎日 のようにデプロイしている企業“をヒントに） 5
- 6. 開発単位を分割するのにＥＡは前提 ①まずは、社内システムの全貌がどうなっているのか、 現行システム（ＡｓＩｓ）をモデル図を用いて見える化する 精緻なモデル図を描く事を目的としない。 ⇒予めタイムボックス（２～３カ月）を定め、概念レベルの表記に留める ②次にあるべきシステム（ＴｏＢｅ）をプロジェクト毎に記述 ＡｓＩｓ同様の表記法、概念レベル、“ビジネス視点”で、描く ＥＡとモデリングツール（例） 6
- 7. 開発単位を分割する方法 -1 ①業務で分割：SCM（生産管理、 販売物流 営業支援 販売物流、原価計算）､SFA､CRM､ ＴＲ ＴＲ 会計といった“システム”の単位で システム ＴＲ－ ＴＲ－Ｈｕｂ ＤＷＨ 疎結合に分割 ⇒各システムを跨ぐＩ／Ｆレコードを汎化 ＴＲ ＴＲ 生産管理 会計 *してＴＲ－ＤＷＨとしてＨｕｂに格納 ②アクターで分割：営業支援シス TR- DWH テム（SFA）を、ﾌﾛﾝﾄｵﾌｨｽ（現場ｾｰ ＴＲ－Ｈｕｂ ｾｰﾙｽ支 援 Large ﾙｽ）と、ﾊﾞｯｸｵﾌｨｽ（管理ｽﾀｯﾌ）に DWH サブシステム分割。 MART ﾊﾞｯｸｵﾌ ⇒両システムを繋ぐＩ／Ｆレコードをクラ ｨｽ ウド上のＨｕｂに格納（レコードは特化） ｻﾌﾞｼｽﾃﾑ 7
- 8. 開発単位を分割する方法 -2 ③ブラックＢＯＸ化した巨大ＥＲＰから、明 示的にイベントを取り出し、これをベースに ＥＲＰ 順次開発する。（販売分析、原価計算などの （販売物流・ 生産管理・ 参照系が主） 会計） ⇒ＧＡＴＥＷＡＹ製品*を用いてメインＴＲをクラウ ド上のＨｕｂに切り出す。（レコードは一部汎化） GATEWAY 販売 ※GATEWAY製品はＥＲＰﾍﾞﾝﾀﾞｰの認定要 分析 他 TR- DWH ※本アプローチ自身がシステムの可視化に！ ⇒①～③のＨＵＢは、ネットワーク領域における“交差点整理 “を目的とした”ＥＳＢ”（Enterprise Service Bus）とは異な り、イベント・トランザクションデータを格納したＤＷＨを保 有する“データＨＵＢ”である。その仕組みは、更新（ＩＮＳ ＥＲＴのみ）ﾓｼﾞｭｰﾙと、参照ﾓｼﾞｭｰﾙからなるシンプルなもの。 8
- 9. ※トランザクションレコードの汎化例 売上 製商品受払 受払 ５Ｗ１Ｈ 受発注 伝票No 伝票No 伝票No 伝票No 受払区分 出荷年月日 取引区分 why 受／発注区分 品目ｺｰﾄﾞ 品目ｺｰﾄﾞ what 製品ｺｰﾄﾞ 出庫年月日 資産部門ｺｰﾄﾞ 顧客ｺｰﾄﾞ 取引先ｺｰﾄﾞ whom 入荷年月日 出庫年月日 担当部門ｺｰﾄﾞ who 出庫拠点ｺｰﾄﾞ 入出庫拠点ｺｰﾄﾞ 入庫年月日 売上部門ｺｰﾄﾞ 資産部門ｺｰﾄﾞ whose 製商品ｺｰﾄﾞ 出庫拠点ｺｰﾄﾞ 出荷数量 出庫年月日 when1 取引先ｺｰﾄﾞ 入庫拠点ｺｰﾄﾞ 売上金額 入庫年月日 when2 担当部門ｺｰﾄﾞ 取引先ｺｰﾄﾞ 出庫拠点ｺｰﾄﾞ where1 受発注数量 担当部門ｺｰﾄﾞ 入庫拠点ｺｰﾄﾞ where2 購入 取引金額 数量 How many 金額 数量 伝票No 金額 How much 入庫年月日 在庫移動 工場内受払 取引登録( ) 商品ｺｰﾄﾞ 伝票No 伝票No 購入先ｺｰﾄﾞ 取引参照( ) 出庫年月日 受払区分 入庫拠点ｺｰﾄﾞ 入庫年月日 品目ｺｰﾄﾞ 購入部門ｺｰﾄﾞ 出庫拠点ｺｰﾄﾞ 取扱部門ｺｰﾄﾞ 〔 属性汎化＝ﾒｿｯﾄﾞ汎化 〕 入庫数量 入庫拠点ｺｰﾄﾞ 出庫年月日 ⇒ﾌﾟﾛｾｽ再利用性 大 購入金額 製商品ｺｰﾄﾞ 入庫年月日 資産部門ｺｰﾄﾞ 出庫拠点ｺｰﾄﾞ 移動数量 入庫拠点ｺｰﾄﾞ 数量 金額 9
- 10. ※トランザクションとアプリケーション 売上 製商品受払 受払 ５Ｗ１Ｈ 伝票No 伝票No 伝票No 受発注 why 受払区分 取引区分 出荷年月日 伝票No 品目ｺｰﾄﾞ what 品目ｺｰﾄﾞ 製品ｺｰﾄﾞ 受／発注区分 得意先ｺｰﾄﾞ whom 得意先ｺｰﾄﾞ 顧客ｺｰﾄﾞ 出荷年月日 担当部門ｺｰﾄﾞ who ＳＦＡ 出庫拠点ｺｰﾄﾞ 製品ｺｰﾄﾞ 担当部門ｺｰﾄﾞ 出庫年月日 when1 出庫年月日 売上部門ｺｰﾄﾞ 顧客ｺｰﾄﾞ when2 入庫年月日 入庫年月日 出荷数量 受発注 出庫拠点ｺｰﾄﾞ 出庫拠点ｺｰﾄﾞ 出庫拠点ｺｰﾄﾞ where1 売上金額 システム 担当部門ｺｰﾄﾞ 入庫拠点ｺｰﾄﾞ 入庫拠点ｺｰﾄﾞ where2 出荷数量 販売物流 数量 数量 How many 購入 売上金額 金額 金額 How much システム 伝票No 工場内受払 取引登録( ) 入庫年月日 在庫移動 商品ｺｰﾄﾞ 伝票No 取引参照( ) 伝票No 受払区分 購入先ｺｰﾄﾞ 出庫年月日 品目ｺｰﾄﾞ 入庫拠点ｺｰﾄﾞ 入庫年月日 得意先ｺｰﾄﾞ ＳＣＭ 購入部門ｺｰﾄﾞ 入庫数量 品目ｺｰﾄﾞ 生産 担当部門ｺｰﾄﾞ （ＥＲＰ） 出庫拠点ｺｰﾄﾞ 出庫年月日 購入金額 入庫拠点ｺｰﾄﾞ 管理 入庫年月日 購買 担当部門ｺｰﾄﾞ シス 出庫拠点ｺｰﾄﾞ 移動数量 テム システム 入庫拠点ｺｰﾄﾞ 数量 金額 10
- 11. “手組み２．０”の適用範囲拡大 ＳＣＭ（受注・出荷、生産、購買）や 管理会計の領域でも、企業のオリジナ 変更が多い 属人的ノウハウ多い。⇒企業のノウ リティを“手組み”することで、企業 ハウにする為にシステム化！ 競争力強化の支援が可能となる。 カスタム・パッケージ 手組み２．０の領域 規制 受注・出荷 対応 製造、研究 営業支援 のコア業務 生産管理 人材 管理 ﾏｽﾀ・ﾒﾝﾃﾅ Ｉ／Ｆ、 バ 品質 ﾝｽ・ｼｽﾃﾑ ＨＵＢ フ ッ 管理 購買 ロ ク オフィス支援 ン オ ｺﾐｭﾆ ト 管理 ｹｰｼｮﾝ フ エ 給与計算 会計 ン ィ ス 非構造化データ ド ＢＩ 制度会計 ＳＮＳ 文書管理 一体成型・パッケージ 汎用ツール 変更が少ない 11
- 12. 小刻みなリリースがもたらす“安定” 開発費用／案件 開発ﾘｽｸ・ ﾍﾞﾝﾀﾞｰ契 時代背景 ＳＥﾓﾁﾍﾞｰｼｮﾝ 見積誤差／案件 品質σ 約 小規模開発 （２１世紀） 費用安 ﾘｽｸ小・ ﾁｬﾚﾝｼﾞｬﾌﾞﾙ 準委任 ＆ 頻繁ﾘﾘｰｽ 多様性・エコ な積極性↑ 契約 、少量多品種 見積誤差小 ﾊﾞﾗﾂｷ小 生産の時代 大規模開発 （２０世紀） 費用高 ﾘｽｸ大・ 失敗できな （ﾘｽｸの ＆ 稀なﾘﾘｰｽ 大量生産・消 見積誤差大 ﾊﾞﾗﾂｷ大 い高いﾌﾟﾚｯ ）請負 費の時代 ｼｬｰ↓ 契約 “DEVOPS”wikipediaより ←左図はﾛｼﾞｽﾃｨｯｸｽ分野での理想 の在庫推移曲線に酷似 ・小規模リリースが実現できると、ア ジャイル開発の適用範囲が増大⇒ ﾋﾞｼﾞﾈｽ・ｱﾌﾟﾘｹｰｼｮﾝに幅ができる。 ・ﾀﾞｳﾝｻｲｼﾞﾝｸﾞも新規再構築も同 様にスモール・スタートが可能。 12
- 13. 本日のまとめ •大規模でもアジャイル開発を取り入れたいシステムがある。 •しかし、大規模開発にアジャイルの適用はリスクを伴う。 •ならば、大規模システムを小規模に刻み順次開発すればよい。 •システム、サブシステム分割の手法は様々有るが、中核となるイベン ト・トランザクションデータに着目するべし。 •切り出したトランザクションはデータＨｕｂに集中格納 し、更新／参照 のプロセスを疎結合に分離すべし。 •Ｈｕｂ上のトランザクション・レコードは汎化度合いが高い程、利用プロ セスの共通部品化が可能となるが、度合いに正解はない。 •ﾃﾞｰﾀHubによるシステム分割はアジャイル適用範囲を拡大する。 •小刻みなリリース単位は開発のリスクヘッジのみならず、ベンダー契 約体系やＳＥのモチベーションにまで変化をもたらす。 ⇒この変化は時代背景の要請により、もはや避けて通れない！！ 13
- 14. ご静聴ありがとうございました。