Embed Size (px)
Citation preview
要求開発アライアンス 4月定例会
ITサービス運営におけるアーキテクチャ設計
グロースエクスパートナーズ（株）
鈴木雄介
2015年4月24日（金）
• グロースエクスパートナーズ（株）
– 執行役員/アーキテクチャ事業本部長
– http://www.gxp.co.jp/
• 日本Javaユーザーグループ
– 会長
– http://www.java-users.jp/
• SNS
– http://arclamp.hatenablog.com/
– @yusuke_arclamp
1
鈴木雄介
arclamp
アジェンダ
• 今、起きていること
• ITサービス運営を考える
• アーキテクチャとは
• ITサービス運営の開発
–マネジメント
–プラットフォーム
–マイクロサービス
• アーキテクトの役割
2
今、起きていること
3
4
「作る」から
https://www.flickr.com/photos/worldbank/6874927688/
「運営する」へ
「作る」から「運営する」へ
• ソフトウェアを作る
–決まった仕様書を元にして作る
–開発者が開発する
–プロジェクトが終了するまでの活動
• ITサービスを運営する
–利用されたフィードバックから改善する
–様々な人が関わる
–終わることのない持続的な活動
5
エンタープライズでも
• Webでの流れがエンタープライズへ
• ただし、エンタープライズ特有の背景
–利害関係者が多い（かつ、縦割りだったりする）
–連携先システムが多い（かつ、レガシーだったりする）
–急激に変化できない/しない（社会基盤としての責務）
–現状維持が重要（「現行踏襲」の罠）
–様々なシステム（B2B、B2C、B2Eなど）
–様々なルール（内部統制、セキュリティ、法制度など）
6
エンタープライズITサービス運営
• いかにエンタープライズでも「ITサービス運営」の流れを作っていくのか？
–特に重要なのは「業務」
–「開発」を変えるだけではなく「業務」を初めてとした企業の運営も変わる必要がある
–同じ言葉でも違う意味
»運用保守： 「作ったモノの動作を安定させる」
»運用保守： 「モノの動作を変えて、サービスを向上させる」
–ハードウェアライフサイクルとの大きな違いを理解する
7
ITサービス運営を考える
8
ITサービス運営のモデル
9
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
ITサービス運営のモデル
10
名前 概要 実例
構造 • ソフトウェアの構造 フレームワークドキュメント体系
プロセス • ソフトウェア開発プロセスや手順
アジャイルウォーターフォール
機能 • ソフトウェアの提供する機能
機能要件
ITサービス • 機能が動作した状態 非機能要件
サービス • 企業が提供するサービス 商品/サービス
満足度 • ユーザーの感じる満足度• 人それぞれ異なる
ITサービス運営のモデル
• その他としては「経営者」「社会通念」などもあげられる
11
名前 関心事 キーワード
企画 • ユーザーが満足するサービスの企画を検討する
事業計画満足度調査
開発 • ソフトウェアを開発する 作るQCD
運用 • ソフトウェアを安定して動作させる
動かすSLA
業務 • ユーザーに満足がいくサービスを提供する
ワークフロー
多様な利害関係者が携わる
12
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
価値は「利用」によって定義される
13
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
構成要素は互いに影響し依存する
14
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
フィードバックが回り続けること
15
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
ITサービス運営で理解すべきこと
• 多様な利害関係者が携わる
• 価値は「利用」によって定義される
• 構成要素は互いに影響し依存する
• フィードバックが回り続ける
16
ITサービス運営のモデル
17
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
要求開発とは
• 「コタツモデル」という協業関係
• 要求開発宣言
18
要求開発宣言• 情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
• 情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。
• 情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。
• ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。
• 要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。
• 「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。
19
Openthology ５つのプリンシプル
• 1.ビジネス主導によるIT化–業務の姿にITを合わせること
• 2.効果検証型プロセスの導入–最低1ヶ月に1回はモデリング効果を検証する
• 3.検証可能なビジネスモデル–概念モデルをビジネスフローで検証する
–ビジネスフローをプロトタイプで検証する
• 4.ビジネス担当主導のビジネスモデリング重視–現場のビジネスナレッジを重視したボトムアップアプローチ
• 5.フレキシブル・ビジネスモデリング–スピーディかつ状況に応じてビジネスモデリングを行う
20
Openthology ７つのプラクティス• 1. 勇気– 問題を発言する勇気を持とう
• 2. オープン– 業務問題点をオープンにする環境と人を形成
• 3. 成功は失敗から– 失敗を隠さない。業務問題を抱えていた部署が新たな改善策を提案する文化を築こう
• 4. スピーディなビジネス改善と公開– 改善できるものは即改善、改善したら即公開
• 5. 目的を理解したモデリング したモデリング– ビジネスモデリングはモデリングの目的を理解して初めて実践できる
• 6. モデリングの価値– モデリングによる視覚化・共有化こそが、ビジネス改善の第一歩
• 7. ペアモデリング– 常にモデルの共有化を図り、最低でもペアでモデリングすること
21
アーキテクチャとは
22
アーキテクチャとは
23
IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）
アーキテクチャとは
24
利害関係者の関心事 ビューポイント
ビュー
ミッション
システム制約（環境）
モデルによって記述
アーキテクチャ
• アーキテクチャとは
–システムのミッションに従い、システムのおかれた制約を前提としながら
–システムに関わる複数の利害関係者の関心事を整合させ、
»経営者、オーナー、ユーザー、プログラマ、 DBA、インフラ屋、PM、上司、保守メンバー
–ライフサイクル（設計から保守）まで意識した
–システムの分け方と組合せ方のこと
25
アーキテクチャとは
• システムの「分け方と組み合わせ方」のこと
–システムのミッションに従い、制約や環境を前提しながら、複数の利害関係者の関心事を整合させた「分け方と組み合わせ方」のこと
–簡単に言うと「システム全体のバランスを取る」こと
»空間的：利害関係者の関心事を意識する
»時間的：現在から未来の時間経過に伴う変化を意識する
26
アーキテクチャの成果とは
• システムの「構造とプロセスの決定」
–構造
»システムの機能が、どのような要素に分解されるのか
–プロセス
»それら要素をどのように組み立てるのか
–上記にリソースとスケジュールを加味すると、WBS（ガントチャート）になる
27
ITサービス運営のモデル
28
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
ｱｰｷﾃｸﾄ
なぜアーキテクチャを定義するのか
• アーキテクチャが全てのスタート
–「構造とプロセス」が明確でなければチームは動けない
• 構造とプロセスのバランスを判断できるのはアーキテクトにしかできない
–技術とビジネスとマネジメントのバランスを取る
–マネージャーは「実行としてのマネジメント」のプロ
29
ITサービス運営の開発はどうあるべきか
30
開発のデザイン
• 構造とプロセスをデザインすること
31
機能
構造
プロセス
アジャイル？
• あるべき「機能」を決めることができない
• とはいえ「構造」は決めないと作れない
• だから、段階的に調整可能なプロセスが必要
32
機能
構造
プロセス
アジャイル？
• 仮に「構造」が十分に柔軟で「機能」を段階的に提供できたら、アジャイルだけに頼る必要はなかったかもしれない
33
機能
構造
プロセス
現在における「構造」
• 「静的構造」から「動的構造」への進化
–サービスを組み合わせることでシステムを作り上げる
–「構造の利用」から「動作の利用」へ
–API+SLA＝(IT)サービス
34
動的構造への道のり
• もちろんクラウドが大きなきっかけ
–クラウドの提示した経済合理性は、実質的なコストだけではなく、「共有」にも意味があった
»おそらくパターンの「共有」＝標準化も全体最適化
–OSSがもたらした「共有」は静的構造が中心
»いまでの「定石なモデル」に対してはOSSが有効
35
構造とプロセス
• では、クラウド＋アジャイルが正解なのか？
• そんな単純なことではない
• 考えるべき流れ–マネジメント»アジャイルかウォーターフォールか
–プラットフォーム»クラウドを超えて
–マイクロサービス»ドメインの自治権
36
アジャイルか、ウォーターフォールか
マネジメント
37
マネジメントの基本
• プロジェクトマネジメントとは
–計画すること
–計測すること
–調整すること
• 「計画と実行のズレを見つけて調整していく」
–そのために計画するし、計測する
38
マネジメントの基本
• ちなみにPMBOK
39
立ち上げ 計画 遂行 コントロール 終結
統合 計画策定 計画実行 統合変更管理
スコープ（目的と範囲）
立ち上げ スコープ計画/定義 スコープ検証/変更管理
時間（期間） アクティビティ定義/順序設定/期間見積スケジュール作成
スケジュールコントロール
コスト（予算） 資源管理コストの見積/予算化
コストコントロール
品質 品質計画 品質保証 品質管理
人的資源 組織計画要員調達
チーム育成
コミュニケーション
コミュニケーション計画 情報配布 実行報告 完了手続き
リスク リスク・マネジメント計画リスク識別定性的/定量的リスク分析
リスクの監視・コントロール
調達 調達/引合計画 引合発注先選定契約管理
契約完了
計画 実行 調整
アジャイルとは
• 広義には”態度”
–アジャイルソフトウェア開発宣言（2001年）
»プロセスやツールよりも個人と対話を
»包括的なドキュメントよりも動くソフトウェアを
»契約交渉よりも顧客との協調を
»計画に従うことよりも変化への対応を
–当時の時代背景が透けて見える
»プロセスやドキュメントや契約や計画が重要だったころ
40
アジャイルとは
• 狭義にはプロジェクトマネジメント”手法”
–ソフトウェア開発では「計画精度をあげて調整の無駄を無くそう」が難しい
»製造業に比べると、目に見えないので計測がしにくい
»製造業に比べると、調整コストが小さい
–なら、調整を前提にすればいい
»小さく計画→動くもので確認→新しい計画＝調整
»顧客を巻き込んで調整する
»計画は定期的にする
41
アジャイルとは
• ”手法”としては画期的
–プロジェクトマネジメントにありがちな失敗
»計画の失敗：計画の精度が悪かった
»計測の失敗：進捗を測り間違えた
»調整の失敗：方向修正する話し合いができなかった
–だから、アジャイル手法は
»計画：精度が出るぐらい小さな計画にすればいい
»計測：動くソフトウェアで計測すればいい
»調整：定期的にみんなで見直すことにすればいい
42
スタイルの選択
• アジャイルが適する場合
–求めるビジネスが探索的
»ただし、エンタープライズでは限定的
–後工程での調整が重要になっている
»画面
• 適さない場合
–利害関係者が多くて合意形成が重要な場合
–他システム連携などの外部との約束事
43
スタイルの選択
• 手法が先ではない
–マネジメント手法が先にあるわけではなく「なにをすべきか」があったうえで「どうやるか」と考える
–アジャイルが絶対ではない
»ただし、完成されたモデルとしてのスクラムは共通言語として優秀ではある
–単純にリスク（ビジネス的/技術的）とリズム（フィードバックが返るまでの期間）を考えるだけでよい
44
クラウドを超えて
プラットフォーム
45
動的構造への理解
• クラウドの思想
–規模の経済の最大化
• プラットフォーム＝共有資源の定義
–仮想化の先としてのクラウド
–クラウド的発想をオンプレミスにも持ち込む
» Docker、Cloud Foundry
46
プラットフォーム
47
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
データ
SaaS
PaaS
IaaS
ロードバランサーストレージアーカイブCDNデータ転送RDB・NoSQLデータウェアハウスメモリキャッシュデータストリーム分散処理オーケストレーションサーチストリーミングメール配信メッセージキュープッシュ通知ワークフロー課金メディア変換コンテナデプロイユーザー活動分析モニタリング認証認可
プラットフォーム
• ミドルウェアの領域が非常に重要
–特定の機能を提供する
–様々なサービス間連携パターンとも理解できる
• 新たなプラットフォーム管理層の出現
–アプリに対応してプラットフォームが動的に構成される
–DockerやCloud Foundry
• データの扱いは、まだまだ注意
–ストックとフロー
–イベント駆動と分散処理
48
プラットフォーム
• プラットフォーム管理層の役割
49
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
コード
設定
実行環境
プラットフォーム管理
デプロイされたアプリケーションの「設定」に合わせて「実行環境」や利用する「ミドルウェア」をセットアップしれくれる
ドメインの自治権
マイクロサービス
50
マイクロサービス• 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/進化的な設計
51
マイクロサービス
• サービスによってシステムを構成する
–サービス同士はAPIによって連携する
–サービス同士は独立した構造とプロセスを持つ
–サービスは独自のライフサイクルを持つ
–サービスは個別のドメインに従う
52
ITｻｰﾋﾞｽ
ITｻｰﾋﾞｽ
ITｻｰﾋﾞｽ
マイクロサービス
• 実装技術というよりも「文化」「スタイル」
–「ドメイン」の固有性を認める
»ドメインに特化した構造とプロセスが必要
–チームに裁量権を与えることが最大の生産性を生む
–ただし、信頼できるチームであれば
53
マイクロサービス
• ドメインを発見するには変化の境界を見極める
–外的変化要因になるもの
»ユーザーの役割が異なる
»ユーザーによって利用されるサイクルが違う
–その他の変化要因
»セキュリティなどの品質特性
–必ず境界にするわけではない。パターンにくくっていくことが大事
54
IT/ソフトウェア品質特性
• 8つの品質特性と31の副特性
55
品質特性 品質副特性
機能適合性 完全性、正確性、適切性
性能効率性 時間効率性、資源利用性、キャパシティ
互換性 共存性、相互運用性
使用性適切度認識性、習得性、運用性、ユーザエラー防止性ユーザインタフェースの快美性、アクセシビリティ
信頼性 成熟性、可用性、障害許容性、回復性
セキュリティ機密保持性、インテグリティ、否認防止性責任追跡性、真正性
保守性 モジュール性、再利用性、解析性、変更性、試験性
移植性 順応性、設置性、置換性「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクト
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
56
品質特性 特性の概要 副品質特性 概要
機能適合性実装された機能がニーズを満たす度合
完全性 ニーズを機能がユーザの目的やタスクを包含している度合
正確性 必要な精度で正確な結果を与える度合
適切性 機能が定められたタスクや目的を円滑に遂行する度合
性能効率性システムの実行時の性能や資源効率の度合
時間効率性 実行時のシステムの応答時間、処理時間などの処理能力の度合
資源利用性 実行時に使用する資源量や種類
キャパシティ 要求を満たすための製品やシステムのパラメータの最大許容値
互換性他製品やシステムと機能や情報を共有、変換できる度合
共存性 他製品へ負の影響を与えず、共通の環境や資源を共有して効果的に実行する度合
相互運用性 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
構造とプロセスの選択
57
構造とプロセスの選択
• どのように選択すべきか？
• 回答：「ドメインによる」
58
機能
構造
プロセス
プラットフォームとマイクロサービス
• プラットフォーム
–どのレベルで共有資源として”定義”すべきか
»パブリック、プライベート、ハイブリッド
–共有しすぎると対応できないことがでてくる
• マイクロサービス
–どのレベルで構造とプロセスの固有性を認めるか
»業界、グループ、企業、事業、業務
–あまりにも独立させるとスケールしない
59
WFとアジャイル
• ウォーターフォール
–計画：計画によってリソースを最適化する
–計測：計画を基準に計測すれば正しい
–調整：計画通りにするための調整を実施する
• アジャイル手法
–計画：精度が出るぐらい小さな計画にする
–計測：動くソフトウェアで計測する
–調整：定期的にみんなで見直す
60
アーキテクトの役割
61
アーキテクトの役割
• よりよいITサービス運営の実現に向けて、構造とプロセスの両輪をデザインする
–構造とプロセスの関係性が強いなら、それを切り離してデザインすることに意味は無い
–アーキテクチャは組織にしたがう、組織はアーキテクチャにしたがう
» Conwayの法則
–プロジェクトマネジメントは「実行」に主眼が置かれる
»「計画」はアーキテクトの仕事
62
どう設計すべきか
• 環境から独立してビルを設計してはいけない
–ビルが価値を産むのは、環境の中で運営されてこそ
–ビルの設備はとても重要だが、立地も重要
• その環境においてビルが存在することで何が起きるのかを考える必要がある
–周辺環境に与える影響も設計しなくてはならない
–交通手段は？飲食は？景観は？廃棄物は？日照は？風は？水の流れは？土壌は？
63
アーキテクトの作業
• やるべきことはたくさん
–利害関係者とのコミュニケーション
–それぞれの関心事の整理と整合
–それを実現する構造とプロセスの設計
»必要なだけの事前検証
–利害関係者への説明と調整
–開発チームへの引き渡し
–トレースと変更管理
–評価
64
アーキテクトのスキル
• 様々なスキルが必要
–コミュニケーション（傾聴、調整）
–モデリング
–予測とリーディング
–もちろん知識
• チームでやるべきことも多い
–1人でできるわけではない
65
まとめ
66
「作る」から「運営する」へ
• ソフトウェアを作る
–決まった仕様書を元にして作る
–開発者が開発する
–プロジェクトが終了するまでの活動
• ITサービスを運営する
–利用されたフィードバックから改善する
–様々な人が関わる
–終わることのない持続的な活動
67
ITサービス運営のモデル
68
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
アーキテクチャとアーキテクト
69
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
ｱｰｷﾃｸﾄ
開発のデザイン
• 構造とプロセスをデザインすること
70
機能
構造
プロセス
プラットフォームとマイクロサービス
• プラットフォーム
–どのレベルで共有資源として”定義”すべきか
»パブリック、プライベート、ハイブリッド
–共有しすぎると対応できないことがでてくる
• マイクロサービス
–どのレベルで構造とプロセスの固有性を認めるか
»業界、グループ、企業、事業、業務
–あまりにも独立させるとスケールしない
71
WFとアジャイル
• ウォーターフォール
–計画：計画によってリソースを最適化する
–計測：計画を基準に計測すれば正しい
–調整：計画通りにするための調整を実施する
• アジャイル手法
–計画：精度が出るぐらい小さな計画にする
–計測：動くソフトウェアで計測する
–調整：定期的にみんなで見直す
72
73『建築について』をアウグストゥスに披露するウィトルウィウスhttp://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A3%E3%83%88%E3%83%AB%E3%82%A6%E3%82%A3%E3%82%A6%E3%82%B9
ある建築が成功するかどうかは、職人の技や形式ではなく、建築家の仕事が社会ともつ相関性に依存する
