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.
アーキテクチャとマネジメントの関係 16http://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 23http://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.
最後に 41http://www.flickr.com/photos/behzad_noorifard/5452729134/

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

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