プロジェクトマネジメントソリューション コンサルティングパック_ケーススタディー
ケーススタディー 電子部品メーカーA社
製品開発プロセスの標準化および、それを管理するプロジェクトマネジメントの高度化のため、現行の管理手法を改革し、世界標準であるPMBOKの考えを取り入れたプロジェクトマネジメントの実践とそれをサポートするツールとして「Microsoft Project」「Microsoft Project Server」を導入。
導入の背景
プロジェクト管理の不備による売上機会の損失
半導体メーカーA社は、日々進化する技術革新の中で、動きの速い市場に対して、いかにニーズに合った質の高い製品をタイムリーに出荷するかに頭を悩ましていた。社内を見渡すといくつかのプロジェクトで納期オーバーが発生し、製品投入の遅れによる売上へのインパクトは計り知れなかった。
このような状況を一新するためには、製品開発プロセスの標準化および、それを管理するプロジェクトマネジメントの高度化が必要と判断し、現行の管理手法を改革し、世界標準であるPMBOKの考えを取り入れたプロジェクトマネジメントの実践とそれをサポートするツールとして「MicrosoftProject」「Microsoft Project Server」を導入を決定した。
「Microsoft Project Server」を導入するに当たり、社内にその専門家を育成している時間は残されていなかった。
今までのスタンドアロンベースでの利用ならともかく、サーバーを利用した全社システムの導入となると、その専門家が必要であるからだ。
そこでマイクロソフト社に相談し外部のコンサルティング会社としてTISの力をかりることとした。
解決すべき課題
Microsoft Project ではさまざまな課題が解決できる現場のプロジェクトマネジャーにインタビューした結果、下記のような課題が浮き彫りになった。
- 作業項目が標準化されておらず、タスクごとの終了条件や成果物が明確に定義されていない。
- WBSのレベルが荒く、プロジェクト管理に利用できない。
- 担当者の負荷状況が管理できていない。
- 作業項目やリソースの状況は、リーダーが頭の中だけで管理しており、それを共有する仕組みがない。
- 進捗報告がリーダーやメンバーの主観に頼ったものとなっており、定量的な裏づけがよわい。
- プロジェクトコストは、経理システムを利用しており、タイムリーな管理ができない。
- プロジェクトの完了後レビューを実施しておらず、次のプロジェクトにつなげるデータを残していない。
プロジェクト管理ツールのグローバルスタンダードである「Microsoft Project」では、上記のような課題を解決し、PMBOKに準拠したマネジメントができる。
導入に際して
インフラの整備だけではなく、ツールを自社のマネジメントにいかに適用するか
1事業部からパイロットプロジェクトを2、3選択し、試行を繰り返すと共に自社のマネジメントにあった運用ルール集、マネジメントプロセスを取りまとめた。
マネジメントプロセスはそのままユーザートレーニングや利用者ガイドとして利用できるように、ルールと合わせてMicrosoft Project やWeb Access の操作手順まで記述した。
それを参照すれば、誰がいつ、どのツールを利用して、どういった手順で、どの情報を参照し何を管理するのかが分かる仕組みとなっている。
A社での特長的なルールは下記の通り。
- プロジェクトの登録は、PMからの申請によりヘルプデスクにて一括して行う。
- 標準化されたWBSを各プロジェクトに徹底するように、プロジェクトは必ずテンプレートを利用して作成する。
- 現行の上司への報告を簡素化するために構築したWeb Access の報告用のビューを常時上司は参照し、プロジェクトの状況を確認する。
- プロジェクト開始当初に承認された計画を基準計画1、継続審議にかけた計画を基準計画2・・・、「基準計画」は現在目指す最新の計画を保存するというように基準計画の利用ルールを定めた。
Project Server のシステムは情報システム部門のメンバーを巻き込み、全社システムの位置付けで導入を進めた。
日本ではまだ事例の少ない全社規模のユーザーに対応できるように設計した。4台のサーバーを役割に応じて負荷分散して利用する仕組みである。
組織面でも、プロジェクトマネジメントの高度化、継続的な改善、標準化、現場に定着化を図るため、社内に専任組織を立ち上げた。
専任組織はコンサルタントと共に、標準を推進すると共に各事業部の個々のプロジェクトの問題点やPMの悩みを解決しプロジェクト自体が成功することを目標に活動を開始した。
導入効果
今までPM自身や一部の担当者でしか共有されていなかった「プロジェクトの状況」が「可視化」された
プロジェクトの透明化が進み、その部門長、PM、リーダー、メンバーなどプロジェクトの関係者全員がプロジェクトの状況がつかめるようになった。
これは、ただ情報が共有化されただけではない。PM、リーダーは自分が作成したプロジェクト計画が共有され、全員から参照されるという意識から、責任を持って作業のブレークダウン、要員割り当て、計画の更新を行うようなった。メンバーも自分に明確にタスクが割り当てられることにより、責任を持って作業を推進し、実績を登録するようになった。また、部門者も各プロジェクトの進捗状況やりソースの負荷状況が明確に分かるようになり、何らかのアクションを取らざるを得なくなった。
このようにツールを通して情報共有化することによって、部門長、PM、リーダー、メンバーのプロジェクトマネジメントへの意識付けができた。
今後の展開
プロジェクトメンバー全員の意識をかえることによりプロジェクトマネジメントの改革が確実に進んでいる
本年度末には全事業部のプロジェクトが Project Server を利用して管理されていることを目標に、専任組織を中心にプロジェクトマネジメントの全社への展開を進めていく。
インフラ面でも今年度末にはProject 2003 Server への移行を行い、Active Directory 連携、負荷分散などを強化する。社員や協力会社を含めたプロジェクトメンバー全員の意識をかえることにより、プロジェクトマネジメントの改革が確実に進んでいる。
ケーススタディー 大手SIベンダーB社
開発案件の営業局面でコスト見積もりプロセスの整備のため、Microsoft Project を活用し、今まで属人的であった見積もりプロセスを標準化、見積もりの根拠が可視化でき、継続的に改善ができる仕組みを構築。
導入の背景
営業局面におけるプロセス整備によるプロジェクトの収支改善へ
B社では、システム開発の開発局面におけるスケジュール・コスト管理プロセスは、Microsoft Project／Server を利用したプロジェクト管理システム導入と、システム開発プロジェクト管理に関する社内ルールにより整備されている。
しかしシステム開発の営業局面におけるプロセスは整備されておらず、社長から、Microsoft Project を「コスト見積もり」に利用し、根拠に基づいた見積もりを行うために利用してはどうかというアイデアが提示された。経営からすると、各プロジェクトの「コスト見積もり」と「営業見積もり」を明確に分離、「利益」「顧客との関係」「競合」「将来性」などを考慮した「営業見積もり」の妥当性を評価する狙いあるためだ。
またビジネス上のプロジェクトの成功は、プロジェクトの収支にあり、開発担当者のがんばりだけでは成功はありえない。
見積もり担当者も開発プロジェクトの見積もり提案時には、個人の勘や経験だけではなく、作業項目を意識した客観的なシミュレーションを行い、根拠あるコスト見積もりを算出する必要がある。Microsoft Project はシミュレーション機能を備えており営業見積もりの段階から有効に利用できる。
また既に整備された、開発のマネジメントプロセスと整合性を取って連携させることにより、さらなる改善も可能である。
導入効果
厳格なセキュリティー設定とドキュメントの共有化を同時に実現
各部門の開発見積もり担当者約10名で推進チームが結成された。さらに、今回のプロジェクトを成功させるために、プロジェクトマネジメント分野に強い、TISが参画した。まずは、現状の問題点を把握するために、各担当者へのインタビューを行い、下記の問題点があることが分かった。
- 見積もりが属人的であり、経験のある担当者しか見積もりができない。
- 見積もり方法に関する社内規定がない。見積もり承認のルールも明確になっていない。
- プロジェクト終了後、見積もりの評価を行っておらず、実績が次の見積もりに生かし切れていない。
- 過去事例が整備されておらず、同じような見積もりミスが発生する。
これらを解決するために、Microsoft Project を利用した見積もりのプロセスとツールのカスタマイズをプロトタイプ的に行い、担当者からの意見を集約してインプリメンテーションを実施した。担当者からはWBSを利用した積み上げ型の工数見積もりを前提に、「FP法」などの標準的な見積もり手法も取り入れ、シミュレーションをしたい。とのニーズもあった。Microsoft Project 標準では、タスク・役割単位に工数を登録することはできるが、生産性や規模、流用率は登録できない。そこでユーザーフィールドをうまく利用し、工数を計算式で求めるように工夫した。計算された工数は、タスクレベルからサマリーレベル、プロジェクト全体へと積みあがるボトムアップ型の見積もりとなる。
さらに見積もりを評価するためにFP法などの標準的な見積もりも平行して行う。FP法を利用見積もりには、TISの提供する「見積もり支援ツール」を適用した。
このツールを利用することにより、上記のボトムアップ見積もりと合わせて「FP法」を利用したトップダウンでの見積もりをシミュレーション可能となる。
またプロジェクト完了後に、その生産性を評価する仕組みも構築した。プロジェクト終了後にMicrosoft Project から「実績規模」「実績流用率」を登録することにより、タスク単位にWeb Access で収集された実績工数から「実績生産性」を計算する。見積時の項目と合わせて一覧表示することにより、見積時からの規模の変化、生産性の違いが明確になる。各プロジェクトでは完了後に開発見積もり担当者も入れてこの画面を見ながら完了時レビューを行う。
導入時の注意点
見積もりの根拠が「タスク単位の規模と生産性」で示せるように
このシステムを利用して見積もり精度が向上されたと言い切れるところまでは至っていない。まだまだタスク単位の「標準生産性」を算出するデータの収集が不十分であるからだ。
しかし、見積もり担当者の今まで不明瞭であった見積もりの根拠を「タスク単位の規模と生産性」で示せるようになったという効果は大きいと考える。
これらのデータが可視化することにより、見積もり承認時にデータとしても、経験の浅い担当者の参考値としても利用できるようになったからである。
今後の展開
システム開発の全フェースをサポートするシステムの完成へ
現在、集まった実績工数を評価し「標準生産性」の整備を行っている。開発に利用するテクノロジーや手法の違いにより複数の生産性を定義する必要はある。
しかし、Microsoft Project を利用したPDCAのサイクルを構築したことにより、効率的でより精度の高いデータを収集することができる。
今後はさらに見積もりの精度向上を目指し、プロジェクトの属性から過去の類似した事例を検索し、営業フェーズにおけるコスト見積時、受注後のプロジェクト計画時に利用できる環境の構築を進める。これにより営業を含めたシステム開発の全てフェーズをサポートするシステムが完成する。
ケーススタディー 通信系会社C社
“IP Telephony” を日本市場に適合させた独自ソリューションで展開する株式会社C社。ネットワーク、ネットワーク認証、セキュリティーに関するソリューションを幅広く展開している。短期間で高品質なネットワークソリューションを提供するためにMicrosoft Project Server を導入し、より高度なプロジェクトマネジメントを実践した。
導入の背景
コミュニケーション不足による問題発生のリスク
C社の展開するサービスの多くは直接顧客での作業が中心となる。大規模なネットワーク構築ともなると担当者は長期間顧客に滞在し、協力会社と連携しながらプロジェクトを遂行していく。コミュニケーションには十分に配慮するが、担当者は数多くの案件を並行して進めておりコミュニケーション不足による問題発生のリスクは少ないとはいえない状況であった。プロジェクトマネジャーは、チームミーティングを通して担当者とのコミュニケーションを蜜に取り、それぞれ独自の管理手法により、スケジュール、リソース稼働状況、課題を把握することでリスクをカバーし、プロジェクトを問題なく完了させている。
しかし、より品質の高いサービスの提供をするためには全社レベルでのプロジェクトマネジメントレベルアップ、情報共有、ノウハウの共有をさらに進める必要性を感じていた。そのため、Microsoft Project Server を導入し、マネジメント環境の整備を進めることとなった。
今回のプロジェクトは、自社にとって未知の分野であったため、Microsoft Project のコンサルティングには定評のあるTISの協力を得ることにした。
導入効果
厳格なセキュリティー設定とドキュメントの共有化を同時に実現
Microsoft Project 導入に際して、C社の期待するポイント以下の通りであった。
- スケジュールの可視化
- リソース負荷状況の把握
- 標準WBS の定義、レベルアップ
- 成果物共有
- 標準マネジメントプロセスの定義
また、C社では、情報共有の一環として成果物（ドキュメント）の共有を実現した。ドキュメントの共有に当たっては、他グループのドキュメントは閲覧できない厳格な権限設定を限定し、セキュリティーにも配慮している。
また、Web Access から入力された実績作業時間の既存システムとの連携も実現し、実績時間の二重入力を排除した。
導入時の注意点
プロジェクトマネジメントの重要性の教育
導入時に注意したことは、現場にプロジェクトマネジメントの重要性を理解させ、「単に上からの管理がきつくなる」、「報告体力が余分にかかるだけ」といった感覚を持たせないことであった。環境を整備することで、問題の早期発見・対策、ミーティング・報告作業の効率化をはじめ結果的には自分のためになることを理解させた。
今後の展開
全社レベルでのマネジメント環境整備の推進
C社では今後、プロジェクトの実績・教訓を蓄積し、全国の拠点へ展開することを計画している。
全社レベルのマネジメント環境整備を進めることで、より一層レベルの高いサービスを顧客に提供することが目標である。
ケーススタディー D社
組み込みソフト開発、海外との共同開発計画、プラント設備開発にて、Microsoft Projectを利用したプロジェクトマネジメントを実践。
組み込みソフト開発事例
導入の背景と解決すべき課題
プロジェクトを管理するための課題が山積み
プロジェクト計画をExcelで作成しているが、作成後、変更があったときのみ修正しており、いつも最新とは限らない。
進捗状況のチェックは、マネジャーが各担当者に聞いて回っているため、全体をまとめるのに時間がかかっている。
サブシステムごとの進捗は、担当者しか把握していない。
トップ階層に提出するプロジェクト進捗報告をまとめ上げるのに、時間がかかっている。
そもそも、プロジェクトマネジメントプロセスが存在しない。
プロジェクトを管理するために、Microsoft Projectを試行導入したが、知識不足で線を引くだけになっており役立っていない。
課題解決へのアプローチ
プロセスの作成とMicrosoft Project で課題を解決
プロジェクトを管理するため、3つのアプローチを進めた。
- マネジメントプロセスとして、プロジェクトを管理する手順の整備とルールを作成する。
- 計画作成・実績収集・進捗報告・承認のマネジメントプロセスを作成。
- エンジニアリングプロセスのパターン化・テンプレート化。
- Microsoft ProjectとWeb Access を活用できるように、インプリメンテーションと定着化を実施。
導入に際して
画面をカスタマイズし、自社のマネジメントに適用
カスタマイズ対象は下記の2点
Microsoft Project のツールバーとビューバーのカスタマイズ
- 必要なボタンやビューのみを表示する
- 各種設定内容を統一する
- 進捗管理シグナル表示の基準を作成する
- 対応状況を登録する
Web Access 画面のカスタマイズ
- 不要なメニューを非表示にする
- 表示フォーマットを変更する
導入効果
改善された5つのポイント
- 同一レベルの計画作成が、できるようになった。
- プロジェクトの作業ごとの実績時間と進捗状況が、Web Access で確実に報告されるようになった。
- サブシステムやタスクごとに、基準値との比較で自動的に点滅する信号サインや対応状況の表示が特に好評である。
- Microsoft Projectを中心にして、プロジェクトの進捗状況を把握できるようになり、定例の報告会と上席への報告がスムーズになった。
- プロジェクトを管理する専任（プロジェクトマネジメントオフィス）をアサインする体制が整った。
海外との共同開発計画事例
導入の背景と解決すべき課題
プロジェクトを管理するための課題が山積み
- プロジェクト数が多く、開発者は複数のプロジェクトを対応している。
- プロジェクトは、海外の複数の国で同時に開発しており、テンプレートや作成した成果物の共有ができていない。
- 同じプロジェクト内でも、開発地域が分散しており時差もあることより、開発者同士の進捗状況が正確に把握できない。
- 進捗を一目で見えるものがないため、上席から開発者の稼働状況が把握できない。
- 顧客に対して毎週進捗レポートを作成するのがとても大変である。
課題解決へのアプローチ
インターネットの活用と運用プロセスの整備・定着
プロジェクトを管理するため、2つのアプローチを進めた。
- Microsoft ProjectとWeb Access を利用し、それをインターネット環境へ適用する。
- 運用プロセスを整備し定着化する。
- 計画立案・進捗管理・成果物共有のプロセスを作成。
導入に際して
画面をカスタマイズし、自社のマネジメントに適用
カスタマイズ対象は下記の8点
Microsoft Projectのカスタマイズ
- 環境設定のクライアントPCを強制設定する
- プロジェクトプロフィールを登録する
Web Access のカスタマイズ
- タスク単位のセキュリティー設定をする
- プロフィールによるプロジェクトのサマライズをする
- ドキュメントライブラリの管理項目を追加する
Project Server のカスタマイズ
- プロジェクトプロフィールの項目を追加する
- インターネットを通したアクセスにする
- 顧客・プロジェクトマネジャー（PM）・メンバーごとにセキュリティー設定をする
導入効果
大きく3点の改善が見られた
開発拠点間での風通しが良くなった。
- 海外の開発拠点間で、Microsoft Projectを介してプロジェクト計画を共有できるようになった。（スケジュール・各タスクの担当者など）
- タスクごとの達成率の入力と共有が行われるようになった。
- 世界中のどこからでもプロジェクト状況が分かるようになった。
成果物品質が改善された。
- Web AccessとWindows Share Point Servicesを利用して、チーム内でテンプレートや成果物を共有できるようになった。
顧客満足度が上がった。
- 顧客からプロジェクト進捗状況へのアクセスが可能になった。
- 進捗レポートが不要になり、報告回数が軽減された。
- 進捗をタイムリーに把握できるようになった。
プラント設備開発事例
導入の背景と解決すべき課題
プロジェクトを管理するための課題が山積み
開発計画が各グループ単位に管理されている。
- 全体像が見えない。
- グループ間でのプロジェクトの調整が難しい。
リソース（実験設備）の利用状況が分からない。
- ダブルブッキングが生じている。
- リソース（部品）の仕様が共有化されていない。
プロジェクトの成果（図面などのドキュメント）が一元管理されていない。
課題解決へのアプローチ
プロセスの整備と定着で課題を解決
プロジェクトを管理するため、2つのアプローチを進めた。
マネジメントプロセスを整備する。
- プロジェクト計画立案（スケジューリング・リソース割り当て・基準計画の設定）
- 計画実行・更新（作業実施・プロジェクト管理・全体管理）
- 再スケジューリング（再スケジューリング・基準計画の再設定）
マネジメントプロセスの説明とツールのトレーニングで定着化を図る。
導入に際して
画面のカスタマイズとExcelへのエクスポートで、自社のマネジメントに適用
カスタマイズ対象は下記の3点
Microsoft Project のカスタマイズ
- 簡易なタスク計画機能を追加する
- 簡易なタスク実績登録機能を追加する
- 専用ビュー・ツールバーの設定により操作を単純化する
- ドキュメントシステムと連携する
Web Access 画面のカスタマイズ
- 専用ビューの設定により管理を単純化する
- ドキュメントシステムと連携する
Excelへ全体レポートをエクスポート
ケーススタディー E社
研究開発、営業見積もりフェーズ、大規模システム開発の下流工程にて、Microsoft Project を利用したプロジェクトマネジメントを実践。
研究開発事例
導入の背景と解決すべき課題
導入前の課題が1点と要求が4点
- Microsoft Project をベースとした現行システムがあるが、個人レベルでの利用しかできていない。
- 組織としてMicrosoft Project を利用できていない。
- 入力されたデータを有効に活用できていない。
- 複数あるプロジェクトの中から、どのプロジェクトを優先して実行すべきかをシミュレーションしたい。
- 部門別の研究開発費（実績）推移をレポートしたい。
- 上記と合わせて、今後の必要予算をシミュレーションしたい。
- 複数の開発テンプレートを組み合わせて、プロジェクトに最適な計画を簡単に作成したい。
- 英語環境と日本語環境でデータを共有したい。
課題解決へのアプローチ
要望事項の実現
リソースの需要予測、プロジェクトシミュレーションを行う。
テンプレートの部品化と、部品を組み合わせての計画策定を行う。
導入に際して
最適な組み合わせシミュレーション機能対応
複数のプロジェクトの開始日などを変更して、最適な組み合わせをシミュレーションできるようにした。
部署別予算計画
複数のプロジェクトの統合で、部署別の開発費推移・予想コストを表示する
リソース需要
リソースが月別にどのくらい必要か人数を表示する
営業見積もりフェーズ事例
導入の背景と解決すべき課題
見積もりフェーズにおける課題が山積み
- 営業プロセスや承認基準が明確になっていない。
- 個人の勘や経験に依存した属人的な見積もりをしている。
- 根拠が不明確な見積もりが存在する。
- 営業担当から開発担当へ、うまく引き継がれていない。（前提条件・制約条件・未決項目などのリスク事項）
- 次期見積もりへ活用できる係数を残していない。
課題解決へのアプローチ
見積もりプロセスの構築
以下の5つの点を意識し、見積もりプロセスを構築した。
- WBSを意識した見積もりを行う。
- 客観的なシミュレーションによる、根拠ある見積もりを算出する。
- 「規模」と「生産性」を根拠として設定する。
- 次期見積もりへ実績（規模・生産性・工数）をフィードバックできる仕組みを作る。
- 営業時リスクを特定する。
導入に際して
確実な見積もりの実現
カスタマイズポイントは下記の2点
トップダウン・ボトムアップの見積もりをサポートする。
- エンジニアリングプロセス（開発テンプレート）を取り込む
- トップダウン見積もりをする（ファンクションポイント法）概算法・IFPUG法
- ボトムアップ見積もりをする（係数の入力による工数見積もり）
見積もりの事後評価をする。
- 予実（規模・流用率・生産性）の評価と教訓の洗い出しをする
- エンジニアリングプロセス（テンプレート）の改善をする
- 事例データベースへ登録する
大規模システム開発の下流工程事例
導入の背景と解決すべき課題
大規模プロジェクトを管理するための課題が山積み
- 約10千本、約10百万ステップ、約15千人月の大規模プロジェクトを管理しなくてはならない。
- 進捗をどう管理するかが問題である。
- 手作業には限界がある。
課題解決へのアプローチ
プロセスに沿って1つずつ課題を解決
プロジェクトを管理するため、6つのアプローチを進めた。
① モジュール開発のタスク（定義）を作成する
- ※1タスク＝1成果物 or 7日～10日
モジュール開発は、成果物ごとに、以下の3タスクに分けて管理する。
（モジュール仕様の作成・プログラミング・単体テスト）
② スケジュール調整を行う
- チームリーダーは、タスク単位でスケジュール策定を行う。
- Microsoft Project でスケジュールをビジュアルに確認・調整する。
- 1.開始日の設定
- 2.期間の調整
- 3.リソースの割り当て
- 4.作業時間の調整
- 5.メトリクスの設定（難易度など）
③ 進捗報告（ステータス）を行う
メンバーは作業の進捗度合いをステータスと実績作業時間をタスクごとに報告する。
④ 作業の完了承認（ステータス）を行う
チームリーダーは、完了報告（ステータス＝99）されたタスクに対して、その承認を行う。
⑤ 進捗管理（アーンドバリュー）を行う
プロジェクトの進捗・遅れの工数を管理する。
⑥ 分析を行う
Microsoft Project Server に蓄積された情報からいろいろな切り口でプロジェクトを分析する。（全体・グループ単位・リソース単位・タスク単位）
導入効果
改善された4つのポイント
- ①プロジェクトの進捗は、常に全体を把握できるようになった。
- ②プロセス定義を正しく行ったことで、同じ基準で可視化できるようになった。
- ③定例（週）進捗会議の資料を迅速に作成できるようになった。
-
④データベールにデータを蓄積したことで、さまざまなレポーティングができるようになった。
- 次につながるデータの蓄積
- 見積もりへの応用