Devlove2012 どうしたら良いシステムが作れるのか

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ユーザーグループ会長鈴木雄介