アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとアジャイル
プロジェクトをまともに進めるための両輪について
グロースエクスパートナーズ（株）
鈴木雄介
2014年12月20日

自己紹介
• 鈴木雄介
–グロースエクスパートナーズ（株）
» 執行役員
» SI事業の統括マネージャー/ITアーキテクト
–日本Javaユーザーグループ
» 会長
–ブログ：http://arclamp.hatenablog.com/
–Twitter：@yusuke_arclamp
1

自己紹介
• グロースエクスパートナーズ（株）
–受託開発を中心としたソフトウェア開発企業
» http://www.gxp.co.jp/
–顧客（全てプライム）
» 医療器械メーカー
» 百貨店
» 企業信用情報提供
» 通信
» オフィス機器＆医療機器メーカー
» 雑誌＆オンラインメディア
2

Copyright© Growth xPartners, Inc. All rights reserved. 3
アーキテクチャとマネジメント
https://www.flickr.com/photos/splorp/6264402594

シャボン玉を
デザインする

• シャボン玉をデザインするときに、どんなに完
璧な丸を紙の上に描いても、いいシャボン玉は
できないわけで、そのシャボン玉をつくる装置
、そこにシャボン液がたくさん溜まるシステム
をつくらなければいけない。
• -阿部雅世
5
http://www.axisjiku.com/jp/2009/12/16/axisフォーラム-阿部雅世さん講演-レポート-その1（全3/
http://opengl.jp/blogger/2009/07/masayo-ave-at-axis.html

今、何が起きているのか
7

• 企業におけるITの役割
8
事務処理を自動化する
管理統制を拡張する
事業に価値を加える
昔
この
10年
最近

• たとえばトヨタフレンド
9
toyota.jp プリウスPHV | 楽しくお使いいただくための会員サービス | トヨタフレンド
http://toyota.jp/priusphv/001_p_004/drivesupport/toyotafriend/

• 「事業に価値を加える」ためのIT
–商品の継続的な利用を促す
–商品の位置づけを段階的に変えていく
» あるいは、時代の流れで変わってしまったことに対応する
–既存商品をベースにした新たな収益の獲得
• 基本的には試行錯誤をしていかないといけない
–何が正解かは、誰も分からない
10

• 企業がIT屋に求めること
–良いアプリケーションが作れても、ITサービスとし
て運営がうまくできなければ意味が無い
11
アプリケーションを
いかに早く、安く、正確に作るか
ITサービスを
いかにうまく運営するか

• アプリケーションを作る
–仕様（静的）を定義する
–開発者が作る
–プロジェクトが終われば終わり
• ITサービスを運営する
–利用（動的）からフィードバックを受ける
–様々な人が関わりながら動かす
–継続的で終わりのない活動
12

ITサービスの運営
13

• ITサービスを運営する
–「ITを通じた企業と利用者の関係」のこと
–実際の運営は従業員によって行われる
14
利用者従業員
企業
※サービストライアングルからのインスパイア
IT

• ITサービス運営モデル v0.2
15
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス

16
特徴例
利用者の
体験価値
• 利用者が体験して感じるもの
• 利用者によって評価が異なる
• ＡさんとＢさんで評価
が異なる
サービスの
振る舞い
• 外部から見てわかる振る舞い
• 誰がテストしても同じ結果
• 仕様（機能と非機能）
• 仕様とテストケース
• 品質特性
• API
動的な構成 • システム実行時の要素と相互作
用
• 流れ、実行、プロセス
• インスタンス
• 処理
• 実行環境/インフラ
静的な構造 • 成果物が配置された静的な構造
• 後に残り、参照可能
• ソースコード
• クラス、テーブル定義
• ドキュメント

17
特徴例
企画
プロセス
• ITサービスの振る舞いを管理する
• 追加や変更を要求する
• 売上
• 要求と受入
開発
プロセス
• 静的な構造を作る
• 追加し、変更する
• 素早さが求められる
• リリース計画
• 開発ツール
運用
プロセス
• 動的な構成を管理する
• 追加や変更を受け入れる
• 安定が求められる
• デプロイ
• 監視
業務
プロセス
• ITサービスを利用者に届ける
• 利用者に追加や変更を伝える
• 安定が求められる
• 現場
• 窓口

• ITサービス運営への理解 1/4
18
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス
1.異なる関心事を持つ利害関係者がいる

19
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス
2.価値は利用者の体験によって定義される

20
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス
3.複雑な構成要素によって成り立つ

21
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス
4.フィードバックによって持続的に成長する

• ITサービス運営で考えるべきこと
–1.異なる関心事を持つ利害関係者がいる
–2.価値は利用者の体験によって定義される
–3.複雑な構成要素によって成り立つ
–4.フィードバックによって持続的に成長する
• ITサービスをうまく運営するには、これら全体
をデザインする必要がある
22

アーキテクチャ
23

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

25
利害関係者の
関心事ビューポイント
ビュー
ミッション
システム
制約（環境）
モデルによって記述

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

マネジメント
27

マネジメント
• プロジェクトマネジメントとは
–計画し、実行し、計測し、調整する
28
計画
実行
計測
調整

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

マネジメント
• ウォーターフォールとアジャイル
–「考え方の違い」であって、優劣ではない
–ウォーターフォール
» 計画/計測の確実性が高いことを前提に、全体を見通すこと
で、実行の効率化を目指していく
» 例：既存システム連携、法令準拠、システム相手のこと
–アジャイル
» 計画/計測の不確実性が高いことを前提に、小さく実行する
ことで、調整の効率化を目指していく
» 例：UI、インシデント発生への対応、人間相手のこと
30

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

マネジメント
• ウォーターフォールが悪ではない
–技術的方式に問題があるならPoCやプロトタイピン
グで不確実性を先に取り除く
–むしろ、積極的な使い分けが重要
» システム連携部分は計画重視、UIは調整重視
32

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

34

• アーキテクチャとマネジメント
35
アーキテクチャマネジメント
目的プロジェクトの目的
を技術的に表現する
プロジェクトの目標
を達成する
手法予測し、方向性を設
定する
計画し、計測し、調
整する
成果対象物の分け方と組
み合わせ方
プロジェクトの成果
物そのもの
行動事前的に決定事後的に対応

• ITサービス運営では切り離せない
36
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス

• アジャイルでも「グランドデザイン」は重要
–アーキテクチャ設計は、きちんとやる
–考える暇がないなら定石に当てはめてもいい
» 例：とりあえず流行のフレームワークを採用する
» そのフレームワークが解決しているドメインの相似性につ
いて考慮する
» 当てはまっていなかった時は大きな問題になる
37

38
内圧
作るコト
戦術/設計/実装
外圧
使うコト
ビジョン/要求/要件

内圧
作るコト
戦術/設計/実装
39
外圧
使うコト
ビジョン/要求/要件
つなぐコト
続けるコト
マネジメント

アーキテクトの仕事
40

• アーキテクトの仕事は「アーキテクチャをデザ
インすること」
• そのために
–利害関係者を参加させ、関心事を理解する
–関心事を整理し、整合させるように調整する
–その関心事に沿ってITサービス運営要素を定義する
» 非常に幅広い要素について検討が必要となる
41

• たとえば
42
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス
こういうクラス
分割が必要だ
こういうトランザクショ
ン増加が想定される
この動きに、これ
だけの並行処理が
求められる
こういう導線を通
るはずだ
このKPIに従って
評価すべきだ
こういう要員と手
法で作るべきだ
ここの数値を監視
すべきだ
この時期は、これ
だけの作業がある

• 基礎知識
–ITトレンドの知識
–対象ドメインのビジネス知識
–対象企業のIT知識
• プロセスとのかかわり
–開発工程とアーキテクチャ設計の関係を定義する
• 個人のスキル
–個人レベルでの能力発揮
43

• 基礎知識（技術トレンド）
44
Networking
Virtualization
Storage
Servers
OS
Middleware
Code
Configuration
Runtime
Data
SaaS
PaaS
IaaS
ロードバランサー
ストレージアーカイブ
CDN
データ転送
RDB・NoSQL
データウェアハウス
メモリキャッシュ
データストリーム
分散処理
オーケストレーション
サーチ
ストリーミング
メール配信
メッセージキュー
プッシュ通知
ワークフロー
課金
メディア変換
コンテナ
デプロイ
ユーザー活動分析
モニタリング
認証認可

• 基礎知識（ドメインのビジネス知識）
–「変化の濃淡と方向」を学ぶ
» 年間スケジュール（量、数、質）＝変化の幅
» ルールとパラメタ＝変化の境界線
» 業界動向＝変化の方向性
–もちろん自分で勉強することも大事だけど、顧客に
聞くのが一番
» 顧客がドメインスペシャリスト
» 顧客と話すための最低限の知識は礼儀として学んでおく
45

• 基礎知識（対象企業のIT知識）
–エンタープライズ・アーキテクチャ上の最適化
–分かりやすくは「他システムとの関係性」
46
戦略性
固有性
汎用性
共通性
複雑
単純

• プロセスとの関わり
–どのタイミングで誰と話して、何を決めるのか
47
要件定義
外部設計
内部設計
実装ユニットテスト
内部結合テスト
外部結合テスト
システムテスト（受入）
企画運用テストあるいは運営
企業やドメインへの理解
アーキテクチャ方針の策定
アーキテクチャ方式の策定
アーキテクチャ変更のトレース
アーキテクチャ方式課題の解決
アーキテクチャ方針課題の解決
アーキテクチャの評価
アーキテクチャの管理

• 個人スキル
–コミュニケーションスキル！
» 理解する
» 整理する
» 表現する
» 調整する
48

• とはいえ、全部は不可能
–基礎知識はチームが重要
–プロセスはPMとの連携が重要
–個人スキルは精進してください
–なんにせよ、経験から学ぶことは多い
• 組織との関わり方が重要
–その企業における「アーキテクト」を定義し、共有
していくことが必要
49

設計の進め方
50

設計の進め方
• Microservices
–ファウラー先生が提唱
» http://martinfowler.com/articles/microservices.html
» 海外では、かなりブームになっている雰囲気
–ITサービス運営のアーキテクチャの考え方を良く表
している
» 個々に独立したサービスによって全体のサービスが構成さ
れている
▸ データ、ガバナンス、手法なども完全に独立
» 個々のサービスは個々のチームによって開発・運用される
▸ 開発と運用は一体化され、個々に責任を持つ
51

設計の進め方
• Microservicesの9つの特徴
– Componentization via Services/サービスによるコンポーネ
ント化
– Organized around Business Capabilities/ビジネスケイパビ
リティに基づく組織化
– Products not Projects/プロジェクトではなくプロダクト
– Smart endpoints and dumb pipes/スマートなエンドポイ
ントと単純なパイプ処理
– Decentralized Governance/分散ガバナンス
– Decentralized Data Management/分散データマネジメント
– Infrastructure Automation/インフラの自動化
– Design for failure/フェイルを前提とした設計
– Evolutionary Design/進化的な設計
52

設計の進め方
• Microservicesは既に起きていること
–たとえばECサイト
» 管理画面から商品を登録する
» 商品を検索する
» 商品をカートにいれて購入する
» 受注を処理して請求や物流手配を行う
» 記事コンテンツを更新する
–これらは、全て異なるドメインとして定義できる
53

設計の進め方
• ドメインの発見には、変化の境界を見極める
–外的変化要因になるもの
» ユーザーの役割が異なる
» ユーザーによって利用されるサイクルが違う
–その他の変化要因
» セキュリティ
–必ず境界にするわけではない。パターンにくくって
いくことが大事
54

設計の進め方
• それぞれのケースにおける分析
55
ビジネスケース利用者サイクル
管理画面から商品を登
録する
商品担当者毎日
商品を検索する消費者かなり頻繁に
商品をカートにいれて
購入する
消費者それなりの回数
受注を処理して請求や
物流手配を行う
受注担当者
配送担当者
受注のたびに
記事コンテンツを更新
する
コンテンツ担当者毎週

設計の進め方
• 非機能についても考えることが必要
– 機能適合性
» 実装された機能がニーズを満たす度合
– 性能効率性
» システムの実行時の性能や資源効率の度合
– 互換性
» 他製品やシステムと機能や情報を共有、変換できる度合
– 使用性
» 効果的、効率的に利用できる度合
– 信頼性
» 必要時に実行することができる度合
– セキュリティ
» 不正にアクセスがされることなく、情報やデータが保護される度合
– 保守性
» 効果的、効率的に保守や修正ができる度合
– 移植性
» 効果的、効率的に他のハードウェアや実行環境に移植できる度合
56

設計の進め方
• 品質特性 1/2
57
品質特性特性の概要副品質特性概要
機能適合性
実装された機能が
ニーズを満たす度合
完全性ニーズを機能がユーザの目的やタスクを包含している度合
正確性必要な精度で正確な結果を与える度合
適切性機能が定められたタスクや目的を円滑に遂行する度合
性能効率性
システムの実行時の
性能や資源効率の度
合
時間効率性実行時のシステムの応答時間、処理時間などの処理能力の度合
資源利用性実行時に使用する資源量や種類
キャパシティ要求を満たすための製品やシステムのパラメータの最大許容値
互換性
他製品やシステムと
機能や情報を共有、
変換できる度合
共存性
他製品へ負の影響を与えず、共通の環境や資源を共有して効果
的に実行する度合
相互運用性
2つ以上の製品やコンポーネント間で情報を交換、利用できる
度合
使用性
効果的、効率的に利
用できる度合
適切度認識性ニーズに適した利用かどうか認識できる度合
習得性システムの使い方の学習ができる度合
運用性運用や管理のしやすさの度合
ユーザエラー防止性誤操作しないように保護する度合
ユーザインタフェー
スの快美性
ユーザインタフェースが親しみがあり満足感のある応答ができ
る度合
アクセシビリティ幅広い層の特徴や能力を持つ人々が利用できる度合
信頼性
必要時に実行するこ
とができる度合
成熟性通常時に信頼性のニーズを満たす度合
可用性必要時に運用、接続できる度合
障害許容性障害時に運用できる度合
回復性障害時にデータやシステムが回復したり再構築できる度合
情報システム/ソフトウェアの品質メトリクスセット http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf

設計の進め方
• 品質特性 2/2
58
品質特性特性の概要副品質特性概要
セキュリ
ティ
不正にアクセスがさ
れることなく、情報
やデータが保護され
る度合
機密保持性許可された者のみがアクセスできるようデータを保証する度合
インテグリティ
プログラムやデータへの変更において未許可なアクセスを防止
する度合
否認防止性イベントやアクションの発生を証明する度合
責任追跡性エンティティの実行が唯一であることを証明する度合
真正性
リソースや物事の身元が要求されたものであることを証明でき
る度合
保守性
効果的、効率的に保
守や修正ができる度
合
モジュール性
変更による他コンポーネントへの影響が最少で済むよう、独立
したコンポーネントで構成される度合い
再利用性他のシステムや資産を構築する際に利用できる度合
解析性
変更部分や障害原因の特定のために診断したり、変更による影
響を評価する際の効果性、効率性の度合
変更性欠陥や品質の低下なく変更が効果的、効率的にできる度合
試験性
テスト基準を確立し、評価するために実行する際の効果性、効
率性の度合
移植性
効果的、効率的に他
のハードウェアや実
行環境に移植できる
度合
順応性
別のもしくは進化したハードウェアやソフトウェアや他の運用
環境に効果的、効率的に順応できる度合
設置性
正しくインストール、もしくはアンインストールする際の効果
性、効率性の度合
置換性
同一の目的、環境下で他のソフトウェア製品に置換（リプレー
ス）できる度合
情報システム/ソフトウェアの品質メトリクスセット http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf

• ドメインと技術要素のマッピング
設計の進め方
59
商品商品登録
商品検索
購買
カート
受注受注管理
記事記事登録
商品担当者
受注担当者
コンテンツ
担当者
消費者
記事表示
CMS
検索エンジン
管理システム
フロントシステム
配送担当者

設計の進め方
• ドメインと技術要素のマッピング
• もちろん、これだけが正解なわけではない
–個別のITサービスごとに適した構成がある
–たとえばクラウドサービスを活用すると、もっとコ
ストが減るかもしれない
60
構成要素特性技術例
記事管理記事登録のワークフロー管理、決
められた時間での公開
CMS
商品検索ハイパフォーマンス Lucene
購買管理複雑なロジックと使いやすさ MVC＋SQL
バックエンドパターン化された画面 JSF+JPA

設計の進め方
• さらに個別のドメイン毎にサービスを構成する
要素に求められることが異なる
61
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス

設計の進め方
• 記事管理（CMS）
62
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス
CMSを採用
CMSカスタマイ
ズ設計書と専門
エンジニア
CMSカスタマイ
ズ設計書と専門
エンジニア
テンプレート更新はデザイ
ナ、商品担当と連携して取
材し、コンテンツを制作
SEOを向上させ
るためのタグを
追加したい
ホワイトペーパー
に従った構成
制作ワークフ
ロー制御とタイ
マー公開
記事を読んで商
品を理解する

設計の進め方
• 商品検索（Lucene）
63
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス
検索エンジンの
Luceneを採用
ランキングや重
み付けの調整
結果の並び順を
最適化したい
Luceneサーバを独立し、
定期的に商品データを取
り込ませる
応答時間を監視し、SLA
を確認する
APIを経由して呼ばれた
結果を返却する
求めている商品
が見つかる
商品登録をしたも、リ
アルタイムに変わるわ
けではないことを理解

設計の進め方
• 購買管理（MVC+SQL）
64
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス
自由度が高い素の
MVCとSQLで構成。
カード決済は外部
ASP利用
難易度が高いの
でハイスキル要
員をアサイン
新しい決済手段
を追加したい
外部ASPのSLA計測
不正アタックの検出
ASPに障害があればエラーで
はなく処理をスキップし、手
動決済を実施する
同時購買点数に応
じて割引を実施
ASP障害時は手
動でオーソリ
商品が簡単に買
える

設計の進め方
• バックエンド（JSF+JPA）
65
利用者の
体験価値
サービスの
振る舞い
静的な
構造
開発
プロセス
動的な
構成
企画
プロセス
運用
プロセス
業務
プロセス
パターン化され
たUIしか受付け
ない
JSF+JPAで可能
な限り生産性を
向上
安定稼働を監視
コールドスタンバイで
の信頼性確保で十分
役割分担によるプロセ
ス、ユーザの追加
新しい商品を扱うこと
で属性の追加要求
受注処理や配送処理が
簡単に行える

設計の進め方
• Microservicesの落とし穴
–ドメイン毎の独自性を強くすると、全体的な保守性
が下がってくる可能性が高い
» だからこそ、フルスタックエンジニアが求められるわけで
すが
–何事もバランスが肝心
66

Q&A
67

アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan

Similar a アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan (20)

Más de Yusuke Suzuki

Más de Yusuke Suzuki (20)

アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan