Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
•
91 j'aime•24,770 vues
2014年11月15日（土）に開催されたJJUG CCC Fall 2014での講演「Javaエンジニアのためのアーキテクト講座」の資料です。
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
Similaire à Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall (20)
Plus de Yusuke Suzuki
Plus de Yusuke Suzuki (8)
Dernier
Dernier (7)
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
- 1. Japan Java User Group Javaエンジニアのためのアーキテクト講座 2014/11/12 鈴木雄介 日本Javaユーザーグループ 会長 H-4 #jjug_ccc #ccc_h4
- 2. Japan Java User Group 自己紹介 • 鈴木雄介 –日本Javaユーザーグループ 会長 –グロースエクスパートナーズ（株） 執行役員 » http://www.gxp.co.jp/ –略歴 » ユーザー系システム子会社で保守とか開発とか（5年） » オンラインマーケベンチャーでプログラマとか（2年） » フリーランスでITアーキテクトとか（3年） » GxPでSI事業の部長とか（7年） ▸ 日本Javaユーザーグループ 会長（2年） 1
- 3. Japan Java User Group アジェンダ • システム開発の現状 • アーキテクチャの役割 • アーキテクトの仕事 • 設計の進め方 • まとめ 2
- 4. Japan Java User Group システム開発の現状 3
- 5. Japan Java User Group システム開発の現状 • 良く言われること –ビジネス環境変化の激化、技術要素の複雑化、業務 の高度化などなど • システム開発に起きている大きな変化 –「アプリケーションをいかに良く作るか」から「IT サービスをいかに良く運営するか」へ –アプリケーションが良くても、ITサービス運営がう まくできなければ意味が無い 4
- 6. Japan Java User Group システム開発の現状 • アプリケーションを開発する –仕様（静的）を定義する –開発者が作る –プロジェクトが終われば終わり • サービスを運営する –利用（動的）からフィードバックを受ける –様々な人が関わりながら動かす –継続的で終わりのない活動 5
- 7. Japan Java User Group システム開発の現状 • Web業界が先駆者としてサービス運営の最適化 を実現してきた 6 企画 開発 運用 Agile DevOps Lean Measure Lean Build tools & culture Individuals and interactions Working software Customer collaboration Responding to change
- 8. Japan Java User Group システム開発の現状 • エンタープライズにおける、これからの10年 –エンタプライズITの「第三の時代」であるデジタル 化が始まっている by ガートナー » デジタル化：テクノロジーによるビジネスの変革 ▸ http://www.gartner.co.jp/press/html/pr20140312-01.html –人を介して、社会とITの関わりがより強くなる » バックヤードのシステム化から、フロントのシステム化、 そして消費者のIT化 » ヘルスケアが分かりやすい ▸ IoT（Internet of Things/モノのインターネット）はバズワードだが 「テクノロジーがいかに社会に関わるか」を示した概念としては意味 がある 7
- 9. Japan Java User Group システム開発の現状 • つまり、システム開発の課題は –「いかに良いアプリケーションを作るか」から –「いかに良いITサービス運営を実現するか」に変わ ってきている • この状況でエンジニアは何を考えるべきか？ –Javaで格好いいコードを書けばいい、というもんじ ゃない –10年後に”価値”がある仕事をしているために 8
- 10. Japan Java User Group アーキテクチャの役割 9
- 11. Japan Java User Group アーキテクチャの役割 • ソフトウェア品質モデル 10 利用時の 品質 利用時の 品質 プロセス 品質 内部 品質 外部 品質 利用時の 品質 影響を与える 依存する JISX0129-1 ソフトウェア製品の品質 第１部 品質モデル
- 12. Japan Java User Group アーキテクチャの役割 • ソフトウェア品質モデル 11JISX0129-1 ソフトウェア製品の品質 第１部 品質モデル 特徴 例 利用時の品質 ・利用状況によって評価が異な る ・ユーザーＡさんと ユーザーＢさんで評価 が異なる 外部品質 ・システムの振る舞い ・誰がテストしても同じ結果 ・一般的な仕様策定の対象 ・テストケース ・外部仕様 内部品質 ・システムを構成している要素 すべて（含ドキュメント） ・後に残り、評価が可能 ・エンジニアがこだわるところ ・クラス図 ・フレームワーク ・ドキュメント プロセス品質 ・後に残らない行動 ・コミュニケーション ・作業手順
- 13. Japan Java User Group アーキテクチャの役割 • ソフトウェア品質モデルは有用だが、ITサービ ス運営の観点では足りないことが多い • そこで、新しいモデルを考えてみた –まだまだ、改善の余地がありますが… 12
- 14. Japan Java User Group アーキテクチャの役割 • ITサービス運営のモデル v0.1 13 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス
- 15. Japan Java User Group アーキテクチャの役割 • ITサービス運営のモデル v0.1 14 特徴 例 利用者の 体験価値 • 利用者が体験して感じるもの • 利用者によって評価が異なる • ＡさんとＢさんで評価 が異なる サービスの 振る舞い • 外部から見てわかる振る舞い • 誰がテストしても同じ結果 • 仕様（機能と非機能） • 仕様とテストケース • 品質特性 • API 動的な構成 • システム実行時の要素と相互作 用 • 流れ、実行、プロセス • インスタンス • 処理 • 実行環境/インフラ 静的な構造 • 成果物が配置された静的な構造 • 後に残り、参照可能 • ソースコード • クラス、テーブル定義 • ドキュメント
- 16. Japan Java User Group アーキテクチャの役割 • ITサービス運営のモデル v0.1 15 特徴 例 企画 プロセス • ITサービスの振る舞いを管理する • 追加や変更を要求する • 売上 • 要求と受入 開発 プロセス • 静的な構造を作る • 追加し、変更する • 素早さが求められる • リリース計画 • 開発ツール 運用 プロセス • 動的な構成を管理する • 追加や変更を受け入れる • 安定が求められる • デプロイ • 監視 業務 プロセス • ITサービスを利用し、利用者にサー ビスを提供する • 利用者からフィードバックを得る • 安定が求められる • 現場 • 効率化
- 17. Japan Java User Group アーキテクチャの役割 • ITサービス運営への理解 1/4 16 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス 1.個別の関心事を持つ利害関係者がいる
- 18. Japan Java User Group アーキテクチャの役割 • ITサービス運営への理解 2/4 17 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス 2.価値は利用者の体験によって定義される
- 19. Japan Java User Group アーキテクチャの役割 • ITサービス運営への理解 2/4 18 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス 3.複雑な構成要素によって成り立つ
- 20. Japan Java User Group アーキテクチャの役割 • ITサービス運営への理解 4/4 19 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス 4.フィードバックによって持続的に成長する
- 21. Japan Java User Group アーキテクチャの役割 • ITサービス運営で考えるべきこと –1.個別の関心事を持つ利害関係者がいる –2.価値は利用者の体験によって定義される –3.複雑な構成要素によって成り立つ –4.フィードバックによって持続的に成長する • 良いITサービス運営を実現するには、これら全 体をデザインする必要がある –そのために「アーキテクチャ」が必要になる 20
- 22. Japan Java User Group アーキテクチャの役割 • ITサービスにおけるアーキテクチャとは –ITサービス運営に関わる利害関係者の関心事を整合 させた、 –ITサービスが提供すべき利用者の体験価値を実現す るために、 –ITサービスの構成する要素の分割と関係のことであ り、 –ITサービスがフィードバックを受けながら継続的に 成長できることを保証する 21
- 23. Japan Java User Group アーキテクチャの役割 • 各要素のバランスがアーキテクチャ 22 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス
- 24. Japan Java User Group アーキテクトの仕事 23
- 25. Japan Java User Group アーキテクトの仕事 • アーキテクトの仕事は「アーキテクチャをデザ インすること」 • そのために –利害関係者を参加させ、関心事を理解する –関心事を整理し、整合させるように調整する –その関心事に沿ってITサービス運営要素を定義する » 非常に幅広い要素について検討が必要となる 24
- 26. Japan Java User Group アーキテクトの仕事 • たとえば、 25 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス こういうクラス 分割が必要だ こういうトランザクショ ン増加が想定される この動きに、これ だけの並行処理が 求められる こういう導線を通 るはずだ このKPIに従って 評価すべきだ こういう要員と手 法で作るべきだ ここの数値を監視 すべきだ この時期は、これ だけの作業がある
- 27. Japan Java User Group アーキテクトの仕事 • 必要とされるスキル（TOGAF参照） 1/3 –IT一般知識 » アプリケーション開発手法＆ツール、言語、ストレージ、 ネットワーク、ITインフラ全般、資産管理、SLA、アプリ ケーションライフサイクル管理、基幹系システム、情報系 システム、 Web系システム、 –技術的なITスキル » ソフトウェアエンジニアリング一般、セキュリティ、トラ ンザクション、画面設計、データ交換、データマネジメン ト、画像処理、OS、ネットワーク、システム管理、 26
- 28. Japan Java User Group アーキテクトの仕事 • 必要とされるスキル（TOGAF参照） 2/3 –エンタープライズアーキテクチャスキル » モデリング、システムデザイン（ビジネスプロセス、組織 、ロール、データ、アプリ）、IT関連標準、運用設計、ア ーキテクチャ方針、システム統合 –プロジェクトマネジメントスキル » 製品管理、変更管理、プロジェクトマネジメント 27
- 29. Japan Java User Group アーキテクトの仕事 • 必要とされるスキル（TOGAF参照） 3/3 –一般スキル » リーダーシップ、チーム管理、コミュニケーションスキル 、リスク管理、論理分析、資料作成、ステークホルダ管理 –ビジネススキル＆メソッド » 経営戦略、組織と部門、業界知識、業務プロセス、予算管 理、経営指標、投資対効果、IT企画 –法律関連 » データ保護、契約関連、調達関連 28
- 30. Japan Java User Group アーキテクトの仕事 • さらに、技術レイヤが広がっている 29 Networking Virtualization Storage Servers OS Middleware Code Configuration Runtime Data SaaS PaaS IaaS ロードバランサー ストレージアーカイブ CDN データ転送 RDB・NoSQL データウェアハウス メモリキャッシュ データストリーム 分散処理 オーケストレーション サーチ ストリーミング メール配信 メッセージキュー プッシュ通知 ワークフロー 課金 メディア変換 コンテナ デプロイ ユーザー活動分析 モニタリング 認証認可
- 31. Japan Java User Group アーキテクトの仕事 • とはいえ、全部をやることはない –プロダクトアーキテクト » ITサービスに長期的に継続して関わる –ドメインアーキテクト » ビジネス、データ、ネットワークなど特定専門領域が対象 –インフラアーキテクト » インフラを対象とする –エンタープライズアーキテクト » 複数のITサービスが対象 –クラウドアーキテクト » クラウドの前提としたITサービスが対象 30
- 32. Japan Java User Group アーキテクトの仕事 • 現実的にはチームでこなすことが必要 –個人のノウハウや知識は限定される –アーキテクトは、アーキテクチャ設計を通じて、ア ーキテクトによって育成される • 組織との関わり方が重要 –その組織における「アーキテクト」の役割を定義し 、インストールしていくことが必要 » 過度な期待を避ける 31
- 33. Japan Java User Group 設計の進め方 32
- 34. Japan Java User Group 設計の進め方 • Microservices –ファウラー先生が提唱 » http://martinfowler.com/articles/microservices.html » 海外では、かなりブームになっている雰囲気 –ITサービス運営のアーキテクチャの考え方を良く表 している » 個々に独立したサービスによって全体のサービスが構成さ れている ▸ データ、ガバナンス、手法なども完全に独立 » 個々のサービスは個々のチームによって開発・運用される ▸ 開発と運用は一体化され、個々に責任を持つ 33
- 35. Japan Java User Group 設計の進め方 • 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
- 36. Japan Java User Group 設計の進め方 • Microservicesは既に起きていること –たとえばECサイト » 管理画面から商品を登録する » 商品を検索する » 商品をカートにいれて購入する » 受注を処理して請求や物流手配を行う » 記事コンテンツを更新する –これらは、全て異なるドメインとして定義できる 35
- 37. Japan Java User Group 設計の進め方 • ドメインの発見には、変化の境界を見極める –分かりやすく外的変化要因になるもの » ユーザーの役割が異なる » ユーザーによって利用されるサイクルが違う –その他の変化要因 » セキュリティ –必ず境界にするわけではない。パターンにくくって いくことが大事 36
- 38. Japan Java User Group 設計の進め方 • それぞれのケースにおける分析 37 ビジネスケース 利用者 サイクル 管理画面から商品を登 録する 商品担当者 毎日 商品を検索する 消費者 かなり頻繁に 商品をカートにいれて 購入する 消費者 それなりの回数 受注を処理して請求や 物流手配を行う 受注担当者 配送担当者 受注のたびに 記事コンテンツを更新 する コンテンツ担当者 毎週
- 39. Japan Java User Group 設計の進め方 • 非機能についても考えることが必要 – 機能適合性 » 実装された機能がニーズを満たす度合 – 性能効率性 » システムの実行時の性能や資源効率の度合 – 互換性 » 他製品やシステムと機能や情報を共有、変換できる度合 – 使用性 » 効果的、効率的に利用できる度合 – 信頼性 » 必要時に実行することができる度合 – セキュリティ » 不正にアクセスがされることなく、情報やデータが保護される度合 – 保守性 » 効果的、効率的に保守や修正ができる度合 – 移植性 » 効果的、効率的に他のハードウェアや実行環境に移植できる度合 38
- 40. Japan Java User Group 設計の進め方 • 品質特性 1/2 39 品質特性 特性の概要 副品質特性 概要 機能適合性 実装された機能が ニーズを満たす度合 完全性 ニーズを機能がユーザの目的やタスクを包含している度合 正確性 必要な精度で正確な結果を与える度合 適切性 機能が定められたタスクや目的を円滑に遂行する度合 性能効率性 システムの実行時の 性能や資源効率の度 合 時間効率性 実行時のシステムの応答時間、処理時間などの処理能力の度合 資源利用性 実行時に使用する資源量や種類 キャパシティ 要求を満たすための製品やシステムのパラメータの最大許容値 互換性 他製品やシステムと 機能や情報を共有、 変換できる度合 共存性 他製品へ負の影響を与えず、共通の環境や資源を共有して効果 的に実行する度合 相互運用性 2つ以上の製品やコンポーネント間で情報を交換、利用できる 度合 使用性 効果的、効率的に利 用できる度合 適切度認識性 ニーズに適した利用かどうか認識できる度合 習得性 システムの使い方の学習ができる度合 運用性 運用や管理のしやすさの度合 ユーザエラー防止性 誤操作しないように保護する度合 ユーザインタフェー スの快美性 ユーザインタフェースが親しみがあり満足感のある応答ができ る度合 アクセシビリティ 幅広い層の特徴や能力を持つ人々が利用できる度合 信頼性 必要時に実行するこ とができる度合 成熟性 通常時に信頼性のニーズを満たす度合 可用性 必要時に運用、接続できる度合 障害許容性 障害時に運用できる度合 回復性 障害時にデータやシステムが回復したり再構築できる度合 情報システム/ソフトウェアの品質メトリクスセット http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf
- 41. Japan Java User Group 設計の進め方 • 品質特性 2/2 40 品質特性 特性の概要 副品質特性 概要 セキュリ ティ 不正にアクセスがさ れることなく、情報 やデータが保護され る度合 機密保持性 許可された者のみがアクセスできるようデータを保証する度合 インテグリティ プログラムやデータへの変更において未許可なアクセスを防止 する度合 否認防止性 イベントやアクションの発生を証明する度合 責任追跡性 エンティティの実行が唯一であることを証明する度合 真正性 リソースや物事の身元が要求されたものであることを証明でき る度合 保守性 効果的、効率的に保 守や修正ができる度 合 モジュール性 変更による他コンポーネントへの影響が最少で済むよう、独立 したコンポーネントで構成される度合い 再利用性 他のシステムや資産を構築する際に利用できる度合 解析性 変更部分や障害原因の特定のために診断したり、変更による影 響を評価する際の効果性、効率性の度合 変更性 欠陥や品質の低下なく変更が効果的、効率的にできる度合 試験性 テスト基準を確立し、評価するために実行する際の効果性、効 率性の度合 移植性 効果的、効率的に他 のハードウェアや実 行環境に移植できる 度合 順応性 別のもしくは進化したハードウェアやソフトウェアや他の運用 環境に効果的、効率的に順応できる度合 設置性 正しくインストール、もしくはアンインストールする際の効果 性、効率性の度合 置換性 同一の目的、環境下で他のソフトウェア製品に置換（リプレー ス）できる度合 情報システム/ソフトウェアの品質メトリクスセット http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf
- 42. Japan Java User Group • ドメインと技術要素のマッピング 設計の進め方 41 商品 商品登録 商品検索 購買 カート 受注 受注管理 記事 記事登録 商品担当者 受注担当者 コンテンツ 担当者 消費者 記事表示 CMS 検索エンジン 管理システム フロントシステム 配送担当者 RDB
- 43. Japan Java User Group 設計の進め方 • ドメインと技術要素のマッピング • もちろん、これだけが正解なわけではない –個別のITサービスごとに適した構成がある –たとえばクラウドサービスを活用すると、もっとコ ストが減るかもしれない 42 構成要素 特性 技術例 記事管理 記事登録のワークフロー管理、決 められた時間での公開 CMS 商品検索 ハイパフォーマンス Lucene 購買管理 複雑なロジックと使いやすさ MVC＋SQL バックエンド パターン化された画面 JSF+JPA
- 44. Japan Java User Group 設計の進め方 • さらに個別のドメイン毎にサービスを構成する 要素に求められることが異なる 43 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス
- 45. Japan Java User Group 設計の進め方 • 記事管理（CMS） 44 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス CMSを採用 CMSカスタマイ ズ設計書と専門 エンジニア 製品のログを監 視対象に追加 テンプレート更新はデザイ ナ、商品担当と連携して取 材し、コンテンツを制作 SEOを向上させ るためのタグを 追加させたい ホワイトペーパー に従った構成 制作ワークフ ロー制御とタイ マー公開 記事を読んで商 品を理解する
- 46. Japan Java User Group 設計の進め方 • 商品検索（Lucene） 45 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス 検索エンジンの Luceneを採用 ランキングや重 み付けの調整 結果の並び順を 最適化したい Luceneサーバを独立し、 定期的に商品データを取 り込ませる 応答時間を監視し、SLA を確認する APIを経由して呼ばれた 結果を返却する 求めている商品が すばやく見つかる 商品登録をしたも、リ アルタイムに変わるわ けではないことを理解
- 47. Japan Java User Group 設計の進め方 • 購買管理（MVC+SQL） 46 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス 自由度が高い素の MVCとSQLで構成。 決済は外部ASP利 用 初期はハイスキ ル要員だけど決 裁の追加は簡単 新しい決済手段 を追加したい 外部ASPのSLA計測 不正アタックの検出 ASPに障害があればエラーで はなく処理をスキップし、手 動決済を実施する 様々な決済手段に 対応している ASP障害時は手 動で作業 商品が簡単に買 える
- 48. Japan Java User Group 設計の進め方 • バックエンド（JSF+JPA） 47 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス パターン化され たUIしか受付け ない JSF+JPAで可能 な限り生産性を 向上 稼働状況を監視 して手動切替 コールドスタンバイで の信頼性確保で十分 ピークに応じて要員 を追加。役割分担に よるユーザの追加 新しい商品を扱うこと で属性の追加要求 商品が安心して受け取 れる 業務プロセスに従った 機能を提供
- 49. Japan Java User Group 設計の進め方 • Microservicesの落とし穴 –ドメイン毎の独自性を強くすると、全体的な保守性 が下がってくる可能性が高い » だからこそ、フルスタックエンジニアが求められるわけで すが –何事もバランスが肝心 48
- 50. Japan Java User Group まとめ 49
- 51. Japan Java User Group まとめ • システム開発の課題は –「いかに良いアプリケーションを作るか」から –「いかに良いITサービス運営を実現するか」に変わ ってきている • この状況で、いかにエンジニアとして生きるか –1つのパスが「アーキテクト」だと思う 50
- 52. Japan Java User Group まとめ • ITサービス運営のモデル v0.1 51 利用者の 体験価値 サービスの 振る舞い 静的な 構造 開発 プロセス 動的な 構成 企画 プロセス 運用 プロセス 業務 プロセス
- 53. Japan Java User Group まとめ • ITサービスにおけるアーキテクチャとは – ITサービス運営に関わる利害関係者の関心事を整合させた、 – ITサービスが提供すべき利用者の体験価値を実現するために、 – ITサービスの構成する要素の分割と関係のことであり、 – ITサービスがフィードバックを受けながら継続的に成長できることを保証 する • ざっくり言うと –ITサービスの各要素のバランスをとること 52
- 54. Japan Java User Group まとめ • アーキテクトの仕事は「アーキテクチャをデザ インすること」 • そのために –利害関係者を参加させ、関心事を理解する –関心事を整理し、整合させるように調整する –その関心事に沿ってITサービス運営要素を定義する • 幅広い知識が必要にはなるが、チームで行動し 、組織における役割が重要 53
- 55. Japan Java User Group まとめ • 設計の進め方 –Microservices的なアプローチは重要 –道具から発想せず、ITサービス運営全体を想像する –利害関係者とコミュニケーションすることが大事 54
- 56. Japan Java User Group まとめ • 最後に –これからの10年、ITはもっと社会の中で活躍するよ うになる » だから、エンタープライズはもっと面白くなる –でも、ただのエンジニアは10年で不要になる » 少なくとも価値が下がる –アーキテクトと名乗らなくても、アーキテクト的な 発想はできるし、日常で役に立つはず » 仕様書をコードに変換するだけのお仕事はやめませんか？ 55