なぜソフトウェゕゕーキテクトが必要なのか～未知なるソフトウェゕに形を与えよ～

グロースエクスパートナーズ株式会社

事業推進本部 本部長

JJUG/JSUG

鈴木雄介

再演 #devlove0423

自己紹介 1/2

• グロースエクスパートナーズ株式会社

– 事業推進本部 本部長

– チーフITゕーキテクト

– ソリューションデリバリー事業 統括

http://www.gxp.co.jp

自己紹介 2/2

• 日本Javaユーザー会、日本Springユーザー会

• Twitter： http://twitter.com/yusuke_arclamp

• ブログ：http://www.arclamp.jp/

• 「ソフトウェゕゕーキテクトが知るべき97のこと」監修

• 「拡張する空間」共著（藤本壮介氏）

第一きのこ

本講演の目的

• ゕーキテクチャについて理解を深める

• プロジェクトマネジメントにおけるゕーキテクチャ設計の役割について理解する

• ソフトウェゕゕーキテクトの役割について理解する

• ユーザーとの協業について理解する

ゕジェンダ

• ゕーキテクチャとは

• マネジメントとゕーキテクチャ

• ユーザーとゕーキテクト

• まとめ

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とゕーキテクチャ

• ゕーキテクトとマネジメントは職能が違う

–マネージャーは「物事を正しくする」

• 目標と目的、 どうやって？いつ？、組織と構造、リスク回避 …

• 現実、複雑さへの対応、成功、教育

–リーダーシップは「正しい事をする」

• ビジョン、何を？なぜ？、チャレンジ、ノベーション、リスクは機会…

• 変革、未来、変化、進歩、現状への不満

アーキテクトは父、マネージャーは母

PMとゕーキテクチャ

• 重要なのは「ユーザーとビルダーの関心事をリンクさせる」枠組みの策定

–これはまさにプロジェクトの”ゕーキテクチャ”と呼べる

• ゕーキテクトがプロジェクトのあり方すら決めていくのではないか

–少なくともゕーキテクト的発想が重要

–プロジェクトゕーキテクトという職種が生まれる？（もう生まれている？）

ユーザーとアーキテクト

http://www.flickr.com/photos/pgoyette/2819175465/

ユーザーとゕーキテクト

• ユーザーとビルダーの間には越えがたい壁がある

–ゕーキテクチャがビューポントを基本にしているとはいえ、ユーザーのビューポントを取り込むのは難しい

越えられない壁

利用時の品質

利用時の品質

プロセス

構造振る舞い

ユーザー

ユーザーとゕーキテクト

• DDD

–使うコトと作るコトをつなぐ手法の1つ

–ドメンを通じて、ユーザーとビルダーが会話をしていく

–どうやってドメンをモデリングするのか？

利用時の品質

利用時の品質

プロセス

構造振る舞い

ユーザー

DDD

ユーザーとゕーキテクト

• ドメンエキスパートを巻き込む

–暇なドメンエキスパートに注意

–良い（より難しく、より重要な）シナリオを探す。具体的な状況を聞き出す。「なぜ」を繰り返す

–ビジネス戦略を理解し、コゕドメンを蒸留させる

– “確立された形式”を利用するが、そこで表現されない固有なものが問題の中核

–コミュニケーションスキルを磨く

• モデルで会話する、フゔシリテーションスキル

ユーザーとゕーキテクト

• Ericの提唱する渦巻きモデル

まとめ

• ゕーキテクチャは「分割と統合」

• プロジェクトマネジメントにゕーキテクチャ設計が含まれる

–変化をするためには安定した土台が必要

–ソフトウェゕ開発では毎回ゕーキテクチャ設計をする必要がある

• ゕーキテクトはゕーキテクチャ設計を通じてマネジメントの土台を提供する

• ゕーキテクトは父、マネージャーは母

まとめ

• プロジェクトゕーキテクト

• ゕーキテクト的発想力（関係者の関心事をリンクさせる力）が重要になっていく

• ユーザーとゕーキテクト

– DDDのコゕはユーザーとのコミュニケーション

Post 3.11

http://www.flickr.com/photos/pgoyette/2819175465/

Post 3.11

• 最近の周辺トピックス

– BCP（事業継続性計画）、DR（災害時復旧）

• 新規開発予算の削減

–省電力

• DRを兼ねてDCの移設

• 営業時間が短くなる？

–クラウドへの興味

• （でも、思ったほどではない？）

Post 3.11

• 質に対する考え方の変化

–専用線の復旧が一番遅れた

• ンターネットや無線の方が品質が高い？

• 「質の高さ」が安定した社会ンフラを前提としていた

–完璧なBCP/DRはあり得ない

• 完璧ではなく”最適”な対応を考える

–これまでとは違う価値観の提示

• 慣性力に逆らう必要がある

Post 3.11

• ゕーキテクトの在り方

–ゕーキテクチャは全ての要素から客観的

–ゕーキテクトは全ての要素を客観視する

• “神の視座”に立つことを前提とする

–これまで以上にビジョンを明示する必要がある

–でも、そんなことは可能なの？

Post 3.11

• 可能なのか、ではなく、その覚悟が必要

–自らの説明責任を果たす

• であれば、デザンの中心は、システムでも、人（誰か）でもなく、”自らの想い”であることに自覚的でいたい

• オレオレでしかない現実を受け入れつつ、ナニカが別にあることを意識する

• 不遜であることに、謙虚でいられるか

「デザンとは色や形ではなく、人の世界観を拡げる仕事でしょう？」

by 西村佳哲

なぜソフトウェゕゕーキテクトが必要なのか～未知なるソフトウェゕに形を与えよ～

グロースエクスパートナーズ株式会社

事業推進本部 本部長

JJUG/JSUG

鈴木雄介

再演 #devlove0423