1. DevLOVE2012
どうしたら良いシステムが作れるのか
あなたが進むべき道を決めるための
アーキテクチャとマネジメントの話
#devlove2012a
グロースエクスパートナーズ株式会社
執行役員/ビジネスソリューション事業本部 本部長
日本Javaユーザーグループ会長
鈴木雄介

2. 自己紹介
• 鈴木雄介
– グロースエクスパートナーズ（株）
• 執行役員
• ビジネスソリューション事業本部 本部長
• 職業：ITアーキテクト
– 日本Javaユーザーグループ 会長
– 日本Springユーザーグループ 幹事
– @yusuke_arclamp
2
http://www.gxp.co.jp

3. agenda
• ソフトウェア開発とは
• アーキテクチャとマネジメント
• アーキテクチャとマネジメントの関係
• アーキテクトとマネージャー
• アーキテクチャとアジャイル
• これからの世界
3

4. ソフトウェア開発とは
4
http://www.flickr.com/photos/riebart/4466482623/

5. ソフトウェア開発とは
• ソフトウェア品質モデル
影響を与える
利用時の
利用時の
プロセス 内部 外部 利用時の
品質
品質
品質 品質 品質 品質
依存する
5
JISX0129-1 ソフトウェア製品の品質 第１部 品質モデル

6. ソフトウェア開発とは
• ソフトウェア品質モデル
特徴 例
利用時の品質 ・利用状況によって評価が異な ・ユーザーＡさんと
る ユーザーＢさんで評価
が異なる
外部品質 ・システムの振る舞い ・テストケース
・誰がテストしても同じ結果 ・外部仕様
・一般的な仕様策定の対象
内部品質 ・システムを構成している要素 ・クラス図
すべて（含ドキュメント） ・フレームワーク
・後に残り、評価が可能 ・ドキュメント
・エンジニアがこだわるところ
プロセス品質 ・後に残らない行動 ・コミュニケーション
・作業手順
6
JISX0129-1 ソフトウェア製品の品質 第１部 品質モデル

7. ソフトウェア開発とは
• ソフトウェア開発は、これらのバランス
を取ることが非常に大事になってくる
利用時の
利用時の
プロセス 内部 外部 利用時の
品質
品質
品質 品質 品質 品質
7

8. ソフトウェア開発とは
• ソフトウェア開発の失敗は、これらの依
存/影響関係が壊れていること
利用時の
利用時の
プロセス 内部 外部 利用時の
品質
品質
品質 品質 品質 品質
8

9. ソフトウェア開発とは
• 良いシステムを作るためには、各品質同
士に良い依存/影響関係をつくることが重
要
利用時の
利用時の
プロセス 内部 外部 利用時の
品質
品質
品質 品質 品質 品質
– 個別の品質よりもバランスが重要
9

10. アーキテクチャと
マネジメント
10

11. アーキテクチャとマネジメント
• アーキテクチャとは
IEEE-Std-1471-2000 Recommended Practice for Architectural Description
11
of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）

12. アーキテクチャとマネジメント
ミッション
システム
制約（環境）
ビュー
モデルによって記述
利害関係者の
関心事 ビューポイント
12

13. アーキテクチャとマネジメント
• アーキテクチャの定義
– システムのミッションに従い、システムのお
かれた制約を前提としながら
– システムに関わる複数の利害関係者の関心事
を整合させ、
• 経営者、オーナー、ユーザー、プログラマ、 DBA、
インフラ屋、PM、上司、保守メンバー
– ライフサイクル（設計から保守）まで意識し
た
– システムの分け方と組合せ方のこと
IEEE-Std-1471-2000 Recommended Practice for Architectural Description
13
of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）

14. アーキテクチャとマネジメント
• PMBOKとは
立ち上げ 計画 遂行 コントロール 終結
統合 計画策定 計画実行 統合変更管理
スコープ 立ち上げ スコープ計画/定義 スコープ検証/変更管理
（目的と範囲）
時間（期間） アクティビティ定義/順序設 スケジュールコントロール
定/期間見積
スケジュール作成
コスト（予算） 資源管理 コストコントロール
コストの見積/予算化
品質
人的資源
品質計画
組織計画
計画 実行
品質保証
チーム育成
調整
品質管理
要員調達
コミュニケー コミュニケーション計画 情報配布 実行報告 完了手続き
ション
リスク リスク・マネジメント計画 リスクの監視・コントロー
リスク識別 ル
定性的/定量的リスク分析
調達 調達/引合計画 引合 契約完了
発注先選定
契約管理
14

15. アーキテクチャとマネジメント
• PMBOKは「計画と実行の差を把握する」
ための知識群（に過ぎない）
– 5つのプロセスグループと9つのナレッジエリ
ア
• プロジェクトマネジメントの本質は計画
と実行の差から課題を発見し、調整を行
うことで、プロジェクトを正しい状態に
導くこと
– 差の把握だけで終わっていたら意味がない
15

16. アーキテクチャと
マネジメントの関係
16
http://www.flickr.com/photos/concubine/1219492740/sizes/l/

17. アーキテクチャとマネジメントの関係
• アーキテクチャとマネジメントの関係
アーキテクチャ マネジメント
目的 プロジェクトの目的 プロジェクトを成功
を技術的に表現する に導く
手法 予測し、方向を設定 計画の策定し、計測
する する
成果 対象物の分け方と組 計画と実行の調整
み合わせ方
行動 事前的に決定 事後的に対応
17

18. アーキテクチャとマネジメントの関係
• アーキテクチャが「システムの分け方と
組み合わせ方」を設定するのであれば、
プロジェクトのWBSはアーキテクトが作
るべき
スコープ管理（WBS） 時間管理（スケジュール）
10 5
20
18

19. アーキテクチャとマネジメントの関係
• スコープ定義はマネジメントの基本だが、
その作成はPMだけでは行えない
マネジメントの主領域
実行 感想
シス
実行 テム
実行 シス
計画 要件
テム
アーキテクチャの主領域
19

20. アーキテクチャとマネジメントの関係
• アーキテクチャとマネジメントは、各品
質をつなぐために重要
マネジメントの主領域
利用時の
利用時の
プロセス 内部 外部 利用時の
品質
品質
品質 品質 品質 品質
アーキテクチャの主領域
20

21. アーキテクチャとマネジメントの関係
System/360
AS/400 DB2
(1964) システムアーキテクト
(1988)
UML（1997）
TCP/IP
（1982）Tuxedo
（1984） IoC(DI）
Ajax
Smalltalk
（1972） Web2.0
ソーシャル
Macintosh
インターネット
Xerox Star(1981)
ブーム（1995）
21
帰属: Bundesarchiv, B 145 Bild-F038812-0014 / Schaack, Lothar / CC-BY-SA

22. アーキテクチャとマネジメントの関係
アジャイルソフトウェア開発宣言
（2001年）
Adaptive Software Development
（2000年）
ウォーターフォール PMBOK（1987） FDD（1997年）
（1970） XP（1996年）
スクラム（1986年）
スパイラルモデル
（1988）
インクリメンタル/イテレーティブ
（1990）
22

23. アーキテクトと
PM
23
http://www.flickr.com/photos/gray_macbook/3505625290/

24. アーキテクトとPM
• ウォレン・ベニス曰く
“Managers do things right
but leaders do the right things”
マネージャーはものごとを正しく行い、
リーダーは正しいことをする。
24
『本物のリーダーとは何か』ウォレン・ベニス/バート・ナナス

25. アーキテクトとPM
• リーダーとマネージャー
リーダー マネージャー
改革する 管理する
発展させる 維持する
人間に注目 組織と構造に注目
信頼を呼び起こす 管理に頼る
「何を、なぜ」 「いつ、どのように」
未来を見すえる 数字を追う
現状に挑戦する 現状を受け入れる
正しいことを行う 事を正しく行う
25
『リーダーになる』ウォレン・ベニス

26. アーキテクトとPM
• プロジェクトの成功にはリーダーもマ
ネージャーも必要
– 立場としてのリーダーやマネージャーという
意味ではない
– 一人が兼ね備えることもあれば、分担するこ
ともある
• 自分の得意/不得意を理解して、帽子をか
ぶり直す
26

27. アーキテクトとPM
• リーダーにはアーキテクトの素養が強く
求められる
– アーキテクチャ設計そのものが向かうべき先
を示すことだから
– マネージャー的PMには、プロジェクトを成功
させることはできない（失敗させないことは
できたとしても）
27

28. アーキテクチャと
アジャイル
28
http://www.flickr.com/photos/mshades/294215049/

29. アーキテクチャとアジャイル
• アーキテクチャとマネジメントの両立を
考える上で、重要なトピックス
• アーキテクチャとアジャイルは仲が悪い
– アーキテクチャへの批判
• 事前設計の限界、変化への不適合
– アジャイルへの批判
• 全体性の欠如、部分の不整合
29

30. アーキテクチャとアジャイル
• では、アーキテクチャとアジャイルは両
立しないのか？
• もちろん、そんなことはない
– 原理主義者は、あらゆる事が敵に見えるだけ
30

31. アーキテクチャとアジャイル
• アーキテクチャは事前に全てを決定して
いる（＝変化を抱擁しない）のか？
– 個人的な感覚：アーキテクチャ設計は、リス
クの濃淡を分析し、不確定なことを分離する
ために重要
– ただ、コンサルのベストプラクティス的な
アーキテクチャには限界がある
• どこにも平均的なアーキテクチャは存在しない
• 象牙の塔から出てきたものは信用できない
31

32. アーキテクチャとアジャイル
• アジャイルとは何か
– 開発プロセス論としてはイテレーションとタ
イムボックス
– アジャイルは組織論と思った方がいい
• うまくいったソフトウェア開発チームは、こうい
う働き方をしていた
• マネージャーよりはリーダーを強く求めている
32

33. アーキテクチャとアジャイル
アジャイル型組織
型（パターン） イテレーションと
リスク/複雑化 タイムボックス
アーキテクチャ マネジメント
形（ベストプラクティス） 全体の計画
安定化/単純化 ガントチャート
ウォーターフォール
職能階層型組織
33

34. これからの世界
34
http://www.flickr.com/photos/huntz/29461961/

35. これからの世界
• Global CEO Study 2012 by IBM
– 世界中のCEOへのヒヤリングから作成した報
告書
– 企業は、サプライヤーやパートナーのネット
ワークを改善し最適化してきたが、デジタル、
ソーシャル、モバイル技術の急速な普及によ
り、顧客、社員、ビジネス・パートナーなど、
人々と企業とのかかわり方が変化している。
＝コネクテッド・エコノミー
– CEO Studyが、2004年に開始されて以来、
初めて「テクノロジー」が企業に重要な影響
を及ぼす外部要因の一位に
35

36. これからの世界
• Global CEO Study 2012 by IBM
36

37. これからの世界
• 企業内における3つのIT予算
– 業務システム（既存保守）
• 情報システム部門
– スタートアップ（新規事業）
• 企画部門
– ソーシャル（B2C）
• マーケティング部門 or 営業部門
• 既存保守は下がり続け、スタートアップ
とソーシャルが増える
37

38. これからの世界
• 仕様決定要素が社内から社外へ
– 要件なんて、どこにもない
• 社会基盤としてのITへ
– 技術そのものではなく、技術が社会生活にど
うな影響を与えているか
– 社会規範やガバナンスの遵守
38

39. これからの世界
• 「いかにソフトウェアを作るか」という
手法だけでは足らない
マネジメントの主領域 ココ
利用時の
利用時の
プロセス 内部 外部 利用時の
品質
品質
品質 品質 品質 品質
アーキテクチャの主領域
39

40. これからの世界
• おそらくデザイン論あたり
– HCD/エスノグラフィ/UX/ペルソナ
• 1980年代にやり尽くされている感が
– リアルタイム化
• ストックからフロー、イベント駆動、センサー
– マルチスクリーン
• PC、タブレット、モバイル、TV、サイネージ
40

41. 最後に
41
http://www.flickr.com/photos/behzad_noorifard/5452729134/

42. 最後に
• 「良いシステム」を作るための視座
– テクノロジーだけでも、マネジメントだけで
も、アーキテクチャだけでも、デザインだけ
でもない。それら全てを包含する
• 学び続けることで、僕らは前に進むこと
ができる
– たとえばDevLOVEを通じて
42

43. DevLOVE2012
どうしたら良いシステムが作れるのか
あなたが進むべき道を決めるための
アーキテクチャとマネジメントの話
#devlove2012a
グロースエクスパートナーズ株式会社
執行役員/ビジネスソリューション事業本部 本部長
日本Javaユーザーグループ会長
鈴木雄介