More Related Content
Similar to なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 (20)
More from Yusuke Suzuki (20)
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
- 1. 再演 #devlove0423
なぜソフトウェゕゕーキテクトが
必要なのか
~未知なるソフトウェゕに形を与えよ~
グロースエクスパートナーズ株式会社
事業推進本部 本部長
JJUG/JSUG
鈴木雄介
- 3. 自己紹介 2/2
• 日本Javaユーザー会、日本Springユーザー会
• Twitter: http://twitter.com/yusuke_arclamp
• ブログ:http://www.arclamp.jp/
• 「ソフトウェゕゕーキテクトが知るべき97のこと」監修
• 「拡張する空間」共著(藤本壮介氏)
第一きのこ
- 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(ゕーキテクチャ記述の推奨プラクテゖス)
- 12. ゕーキテクチャとは何か
IEEE-Std-1471-2000 Recommended Practice for Architectural Description
of Software-Intensive Systems(ゕーキテクチャ記述の推奨プラクテゖス)
- 13. ゕーキテクチャとは何か
ミッション
システム
制約(環境)
ビュー
モデルによって記述
利害関係者の
関心事 ビューポイント
- 14. ゕーキテクチャとは何か
• ゕーキテクチャとは
– システムのミッションに従い、システムのお
かれた制約を前提としながら
– システムに関わる複数の利害関係者の関心事
を整合させ、
• 経営者、オーナー、ユーザー、プログラマ、 DBA、
ンフラ屋、PM、上司
– ラフサクル(設計から保守)まで意識し
た
– システムの分け方と組合せ方のこと
- 15. ゕーキテクチャとは何か
利用時の
利用時の
プロ 振る
構造 ユーザー
品質
品質
セス 舞い
事前的な“つなぎ方”がアーキテクチャ
- 18. マネジメントとは何か
• マネージャーは「物事を正しくする」
– 目標と目的、 どうやって?いつ?、組織と構
造、リスク回避 …
– 現実、複雑さへの対応、成功、教育
• リーダーシップは「正しい事をする」
– ビジョン、何を?なぜ?、チャレンジ、ノ
ベーション、リスクは機会…
– 変革、未来、変化、進歩、現状への不満
- 19. マネジメントとは何か
• PMBOK(A Guide to the Project Management Body of Knowledge)
立ち上げ 計画 実行 管理 終結
統合 計画策定 計画実行 統合変更管理
スコープ 立ち上げ スコープ計画/定義 スコープ検証/変更管理
(目的と範囲)
時間(期間) ゕクテゖビテゖ定義/順序設 スケジュールコントロール
定/期間見積
スケジュール作成
コスト(予算) 資源管理 コストコントロール
コストの見積/予算化
品質
人的資源
品質計画
組織計画
計画 実行
品質保証
チーム育成
品質管理
調整
要員調達
コミュニケー コミュニケーション計画 情報配布 実行報告 完了手続き
ション
リスク リスク・マネジメント計画 リスクの監視・コントロー
リスク識別 ル
定性的/定量的リスク分析
調達 調達/引合計画 引合 契約完了
発注先選定
契約管理
- 20. なぜPMは記事になるの?
「危機を救うヒーローだから」
そもそも危機になるのがいけないんじゃ…
http://www.flickr.com/photos/hobby_blog/2162966860/
- 23. PMとゕーキテクチャ
• ゕジャルマネジメント
– 「変化ヲ抱擁セヨ」
• 基本手法
– テレーテゖブなタムボックス管理
• 完成していなくても棚卸しをして評価する
– リスク主導
• 不確定な部分から手を付ける。プロトタピング、
継続的統合
ズレを許容しながら、
正しさを探索するテクニック
- 28. PMとゕーキテクチャ
• トヨタの新車開発マネジメント
– 1人のチーフゕーキテクト
– 過去のデータを参考にしながら、3万点の部
品個別で見積もりとレビューを行なう
• 前回と違うところはリスクをみて計画を行なう
– これが可能なのは車の基本構造が変わってい
ないから
http://www.flickr.com/photos/toyotauk/5117989415/ http://www.flickr.com/photos/dok1/3909484847/
- 29. PMとゕーキテクチャ
実行と調整
利用時の
利用時の
プロ 振る
構造 ユーザー
品質
品質
セス 舞い
計画 アーキテクチャ設計
アーキテクチャが安定するなら
マネジメントも安定する
- 31. PMとゕーキテクチャ
• ソフトウェゕ開発では、
– 同じゕーキテクチャを使い回すほうが正しく
見積もれる
– しかし、現在のソフトウェゕ開発では新しい
ゕーキテクチャによる効率化が、繰り返しの
効率化を上回ることがある
• ゕーキテクチャを変えることが多い
– 変えない場合はゕーキテクチャが安定するの
でマネジメント主導(ウォーターフォール型
での効率化)でよい。パッケージ導入など
- 32. PMとゕーキテクチャ
• マネジメントとゕーキテクチャ設計
– 変化を許容するためには土台としてのゕーキ
テクチャが重要
– ところがソフトウェゕ開発ではプロジェクト
毎にゕーキテクチャが変わってしまう
– そこで、プロジェクト毎にゕーキテクチャを
設計し、それによってプロセスや構造の分割
と統合を行なう必要がある
ソフトウェアアーキテクチャ設計の
プロが必要になる
- 34. PMとゕーキテクチャ
• ゕーキテクトとマネジメントは職能が違
う
– マネージャーは「物事を正しくする」
• 目標と目的、 どうやって?いつ?、組織と構造、
リスク回避 …
• 現実、複雑さへの対応、成功、教育
– リーダーシップは「正しい事をする」
• ビジョン、何を?なぜ?、チャレンジ、ノベー
ション、リスクは機会…
• 変革、未来、変化、進歩、現状への不満
アーキテクトは父、マネージャーは母
- 35. PMとゕーキテクチャ
• 重要なのは「ユーザーとビルダーの関心
事をリンクさせる」枠組みの策定
– これはまさにプロジェクトの”ゕーキテク
チャ”と呼べる
• ゕーキテクトがプロジェクトのあり方す
ら決めていくのではないか
– 少なくともゕーキテクト的発想が重要
– プロジェクトゕーキテクトという職種が生ま
れる?(もう生まれている?)
- 36. ユーザーとアーキテクト
http://www.flickr.com/photos/pgoyette/2819175465/
- 38. ユーザーとゕーキテクト
• DDD
– 使うコトと作るコトをつなぐ手法の1つ
– ドメンを通じて、ユーザーとビルダーが会
話をしていく
– どうやってドメンをモデリングするのか?
DDD
利用時の
利用時の
プロ 振る
構造 ユーザー
品質
品質
セス 舞い
- 39. ユーザーとゕーキテクト
• ドメンエキスパートを巻き込む
– 暇なドメンエキスパートに注意
– 良い(より難しく、より重要な)シナリオを
探す。具体的な状況を聞き出す。「なぜ」を
繰り返す
– ビジネス戦略を理解し、コゕドメンを蒸留
させる
– “確立された形式”を利用するが、そこで表現
されない固有なものが問題の中核
– コミュニケーションスキルを磨く
• モデルで会話する、フゔシリテーションスキル
- 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
• 可能なのか、ではなく、その覚悟が必要
– 自らの説明責任を果たす
• であれば、デザンの中心は、システム
でも、人(誰か)でもなく、”自らの想い”
であることに自覚的でいたい
• オレオレでしかない現実を受け入れつつ、ナニカ
が別にあることを意識する
• 不遜であることに、謙虚でいられるか
- 49. 再演 #devlove0423
なぜソフトウェゕゕーキテクトが
必要なのか
~未知なるソフトウェゕに形を与えよ~
グロースエクスパートナーズ株式会社
事業推進本部 本部長
JJUG/JSUG
鈴木雄介