PMBOKに沿った、プロジェクトマネジメントによりお客様のビジネス成功を成功に導く

数々の企業のシステム導入プロジェクト～運用の実績があるスカイアーチネットワークスが、プロジェクトマネジメント手法を用いた最適なプロジェクトをご提案・実行いたします。

システム構築プロジェクトで起こりがちな問題点

情報システムの構築は、プロジェクトとして進められています。規模は、小規模なものであれば、数か月、SAPなど基幹システムの刷新などであれば数年、銀行のシステム統合であれば10年近いまたはそれ以上の歳月がかかるなど、種類も様々です。

通常、このプロジェクトは、大規模になればなるほど、社内、社外支援を含む、多数のメンバーで構成されるようになり、ステークホルダーも増えることから必然的に複雑になっていきます。また、基幹システム刷新プロジェクトなどでは、バリューチェーン上の複数の機能が一斉更新となるケースが多く、複数のプロジェクトが並行して走り、連携する必要が出てきます。

プロジェクトを実際に開始すると、よくこんな問題が起こります。

プロジェクトの進捗およびスケジュールがわからない

中長期プロジェクトになると、週次などの単位で個別に進捗確認が行われることがありますが、各プロジェクトがスケジュール通り進んでいるのか、遅れているのか早まっているのか現状把握さえ難しいということが起こります。

遅れているのであれば、追加のリソース投入や納期の延期などリカバリーするための意思決定をスポンサーに提案するなど、手を打つ必要があるにも関わらず、そもそも現状把握ができないケースです。

他のシステムと連携したい、ピーク時に耐えれるようにしてほしいなど、後出し条件・要望が出る

ウォーターフォール型ののシステム構築プロジェクトでは、初めに仕様となる業務要件を洗い出し、そこからシステム要件、設計にとプロセスが進んでいきます。初めに決めた要件（仕様）をもとにその後ろのフェーズが動いていくため、非常に重要な工程になります。

しかしながら、初期の仕様検討の段階で、新システムの要件を決めきれず、ふわっとしたイメージ（つまり、メンバーの中でも、それはシステムで実現することなのか、人が実施することなのか理解が違うことがありうる）の状態で次に進み、すでに着手済みの設計や開発、テストフェーズになって始めて、新たな要望が出てきてしまうことがあります。

これは、外部開発パートナーが、既存システムの状況や、ビジネスの情報を十分に開示されておらず、把握できず、影響範囲が特定できないことも要因の一つになります。

問題に的確に対処するためのPMBOKとは

こういったプロジェクトを進める上で起こる問題を、タイミングごとに、的確にマネジメントしていく手法の中で、ベストプラクティスとされているのが、PMBOKです。

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

PMBOK (Project Management Body of Knowledge)とは、米国のProject Management Institute(PMI)が発行する、プロジェクトマネジメントにおける知識、メソッドおよびノウハウを体系だててまとめたものです。

PMIは、1969年に設立された、プロジェクトマネジメントの研究と推進を行う国際的な非営利組織で、全世界で55万人を超える会員を擁します。

また、PMBOKに基づいたプロジェクトマネジメントの専門知識を有していることを認定する資格として、Project Management Professional (PMP)という、国際資格の認定も行われています。

PMBOKは、プロジェクトマネジメントの実質的なグローバルスタンダード(デファクト)となっており、日本企業や、米国企業のみならず、全世界で導入されています。

PMBOKの知識体系

このPMBOKでは、まず、プロジェクトに必要な知識を10個の管理エリアに分類しています。

それは、プロジェクトの進め方に関わるかかわる、スコープ管理、リソース管理、ステークホルダー管理、調達管理、コミュニケーション管理、リスク管理、そして、プロジェクトの成果に関わる、品質管理、コスト管理、スケジュール管理、これら全体を束ねる統合管理です。

また、プロジェクトは始まりと終わりがあるものとして、そのライフサイクルを５つのプロセス(立ち上げ、計画、実行、監視・管理、終結）に分け、それぞれのプロセスで、インプット、処理内容と用いるツール、アウトプットの3つの必要要素を定義しています。

これらの知識体系と、プロセス、要素を組み合わせ、プロジェクトを1つのライフサイクルとして管理していくための指針、方法論が記載された、PMBOKは現在第六版が発行されており、日本語版では769ページにわたり解説されています。

なお、この手法を用いて、より大規模管理を行っていくために、大型のプロジェクトでは、プロジェクトマネージメントオフィス(Project Management Office、略してPMO)という専門チームを作り、横断的に全体管理を行うこともあります。

PMBOKを用いたプロジェクトマネジメントのメリット、デメリット

PMBOKを用いたプロジェクトマネジメントにおけるメリットは2つあります。　

PMBOKのメリット

1つ目に、導入しやすいフレームワークです。

過去の英知をベースにしているため、手法やテンプレートなど事例が豊富に紹介されています。

それらを実践に活用することで、資料作成などの時間が短縮できたり、プロジェクトに参画しているベテランから新人まで全員が共通のフレームに則ってコミュニケーションできるため、タスク漏れや進捗管理を複数の目線で理解・チェックすることができ、方向性のブレを防ぐことができます。

2つ目は、ツールです。

プロジェクトマネジメントでは、各プロセスの円滑な処理を支援するために様々なツールが定義されています。例えば、プロジェクトチャーター、ビジネスケース、イシュ―ログなど。

その中の一つである、WBS（Work Breakdown Structure)は、プロジェクトのプロセスごとに、タスク全体を一覧化します。これにより、そのプロジェクトの一つ一つは何をインプット、処理、アウトプットするのか、どの程度時間がかかるのか、何をやるのか、誰が責任者なのか、どのくらいの工数がかかるのかといった情報やリソースを管理しやすくなります。

また、このWBSは、そのまま工数などが算出しやすいため見積もり作成に利用し、クリティカルパスの把握やリスク管理に用いられます。

PMBOKのデメリット

ただし、この手法にもデメリットが2つあります。

1つ目は、初期段階で全体のタスクをスケジューリングするため、PoC（概念実証）やアジャイルのような開発手法にはむいていないことです。

既存のプロジェクトマネジメント手法は、ウォーターフォール型の開発について定義されているため、あてはめるとスコープの都度修正など変更要素も頻度も多くなり、結局管理コストが著しくかかり非効率になります。

（代わりに、現在、前述のPMIでは、アジャイル時代のプロジェクトマネジメント手法(Agile Project Management with Scrum) も別途まとめられています。）

2つ目に、このPMBOKは、過去に起こった事例をもとにしたベストプラクティスを概念化したものであるため、抽象度が高く、直接現場での実践に役立つ内容ではない場合や、現場で起こることを必ずしもカバーしきれていないことです。

プロジェクトは生き物であり、想定外のことがたくさん起こります。また、プロジェクトは、国や企業文化などのバックグラウンド、参加するメンバー、プロジェクトの内容、プロジェクトのタイミングによって、様々なことが起こり、正論だけで進められないこともたくさんあります。

ただし、プロジェクトマネジメント自体は、グローバルなスタンダードであることに変わりはなく、IT企業のみならず、全業界・業種において、プロジェクトタイプの仕事をする方は知っておくことで、よりプロジェクトの全体像が把握しやすくなり、メンバーとしてよりうまく機能していくことも可能になります。

次より、PMBOKをベースとした、弊社の実際のプロジェクトマネジメントの例を2件ご紹介します。

PMBOKを用いたプロジェクトマネジメント事例①

どのプロジェクトでも、立ち上げ時にスコープを定義します。このスコープの範囲に基づき、詳細を決めていきます。

クライアントA様の開発プロジェクトでは、大規模で複雑なプロジェクトでありながら、標準的なものに比べ、短い期間での完成をご要望されていました。

新システムへの期待から、たくさんのビジネス要望が寄せられましたが、スコープの範囲の中でも、全て要件化して実装すると、希望する納期や費用に見合わないというジレンマがありました。

弊社では、いただいた要望を次の要領でタスクに落とし込みました。

• 機能要件や非機能要件は明確にする
• 問題にするリスク及び影響範囲は何か
• システムとしての影響範囲はどこに及ぶか
• 手戻り含めスケジュールに影響は出るか
• クリティカルなのか、運用対処可能か

併せて、お客様と認識の齟齬がないように、ビジネスインパクト、開発期間、コスト感を明らかにしたた上で、お客様に優先順位を決めていただきました。

結果として、ステークホルダーにも必要最低限のシステム機能の実装を実現することで意思決定していただくことができました。

クライアントの利用用途やシステム構築背景などできる限りの情報収集を実施し、経験と組み合わせて、お客様がイメージしやすい、開発内容のタスク化をインプット情報としてご提示することに努めています。

PMBOKを活用した事例②　

また、弊社では、大規模なプロジェクトで起こりがちな、プロジェクトの複雑化を回避するため、統合管理プロセスを重視します。

プロジェクト立ち上げ時のプロジェクトチャーター宣言時に、併せて、プロジェクトスポンサーが出席して、予算などの意思決定を行う場、問題を解決する場、進捗を確認する場など、それぞれのガバナンスを制定します。

このガバナンスとは、どの会議体で、誰が出席し、なんの役割で、何を意思決定するのか、その意思決定プロセス・そのためのミーティングを定義することです。

特に、実務レベルでのミーティングでは、プロジェクト共通で作成するWBSをもって、統一したコミュニケーションを心がけます。

例えば、クライアントB社様のプロジェクトでは、短納期でプロジェクトが進められており、進捗確認のミーティングでは、週１回、WBSをお客様と共有し、各進捗状況を報告しました。

この報告の中では、WBSのタスクの中で、遅延しているもの、その遅延の影響範囲、リスク、懸念事項等をオープンに共有・議論して、常に臨機応変に再スケジューリングを行うという方針のもと、開発を進めていきました。

そのため、スケジュール期間中の内容や個別タスクのスケジュールには変更が多々生じたものの、全体の納期には影響させずに、納期通りローンチすることができました。

プロジェクトを進めていく中で、フェーズごとに的確な調整や、全体管理を行っていくことは、プロジェクトの成否そのものを左右します。

弊社では、その重要性を理解しているからこそ、お客様へのアドバイスも欠かしません。

まとめ　

PMBOKを用いたプロジェクトマネジメントと、弊社での活用事例についてご紹介してきました。

弊社では、このPMBOKに沿って、基本に忠実にプロジェクトマネジメント行うことが前提ながらも、お客様の業種や企業文化、社内での意思決定のプロセスなどに併せ、柔軟に寄り添いお客様と相談しながらプロジェクトをすすめていきます。

例えば、PoCをご希望の場合、一定期間内に検証確認できた内容を、残りの期間でシステム作成することも可能です。

システム構築の豊富な経験を基に、予算や希望納期などお客様のご要望をうかがった上で、アドバイスも行いながら可能なかぎり、そのご要望を実現してまいります。

まずは、ぜひ、お気軽にご相談ください。