Devlove2012 どうしたら良いシステムが作れるのか
•
63 likes•7,322 views
2012年12月15日に開催されたDevLOVE2012での「どうしたら良いシステムが作れるのか - あなたが進むべき道を決めるための アーキテクチャとマネジメントの話」の資料です。
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. アーキテクチャと マネジメントの関係 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ユーザーグループ会長 鈴木雄介