2015/2/20に開催されたデブサミ2015での講演【20-C-1】「ITアーキテクトの役割と責任」の資料です。 http://togetter.com/li/784401

1. 【20-C-1】
ITアーキテクトの役割と責任
グロースエクスパートナーズ（株）
鈴木雄介
2015年2月20日（金）
#devsumiC

2. • グロースエクスパートナーズ（株）
– 執行役員/ITアーキテクト
– http://www.gxp.co.jp/
• 日本Javaユーザーグループ
– 会長
– http://www.java-users.jp/
• ブログ
– http://arclamp.hatenablog.com/
1
鈴木雄介
arclamp

3. 今日、話したいこと
• 現在のシステム開発に何が求められているのか
• アーキテクチャは何をもたらすのか
• ITアーキテクトの役割やスキル
• ITアーキテクトの責任と覚悟
2

4. アジェンダ
• 今、起きていること
• ITサービス運営を考える
• ITサービス運営の開発はどうあるべきか
• 動的構造とは
• アーキテクトの役割
• アーキテクトの責任
3

5. 今、起きていること
4

6. 5
「作る」から
https://www.flickr.com/photos/worldbank/6874927688/
「運営する」へ

7. 「作る」から「運営する」へ
• ソフトウェアを作る
–決まった仕様書を元にして作る
–開発者が開発する
–プロジェクトが終了するまでの活動
• ITサービスを運営する
–利用されたフィードバックから改善する
–様々な人が関わる
–終わることのない持続的な活動
6

8. ITサービス運営を考える
7

9. ITサービス運営のモデル
8
ｻｰﾋﾞｽ機能
IT
ｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロ
セス

10. ITサービス運営のモデル
9
名前 概要 実例
構造 • ソフトウェアの構造 フレームワーク
ドキュメント体系
プロセス • ソフトウェア開発プロセス
や手順
アジャイル
ウォーターフォール
機能 • ソフトウェアの提供する機
能
機能要件
ITサービス • 機能が動作した状態 非機能要件
サービス • 企業が提供するサービス 商品/サービス
満足度 • ユーザーの感じる満足度
• 人それぞれ異なる

11. ITサービス運営のモデル
• その他としては「経営者」「社会通念」などもあげられる
10
名前 関心事 キーワード
企画 • ユーザーが満足するサービ
スの企画を検討する
事業計画
満足度調査
開発 • ソフトウェアを開発する 作る
QCD
運用 • ソフトウェアを安定して動
作させる
動かす
SLA
業務 • ユーザーに満足がいくサー
ビスを提供する
ワークフロー

12. 多様な利害関係者が携わる
11
ｻｰﾋﾞｽ機能
IT
ｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロ
セス

13. 価値は「利用」によって定義される
12
ｻｰﾋﾞｽ機能
IT
ｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロ
セス

14. 構成要素は互いに影響し依存する
13
ｻｰﾋﾞｽ機能
IT
ｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロ
セス

15. フィードバックが回り続けること
14
ｻｰﾋﾞｽ機能
IT
ｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロ
セス

16. ITサービス運営で理解すべきこと
• 多様な利害関係者が携わる
• 価値は「利用」によって定義される
• 構成要素は互いに影響し依存する
• フィードバックが回り続ける
15

17. ITサービス運営の開発は
どうあるべきか
16

18. 17https://www.flickr.com/photos/zlatko/3198796703
アジャイル？

19. なぜアジャイルが必要だったか
• あるべき「機能」を決めることができない
• とはいえ「構造」は決めないと作れない
• だから、段階的に調整可能なプロセスが必要
18
機能
構造
プロ
セス

20. なぜアジャイルが必要だったか
• 仮に「構造」が十分に柔軟で「機能」を段階的に
提供できたら、アジャイルだけに頼る必要はなか
ったかもしれない
19
機能
構造
プロ
セス

21. 20https://www.flickr.com/photos/rahego/6479063525/
なぜアジャイルが必要だったか？
それは「構造」が敗北した歴史

22. 現在における構造
• 「静的構造」から「動的構造」への進化
–サービスを組み合わせることでシステムを作り上げる
–「構造の利用」から「動作の利用」へ
–API+SLA＝(IT)サービス
–動的構造は計画型プロセスも許容する
» システム間連携や内部統制対応には計画型プロセスが変わらず
重要
21

23. 動的構造への道のり
• もちろんクラウドが大きなきっかけ
–クラウドの提示した経済合理性は、実質的なコストだけ
ではなく、「共有」にも意味があった
» おそらくパターンの「共有」＝標準化も全体最適化
–OSSがもたらした「共有」は静的構造が中心
22

24. 構造とプロセスの歴史
• 昔：
–静的構造を前提にした計画型プロセス
• アジャイル：
–静的構造を調整型プロセスによる補完
• これから：
–動的構造と調整型あるいは計画型プロセスの選択
23

25. 動的構造とは
24

26. 動的構造への理解
• 1.Microservices
• 2.プラットフォーム
25

27. 1.Microservices
• サービスによってシステムを構成する
–サービス同士はAPIによって連携する
–サービス同士は独立した構造とプロセスを持つ
–サービスは独自のライフサイクルを持つ
–サービスは個別のドメインに従う
26
IT
ｻｰﾋﾞｽ
IT
ｻｰﾋﾞｽ
IT
ｻｰﾋﾞｽ

28. 2.プラットフォーム
27
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
データ
SaaS
PaaS
IaaS
ロードバランサー
ストレージアーカイブ
CDN
データ転送
RDB・NoSQL
データウェアハウス
メモリキャッシュ
データストリーム
分散処理
オーケストレーション
サーチ
ストリーミング
メール配信
メッセージキュー
プッシュ通知
ワークフロー
課金
メディア変換
コンテナ
デプロイ
ユーザー活動分析
モニタリング
認証認可

29. 2.プラットフォーム
• ミドルウェアの領域が非常に重要
–特定の機能を提供する
–様々なサービス間連携パターンとも理解できる
• 新たなプラットフォーム管理層の出現
–アプリに対応してプラットフォームが動的に構成される
–DockerやCloud Foundry
• データの扱いは、まだまだ注意
–ストックとフロー
–イベント駆動と分散処理
28

30. 2.プラットフォーム
• プラットフォーム管理層の役割
29
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
コード
設定
実行環境
プラットフォーム管理
デプロイされたアプリ
ケーションの「設定」に
合わせて「実行環境」や
利用する「ミドルウェ
ア」をセットアップしれ
くれる

31. アーキテクトの役割
30

32. アーキテクトの役割
• よりよいITサービス運営の実現に向けて、構造と
プロセスの両輪をデザインする
–構造とプロセスの関係性が強いなら、それを切り離して
デザインすることに意味は無い
–アーキテクチャは組織にしたがう、組織はアーキテクチ
ャにしたがう
» Conwayの法則
–プロジェクトマネジメントは「実行」に主眼が置かれる
» 「計画」はアーキテクトの仕事
31

33. アーキテクトの位置づけ
32
ｻｰﾋﾞｽ機能
IT
ｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロ
セス
ｱｰｷﾃｸﾄ

34. どう設計すべきか
• 環境から独立してビルを設計してはいけない
–ビルが価値を産むのは、環境の中で運営されてこそ
–ビルの設備はとても重要だが、立地も重要
• その環境においてビルが存在することで何が起き
るのかを考える必要がある
–周辺環境に与える影響も設計しなくてはならない
–交通手段は？飲食は？景観は？廃棄物は？日照は？風は
？水の流れは？土壌は？
33

35. アーキテクトの作業
• やるべきことはたくさん
–利害関係者とのコミュニケーション
–それぞれの関心事の整理と整合
–それを実現する構造とプロセスの設計
» 必要なだけの事前検証
–利害関係者への説明と調整
–開発チームへの引き渡し
–トレースと変更管理
–評価
34

36. アーキテクトのスキル
• 様々なスキルが必要
–コミュニケーション（傾聴、調整）
–モデリング
–予測とリーディング
–もちろん知識
• チームでやるべきことも多い
–1人でできるわけではない
35

37. アーキテクトの責任
36

38. アーキテクトの覚悟と責任
• 最大公約数を目指す
• 銀の弾丸はない
• 妥協せず、諦める
37

39. 最大公約数を目指す
• 「最小公倍数」ではなく「最大公約数」を目指す
–「最小公倍数」は全員が満足する
–「最大公約数」には誰も満足しない
–でも「最小公倍数」は誰も幸せにしない
• 「最大公約数」を目指すことを誰も理解してくれ
ない
38

40. 39
決定は「誰か」のものではなく、
自分のものだという責任
https://www.flickr.com/photos/vincenadmathsw/6988287627

41. 銀の弾丸はない
• 誰かの成功事例が自分
に当てはまるとは限ら
ない
–知識は知識でしかない
–体験によってしか得られ
ないことがある
–必要なだけの事前検証を
する
40https://www.flickr.com/photos/davidw/152220578

42. 41https://www.flickr.com/photos/mustafakhayat/6933636588
銀の弾丸をこめたら、
打ち抜くまでやめないのが責任

43. 妥協せず、諦める
• 妥協はできないが、適切に諦めること
–アーキテクトは神ではない。全てを見通すことなどでき
ない。もちろん未来も。
–今ある材料で判断できないなら、材料を集めるべき。妥
協してはならない
–でも、どこかで諦めないといけない
–そのときは持続的な中で改善していく
42

44. 43
諦めるまで考え続ける、
諦める時は未来に託すのが責任
http://www.flickr.com/photos/atomdocs/3275758118/

45. まとめ
44

46. 「作る」から「運営する」へ
• ソフトウェアを作る
–決まった仕様書を元にして作る
–開発者が開発する
–プロジェクトが終了するまでの活動
• ITサービスを運営する
–利用されたフィードバックから改善する
–様々な人が関わる
–終わることのない持続的な活動
45

47. ITサービス運営のモデル
46
ｻｰﾋﾞｽ機能
IT
ｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロ
セス

48. ITサービス運営で理解すべきこと
• 多様な利害関係者が携わること
• 価値は「利用」によって定義されること
• サービスの構成要素は互いに影響し依存すること
• フィードバックが回り続けること
47

49. 現在におけるアーキテクチャ
• アジャイルによって「構造」を補完していた
• 「静的構造」から「動的構造」への進化
–Microservices
–プラットフォーム
48

50. アーキテクトの位置づけ
49
ｻｰﾋﾞｽ機能
IT
ｻｰﾋﾞｽ
満足度
構造
開発 企画
運用 業務
プロ
セス
ｱｰｷﾃｸﾄ

51. アーキテクトの覚悟と責任
• 最大公約数を目指す
• 銀の弾丸はない
• 妥協せず、諦める
50

52. 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
ある建築が成功するかどうかは、職人の
技や形式ではなく、建築家の仕事が社会
ともつ相関性に依存する