アジャイル開発を可能にするEA

3,536 views
3,510 views

Published on

オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2012年12月定例会発表資料です。
Open Community "Requirement Development Alliance" 2012/12 regular meeting of the presentation materials.

0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,536
On SlideShare
0
From Embeds
0
Number of Embeds
1,673
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

アジャイル開発を可能にするEA

  1. 1. アジャイル開発を可能にするEA(エンタープライズ・アーキテクチャ) 2012. 9.26 E-AGILITYカンファレンス E-AGILITY協議会理事 中山嘉之 要求開発アライアンス理事 2012年 9月 26日 1
  2. 2. 前回までのおさらい -1•1990年代後半~今日で大企業のERP導入が一段落 早い企業で2,3回目、遅いところでも初回のVupを迎える ↓•ERPは財務処理統制の強化や業務プロセスの標準化といったガバナンス面や効率化で企業に価値もたらした ↓•しかし事業競争力の強化には必ずしも貢献できていない ↓•企業のオリジナリティ溢れる業務は、パッケージシステムでは難しく、“手組み”による構築が必要 ↓•生産性と品質向上をとことん追求した“次世代手組2.0”注)問題認識の中心は年商数百億円超のいわゆる大企業だが、中小企業に当てはまらないわけではない。(寧ろ制約条件が少ないので問題は小さい) 2
  3. 3. ※手組み“2.0”を適用する領域 属人的ノウハウを企業のノウハウにす 変更が多い 属人的ノウハウ多い。⇒企業のノウ る為にシステム化(コアは業種、企業 によって若干異なる部分あり) ハウにする為にシステム化! カスタム・パッケージ 手組み2.0の領域 規制 受注・出荷 対応 製造、研究 営業支援 のコア業務 生産管理 人材 管理 マスタ・メンテナ I/F、バ 品質 ンス・システム HUB フッ 管理 購買 ロク オフィス支援 ンオ コミュニ ト 管理 ケーションフ エ 給与計算 会計 ンィス 非構造化データ ド BI 制度会計 SNS 文書管理 一体成型・パッケージ 汎用ツール 変更が少ない 3
  4. 4. 前回までのおさらい -2•エンタープライズな手組み2.0では、より高い生産性、継続性、品質(特にデータ品質)が求められる ↓•要求開発+アジャイルによりビジネス的価値を実証•クラウド環境で生産性、可用性、信頼性を確保•アーキテクチャ重視の設計で品質、保守性を担保 ↓案件毎に、①開発方法論がフィットしているか ②プロジェクト体制は適切か ③開発スコープが妥当か 等をチェックし上流工程から品質を作り込む ↓•日本特有の課題(多重請負契約の構造、ユーザ企業のベンダー丸投げ体質等)をクリアーする必要あり 4
  5. 5. 本題:大規模アジャイルのリスク回避策過大なスコープのアジャイル開発は、ビジネスニーズの発散・矛盾、部品点数の増大等で確かにリスクは増す ↓ウオータフォールで、作り手優位に開発すればリスクは軽減するが、ビジネス的価値創造が犠牲になり易い(Project は成功するがProduct が残念なケース) ↓•ならば開発単位を“大規模にしない”ことを考える ↓•複数の小さな開発単位に分割する方法を考えよう!(前回Eアジ寺子屋でメアリーの話に登場した“毎日のようにデプロイしている企業“をヒントに) 5
  6. 6. 開発単位を分割するのにEAは前提①まずは、社内システムの全貌がどうなっているのか、 現行システム(AsIs)をモデル図を用いて見える化する 精緻なモデル図を描く事を目的としない。 ⇒予めタイムボックス(2~3カ月)を定め、概念レベルの表記に留める②次にあるべきシステム(ToBe)をプロジェクト毎に記述 AsIs同様の表記法、概念レベル、“ビジネス視点”で、描く EAとモデリングツール(例) 6
  7. 7. 開発単位を分割する方法 -1①業務で分割:SCM(生産管理、 販売物流 営業支援販売物流、原価計算)、SFA、CRM、 TR TR会計といった“システム”の単位で システム TR- TR-Hub DWH疎結合に分割⇒各システムを跨ぐI/Fレコードを汎化 TR TR 生産管理 会計*してTR-DWHとしてHubに格納②アクターで分割:営業支援シス TR- DWHテム(SFA)を、フロントオフィス(現場セー TR-Hub セールス支 援 Largeルス)と、バックオフィス(管理スタッフ)に DWHサブシステム分割。 MART バックオフ⇒両システムを繋ぐI/Fレコードをクラ ィスウド上のHubに格納(レコードは特化) サブシステム 7
  8. 8. 開発単位を分割する方法 -2③ブラックBOX化した巨大ERPから、明示的にイベントを取り出し、これをベースに ERP順次開発する。(販売分析、原価計算などの (販売物流・ 生産管理・参照系が主) 会計)⇒GATEWAY製品*を用いてメインTRをクラウド上のHubに切り出す。(レコードは一部汎化) GATEWAY 販売※GATEWAY製品はERPベンダーの認定要 分析 他 TR- DWH※本アプローチ自身がシステムの可視化に!⇒①~③のHUBは、ネットワーク領域における“交差点整理“を目的とした”ESB”(Enterprise Service Bus)とは異なり、イベント・トランザクションデータを格納したDWHを保有する“データHUB”である。その仕組みは、更新(INSERTのみ)モジュールと、参照モジュールからなるシンプルなもの。 8
  9. 9. ※トランザクションレコードの汎化例 売上 製商品受払 受払 5W1H 受発注 伝票No 伝票No伝票No 伝票No 受払区分出荷年月日 取引区分 why 受/発注区分 品目コード 品目コード what製品コード 出庫年月日 資産部門コード顧客コード 取引先コード whom 入荷年月日 出庫年月日 担当部門コード who出庫拠点コード 入出庫拠点コード 入庫年月日売上部門コード 資産部門コード whose 製商品コード 出庫拠点コード出荷数量 出庫年月日 when1 取引先コード 入庫拠点コード売上金額 入庫年月日 when2 担当部門コード 取引先コード 出庫拠点コード where1 受発注数量 担当部門コード 入庫拠点コード where2 購入 取引金額 数量 How many 金額 数量伝票No 金額 How much入庫年月日 在庫移動 工場内受払 取引登録( )商品コード 伝票No 伝票No購入先コード 取引参照( ) 出庫年月日 受払区分入庫拠点コード 入庫年月日 品目コード購入部門コード 出庫拠点コード 取扱部門コード 〔 属性汎化=メソッド汎化 〕入庫数量 入庫拠点コード 出庫年月日 ⇒プロセス再利用性 大購入金額 製商品コード 入庫年月日 資産部門コード 出庫拠点コード 移動数量 入庫拠点コード 数量 金額 9
  10. 10. ※トランザクションとアプリケーション 売上 製商品受払 受払 5W1H 伝票No 伝票No 伝票No 受発注 why 受払区分 取引区分 出荷年月日 伝票No 品目コード what 品目コード 製品コード 受/発注区分 得意先コード whom 得意先コード 顧客コード 出荷年月日 担当部門コード whoSFA 出庫拠点コード 製品コード 担当部門コード 出庫年月日 when1 出庫年月日 売上部門コード 顧客コード when2 入庫年月日 入庫年月日 出荷数量 受発注 出庫拠点コード 出庫拠点コード 出庫拠点コード where1 売上金額 システム 担当部門コード 入庫拠点コード 入庫拠点コード where2 出荷数量 販売物流 数量 数量 How many 購入 売上金額 金額 金額 How much システム 伝票No 工場内受払 取引登録( ) 入庫年月日 在庫移動 商品コード 伝票No 取引参照( ) 伝票No 受払区分 購入先コード 出庫年月日 品目コード 入庫拠点コード 入庫年月日 得意先コード SCM 購入部門コード 入庫数量 品目コード 生産 担当部門コード (ERP) 出庫拠点コード 出庫年月日 購入金額 入庫拠点コード 管理 入庫年月日 購買 担当部門コード シス 出庫拠点コード 移動数量 テム システム 入庫拠点コード 数量 金額 10
  11. 11. “手組み2.0”の適用範囲拡大SCM(受注・出荷、生産、購買)や管理会計の領域でも、企業のオリジナ 変更が多い 属人的ノウハウ多い。⇒企業のノウリティを“手組み”することで、企業 ハウにする為にシステム化! 競争力強化の支援が可能となる。 カスタム・パッケージ 手組み2.0の領域 規制 受注・出荷 対応 製造、研究 営業支援 のコア業務 生産管理 人材 管理 マスタ・メンテナ I/F、バ 品質 ンス・システム HUB フッ 管理 購買 ロク オフィス支援 ンオ コミュニ ト 管理 ケーションフ エ 給与計算 会計 ンィス 非構造化データ ド BI 制度会計 SNS 文書管理 一体成型・パッケージ 汎用ツール 変更が少ない 11
  12. 12. 小刻みなリリースがもたらす“安定” 開発費用/案件 開発リスク・ ベンダー契 時代背景 SEモチベーション 見積誤差/案件 品質σ 約小規模開発 (21世紀) 費用安 リスク小・ チャレンジャブル 準委任& 頻繁リリース 多様性・エコ な積極性↑ 契約 、少量多品種 見積誤差小 バラツキ小 生産の時代大規模開発 (20世紀) 費用高 リスク大・ 失敗できな (リスクの& 稀なリリース 大量生産・消 見積誤差大 バラツキ大 い高いプレッ )請負 費の時代 シャー↓ 契約 “DEVOPS”wikipediaより ←左図はロジスティックス分野での理想 の在庫推移曲線に酷似 ・小規模リリースが実現できると、ア ジャイル開発の適用範囲が増大⇒ ビジネス・アプリケーションに幅ができる。 ・ダウンサイジングも新規再構築も同 様にスモール・スタートが可能。 12
  13. 13. 本日のまとめ•大規模でもアジャイル開発を取り入れたいシステムがある。•しかし、大規模開発にアジャイルの適用はリスクを伴う。•ならば、大規模システムを小規模に刻み順次開発すればよい。•システム、サブシステム分割の手法は様々有るが、中核となるイベン ト・トランザクションデータに着目するべし。•切り出したトランザクションはデータHubに集中格納 し、更新/参照 のプロセスを疎結合に分離すべし。•Hub上のトランザクション・レコードは汎化度合いが高い程、利用プロセスの共通部品化が可能となるが、度合いに正解はない。•データHubによるシステム分割はアジャイル適用範囲を拡大する。•小刻みなリリース単位は開発のリスクヘッジのみならず、ベンダー契約体系やSEのモチベーションにまで変化をもたらす。⇒この変化は時代背景の要請により、もはや避けて通れない!! 13
  14. 14. ご静聴ありがとうございました。

×