マクロソフト Project Conference 2010

中小規模でのProject運用の課題とその対策事例

2010/12/20

株式会社 ＲＤＰｉ
株式会社ＲＤＰｉ 東京都八王子市新町 1-5 ユメックスGLビル ４F TEL: 050-5534-7004 e-mail: info@rdpi.jp

中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

中小規模での MS Project 運用の課題とその対策事例

概要
MS Project は豊富な機能と高い柔軟性を持つ優れたツールだが、中小規模の組織や小さな規模から運用を徐々に拡大したい場合には負担が大きい。エンタープライズの導入・運用だとシステム管理関連のオーバーヘッドが大きくなるし、メンバーやプロジェクトなどの一元管理にも手間がかかる。一方、スタンダードでは、人によって使い方がバラバラになってしまい組織での共有や標準化が進みにくい。また、進捗管理がガントチャートなどの限られた視点や表現でしか提供されておらず、プロジェクトに対する多面的な見方や進捗管理のパターン化やノウハウ化が進まない。MSP2003 などの古いバージョンが使われずに眠れる資産となっていることも問題である。
これらのことを考えると、プロジェクトを成功させるためのプロジェクト管理の仕組み、そして、プロジェクト管理の仕組みを支えるツールやシステムが十分に機能していないことが、プロジェクトの失敗の原因になっている側面があることに気づく。本稿ではこのような課題を解決するための、プロジェクト管理の仕組みとして考えておくべき基本方針と、それを実現するプロジェクト管理支援システムについて解説する。
プロジェクト管理支援システムについては、プロジェクト管理の結果を蓄積して活用するためのデータ形式にして出力する MS Project のアドイン・ツールと、そのデータを使って MS Project スタンダードでもプロジェクト単体だけでなく組織レベルで進捗管理やリソース管理ができるクラウドサービスを、実際の運用事例を使って紹介する。

プロジェクト管理のシステム環境
プロジェクト管理は、スケジュールやその進捗などをマネジャーやメンバーなどの関係者で共有する必要があり、また、役割や立場により様々な視点でプロジェクトの状況を把握する必要があるため、システムやツールの支援が必要不可欠である。ここでは、プロジェクト管理を支援するシステム環境について考えてみたい。

レベル１：オフィスツール利用
小規模なプロジェクトでは、スケジュール作成や定期的な進捗報告などは Excel やテキストエディタなどの普段使っているツールで作成することが多い。手軽にプロジェクト管理を行う
ことができる反面、個人が自由な使い方をしているために様々な問題も引き起こす。この場合の特徴と課題は、次のように整理することができる。

Project Conference 2010!

1

中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

特徴• 10 個前後のマイルストーン管理ですむ場合は文字中心のメールやファイルでやりとりすることが多い。
• 使い慣れた Excel を使ってガントチャート・スタイルのスケジュールを作成する。
• Excel をお絵かきツールのようにして使うことが多い。
• Excel のマクロ作成を行ってメンバーの負荷分析などを行うなど、高度な使い方をしているケースもある。
課題• 人によって表現方法やフォーマットが違うため、スケジュールを結合したり分割したりするときに手間がかかる。
• わかりやすいように表現を工夫すればするほど修正や更新に手間がかかることになり、オーバーヘッドが増えていく。
• 便利なマクロでもマクロ作成者がいなくなると保守ができなくなり、安心して使うことができなくなる。
• 個人ファイル扱いとなっているため、関係者間での共有はトラブルが起きやすい。
• 作業（タスク）は絵として表現されているだけなので、負荷分析やタスク分析などは別途手作業で行う必要がある。

レベル２：Project スタンダード導入
Excel などではトラブルやオーバーヘッドが大きくなってきたときや、プロジェクトのメンバーが 10 人から 50 人くらいの中規模になるとき、そして、メンバー間での計画や進捗の共有を強化したいときなどは、MS Project などのプロジェクト管理ツールを導入することが多い。ただ、使えるものかどうかを確認する必要があるために、手軽な MS Project スタンダード版を試験的に導入するケースが多い。この場合の特徴と課題は以下の通りである。
特徴• MS Project を使うことで進捗管理の基本スキルが身につく。
• 関連した作業（タスク）の日程変更などの修正が容易。
• プロジェクトの計画と進捗の管理に関する情報がプロジェクトファイルに一元化される。
• 様々な見方（ビュー）で計画や進捗を見ることが可能。
• リソースの負荷分析やタスクのクリティカルパス分析などが可能。
課題• 人により使い方や記述方法のバラツキが大きい。
• 複数プロジェクトの進捗をまとめて見たいときなどプロジェクトを統合するのが難しい。
• 組織全体で見たときに誰が過負荷になるかなどのプロジェクト横断的な分析が難しい。
• マトリクス体制の場合の進捗分析が困難。

レベル３：Project エンタープライズ導入
メンバーが 50 人以上の大規模プロジェクトが同時に複数走っているよう場合や、組織レベルでプロジェクト管理ツールを一括運用するような場合は、選択肢の１つとして MS Project のエンタープライズ版を導入することが多い。この場合の特徴と課題は以下の通り。

Project Conference 2010!

2

中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

特徴• 組織全体のプロジェクトを一括して管理できる。
• 組織全体のメンバーなどのリソースを一括して管理できる。
• 組織全体でプロジェクトのポートフォリオ分析などが可能。
課題• 様々な事前準備や設定が必要となるため、導入の際の手間が大きい。
• 組織にあった運用のためにはカスタマイズが必要になることが多く、コストが増大する。
• サーバーやネットワークなどのシステム管理が必要になる。
• プロジェクト管理のノウハウを組織的に蓄積するのが困難。
• 進捗の分析方法などの運用を徐々に高度化する（進化させる）のが困難。

プロジェクト管理の仕組みにおける真の問題
以上、プロジェクト管理のシステム環境について考察したが、問題を解決するためにシステム環境をレベルアップしてもまた新たな問題を抱えてしまうと言える。これは、プロジェクト管理の仕組み全体についても同様である。新しい仕組みを導入しても常に問題を抱えることとなり、現場ではそれに対応するために様々な工夫を行っている。
このような状況下で真の問題となるのは、仕組みの問題に対処する現場での工夫や努力が、何度も繰り返されることである。現場では、プロジェクトの最中でも、プロジェクトが変わっても、部署が変わっても、システムを含めた仕組みの足りないところを、時間と手間をかけて何度も繰り返し補っている。そして、プロジェクトのリーダーやメンバーは、ムダやムリだとわかっているその場限りの対処を何度も繰り返しやらされることにより、疲れ切ってしまうのである。
MS Project の場合であれば、次のような現場の声をよく聞く。
「もともと適当な日程なのに細かな入力や設定を要求される」「自動的にタスクが動いたりして、何をやるにしても時間がかかる」「リリースに合わせるために机上で精緻につじつま合わせしているだけ」「作ったファイルを結合したり、分割したりするのは手作業で大変なことになる」「進捗見たいだけなのに覚えることがたくさん」「この部分だけ見たいのに」
現場では繰り返し、システムや仕組みの足りないところを手作業で（仕方なく）補っている。

プロジェクト管理の仕組みに必要な２つの思想
このようなムダやムリになるとわかっているその場限りの対応が真の問題だととらえて、それを極力なくすための思想を仕組みに組み入れることが必要である。そのための基本思想が次の２つである。
A. 現場に合ったミニマル運用
B. プロジェクト管理の資産化
プロジェクト管理の資産化とは、やってことがムダにならないということ。一つひとつのプロジェクトでやったことが活用できる形で記録され、そのプロジェクト記録はプロジェクトが終わるたびに積み上がっていく。一つひとつが活用できる形になっているため、積み上がれば積み上がるほど、その利用価値は高くなっていく。プロジェクトをやった結果が資産となる。
Project Conference 2010!

3

中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

そして、現場に合ったミニマル運用とは、やることにムダがないということ。たとえば、MS Project は多機能でいろいろな要求に答えることができるが、現場により暗黙的な決まりごとは数多くあり、その暗黙的な決まりごとに対応することで、必要最小限のシンプルな運用にすることが大切である。
それぞれについてもう少し詳しく取り上げたい。

現場に合ったミニマル運用
暗黙的な決まりごとの１つに納期最優先というものがある。
日本でのほとんどのプロジェクトは完了日、または、リリース日は動かすことができない。結果的に延期になることはあっても、計画の段階でプロジェクトの終了日が変更されることは稀である。
納期厳守が暗黙的な決まりごとだと、MS Project (MSP) の単位数固定におけるシミュレーション機能はほとんど意味がない。進捗によってプロジェクト終了日が変わるのは（遅れるのは）迷惑なだけである。
また、計画は「できないことはわかっている」という状態からはじめるのが普通で、誰をプロジェクトに参加させればできるようになるのか、何人追加すればできるのかなどを問われる。つまり、スケジューリングとはメンバーやメンバーの負荷を分析することであり、調整することである。メンバーの負荷分析が重要なことがわかる。
もうひとつ、ミニマル運用で考えておく必要があるポイントを紹介しておきたい。進捗管理にはさまざまな視点の必要性である。多様な視点が複眼思考や多面的思考を促し、プロジェクトの状態をより正確に把握することにつながる。
たとえば、ある組織を考えたときでも、組織の中にはいくつかのプロジェクトが存在すると同時に、これとは別に電子制御部、機構部、ソフト部などのように機能グループ（部）が存在する。プロジェクトはさらに電源ブロック、制御ブロックなどのようにブロックに分かれ、ブロックごとに個人がアサインされる。機能グループ（部）はさらにチーム（課）に分かれ、チームごとに個人がアサインされる。たとえば、ソフト部の下が設計１課、設計２課、設計３課に分かれていて、それぞれに技術者が配属される。
進捗はこの構造のどこにおいても見たいという要望が出てくる。プロジェクトごと、ブロックごと、グループ（部）ごと、個人ごとのどの単位でも見たいものである。

メトリクスによるプロジェクト管理の資産化
個人的に見積もりをしたりスケジュールを書いたりするだけでは、どんなに MSP などのツールを使ったとしても、そのノウハウを他の人たちへと水平展開するのは難しい。実際、他人が作ったプロジェクトのガントチャートを見ても、どこをどう活用できるかはわからない。参考にはなるところはあるかもしれないが、その場合でも、見る側の個人的なスキルやセンスで決まる。
このような状況を越えて、プロジェクトの結果を次々と蓄積でき、蓄積したものがいつでも使える状態になる、それが資産化だ。資産化の仕組みができていれば、あるプロジェクトでやったことを他のプロジェクトに水平展開することができる。過去の経験を流用することも可能だ。
Project Conference 2010!

4中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

この資産化の仕組みを支えるのがメトリクス。メトリクスとは、数値化して定量的な管理を可能にすることである。資産化の仕組みを作るために、メトリクスを使った、可視化、パターン化、モデル化という３つのステップが必要となる。以下、それぞれのステップについて説明したい。

１．可視化（見える化）
プロジェクトで計画している作業や進捗度合いなどを適切に把握し、関係者で共有するためには、プロジェクトの活動そのものを可視化（見える化）することが最も効果的である。「自分のことは自分でわかっているから可視化は必要ない」という主張を聞くことがあるが、重要なのは、関係者全員がプロジェクトの状況に対して共通認識を持つこと。そのための手段が可視化である。
MSP で見ることができるガントチャートなども可視化のひとつだが、それだけでは不十分である。プロ
ジェクト活動を包括的に把握するためには、少なくとも基本メトリクスセットとよぶ４つの要素を可視化する必要がある。プロジェクトを可視化するための必要最小限のメトリクスである。
可視化は、標準の MSP では弱い部分だが、出力を工夫することにより、基本メトリクスセットの工数とタスク（作業要素）を可視化することが可能である（詳細は後述）。作業成果物と不具合・課題については MSP とは別の仕組みが必要となる。基本的に、作業成果物は成果物管理の仕組み、不具合・課題は不具合管理や課題管理の仕組みと関連づけて可視化する。

２．パターン化
下図の左のグラフは、時間軸で見て、開発工程ごとにプロジェクトがどのような工数のかけ方をしたのかをグラフ化したものである。プロジェクトの開発工程ごとの工数パターンである。そして、その右のグラフは、別のプロジェクトの工数パターンである。これを見ると、この２つのプロジェクトはかかった工数と期間はほぼ同じだが、工数のかけ方はまったく別だということがわかる。

このように、パターン化とは相違点や類似点を明らかにするための「型（パターン）」を作るということである。さらに、それぞれのパターンに成功と失敗というプロジェクトの結果を関連づける。このグラフでは、左側はほぼ計画通りにリリースして、リリースした後も品質問題などが起きなかったプロジェクトである。そして、右側のプロジェクトは日程も工数も計画を超過しただけでなく、リリース後も品質問題に悩まされたプロジェクトである。つまり、左は成功したプロジェクトで、右は失敗プロジェクトだ。このような結果とリンクしたパターン化ができれば、進行中のプロジェクトを同じ工数パターンであらわしたとき、左Project Conference 2010!

5中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPiのパターンと同じであれば成功する可能性が高いだろうし、右のパターンと同じであれば失敗する可能性が高くなる。

３．モデル化
パターン化により成功プロジェクトの「型」がわかるので、成功プロジェクトを集めたものから共通の特徴を抽出する。これがモデル化である。こうやって抽出されたものは成功のためのお手本（モデル）となる。
プロジェクト管理において、計画にしろ進捗にしろ、過去事例を参考にしたり、他への水平展開を行いたいという要求は強いが、そのためには、どのような「型」を目指せばいいのかというお手本（モデル）が明確で、進めようとしているプロジェクトがどのような「型」を持ったものなのかが把握できる仕組みが必要となる。すべてのプロジェクトはこのモデルをまねて計画を作成し、モデルをまねて進捗管理をする。まねるための基準がモデルという意味で、基準モデルとも呼んでいる。
メトリクスによるモデル化で、プロジェクト管理のノウハウを誰もが使える資産になる。前述したように、
メトリクスによる可視化とパターン化で、プロジェクトを客観的に見て分類することができるようになった。その上で、成功したプロジェクトと失敗したプロジェクトに分類し、成功プロジェクトに共通するパターンを抽出すると、できたものは成功パターン・セット（基準モデル）になる。すべてのプロジェクトがモデル化のために利用でき、作成した基準モデルはすべてのプロジェクトで利用できるようになる。これが資産になるという意味である。

RDPi Metrics for Project Management の概要
ミニマル運用と資産化という基本的な考え方をシステムとして実現したものが、 RDPi Metrics for
Project Management（以下、Metrics PM）である。また、Metrics という単語が入っていることからもわかるように、メトリクスを徹底的に活用している。
前述のプロジェクト管理のシステム環境を考えたとき、レベル３の Project エンタープライズ導入は費用や手間の観点から負担が大き過ぎるが、レベル２のスタンダード導入では組織レベルでの管理が難しいため拡張性や柔軟性に欠けるという問題がある。レベル２とレベル３の間の差は大きく、とくに中規模、小規模の組織では適切なシステム環境を構築しづらい原因になっている。実際、中小規模の組織では Project の導入・運用に関して次の図に示すような問題を抱えているところが多い。

Project Conference 2010!

6中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

このようなことから、スタンダードの導入であっても、複数プロジェクトの管理やリソース管理を組織レベルで可能とするレベ
ル2.5 とよべるシステム環境が望まれていた。
Metrics PM では、MSP で作成し進捗を記録したファイル（プロジェクトファイル）をメトリクスが活用できるフォーマットに変換し、クラウドのデータベースに登録することにより、複数プロジェクトの進捗管理やプロジェクトを横断したリソース管理などを可能にする。つまり、Projectスタンダードであっても組織全体でプロジェクト横断的な進捗管理を可能にし、メトリクスによる蓄積や分析を標準機能として提供する。レベル2とレベル3のギャップを埋める レベル2.5 のシステム環境といえる。Metrics PM は、右図に示すような特徴を持つ。
Metrics for PM のデータベース機能や各種の分析機能はクラウドサービスとして提供するため、プロジェクトの増減、規模のバラツキ、利用者の変化などに柔軟に対応することが可能である。１人１ヶ月単位で利用契約を結ぶことができる。さらに、MS Project そのものもクラウドサービスを利用することで（佐山経済研究所により提供されている）、運用環境の変化に容易に対応することが可能である。
Metrics for PM の全体像は次のとおりである。
MSP のアドイン (Metrics Add-in) を使って、MSP ファイルからメトリクスによる見える化、パターン化、モデル化ができるフォーマットにした分析用データを出力する。資産化できるデータ・フォーマットに変換するわけである。この分析用データを Excel などに取り込むことでも、見える化、パターン化、モデル化という一連の作業を行うことも可能である。
ただ、資産として蓄積して過去から現在まで、組織レベルの複数プロジェクトで見たり、分析したりするには、この分析用データをデータベースに蓄積していく必要がある。
これを Metrics for PM ではクラウドサービスとして提供している (Cloud-Based MetricsPM) 。
データベースに蓄積されたデータは、各種ブラウザ上で様々な進捗分析レポートやリソース分析レポートとして見ることができる。当然、過去プロジェクトを見ることや、現在走っている複数プロジェクトを比較すること、特定プロ
Project Conference 2010!

7中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

ジェクトの中を詳しく見ることなど、様々な視点での分析結果を見ることができる。
Metrics for PM での進捗管理やリソース管理は、次のような手順の繰り返しとなる。
1. MSP で計画を作成し、進捗の入力・更新を行う
2. 進捗を更新した後、Metrics Add-in を使って分析用データを作成する
3. 出力した分析用データを Cloud-Based Metrics PM にアップロードする
4. ウェブブラウザを使って進捗やリソースの分析を行う
なお、Metrics Add-in から出力される分析用データは、Excel のピボットを使って様々な表やグラフにすることも可能である。この場合、クラウドサービスを利用せずに進捗やリソースを分析することができる。

メトリクスの実例
それでは、実際の開発現場で使われたメトリクスの実例を紹介したい。グラフなどはすべて Cloud-Based
Metrics PM を使ってウェブブラウザで表示させたものである。一部、Metrics Add-in の出力を使ってExcel で表示させたものもある。
工数推移
時間軸で見た工数の予定（青色）と実績（赤色）のグラフ。
プロジェクト全体や、プロジェクト中のブロックなど、必要なスコープ（範囲）で表示させることができる。単純に計画と実績の乖離を確認することができる。実績は進捗率を工数（時間）に変換したものである。
タスク数推移時間軸でみたタスク数の推移グ
ラフ。タスク数とは時間の分解能（日，週，月）に合わせて、その分解能であらわした期間のタスクをカウントしたものである。作業の負荷を知ることができる。プロジェクト全体や、プロジェクト中のブロックなど、必要なスコープ（範囲）で表示が可能。
また、色分けは「タスクの状態」を使った「遅れている」「完了」「今後のタスク」などの分類である。タスク数で見たときの遅れ度合いや、遅れているタスクがいつからはじまっているのか、その遅れはいつまで影響するのか、などを知ることができる。

Project Conference 2010!

8中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

工数一覧・タスク数一覧
組織全体やある特定の部署で存在している複数のプロジェクトについて、タスク数や工数を表示したグラ
フ。色分けは前述のグラフと同じで、工数の場合は「計画」（図では作業時間）と「実績」（図では実績作業時間）。タスクの場合は「遅れている」「完了」「今後のタスク」といった進捗状況の分類である。タスク数や工数を比較・一覧できるほか、その進捗状況を比較・一覧することができる。
進捗率などの遅れている割合（比率）の把握も重要だが、規模が大きいほど進捗の影響が大きくなるので、作業量と遅れている割合の両方を一覧できることは効果的である。

進捗履歴
過去どのようにプロジェクトの進捗率が推移してきたかを表示したもの。過去その時々の工数やタスク数で見たときの進捗率の履歴である。遅れが拡大傾向にあるのか収束傾向にあるのかわかる。
下図では２つのプロジェクトについて、 約１ヶ月ごとに、そのときの上段は遅延時間（日）、下段は遅延タスクの割合（％）を表示している。遅延時間は、その時点で計画（作業時間）に較べて実績（実績作業時間）がどれだけ遅れているか、遅延タスク割合は、その時点のタスク数に対して「遅れている」タスクがどのくらいの割合なのかを示している。

Project Conference 2010!

9中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

リソースマップ
プロジェクトのブロックごとに計画と実績の工数を表示し、それぞれを担当しているメンバーで分類したグラフ。メンバーがどのブロックの作業にどのくらいの時間を投入する予定になっており、実際にどのくらいの時間を投入したのかを一覧することができる。

プロジェクト横断のメンバーの負荷分析
組織が、電子制御，機構，ソフトなどの技術要素で別れており、プロジェクト・メンバーがそれらの組織からの横断的なメンバーで成り立つような場合、実質、組織のマネジャーがプロジェクトへのメンバーアサインやメンバーの進捗や負荷の管理を任されているケースが多い。
この場合、組織のマネジャーにとって、自分の組織に所属しているメンバーの工数管理は非常に重要になるが、今後の詳細な予定工数を知りたい場合は、メンバーが関係しているプロジェクトそれぞれの詳細な計画を入手して、メンバーが関係している部分だけを抜き出して足し合わせるという手間のかかる作業となる。
Metrics for PM を使えば、プロジェクトごとのデータを結合して分析することが可能である。
図の左側のグラフは、ある部署に所属しているメンバーの毎月の計画工数であり、右側のグラフは、あるメンバーについて毎月の計画工数で担当するプロジェクトごとに色分けしたものである。このグラフにより、プロジェクトの兼任状況や、移行状況などを確認することができる。

Project Conference 2010!

10中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi工数を使ったアーンドバリュー・マネジメント
Metrics for PM では、個別にインタフェースを作成する必要があるが、 MS Project ファイルとは別に実績工数をデータベースに登録することができ、実績工数を使うと、工数でのアーンドバリュー・マネジメントを表示することが可能である。最新の計画と別に当初（企画時）の計画の差異を比較することもできる。

進捗ポートフォリオ
前述のアーンドバリュー・マネジメントの計画工数、進捗工数、実績工数を使って、プロジェクトのブロックごとに計画の遅延と実績の遅延とを算出し、ポートフォリオ表示したグラフ。横軸が計画遅延で、縦軸が実績遅延を示す。それぞれ 100% がオンスケジュールで、100% 未満が遅れている状態である。プロット（点）は、プロジェクトを構成するブロックであり、このグラフにより、どのブロックが遅れているのか、計画を修正すべき遅れなのか、メンバーを増やす必要がある工数投入遅れなのかを知ることができる。

運用の規模や形態に合わせた仕組み化
冒頭で、レベル１，レベル２，レベル３というプロジェクト管理の運用形態をツールやシステム環境の違いをもとに説明したが、MSP は利用形態にバラツキがあることも考慮しておく必要がある。典型的には次のように整理することができる。

Project Conference 2010!

11中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

プロジェクトの現場では、規模や MSP の利用形態が、プロジェクトによって違っていたり、組織によって変化したりすることは珍しくない。そもそも、プロジェクトとはこのような多様性を持つものであるため、プロジェクト管理の仕組みも柔軟性を持ったものになっている必要がある。さもなければ、結局は無駄な投資や時間を生むことになる。
Metrics for PM というプロジェクト管理支援環境について説明してきたが、最後に弊社で提供可能なサービスを紹介する。開発現場の運用規模や利用形態に合わせた仕組みや、その変化に対応するための仕組みを提供している。

MSP運用ガイド
MS Project は様々なプロジェクト管理スタイルに対応できるように豊富な機能を持っているが、それが運用を難しくしているというジレンマがある。また、スタンダード版で十分であるにもかかわらず、エンタープライズ版を導入してその導入や管理のオーバーヘッドに苦しむケースも多い。
弊社が提供するMSP運用ガイドは、納期を変更することは困難で、遅れにはリソース調整で対応するという日本的なプロジェクト管理スタイルに対応した使い方や、進捗分析を効果的にするタスクの属性の付け方、組織全体で複数プロジェクトを管理するスタンダード版の設定など、開発現場に合わせた運用方法を解説している。

Metrics Add-in，分析用 Excel ファイル
Metrics Add-in は本稿で述べたようなメトリクス分析を可能にするデータを出力する機能を MS Projectに追加するアドインである。MS Project のメニューから実行でき、時間軸で分解したデータを出力する。
Excel ファイルや CSV ファイルとして保存する。

Project Conference 2010!

12中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

左図は Metics Add-in を起動したときの出力形式を指定する画面である。出力するタスク種別や時間分解の単位、時間の換算レート、期間などを指定することができる。
分析用 Excel ファイルはこの出力ファイルを使って、進捗分析やリソース分析のための様々なグラフや表を表示できる Excel ファイルである。基本的にピボットを使って様々な表示を行うようにしており、カスタマイズすることも容易である。

Cloud-Based Metrics PM
機能の一部はすでに本稿で紹介した。MS Project からMetrics Add-in を使って出力したファイルをクラウドのデータベースに登録することにより、ウェブブラウ
ザで様々な進捗分析やリソース分析のグラフや表を見ることができる。
クラウドサービスであるため、利用する人、利用する期間だけの費用で使うことができる。また、グラフや表などは継続的に拡充していくため、常に最新の分析機能を利用することが可能である。
Cloud-Based Metrics PM はプロジェクト規模や MSP の利用形態のバラツキや変化に柔軟に対応できるのが特徴だが、システム導入にかかる費用の面でもメリットがある。
右図は、MSP エンタープライズのシステム導入費用と、Cloud-Based Metrics PM を含む
RDPi Metrics for PM のシステム導入費用を比較したグラフである。ユーザ数を横軸にして、ユーザ規模により導入費用がどのように変わるのかを見ている。各社の状況によりパッケージの購入価格は違うと思うが、ここでは以下のように設定した。
MSP エンタープライズ システム費用の内訳
Project Server : 948,000 円
SharePoint Server : 948,000 円
SQA Server 2008 Standard : 1,070,000 円
MS Project Professional : 130,000 円（５人に１台とした）
PWA ライセンス : 21,200 円 x ユーザ数
Enterprise CAL : 33,300 円 x ユーザ数
RDPi Metrics for PM システム費用の内訳
MS Project Standard : 74,100 円 x ユーザ数
Metrics Add-in : 12,800 円（５人に１台とした）
Cloud-Based Metrics PM : 9.800 円（５人に１台で２年間の契約とした）
この試算ではユーザが 70 人までは Metrics for PM の方が費用的にもメリットがあるという結果になった。Metrics for PM は必要な時に必要な人数分だけの契約でよいので、実際には費用はさらに安くなると考える。

Project Conference 2010!

13中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

プロジェクト管理コンサルティング
アセスメントによりプロジェクト管理の強み弱みを明らかにし、具体的な対策を一緒に実施する。大作実施には、特定のプロジェクトに参加し、プロジェクトマネジャーのスタッフ的な立場で改善を進める方法と、開発プロセスや組織レベルの仕組み作りをタスクフォースなどの形で勧める方法とがある。また、必要に応じてトレーニングやガイドラインの作成なども行う。総合的なコンサルティングを行ったある電子機器メー
カでの効果を下図に示す。
コンサルティングは、プロジェクト管理に限らず、開発プロセス管理、開発マネジメント、CMMI, ISO などへの対応など開発の仕組み化に関すること全般に可能である。プロジェクト管理と合わせて改善・改革を進めることができる。これまでの実績（一部）を以下に紹介する。
顧客

実施テーマ

電子部品開発

部品情報・部品表情報管理システム構築

電子機器開発事業部全体の開発プロセス改革

車部品開発

モデル活用による開発プロセス構築

車部品開発

ソフトウエア開発支援システム構築

電子機器開発CMM によるソフトウェア開発プロセス改善

電子機器開発ソフトウェア開発マネジメント改革

車部品開発

SPICE(ISO15504) による開発プロセス構築

通信機器開発リスクベースの開発計画＆進捗管理の仕組み構築

電子機器開発CMMI アセスメント＆トレーニング

半導体開発

プロジェクト管理の仕組み構築

電子機器開発メトリクスによるプロジェクト管理の仕組み構築

セミナー，ワークショップ（いずれもオンサイト）
プロジェクト管理全般、もしくは、メトリクスなどの特定テーマについて、１〜２時間程度のセミナーや、４時間〜10時間程度のワークショップを御社にて実施。テーマや内容は事前に打ち合わせさせていただ
き、御社に合ったものにカスタマイズすることが可能である。

サービスのまとめ
簡単のため、プロジェクト管理
環境を小規模、中規模、大規模という３つに分類した場合の、上記サービスの基本的な適用範
囲を右図に示す。

Project Conference 2010!

14中小規模でのＭＳプロジェクト運用の課題とその対策事例

株式会社 RDPi

価格
MS Project 運用ガイド 3,800 円
Metrics Add-in

12,800 円

Cloud-Based Metrics PM

１人月額 9,800 円

プロジェクト管理コンサルティング

100 万円／月 〜
以上Project Conference 2010!

15