札幌Javaカンファレンス2012 #sjc12

[C3] 顧客とPMとPGの話は、 なぜ噛み合わないのか

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

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

鈴木雄介

http://www.gxp.co.jp

自己紹介

• 鈴木雄介

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

• 執行役員

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

• 職業：ITアーキテクト

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

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

– @yusuke_arclamp

2

はじめに

• 次の案件には、どのフレームワークを採用しますか？

–（伝統の）Struts

–（標準の）JavaEE6

–（革新の）PlayFramework

–（てか、）なんでもいい

3

はじめに

• あなたは、どの立場にいますか？

–プロジェクトを任されたPM。これが赤字になれば会社がつぶれる

–プロジェクトの技術リーダー。スケーラビリティと開発生産性を両立させねばならない

–リリースした後の保守リーダー。今後、10年間メンテし続ける。自分だけがメンテできる状態では抜けられない

–顧客。早く！早く！早く！安く！安く！安く！でも、安全に。

4

はじめに

• では、各自の立場（PM、技術リーダー、保守リーダー、顧客）になって「次の案件には、どんなフレームワークを採用すべきか」を考えてみよう

–（伝統の）Struts

–（標準の）JavaEE6

–（革新の）PlayFramework

–（てか、）なんでもいい

5

はじめに

• おそらく立場によって答えは異なるでしょうが、次の案件では、どれか1つを選ばなくてはいけません

• 何を考え、どう判断すべきかを一緒に考えましょう

6

アジェンダ

• ソフトウェア開発とは

• プロジェクトマネジメントとは

• アーキテクチャとは

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

• まとめ

7

ソフトウェア開発とは

8

ソフトウェア開発とは

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

9

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

影響を与える

依存する

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

ソフトウェア開発とは

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

10

特徴 例

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

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

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

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

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

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

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

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

ソフトウェア開発とは

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

11

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

ソフトウェア開発とは

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

12

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

ソフトウェア開発とは

• では、どうやったら良い依存/影響関係をつくれるのか

13

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

http://www.flickr.com/photos/drift-words/10434156/

プロジェクトマネジメントとは

14

プロジェクトマネジメントとは

• PMBOK

– 5つのプロセスグループ

15

スコープ 定義

ｽｹｼﾞｭｰﾙ 作成

コスト 積算

PJ計画 策定

PJ計画 実施

進捗報告 変更管理

計画プロセス

遂行プロセス コントロールプロセス

終結

立ち上げ

ﾘｽｸ管理 計画

品質 計画

ｺﾐｭﾆｹｰｼｮﾝ 計画

調達 計画

プロジェクトマネジメントとは

• PMBOK

– 9つのナレッジエリア

• 統合管理

• スコープ管理

• 時間管理（スケジュール管理）

• コスト管理

• 品質管理

• 人的資源管理

• コミュニケーション管理

• リスク管理

• 調達管理

16

プロジェクトマネジメントとは

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

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

スコープ （目的と範囲）

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

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

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

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

コストコントロール

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

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

チーム育成

コミュニケーション

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

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

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

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

契約完了

• PMBOK

計画 実行 調整

17

プロジェクトマネジメントとは

• 計画立案（時間視点）

–スケジュールの作成

• 「全体」を「部分」に分割

• 「部分」を成果物とするタスクを定義する

• タスクの順番を整合させる

• タスクの工数を見積もる

10 5

20

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

プロジェクトマネジメントとは

• プロジェクトでの事故原因は2つ

–計画の問題

–実行の問題

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

• PMは「計画と実行の差」から「課題を予知/予測」し「調整」を行うことで、プロジェクトを正しい状態に導くことが必要

–ここがプロジェクトマネジメントの本質

19

20

アーキテクチャとは

http://www.flickr.com/photos/wscullin/3770015203/

アーキテクチャとは

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

21

アーキテクチャとは

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

ビュー

ミッション

システム 制約（環境）

モデルによって記述

22

23

アーキテクチャとは

http://www.flickr.com/photos/montanaraven/20917616/

アーキテクチャとは

• IEEE-Std-1471-200の定義

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

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

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

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

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

24

http://www.flickr.com/photos/chausinho/3104627075/

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

25

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

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

• アーキテクチャ設計とはシステムのミッションと制約を前提に利害関係者の関心事を整合させたシステムの分け方と組合せ方をデザインすること

26

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

• プロジェクトマネジメントとは？

• NO。それはスケジュール管理

–狭義にはYES

27

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

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

• アーキテクチャとは？

• NO。それは構造/構成（ストラクチャー）

–狭義にはYES

28

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

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

• むしろ、ここ！

• 立ち位置は違えど、両者とも各品質の関係を重視している

29

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

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

• プロジェクトマネジメントとは「問題の予測と対応」

–事後的な活動がメイン。計画段階はアーキテクトと協業

• アーキテクチャ設計とは「問題対応能力の確保」

–事前的な活動がメインで、事後的にはプロジェクトマネジメントへの技術的な支援をする

30

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

• PMとアーキテクトの結節点はWBS

–アーキテクト：何をどう作るか

– PM：どういうリソースで実現するか

31

10 5

20

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

アーキテクチャ設計

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

• 誰が、その役割を果たすべきか

–マネジメントは必ずしもPMだけのものではない

–アーキテクチャ設計は必ずしもアーキテクトだけのものではない

32

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

• マネジメントとリーダーシップ

– Do things right と Do the right thing

33

マネージャー リーダー

管理する 革新する

制度・機構に着目 人に着目

統制する 信頼する

how と whenを問う what と whyを問う

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

忠実な兵士 自分自身

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

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

• 自分の得意と不得意を認識する

–完璧な人などいない

–帽子をかぶり直す（＝演技はできる）

34

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

• 内圧と外圧のバランスを取り、張りを維持する

内圧 作るコト

戦術/設計/実装 ミッション

外圧 使うコト

ビジョン/要求/要件 制約

まとめ

36 http://www.flickr.com/photos/tanaka_juuyoh/4295156760/

まとめ

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

–相互の依存/影響関係がプロジェクトの成否に関わる

37

利用時の 品質

利用時の 品質

プロセス 品質

内部 品質

外部 品質

利用時の 品質

影響を与える

依存する

まとめ

• 良い影響/依存関係をつくる役割

–プロジェクトマネージャー

–アーキテクト

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

–相互補完的

–誰の中にもあるし、誰もが決定者

– WBSが結節点

–リーダーシップとマネジメント

–自分の得意と不得意を認識する

–内圧と外圧のバランスを取る 38

さいごに

39 http://www.flickr.com/photos/atomdocs/3275758118/

さいごに

• 次の案件には、どのフレームワークを採用しますか？

–（伝統の）Struts

–（標準の）JavaEE6

–（革新の）PlayFramework

–（てか、）なんでもいい

–場合による

40

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

選択することは簡単ではない 理由を説明する「責任」と、結果を受け入れる「覚悟」が必要