1.
エンタープライズアジャイルと全体最適について
～アーキテクチャ設計とウォーターフォールの必要性～
2015/10/21
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
エンタープライズアジャイル勉強会
2015年10月セミナー
https://easg.smartcore.jp/

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

5.
エンタープライズ
アジャイルとは
4

6.
アジャイル
Agile＝俊敏、敏捷、機敏
• 過去において主流であったマネジメントスタイ
ルへのアンチテーゼ
• アジャイルソフトウェア宣言
»プロセスやツールよりも個人と対話を、
»包括的なドキュメントよりも動くソフトウェアを、
»契約交渉よりも顧客との協調を、
»計画に従うことよりも変化への対応を
5

7.
エンタープライズ
企業は営みの持続が重要
• 社会への責任
»安定、事業継続、ブランド…
• 複数の利害関係者
»企画、開発、運用、運営…
»組織、決裁プロセス、複数の業務、予算編成…
• 複数の既存システム
»会計、人事、販売、物流、生産…
6

8.
エンタープライズとアジャイル
エンプラはアジャイルではない
• 普通の企業が事前に決めたいこと、
»提供サービス、リリース日、予算
• 企業の現場は基本的に変更を嫌う
»スタッフや顧客への教育タイムラグ
»変更は予定されなければならない
• 一方で、持続のためには変化が必要
»アジャイルをいかに取り入れるのかは重要
7

9.
エンタープライズアジャイル
持続のための変化に向けて
• エンタープライズという持続的で複雑で変化を
嫌う環境において、アジャイルという変化と適
応を実現する挑戦のこと
»いかに良いITサービスを作り上げるか
»いかに顧客とエンジニアを幸せにするか
• 狭義には、そのための開発論
»いかにシステム開発を効率化するか
»いかに探索的にシステム開発を行うか
8

10.
戦いに向けて
バランスを取る
• プロセス面での戦い
»アジャイル的とウォーターフォール的
• アーキテクチャ面での戦い
»アーキテクチャをどこまで事前に決定すべきか
9

11.
プロセス面での戦い
10

12.
プロジェクトマネジメントとは
計画し、実行し、計測し、調整する
11
計画
実行
計測
調整

13.
プロジェクトマネジメントとは
• PMBOK
12
立ち上げ 計画 遂行 コントロール 終結
統合 計画策定 計画実行 統合変更管理
スコープ
（目的と範囲）
立ち上げ スコープ計画/定義 スコープ検証/変更管理
時間（期間） アクティビティ定義/順序設
定/期間見積
スケジュール作成
スケジュールコントロール
コスト（予算） 資源管理
コストの見積/予算化
コストコントロール
品質 品質計画 品質保証 品質管理
人的資源 組織計画
要員調達
チーム育成
コミュニケー
ション
コミュニケーション計画 情報配布 実行報告 完了手続き
リスク リスク・マネジメント計画
リスク識別
定性的/定量的リスク分析
リスクの監視・コントロー
ル
調達 調達/引合計画 引合
発注先選定
契約管理
契約完了
計画 実行
計測
と
調整

14.
WFからアジャイルへ
• ウォーターフォールにありがちな失敗
»計画の失敗：計画の精度が悪かった
»計測の失敗：進捗を測り間違えた
»調整の失敗：方向修正する話し合いができなかった
• だから、アジャイルでは
»計画：精度が出るぐらい小さな計画にすればいい
»計測：動くソフトウェアで計測すればいい
»調整：定期的にみんなで見直すことにすればいい
13

15.
WFとアジャイルの比較
ウォーターフォール
• 計画/計測の確実性が高いことを前提に、全体を見
通すことで、実行の効率化を目指していく
• 全体最適、全体的な整合性、全体から部分へ
アジャイル
• 計画/計測の不確実性が高いことを前提に、小さく
実行することで、調整の効率化を目指していく
• 部分最適、調整による整合、部分の積み上げ、
14

16.
プロセス面での戦い方
考え方の違いであって優劣ではない
• プラクティスは共通して重要
»情報共有：チケット、レポジトリ
»リスクの先行評価：PoC、プロトタイプ
»自動化：自動テスト、自動デプロイ
• むしろ、積極的な使い分けが重要
»計画重視：システム連携、法令順守…
»調整重視：UI、インシデント対応…
15

17.
アジャイルのダークサイド
エンジニアの言い訳にしないこと
16
よく使う言葉 ダークサイド思考
顧客が欲しいものを作る ダメなのは顧客の責任
あとで変更できる 最初に決めるのが面倒
動くコードがすべて 説明しても分からない
イテレーションごと計画 全体にはコミットしない
自動デプロイしています お前がテストしろ
優れたメンバーを確保 委任契約でリスクは発注元

18.
アーキテクチャ面での戦い
17

19.
アーキテクチャとは
18
IEEE-Std-1471-2000 Recommended Practice for Architectural Description
of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）

20.
アーキテクチャとは
19
利害関係者の
関心事 ビューポイント
ビュー
ミッション
システム
制約（環境）
モデルによって記述

21.
アーキテクチャとは
• システムのミッションに従い、システムのおか
れた制約を前提としながら
• システムに関わる複数の利害関係者の関心事を
整合させ、
»経営者、オーナー、ユーザー、プログラマ、 DBA、
インフラ屋、PM、上司、保守メンバー
• ライフサイクル（設計から保守）まで意識した
• システムの分け方と組合せ方のこと
20

22.
アーキテクチャ設計とは
• 成果物は「アーキテクチャ」
»構造の設計図
»構造は一度決定すると変更しにくい
• 「事前的」な作業
»先に決定しないと前に進まない構造は一度決定する
と変更コストが高い
»事前的である以上、予測や方向づけが重要
21

23.
マネジメントとは
• 成果物は「プロジェクト活動」
»計画→実行→計測→調整の結果
• 「事後的」な作業
»計画通りに進めることが基本ではあるものの、修正
が必要であれば対応する
»計画することは、とても大事
▸アジャイルであっても計画幅が異なるだけで同じ
• PMはヒーローになれる
»アーキテクトの理想：予想外のことが何もない
»無理なので、ギャップをPMがカバーする
22

24.
アーキテクチャ面での戦い方
事前決定とリスクのバランス
• リスクとは不確定要素であり、確定できないな
ら決めてはならない
• 決められないことの決定を遅らせるための手を
打って、マネジメントにゆだねる
»ドメイン、コンポーネント、モジュールなどによる
分割が腕の見せ所
▸分割をどうすべきかは割愛
23

25.
アーキテクチャの敗北
アーキテクチャからアジャイルへ
• 「象牙の塔のアーキテクト」という批判
»プロジェクトの柔軟性を確保するためには事後的な
調整を重視することが重要だった
• もちろんアーキテクチャは重要
»アジャイルでも「必要なだけ決める」ことは大事
»マネジメントには、必ず技術的な土台が必要
»優れたアジャイラーは優れたアーキテクト
24

26.
アーキテクチャの逆襲
柔軟なアーキテクチャの登場
• アーキテクチャが十分に柔軟であれば、マネジ
メント上の柔軟性に頼らないでも良くなる
• 近年でトレンドになりつつあるのがマイクロサ
ービスアーキテクチャ（MSA）
25

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

34.
MSAを理解する
粒度ではなく関係性に注目を
• どの粒度でもよい（マイクロに惑わされない）
»アプリとコンポーネント
»システムとサブシステム
»システム全体と個別システム
• 重要なのはサービス相互の関係性のあり方
»複雑なものを、いかに管理するのか
»粒度を無視して、SOAとMSAを比較する
33

35.
SOAとMSA
SOA：トップダウン
• 理想の世界、全体最適、変更対応
• 個別システムの集合を統治（すべき）
MSA：ボトムアップ
• 現実解、部分最適の集合、変化対応
• 全体サービスを分割して統治（するしかない）
34

36.
システム統治としてのMSA
アーキテクチャは統治の手法
• アーキテクチャはシステムを効率的に統治する
ための手法
• 封建制→君主制→民主制への変化と似てる？
»乱立＝封建制：孤立した統治
»SOA＝君主制：偉大な王がいれば可能な統治
»MSA＝民主制：良識ある市民が必要な統治
• 「これが良い」と一概には言えない
35

37.
MSAの発想
新しい理想論ではなく現実解
• Amazon.comやNetflixなどの先端的なクラウ
ドサービスの観測結果であり、理想論というよ
り現実解
»適切な手法を模索していたら、自然にそうなった
• ではあるが、それを先鋭化して理想論的になり
つつある状況
36

38.
MSAとは
組織におけるITサービス運営論
• 「アーキテクチャとマネジメントはドメインご
とに最適化される」という当然の結論
»組織では、全体として統一化されたアーキテクチャ
とマネジメントは適用できない
»そのために適切なドメイン分割とし、可能な限り疎
結合にする
37

39.
MSAの実例
38

40.
MSAの実例
エンタープライズのECサイト
• 既存の社会的責任が維持されてしまう
• 多様な利害関係者/ルール/システム
• レガシー連携と最新トレンドへの追随
• 複雑性と柔軟性の課題が多い
39

41.
ECサイトのドメイン設計
特性
• 流入→商品検索→購買
»それぞれでの複雑性や利用者数の違い
»買わせるための属性と売るための属性の違い
• 個人情報やカード番号
• 基幹（請求/在庫など）との連携
»データの整合性と鮮度のコントロール
40

42.
ECサイトの構成例
• 商品管理
» 分かりやすい商品登録。商品とマスタの紐付け、撮影
• コンテンツ管理
» 的確なコンテンツ配信。タイミング、キャンペーン
• 商品検索エンジン
» 高速で探しやすい検索
• 商品受注
» 分かりやすく間違えない購買プロセス
• 受注管理
» 確実で抜け漏れがない受注処理や配送処理
41

43.
サービス配置例
42
商品 商品登録商品検索
購買
受注 受注管理
記事 記事登録
商品担当者
請求担当者
コンテンツ
担当者
消費者
記事表示
CMS
検索エンジン
商品管理
受注フロント
配送担当者
配送/請求ワークフロー
アジャイル的がよい
WF的がよい
アジャイル的がよい
WF的がよい

44.
ドメインと
プラットフォーム
43

45.
プラットフォーム
MSAが前提とするもの
• 「アーキテクチャとマネジメントはドメインご
とに最適化される」が「プラットフォームは共
通化されている」
»AmazonもNetflixもAWSのヘビーユーザー
• MSAの裏側には、何を個別化し、何を共有化す
るという議論がある
44

46.
プラットフォームの利用
45
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
データ
SaaS
PaaS
IaaS
仮想マシン
バッチ
リモート実行
モバイルアプリ
API管理
プッシュ通知
リアルタイム分析
RDB
NoSQL
キャッシュ
ストレージ
サーチ
Hadoopクラスタ
機械学習
ストリーム処理
データ変換
イベント処理
仮想ネットワーク
負荷分散
ロードバランサ
DNS
VPN
メディア変換
CDN
ハブ処理
バックアップ
リカバリ
認証認可
開発ツール
スケジューラー
インフラ自動化

47.
MSAのデザイン
ドメイン
• どこを分割し、いかに統合するのか？
• どういった技術とプロセスを適用するか？
プラットフォーム
• 何を共有するのか？
• どういった技術とプロセスを提供するのか？
46

48.
ドメインとプラットフォーム
バランスをいかに取るか
• 独立させすぎると無駄が増える
• 共有しすぎると対応できない
47

49.
MSAの先へ
• MSAの発想は多くの企業において導入される
»というか、きちんと全体設計ができていれば、程度
の差はあれどMSA的になるしかない
»日本の問題は全体視点でアーキテクチャ設計する人
がいないこと
• 今後、PaaSの多様化が進むはず
»現時点はプラットフォームを決めたほうが楽
»Domain PaaS、Private PaaSの登場
48

50.
振り返り
49

51.
エンタープライズアジャイルとは
• エンタープライズとアジャイルには、そもそも
相反する部分がある
»企業にとって様々なことを事前に決定するのは必要
• エンタープライズアジャイルとは「エンタープ
ライズという持続的で複雑で変化を嫌う環境に
おいて、アジャイルという変化と適応を実現す
る挑戦」のこと
»狭義には、そのための方法論でプロセスとアーキテ
クチャから考える必要がある
50

52.
プロセス面の戦い方
• いわゆるアジャイルソフトウェア開発プロセス
だけが正解ではない
»ウォーターフォール
▸計画/計測の確実性が高いことを前提に、全体を見通すこと
で、実行の効率化を目指していく
▸全体最適、全体的な整合性、全体から部分へ
»アジャイル
▸計画/計測の不確実性が高いことを前提に、小さく実行する
ことで、調整の効率化を目指していく
▸部分最適、調整による整合、部分の積み上げ、
51

53.
アーキテクチャ面での戦い方
• アーキテクチャは事前決定せざるを得ない
»マネジメントは事後的に調整を可能にする
»事前的に決めるべきコトと決めないコトを決めて、
プロジェクトマネジメントの中で解決していく
• そのためにドメイン、コンポーネント、モジュ
ールなどによる分割していおくことが重要
52

54.
MSAとは
• マイクロサービスアーキテクチャは、組織にお
けるITサービス運営論
»Webサービスのレガシー化＋技術進歩
• 「アーキテクチャとマネジメントはドメインご
とに最適化される」という当然の話
»一方で「プラットフォームによる共有化」も考える
53

55.
まとめ
54

56.
まとめ 1/3
• プロセスは対象システムごとに適切に考える
»アジャイルとウィーターフォールのバランス
• アーキテクチャ設計で決められないものは適切
にマネジメントに投げる
»事前決定とリスクのバランス
• 社内には様々なドメインがあるので、それぞれ
に適切なプロセスとアーキテクチャがある
»技術進歩によって、ドメイン横断でプラットフォー
ムが提供できる
55

57.
まとめ 2/3
56
• 全社視点からITサービスを考えた結論としては
当たり前
»Amazon（1994年～）、Netflix（1997年～）
• MSAは「エンタープライズ・アジャイル」の話
»組織にアジャイル要素を取込むには、アジャイル手
法をスケールして適用するのではなく、ドメインご
とに最適化する
»アジャイルでない部分もあるべき

58.
まとめ 3/3
• 残念ながら、一気には整備できない
• 全体視点で段階的に進めるしかない
»全社システム視点のデザインは重要
»つまり、全社視点でのアーキテクトがいないとダメ
• そうするしかないのは間違いない
»「日本でどうするべきか」は大事な議論
»勉強会を通じて議論ができれば
57