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

1. 【18-C-1】
なぜソフトウェアアーキテクトが
必要なのか
～未知なるソフトウェアに形を与えよ～
グロースエクスパートナーズ株式会社
事業推進本部 本部長
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. 宣伝
• 「アーキテクチャとクラウド～情報によ
る空間の変容」
– 建築家とソフトウェアアーキテクトの対談と
してイベントを実施
– トゥギャっていただきました
• http://togetter.com/li/102207
翔泳社ブースで
売ってます

5. 本講演の目的
• アーキテクチャについて理解を深める
• プロジェクトマネジメントにおけるアー
キテクチャ設計の役割について理解する
• ソフトウェアアーキテクトの役割につい
て理解する
• ユーザーとの協業について理解する

6. アジェンダ
• アーキテクチャとは
• マネジメントとアーキテクチャ
• ユーザーとアーキテクト
• まとめ

7. アーキテクチャとは
• ソフトウェアとは何か
• アーキテクチャとは何か
http://www.flickr.com/photos/left-hand/3510633193/

8. ソフトウェアとは何か
影響を与える
利用時の
利用時の
プロセス 内部 外部 利用時
品質
品質
行動 構造 振る舞い
依存する
JISX0129-1 ソフトウェア製品の品質 第１部 品質モデル

9. ソフトウェアとは何か
特徴 例
利用時の品質 ・利用状況によって評価が異な ・ユーザーＡさんと
る ユーザーＢさんで評価
が異なる
外部品質 ・システムの振る舞い ・テストケース
・誰がテストしても同じ結果 ・外部仕様
・一般的な仕様策定の対象
内部品質 ・システムを構成している要素 ・クラス図
すべて（含ドキュメント） ・フレームワーク
・後に残り、評価が可能 ・ドキュメント
・エンジニアがこだわるところ
プロセス品質 ・後に残らない ・コミュニケーション
・

10. ソフトウェアとは何か
プログラマの視点
利用時の
利用時の
コーデ インス
クラス 品質
ユーザー
品質
ィング タンス
行動 構造 振る舞い
テスト
ユニットテスト
自動テスト

11. アーキテクチャとは何か
• システムの基盤であり、コンポーネント
群、コンポーネント間の相互関係と環境
との関係、設計と改良を管理する原則に
より構成される
IEEE-Std-1471-2000 Recommended Practice for Architectural Description
of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）

12. アーキテクチャとは何か
• 基本は分割と統合
– 全体をどのように分けて、分けた部分をどの
ように関係づけるか
これ？
利用時の
利用時の
振る
プロセス 構造 利用
品質
品質
舞い
NO。それはストラクチャー

13. アーキテクチャとは何か
IEEE-Std-1471-2000 Recommended Practice for Architectural Description
of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）

14. アーキテクチャとは何か
ミッション
システム
制約（環境）
ビュー
モデルによって記述
利害関係者の
関心事 ビューポイント

15. アーキテクチャとは何か
• アーキテクチャとは
– システムのミッションに従い、システムのお
かれた制約を前提としながら
– システムに関わる複数の利害関係者の関心事
を整合させ、
• 経営者、オーナー、ユーザー、プログラマ、 DBA、
インフラ屋、PM、上司
– ライフサイクル（設計から保守）まで意識し
た
– システムの分け方と組合せ方のこと

16. アーキテクチャとは何か
利用時の
利用時の
プロ 振る
構造 ユーザー
品質
品質
セス 舞い
事前的な“つなぎ方”がアーキテクチャ

17. マジメントとアーキテクチャ
• マネジメントとは何か
• PMとアーキテクチャ
http://www.flickr.com/photos/drift-words/10434156/

18. Good managers
do the things right
Good leadership
does the right thing

19. マネジメントとは何か
• マネージャーは「物事を正しくする」
– 目標と目的、 どうやって？いつ？、組織と構
造、リスク回避 …
– 現実、複雑さへの対応、成功、教育
• リーダーシップは「正しい事をする」
– ビジョン、何を？なぜ？、チャレンジ、イノ
ベーション、リスクは機会…
– 変革、未来、変化、進歩、現状への不満

20. マネジメントとは何か
• PMBOK（A Guide to the Project Management Body of Knowledge）
立ち上げ 計画 実行 管理 終結
統合 計画策定 計画実行 統合変更管理
スコープ 立ち上げ スコープ計画/定義 スコープ検証/変更管理
（目的と範囲）
時間（期間） アクティビティ定義/順序設 スケジュールコントロール
定/期間見積
スケジュール作成
コスト（予算） 資源管理 コストコントロール
コストの見積/予算化
品質
人的資源
品質計画
組織計画
計画 実行
品質保証
チーム育成
品質管理
調整
要員調達
コミュニケー コミュニケーション計画 情報配布 実行報告 完了手続き
ション
リスク リスク・マネジメント計画 リスクの監視・コントロー
リスク識別 ル
定性的/定量的リスク分析
調達 調達/引合計画 引合 契約完了
発注先選定
契約管理

21. なぜPMは記事になるの？
「危機を救うヒーローだから」
そもそも危機になるのがいけないんじゃ…
http://www.flickr.com/photos/hobby_blog/2162966860/

22. 将来について分かっていることはただひとつ、
現在と同じではないだろう、という点だけだ。
「マネジメント 努め、責任、実践 Ⅰ」 P132
ピーター々ドラッカー
正しい計画を立てることができるのか？
http://www.flickr.com/photos/garyhayes/305475097/

23. 「運転で大切なのは〃車を正しい方向に進
めることじゃないのよ〄大切 なのは〃常
に注意を払って細かく左右に方向修正し
ていくことなの〄」
XPエクストリーム々プログラミング入門
ケント々ベック
http://www.flickr.com/photos/jontintinjordan/420270797/

24. PMとアーキテクチャ
• アジャイルマネジメント
– 「変化ヲ抱擁セヨ」
• 基本手法
– イテレーティブなタイムボックス管理
• 完成していなくても棚卸しをして評価する
– リスク主導
• 不確定な部分から手を付ける。プロトタイピング、
継続的統合
ズレを許容しながら、
正しさを探索するテクニック

25. PMとアーキテクチャ
• アジャイルを機能させるには
– 機能の分割と実施順がそれなりに正しい
– 不確定な部分をうまく取り出す
• 全体の計画は正しくなくても良いが、正
しさを見つけるプロセスはきちんと決め
る必要がある

26. PMとアーキテクチャ
• プロセスを決めるには要求まで遡る必要
がある
プロセス 構造 作りたいもの 要求
この絵、どこかで見ましたよね

27. PMとアーキテクチャ
• アジャイルはアーキテクチャ設計を内包
している
– というか、すべてのマネジメントはアーキテ
クチャ設計を前提とする
実行と調整
利用時の
利用時の
プロ 振る
構造 ユーザー
品質
品質
セス 舞い
計画 アーキテクチャ設計

28. 未知への変化が大きければ大きいほど、
飛躍のための土台を確かなものにしておく
必要がある。
「マネジメント 努め、責任、実践 Ⅰ」 P132
ピーター々ドラッカー
http://www.flickr.com/photos/chausinho/3104627075/

29. PMとアーキテクチャ
• トヨタの新車開発マネジメント
– 1人のチーフアーキテクト
– 過去のデータを参考にしながら、3万点の部
品個別で見積もりとレビューを行なう
• 前回と違うところはリスクをみて計画を行なう
– これが可能なのは車の基本構造が変わってい
ないから
http://www.flickr.com/photos/toyotauk/5117989415/ http://www.flickr.com/photos/dok1/3909484847/

30. PMとアーキテクチャ
実行と調整
利用時の
利用時の
プロ 振る
構造 ユーザー
品質
品質
セス 舞い
計画 アーキテクチャ設計
アーキテクチャが安定するなら
マネジメントも安定する

31. ソフトウェア開発の
アーキテクチャは安定している？

32. PMとアーキテクチャ
• ソフトウェア開発では、
– 同じアーキテクチャを使い回すほうが正しく
見積もれる
– しかし、現在のソフトウェア開発では新しい
アーキテクチャによる効率化が、繰り返しの
効率化を上回ることがある
• アーキテクチャを変えることが多い
– 変えない場合はアーキテクチャが安定するの
でマネジメント主導（ウォーターフォール型
での効率化）でよい。パッケージ導入など

33. PMとアーキテクチャ
• マネジメントとアーキテクチャ設計
– 変化を許容するためには土台としてのアーキ
テクチャが重要
– ところがソフトウェア開発ではプロジェクト
毎にアーキテクチャが変わってしまう
– そこで、プロジェクト毎にアーキテクチャを
設計し、それによってプロセスや構造の分割
と統合を行なう必要がある
ソフトウェアアーキテクチャ設計の
プロが必要になる

34. PMとアーキテクチャ
• ソフトウェアアーキテクトはアーキテク
チャ設計を通じてマネジメントの土台を
提供する
• ソフトウェアアーキテクトがいないと計
画を立てられない＝何をマネジメントし
ていいかが分からない
– 「『正しさ』を見つけるための方法」を見つ
ける
– リーダーシップ的な素養

35. PMとアーキテクチャ
• アーキテクトとマネジメントは職能が違
う
– マネージャーは「物事を正しくする」
• 目標と目的、 どうやって？いつ？、組織と構造、
リスク回避 …
• 現実、複雑さへの対応、成功、教育
– リーダーシップは「正しい事をする」
• ビジョン、何を？なぜ？、チャレンジ、イノベー
ション、リスクは機会…
• 変革、未来、変化、進歩、現状への不満
アーキテクトは父、マネージャーは母

36. ユーザーとアーキテクト
http://www.flickr.com/photos/pgoyette/2819175465/

37. ユーザーとアーキテクト
• ユーザーとビルダーの間には越えがたい
壁がある
– アーキテクチャがビューポイントを基本にし
ているとはいえ、ユーザーのビューポイント
を取り込むのは難しい
越えられない壁
利用時の
利用時の
プロ 振る
構造 ユーザー
品質
品質
セス 舞い

38. ユーザーとアーキテクト
• 外圧と内圧モデル
外圧 内圧
使うコト 作るコト
ビジョン/要求/要件 戦術/設計/実装

39. ユーザーとアーキテクト
• 外圧と内圧モデル
つなぐコト
アーキテクチャ/戦略/バランス
外圧 内圧
使うコト 作るコト
ビジョン/要求/要件 戦術/設計/実装

40. ユーザーとアーキテクト
• 使うコトと作るコトをつなぐ手法
– アーキテクチャ設計ではDDD
• ドメインエキスパートとドメインモデル
– マネジメントでは「スクラム」
• プロダクトオーナーとスクラムマスター
スクラム
利用時の
利用時の
プロ 振る
構造 ユーザー
品質
品質
セス 舞い
DDD

41. ユーザーとアーキテクト
• つまりスクラムやDDDは「ユーザーとビ
ルダーの関心事をリンクさせる」枠組み
– これはまさにプロジェクトの”アーキテク
チャ”と呼べる
• アーキテクトがプロジェクトのあり方す
ら決めていくのではないか
– 少なくともアーキテクト的発想が重要
– プロジェクトアーキテクトという職種が生ま
れる？（もう生まれている？）

42. まとめ
• アーキテクチャは「分割と統合」
• プロジェクトマネジメントにアーキテク
チャ設計が含まれる
– 変化をするためには安定した土台が必要
– ソフトウェア開発では毎回アーキテクチャ設
計をする必要がある
• アーキテクトはアーキテクチャ設計を通
じてマネジメントの土台を提供する
• アーキテクトは父、マネージャーは母

43. まとめ
• ユーザーとアーキテクト
– DDDやスクラムによってユーザーをビルダー
をつないでいく
– プロジェクトアーキテクト
– アーキテクト的発想力（関係者の関心事をリ
ンクさせる力）が重要になっていく

44. 宣伝
• Qcon Tokyo 2011
– http://qcontokyo.com/
– Eric Evans氏（Domain-Driven Design著
者）と和智氏（和訳者）とのパネルディス
カッションでモデレータをやります

45. 【18-C-1】
なぜソフトウェアアーキテクトが
必要なのか
～未知なるソフトウェアに形を与えよ～
グロースエクスパートナーズ株式会社
事業推進本部 本部長
JJUG/JSUG
鈴木雄介