なぜソフトウェアアーキテクトが必要なのか - デブサミ2011

12,375 views

Published on

デブサミ2011での講演内容です。

Published in: Technology, Business
0 Comments
21 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
12,375
On SlideShare
0
From Embeds
0
Number of Embeds
2,691
Actions
Shares
0
Downloads
219
Comments
0
Likes
21
Embeds 0
No embeds

No notes for slide

なぜソフトウェアアーキテクトが必要なのか - デブサミ2011

  1. 1. 【18-C-1】なぜソフトウェアアーキテクトが必要なのか~未知なるソフトウェアに形を与えよ~ グロースエクスパートナーズ株式会社 事業推進本部 本部長 JJUG/JSUG 鈴木雄介
  2. 2. 自己紹介 1/2• グロースエクスパートナーズ株式会社 – 事業推進本部 本部長 – チーフITアーキテクト – ソリューションデリバリー事業 統括 http://www.gxp.co.jp
  3. 3. 自己紹介 2/2• 日本Javaユーザー会、日本Springユーザー会• Twitter: http://twitter.com/yusuke_arclamp• ブログ:http://www.arclamp.jp/• 「ソフトウェアアーキテクトが知るべき97のこと」監修• 「拡張する空間」共著(藤本壮介氏) オライリーブースで 売ってます
  4. 4. 宣伝• 「アーキテクチャとクラウド~情報によ る空間の変容」 – 建築家とソフトウェアアーキテクトの対談と してイベントを実施 – トゥギャっていただきました • http://togetter.com/li/102207 翔泳社ブースで 売ってます
  5. 5. 本講演の目的• アーキテクチャについて理解を深める• プロジェクトマネジメントにおけるアー キテクチャ設計の役割について理解する• ソフトウェアアーキテクトの役割につい て理解する• ユーザーとの協業について理解する
  6. 6. アジェンダ• アーキテクチャとは• マネジメントとアーキテクチャ• ユーザーとアーキテクト• まとめ
  7. 7. アーキテクチャとは • ソフトウェアとは何か • アーキテクチャとは何かhttp://www.flickr.com/photos/left-hand/3510633193/
  8. 8. ソフトウェアとは何か 影響を与える 利用時の 利用時の プロセス 内部 外部 利用時 品質 品質 行動 構造 振る舞い 依存するJISX0129-1 ソフトウェア製品の品質 第1部 品質モデル
  9. 9. ソフトウェアとは何か 特徴 例利用時の品質 ・利用状況によって評価が異な ・ユーザーAさんと る ユーザーBさんで評価 が異なる外部品質 ・システムの振る舞い ・テストケース ・誰がテストしても同じ結果 ・外部仕様 ・一般的な仕様策定の対象内部品質 ・システムを構成している要素 ・クラス図 すべて(含ドキュメント) ・フレームワーク ・後に残り、評価が可能 ・ドキュメント ・エンジニアがこだわるところプロセス品質 ・後に残らない ・コミュニケーション ・
  10. 10. ソフトウェアとは何か プログラマの視点 利用時の 利用時のコーデ インス クラス 品質 ユーザー 品質ィング タンス 行動 構造 振る舞い テスト ユニットテスト 自動テスト
  11. 11. アーキテクチャとは何か• システムの基盤であり、コンポーネント 群、コンポーネント間の相互関係と環境 との関係、設計と改良を管理する原則に より構成される IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems(アーキテクチャ記述の推奨プラクティス)
  12. 12. アーキテクチャとは何か• 基本は分割と統合 – 全体をどのように分けて、分けた部分をどの ように関係づけるか これ? 利用時の 利用時の 振るプロセス 構造 利用 品質 品質 舞い NO。それはストラクチャー
  13. 13. アーキテクチャとは何か IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems(アーキテクチャ記述の推奨プラクティス)
  14. 14. アーキテクチャとは何か ミッション システム制約(環境) ビュー モデルによって記述 利害関係者の 関心事 ビューポイント
  15. 15. アーキテクチャとは何か• アーキテクチャとは – システムのミッションに従い、システムのお かれた制約を前提としながら – システムに関わる複数の利害関係者の関心事 を整合させ、 • 経営者、オーナー、ユーザー、プログラマ、 DBA、 インフラ屋、PM、上司 – ライフサイクル(設計から保守)まで意識し た – システムの分け方と組合せ方のこと
  16. 16. アーキテクチャとは何か 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い事前的な“つなぎ方”がアーキテクチャ
  17. 17. マジメントとアーキテクチャ• マネジメントとは何か• PMとアーキテクチャ http://www.flickr.com/photos/drift-words/10434156/
  18. 18. Good managersdo the things rightGood leadershipdoes the right thing
  19. 19. マネジメントとは何か• マネージャーは「物事を正しくする」 – 目標と目的、 どうやって?いつ?、組織と構 造、リスク回避 … – 現実、複雑さへの対応、成功、教育• リーダーシップは「正しい事をする」 – ビジョン、何を?なぜ?、チャレンジ、イノ ベーション、リスクは機会… – 変革、未来、変化、進歩、現状への不満
  20. 20. マネジメントとは何か • PMBOK(A Guide to the Project Management Body of Knowledge) 立ち上げ 計画 実行 管理 終結統合 計画策定 計画実行 統合変更管理スコープ 立ち上げ スコープ計画/定義 スコープ検証/変更管理(目的と範囲)時間(期間) アクティビティ定義/順序設 スケジュールコントロール 定/期間見積 スケジュール作成コスト(予算) 資源管理 コストコントロール コストの見積/予算化品質人的資源 品質計画 組織計画 計画 実行 品質保証 チーム育成 品質管理 調整 要員調達コミュニケー コミュニケーション計画 情報配布 実行報告 完了手続きションリスク リスク・マネジメント計画 リスクの監視・コントロー リスク識別 ル 定性的/定量的リスク分析調達 調達/引合計画 引合 契約完了 発注先選定 契約管理
  21. 21. なぜPMは記事になるの? 「危機を救うヒーローだから」そもそも危機になるのがいけないんじゃ…http://www.flickr.com/photos/hobby_blog/2162966860/
  22. 22. 将来について分かっていることはただひとつ、 現在と同じではないだろう、という点だけだ。 「マネジメント 努め、責任、実践 Ⅰ」 P132 ピーター々ドラッカー正しい計画を立てることができるのか? http://www.flickr.com/photos/garyhayes/305475097/
  23. 23. 「運転で大切なのは〃車を正しい方向に進 めることじゃないのよ〄大切 なのは〃常 に注意を払って細かく左右に方向修正し ていくことなの〄」XPエクストリーム々プログラミング入門ケント々ベック http://www.flickr.com/photos/jontintinjordan/420270797/
  24. 24. PMとアーキテクチャ• アジャイルマネジメント – 「変化ヲ抱擁セヨ」• 基本手法 – イテレーティブなタイムボックス管理 • 完成していなくても棚卸しをして評価する – リスク主導 • 不確定な部分から手を付ける。プロトタイピング、 継続的統合 ズレを許容しながら、 正しさを探索するテクニック
  25. 25. PMとアーキテクチャ• アジャイルを機能させるには – 機能の分割と実施順がそれなりに正しい – 不確定な部分をうまく取り出す• 全体の計画は正しくなくても良いが、正 しさを見つけるプロセスはきちんと決め る必要がある
  26. 26. PMとアーキテクチャ• プロセスを決めるには要求まで遡る必要 があるプロセス 構造 作りたいもの 要求 この絵、どこかで見ましたよね
  27. 27. PMとアーキテクチャ• アジャイルはアーキテクチャ設計を内包 している – というか、すべてのマネジメントはアーキテ クチャ設計を前提とする 実行と調整 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い計画 アーキテクチャ設計
  28. 28. 未知への変化が大きければ大きいほど、飛躍のための土台を確かなものにしておく必要がある。 「マネジメント 努め、責任、実践 Ⅰ」 P132 ピーター々ドラッカーhttp://www.flickr.com/photos/chausinho/3104627075/
  29. 29. PMとアーキテクチャ • トヨタの新車開発マネジメント – 1人のチーフアーキテクト – 過去のデータを参考にしながら、3万点の部 品個別で見積もりとレビューを行なう • 前回と違うところはリスクをみて計画を行なう – これが可能なのは車の基本構造が変わってい ないからhttp://www.flickr.com/photos/toyotauk/5117989415/ http://www.flickr.com/photos/dok1/3909484847/
  30. 30. PMとアーキテクチャ 実行と調整 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い計画 アーキテクチャ設計 アーキテクチャが安定するなら マネジメントも安定する
  31. 31. ソフトウェア開発のアーキテクチャは安定している?
  32. 32. PMとアーキテクチャ• ソフトウェア開発では、 – 同じアーキテクチャを使い回すほうが正しく 見積もれる – しかし、現在のソフトウェア開発では新しい アーキテクチャによる効率化が、繰り返しの 効率化を上回ることがある• アーキテクチャを変えることが多い – 変えない場合はアーキテクチャが安定するの でマネジメント主導(ウォーターフォール型 での効率化)でよい。パッケージ導入など
  33. 33. PMとアーキテクチャ• マネジメントとアーキテクチャ設計 – 変化を許容するためには土台としてのアーキ テクチャが重要 – ところがソフトウェア開発ではプロジェクト 毎にアーキテクチャが変わってしまう – そこで、プロジェクト毎にアーキテクチャを 設計し、それによってプロセスや構造の分割 と統合を行なう必要がある ソフトウェアアーキテクチャ設計の プロが必要になる
  34. 34. PMとアーキテクチャ• ソフトウェアアーキテクトはアーキテク チャ設計を通じてマネジメントの土台を 提供する• ソフトウェアアーキテクトがいないと計 画を立てられない=何をマネジメントし ていいかが分からない – 「『正しさ』を見つけるための方法」を見つ ける – リーダーシップ的な素養
  35. 35. PMとアーキテクチャ• アーキテクトとマネジメントは職能が違 う – マネージャーは「物事を正しくする」 • 目標と目的、 どうやって?いつ?、組織と構造、 リスク回避 … • 現実、複雑さへの対応、成功、教育 – リーダーシップは「正しい事をする」 • ビジョン、何を?なぜ?、チャレンジ、イノベー ション、リスクは機会… • 変革、未来、変化、進歩、現状への不満 アーキテクトは父、マネージャーは母
  36. 36. ユーザーとアーキテクト http://www.flickr.com/photos/pgoyette/2819175465/
  37. 37. ユーザーとアーキテクト• ユーザーとビルダーの間には越えがたい 壁がある – アーキテクチャがビューポイントを基本にし ているとはいえ、ユーザーのビューポイント を取り込むのは難しい 越えられない壁 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い
  38. 38. ユーザーとアーキテクト• 外圧と内圧モデル 外圧 内圧 使うコト 作るコトビジョン/要求/要件 戦術/設計/実装
  39. 39. ユーザーとアーキテクト• 外圧と内圧モデル つなぐコト アーキテクチャ/戦略/バランス 外圧 内圧 使うコト 作るコトビジョン/要求/要件 戦術/設計/実装
  40. 40. ユーザーとアーキテクト• 使うコトと作るコトをつなぐ手法 – アーキテクチャ設計ではDDD • ドメインエキスパートとドメインモデル – マネジメントでは「スクラム」 • プロダクトオーナーとスクラムマスター スクラム 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い DDD
  41. 41. ユーザーとアーキテクト• つまりスクラムやDDDは「ユーザーとビ ルダーの関心事をリンクさせる」枠組み – これはまさにプロジェクトの”アーキテク チャ”と呼べる• アーキテクトがプロジェクトのあり方す ら決めていくのではないか – 少なくともアーキテクト的発想が重要 – プロジェクトアーキテクトという職種が生ま れる?(もう生まれている?)
  42. 42. まとめ• アーキテクチャは「分割と統合」• プロジェクトマネジメントにアーキテク チャ設計が含まれる – 変化をするためには安定した土台が必要 – ソフトウェア開発では毎回アーキテクチャ設 計をする必要がある• アーキテクトはアーキテクチャ設計を通 じてマネジメントの土台を提供する• アーキテクトは父、マネージャーは母
  43. 43. まとめ• ユーザーとアーキテクト – DDDやスクラムによってユーザーをビルダー をつないでいく – プロジェクトアーキテクト – アーキテクト的発想力(関係者の関心事をリ ンクさせる力)が重要になっていく
  44. 44. 宣伝• Qcon Tokyo 2011 – http://qcontokyo.com/ – Eric Evans氏(Domain-Driven Design著 者)と和智氏(和訳者)とのパネルディス カッションでモデレータをやります
  45. 45. 【18-C-1】なぜソフトウェアアーキテクトが必要なのか~未知なるソフトウェアに形を与えよ~ グロースエクスパートナーズ株式会社 事業推進本部 本部長 JJUG/JSUG 鈴木雄介

×