ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
•
19 likes•4,285 views
2015/4/24に開催された要求開発アライアンス 4月定例会での講演「ITサービス運営におけるアーキテクチャ設計」の講演資料です。 Toggerはこちら： http://togetter.com/li/812435
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (11)
Similar to ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
Similar to ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会 (20)
More from Yusuke Suzuki
More from Yusuke Suzuki (12)
Recently uploaded
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
- 2. • グロースエクスパートナーズ（株） – 執行役員/アーキテクチャ事業本部長 – http://www.gxp.co.jp/ • 日本Javaユーザーグループ – 会長 – http://www.java-users.jp/ • SNS – http://arclamp.hatenablog.com/ – @yusuke_arclamp 1 鈴木雄介 arclamp
- 3. アジェンダ • 今、起きていること • ITサービス運営を考える • アーキテクチャとは • ITサービス運営の開発 –マネジメント –プラットフォーム –マイクロサービス • アーキテクトの役割 2
- 4. 今、起きていること 3
- 8. エンタープライズITサービス運営 • いかにエンタープライズでも「ITサービス運営」 の流れを作っていくのか？ –特に重要なのは「業務」 –「開発」を変えるだけではなく「業務」を初めてとした 企業の運営も変わる必要がある –同じ言葉でも違う意味 » 運用保守： 「作ったモノの動作を安定させる」 » 運用保守： 「モノの動作を変えて、サービスを向上させる」 –ハードウェアライフサイクルとの大きな違いを理解する 7
- 11. ITサービス運営のモデル 10 名前 概要 実例 構造 • ソフトウェアの構造 フレームワーク ドキュメント体系 プロセス • ソフトウェア開発プロセス や手順 アジャイル ウォーターフォール 機能 • ソフトウェアの提供する機 能 機能要件 ITサービス • 機能が動作した状態 非機能要件 サービス • 企業が提供するサービス 商品/サービス 満足度 • ユーザーの感じる満足度 • 人それぞれ異なる
- 12. ITサービス運営のモデル • その他としては「経営者」「社会通念」などもあげられる 11 名前 関心事 キーワード 企画 • ユーザーが満足するサービ スの企画を検討する 事業計画 満足度調査 開発 • ソフトウェアを開発する 作る QCD 運用 • ソフトウェアを安定して動 作させる 動かす SLA 業務 • ユーザーに満足がいくサー ビスを提供する ワークフロー
- 17. ITサービス運営で理解すべきこと • 多様な利害関係者が携わる • 価値は「利用」によって定義される • 構成要素は互いに影響し依存する • フィードバックが回り続ける 16
- 20. 要求開発宣言 • 情報システムに対する要求は、あらかじめ存在しているものではなく、 ビジネス価値にもとづいて「開発」されるべきものである。 • 情報システムは、それ単体ではなく、人間の業務活動と相互作用する一 体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上 を目的とするべきである。 • 情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシ ステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能であ る。 • ビジネス価値を満たす要求は、直接・間接にその価値に関わるステーク ホルダー間の合意形成を通じてのみ創り出される。 • 要求の開発は、命令統制によらず参加協調による継続的改善プロセスを 指向すべきである。 • 「ビジネスをモデルとして可視化する」ということが、合意形成、追跡 可能性、説明可能性、および継続的改善にとって、決定的に重要である 。 19
- 21. Openthology ５つのプリンシプル • 1.ビジネス主導によるIT化 – 業務の姿にITを合わせること • 2.効果検証型プロセスの導入 – 最低1ヶ月に1回はモデリング効果を検証する • 3.検証可能なビジネスモデル – 概念モデルをビジネスフローで検証する – ビジネスフローをプロトタイプで検証する • 4.ビジネス担当主導のビジネスモデリング重視 – 現場のビジネスナレッジを重視したボトムアップアプローチ • 5.フレキシブル・ビジネスモデリング – スピーディかつ状況に応じてビジネスモデリングを行う 20
- 22. Openthology ７つのプラクティス • 1. 勇気 – 問題を発言する勇気を持とう • 2. オープン – 業務問題点をオープンにする環境と人を形成 • 3. 成功は失敗から – 失敗を隠さない。業務問題を抱えていた部署が新たな改善策を提案する文化を 築こう • 4. スピーディなビジネス改善と公開 – 改善できるものは即改善、改善したら即公開 • 5. 目的を理解したモデリング したモデリング – ビジネスモデリングはモデリングの目的を理解して初めて実践できる • 6. モデリングの価値 – モデリングによる視覚化・共有化こそが、ビジネス改善の第一歩 • 7. ペアモデリング – 常にモデルの共有化を図り、最低でもペアでモデリングすること 21
- 23. アーキテクチャとは 22
- 24. アーキテクチャとは 23 IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）
- 26. アーキテクチャ • アーキテクチャとは –システムのミッションに従い、システムのおかれた制約 を前提としながら –システムに関わる複数の利害関係者の関心事を整合させ 、 » 経営者、オーナー、ユーザー、プログラマ、 DBA、インフラ 屋、PM、上司、保守メンバー –ライフサイクル（設計から保守）まで意識した –システムの分け方と組合せ方のこと 25
- 27. アーキテクチャとは • システムの「分け方と組み合わせ方」のこと –システムのミッションに従い、制約や環境を前提しなが ら、複数の利害関係者の関心事を整合させた「分け方と 組み合わせ方」のこと –簡単に言うと「システム全体のバランスを取る」こと » 空間的：利害関係者の関心事を意識する » 時間的：現在から未来の時間経過に伴う変化を意識する 26
- 28. アーキテクチャの成果とは • システムの「構造とプロセスの決定」 –構造 » システムの機能が、どのような要素に分解されるのか –プロセス » それら要素をどのように組み立てるのか –上記にリソースとスケジュールを加味すると、WBS（ ガントチャート）になる 27
- 33. アジャイル？ • あるべき「機能」を決めることができない • とはいえ「構造」は決めないと作れない • だから、段階的に調整可能なプロセスが必要 32 機能 構造 プロ セス
- 35. 現在における「構造」 • 「静的構造」から「動的構造」への進化 –サービスを組み合わせることでシステムを作り上げる –「構造の利用」から「動作の利用」へ –API+SLA＝(IT)サービス 34
- 36. 動的構造への道のり • もちろんクラウドが大きなきっかけ –クラウドの提示した経済合理性は、実質的なコストだけ ではなく、「共有」にも意味があった » おそらくパターンの「共有」＝標準化も全体最適化 –OSSがもたらした「共有」は静的構造が中心 » いまでの「定石なモデル」に対してはOSSが有効 35
- 37. 構造とプロセス • では、クラウド＋アジャイルが正解なのか？ • そんな単純なことではない • 考えるべき流れ –マネジメント » アジャイルかウォーターフォールか –プラットフォーム » クラウドを超えて –マイクロサービス » ドメインの自治権 36
- 40. マネジメントの基本 • ちなみにPMBOK 39 立ち上げ 計画 遂行 コントロール 終結 統合 計画策定 計画実行 統合変更管理 スコープ （目的と範囲） 立ち上げ スコープ計画/定義 スコープ検証/変更管理 時間（期間） アクティビティ定義/順序設 定/期間見積 スケジュール作成 スケジュールコントロール コスト（予算） 資源管理 コストの見積/予算化 コストコントロール 品質 品質計画 品質保証 品質管理 人的資源 組織計画 要員調達 チーム育成 コミュニケー ション コミュニケーション計画 情報配布 実行報告 完了手続き リスク リスク・マネジメント計画 リスク識別 定性的/定量的リスク分析 リスクの監視・コントロー ル 調達 調達/引合計画 引合 発注先選定 契約管理 契約完了 計画 実行 調整
- 41. アジャイルとは • 広義には”態度” –アジャイルソフトウェア開発宣言（2001年） » プロセスやツールよりも個人と対話を » 包括的なドキュメントよりも動くソフトウェアを » 契約交渉よりも顧客との協調を » 計画に従うことよりも変化への対応を –当時の時代背景が透けて見える » プロセスやドキュメントや契約や計画が重要だったころ 40
- 42. アジャイルとは • 狭義にはプロジェクトマネジメント”手法” –ソフトウェア開発では「計画精度をあげて調整の無駄を 無くそう」が難しい » 製造業に比べると、目に見えないので計測がしにくい » 製造業に比べると、調整コストが小さい –なら、調整を前提にすればいい » 小さく計画→動くもので確認→新しい計画＝調整 » 顧客を巻き込んで調整する » 計画は定期的にする 41
- 43. アジャイルとは • ”手法”としては画期的 –プロジェクトマネジメントにありがちな失敗 » 計画の失敗：計画の精度が悪かった » 計測の失敗：進捗を測り間違えた » 調整の失敗：方向修正する話し合いができなかった –だから、アジャイル手法は » 計画：精度が出るぐらい小さな計画にすればいい » 計測：動くソフトウェアで計測すればいい » 調整：定期的にみんなで見直すことにすればいい 42
- 44. スタイルの選択 • アジャイルが適する場合 –求めるビジネスが探索的 » ただし、エンタープライズでは限定的 –後工程での調整が重要になっている » 画面 • 適さない場合 –利害関係者が多くて合意形成が重要な場合 –他システム連携などの外部との約束事 43
- 47. 動的構造への理解 • クラウドの思想 –規模の経済の最大化 • プラットフォーム＝共有資源の定義 –仮想化の先としてのクラウド –クラウド的発想をオンプレミスにも持ち込む » Docker、Cloud Foundry 46
- 49. プラットフォーム • ミドルウェアの領域が非常に重要 –特定の機能を提供する –様々なサービス間連携パターンとも理解できる • 新たなプラットフォーム管理層の出現 –アプリに対応してプラットフォームが動的に構成される –DockerやCloud Foundry • データの扱いは、まだまだ注意 –ストックとフロー –イベント駆動と分散処理 48
- 52. マイクロサービス • 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
- 55. マイクロサービス • ドメインを発見するには変化の境界を見極める –外的変化要因になるもの » ユーザーの役割が異なる » ユーザーによって利用されるサイクルが違う –その他の変化要因 » セキュリティなどの品質特性 –必ず境界にするわけではない。パターンにくくっていく ことが大事 54
- 56. IT/ソフトウェア品質特性 • 8つの品質特性と31の副特性 55 品質特性 品質副特性 機能適合性 完全性、正確性、適切性 性能効率性 時間効率性、資源利用性、キャパシティ 互換性 共存性、相互運用性 使用性 適切度認識性、習得性、運用性、ユーザエラー防止性 ユーザインタフェースの快美性、アクセシビリティ 信頼性 成熟性、可用性、障害許容性、回復性 セキュリティ 機密保持性、インテグリティ、否認防止性 責任追跡性、真正性 保守性 モジュール性、再利用性、解析性、変更性、試験性 移植性 順応性、設置性、置換性 「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクト http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdf http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf
- 57. 56 品質特性 特性の概要 副品質特性 概要 機能適合性 実装された機能がニーズを満たす 度合 完全性 ニーズを機能がユーザの目的やタスクを包含している度合 正確性 必要な精度で正確な結果を与える度合 適切性 機能が定められたタスクや目的を円滑に遂行する度合 性能効率性 システムの実行時の性能や資源効 率の度合 時間効率性 実行時のシステムの応答時間、処理時間などの処理能力の度合 資源利用性 実行時に使用する資源量や種類 キャパシティ 要求を満たすための製品やシステムのパラメータの最大許容値 互換性 他製品やシステムと機能や情報を 共有、変換できる度合 共存性 他製品へ負の影響を与えず、共通の環境や資源を共有して効果的に実行する度合 相互運用性 2つ以上の製品やコンポーネント間で情報を交換、利用できる度合 使用性 効果的、効率的に利用できる度合 適切度認識性 ニーズに適した利用かどうか認識できる度合 習得性 システムの使い方の学習ができる度合 運用性 運用や管理のしやすさの度合 ユーザエラー防止性 誤操作しないように保護する度合 ユーザインタフェースの快 美性 ユーザインタフェースが親しみがあり満足感のある応答ができる度合 アクセシビリティ 幅広い層の特徴や能力を持つ人々が利用できる度合 信頼性 必要時に実行することができる度 合 成熟性 通常時に信頼性のニーズを満たす度合 可用性 必要時に運用、接続できる度合 障害許容性 障害時に運用できる度合 回復性 障害時にデータやシステムが回復したり再構築できる度合 セキュリ ティ 不正にアクセスがされることなく、 情報やデータが保護される度合 機密保持性 許可された者のみがアクセスできるようデータを保証する度合 インテグリティ プログラムやデータへの変更において未許可なアクセスを防止する度合 否認防止性 イベントやアクションの発生を証明する度合 責任追跡性 エンティティの実行が唯一であることを証明する度合 真正性 リソースや物事の身元が要求されたものであることを証明できる度合 保守性 効果的、効率的に保守や修正がで きる度合 モジュール性 変更による他コンポーネントへの影響が最少で済むよう、独立したコンポーネントで構成される度合い 再利用性 他のシステムや資産を構築する際に利用できる度合 解析性 変更部分や障害原因の特定のために診断したり、変更による影響を評価する際の効果性、効率性の度合 変更性 欠陥や品質の低下なく変更が効果的、効率的にできる度合 試験性 テスト基準を確立し、評価するために実行する際の効果性、効率性の度合 移植性 効果的、効率的に他のハードウェ アや実行環境に移植できる度合 順応性 別のもしくは進化したハードウェアやソフトウェアや他の運用環境に効果的、効率的に順応できる度合 設置性 正しくインストール、もしくはアンインストールする際の効果性、効率性の度合 置換性 同一の目的、環境下で他のソフトウェア製品に置換（リプレース）できる度合 「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクト http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdf http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf
- 58. 構造とプロセスの選択 57
- 60. プラットフォームとマイクロサービス • プラットフォーム –どのレベルで共有資源として”定義”すべきか » パブリック、プライベート、ハイブリッド –共有しすぎると対応できないことがでてくる • マイクロサービス –どのレベルで構造とプロセスの固有性を認めるか » 業界、グループ、企業、事業、業務 –あまりにも独立させるとスケールしない 59
- 62. アーキテクトの役割 61
- 63. アーキテクトの役割 • よりよいITサービス運営の実現に向けて、構造と プロセスの両輪をデザインする –構造とプロセスの関係性が強いなら、それを切り離して デザインすることに意味は無い –アーキテクチャは組織にしたがう、組織はアーキテクチ ャにしたがう » Conwayの法則 –プロジェクトマネジメントは「実行」に主眼が置かれる » 「計画」はアーキテクトの仕事 62
- 66. アーキテクトのスキル • 様々なスキルが必要 –コミュニケーション（傾聴、調整） –モデリング –予測とリーディング –もちろん知識 • チームでやるべきことも多い –1人でできるわけではない 65
- 67. まとめ 66
- 72. プラットフォームとマイクロサービス • プラットフォーム –どのレベルで共有資源として”定義”すべきか » パブリック、プライベート、ハイブリッド –共有しすぎると対応できないことがでてくる • マイクロサービス –どのレベルで構造とプロセスの固有性を認めるか » 業界、グループ、企業、事業、業務 –あまりにも独立させるとスケールしない 71