Successfully reported this slideshow.

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

63

Share

Loading in …3
×
1 of 43
1 of 43

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

63

Share

Download to read offline

2012年12月15日に開催されたDevLOVE2012での「どうしたら良いシステムが作れるのか - あなたが進むべき道を決めるための アーキテクチャとマネジメントの話」の資料です。

2012年12月15日に開催されたDevLOVE2012での「どうしたら良いシステムが作れるのか - あなたが進むべき道を決めるための アーキテクチャとマネジメントの話」の資料です。

More Related Content

Viewers also liked

More from Yusuke SUZUKI

Related Books

Free with a 14 day trial from Scribd

See all

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

  1. 1. DevLOVE2012 どうしたら良いシステムが作れるのか あなたが進むべき道を決めるための アーキテクチャとマネジメントの話 #devlove2012a グロースエクスパートナーズ株式会社 執行役員/ビジネスソリューション事業本部 本部長 日本Javaユーザーグループ会長 鈴木雄介
  2. 2. 自己紹介 • 鈴木雄介 – グロースエクスパートナーズ(株) • 執行役員 • ビジネスソリューション事業本部 本部長 • 職業:ITアーキテクト – 日本Javaユーザーグループ 会長 – 日本Springユーザーグループ 幹事 – @yusuke_arclamp 2 http://www.gxp.co.jp
  3. 3. agenda • ソフトウェア開発とは • アーキテクチャとマネジメント • アーキテクチャとマネジメントの関係 • アーキテクトとマネージャー • アーキテクチャとアジャイル • これからの世界 3
  4. 4. ソフトウェア開発とは 4 http://www.flickr.com/photos/riebart/4466482623/
  5. 5. ソフトウェア開発とは • ソフトウェア品質モデル 影響を与える 利用時の 利用時の プロセス 内部 外部 利用時の 品質 品質 品質 品質 品質 品質 依存する 5 JISX0129-1 ソフトウェア製品の品質 第1部 品質モデル
  6. 6. ソフトウェア開発とは • ソフトウェア品質モデル 特徴 例 利用時の品質 ・利用状況によって評価が異な ・ユーザーAさんと る ユーザーBさんで評価 が異なる 外部品質 ・システムの振る舞い ・テストケース ・誰がテストしても同じ結果 ・外部仕様 ・一般的な仕様策定の対象 内部品質 ・システムを構成している要素 ・クラス図 すべて(含ドキュメント) ・フレームワーク ・後に残り、評価が可能 ・ドキュメント ・エンジニアがこだわるところ プロセス品質 ・後に残らない行動 ・コミュニケーション ・作業手順 6 JISX0129-1 ソフトウェア製品の品質 第1部 品質モデル
  7. 7. ソフトウェア開発とは • ソフトウェア開発は、これらのバランス を取ることが非常に大事になってくる 利用時の 利用時の プロセス 内部 外部 利用時の 品質 品質 品質 品質 品質 品質 7
  8. 8. ソフトウェア開発とは • ソフトウェア開発の失敗は、これらの依 存/影響関係が壊れていること 利用時の 利用時の プロセス 内部 外部 利用時の 品質 品質 品質 品質 品質 品質 8
  9. 9. ソフトウェア開発とは • 良いシステムを作るためには、各品質同 士に良い依存/影響関係をつくることが重 要 利用時の 利用時の プロセス 内部 外部 利用時の 品質 品質 品質 品質 品質 品質 – 個別の品質よりもバランスが重要 9
  10. 10. アーキテクチャと マネジメント 10
  11. 11. アーキテクチャとマネジメント • アーキテクチャとは IEEE-Std-1471-2000 Recommended Practice for Architectural Description 11 of Software-Intensive Systems(アーキテクチャ記述の推奨プラクティス)
  12. 12. アーキテクチャとマネジメント ミッション システム 制約(環境) ビュー モデルによって記述 利害関係者の 関心事 ビューポイント 12
  13. 13. アーキテクチャとマネジメント • アーキテクチャの定義 – システムのミッションに従い、システムのお かれた制約を前提としながら – システムに関わる複数の利害関係者の関心事 を整合させ、 • 経営者、オーナー、ユーザー、プログラマ、 DBA、 インフラ屋、PM、上司、保守メンバー – ライフサイクル(設計から保守)まで意識し た – システムの分け方と組合せ方のこと IEEE-Std-1471-2000 Recommended Practice for Architectural Description 13 of Software-Intensive Systems(アーキテクチャ記述の推奨プラクティス)
  14. 14. アーキテクチャとマネジメント • PMBOKとは 立ち上げ 計画 遂行 コントロール 終結 統合 計画策定 計画実行 統合変更管理 スコープ 立ち上げ スコープ計画/定義 スコープ検証/変更管理 (目的と範囲) 時間(期間) アクティビティ定義/順序設 スケジュールコントロール 定/期間見積 スケジュール作成 コスト(予算) 資源管理 コストコントロール コストの見積/予算化 品質 人的資源 品質計画 組織計画 計画 実行 品質保証 チーム育成 調整 品質管理 要員調達 コミュニケー コミュニケーション計画 情報配布 実行報告 完了手続き ション リスク リスク・マネジメント計画 リスクの監視・コントロー リスク識別 ル 定性的/定量的リスク分析 調達 調達/引合計画 引合 契約完了 発注先選定 契約管理 14
  15. 15. アーキテクチャとマネジメント • PMBOKは「計画と実行の差を把握する」 ための知識群(に過ぎない) – 5つのプロセスグループと9つのナレッジエリ ア • プロジェクトマネジメントの本質は計画 と実行の差から課題を発見し、調整を行 うことで、プロジェクトを正しい状態に 導くこと – 差の把握だけで終わっていたら意味がない 15
  16. 16. アーキテクチャと マネジメントの関係 16 http://www.flickr.com/photos/concubine/1219492740/sizes/l/
  17. 17. アーキテクチャとマネジメントの関係 • アーキテクチャとマネジメントの関係 アーキテクチャ マネジメント 目的 プロジェクトの目的 プロジェクトを成功 を技術的に表現する に導く 手法 予測し、方向を設定 計画の策定し、計測 する する 成果 対象物の分け方と組 計画と実行の調整 み合わせ方 行動 事前的に決定 事後的に対応 17
  18. 18. アーキテクチャとマネジメントの関係 • アーキテクチャが「システムの分け方と 組み合わせ方」を設定するのであれば、 プロジェクトのWBSはアーキテクトが作 るべき スコープ管理(WBS) 時間管理(スケジュール) 10 5 20 18
  19. 19. アーキテクチャとマネジメントの関係 • スコープ定義はマネジメントの基本だが、 その作成はPMだけでは行えない マネジメントの主領域 実行 感想 シス 実行 テム 実行 シス 計画 要件 テム アーキテクチャの主領域 19
  20. 20. アーキテクチャとマネジメントの関係 • アーキテクチャとマネジメントは、各品 質をつなぐために重要 マネジメントの主領域 利用時の 利用時の プロセス 内部 外部 利用時の 品質 品質 品質 品質 品質 品質 アーキテクチャの主領域 20
  21. 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. 22. アーキテクチャとマネジメントの関係 アジャイルソフトウェア開発宣言 (2001年) Adaptive Software Development (2000年) ウォーターフォール PMBOK(1987) FDD(1997年) (1970) XP(1996年) スクラム(1986年) スパイラルモデル (1988) インクリメンタル/イテレーティブ (1990) 22
  23. 23. アーキテクトと PM 23 http://www.flickr.com/photos/gray_macbook/3505625290/
  24. 24. アーキテクトとPM • ウォレン・ベニス曰く “Managers do things right but leaders do the right things” マネージャーはものごとを正しく行い、 リーダーは正しいことをする。 24 『本物のリーダーとは何か』ウォレン・ベニス/バート・ナナス
  25. 25. アーキテクトとPM • リーダーとマネージャー リーダー マネージャー 改革する 管理する 発展させる 維持する 人間に注目 組織と構造に注目 信頼を呼び起こす 管理に頼る 「何を、なぜ」 「いつ、どのように」 未来を見すえる 数字を追う 現状に挑戦する 現状を受け入れる 正しいことを行う 事を正しく行う 25 『リーダーになる』ウォレン・ベニス
  26. 26. アーキテクトとPM • プロジェクトの成功にはリーダーもマ ネージャーも必要 – 立場としてのリーダーやマネージャーという 意味ではない – 一人が兼ね備えることもあれば、分担するこ ともある • 自分の得意/不得意を理解して、帽子をか ぶり直す 26
  27. 27. アーキテクトとPM • リーダーにはアーキテクトの素養が強く 求められる – アーキテクチャ設計そのものが向かうべき先 を示すことだから – マネージャー的PMには、プロジェクトを成功 させることはできない(失敗させないことは できたとしても) 27
  28. 28. アーキテクチャと アジャイル 28 http://www.flickr.com/photos/mshades/294215049/
  29. 29. アーキテクチャとアジャイル • アーキテクチャとマネジメントの両立を 考える上で、重要なトピックス • アーキテクチャとアジャイルは仲が悪い – アーキテクチャへの批判 • 事前設計の限界、変化への不適合 – アジャイルへの批判 • 全体性の欠如、部分の不整合 29
  30. 30. アーキテクチャとアジャイル • では、アーキテクチャとアジャイルは両 立しないのか? • もちろん、そんなことはない – 原理主義者は、あらゆる事が敵に見えるだけ 30
  31. 31. アーキテクチャとアジャイル • アーキテクチャは事前に全てを決定して いる(=変化を抱擁しない)のか? – 個人的な感覚:アーキテクチャ設計は、リス クの濃淡を分析し、不確定なことを分離する ために重要 – ただ、コンサルのベストプラクティス的な アーキテクチャには限界がある • どこにも平均的なアーキテクチャは存在しない • 象牙の塔から出てきたものは信用できない 31
  32. 32. アーキテクチャとアジャイル • アジャイルとは何か – 開発プロセス論としてはイテレーションとタ イムボックス – アジャイルは組織論と思った方がいい • うまくいったソフトウェア開発チームは、こうい う働き方をしていた • マネージャーよりはリーダーを強く求めている 32
  33. 33. アーキテクチャとアジャイル アジャイル型組織 型(パターン) イテレーションと リスク/複雑化 タイムボックス アーキテクチャ マネジメント 形(ベストプラクティス) 全体の計画 安定化/単純化 ガントチャート ウォーターフォール 職能階層型組織 33
  34. 34. これからの世界 34 http://www.flickr.com/photos/huntz/29461961/
  35. 35. これからの世界 • Global CEO Study 2012 by IBM – 世界中のCEOへのヒヤリングから作成した報 告書 – 企業は、サプライヤーやパートナーのネット ワークを改善し最適化してきたが、デジタル、 ソーシャル、モバイル技術の急速な普及によ り、顧客、社員、ビジネス・パートナーなど、 人々と企業とのかかわり方が変化している。 =コネクテッド・エコノミー – CEO Studyが、2004年に開始されて以来、 初めて「テクノロジー」が企業に重要な影響 を及ぼす外部要因の一位に 35
  36. 36. これからの世界 • Global CEO Study 2012 by IBM 36
  37. 37. これからの世界 • 企業内における3つのIT予算 – 業務システム(既存保守) • 情報システム部門 – スタートアップ(新規事業) • 企画部門 – ソーシャル(B2C) • マーケティング部門 or 営業部門 • 既存保守は下がり続け、スタートアップ とソーシャルが増える 37
  38. 38. これからの世界 • 仕様決定要素が社内から社外へ – 要件なんて、どこにもない • 社会基盤としてのITへ – 技術そのものではなく、技術が社会生活にど うな影響を与えているか – 社会規範やガバナンスの遵守 38
  39. 39. これからの世界 • 「いかにソフトウェアを作るか」という 手法だけでは足らない マネジメントの主領域 ココ 利用時の 利用時の プロセス 内部 外部 利用時の 品質 品質 品質 品質 品質 品質 アーキテクチャの主領域 39
  40. 40. これからの世界 • おそらくデザイン論あたり – HCD/エスノグラフィ/UX/ペルソナ • 1980年代にやり尽くされている感が – リアルタイム化 • ストックからフロー、イベント駆動、センサー – マルチスクリーン • PC、タブレット、モバイル、TV、サイネージ 40
  41. 41. 最後に 41 http://www.flickr.com/photos/behzad_noorifard/5452729134/
  42. 42. 最後に • 「良いシステム」を作るための視座 – テクノロジーだけでも、マネジメントだけで も、アーキテクチャだけでも、デザインだけ でもない。それら全てを包含する • 学び続けることで、僕らは前に進むこと ができる – たとえばDevLOVEを通じて 42
  43. 43. DevLOVE2012 どうしたら良いシステムが作れるのか あなたが進むべき道を決めるための アーキテクチャとマネジメントの話 #devlove2012a グロースエクスパートナーズ株式会社 執行役員/ビジネスソリューション事業本部 本部長 日本Javaユーザーグループ会長 鈴木雄介

×