Your SlideShare is downloading. ×
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423

22,131

Published on

2011年4月23日の「DevLOVE 今、未来に繋がるために帆を立てるとき」での講演内容です。 …

2011年4月23日の「DevLOVE 今、未来に繋がるために帆を立てるとき」での講演内容です。

http://kokucheese.com/event/index/9778/

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

No Downloads
Views
Total Views
22,131
On Slideshare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
114
Comments
0
Likes
32
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 再演 #develove0423なぜソフトウェゕゕーキテクトが必要なのか~未知なるソフトウェゕに形を与えよ~ グロースエクスパートナーズ株式会社 事業推進本部 本部長 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 ソフトウェア製品の品質 第1部 品質モデル
  • 8. ソフトウェゕとは何か 特徴 例利用時の品質 ・利用状況によって評価が異な ・ユーザーAさんと る ユーザーBさんで評価 が異なる外部品質 ・システムの振る舞い ・テストケース ・誰がテストしても同じ結果 ・外部仕様 ・一般的な仕様策定の対象内部品質 ・システムを構成している要素 ・クラス図 すべて(含ドキュメント) ・フレームワーク ・後に残り、評価が可能 ・ドキュメント ・エンジニゕがこだわるところプロセス品質 ・後に残らない ・コミュニケーション ・
  • 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 managersdo the things rightGood leadershipdoes 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とゕーキテクチャ 実行と調整 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い計画 アーキテクチャ設計 アーキテクチャが安定するなら マネジメントも安定する
  • 30. ソフトウェア開発のアーキテクチャは安定している?
  • 31. PMとゕーキテクチャ• ソフトウェゕ開発では、 – 同じゕーキテクチャを使い回すほうが正しく 見積もれる – しかし、現在のソフトウェゕ開発では新しい ゕーキテクチャによる効率化が、繰り返しの 効率化を上回ることがある• ゕーキテクチャを変えることが多い – 変えない場合はゕーキテクチャが安定するの でマネジメント主導(ウォーターフォール型 での効率化)でよい。パッケージ導入など
  • 32. PMとゕーキテクチャ• マネジメントとゕーキテクチャ設計 – 変化を許容するためには土台としてのゕーキ テクチャが重要 – ところがソフトウェゕ開発ではプロジェクト 毎にゕーキテクチャが変わってしまう – そこで、プロジェクト毎にゕーキテクチャを 設計し、それによってプロセスや構造の分割 と統合を行なう必要がある ソフトウェアアーキテクチャ設計の プロが必要になる
  • 33. PMとゕーキテクチャ• ソフトウェゕゕーキテクトはゕーキテク チャ設計を通じてマネジメントの土台を 提供する• ソフトウェゕゕーキテクトがいないと計 画を立てられない=何をマネジメントし ていいかが分からない – 「『正しさ』を見つけるための方法」を見つ ける – リーダーシップ的な素養
  • 34. PMとゕーキテクチャ• ゕーキテクトとマネジメントは職能が違 う – マネージャーは「物事を正しくする」 • 目標と目的、 どうやって?いつ?、組織と構造、 リスク回避 … • 現実、複雑さへの対応、成功、教育 – リーダーシップは「正しい事をする」 • ビジョン、何を?なぜ?、チャレンジ、゗ノベー ション、リスクは機会… • 変革、未来、変化、進歩、現状への不満 アーキテクトは父、マネージャーは母
  • 35. PMとゕーキテクチャ• 重要なのは「ユーザーとビルダーの関心 事をリンクさせる」枠組みの策定 – これはまさにプロジェクトの”ゕーキテク チャ”と呼べる• ゕーキテクトがプロジェクトのあり方す ら決めていくのではないか – 少なくともゕーキテクト的発想が重要 – プロジェクトゕーキテクトという職種が生ま れる?(もう生まれている?)
  • 36. ユーザーとアーキテクト http://www.flickr.com/photos/pgoyette/2819175465/
  • 37. ユーザーとゕーキテクト• ユーザーとビルダーの間には越えがたい 壁がある – ゕーキテクチャがビューポ゗ントを基本にし ているとはいえ、ユーザーのビューポ゗ント を取り込むのは難しい 越えられない壁 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い
  • 38. ユーザーとゕーキテクト• DDD – 使うコトと作るコトをつなぐ手法の1つ – ドメ゗ンを通じて、ユーザーとビルダーが会 話をしていく – どうやってドメ゗ンをモデリングするのか? DDD 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い
  • 39. ユーザーとゕーキテクト• ドメ゗ンエキスパートを巻き込む – 暇なドメ゗ンエキスパートに注意 – 良い(より難しく、より重要な)シナリオを 探す。具体的な状況を聞き出す。「なぜ」を 繰り返す – ビジネス戦略を理解し、コゕドメ゗ンを蒸留 させる – “確立された形式”を利用するが、そこで表現 されない固有なものが問題の中核 – コミュニケーションスキルを磨く • モデルで会話する、フゔシリテーションスキル
  • 40. ユーザーとゕーキテクト• Ericの提唱する渦巻きモデル
  • 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. 再演 #develove0423なぜソフトウェゕゕーキテクトが必要なのか~未知なるソフトウェゕに形を与えよ~ グロースエクスパートナーズ株式会社 事業推進本部 本部長 JJUG/JSUG 鈴木雄介

×