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

Copyright© Growth xPartners, Inc. All rights reserved.

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

グロースエクスパートナーズ（株）

鈴木雄介

2014年12月20日


自己紹介

• 鈴木雄介

–グロースエクスパートナーズ（株）

» 執行役員

» SI事業の統括マネージャー/ITアーキテクト

–日本Javaユーザーグループ

» 会長

–ブログ：http://arclamp.hatenablog.com/

–Twitter：@yusuke_arclamp

1

http://arclamp.hatenablog.com/


自己紹介

• グロースエクスパートナーズ（株）

–受託開発を中心としたソフトウェア開発企業

» http://www.gxp.co.jp/

–顧客（全てプライム）

» 医療器械メーカー

» 百貨店

» 企業信用情報提供

» 通信

» オフィス機器＆医療機器メーカー

» 雑誌＆オンラインメディア

2

http://www.gxp.co.jp/

Copyright© Growth xPartners, Inc. All rights reserved. 3

アーキテクチャとマネジメント

https://www.flickr.com/photos/splorp/6264402594

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

http://www.axisjiku.com/jp/2009/12/16/axis%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A9%E3%83%A0-%E9%98%BF%E9%83%A8%E9%9B%85%E4%B8%96%E3%81%95%E3%82%93%E8%AC%9B%E6%BC%94-%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88-%E3%81%9D%E3%81%AE1%EF%BC%88%E5%85%A83/

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/

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

Technology

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