エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～
•
44 likes•11,951 views
2015年10月21日に行われたエンタープライズアジャイル勉強会2015年10月セミナーでの講演『エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～』の資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～
Similar to エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～ (20)
More from Yusuke Suzuki
More from Yusuke Suzuki (10)
Recently uploaded
Recently uploaded (8)
エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～
- 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
- 3. 講演者のバックグラウンド • SI事業のマネジメントをやってます »プライム/継続案件/5-15人程度のチームが複数 »自分はアーキテクト • 顧客業界はマルチですが、いわゆるSoE系の案 件が多いです »百貨店（流通）、クレジットカード、医療、企業情 報販売、通信、出版/メディア、製造 »SFA、CRM、EC、EDI、BIなど • アジャイルは好きですが、アジャイルだけが正 しいとは思っていません 2
- 4. Agenda • エンタープライズアジャイルとは • プロセス面の戦い • アーキテクチャ面の戦い • MSAについて • ドメインとプラットフォーム • まとめ 3
- 7. エンタープライズ 企業は営みの持続が重要 • 社会への責任 »安定、事業継続、ブランド… • 複数の利害関係者 »企画、開発、運用、運営… »組織、決裁プロセス、複数の業務、予算編成… • 複数の既存システム »会計、人事、販売、物流、生産… 6
- 8. エンタープライズとアジャイル エンプラはアジャイルではない • 普通の企業が事前に決めたいこと、 »提供サービス、リリース日、予算 • 企業の現場は基本的に変更を嫌う »スタッフや顧客への教育タイムラグ »変更は予定されなければならない • 一方で、持続のためには変化が必要 »アジャイルをいかに取り入れるのかは重要 7
- 11. プロセス面での戦い 10
- 13. プロジェクトマネジメントとは • PMBOK 12 立ち上げ 計画 遂行 コントロール 終結 統合 計画策定 計画実行 統合変更管理 スコープ （目的と範囲） 立ち上げ スコープ計画/定義 スコープ検証/変更管理 時間（期間） アクティビティ定義/順序設 定/期間見積 スケジュール作成 スケジュールコントロール コスト（予算） 資源管理 コストの見積/予算化 コストコントロール 品質 品質計画 品質保証 品質管理 人的資源 組織計画 要員調達 チーム育成 コミュニケー ション コミュニケーション計画 情報配布 実行報告 完了手続き リスク リスク・マネジメント計画 リスク識別 定性的/定量的リスク分析 リスクの監視・コントロー ル 調達 調達/引合計画 引合 発注先選定 契約管理 契約完了 計画 実行 計測 と 調整
- 15. WFとアジャイルの比較 ウォーターフォール • 計画/計測の確実性が高いことを前提に、全体を見 通すことで、実行の効率化を目指していく • 全体最適、全体的な整合性、全体から部分へ アジャイル • 計画/計測の不確実性が高いことを前提に、小さく 実行することで、調整の効率化を目指していく • 部分最適、調整による整合、部分の積み上げ、 14
- 17. アジャイルのダークサイド エンジニアの言い訳にしないこと 16 よく使う言葉 ダークサイド思考 顧客が欲しいものを作る ダメなのは顧客の責任 あとで変更できる 最初に決めるのが面倒 動くコードがすべて 説明しても分からない イテレーションごと計画 全体にはコミットしない 自動デプロイしています お前がテストしろ 優れたメンバーを確保 委任契約でリスクは発注元
- 18. アーキテクチャ面での戦い 17
- 19. アーキテクチャとは 18 IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）
- 21. アーキテクチャとは • システムのミッションに従い、システムのおか れた制約を前提としながら • システムに関わる複数の利害関係者の関心事を 整合させ、 »経営者、オーナー、ユーザー、プログラマ、 DBA、 インフラ屋、PM、上司、保守メンバー • ライフサイクル（設計から保守）まで意識した • システムの分け方と組合せ方のこと 20
- 23. マネジメントとは • 成果物は「プロジェクト活動」 »計画→実行→計測→調整の結果 • 「事後的」な作業 »計画通りに進めることが基本ではあるものの、修正 が必要であれば対応する »計画することは、とても大事 ▸アジャイルであっても計画幅が異なるだけで同じ • PMはヒーローになれる »アーキテクトの理想：予想外のことが何もない »無理なので、ギャップをPMがカバーする 22
- 27. MSAについて 26
- 28. MSAとは Microservices Architecture • サービスによるコンポーネント化 • ビジネスケイパビリティに基づく組織化 • プロジェクトではなくプロダクト • スマートなエンドポイントと単純なパイプ処理 • 分散ガバナンス • 分散データマネジメント • インフラの自動化 • フェイルを前提とした設計 • 進化的な設計 27 http://martinfowler.com/articles/microservices.html “Microservices”
- 29. MSAの2つの側面 技術面：分散配置と統合 • サービスによるコンポーネント化 • スマートなエンドポイントと単純なパイプ処理 • 分散データマネジメント • インフラの自動化 • フェイルを前提とした設計 文化面：持続性と分権 • ビジネスケイパビリティに基づく組織化 • プロジェクトではなくプロダクト • 分散ガバナンス • 進化的な設計 28
- 30. MSAの技術面 分散配置と統合 • サービスをサービスで構成する »静的要素の組み合わせから動的要素の組み合わせへ • メッセージによる統合 »個々の動的要素は標準プロトコルで協調動作する • サービスをマネージする »稼働監視、依存性管理、障害検知と復旧、ver管理 29
- 31. MSAの文化面 持続性と分権 • サービス全体を持続的に動作させる »ソフトウェア開発からITサービス運営へ • ドメイン固有の技術と運営 »ドメインごとの自主性を認め、標準化を否定する • ドメイン個別のライフサイクル »個別再構築の許容、あるいは犠牲的アーキテクチャ 30
- 32. MSAの背景 1/2 ウェブサービスのレガシー化 • いまやエンタープライズよりも巨大で複雑 • サービスの各要素ごとに特性や変化速度が大き く異なるため、標準化ができない »ビッグバンではなく、個別サービスの再構築 • 巨大なウェブサービスをマネージするための必 然的な選択がMSA 31
- 33. MSAの背景 2/2 ITサービスの共有化 • サービスレベルがコードで管理できる »SDxの流れ »コードによって「機能」だけでなく、「サービスレ ベル（≒非機能要件）」も管理できる • 動作構成パターンの共有化 »OSSは静的な構成の共有化を実現し、APIは動的な構 成の共有化を実現した »代表例がパブリッククラウドサービス 32
- 35. SOAとMSA SOA：トップダウン • 理想の世界、全体最適、変更対応 • 個別システムの集合を統治（すべき） MSA：ボトムアップ • 現実解、部分最適の集合、変化対応 • 全体サービスを分割して統治（するしかない） 34
- 36. システム統治としてのMSA アーキテクチャは統治の手法 • アーキテクチャはシステムを効率的に統治する ための手法 • 封建制→君主制→民主制への変化と似てる？ »乱立＝封建制：孤立した統治 »SOA＝君主制：偉大な王がいれば可能な統治 »MSA＝民主制：良識ある市民が必要な統治 • 「これが良い」と一概には言えない 35
- 39. MSAの実例 38
- 40. MSAの実例 エンタープライズのECサイト • 既存の社会的責任が維持されてしまう • 多様な利害関係者/ルール/システム • レガシー連携と最新トレンドへの追随 • 複雑性と柔軟性の課題が多い 39
- 41. ECサイトのドメイン設計 特性 • 流入→商品検索→購買 »それぞれでの複雑性や利用者数の違い »買わせるための属性と売るための属性の違い • 個人情報やカード番号 • 基幹（請求/在庫など）との連携 »データの整合性と鮮度のコントロール 40
- 42. ECサイトの構成例 • 商品管理 » 分かりやすい商品登録。商品とマスタの紐付け、撮影 • コンテンツ管理 » 的確なコンテンツ配信。タイミング、キャンペーン • 商品検索エンジン » 高速で探しやすい検索 • 商品受注 » 分かりやすく間違えない購買プロセス • 受注管理 » 確実で抜け漏れがない受注処理や配送処理 41
- 43. サービス配置例 42 商品 商品登録商品検索 購買 受注 受注管理 記事 記事登録 商品担当者 請求担当者 コンテンツ 担当者 消費者 記事表示 CMS 検索エンジン 商品管理 受注フロント 配送担当者 配送/請求ワークフロー アジャイル的がよい WF的がよい アジャイル的がよい WF的がよい
- 47. MSAのデザイン ドメイン • どこを分割し、いかに統合するのか？ • どういった技術とプロセスを適用するか？ プラットフォーム • 何を共有するのか？ • どういった技術とプロセスを提供するのか？ 46
- 49. MSAの先へ • MSAの発想は多くの企業において導入される »というか、きちんと全体設計ができていれば、程度 の差はあれどMSA的になるしかない »日本の問題は全体視点でアーキテクチャ設計する人 がいないこと • 今後、PaaSの多様化が進むはず »現時点はプラットフォームを決めたほうが楽 »Domain PaaS、Private PaaSの登場 48
- 50. 振り返り 49
- 55. まとめ 54
- 56. まとめ 1/3 • プロセスは対象システムごとに適切に考える »アジャイルとウィーターフォールのバランス • アーキテクチャ設計で決められないものは適切 にマネジメントに投げる »事前決定とリスクのバランス • 社内には様々なドメインがあるので、それぞれ に適切なプロセスとアーキテクチャがある »技術進歩によって、ドメイン横断でプラットフォー ムが提供できる 55
- 57. まとめ 2/3 56 • 全社視点からITサービスを考えた結論としては 当たり前 »Amazon（1994年～）、Netflix（1997年～） • MSAは「エンタープライズ・アジャイル」の話 »組織にアジャイル要素を取込むには、アジャイル手 法をスケールして適用するのではなく、ドメインご とに最適化する »アジャイルでない部分もあるべき
- 58. まとめ 3/3 • 残念ながら、一気には整備できない • 全体視点で段階的に進めるしかない »全社システム視点のデザインは重要 »つまり、全社視点でのアーキテクトがいないとダメ • そうするしかないのは間違いない »「日本でどうするべきか」は大事な議論 »勉強会を通じて議論ができれば 57