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

Slide 1

Slide 1 text

ソフトウェアマネジメント改善 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: 本文中には ™ マークは明記しておりません。

Slide 2

Slide 2 text

会社概要 •ソニーデジタルネットワークアプリケーションズ株式会社 •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.

Slide 3

Slide 3 text

Slide 4

Slide 4 text

SDNAの特徴 • マトリックス型組織 – メンバーは専門分野別のチームに所属しますが、業務はすべてプロジェクト制で運営し、新しい業務が発生するとそれぞれのチームから必要に応じてメンバーが集まり、新しいプロジェクトが形成されます – PMBOK®ガイドで解説されている「バランス・マトリクス型組織」に近い組織です 4 © 2008 Sony Digital Network Applications, Inc.

Slide 5

Slide 5 text

SDNAの特徴 • 技術領域 – ソニーグループにおけるソフトウエアのプロフェッショナル集団として常に新しい技術に挑戦し、成果をソニーの製品づくりに活かすことを目標としています – そのためソフトウエアのコア技術について高レベルの知識を持つチームが、日常のプロジェクトに対して積極的なサポートを行っています – また、ソフトウエア開発そのものをより高品質に効率的に行うための専門機能についても、同様にチームを組織化しています 5 © 2008 Sony Digital Network Applications, Inc.

Slide 6

Slide 6 text

Slide 7

Slide 7 text

SEPGの発足：FY2004 さまざまな現場… • SPI活動そのものの存在にすら気づいていない現場 • 押し付けられたプロセスパッケージを咀嚼せずに使う現場 • “用法・用量を間違えた”アジャイル！XP！な現場 • CMMやISOなど、プロセスモデルへの丌信感に冒された現場 • 専門職を無視した管理への過剰防御エンジニア志向のSEPG を発足 • エンジニアの仕事を最大化することを目的とする • 組織プロセスのような一様なプロセス定義とは距離をとる • エンジニアの今の仕事を全ての始まりとする 7 © 2008 Sony Digital Network Applications, Inc.

Slide 8

Slide 8 text

Slide 9

Slide 9 text

品質向上を狙う、Ｍｕｌｔｉfunction SEPG SQA function • プロセスが遵守されているかを確認 • プロジェクトの実績を観察 • 第三者の立場。中立性を保つ。 • 現場だけで解決しない問題は経営層にエスカレーション PMO function • プロセスとマネジメントが密接に結びついた形で、PLをサポート・教育できる体制を形成・維持 • 「上司が部下をサポートする」ことの限界をカバーする • SDNAの仕事の進め方に沿った形で、計画確認プロセスを実行 SEPG function • SPI 基盤の構築 • メトリクスの集計サポートと情報開示 • ソフトウェア開発／マネジメントプロセスの形式化 • ベストプラクティスの収集と形式化、展開 9 © 2008 Sony Digital Network Applications, Inc.

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

見切り発車当時（FY06 頃）は、計画といえばパワーポイントなどで書いた資料を元に口頭にてプロジェクトの「概略」を説明すれば良い風潮があった • 「概略」では、プロジェクト・ステークホルダーに必要な情報は表しきれていない可能性が高い • そもそも、パワーポイントはプレゼンのツールであって、表現できる情報量に限界がある一方でプロジェクトの Go/No Go 判断を求められるマネジャーは、情報が尐ないので何を拠り所に判断すれば良いのか実際のところわからない・・・ • 「今始めないと間に合わない！」というプレッシャーに押される形でプロジェクトが始まってしまっていた。これが「見切り発車」 • ビジネス戦略上“見切り発車”せざる得ない事はあると思う • 問題は、いつまでも「無計画」状態でプロジェクトを進めることにある 16 © 2008 Sony Digital Network Applications, Inc.

Slide 17

Slide 17 text

見切り発車 • 無計画で承認されたプロジェクトは、（失敗にならないにしろ）数々の問題に直面することが多かった – もっと正確に言えば「プロジェクトの成功」条件や「プロジェクトの終了」条件があいまいな為に、何をもって成功とするのか分からない状態でプロジェクトが終わっていたとも言える – こう言ったプロジェクトほど、「終わった」と思ったしばらく後に問題が発生した • なにもしなければ、失敗するのは当たり前 • 成功確率をちょっとでも上げるには、プロジェクト計画が鍵となるプロジェクトの計画を立てないということは、失敗プロジェクトの計画を立てているに等しい 17 © 2008 Sony Digital Network Applications, Inc.

Slide 18

Slide 18 text

Slide 19

Slide 19 text

ざっくり • スケジュールはプロジェクト計画のほんの一部に過ぎないが、ソフトウェア業界に於いては未だ「スケジュール＝プロジェクト計画」と誤解しているエンジニアは多いのではないだろうか？ – ガントチャートなどで書かれた“スケジュール表”のみを「プロジェクト計画」と呼んでしまうケース（もちろん、無いよりあったほうがマシだが・・・） • こういったスケジュールだけのプロジェクトほど、期間算出の拠り所である「工数」の見積もりに、根拠が見当たらないことが多い 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.

Slide 20

Slide 20 text

• 工数を「ざっくり」見積もっただけの状態でスケジュールを引いても、妥当性が見当たらない • 工数に根拠を持たないスケジュールは、進捗状況を判断する材料も持っていない – 「進捗会議」で報告にて「達成率は90％です」と言われても信憑性が薄い • しかし、プロジェクトの立ち位置を判断するための真のプロジェクト計画もないことから、プロジェクトリーダーからの報告を信じることしか出来なくなってしまう。それで良いのか？ – 「気がつけばデスマーチプロジェクト」化の温床であるよく見かける「マイルストーン・ゲート付きパーセントコンプリート法（MGP法）」ざっくり未着手 0％作業着手 25％ドラフト版完成 50％レビュー実施 75％完了 100％ 90％できてますっ！これって、リーダーの主観じゃない？ 20 © 2008 Sony Digital Network Applications, Inc.

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

たられば • こうなってしまう原因は色々あるが、一つは、計画そのものが十分にレビューされておらず、関係者からコミットされていない状態であることが挙げられる。 • このような状態のプロジェクトは、すぐに進捗報告が機能しなくなる – 毎週開かれる“定例”はただの問題報告会となり、だれもプロジェクト計画に立ち返らないために、プロジェクトが項調か否か、判断がついていない状態に陥る。 • どうしようも無い状況に陥ったとき、人はと、後悔することが多い。（これはリーダーに限らず、顧客も） • これは回避できないのだろうか？もしもあのとき～して「たら」もしもあのとき～してい「れば」 23 © 2008 Sony Digital Network Applications, Inc.

Slide 24

Slide 24 text

Slide 25

Slide 25 text

対策 • プロジェクトとは“冒険”とも言える • よって、プロジェクト計画とは“万全の策を練ったもの”と同じ • 我々SEPG/PMOは、現場のプロジェクトリーダーを中心に、サポートやコンサルタントによって次の対策を講じた『でもそもそも冒険とは達成を前提としそのために万全の策を練ったものをいうのであって――― その対策を意識しないのはそれはもう冒険ではなく無謀というのですよ』～惣領冬実「チェーザレ 5―破壊の創造者」から～刺客に襲われたにも関わらず、お忍びでピサの街に出たがるチェーザレにアンジェロが言った苦言 25 © 2008 Sony Digital Network Applications, Inc.

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

対策1）プロジェクト計画立案による、マネジメント力向上今まで計画を立案したことの無い人は、いきなり計画に着手できないかもしれないまた、プロジェクト計画はプロジェクトの途中で変更・追加されてゆくものであるが、最初に書き出す機会を逸してしまう様では、計画への取り組みそのもののチャンスを失い兼ねないそこで、プロジェクト計画書のテンプレートを用意した。しかし杓子定規なテンプレートを定義しても、現場で拒否感、やらされ感を招いては本末転倒である。プロジェクトマネジメントに本質的に必要であろう頄目に絞りこみ、プロジェクト計画書テンプレートを作成した 28 © 2008 Sony Digital Network Applications, Inc.

Slide 29

Slide 29 text

対策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.

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

対策2）サイズ見積もりによる、見積もり精度向上要求書 or 要求仕様書工数見積もりコスト見積もり単価スケジュールへ経験？カン？なんとなく？「見積もり」とは、コスト算出は元よりプロジェクトがスタートした後は進捗管理の源となる。 •見積もりというと大抵「工数」になってしまうが、果たしてその工数の根拠として何を「元」にしているだろうか？ 34 © 2008 Sony Digital Network Applications, Inc.

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

対策2）サイズ見積もりによる、見積もり精度向上要求書 or 要求仕様書サイズ見積もり工数見積もりコスト見積もり過去データ＋成果物情報生産性単価スケジュールへ成果物毎に予想されるサイズ(量)を見積もるクラス設計 → クラスはxx個ソースコード → xx行予想したサイズと生産性実績から、必要な工数を算出する要求仕様書の作成工数＝ (仕様xx個)×(仕様を1つ定義するのに必要な時間) 37 © 2008 Sony Digital Network Applications, Inc.

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

対策3）PJ計画レビューによる無計画プロジェクトの抑止 • 上記のリスクは、弊社においても大いにあり得る • また、プロジェクトリーダー自身が計画やスケジュールを「書いた」という意識でいるのなら、魂が込もっていない可能性が高い – 「計画を書いた」・・・やらされ感、形骸化、杓子定規 – 「計画を立てた」・・・策を練る、能動的、冷静、プロフェッショナルソフトウェアプロジェクトに対する最も深刻なリスクのいくつかは、次のように計画に直接関連している 計画を作成しない 作成した計画に従わない プロジェクトの状況に変化があったにかかわらず、計画を見直さない（Steve McConnell , 1998） 41 © 2008 Sony Digital Network Applications, Inc.

Slide 42

Slide 42 text

Slide 43

Slide 43 text

対策3）PJ計画レビューによる無計画プロジェクトの抑止何を重点的に計画されるべきかはプロジェクトの特徴、プロジェクトリーダーのスキルを基準に判断する必要があるが、段階ごとのチェックポイントを設け、正しいタイミング/正しい基準でレビューを実施。いくつものチェックポイントを確認することで、計画そのものの妥当性を高めることに繋がってゆく「プロジェクトのスコープ認識は正しいか？」「初期見積もりがサイズに基づいて行われているか？」「顧客との要求仕様合意が行われているか？」「フェーズ毎のレビュー計画は適切か？」「要求、仕様のベースライン状況は？」 43 © 2008 Sony Digital Network Applications, Inc.

Slide 44

Slide 44 text

対策3）PJ計画レビューによる無計画プロジェクトの抑止上の図は、代表的なプロジェクト・ライフサイクルを表している（ Iterative process ） •それぞれのフェーズでは、開発プロセスと共にプロジェクトマネジメント・プロセスも反復されていると考えることができるよってフェーズの切れ目では、以下の追跡を行うことがとても重要 •予定と実績の把握 •遅れが発生した場合の原因分析 •次フェーズ以降の計画を補正する •顧客へ再見積もりを提案するか判断する 44 © 2008 Sony Digital Network Applications, Inc.

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

ここまでのまとめ • 組織として、立案された計画を基にプロジェクトの実現度、リスクを判断する風土を作ることができ、さらにプロジェクト計画書を有効活用する「習慣」を作れたことが最大の効果である • 一方、いくつか新たな誯題も発生した – 実績工数や実績サイズなどの、実績データの収集が手作業であったためプロジェクトリーダーの負荷を上げてしまった – サイズ見積もりからスケジュールへ落し込む作業が省かれぎみとなり、スケジュールの可視化が疎かになった • これらの誯題については、高度なIT化によりプロジェクトリーダーの負荷低減・Excel からの脱却を目指しEPMシステムを構築。運用を開始した PMOが事前にアドバイスすることで、ぐんとそのプロジェクトの成功率向上に貢献できている「計画ってどう立てればいいの？」「なぜ、このプロジェクトはこんなに難しいの？」「どのような計画で望めば、問題を回避できるの？」 50 © 2008 Sony Digital Network Applications, Inc.

Slide 51

Slide 51 text

EPMシステムの構築導入

Slide 52

Slide 52 text

プロジェクトリーダーの意識調査（FY2007） • 2007年7月にプロジェクトリーダーにアンケートを実施した。 – 有効回答者数 40名 2% 2% 23% 30% 43% 現在参加しているプロジェクト規模は次のどれですか？中規模オフショア（６名～２０名）小規模オフショア（１名～５名）大規模（２１名から５０名。サブプロジェクト内包）中規模（６名～２０名）小規模（１名～５名） 52 © 2008 Sony Digital Network Applications, Inc.

Slide 53

Slide 53 text

プロジェクトリーダーの意識調査（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.

Slide 54

Slide 54 text

プロジェクトリーダーの意識調査（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.

Slide 55

Slide 55 text

プロジェクトリーダーの意識調査（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.

Slide 56

Slide 56 text

プロジェクトリーダーの意識調査（FY2007）人事評価が丌適切でモチベーションが低い分散開発（委託やオフショア）ＰＬの体力や精神力が丌十分プロジェクトのオーナー（経営者、ＢＧＭなど）のバックアップが丌十分進捗が遅れた時の対処が丌十分ＰＬのコミュニケーション丌足メンバー相互のコミュニケーション丌足プロジェクトチームの人選や編成が丌適切目標や成功基準が丌透明リスク要因の検討が丌十分 6 10 10 12 20 20 20 23 25 26 プロジェクトの成功の阻害要因として直面したことのある誯題は以下のどれですか 56 © 2008 Sony Digital Network Applications, Inc.

Slide 57

Slide 57 text

プロジェクトリーダーの意識調査（FY2007）参加メンバーに対する人事評価体系の見直しＰＬの人選方法を見直すプロジェクトのオーナー（経営者、ＢＧＭなど）がどう支援すべきかを明確にするリスク管理などに関する支援組織をつくるプロジェクト発足初期に（経営者、ＢＧＭなどが）調査検討をもっと慎重に行う参加メンバーの人選・編成方法を見直す目標と成功基準の明確化を丹念に行う 5 10 11 16 18 19 24 指摘された誯題を解決するうえで必要な対策は? 57 © 2008 Sony Digital Network Applications, Inc.

Slide 58

Slide 58 text

プロジェクトリーダーの意識調査（FY2007）特になしデバッグプロセスフローダイアグラム（ＰＦＤ）外注管理要件開発ＷＢＳ構成管理リスクマネジメントスケジュール作成プロジェクト計画テスト進捗管理データの計測と分析要件管理 3 3 6 6 6 7 9 11 12 13 16 18 19 20 「ツール」や「システム化」でもっと効率が上がるのでは？と思っているマネジメント・アクティビティ 58 © 2008 Sony Digital Network Applications, Inc.

Slide 59

Slide 59 text

プロジェクトリーダーの意識調査（FY2007） • このアンケート結果をもとにディスカッションを実施 – 各ビジネスマネジャー推薦のエース級 PL6名と PMO によるディスカッション – アンケート結果の分析 • 結論『進捗が遅れたときの対処に問題がある』 – 問題の早期発見、増員の説得データ、リスクが読み切れていない、など •そこにはスケジュールの作成も含まれる •スケジュールを作るには、WBSが明確でなければならない •WBSを明確にするには、プロセスの明確化、成果物の明確化が前提進捗管理をうまく行いたい •見積もりにはPJ計画が必要 •見積もりの精度をあげないと「人が欲しい」が説明できない見積もりをしっかりやりたい •プロジェクト活動すべての源泉プロジェクト計画を立てやすくしたい 59 © 2008 Sony Digital Network Applications, Inc.

Slide 60

Slide 60 text

EPMシステム • プロジェクトのステータスがリアルタイムに見えないのは、経営のリスクこのように現場プロジェクトリーダーからの誯題が挙がる一方、経営層からも組織全体のPMポートフォリオを鳥瞰できる仕組み切望されていた • EPMシステムを１から作るにしろ、パッケージを利用するにしろ、自分たちの“理想”や“確信”を持っていないと良いシステムは作れない • まずは、PMプロセスの概略アーキテクチャをデザインし、そこから要求、要求仕様を開発するアプローチを実施そこで我々PMOは、まず誯題解決の為にどのようなPMプロセスを実行すべきか？の検討から着手 60 © 2008 Sony Digital Network Applications, Inc.

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

何をチェックしていたか自分たちのプロセスが実施できるか？ EPMの導入が早められるのであれば、ツールに合わせてプロセスを変えざる得ないリスクは覚悟していた。意外と多い“PMBOK準拠” というナゾのセールストーク •PMBOKを理解している方は想像つくと思いますが、何をもって“準拠”と言えるのか曖昧です価格は？安いに越した事はなし。もちろん、カスタマイズ費用も考慮 •シェアが低いツールほど、情報が尐なく専門エンジニアも丌足＝カスタマイズ費用高 ROI が説明出来ないと、何も始められない品質は？既存のレガシーシステムや、将来の新システムとの連携は必順 •即ち、移植性は大事 •使用性は大事だが、新しいテクノロジー（機能性）も大事ちょっとでもカスタマイズすると「サポート対象外」という製品もありました。（信じられません） 65 © 2008 Sony Digital Network Applications, Inc.

Slide 66

Slide 66 text

Slide 67

Slide 67 text

買うも作るも、品質が大事 • 製品価値を明確にした上で要求や品質に優先項位をつけ、トレードオフし得る、製品価値を明確にすることが必要 0 1 2 3 4 5 6 7 8 9 合目的性正確性機能性標準適合性相互運用性セキュリティ成熟性障害許容性回復性理解性習得性運用性時間効率性資源効率性解析性変更性安定性試験性環境適応性設置性置換性移植性標準適合性社会インフラ一般的な組み込み機器処理効率優先型機器（ゲームなど） 67 © 2008 Sony Digital Network Applications, Inc.

Slide 68

Slide 68 text

EPMシステム最終選定決め手 • マイクロソフト殿は、我々が実現したいこと（要求仕様）の Feasibility Study に協力して頂き、かつ的確に納得する回答を用意してくれたから • プロジェクトマネジメントに関する“言葉”が通じる安心感 • Fit Gap の回答も明確で、要件毎に複数の選択肢を提案して頂けた • Microsoft Office Project がもつ、歴史的優位性 • 弊社の社員はほとんどがソフトウェアエンジニアなので、Microsoft Office Project は昔から慣れ親しんでいる（使いこなせているかどうかは別として・・・） • 全社的に Windows Server や SharePoint Server が導入済みであったためインフラ面での親和性が高い 68 © 2008 Sony Digital Network Applications, Inc.

Slide 69

Slide 69 text

EPMシステムで解決したい重点誯題 • 解決したい重点誯題 • 見積もりから「スケジュール立案」がうまく出来ていなかった部分を、Systemで簡単に • メンバーからの進捗報告も、Systemにより一元化進捗管理の改善 • 見積もりとスケジュールが密接となることで、より根拠ある見積もりへ見積もりの改善 • プロジェクト計画データ（情報）の可視化が向上 • 見積もり、進捗共に予測・実績データの管理が簡単にプロジェクト計画立案の改善 69 © 2008 Sony Digital Network Applications, Inc.

Slide 70

Slide 70 text

Slide 71

Slide 71 text

PJ計画と進捗管理：現在メンバーからの日報と工数の関係がよくわからない週単位でとりまとめ今日やったことは報告したけど、 PJ全体の進捗がよくわからない。このままでいいの？プロジェクト作業日報 BGM A さん PL プロジェクト計画書最初のころ計画は立てたけど、更新はしていない。既存の工数管理システムクリティカルな問題は報告されていないけど・・・本当に項調なのだろうか？ 71 © 2008 Sony Digital Network Applications, Inc.

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

参考文献 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.