Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
要求開発アライアンス 4月定例会
ITサービス運営におけるアーキテクチャ設計
グロースエクスパートナーズ(株)
鈴木雄介
2015年4月24日(金)
• グロースエクスパートナーズ(株)
– 執行役員/アーキテクチャ事業本部長
– http://www.gxp.co.jp/
• 日本Javaユーザーグループ
– 会長
– http://www.java-users.jp/
• SNS
– h...
アジェンダ
• 今、起きていること
• ITサービス運営を考える
• アーキテクチャとは
• ITサービス運営の開発
–マネジメント
–プラットフォーム
–マイクロサービス
• アーキテクトの役割
2
今、起きていること
3
4
「作る」から
https://www.flickr.com/photos/worldbank/6874927688/
「運営する」へ
「作る」から「運営する」へ
• ソフトウェアを作る
–決まった仕様書を元にして作る
–開発者が開発する
–プロジェクトが終了するまでの活動
• ITサービスを運営する
–利用されたフィードバックから改善する
–様々な人が関わる
–終わることのな...
エンタープライズでも
• Webでの流れがエンタープライズへ
• ただし、エンタープライズ特有の背景
–利害関係者が多い(かつ、縦割りだったりする)
–連携先システムが多い(かつ、レガシーだったりする)
–急激に変化できない/しない(社会基盤と...
エンタープライズITサービス運営
• いかにエンタープライズでも「ITサービス運営」
の流れを作っていくのか?
–特に重要なのは「業務」
–「開発」を変えるだけではなく「業務」を初めてとした
企業の運営も変わる必要がある
–同じ言葉でも違う意味...
ITサービス運営を考える
8
ITサービス運営のモデル
9
サービス機能
IT
サービス
満足度
構造
開発 企画
運用 業務
プロ
セス
ITサービス運営のモデル
10
名前 概要 実例
構造 • ソフトウェアの構造 フレームワーク
ドキュメント体系
プロセス • ソフトウェア開発プロセス
や手順
アジャイル
ウォーターフォール
機能 • ソフトウェアの提供する機
能
機能要件
...
ITサービス運営のモデル
• その他としては「経営者」「社会通念」などもあげられる
11
名前 関心事 キーワード
企画 • ユーザーが満足するサービ
スの企画を検討する
事業計画
満足度調査
開発 • ソフトウェアを開発する 作る
QCD
運...
多様な利害関係者が携わる
12
サービス機能
IT
サービス
満足度
構造
開発 企画
運用 業務
プロ
セス
価値は「利用」によって定義される
13
サービス機能
IT
サービス
満足度
構造
開発 企画
運用 業務
プロ
セス
構成要素は互いに影響し依存する
14
サービス機能
IT
サービス
満足度
構造
開発 企画
運用 業務
プロ
セス
フィードバックが回り続けること
15
サービス機能
IT
サービス
満足度
構造
開発 企画
運用 業務
プロ
セス
ITサービス運営で理解すべきこと
• 多様な利害関係者が携わる
• 価値は「利用」によって定義される
• 構成要素は互いに影響し依存する
• フィードバックが回り続ける
16
ITサービス運営のモデル
17
サービス機能
IT
サービス
満足度
構造
開発 企画
運用 業務
プロ
セス
要求開発とは
• 「コタツモデル」という協業関係
• 要求開発宣言
18
要求開発宣言
• 情報システムに対する要求は、あらかじめ存在しているものではなく、
ビジネス価値にもとづいて「開発」されるべきものである。
• 情報システムは、それ単体ではなく、人間の業務活動と相互作用する一
体化した業務プロセスとしてデザイン...
Openthology 5つのプリンシプル
• 1.ビジネス主導によるIT化
– 業務の姿にITを合わせること
• 2.効果検証型プロセスの導入
– 最低1ヶ月に1回はモデリング効果を検証する
• 3.検証可能なビジネスモデル
– 概念モデルを...
Openthology 7つのプラクティス
• 1. 勇気
– 問題を発言する勇気を持とう
• 2. オープン
– 業務問題点をオープンにする環境と人を形成
• 3. 成功は失敗から
– 失敗を隠さない。業務問題を抱えていた部署が新たな改善策を...
アーキテクチャとは
22
アーキテクチャとは
23
IEEE-Std-1471-2000 Recommended Practice for Architectural Description
of Software-Intensive Systems(アーキテクチャ記述...
アーキテクチャとは
24
利害関係者の
関心事 ビューポイント
ビュー
ミッション
システム
制約(環境)
モデルによって記述
アーキテクチャ
• アーキテクチャとは
–システムのミッションに従い、システムのおかれた制約
を前提としながら
–システムに関わる複数の利害関係者の関心事を整合させ
、
» 経営者、オーナー、ユーザー、プログラマ、 DBA、インフラ
屋、PM、...
アーキテクチャとは
• システムの「分け方と組み合わせ方」のこと
–システムのミッションに従い、制約や環境を前提しなが
ら、複数の利害関係者の関心事を整合させた「分け方と
組み合わせ方」のこと
–簡単に言うと「システム全体のバランスを取る」こと...
アーキテクチャの成果とは
• システムの「構造とプロセスの決定」
–構造
» システムの機能が、どのような要素に分解されるのか
–プロセス
» それら要素をどのように組み立てるのか
–上記にリソースとスケジュールを加味すると、WBS(
ガントチ...
ITサービス運営のモデル
28
サービス機能
IT
サービス
満足度
構造
開発 企画
運用 業務
プロ
セス
アーキテクト
なぜアーキテクチャを定義するのか
• アーキテクチャが全てのスタート
–「構造とプロセス」が明確でなければチームは動けない
• 構造とプロセスのバランスを判断できるのはアー
キテクトにしかできない
–技術とビジネスとマネジメントのバランスを取る...
ITサービス運営の開発は
どうあるべきか
30
開発のデザイン
• 構造とプロセスをデザインすること
31
機能
構造
プロ
セス
アジャイル?
• あるべき「機能」を決めることができない
• とはいえ「構造」は決めないと作れない
• だから、段階的に調整可能なプロセスが必要
32
機能
構造
プロ
セス
アジャイル?
• 仮に「構造」が十分に柔軟で「機能」を段階的に
提供できたら、アジャイルだけに頼る必要はなか
ったかもしれない
33
機能
構造
プロ
セス
現在における「構造」
• 「静的構造」から「動的構造」への進化
–サービスを組み合わせることでシステムを作り上げる
–「構造の利用」から「動作の利用」へ
–API+SLA=(IT)サービス
34
動的構造への道のり
• もちろんクラウドが大きなきっかけ
–クラウドの提示した経済合理性は、実質的なコストだけ
ではなく、「共有」にも意味があった
» おそらくパターンの「共有」=標準化も全体最適化
–OSSがもたらした「共有」は静的構造が中心...
構造とプロセス
• では、クラウド+アジャイルが正解なのか?
• そんな単純なことではない
• 考えるべき流れ
–マネジメント
» アジャイルかウォーターフォールか
–プラットフォーム
» クラウドを超えて
–マイクロサービス
» ドメインの自...
アジャイルか、ウォーターフォールか
マネジメント
37
マネジメントの基本
• プロジェクトマネジメントとは
–計画すること
–計測すること
–調整すること
• 「計画と実行のズレを見つけて調整していく」
–そのために計画するし、計測する
38
マネジメントの基本
• ちなみにPMBOK
39
立ち上げ 計画 遂行 コントロール 終結
統合 計画策定 計画実行 統合変更管理
スコープ
(目的と範囲)
立ち上げ スコープ計画/定義 スコープ検証/変更管理
時間(期間) アクティビティ定義...
アジャイルとは
• 広義には”態度”
–アジャイルソフトウェア開発宣言(2001年)
» プロセスやツールよりも個人と対話を
» 包括的なドキュメントよりも動くソフトウェアを
» 契約交渉よりも顧客との協調を
» 計画に従うことよりも変化への対...
アジャイルとは
• 狭義にはプロジェクトマネジメント”手法”
–ソフトウェア開発では「計画精度をあげて調整の無駄を
無くそう」が難しい
» 製造業に比べると、目に見えないので計測がしにくい
» 製造業に比べると、調整コストが小さい
–なら、調整...
アジャイルとは
• ”手法”としては画期的
–プロジェクトマネジメントにありがちな失敗
» 計画の失敗:計画の精度が悪かった
» 計測の失敗:進捗を測り間違えた
» 調整の失敗:方向修正する話し合いができなかった
–だから、アジャイル手法は
»...
スタイルの選択
• アジャイルが適する場合
–求めるビジネスが探索的
» ただし、エンタープライズでは限定的
–後工程での調整が重要になっている
» 画面
• 適さない場合
–利害関係者が多くて合意形成が重要な場合
–他システム連携などの外部と...
スタイルの選択
• 手法が先ではない
–マネジメント手法が先にあるわけではなく「なにをすべ
きか」があったうえで「どうやるか」と考える
–アジャイルが絶対ではない
» ただし、完成されたモデルとしてのスクラムは共通言語として
優秀ではある
–単...
クラウドを超えて
プラットフォーム
45
動的構造への理解
• クラウドの思想
–規模の経済の最大化
• プラットフォーム=共有資源の定義
–仮想化の先としてのクラウド
–クラウド的発想をオンプレミスにも持ち込む
» Docker、Cloud Foundry
46
プラットフォーム
47
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
データ
SaaS
PaaS
IaaS
ロードバランサー
ストレージアーカイブ
CDN
データ転送
RDB・NoSQL
データウェアハウ...
プラットフォーム
• ミドルウェアの領域が非常に重要
–特定の機能を提供する
–様々なサービス間連携パターンとも理解できる
• 新たなプラットフォーム管理層の出現
–アプリに対応してプラットフォームが動的に構成される
–DockerやCloud...
プラットフォーム
• プラットフォーム管理層の役割
49
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
コード
設定
実行環境
プラットフォーム管理
デプロイされたアプリ
ケーションの「設定」に
合わせて...
ドメインの自治権
マイクロサービス
50
マイクロサービス
• Microservicesの9つの特徴
– Componentization via Services/サービスによるコンポーネン
ト化
– Organized around Business Capabilities/ビ...
マイクロサービス
• サービスによってシステムを構成する
–サービス同士はAPIによって連携する
–サービス同士は独立した構造とプロセスを持つ
–サービスは独自のライフサイクルを持つ
–サービスは個別のドメインに従う
52
IT
サービス
I...
マイクロサービス
• 実装技術というよりも「文化」「スタイル」
–「ドメイン」の固有性を認める
» ドメインに特化した構造とプロセスが必要
–チームに裁量権を与えることが最大の生産性を生む
–ただし、信頼できるチームであれば
53
マイクロサービス
• ドメインを発見するには変化の境界を見極める
–外的変化要因になるもの
» ユーザーの役割が異なる
» ユーザーによって利用されるサイクルが違う
–その他の変化要因
» セキュリティなどの品質特性
–必ず境界にするわけではな...
IT/ソフトウェア品質特性
• 8つの品質特性と31の副特性
55
品質特性 品質副特性
機能適合性 完全性、正確性、適切性
性能効率性 時間効率性、資源利用性、キャパシティ
互換性 共存性、相互運用性
使用性
適切度認識性、習得性、運用性、ユ...
56
品質特性 特性の概要 副品質特性 概要
機能適合性
実装された機能がニーズを満たす
度合
完全性 ニーズを機能がユーザの目的やタスクを包含している度合
正確性 必要な精度で正確な結果を与える度合
適切性 機能が定められたタスクや目的を円滑...
構造とプロセスの選択
57
構造とプロセスの選択
• どのように選択すべきか?
• 回答:「ドメインによる」
58
機能
構造
プロ
セス
プラットフォームとマイクロサービス
• プラットフォーム
–どのレベルで共有資源として”定義”すべきか
» パブリック、プライベート、ハイブリッド
–共有しすぎると対応できないことがでてくる
• マイクロサービス
–どのレベルで構造とプロセスの...
WFとアジャイル
• ウォーターフォール
–計画:計画によってリソースを最適化する
–計測:計画を基準に計測すれば正しい
–調整:計画通りにするための調整を実施する
• アジャイル手法
–計画:精度が出るぐらい小さな計画にする
–計測:動くソフ...
アーキテクトの役割
61
アーキテクトの役割
• よりよいITサービス運営の実現に向けて、構造と
プロセスの両輪をデザインする
–構造とプロセスの関係性が強いなら、それを切り離して
デザインすることに意味は無い
–アーキテクチャは組織にしたがう、組織はアーキテクチ
ャに...
どう設計すべきか
• 環境から独立してビルを設計してはいけない
–ビルが価値を産むのは、環境の中で運営されてこそ
–ビルの設備はとても重要だが、立地も重要
• その環境においてビルが存在することで何が起き
るのかを考える必要がある
–周辺環境に...
アーキテクトの作業
• やるべきことはたくさん
–利害関係者とのコミュニケーション
–それぞれの関心事の整理と整合
–それを実現する構造とプロセスの設計
» 必要なだけの事前検証
–利害関係者への説明と調整
–開発チームへの引き渡し
–トレース...
アーキテクトのスキル
• 様々なスキルが必要
–コミュニケーション(傾聴、調整)
–モデリング
–予測とリーディング
–もちろん知識
• チームでやるべきことも多い
–1人でできるわけではない
65
まとめ
66
「作る」から「運営する」へ
• ソフトウェアを作る
–決まった仕様書を元にして作る
–開発者が開発する
–プロジェクトが終了するまでの活動
• ITサービスを運営する
–利用されたフィードバックから改善する
–様々な人が関わる
–終わることのな...
ITサービス運営のモデル
68
サービス機能
IT
サービス
満足度
構造
開発 企画
運用 業務
プロ
セス
アーキテクチャとアーキテクト
69
サービス機能
IT
サービス
満足度
構造
開発 企画
運用 業務
プロ
セス
アーキテクト
開発のデザイン
• 構造とプロセスをデザインすること
70
機能
構造
プロ
セス
プラットフォームとマイクロサービス
• プラットフォーム
–どのレベルで共有資源として”定義”すべきか
» パブリック、プライベート、ハイブリッド
–共有しすぎると対応できないことがでてくる
• マイクロサービス
–どのレベルで構造とプロセスの...
WFとアジャイル
• ウォーターフォール
–計画:計画によってリソースを最適化する
–計測:計画を基準に計測すれば正しい
–調整:計画通りにするための調整を実施する
• アジャイル手法
–計画:精度が出るぐらい小さな計画にする
–計測:動くソフ...
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...
Upcoming SlideShare
Loading in …5
×

ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会

2,313 views

Published on

2015/4/24に開催された要求開発アライアンス 4月定例会での講演「ITサービス運営におけるアーキテクチャ設計」の講演資料です。
Toggerはこちら: http://togetter.com/li/812435

Published in: Technology
  • Be the first to comment

ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会

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

×