【6-4】エンタープライズ・アーキテクチャの

選択についてグロースエクスパートナーズ（株）

鈴木雄介

2015年4月6日

Java Day Tokyo 2015

1

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

– 執行役員/アーキテクチャ事業本部長

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

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

– 会長

– http://www.java-users.jp/

• SNS

– http://arclamp.hatenablog.com/

– @yusuke_arclamp

1

鈴木雄介

arclamp

今日、話したいこと

• アーキテクチャとは何か？

• どうやって選択したらよいのか？

–どういう観点で考えるべきか

2

アジェンダ

• アーキテクチャとは

• 選択の観点

• 選択の実践

• 選択の覚悟

• まとめ

3

アーキテクチャとは

4

アーキテクチャとは

• システムの「分け方と組み合わせ方」のこと

–システムのミッションに従い、制約や環境を前提しながら、複数の利害関係者の関心事を整合させた「分け方と組み合わせ方」のこと

–簡単に言うと「システム全体のバランスを取る」こと

»空間的：利害関係者の関心事を意識する

»時間的：現在から未来の時間経過に伴う変化を意識する

5

アーキテクチャの成果とは

• システムの「構造とプロセスの決定」

–構造

»システムの機能が、どのような要素に分解されるのか

–プロセス

»それら要素をどのように組み立てるのか

–上記にリソースとスケジュールを加味すると、WBS（ガントチャート）になる

6

エンタープライズ・アーキテクチャとは

• 企業システムを対象としたアーキテクチャ

• 特徴

–利害関係者が多い（かつ、縦割りだったりする）

–連携先システムが多い（かつ、レガシーだったりする）

–急激に変化できない/しない（社会基盤としての責務）

–現状維持が重要（「現行踏襲」の罠）

–様々なシステム（B2B、B2C、B2Eなど）

–様々なルール（内部統制、セキュリティ、法制度など）

7

なぜアーキテクチャを定義するのか

• アーキテクチャが全てのスタート

–「構造とプロセス」が明確でなければチームは動けない

–プロジェクトマネジメントはアーキテクチャを前提とした実行段階における「計画→実行→計測→調整」の営み

• 最初に「全てを固定的に決める」必要はない

–「選択肢を残す決定」はできる

–YNGNIの法則は今でも有効

8

選択の観点

9

アーキテクチャを選択するために

• 様々な観点でバランスを取る作業

• 本日は、3つの観点を紹介

– ITサービス運営の観点

–品質の観点

–技術の観点

10

ITサービス運営の必要性

• 「アプリケーションを作る」から

–決めた仕様に従う

–開発者が開発する

–プロジェクトが終了するまでの活動

• 「ITサービスを運営する」へ

–利用者からフィードバックを受ける

–様々な人が関わる

–終わることのない持続的な活動

11

ITサービス運営モデル

12

ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ

満足度

構造

開発 企画

運用 業務

プロセス

ITサービス運営モデル

13

名前 概要 実例

構造 • ソフトウェアの構造 フレームワークドキュメント体系

プロセス • ソフトウェア開発プロセスや手順

アジャイルウォーターフォール

機能 • ソフトウェアの提供する機能

機能要件

ITサービス • 機能が動作した状態 非機能要件

サービス • 企業が提供するサービス 商品/サービス

満足度 • ユーザーの感じる満足度• 人それぞれ異なる

ITサービス運営モデル

• その他としては「経営者」「社会通念」などもあげられる

14

名前 関心事 キーワード

企画 • ユーザーが満足するサービスの企画を検討する

事業計画満足度調査

開発 • ソフトウェアを開発する 作るQCD

運用 • ソフトウェアを安定して動作させる

動かすSLA

業務 • ユーザーに満足がいくサービスを提供する

ワークフロー

ITサービス運営モデル

• より「ITサービス運営」を意識したアーキテクチャ設計になっていく必要性がある

–利害関係者はさらに多くなる

–ユーザーが利用することで評価される

–様々な要素の相互関係によって成り立つ

–継続的な活動を前提とした効率性を求める

15

ITサービス運営モデル

16

ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ

満足度

構造

開発 企画

運用 業務

プロセス

IT/ソフトウェア品質特性

• 品質とは何か？

–品質とは多面的で、1つのパラメタでは制御できない

–いくつかの観点でバランスを取りながら検討を進める

17

IT/ソフトウェア品質特性

• 8つの品質特性と31の副特性

18

品質特性 品質副特性

機能適合性 完全性、正確性、適切性

性能効率性 時間効率性、資源利用性、キャパシティ

互換性 共存性、相互運用性

使用性適切度認識性、習得性、運用性、ユーザエラー防止性ユーザインタフェースの快美性、アクセシビリティ

信頼性 成熟性、可用性、障害許容性、回復性

セキュリティ機密保持性、インテグリティ、否認防止性責任追跡性、真正性

保守性 モジュール性、再利用性、解析性、変更性、試験性

移植性 順応性、設置性、置換性「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクト

http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdfhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf

19

品質特性 特性の概要 副品質特性 概要

機能適合性実装された機能がニーズを満たす度合

完全性 ニーズを機能がユーザの目的やタスクを包含している度合

正確性 必要な精度で正確な結果を与える度合

適切性 機能が定められたタスクや目的を円滑に遂行する度合

性能効率性システムの実行時の性能や資源効率の度合

時間効率性 実行時のシステムの応答時間、処理時間などの処理能力の度合

資源利用性 実行時に使用する資源量や種類

キャパシティ 要求を満たすための製品やシステムのパラメータの最大許容値

互換性他製品やシステムと機能や情報を共有、変換できる度合

共存性 他製品へ負の影響を与えず、共通の環境や資源を共有して効果的に実行する度合

相互運用性 2つ以上の製品やコンポーネント間で情報を交換、利用できる度合

使用性 効果的、効率的に利用できる度合

適切度認識性 ニーズに適した利用かどうか認識できる度合

習得性 システムの使い方の学習ができる度合

運用性 運用や管理のしやすさの度合

ユーザエラー防止性 誤操作しないように保護する度合

ユーザインタフェースの快美性

ユーザインタフェースが親しみがあり満足感のある応答ができる度合

アクセシビリティ 幅広い層の特徴や能力を持つ人々が利用できる度合

信頼性必要時に実行することができる度合

成熟性 通常時に信頼性のニーズを満たす度合

可用性 必要時に運用、接続できる度合

障害許容性 障害時に運用できる度合

回復性 障害時にデータやシステムが回復したり再構築できる度合

セキュリティ

不正にアクセスがされることなく、情報やデータが保護される度合

機密保持性 許可された者のみがアクセスできるようデータを保証する度合

インテグリティ プログラムやデータへの変更において未許可なアクセスを防止する度合

否認防止性 イベントやアクションの発生を証明する度合

責任追跡性 エンティティの実行が唯一であることを証明する度合

真正性 リソースや物事の身元が要求されたものであることを証明できる度合

保守性効果的、効率的に保守や修正ができる度合

モジュール性 変更による他コンポーネントへの影響が最少で済むよう、独立したコンポーネントで構成される度合い

再利用性 他のシステムや資産を構築する際に利用できる度合

解析性 変更部分や障害原因の特定のために診断したり、変更による影響を評価する際の効果性、効率性の度合

変更性 欠陥や品質の低下なく変更が効果的、効率的にできる度合

試験性 テスト基準を確立し、評価するために実行する際の効果性、効率性の度合

移植性効果的、効率的に他のハードウェアや実行環境に移植できる度合

順応性 別のもしくは進化したハードウェアやソフトウェアや他の運用環境に効果的、効率的に順応できる度合

設置性 正しくインストール、もしくはアンインストールする際の効果性、効率性の度合

置換性 同一の目的、環境下で他のソフトウェア製品に置換（リプレース）できる度合

「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクトhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdfhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf

IT/ソフトウェア品質特性

• 技術に選択においては、品質特性同士が打ち消しあう場合もある

–安易は両立は避けるべき

• 特筆するならば

–コストの観点では保守性が重要

–性能効率性は仮想化/クラウドによって少し自由に

–互換性はあらゆるシーンで重要（標準準拠）

–エンタープライズでは信頼性とセキュリティが重要

20

技術

• 共有と固有のバランス

–共有された資源を最大限に活用する

–固有ドメインの特性を最大限に発揮する

• プラットフォームとマイクロサービス

–プラットフォーム＝共有資源の定義

» Docker、Cloud Foundry

–マイクロサービス＝固有の構造とプロセス

21

技術：プラットフォーム

22

ネットワーク

仮想化

ストレージ

サーバ

OS

ミドルウェア

コード

設定

実行環境

データ

SaaS

PaaS

IaaS

ロードバランサーストレージアーカイブCDNデータ転送RDB・NoSQLデータウェアハウスメモリキャッシュデータストリーム分散処理オーケストレーションサーチストリーミングメール配信メッセージキュープッシュ通知ワークフロー課金メディア変換コンテナデプロイユーザー活動分析モニタリング認証認可

技術：マイクロサービス

• サービスによってシステムを構成する

–サービス同士はAPIによって連携する

–サービス同士は独立した構造とプロセスを持つ

–サービスは独自のライフサイクルを持つ

–サービスは個別のドメインに従う

23

ITｻｰﾋﾞｽ

ITｻｰﾋﾞｽ

ITｻｰﾋﾞｽ

技術：プラットフォームとサービス

24

ネットワーク

仮想化

ストレージ

サーバ

OS

ミドルウェア

コード

設定

実行環境

コード

設定

実行環境

プラットフォーム管理

デプロイされたアプリケーションの「設定」に合わせて「実行環境」や利用する「ミドルウェア」をセットアップしれくれる

技術

• プラットフォーム

–どのレベルで共有資源として”定義”すべきか

»パブリック、プライベート、ハイブリッド

–共有しすぎると対応できないことがでてくる

• マイクロサービス

–どのレベルで構造とプロセスの固有性を認めるか

»業界、グループ、企業、事業、業務

–あまりにも独立させるとスケールしない

25

選択の実践

26

選択の観点

• 3つの観点

– ITサービス運営の観点

–品質の観点

–技術の観点

• 分かりやすい例としてECサイト

–エンタープライズ的でありながら、Web的

–Web的でありながら、エンタープライズ的

27

例：ECサイト

• ECサイトに必要な機能（≒ドメイン）–商品管理»分かりやすい商品登録。商品とマスタの紐付け、撮影。

–コンテンツ管理»的確なコンテンツ配信。タイミング、キャンペーン。

–商品検索»高速で探しやすい検索。

–商品購買»分かりやすく間違えない購買プロセス

–受注管理»確実で抜け漏れがない受注処理や配送処理

28

選択の実践

29

ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ

満足度

構造

開発 企画

運用 業務

プロセス

こういう機能分割が必要だ

金曜日になると負荷が高くなる

こういう動きをすると使いやすい

注文してスムーズに届いてうれしい

このKPIに従って評価すべきだ

こういう要員と手法で作るべきだ

ここの数値を監視すべきだ

受注に従って配送しなくてはならない

この機能を優先的に作ろう

翌日に配達を実現

選択の実践

• たとえば検索エンジンの品質特性

30

品質特性 品質副特性

機能適合性 柔軟なパラメタ設定、データのリアルタイムな更新

性能効率性 ともかくパフォーマンスを重視、測定可能なログ出力

互換性 API化して他サービスからも呼びたい

使用性 検索順位の最適化が容易に行えるUI

信頼性 24h365d、ただし、夜間縮退は可能

セキュリティ 重要ではあるが、そこまでではない

保守性 検索が正しく行われていることを把握するための仕組み

移植性 独自エンジンを利用し、移植性は無視

選択の実践

31

商品 商品登録

商品検索

購買

受注 受注管理

記事 記事登録

商品担当者

受注担当者

コンテンツ担当者

消費者

記事表示

CMS

検索エンジン

管理システム

フロントシステム

配送担当者

ワークフロー

アジャイル的がよい

WF的でよい

アジャイル的がよい

WF的でよい

選択の実践

• 多面的に組み立てることが大事

–全ての要素を”完璧”に組み立てることはできないが、全ての要素に利害関係者がいることが理解しておく

• 完璧な選択はできない

32

選択の覚悟

33

アーキテクトの覚悟と責任

• アーキテクトはアーキテクチャを決定する重要な役割を負う

• 「正解がない」からこそ、覚悟が必要になる

34

最大公約数を目指す

• 「最小公倍数」ではなく「最大公約数」を目指す

–「最小公倍数」は全員が満足する

–「最大公約数」には誰も満足しない

–でも「最小公倍数」は誰も幸せにしない

• 「最大公約数」を目指すことを誰も理解してくれない

35

36

決定は「誰か」のものではなく、自分のものだという責任

https://www.flickr.com/photos/vincenadmathsw/6988287627

銀の弾丸はない

• 誰かの成功事例が自分に当てはまるとは限らない

–知識は知識でしかない

–体験によってしか得られないことがある

–必要なだけの事前検証をする

37https://www.flickr.com/photos/davidw/152220578

38https://www.flickr.com/photos/mustafakhayat/6933636588

銀の弾丸をこめたら、打ち抜くまでやめないのが責任

妥協せず、諦める

• 妥協はできないが、適切に諦めること

–アーキテクトは神ではない。全てを見通すことなどできない。もちろん未来も。

–今ある材料で判断できないなら、材料を集めるべき。妥協してはならない

–でも、どこかで諦めないといけない

–そのときは持続的な中で改善していく

39

40

諦めるまで考え続ける、諦める時は未来に託すのが責任（丸投げしない！）

http://www.flickr.com/photos/atomdocs/3275758118/

まとめ

41

アーキテクチャとは

• アーキテクチャとは「分け方と組み合わせ方」

• 成果は「構造とプロセスの決定」

• エンタープライズ・アーキテクチャはめんどう

• どういった観点で考えるべきか？

– ITサービス運営の観点

–品質の観点

–技術の観点

42

ITサービス運営モデル

43

ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ

満足度

構造

開発 企画

運用 業務

プロセス

IT/ソフトウェア品質特性

• 8つの品質特性と31の副特性

44

品質特性 品質副特性

機能適合性 完全性、正確性、適切性

性能効率性 時間効率性、資源利用性、キャパシティ

互換性 共存性、相互運用性

使用性適切度認識性、習得性、運用性、ユーザエラー防止性ユーザインタフェースの快美性、アクセシビリティ

信頼性 成熟性、可用性、障害許容性、回復性

セキュリティ機密保持性、インテグリティ、否認防止性責任追跡性、真正性

保守性 モジュール性、再利用性、解析性、変更性、試験性

移植性 順応性、設置性、置換性「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクト

http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdfhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf

技術

• 共有と固有のバランス

–共有された資源を最大限に活用する

–固有ドメインの特性を最大限に発揮する

• プラットフォームとマイクロサービス

–プラットフォーム＝共有資源の定義

» Docker、Cloud Foundry

–マイクロサービス＝固有の構造とプロセス

45

アーキテクトの覚悟と責任

• 最大公約数を目指す

• 銀の弾丸はない

• 妥協せず、諦める

46

最後に

• アーキテクチャ設計の観点は変化している

–今日の3つの観点も”正解”ではない

• チームでアーキテクチャに取り組もう

–個人で考えることの限界

–なるべく多くの人と話す

• よりよい選択のための継続的な努力を

47