なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
•
40 likes•50,296 views
2011年4月23日の「DevLOVE 今、未来に繋がるために帆を立てるとき」での講演内容です。 http://kokucheese.com/event/index/9778/
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (8)
Similar to なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
Similar to なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 (20)
More from Yusuke Suzuki
More from Yusuke Suzuki (20)
Recently uploaded
Recently uploaded (11)
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
- 1. 再演 #devlove0423 なぜソフトウェゕゕーキテクトが 必要なのか ～未知なるソフトウェゕに形を与えよ～ グロースエクスパートナーズ株式会社 事業推進本部 本部長 JJUG/JSUG 鈴木雄介
- 2. 自己紹介 1/2 • グロースエクスパートナーズ株式会社 – 事業推進本部 本部長 – チーフITゕーキテクト – ソリューションデリバリー事業 統括 http://www.gxp.co.jp
- 3. 自己紹介 2/2 • 日本Javaユーザー会、日本Springユーザー会 • Twitter： http://twitter.com/yusuke_arclamp • ブログ：http://www.arclamp.jp/ • 「ソフトウェゕゕーキテクトが知るべき97のこと」監修 • 「拡張する空間」共著（藤本壮介氏） 第一きのこ
- 4. 本講演の目的 • ゕーキテクチャについて理解を深める • プロジェクトマネジメントにおけるゕー キテクチャ設計の役割について理解する • ソフトウェゕゕーキテクトの役割につい て理解する • ユーザーとの協業について理解する
- 5. ゕジェンダ • ゕーキテクチャとは • マネジメントとゕーキテクチャ • ユーザーとゕーキテクト • まとめ
- 6. アーキテクチャとは • ソフトウェアとは何か • アーキテクチャとは何か http://www.flickr.com/photos/left-hand/3510633193/
- 7. ソフトウェゕとは何か 影響を与える 利用時の 利用時の プロセス 内部 外部 利用時 品質 品質 行動 構造 振る舞い 依存する JISX0129-1 ソフトウェア製品の品質 第１部 品質モデル
- 8. ソフトウェゕとは何か 特徴 例 利用時の品質 ・利用状況によって評価が異な ・ユーザーＡさんと る ユーザーＢさんで評価 が異なる 外部品質 ・システムの振る舞い ・テストケース ・誰がテストしても同じ結果 ・外部仕様 ・一般的な仕様策定の対象 内部品質 ・システムを構成している要素 ・クラス図 すべて（含ドキュメント） ・フレームワーク ・後に残り、評価が可能 ・ドキュメント ・エンジニゕがこだわるところ プロセス品質 ・後に残らない ・コミュニケーション ・
- 9. ソフトウェゕとは何か プログラマの視点 利用時の 利用時の コーデ インス クラス 品質 ユーザー 品質 ィング タンス 行動 構造 振る舞い テスト ユニットテスト 自動テスト
- 10. ゕーキテクチャとは何か • システムの基盤であり、コンポーネント 群、コンポーネント間の相互関係と環境 との関係、設計と改良を管理する原則に より構成される IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems（ゕーキテクチャ記述の推奨プラクテゖス）
- 11. ゕーキテクチャとは何か • 基本は分割と統合 – 全体をどのように分けて、分けた部分をどの ように関係づけるか これ？ 利用時の 利用時の 振る プロセス 構造 利用 品質 品質 舞い NO。それはストラクチャー
- 12. ゕーキテクチャとは何か IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems（ゕーキテクチャ記述の推奨プラクテゖス）
- 13. ゕーキテクチャとは何か ミッション システム 制約（環境） ビュー モデルによって記述 利害関係者の 関心事 ビューポイント
- 14. ゕーキテクチャとは何か • ゕーキテクチャとは – システムのミッションに従い、システムのお かれた制約を前提としながら – システムに関わる複数の利害関係者の関心事 を整合させ、 • 経営者、オーナー、ユーザー、プログラマ、 DBA、 ンフラ屋、PM、上司 – ラフサクル（設計から保守）まで意識し た – システムの分け方と組合せ方のこと
- 15. ゕーキテクチャとは何か 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い 事前的な“つなぎ方”がアーキテクチャ
- 16. マジメントとアーキテクチャ • マネジメントとは何か • PMとアーキテクチャ http://www.flickr.com/photos/drift-words/10434156/
- 17. Good managers do the things right Good leadership does the right thing
- 18. マネジメントとは何か • マネージャーは「物事を正しくする」 – 目標と目的、 どうやって？いつ？、組織と構 造、リスク回避 … – 現実、複雑さへの対応、成功、教育 • リーダーシップは「正しい事をする」 – ビジョン、何を？なぜ？、チャレンジ、ノ ベーション、リスクは機会… – 変革、未来、変化、進歩、現状への不満
- 19. マネジメントとは何か • PMBOK（A Guide to the Project Management Body of Knowledge） 立ち上げ 計画 実行 管理 終結 統合 計画策定 計画実行 統合変更管理 スコープ 立ち上げ スコープ計画/定義 スコープ検証/変更管理 （目的と範囲） 時間（期間） ゕクテゖビテゖ定義/順序設 スケジュールコントロール 定/期間見積 スケジュール作成 コスト（予算） 資源管理 コストコントロール コストの見積/予算化 品質 人的資源 品質計画 組織計画 計画 実行 品質保証 チーム育成 品質管理 調整 要員調達 コミュニケー コミュニケーション計画 情報配布 実行報告 完了手続き ション リスク リスク・マネジメント計画 リスクの監視・コントロー リスク識別 ル 定性的/定量的リスク分析 調達 調達/引合計画 引合 契約完了 発注先選定 契約管理
- 20. なぜPMは記事になるの？ 「危機を救うヒーローだから」 そもそも危機になるのがいけないんじゃ… http://www.flickr.com/photos/hobby_blog/2162966860/
- 21. 将来について分かっていることはただひとつ、 現在と同じではないだろう、という点だけだ。 「マネジメント 努め、責任、実践 Ⅰ」 P132 ピーター々ドラッカー 正しい計画を立てることができるのか？ http://www.flickr.com/photos/garyhayes/305475097/
- 22. 「運転で大切なのは〃車を正しい方向に進 めることじゃないのよ〄大切 なのは〃常 に注意を払って細かく左右に方向修正し ていくことなの〄」 XPエクストリーム々プログラミング入門 ケント々ベック http://www.flickr.com/photos/jontintinjordan/420270797/
- 23. PMとゕーキテクチャ • ゕジャルマネジメント – 「変化ヲ抱擁セヨ」 • 基本手法 – テレーテゖブなタムボックス管理 • 完成していなくても棚卸しをして評価する – リスク主導 • 不確定な部分から手を付ける。プロトタピング、 継続的統合 ズレを許容しながら、 正しさを探索するテクニック
- 24. PMとゕーキテクチャ • ゕジャルを機能させるには – 機能の分割と実施順がそれなりに正しい – 不確定な部分をうまく取り出す • 全体の計画は正しくなくても良いが、正 しさを見つけるプロセスはきちんと決め る必要がある
- 25. PMとゕーキテクチャ • プロセスを決めるには要求まで遡る必要 がある プロセス 構造 作りたいもの 要求 この絵、どこかで見ましたよね
- 26. PMとゕーキテクチャ • ゕジャルはゕーキテクチャ設計を内包 している – というか、すべてのマネジメントはゕーキテ クチャ設計を前提とする 実行と調整 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い 計画 アーキテクチャ設計
- 27. 未知への変化が大きければ大きいほど、 飛躍のための土台を確かなものにしておく 必要がある。 「マネジメント 努め、責任、実践 Ⅰ」 P132 ピーター々ドラッカー http://www.flickr.com/photos/chausinho/3104627075/
- 28. PMとゕーキテクチャ • トヨタの新車開発マネジメント – 1人のチーフゕーキテクト – 過去のデータを参考にしながら、3万点の部 品個別で見積もりとレビューを行なう • 前回と違うところはリスクをみて計画を行なう – これが可能なのは車の基本構造が変わってい ないから http://www.flickr.com/photos/toyotauk/5117989415/ http://www.flickr.com/photos/dok1/3909484847/
- 29. PMとゕーキテクチャ 実行と調整 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い 計画 アーキテクチャ設計 アーキテクチャが安定するなら マネジメントも安定する
- 31. PMとゕーキテクチャ • ソフトウェゕ開発では、 – 同じゕーキテクチャを使い回すほうが正しく 見積もれる – しかし、現在のソフトウェゕ開発では新しい ゕーキテクチャによる効率化が、繰り返しの 効率化を上回ることがある • ゕーキテクチャを変えることが多い – 変えない場合はゕーキテクチャが安定するの でマネジメント主導（ウォーターフォール型 での効率化）でよい。パッケージ導入など
- 32. PMとゕーキテクチャ • マネジメントとゕーキテクチャ設計 – 変化を許容するためには土台としてのゕーキ テクチャが重要 – ところがソフトウェゕ開発ではプロジェクト 毎にゕーキテクチャが変わってしまう – そこで、プロジェクト毎にゕーキテクチャを 設計し、それによってプロセスや構造の分割 と統合を行なう必要がある ソフトウェアアーキテクチャ設計の プロが必要になる
- 33. PMとゕーキテクチャ • ソフトウェゕゕーキテクトはゕーキテク チャ設計を通じてマネジメントの土台を 提供する • ソフトウェゕゕーキテクトがいないと計 画を立てられない＝何をマネジメントし ていいかが分からない – 「『正しさ』を見つけるための方法」を見つ ける – リーダーシップ的な素養
- 34. PMとゕーキテクチャ • ゕーキテクトとマネジメントは職能が違 う – マネージャーは「物事を正しくする」 • 目標と目的、 どうやって？いつ？、組織と構造、 リスク回避 … • 現実、複雑さへの対応、成功、教育 – リーダーシップは「正しい事をする」 • ビジョン、何を？なぜ？、チャレンジ、ノベー ション、リスクは機会… • 変革、未来、変化、進歩、現状への不満 アーキテクトは父、マネージャーは母
- 35. PMとゕーキテクチャ • 重要なのは「ユーザーとビルダーの関心 事をリンクさせる」枠組みの策定 – これはまさにプロジェクトの”ゕーキテク チャ”と呼べる • ゕーキテクトがプロジェクトのあり方す ら決めていくのではないか – 少なくともゕーキテクト的発想が重要 – プロジェクトゕーキテクトという職種が生ま れる？（もう生まれている？）
- 36. ユーザーとアーキテクト http://www.flickr.com/photos/pgoyette/2819175465/
- 37. ユーザーとゕーキテクト • ユーザーとビルダーの間には越えがたい 壁がある – ゕーキテクチャがビューポントを基本にし ているとはいえ、ユーザーのビューポント を取り込むのは難しい 越えられない壁 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い
- 38. ユーザーとゕーキテクト • DDD – 使うコトと作るコトをつなぐ手法の1つ – ドメンを通じて、ユーザーとビルダーが会 話をしていく – どうやってドメンをモデリングするのか？ DDD 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い
- 39. ユーザーとゕーキテクト • ドメンエキスパートを巻き込む – 暇なドメンエキスパートに注意 – 良い（より難しく、より重要な）シナリオを 探す。具体的な状況を聞き出す。「なぜ」を 繰り返す – ビジネス戦略を理解し、コゕドメンを蒸留 させる – “確立された形式”を利用するが、そこで表現 されない固有なものが問題の中核 – コミュニケーションスキルを磨く • モデルで会話する、フゔシリテーションスキル
- 41. まとめ • ゕーキテクチャは「分割と統合」 • プロジェクトマネジメントにゕーキテク チャ設計が含まれる – 変化をするためには安定した土台が必要 – ソフトウェゕ開発では毎回ゕーキテクチャ設 計をする必要がある • ゕーキテクトはゕーキテクチャ設計を通 じてマネジメントの土台を提供する • ゕーキテクトは父、マネージャーは母
- 42. まとめ • プロジェクトゕーキテクト • ゕーキテクト的発想力（関係者の関心事 をリンクさせる力）が重要になっていく • ユーザーとゕーキテクト – DDDのコゕはユーザーとのコミュニケーショ ン
- 43. Post 3.11 http://www.flickr.com/photos/pgoyette/2819175465/
- 44. Post 3.11 • 最近の周辺トピックス – BCP（事業継続性計画）、DR（災害時復旧） • 新規開発予算の削減 – 省電力 • DRを兼ねてDCの移設 • 営業時間が短くなる？ – クラウドへの興味 • （でも、思ったほどではない？）
- 45. Post 3.11 • 質に対する考え方の変化 – 専用線の復旧が一番遅れた • ンターネットや無線の方が品質が高い？ • 「質の高さ」が安定した社会ンフラを前提とし ていた – 完璧なBCP/DRはあり得ない • 完璧ではなく”最適”な対応を考える – これまでとは違う価値観の提示 • 慣性力に逆らう必要がある
- 46. Post 3.11 • ゕーキテクトの在り方 – ゕーキテクチャは全ての要素から客観的 – ゕーキテクトは全ての要素を客観視する • “神の視座”に立つことを前提とする – これまで以上にビジョンを明示する必要があ る – でも、そんなことは可能なの？
- 47. Post 3.11 • 可能なのか、ではなく、その覚悟が必要 – 自らの説明責任を果たす • であれば、デザンの中心は、システム でも、人（誰か）でもなく、”自らの想い” であることに自覚的でいたい • オレオレでしかない現実を受け入れつつ、ナニカ が別にあることを意識する • 不遜であることに、謙虚でいられるか
- 48. 「デザンとは色や形 ではなく、人の世界 観を拡げる仕事で しょう？」 by 西村佳哲
- 49. 再演 #devlove0423 なぜソフトウェゕゕーキテクトが 必要なのか ～未知なるソフトウェゕに形を与えよ～ グロースエクスパートナーズ株式会社 事業推進本部 本部長 JJUG/JSUG 鈴木雄介