「itアーキテクトの役割と責任」デブサミ2015 20-c-1
TRANSCRIPT
【20-C-1】ITアーキテクトの役割と責任
グロースエクスパートナーズ（株）
鈴木雄介
2015年2月20日（金）
#devsumiC
• グロースエクスパートナーズ（株）
– 執行役員/ITアーキテクト
– http://www.gxp.co.jp/
• 日本Javaユーザーグループ
– 会長
– http://www.java-users.jp/
• ブログ
– http://arclamp.hatenablog.com/
1
鈴木雄介
arclamp
今日、話したいこと
• 現在のシステム開発に何が求められているのか
• アーキテクチャは何をもたらすのか
• ITアーキテクトの役割やスキル
• ITアーキテクトの責任と覚悟
2
アジェンダ
• 今、起きていること
• ITサービス運営を考える
• ITサービス運営の開発はどうあるべきか
• 動的構造とは
• アーキテクトの役割
• アーキテクトの責任
3
今、起きていること
4
5
「作る」から
https://www.flickr.com/photos/worldbank/6874927688/
「運営する」へ
「作る」から「運営する」へ
• ソフトウェアを作る
–決まった仕様書を元にして作る
–開発者が開発する
–プロジェクトが終了するまでの活動
• ITサービスを運営する
–利用されたフィードバックから改善する
–様々な人が関わる
–終わることのない持続的な活動
6
ITサービス運営を考える
7
ITサービス運営のモデル
8
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
ITサービス運営のモデル
9
名前 概要 実例
構造 • ソフトウェアの構造 フレームワークドキュメント体系
プロセス • ソフトウェア開発プロセスや手順
アジャイルウォーターフォール
機能 • ソフトウェアの提供する機能
機能要件
ITサービス • 機能が動作した状態 非機能要件
サービス • 企業が提供するサービス 商品/サービス
満足度 • ユーザーの感じる満足度• 人それぞれ異なる
ITサービス運営のモデル
• その他としては「経営者」「社会通念」などもあげられる
10
名前 関心事 キーワード
企画 • ユーザーが満足するサービスの企画を検討する
事業計画満足度調査
開発 • ソフトウェアを開発する 作るQCD
運用 • ソフトウェアを安定して動作させる
動かすSLA
業務 • ユーザーに満足がいくサービスを提供する
ワークフロー
多様な利害関係者が携わる
11
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
価値は「利用」によって定義される
12
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
構成要素は互いに影響し依存する
13
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
フィードバックが回り続けること
14
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
ITサービス運営で理解すべきこと
• 多様な利害関係者が携わる
• 価値は「利用」によって定義される
• 構成要素は互いに影響し依存する
• フィードバックが回り続ける
15
ITサービス運営の開発はどうあるべきか
16
17https://www.flickr.com/photos/zlatko/3198796703
アジャイル？
なぜアジャイルが必要だったか
• あるべき「機能」を決めることができない
• とはいえ「構造」は決めないと作れない
• だから、段階的に調整可能なプロセスが必要
18
機能
構造
プロセス
なぜアジャイルが必要だったか
• 仮に「構造」が十分に柔軟で「機能」を段階的に提供できたら、アジャイルだけに頼る必要はなかったかもしれない
19
機能
構造
プロセス
20https://www.flickr.com/photos/rahego/6479063525/
なぜアジャイルが必要だったか？
それは「構造」が敗北した歴史
現在における構造
• 「静的構造」から「動的構造」への進化
–サービスを組み合わせることでシステムを作り上げる
–「構造の利用」から「動作の利用」へ
–API+SLA＝(IT)サービス
–動的構造は計画型プロセスも許容する
»システム間連携や内部統制対応には計画型プロセスが変わらず重要
21
動的構造への道のり
• もちろんクラウドが大きなきっかけ
–クラウドの提示した経済合理性は、実質的なコストだけではなく、「共有」にも意味があった
»おそらくパターンの「共有」＝標準化も全体最適化
–OSSがもたらした「共有」は静的構造が中心
22
構造とプロセスの歴史
• 昔：
–静的構造を前提にした計画型プロセス
• アジャイル：
–静的構造を調整型プロセスによる補完
• これから：
–動的構造と調整型あるいは計画型プロセスの選択
23
動的構造とは
24
動的構造への理解
• 1.Microservices
• 2.プラットフォーム
25
1.Microservices
• サービスによってシステムを構成する
–サービス同士はAPIによって連携する
–サービス同士は独立した構造とプロセスを持つ
–サービスは独自のライフサイクルを持つ
–サービスは個別のドメインに従う
26
ITｻｰﾋﾞｽ
ITｻｰﾋﾞｽ
ITｻｰﾋﾞｽ
2.プラットフォーム
27
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
データ
SaaS
PaaS
IaaS
ロードバランサーストレージアーカイブCDNデータ転送RDB・NoSQLデータウェアハウスメモリキャッシュデータストリーム分散処理オーケストレーションサーチストリーミングメール配信メッセージキュープッシュ通知ワークフロー課金メディア変換コンテナデプロイユーザー活動分析モニタリング認証認可
2.プラットフォーム
• ミドルウェアの領域が非常に重要
–特定の機能を提供する
–様々なサービス間連携パターンとも理解できる
• 新たなプラットフォーム管理層の出現
–アプリに対応してプラットフォームが動的に構成される
–DockerやCloud Foundry
• データの扱いは、まだまだ注意
–ストックとフロー
–イベント駆動と分散処理
28
2.プラットフォーム
• プラットフォーム管理層の役割
29
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
コード
設定
実行環境
プラットフォーム管理
デプロイされたアプリケーションの「設定」に合わせて「実行環境」や利用する「ミドルウェア」をセットアップしれくれる
アーキテクトの役割
30
アーキテクトの役割
• よりよいITサービス運営の実現に向けて、構造とプロセスの両輪をデザインする
–構造とプロセスの関係性が強いなら、それを切り離してデザインすることに意味は無い
–アーキテクチャは組織にしたがう、組織はアーキテクチャにしたがう
» Conwayの法則
–プロジェクトマネジメントは「実行」に主眼が置かれる
»「計画」はアーキテクトの仕事
31
アーキテクトの位置づけ
32
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
ｱｰｷﾃｸﾄ
どう設計すべきか
• 環境から独立してビルを設計してはいけない
–ビルが価値を産むのは、環境の中で運営されてこそ
–ビルの設備はとても重要だが、立地も重要
• その環境においてビルが存在することで何が起きるのかを考える必要がある
–周辺環境に与える影響も設計しなくてはならない
–交通手段は？飲食は？景観は？廃棄物は？日照は？風は？水の流れは？土壌は？
33
アーキテクトの作業
• やるべきことはたくさん
–利害関係者とのコミュニケーション
–それぞれの関心事の整理と整合
–それを実現する構造とプロセスの設計
»必要なだけの事前検証
–利害関係者への説明と調整
–開発チームへの引き渡し
–トレースと変更管理
–評価
34
アーキテクトのスキル
• 様々なスキルが必要
–コミュニケーション（傾聴、調整）
–モデリング
–予測とリーディング
–もちろん知識
• チームでやるべきことも多い
–1人でできるわけではない
35
アーキテクトの責任
36
アーキテクトの覚悟と責任
• 最大公約数を目指す
• 銀の弾丸はない
• 妥協せず、諦める
37
最大公約数を目指す
• 「最小公倍数」ではなく「最大公約数」を目指す
–「最小公倍数」は全員が満足する
–「最大公約数」には誰も満足しない
–でも「最小公倍数」は誰も幸せにしない
• 「最大公約数」を目指すことを誰も理解してくれない
38
39
決定は「誰か」のものではなく、自分のものだという責任
https://www.flickr.com/photos/vincenadmathsw/6988287627
銀の弾丸はない
• 誰かの成功事例が自分に当てはまるとは限らない
–知識は知識でしかない
–体験によってしか得られないことがある
–必要なだけの事前検証をする
40https://www.flickr.com/photos/davidw/152220578
41https://www.flickr.com/photos/mustafakhayat/6933636588
銀の弾丸をこめたら、打ち抜くまでやめないのが責任
妥協せず、諦める
• 妥協はできないが、適切に諦めること
–アーキテクトは神ではない。全てを見通すことなどできない。もちろん未来も。
–今ある材料で判断できないなら、材料を集めるべき。妥協してはならない
–でも、どこかで諦めないといけない
–そのときは持続的な中で改善していく
42
43
諦めるまで考え続ける、諦める時は未来に託すのが責任
http://www.flickr.com/photos/atomdocs/3275758118/
まとめ
44
「作る」から「運営する」へ
• ソフトウェアを作る
–決まった仕様書を元にして作る
–開発者が開発する
–プロジェクトが終了するまでの活動
• ITサービスを運営する
–利用されたフィードバックから改善する
–様々な人が関わる
–終わることのない持続的な活動
45
ITサービス運営のモデル
46
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
ITサービス運営で理解すべきこと
• 多様な利害関係者が携わること
• 価値は「利用」によって定義されること
• サービスの構成要素は互いに影響し依存すること
• フィードバックが回り続けること
47
現在におけるアーキテクチャ
• アジャイルによって「構造」を補完していた
• 「静的構造」から「動的構造」への進化
–Microservices
–プラットフォーム
48
アーキテクトの位置づけ
49
ｻｰﾋﾞｽ機能ITｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロセス
ｱｰｷﾃｸﾄ
アーキテクトの覚悟と責任
• 最大公約数を目指す
• 銀の弾丸はない
• 妥協せず、諦める
50
51『建築について』をアウグストゥスに披露するウィトルウィウス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
ある建築が成功するかどうかは、職人の技や形式ではなく、建築家の仕事が社会ともつ相関性に依存する