DevLOVE2012

どうしたら良いシステムが作れるのか あなたが進むべき道を決めるための アーキテクチャとマネジメントの話 #devlove2012a

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

執行役員/ビジネスソリューション事業本部 本部長

日本Javaユーザーグループ会長

鈴木雄介

http://www.gxp.co.jp

自己紹介

• 鈴木雄介

–グロースエクスパートナーズ（株）

• 執行役員

• ビジネスソリューション事業本部 本部長

• 職業：ITアーキテクト

–日本Javaユーザーグループ 会長

–日本Springユーザーグループ 幹事

– @yusuke_arclamp

2

agenda

• ソフトウェア開発とは

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

• アーキテクチャとマネジメントの関係

• アーキテクトとマネージャー

• アーキテクチャとアジャイル

• これからの世界

3

ソフトウェア開発とは

4 http://www.flickr.com/photos/riebart/4466482623/

ソフトウェア開発とは

• ソフトウェア品質モデル

5

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

影響を与える

依存する

JISX0129-1 ソフトウェア製品の品質 第１部 品質モデル

ソフトウェア開発とは

• ソフトウェア品質モデル

6

特徴 例

利用時の品質 ・利用状況によって評価が異なる

・ユーザーＡさんとユーザーＢさんで評価が異なる

外部品質 ・システムの振る舞い ・誰がテストしても同じ結果 ・一般的な仕様策定の対象

・テストケース ・外部仕様

内部品質 ・システムを構成している要素すべて（含ドキュメント） ・後に残り、評価が可能 ・エンジニアがこだわるところ

・クラス図 ・フレームワーク ・ドキュメント

プロセス品質 ・後に残らない行動 ・コミュニケーション ・作業手順

JISX0129-1 ソフトウェア製品の品質 第１部 品質モデル

ソフトウェア開発とは

• ソフトウェア開発は、これらのバランスを取ることが非常に大事になってくる

7

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

ソフトウェア開発とは

• ソフトウェア開発の失敗は、これらの依存/影響関係が壊れていること

8

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

ソフトウェア開発とは

• 良いシステムを作るためには、各品質同士に良い依存/影響関係をつくることが重要

–個別の品質よりもバランスが重要

9

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

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

10

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

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

11

• アーキテクチャとは

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

利害関係者の 関心事 ビューポイント

ビュー

ミッション

システム 制約（環境）

モデルによって記述

12

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

• アーキテクチャの定義

–システムのミッションに従い、システムのおかれた制約を前提としながら

–システムに関わる複数の利害関係者の関心事を整合させ、

• 経営者、オーナー、ユーザー、プログラマ、 DBA、インフラ屋、PM、上司、保守メンバー

–ライフサイクル（設計から保守）まで意識した

–システムの分け方と組合せ方のこと

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

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

立ち上げ 計画 遂行 コントロール 終結

統合 計画策定 計画実行 統合変更管理

スコープ （目的と範囲）

立ち上げ スコープ計画/定義 スコープ検証/変更管理

時間（期間） アクティビティ定義/順序設定/期間見積 スケジュール作成

スケジュールコントロール

コスト（予算） 資源管理 コストの見積/予算化

コストコントロール

品質 品質計画 品質保証 品質管理

人的資源 組織計画 要員調達

チーム育成

コミュニケーション

コミュニケーション計画 情報配布 実行報告 完了手続き

リスク リスク・マネジメント計画 リスク識別 定性的/定量的リスク分析

リスクの監視・コントロール

調達 調達/引合計画 引合 発注先選定 契約管理

契約完了

• PMBOKとは

計画 実行 調整

14

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

• PMBOKは「計画と実行の差を把握する」ための知識群（に過ぎない）

– 5つのプロセスグループと9つのナレッジエリア

• プロジェクトマネジメントの本質は計画と実行の差から課題を発見し、調整を行うことで、プロジェクトを正しい状態に導くこと

–差の把握だけで終わっていたら意味がない

15

アーキテクチャと マネジメントの関係

16 http://www.flickr.com/photos/concubine/1219492740/sizes/l/

アーキテクチャとマネジメントの関係

• アーキテクチャとマネジメントの関係

17

アーキテクチャ マネジメント

目的 プロジェクトの目的を技術的に表現する

プロジェクトを成功に導く

手法 予測し、方向を設定する

計画の策定し、計測する

成果 対象物の分け方と組み合わせ方

計画と実行の調整

行動 事前的に決定 事後的に対応

アーキテクチャとマネジメントの関係

• アーキテクチャが「システムの分け方と組み合わせ方」を設定するのであれば、プロジェクトのWBSはアーキテクトが作るべき

18

10 5

20

スコープ管理（WBS） 時間管理（スケジュール）

要件 システム

アーキテクチャとマネジメントの関係

• スコープ定義はマネジメントの基本だが、その作成はPMだけでは行えない

19

システム

実行 計画

感想

アーキテクチャの主領域

マネジメントの主領域

実行

実行

アーキテクチャとマネジメントの関係

• アーキテクチャとマネジメントは、各品質をつなぐために重要

20

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

アーキテクチャの主領域

マネジメントの主領域

アーキテクチャとマネジメントの関係

21 帰属: Bundesarchiv, B 145 Bild-F038812-0014 / Schaack, Lothar / CC-BY-SA

System/360 (1964)

Tuxedo （1984）

Web2.0

Ajax

IoC(DI）

Smalltalk （1972）

UML（1997） TCP/IP （1982）

インターネットブーム（1995）

Macintosh

Xerox Star(1981)

AS/400 DB2 (1988) システムアーキテクト

ソーシャル

アーキテクチャとマネジメントの関係

22

スクラム（1986年）

XP（1996年）

アジャイルソフトウェア開発宣言 （2001年）

ウォーターフォール （1970）

PMBOK（1987）

スパイラルモデル （1988）

インクリメンタル/イテレーティブ （1990）

FDD（1997年）

Adaptive Software Development （2000年）

アーキテクトと PM

23 http://www.flickr.com/photos/gray_macbook/3505625290/

アーキテクトとPM

• ウォレン・ベニス曰く

24

“Managers do things right but leaders do the right things”

『本物のリーダーとは何か』ウォレン・ベニス/バート・ナナス

マネージャーはものごとを正しく行い、 リーダーは正しいことをする。

アーキテクトとPM

• リーダーとマネージャー

25

リーダー マネージャー

改革する 管理する

発展させる 維持する

人間に注目 組織と構造に注目

信頼を呼び起こす 管理に頼る

「何を、なぜ」 「いつ、どのように」

未来を見すえる 数字を追う

現状に挑戦する 現状を受け入れる

正しいことを行う 事を正しく行う

『リーダーになる』ウォレン・ベニス

アーキテクトとPM

• プロジェクトの成功にはリーダーもマネージャーも必要

–立場としてのリーダーやマネージャーという意味ではない

–一人が兼ね備えることもあれば、分担することもある

• 自分の得意/不得意を理解して、帽子をかぶり直す

26

アーキテクトとPM

• リーダーにはアーキテクトの素養が強く求められる

–アーキテクチャ設計そのものが向かうべき先を示すことだから

–マネージャー的PMには、プロジェクトを成功させることはできない（失敗させないことはできたとしても）

27

アーキテクチャと アジャイル

28 http://www.flickr.com/photos/mshades/294215049/

アーキテクチャとアジャイル

• アーキテクチャとマネジメントの両立を考える上で、重要なトピックス

• アーキテクチャとアジャイルは仲が悪い

–アーキテクチャへの批判

• 事前設計の限界、変化への不適合

–アジャイルへの批判

• 全体性の欠如、部分の不整合

29

アーキテクチャとアジャイル

• では、アーキテクチャとアジャイルは両立しないのか？

• もちろん、そんなことはない

–原理主義者は、あらゆる事が敵に見えるだけ

30

アーキテクチャとアジャイル

• アーキテクチャは事前に全てを決定している（＝変化を抱擁しない）のか？

–個人的な感覚：アーキテクチャ設計は、リスクの濃淡を分析し、不確定なことを分離するために重要

–ただ、コンサルのベストプラクティス的なアーキテクチャには限界がある

• どこにも平均的なアーキテクチャは存在しない

• 象牙の塔から出てきたものは信用できない

31

アーキテクチャとアジャイル

• アジャイルとは何か

–開発プロセス論としてはイテレーションとタイムボックス

–アジャイルは組織論と思った方がいい

• うまくいったソフトウェア開発チームは、こういう働き方をしていた

• マネージャーよりはリーダーを強く求めている

32

アーキテクチャとアジャイル

33

アジャイル型組織

職能階層型組織

アーキテクチャ マネジメント

イテレーションと タイムボックス

型（パターン） リスク/複雑化

形（ベストプラクティス） 安定化/単純化

全体の計画 ガントチャート ウォーターフォール

これからの世界

34 http://www.flickr.com/photos/huntz/29461961/

これからの世界

• Global CEO Study 2012 by IBM –世界中のCEOへのヒヤリングから作成した報告書

–企業は、サプライヤーやパートナーのネットワークを改善し最適化してきたが、デジタル、ソーシャル、モバイル技術の急速な普及により、顧客、社員、ビジネス・パートナーなど、人々と企業とのかかわり方が変化している。＝コネクテッド・エコノミー

– CEO Studyが、2004年に開始されて以来、初めて「テクノロジー」が企業に重要な影響を及ぼす外部要因の一位に

35

これからの世界

• Global CEO Study 2012 by IBM

36

これからの世界

• 企業内における3つのIT予算

–業務システム（既存保守）

• 情報システム部門

–スタートアップ（新規事業）

• 企画部門

–ソーシャル（B2C）

• マーケティング部門 or 営業部門

• 既存保守は下がり続け、スタートアップとソーシャルが増える

37

これからの世界

• 仕様決定要素が社内から社外へ

–要件なんて、どこにもない

• 社会基盤としてのITへ

–技術そのものではなく、技術が社会生活にどうな影響を与えているか

–社会規範やガバナンスの遵守

38

これからの世界

• 「いかにソフトウェアを作るか」という手法だけでは足らない

39

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

アーキテクチャの主領域

マネジメントの主領域 ココ

これからの世界

• おそらくデザイン論あたり

– HCD/エスノグラフィ/UX/ペルソナ

• 1980年代にやり尽くされている感が

–リアルタイム化

• ストックからフロー、イベント駆動、センサー

–マルチスクリーン

• PC、タブレット、モバイル、TV、サイネージ

40

http://www.flickr.com/photos/behzad_noorifard/5452729134/

最後に

41

最後に

• 「良いシステム」を作るための視座

–テクノロジーだけでも、マネジメントだけでも、アーキテクチャだけでも、デザインだけでもない。それら全てを包含する

• 学び続けることで、僕らは前に進むことができる

–たとえばDevLOVEを通じて

42

DevLOVE2012

どうしたら良いシステムが作れるのか あなたが進むべき道を決めるための アーキテクチャとマネジメントの話 #devlove2012a

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

執行役員/ビジネスソリューション事業本部 本部長

日本Javaユーザーグループ会長

鈴木雄介