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