ソフトウェアマネジメント改善 Office Project Server 2007 導入アプローチ

Transcript

1. ソフトウェアマネジメント改善 Office Project Server 2007 導入アプローチ Sony Digital Network Applications, Inc.(SDNA) Technology Track Engineering Improvement Group Process Improvement Team SEPG/SQA/PMO Manager 高橋裕之 *1: In the U.S., SEPG is a service mark of Carnegie Mellon University. SEPG は、カーネギーメロン大学のサービスマークです。 *2: 本文中には ™ マークは明記しておりません。
2. 会社概要 •ソニーデジタルネットワークアプリケーションズ株式会社 •Sony Digital Network Applications, Inc. （以降、「SDNA」 と略す） 商号 •2000年8月1日 設立 •東京都品川区東五反田2-21-28 本社所在地 •高松 和子 代表者 •ソフトウェア開発 事業内容 •450百万円 資本金 •ソニー株式会社 100％ 主要株主 •285名 (2008年4月1日現在） 社員数 2 © 2008 Sony Digital Network Applications, Inc.
3. SDNAの特徴 • ソフトウェア開発専門会社 – 弊社が開発するソフトウエアは、 PC系とCE系の二つに大別され ます。PC系では主にVAIOを対象 に各種のソフトウエアを開発 – 一方CE系では、ハンディカムやサ イバーショットなどのポータブル機 器から半導体まで幅広い分野の ソフトウエア開発を行っています 3 © 2008 Sony Digital Network Applications, Inc.
4. SDNAの特徴 • マトリックス型組織 – メンバーは専門分野別のチーム に所属しますが、業務はすべて プロジェクト制で運営し、新しい 業務が発生するとそれぞれのチ ームから必要に応じてメンバーが 集まり、新しいプロジェクトが形 成されます – PMBOK®ガイドで解説されている 「バランス・マトリクス型組織」に 近い組織です 4 © 2008 Sony Digital Network Applications, Inc.
5. SDNAの特徴 • 技術領域 – ソニーグループにおけるソフトウ エアのプロフェッショナル集団と して常に新しい技術に挑戦し、 成果をソニーの製品づくりに活 かすことを目標としています – そのためソフトウエアのコア技術 について高レベルの知識を持つ チームが、日常のプロジェクトに 対して積極的なサポートを行って います – また、ソフトウエア開発そのもの をより高品質に効率的に行うた めの専門機能についても、同様 にチームを組織化しています 5 © 2008 Sony Digital Network Applications, Inc.
6. SDNA の SEPG活動概略 6 © 2008 Sony Digital Network Applications, Inc.
7. SEPGの発足：FY2004 さまざまな現場… • SPI活動そのものの存在にすら気づいていない現場 • 押し付けられたプロセスパッケージを咀嚼せずに使う現場 • “用法・用量を間違えた”アジャイル！XP！な現場 • CMMやISOなど、プロセスモデルへの丌信感に冒された現場 • 専門職を無視した管理への過剰防御 エンジニア志向のSEPG を発足 • エンジニアの仕事を最大化することを目的とする • 組織プロセスのような一様なプロセス定義とは距離をとる • エンジニアの今の仕事を全ての始まりとする 7 © 2008 Sony Digital Network Applications, Inc.
8. 品質向上を狙う、Ｍｕｌｔｉfunction SEPG • SEPG Architecture 8 © 2008 Sony Digital Network Applications, Inc.
9. 品質向上を狙う、Ｍｕｌｔｉfunction SEPG SQA function • プロセスが遵守されているかを確認 • プロジェクトの実績を観察 • 第三者の立場。中立性を保つ。 • 現場だけで解決しない問題は経営層 にエスカレーション PMO function • プロセスとマネジメントが密接に結び ついた形で、PLをサポート・教育でき る体制を形成・維持 • 「上司が部下をサポートする」ことの限 界をカバーする • SDNAの仕事の進め方に沿った形で、 計画確認プロセスを実行 SEPG function • SPI 基盤の構築 • メトリクスの集計サポートと情報開示 • ソフトウェア開発／マネジメントプロセ スの形式化 • ベストプラクティスの収集と形式化、 展開 9 © 2008 Sony Digital Network Applications, Inc.
10. PAG • SEPG Architecture 10 © 2008 Sony Digital Network Applications, Inc.
11. PAG • PAG [Project Architecture Guideline] – 既存のプロセスモデルから派生させたものではなく、開発現場の要望を元に した、弊社独自のプロジェクト構築・運用・改善のガイドライン 11 © 2008 Sony Digital Network Applications, Inc.
12. プロジェクトの誯題：３つのキーワード 12 © 2008 Sony Digital Network Applications, Inc.
13. プロジェクトの誯題：３つのキーワード プロジェクト計画に本格的に取り組む前（FY06 頃）は、スコープのあいまいさや、プロジェクトの 丌確実性に対する取り組み丌足から数々の問 題に直面するプロジェクトが後を絶たなかった 当時の散在する誯題を大きくまとめると、つぎ の３つのキーワードが浮かんだ 13 © 2008 Sony Digital Network Applications, Inc.
14. プロジェクトの誯題：３つのキーワード 見切り発車 ざっくり たられば 14 © 2008 Sony Digital Network Applications, Inc.
15. プロジェクトの誯題：３つのキーワード 見切り発車 ざっくり たられば 15 © 2008 Sony Digital Network Applications, Inc.
16. 見切り発車 当時（FY06 頃）は、計画といえばパワーポイントなどで 書いた資料を元に口頭にてプロジェクトの「概略」を説 明すれば良い風潮があった • 「概略」では、プロジェクト・ステークホルダーに必要な情報は表しきれ ていない可能性が高い • そもそも、パワーポイントはプレゼンのツールであって、表現できる情 報量に限界がある 一方でプロジェクトの Go/No Go 判断を求められるマ ネジャーは、情報が尐ないので何を拠り所に判断すれば 良いのか実際のところわからない・・・ • 「今始めないと間に合わない！」というプレッシャーに押される形でプ ロジェクトが始まってしまっていた。これが「見切り発車」 • ビジネス戦略上“見切り発車”せざる得ない事はあると思う • 問題は、いつまでも「無計画」状態でプロジェクトを進めることにある 16 © 2008 Sony Digital Network Applications, Inc.
17. 見切り発車 • 無計画で承認されたプロジェクトは、（失敗にならないにしろ）数々 の問題に直面することが多かった – もっと正確に言えば「プロジェクトの成功」条件や「プロジェクトの終了」条件 があいまいな為に、何をもって成功とするのか分からない状態でプロジェクト が終わっていたとも言える – こう言ったプロジェクトほど、「終わった」と思ったしばらく後に問題が発生した • なにもしなければ、失敗するのは当たり前 • 成功確率をちょっとでも上げるには、プロジェクト計画が鍵となる プロジェクトの計画を立てないということは、 失敗プロジェクトの計画を立てているに等しい 17 © 2008 Sony Digital Network Applications, Inc.
18. プロジェクトの誯題：３つのキーワード 見切り発車 ざっくり たられば 18 © 2008 Sony Digital Network Applications, Inc.
19. ざっくり • スケジュールはプロジェクト計画のほんの一部に過ぎないが、ソフト ウェア業界に於いては未だ「スケジュール＝プロジェクト計画」と誤 解しているエンジニアは多いのではないだろうか？ – ガントチャートなどで書かれた“スケジュール表”のみを「プロジェクト計画」と呼 んでしまうケース（もちろん、無いよりあったほうがマシだが・・・） • こういったスケジュールだけのプロジェクトほど、期間算出の拠り所 である「工数」の見積もりに、根拠が見当たらないことが多い 8月 9月 10月 11月 12月 1月 2月 3月 SMILE システム 実現性確認・ベンダ選定フェーズ 8/8 開始 9/18 終了 要件開発フェーズ 8/8 開始 9/30 終了 仕様定義（基本）フェーズ 8/27 開始 9/30 終了 仕様定義（詳細）フェーズ 10/1 開始 10/31 終了 仕様レビューフェーズ 11/1 開始 11/30 終了 設計実装フェーズ 10/15 開始 1/31 終了 結合テストフェーズ 1/15 開始 2/15 終了 検収フェーズ 2/16 開始 3/15 終了 パイロット導入フェーズ 3/1 開始 3/31 終了 19 © 2008 Sony Digital Network Applications, Inc.
20. • 工数を「ざっくり」見積もっただけの状態でスケジュールを引いても、 妥当性が見当たらない • 工数に根拠を持たないスケジュールは、進捗状況を判断する材料 も持っていない – 「進捗会議」で報告にて「達成率は90％です」と言われても信憑性が薄い • しかし、プロジェクトの立ち位置を判断するための真のプロジェクト 計画もないことから、プロジェクトリーダーからの報告を信じることし か出来なくなってしまう。それで良いのか？ – 「気がつけばデスマーチプロジェクト」化の温床である よく見かける「マイルストーン・ゲート付きパーセントコンプリート法（MGP法）」 ざっくり 未着手 0％ 作業着手 25％ ドラフト版完成 50％ レビュー実施 75％ 完了 100％ 90％できてますっ！ これって、 リーダーの 主観じゃない？ 20 © 2008 Sony Digital Network Applications, Inc.
21. プロジェクトの誯題：３つのキーワード 見切り発車 ざっくり たられば 21 © 2008 Sony Digital Network Applications, Inc.
22. たられば • プロジェクト計画を書いてみたものの、プロジェクトの成功に必要な 「チェックポイント」が正しいタイミングで確認されていないために 「計画と現実のズレ」と「そのスピード」を理解出来ぬまま手を拱いて しまい、気がつけばデスマーチプロジェクト化していることもあった。 残作業 開始日 期日 現在 おとぎ話 現実 22 © 2008 Sony Digital Network Applications, Inc.
23. たられば • こうなってしまう原因は色々あるが、一つは、計画そのものが十分 にレビューされておらず、関係者からコミットされていない状態であ ることが挙げられる。 • このような状態のプロジェクトは、すぐに進捗報告が機能しなくなる – 毎週開かれる“定例”はただの問題報告会となり、だれもプロジェクト計画に 立ち返らないために、プロジェクトが項調か否か、判断がついていない状態 に陥る。 • どうしようも無い状況に陥ったとき、人は と、後悔することが多い。（これはリーダーに限らず、顧客も） • これは回避できないのだろうか？ もしもあのとき～して「たら」 もしもあのとき～してい「れば」 23 © 2008 Sony Digital Network Applications, Inc.
24. 対策 24 © 2008 Sony Digital Network Applications, Inc.
25. 対策 • プロジェクトとは“冒険”とも言える • よって、プロジェクト計画とは“万全の策を練ったもの”と同じ • 我々SEPG/PMOは、現場のプロジェクトリーダーを中心に、サポート やコンサルタントによって次の対策を講じた 『でも そもそも 冒険とは 達成を前提とし そのために 万全の策を練ったものをいうのであって――― その対策を 意識しないのは それはもう冒険ではなく 無謀というのですよ』 ～惣領冬実「チェーザレ 5―破壊の創造者」から～ 刺客に襲われたにも関わらず、お忍びでピサの街に出たがるチェーザレにアンジェロが言った苦言 25 © 2008 Sony Digital Network Applications, Inc.
26. 対策 26 © 2008 Sony Digital Network Applications, Inc.
27. 対策 27 © 2008 Sony Digital Network Applications, Inc.
28. 対策1）プロジェクト計画立案による、マネジメント力向上 今まで計画を立案したことの無い人は、いきなり計画に 着手できないかもしれない また、プロジェクト計画はプロジェクトの途中で変更・追 加されてゆくものであるが、最初に書き出す機会を逸し てしまう様では、計画への取り組みそのもののチャンス を失い兼ねない そこで、プロジェクト計画書のテンプレートを用意した。し かし杓子定規なテンプレートを定義しても、現場で拒否 感、やらされ感を招いては本末転倒である。プロジェクト マネジメントに本質的に必要であろう頄目に絞りこみ、 プロジェクト計画書テンプレートを作成した 28 © 2008 Sony Digital Network Applications, Inc.
29. 対策1）プロジェクト計画立案による、マネジメント力向上 No 計画範囲 目的と内容 1 スコープ 要求や成果物がProjectの中か外かを判断できるように、Projectが 発足した背景や、大前提となる顧客から提示された納品物/マイル ストン、その他Projectに誯せられた条件や成立するために仮定され ている条件、Projectにどんな難しさがあるかを整理する 2 ステークホルダー 分析 ヒアリングや承認の項番や時期を考えるために誮がどんな要求を出 すか分析する 3 プロセスの設計 Projectの進め方を明確にするために、どのような成果物を作りなが ら進めるか分析する 4 成果物の一覧 過去のデータと、サイズにもとづいた見積りをするために作成する成 果物の一覧を作成する 5 見積り 人員の適切な確保と以後の進捗管理ためにProjectのボリュームを サイズに基づいて見積る 6 フェーズ計画 どの時期に何を作るかがわかるようにProjectを時間と成果物で区 分する 7 誯題 誯題を正しく認識した上でProjectが進められるように、列挙しBGM のレビューが受けられるようにする。 8 リスク 事前に問題に対処するため、上記を計画することで見えてきた丌確 定要素を列挙し対策する 29 © 2008 Sony Digital Network Applications, Inc.
30. 対策1）プロジェクト計画立案による、マネジメント力向上 30 © 2008 Sony Digital Network Applications, Inc.
31. 対策1）プロジェクト計画立案による、マネジメント力向上 31 © 2008 Sony Digital Network Applications, Inc.
32. 対策1）プロジェクト計画立案による、マネジメント力向上 32 © 2008 Sony Digital Network Applications, Inc.
33. 対策 33 © 2008 Sony Digital Network Applications, Inc.
34. 対策2）サイズ見積もりによる、見積もり精度向上 要求書 or 要求仕様書 工数見積もり コスト見積もり 単価 スケジュールへ 経験？カン？なんとなく？ 「見積もり」とは、コスト算出は元よりプロジェ クトがスタートした後は進捗管理の源となる。 •見積もりというと大抵「工数」になってしまうが、 果たしてその工数の根拠として 何を「元」にしているだろうか？ 34 © 2008 Sony Digital Network Applications, Inc.
35. 対策2）サイズ見積もりによる、見積もり精度向上 35 © 2008 Sony Digital Network Applications, Inc.
36. 対策2）サイズ見積もりによる、見積もり精度向上 要求書 or 要求仕様書 工数見積もり コスト見積もり 単価 スケジュールへ 経験？カン？なんとなく？ 36 © 2008 Sony Digital Network Applications, Inc.
37. 対策2）サイズ見積もりによる、見積もり精度向上 要求書 or 要求仕様書 サイズ見積もり 工数見積もり コスト見積もり 過去データ ＋ 成果物情報 生産性 単価 スケジュールへ 成果物毎に予想されるサイズ(量)を見積もる クラス設計 → クラスはxx個 ソースコード → xx行 予想したサイズと生産性実績から、必要な工数を算出する 要求仕様書の作成工数 ＝ (仕様xx個)×(仕様を1つ定義するのに必要な時間) 37 © 2008 Sony Digital Network Applications, Inc.
38. 対策2）サイズ見積もりによる、見積もり精度向上 38 © 2008 Sony Digital Network Applications, Inc.
39. 対策2）サイズ見積もりによる、見積もり精度向上 39 © 2008 Sony Digital Network Applications, Inc.
40. 対策 40 © 2008 Sony Digital Network Applications, Inc.
41. 対策3）PJ計画レビューによる無計画プロジェクトの抑止 • 上記のリスクは、弊社においても大いにあり得る • また、プロジェクトリーダー自身が計画やスケジュールを「書いた」と いう意識でいるのなら、魂が込もっていない可能性が高い – 「計画を書いた」・・・やらされ感、形骸化、杓子定規 – 「計画を立てた」・・・策を練る、能動的、冷静、プロフェッショナル ソフトウェアプロジェクトに対する最も深刻なリスクのいくつかは、次のように計 画に直接関連している 計画を作成しない 作成した計画に従わない プロジェクトの状況に変化があったにかかわらず、計画を見直さない （Steve McConnell , 1998） 41 © 2008 Sony Digital Network Applications, Inc.
42. 対策3）PJ計画レビューによる無計画プロジェクトの抑止 • 立案されたプロジェクト計画には、客観的レビューが重要である。 42 © 2008 Sony Digital Network Applications, Inc.
43. 対策3）PJ計画レビューによる無計画プロジェクトの抑止 何を重点的に計画されるべきかはプロジェクトの特徴、プロジェクトリーダー のスキルを基準に判断する必要があるが、段階ごとのチェックポイントを設け、 正しいタイミング/正しい基準でレビューを実施。いくつものチェックポイントを 確認することで、計画そのものの妥当性を高めることに繋がってゆく 「プロジェクトのスコープ認識は正しいか？」 「初期見積もりがサイズに基づいて行われているか？」 「顧客との要求仕様合意が行われているか？」 「フェーズ毎のレビュー計画は適切か？」 「要求、仕様のベースライン状況は？」 43 © 2008 Sony Digital Network Applications, Inc.
44. 対策3）PJ計画レビューによる無計画プロジェクトの抑止 上の図は、代表的なプロジェクト・ ライフサイクルを表している （ Iterative process ） •それぞれのフェーズでは、開発プロセスと 共にプロジェクトマネジメント・プロセスも反 復されていると考えることができる よってフェーズの切れ目では、以下 の追跡を行うことがとても重要 •予定と実績の把握 •遅れが発生した場合の原因分析 •次フェーズ以降の計画を補正する •顧客へ再見積もりを提案するか判断する 44 © 2008 Sony Digital Network Applications, Inc.
45. 対策3）PJ計画レビューによる無計画プロジェクトの抑止 • サイズ見積もりの予定と実績把握 ☑サイズが想定よりも大きく変わっていないか？ 45 © 2008 Sony Digital Network Applications, Inc.
46. 対策3）PJ計画レビューによる無計画プロジェクトの抑止 • 工数見積もりの予定と実績把握 ☑工数バッファを想定外に消化していないか？ 46 © 2008 Sony Digital Network Applications, Inc.
47. 対策3）PJ計画レビューによる無計画プロジェクトの抑止 この様な分析や対応策定は 基本的にプロジェクトリーダー 自身が実行している。 慣れないうちはPMOがサポー トしていたが、次第に自分自 身で実施できるようになって 行った。 47 © 2008 Sony Digital Network Applications, Inc.
48. ここまでのまとめ 48 © 2008 Sony Digital Network Applications, Inc.
49. ここまでのまとめ 49 © 2008 Sony Digital Network Applications, Inc.
50. ここまでのまとめ • 組織として、立案された計画 を基にプロジェクトの実現度、 リスクを判断する風土を作るこ とができ、さらにプロジェクト計 画書を有効活用する「習慣」を 作れたことが最大の効果であ る • 一方、いくつか新たな誯題も 発生した – 実績工数や実績サイズなどの、 実績データの収集が手作業であ ったためプロジェクトリーダーの負 荷を上げてしまった – サイズ見積もりからスケジュール へ落し込む作業が省かれぎみと なり、スケジュールの可視化が疎 かになった • これらの誯題については、高 度なIT化によりプロジェクトリー ダーの負荷低減・Excel からの 脱却を目指しEPMシステムを 構築。運用を開始した PMOが事前にアド バイスすることで、 ぐんとそのプロ ジェクトの成功率 向上に貢献できて いる 「計画ってどう 立てればいい の？」 「なぜ、このプ ロジェクトはこ んなに難しい の？」 「どのような計 画で望めば、 問題を回避で きるの？」 50 © 2008 Sony Digital Network Applications, Inc.
51. EPMシステムの構築導入
52. プロジェクトリーダーの意識調査（FY2007） • 2007年7月にプロジェクトリーダーにアンケートを実施した。 – 有効回答者数 40名 2% 2% 23% 30% 43% 現在参加しているプロジェクト規模は次のどれですか？ 中規模オフショア（６名～２０名） 小規模オフショア（１名～５名） 大規模（２１名から５０名。サブプロジェクト内包） 中規模（６名～２０名） 小規模（１名～５名） 52 © 2008 Sony Digital Network Applications, Inc.
53. プロジェクトリーダーの意識調査（FY2007） • 「プロジェクトがうまくいく」最大の要因があったら教えてください PMBOK 知識エリア・プロセス 個数 PJコミュニケーションマネジメント 13 PJ人的資源マネジメント 10 ＰＪ統合マネジメント 4 PJスコープマネジメント 4 PJリスクマネジメント 3 PJコストマネジメント 2 PJタイムマネジメント 2 PJ品質マネジメント PJ調達マネジメント 総計 38 次ページに詳細 53 © 2008 Sony Digital Network Applications, Inc.
54. プロジェクトリーダーの意識調査（FY2007） • 「プロジェクトがうまくいく」最大の要因があったら教えてください PMBOK 知識エリア・プロセス 個数 PJコミュニケーションマネジメント 13 PLがプロジェクトの状態を適切な粒度で把握していること 1 PLのコミュニケーション能力 1 コミュニケーション 1 プロジェクトに関する情報や狙いがメンバー全員で共有されていること。 1 プロジェクトメンバーおよびクライアントとゴールのイメージを納得して共有できる 1 プロジェクトメンバーどうしのコミュニケーションが良好であること 1 プロジェクト内のコミュニケーション 1 メンバーの意思導通 1 メンバーの共通目的意識 1 メンバー間で目標が共有され、各人がそれに向かって何をすれば良いか理解し実践すること。 1 モチベーション 1 志を関係者と共有する 1 明確な方向性提示 1 総計 13 54 © 2008 Sony Digital Network Applications, Inc.
55. プロジェクトリーダーの意識調査（FY2007） • 「プロジェクトがうまくいく」最大の要因があったら教えてください PMBOK 知識エリア・プロセス 個数 PJ人的資源マネジメント 10 メンバーの知識&経験&調査能力の総量 1 メンバー構成のバランスが取れている。 1 見積もりに基づきアサインされていること。 1 自律的に動ける優秀なメンバーであること 1 人 1 適時かつ適材適所であること。 1 役割分担 1 優秀なエンジニアをたくさん集めること 1 優秀なメンバーを集める 1 要求解、分析、提案、見積もり、進捗管理ができる人たち。 1 ＰＪ統合マネジメント 4 BGMとTLと顧客(=ステークホルダー)がスマートであること。 1 顧客のゴールが明確なこと。 1 段取り8分。PJ開始当初の成果がPJ全体の成果を決定付けるような気がします 1 要件管理 1 総計 14 55 © 2008 Sony Digital Network Applications, Inc.
56. プロジェクトリーダーの意識調査（FY2007） 人事評価が丌適切でモチベーションが低い 分散開発（委託やオフショア） ＰＬの体力や精神力が丌十分 プロジェクトのオーナー（経営者、ＢＧＭなど）のバックアップが丌十分 進捗が遅れた時の対処が丌十分 ＰＬのコミュニケーション丌足 メンバー相互のコミュニケーション丌足 プロジェクトチームの人選や編成が丌適切 目標や成功基準が丌透明 リスク要因の検討が丌十分 6 10 10 12 20 20 20 23 25 26 プロジェクトの成功の阻害要因として 直面したことのある誯題は以下のどれですか 56 © 2008 Sony Digital Network Applications, Inc.
57. プロジェクトリーダーの意識調査（FY2007） 参加メンバーに対する人事評価体系の見直し ＰＬの人選方法を見直す プロジェクトのオーナー（経営者、ＢＧＭなど）がどう支援すべきかを明確にする リスク管理などに関する支援組織をつくる プロジェクト発足初期に（経営者、ＢＧＭなどが）調査検討をもっと慎重に行う 参加メンバーの人選・編成方法を見直す 目標と成功基準の明確化を丹念に行う 5 10 11 16 18 19 24 指摘された誯題を解決するうえで必要な対策は? 57 © 2008 Sony Digital Network Applications, Inc.
58. プロジェクトリーダーの意識調査（FY2007） 特になし デバッグ プロセスフローダイアグラム（ＰＦＤ） 外注管理 要件開発 ＷＢＳ 構成管理 リスクマネジメント スケジュール作成 プロジェクト計画 テスト 進捗管理 データの計測と分析 要件管理 3 3 6 6 6 7 9 11 12 13 16 18 19 20 「ツール」や「システム化」でもっと効率が上がるのでは？と思っている マネジメント・アクティビティ 58 © 2008 Sony Digital Network Applications, Inc.
59. プロジェクトリーダーの意識調査（FY2007） • このアンケート結果をもとにディスカッションを実施 – 各ビジネスマネジャー推薦のエース級 PL6名と PMO によるディスカッション – アンケート結果の分析 • 結論『進捗が遅れたときの対処に問題がある』 – 問題の早期発見、増員の説得データ、リスクが読み切れていない、など •そこにはスケジュールの作成も含まれる •スケジュールを作るには、WBSが明確でなければならない •WBSを明確にするには、プロセスの明確化、成果物の明確化が前提 進捗管理をうまく行いたい •見積もりにはPJ計画が必要 •見積もりの精度をあげないと「人が欲しい」が説明できない 見積もりをしっかりやりたい •プロジェクト活動すべての源泉 プロジェクト計画を立てやすくしたい 59 © 2008 Sony Digital Network Applications, Inc.
60. EPMシステム • プロジェクトのステータスがリアルタイムに見え ないのは、経営のリスク このように現場プロ ジェクトリーダーからの 誯題が挙がる一方、 経営層からも組織全 体のPMポートフォリオ を鳥瞰できる仕組み切 望されていた • EPMシステムを１から作るにしろ、パッケージを 利用するにしろ、自分たちの“理想”や“確信”を 持っていないと良いシステムは作れない • まずは、PMプロセスの概略アーキテクチャをデ ザインし、そこから要求、要求仕様を開発する アプローチを実施 そこで我々PMOは、ま ず誯題解決の為にど のようなPMプロセスを 実行すべきか？の検 討から着手 60 © 2008 Sony Digital Network Applications, Inc.
61. 改善 • SEPG Architecture 61 © 2008 Sony Digital Network Applications, Inc.
62. • SEPG Architecture 2.0 改善 62 © 2008 Sony Digital Network Applications, Inc.
63. EPMシステム要求仕様書 63 © 2008 Sony Digital Network Applications, Inc.
64. • プロジェクトマネジメントツールの独自調査 – ベンダー製品の徹底比較 市販製品の調査 64 © 2008 Sony Digital Network Applications, Inc.
65. 何をチェックしていたか 自分たちの プロセスが実 施できるか？ EPMの導入が早められる のであれば、ツールに合わ せてプロセスを変えざる得 ないリスクは覚悟してい た。 意外と多い“PMBOK準拠” というナゾのセールストー ク •PMBOKを理解している方は想像 つくと思いますが、何をもって“準 拠”と言えるのか曖昧です 価格は？ 安いに越した事はなし。も ちろん、カスタマイズ費用 も考慮 •シェアが低いツールほど、情報が 尐なく専門エンジニアも丌足＝カ スタマイズ費用高 ROI が説明出来ないと、 何も始められない 品質は？ 既存のレガシーシステム や、将来の新システムとの 連携は必順 •即ち、移植性は大事 •使用性は大事だが、新しいテクノ ロジー（機能性）も大事 ちょっとでもカスタマイズす ると「サポート対象外」とい う製品もありました。 （信じられません） 65 © 2008 Sony Digital Network Applications, Inc.
66. 買うも作るも、品質が大事 • ISO/IEC9126（JIS X 0129-1）ソフトウェア品質特性 EPMパッケージ 66 © 2008 Sony Digital Network Applications, Inc.
67. 買うも作るも、品質が大事 • 製品価値を明確にした上で要求や品質に優先項位をつけ、 トレードオフし得る、製品価値を明確にすることが必要 0 1 2 3 4 5 6 7 8 9 合目的性 正確性 機能性標準適合性 相互運用性 セキュリティ 成熟性 障害許容性 回復性 理解性 習得性 運用性 時間効率性 資源効率性 解析性 変更性 安定性 試験性 環境適応性 設置性 置換性 移植性標準適合性 社会インフラ 一般的な組み込み機器 処理効率優先型機器（ゲームなど） 67 © 2008 Sony Digital Network Applications, Inc.
68. EPMシステム 最終選定 決め手 • マイクロソフト 殿は、我々が実現したいこと（要求仕様）の Feasibility Study に協力して頂 き、かつ的確に納得する回答を用意してくれたから • プロジェクトマネジメントに関する“言葉”が通じる安心感 • Fit Gap の回答も明確で、要件毎に複数の選択肢を提案して頂けた • Microsoft Office Project がもつ、歴史的優位性 • 弊社の社員はほとんどがソフトウェアエンジニアなので、Microsoft Office Project は昔から 慣れ親しんでいる（使いこなせているかどうかは別として・・・） • 全社的に Windows Server や SharePoint Server が導入済みであったためインフラ面での 親和性が高い 68 © 2008 Sony Digital Network Applications, Inc.
69. EPMシステムで解決したい重点誯題 • 解決したい重点誯題 • 見積もりから「スケジュール立案」がうまく出来ていなかった部 分を、Systemで簡単に • メンバーからの進捗報告も、Systemにより一元化 進捗管理の改善 • 見積もりとスケジュールが密接となることで、より根拠ある見積 もりへ 見積もりの改善 • プロジェクト計画データ（情報）の可視化が向上 • 見積もり、進捗共に予測・実績データの管理が簡単に プロジェクト計画立案の改善 69 © 2008 Sony Digital Network Applications, Inc.
70. PJ計画と進捗管理の誯題 立ち上げ プロセス群 終結 プロセス群 計画プロセス群 実行プロセス群 監視コントロール・ プロセス群 (Plan) (Do) (Check, Act) 70 © 2008 Sony Digital Network Applications, Inc.
71. PJ計画と進捗管理：現在 メンバーからの日報と 工数の関係が よくわからない 週単位で とりまとめ 今日やったことは報告したけど、 PJ全体の進捗がよくわからない。 このままでいいの？ プロジェクト 作業日報 BGM A さん PL プロジェクト 計画書 最初のころ計画は 立てたけど、更新は していない。 既存の工数 管理システム クリティカルな問題 は報告されていない けど・・・本当に項調 なのだろうか？ 71 © 2008 Sony Digital Network Applications, Inc.
72. PJ計画と進捗管理：これから 進捗を入力 Project データベース 入力フォーム 工数と実績 管理 エクスポート 進捗の入力作業が 容易になった メンバーの実績が データベースに累積 する BGM A さん PL 既存の工数 管理システム EVM分析ビュー 72 © 2008 Sony Digital Network Applications, Inc.
73. EPMシステム：グランドデザイン 73 © 2008 Sony Digital Network Applications, Inc.
74. • Software Management Improvement for LEAP （飛躍のためのソフトウェアマネジメント改善） EPMシステム：SMILE 74 © 2008 Sony Digital Network Applications, Inc.
75. EPMシステム：SMILE • サイズ見積もりの実現（アドイン） タスク名 _総計 _予定成果物数 成果物 400 400 タスク1 0 200 Aさん 0 200 タスク2 0 200 Bさん 0 100 Cさん 0 100 自 動 配 分 手動で入力 手入力で設定 自動的に積上げ ② 計算 ① 75 © 2008 Sony Digital Network Applications, Inc.
76. EPMシステム：SMILE • スコープ記述（プロジェクト ワークスペース） 76 © 2008 Sony Digital Network Applications, Inc.
78. 参考文献 i. The Art Of Project Management, Theory in Practice (O'Reilly) 『アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法』（Scott Berkun(著)、村上 雅章(翻訳)、オライリー・ジャパン、2006/9/7） ii. Steve McConnell, Software Project Survival Guide, Microsoft Corporation. スティーブ・マコネル『ソフトウェアプロジェクトサバイバルガイド』（新訳、（株）アルテア・ジ ャパン 訳、久手堅 憲之 監修、日経BP ソフトプレス、2005/8/1） iii. Project Management Institute, A Guide To The Project Management Body Of Knowledge (PMBOK® Guides), 3rd, 2004/11 PMI東京『プロジェクトマネジメント知識体系ガイド（PMBOK® ガイド第3版）』（PMI東京支 部翻訳、2004） iv. 『Software People - ソフトウェア開発を成功に導くための情報誌 (Vol.5)』（技術評論社、 2004/10）から、『 【特集1】コンサルタントが教える究極の仕事術 見積もりと進捗管理 入門（システムクリエイツ 清水吉男(著)）』 v. コミック「チェーザレ 5―破壊の創造者」（惣領 冬実 (著)、講談社 2008/7/23） vi. SEC BOOKS 組込みソフトウェア開発における品質向上の勧め[設計モデリング編]、（独 立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター編、 2006/6/20） 78 © 2008 Sony Digital Network Applications, Inc.