javaエンジニアのためのアーキテクト講座-jjug ccc 2014 fall

Japan Java User Group

Javaエンジニアのためのアーキテクト講座

2014/11/12

鈴木雄介日本Javaユーザーグループ会長

H-4

#jjug_ccc #ccc_h4


自己紹介

• 鈴木雄介

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

–グロースエクスパートナーズ（株）執行役員

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

–略歴

»ユーザー系システム子会社で保守とか開発とか（5年）

»オンラインマーケベンチャーでプログラマとか（2年）

»フリーランスでITアーキテクトとか（3年）

» GxPでSI事業の部長とか（7年）

▸日本Javaユーザーグループ会長（2年）

1

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


アジェンダ

• システム開発の現状

• アーキテクチャの役割

• アーキテクトの仕事

• 設計の進め方

• まとめ

2


システム開発の現状

3



• 良く言われること

–ビジネス環境変化の激化、技術要素の複雑化、業務の高度化などなど

• システム開発に起きている大きな変化

–「アプリケーションをいかに良く作るか」から「ITサービスをいかに良く運営するか」へ

–アプリケーションが良くても、ITサービス運営がうまくできなければ意味が無い

4



• アプリケーションを開発する

–仕様（静的）を定義する

–開発者が作る

–プロジェクトが終われば終わり

• サービスを運営する

–利用（動的）からフィードバックを受ける

–様々な人が関わりながら動かす

–継続的で終わりのない活動

5



• Web業界が先駆者としてサービス運営の最適化を実現してきた

6

企画

開発運用

Agile

DevOps

Lean

MeasureLeanBuild

tools & culture

Individuals and interactionsWorking softwareCustomer collaborationResponding to change



• エンタープライズにおける、これからの10年

–エンタプライズITの「第三の時代」であるデジタル化が始まっている by ガートナー

»デジタル化：テクノロジーによるビジネスの変革

▸ http://www.gartner.co.jp/press/html/pr20140312-01.html

–人を介して、社会とITの関わりがより強くなる

»バックヤードのシステム化から、フロントのシステム化、そして消費者のIT化

»ヘルスケアが分かりやすい

▸ IoT（Internet of Things/モノのインターネット）はバズワードだが「テクノロジーがいかに社会に関わるか」を示した概念としては意味がある

7

http://www.gartner.co.jp/press/html/pr20140312-01.html



• つまり、システム開発の課題は

–「いかに良いアプリケーションを作るか」から

–「いかに良いITサービス運営を実現するか」に変わってきている

• この状況でエンジニアは何を考えるべきか？

–Javaで格好いいコードを書けばいい、というもんじゃない

–10年後に”価値”がある仕事をしているために

8


アーキテクチャの役割

9



• ソフトウェア品質モデル

10

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質

影響を与える

依存する

JISX0129-1 ソフトウェア製品の品質第１部品質モデル



• ソフトウェア品質モデル

11JISX0129-1 ソフトウェア製品の品質第１部品質モデル

特徴例

利用時の品質・利用状況によって評価が異なる

・ユーザーＡさんとユーザーＢさんで評価が異なる

外部品質・システムの振る舞い・誰がテストしても同じ結果・一般的な仕様策定の対象

・テストケース・外部仕様

内部品質・システムを構成している要素すべて（含ドキュメント）

・後に残り、評価が可能・エンジニアがこだわるところ

・クラス図・フレームワーク・ドキュメント

プロセス品質・後に残らない行動・コミュニケーション・作業手順



• ソフトウェア品質モデルは有用だが、ITサービス運営の観点では足りないことが多い

• そこで、新しいモデルを考えてみた

–まだまだ、改善の余地がありますが…

12



• ITサービス運営のモデル v0.1

13

利用者の体験価値

サービスの振る舞い

静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス




14

特徴例


• 利用者が体験して感じるもの• 利用者によって評価が異なる

• ＡさんとＢさんで評価が異なる


• 外部から見てわかる振る舞い• 誰がテストしても同じ結果• 仕様（機能と非機能）

• 仕様とテストケース• 品質特性• API

動的な構成 • システム実行時の要素と相互作用

• 流れ、実行、プロセス

• インスタンス• 処理• 実行環境/インフラ

静的な構造 • 成果物が配置された静的な構造• 後に残り、参照可能

• ソースコード• クラス、テーブル定義• ドキュメント




15

特徴例

企画プロセス

• ITサービスの振る舞いを管理する• 追加や変更を要求する

• 売上• 要求と受入

開発プロセス

• 静的な構造を作る• 追加し、変更する• 素早さが求められる

• リリース計画• 開発ツール

運用プロセス

• 動的な構成を管理する• 追加や変更を受け入れる• 安定が求められる

• デプロイ• 監視

業務プロセス

• ITサービスを利用し、利用者にサービスを提供する

• 利用者からフィードバックを得る• 安定が求められる

• 現場• 効率化



• ITサービス運営への理解 1/4

16



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス

1.個別の関心事を持つ利害関係者がいる




17



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス

2.価値は利用者の体験によって定義される




18



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス

3.複雑な構成要素によって成り立つ




19



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス

4.フィードバックによって持続的に成長する



• ITサービス運営で考えるべきこと

–1.個別の関心事を持つ利害関係者がいる

–2.価値は利用者の体験によって定義される

–3.複雑な構成要素によって成り立つ

–4.フィードバックによって持続的に成長する

• 良いITサービス運営を実現するには、これら全体をデザインする必要がある

–そのために「アーキテクチャ」が必要になる

20



• ITサービスにおけるアーキテクチャとは

– ITサービス運営に関わる利害関係者の関心事を整合させた、

– ITサービスが提供すべき利用者の体験価値を実現するために、

– ITサービスの構成する要素の分割と関係のことであり、

– ITサービスがフィードバックを受けながら継続的に成長できることを保証する

21



• 各要素のバランスがアーキテクチャ

22



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス


アーキテクトの仕事

23



• アーキテクトの仕事は「アーキテクチャをデザインすること」

• そのために

–利害関係者を参加させ、関心事を理解する

–関心事を整理し、整合させるように調整する

–その関心事に沿ってITサービス運営要素を定義する

»非常に幅広い要素について検討が必要となる

24



• たとえば、

25



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス

こういうクラス分割が必要だ

こういうトランザクション増加が想定される

この動きに、これだけの並行処理が求められる

こういう導線を通るはずだ

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

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

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

この時期は、これだけの作業がある



• 必要とされるスキル（TOGAF参照） 1/3

– IT一般知識

»アプリケーション開発手法＆ツール、言語、ストレージ、ネットワーク、ITインフラ全般、資産管理、SLA、アプリケーションライフサイクル管理、基幹系システム、情報系システム、 Web系システム、

–技術的なITスキル

»ソフトウェアエンジニアリング一般、セキュリティ、トランザクション、画面設計、データ交換、データマネジメント、画像処理、OS、ネットワーク、システム管理、

26




–エンタープライズアーキテクチャスキル

»モデリング、システムデザイン（ビジネスプロセス、組織、ロール、データ、アプリ）、IT関連標準、運用設計、アーキテクチャ方針、システム統合

–プロジェクトマネジメントスキル

»製品管理、変更管理、プロジェクトマネジメント

27




–一般スキル

»リーダーシップ、チーム管理、コミュニケーションスキル、リスク管理、論理分析、資料作成、ステークホルダ管理

–ビジネススキル＆メソッド

»経営戦略、組織と部門、業界知識、業務プロセス、予算管理、経営指標、投資対効果、IT企画

–法律関連

»データ保護、契約関連、調達関連

28



• さらに、技術レイヤが広がっている

29

Networking

Virtualization

Storage

Servers

OS

Middleware

Code

Configuration

Runtime

Data

SaaS

PaaS

IaaS

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



• とはいえ、全部をやることはない–プロダクトアーキテクト» ITサービスに長期的に継続して関わる

–ドメインアーキテクト»ビジネス、データ、ネットワークなど特定専門領域が対象

–インフラアーキテクト»インフラを対象とする

–エンタープライズアーキテクト»複数のITサービスが対象

–クラウドアーキテクト»クラウドの前提としたITサービスが対象

30



• 現実的にはチームでこなすことが必要

–個人のノウハウや知識は限定される

–アーキテクトは、アーキテクチャ設計を通じて、アーキテクトによって育成される

• 組織との関わり方が重要

–その組織における「アーキテクト」の役割を定義し、インストールしていくことが必要

»過度な期待を避ける

31


設計の進め方

32


設計の進め方

• Microservices

–ファウラー先生が提唱

» http://martinfowler.com/articles/microservices.html

»海外では、かなりブームになっている雰囲気

– ITサービス運営のアーキテクチャの考え方を良く表している

»個々に独立したサービスによって全体のサービスが構成されている

▸データ、ガバナンス、手法なども完全に独立

»個々のサービスは個々のチームによって開発・運用される

▸開発と運用は一体化され、個々に責任を持つ

33


設計の進め方• 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/進化的な設計

34


設計の進め方

• Microservicesは既に起きていること

–たとえばECサイト

»管理画面から商品を登録する

»商品を検索する

»商品をカートにいれて購入する

»受注を処理して請求や物流手配を行う

»記事コンテンツを更新する

–これらは、全て異なるドメインとして定義できる

35


設計の進め方

• ドメインの発見には、変化の境界を見極める

–分かりやすく外的変化要因になるもの

»ユーザーの役割が異なる

»ユーザーによって利用されるサイクルが違う

–その他の変化要因

»セキュリティ

–必ず境界にするわけではない。パターンにくくっていくことが大事

36


設計の進め方

• それぞれのケースにおける分析

37

ビジネスケース利用者サイクル

管理画面から商品を登録する

商品担当者毎日

商品を検索する消費者かなり頻繁に

商品をカートにいれて購入する

消費者それなりの回数

受注を処理して請求や物流手配を行う

受注担当者配送担当者

受注のたびに

記事コンテンツを更新する

コンテンツ担当者毎週


設計の進め方• 非機能についても考えることが必要– 機能適合性

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

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

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

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

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

– セキュリティ» 不正にアクセスがされることなく、情報やデータが保護される度合

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

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

38


設計の進め方

• 品質特性 1/2

39

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

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

完全性ニーズを機能がユーザの目的やタスクを包含している度合正確性必要な精度で正確な結果を与える度合適切性機能が定められたタスクや目的を円滑に遂行する度合

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

時間効率性実行時のシステムの応答時間、処理時間などの処理能力の度合資源利用性実行時に使用する資源量や種類キャパシティ要求を満たすための製品やシステムのパラメータの最大許容値

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

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

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

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

適切度認識性ニーズに適した利用かどうか認識できる度合習得性システムの使い方の学習ができる度合運用性運用や管理のしやすさの度合ユーザエラー防止性誤操作しないように保護する度合ユーザインタフェースの快美性

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

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

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

成熟性通常時に信頼性のニーズを満たす度合可用性必要時に運用、接続できる度合障害許容性障害時に運用できる度合回復性障害時にデータやシステムが回復したり再構築できる度合

情報システム/ソフトウェアの品質メトリクスセットhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf


設計の進め方

• 品質特性 2/2

40

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

セキュリティ

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

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

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

否認防止性イベントやアクションの発生を証明する度合責任追跡性エンティティの実行が唯一であることを証明する度合

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

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

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

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

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

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

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

移植性

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

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

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

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

情報システム/ソフトウェアの品質メトリクスセットhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf


• ドメインと技術要素のマッピング

設計の進め方

41

商品商品登録

商品検索

購買

カート

受注受注管理

記事記事登録

商品担当者

受注担当者

コンテンツ担当者

消費者

記事表示

CMS

検索エンジン

管理システム

フロントシステム

配送担当者

RDB


設計の進め方

• ドメインと技術要素のマッピング

• もちろん、これだけが正解なわけではない

–個別のITサービスごとに適した構成がある

–たとえばクラウドサービスを活用すると、もっとコストが減るかもしれない

42

構成要素特性技術例

記事管理記事登録のワークフロー管理、決められた時間での公開

CMS

商品検索ハイパフォーマンス Lucene

購買管理複雑なロジックと使いやすさ MVC＋SQL

バックエンドパターン化された画面 JSF+JPA


設計の進め方

• さらに個別のドメイン毎にサービスを構成する要素に求められることが異なる

43



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス


設計の進め方

• 記事管理（CMS）

44



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス

CMSを採用

CMSカスタマイズ設計書と専門エンジニア

製品のログを監視対象に追加

テンプレート更新はデザイナ、商品担当と連携して取材し、コンテンツを制作

SEOを向上させるためのタグを追加させたい

ホワイトペーパーに従った構成

制作ワークフロー制御とタイマー公開

記事を読んで商品を理解する


設計の進め方

• 商品検索（Lucene）

45



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス

検索エンジンのLuceneを採用

ランキングや重み付けの調整

結果の並び順を最適化したい

Luceneサーバを独立し、定期的に商品データを取り込ませる

応答時間を監視し、SLAを確認する

APIを経由して呼ばれた結果を返却する

求めている商品がすばやく見つかる

商品登録をしたも、リアルタイムに変わるわけではないことを理解


設計の進め方

• 購買管理（MVC+SQL）

46



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス

自由度が高い素のMVCとSQLで構成。決済は外部ASP利用

初期はハイスキル要員だけど決裁の追加は簡単

新しい決済手段を追加したい

外部ASPのSLA計測不正アタックの検出

ASPに障害があればエラーではなく処理をスキップし、手動決済を実施する

様々な決済手段に対応している

ASP障害時は手動で作業

商品が簡単に買える


設計の進め方

• バックエンド（JSF+JPA）

47



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス

パターン化されたUIしか受付けない

JSF+JPAで可能な限り生産性を向上

稼働状況を監視して手動切替

コールドスタンバイでの信頼性確保で十分

ピークに応じて要員を追加。役割分担によるユーザの追加

新しい商品を扱うことで属性の追加要求

商品が安心して受け取れる

業務プロセスに従った機能を提供


設計の進め方

• Microservicesの落とし穴

–ドメイン毎の独自性を強くすると、全体的な保守性が下がってくる可能性が高い

»だからこそ、フルスタックエンジニアが求められるわけですが

–何事もバランスが肝心

48


まとめ

49


まとめ

• システム開発の課題は

–「いかに良いアプリケーションを作るか」から

–「いかに良いITサービス運営を実現するか」に変わってきている

• この状況で、いかにエンジニアとして生きるか

–1つのパスが「アーキテクト」だと思う

50


まとめ


51



静的な構造

開発プロセス

動的な構成

企画プロセス

運用プロセス

業務プロセス


まとめ

• ITサービスにおけるアーキテクチャとは– ITサービス運営に関わる利害関係者の関心事を整合させた、

– ITサービスが提供すべき利用者の体験価値を実現するために、

– ITサービスの構成する要素の分割と関係のことであり、

– ITサービスがフィードバックを受けながら継続的に成長できることを保証する

• ざっくり言うと

– ITサービスの各要素のバランスをとること

52


まとめ

• アーキテクトの仕事は「アーキテクチャをデザインすること」

• そのために

–利害関係者を参加させ、関心事を理解する

–関心事を整理し、整合させるように調整する

–その関心事に沿ってITサービス運営要素を定義する

• 幅広い知識が必要にはなるが、チームで行動し、組織における役割が重要

53


まとめ

• 設計の進め方

–Microservices的なアプローチは重要

–道具から発想せず、ITサービス運営全体を想像する

–利害関係者とコミュニケーションすることが大事

54


まとめ

• 最後に

–これからの10年、ITはもっと社会の中で活躍するようになる

»だから、エンタープライズはもっと面白くなる

–でも、ただのエンジニアは10年で不要になる

»少なくとも価値が下がる

–アーキテクトと名乗らなくても、アーキテクト的な発想はできるし、日常で役に立つはず

»仕様書をコードに変換するだけのお仕事はやめませんか？

55

javaエンジニアのためのアーキテクト講座-jjug ccc 2014 fall

Technology