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