情報システム部門担当者が身につけたいプロジェクトマネジメントを丁寧に解説
この記事では、主に情報システム部門に所属している方に向けて、「プロジェクトマネジメント」を身に着けるための第一歩となる情報や解説をお伝えします。
情報システム部門に所属していると、定常業務に加えて、業務部門からシステム利用についての相談がある、システム開発について外部業者との会議がある等、毎日が淡々と過ぎることはなかなかありません。また、会議に参加しながらシステムの障害対応をしなければならないという場面が発生することもあります。
この記事でお伝えするプロジェクトマネジメントの考え方は、実際のプロジェクトそのものだけではなく、日常の様々な状況を整理するヒントになるかもしれません。
目次
1. プロジェクトとは、プロジェクトマネジメントとは、プロジェクトマネジャーとは
この記事は、プロジェクトマネジメントの概要や、プロジェクトマネジメントを身に着けることのメリットをお伝えしますが、そもそも、「プロジェクト」とは何でしょうか。
プロジェクトは「ある成果物を決められた期限の中で、決められたリソース（予算、人員、設備など）で、決められた品質で完成する業務」と言えます。
そして、その業務を適正に管理し、成功に導くことをプロジェクトマネジメントと呼び、その責任者がプロジェクトマネジャーです。
2. なぜ情報システム部員にプロジェクトマネジメント力が必要なのか
「決められた期日内に、決められた予算と人員で、決められた品質の成果物を完成されること」と言ってしまえば簡単なようですが、実は、ここに様々な困難が含まれています。
このリスクの要因を端的に表現したものが「プロジェクトの3つの制約（3 constraints）」です。
3つとは「品質」「リソース（特にコスト）」「期限」を指し、QCDと略します。これに成果物そのものを加えて「4つの制約」と呼ぶこともあります。
なぜ「制約」と表現されるのでしょうか。例えば、成果物の品質が目標に届いておらず、完成期限をオーバーしてしまいそうなケースを想像してみてください。
成果物の品質が当初の目標に届いておらず、完成期限をオーバーしてしまいそう。
→期限を守ろうとすると、人員を増やすか、コストをかけないといけない。
→でも、予算がないから品質を下げざるを得ない。
これで、制約の意味がご理解いただけると思います。
この3つ（または４つ）は互いに密接に関連しており、「あちらを立てればこちらが立たず」の関係にあります。この状況を防ぐためにプロジェクトマネジメントの考え方があるのです。
2-1 プロジェクトマネジメントの主体
「プロジェクトマネジメント」は実行する主体によって、その意図が違うことがあるため、注意が必要です。
例として、新システム導入プロジェクトを考えてみましょう。
システムの開発自体はシステム開発会社に外部委託することが多くありますが、発注側企業の言う「プロジェクトマネジメント」と受注側企業（システム開発会社）の言う「プロジェクトマネジメント」では、往々にして意味や範囲が違うことに注意しなければなりません。
システム開発会社では「発注されたシステムを開発して納品する」ことがプロジェクトの目標です。一方で、発注側企業のプロジェクトのゴールは（プロジェクトによって異なりますが、）例えば、「新システムの導入を通じて、業務効率化を実現する」「新システムを通じて、顧客に新たな価値を提供する」ことです。
そのため、「システム開発の前段階として、現状業務と既存システムを分析し、新システムに対する要求をまとめること」や「開発され、設置された新システムを安定的に利用するために、利用者教育を行い、必要であれば導入時のヘルプデスクを準備すること」もプロジェクトの範囲に含まれます。
この点は、発注側企業内部でのプロジェクトマネジメントにおいて重要な留意点となります。
また、発注側企業としてのプロジェクトマネジメント自体を外注委託する場合があります。この場合、「ステークホルダー（利害関係者）管理」は外注先任せでは進めることができません。プロジェクトマネジメントの専門家はプロジェクトの進め方には精通していますが、社内のステークホルダーとどう向き合うかは、やはり、社員でないとわからないものです。
このように情報システム部門は、日々の仕事においても「システムの利用者やステークホルダーを強く意識すること」がとても重要です。
2-2 プロジェクトマネジメント力不足によって起きる問題
3つの制約が崩れるとどんな問題が起こるのでしょうか。前述の例がわかりやすいと思いますが、まとめると、以下のものがあります。
・「成果物」の定義の曖昧さによる業務の手戻り
・成果物の納期の遅れ、業務完了期限の超過
・予算超過
・要員不足
・期待する品質に満たない成果物とそのための利用部門での業務の混乱
あってはいけないことですが、最悪のシナリオとしては、プロジェクトの失敗・停止を招くこともあります。
また、プロジェクトの規模や複雑性が増すほどステークホルダーが多くなることも上記の問題のリスク要因となります。プロジェクト自体やプロジェクトでの最終成果物にメリットを感じる人ばかりではありません。導入される新システムによって、慣れ親しんだ業務のやり方を変えないといけないことも発生し、その変化を嫌う人もいますし、プロジェクトが進んでいるにもかかわらず、要求事項の追加・変更を求める人もいます。
ただし、期日超過や予算超過が一概にプロジェクトの失敗を意味するわけではありません。発生した問題を管理し対応策を講じた結果、予算や期限の超過が会社として許容されるのであれば、「プロジェクトの失敗」と考える必要はありません。そして、プロジェクトの中で発生する問題を解決することもプロジェクトマネジメントの大きな役割なのです。
3. プロジェクトの管理要素とは
これまで、プロジェクトマネジメントという言葉を多く使ってきましたが、具体的に何を管理すればいいのでしょうか。
管理にポイントは、大きく分けて次の2つがあります。
・プロジェクトのプロセス
・プロジェクトの管理領域
3-1 プロジェクトのプロセス
プロジェクトの大まかなプロセスとしては、図のように「立ち上げ/開始→計画→実行→是正措置→実行→（必要に応じて、実行と是正措置を繰り返す）→終結」となります。また、これらの流れの中で問題が発生していないかを監視する必要もあります。
3-2 プロジェクトの管理領域
プロジェクトの管理領域は前述の「品質」「リソース（コスト）」「期限」と「成果物」が主なものですが、これらに加えて、以下のポイントが挙げられます。
・調達管理：外部からのシステム、要員の調達をどのように行うかを計画し、実行する
・コミュニケーション管理：仕事を進めていく上でのコミュニケーションの相手、方法、タイミングを明確にし、実行する。特にステークホルダーについては、プロジェクト/業務との関係性を明確にしておくとコミュニケーションがとりやすくなる
・リスク管理：あらかじめリスク分析を行い、その対応方法を検討し、必要に応じて実施する（検討した結果、対応しないと判断するリスクもある）
・全体調整：4つの制約をもとに全体のバランスに問題がないかをチェックし、関係の管理要素に対してフィードバックする
なお、リソースはコストだけではなく「人的資源」「物的資源」を含みます。また、期限は「スケジュール」、成果物は「（プロジェクトや日常業務の）スコープ」と読み替えると、正確な意味になります。
プロジェクトの管理領域についてはPMBOK®ガイド*でも詳しく説明されています。
*PMBOK®は、米国のNPOであるPMI®（Project Management Institute米国プロジェクトマネジメント協会）がプロジェクトマネジメントの知識体系をまとめたもので、それを書籍の形にしたものをPMBOK®ガイドと呼びます。なお、米国PMIの日本法人である一般社団法人PMI日本支部ではPMBOK®ガイドの日本語版を出版しています。また、プロジェクトマネジメントに関してPMBOK®以外の標準体系については、PRINCE2やCMMIなどがあります。
参考情報：
・PMI日本支部ホームページ
3-3 プロジェクトマネジメントのツール
プロジェクトでも使えるツールは多くあります。
例としては「プロジェクト提案書」「プロジェクト実行計画書」「スコープ定義書」「プロジェクト体制図」「WBS」「アローダイヤグラム」「ガントチャート」「課題管理表」などですが、ここでは、「プロジェクト実行計画書」「スコープ定義書」「WBS」「ガントチャート」「課題管理表」を紹介します。
3-3-1 プロジェクト実行計画書
プロジェクト実行計画書はプロジェクトの開始時に作成するプロジェクトの定義書です。ここには、プロジェクトの目的、成果物の定義、期間、プロジェクト組織、予算などが記述されます。内容の詳細度は業種や企業規模、プロジェクトの規模、成果物の複雑性をもとに内部で決定します。それは、「プロジェクトの求めるものが独自の成果物である」という特徴によるものです。
3-3-2 スコープ定義書
スコープ定義書は、プロジェクトとして達成する成果物とそのために実行することの概要、および、プロジェクトとして達成しない対象を明確にするドキュメントです。このドキュメントは「計画する成果物の完成に注力し、予定していない成果物は求めない」という原則に則ったものです。極端な例ですが「顧客管理システムを開発・導入したら『売り上げ倍増』を求められた」というようなケースです。
3-3-3 WBS
WBS（Work Breakdown Structure）は、簡単に言うと「プロジェクト内でやることリスト」です。詳しい説明は別の機会に譲りますが、対象は想定したプロジェクトでも日常業務でもかまいませんので、WBSを作成してみるとプロジェクトマネジメントとして管理すべき項目の意味を肌で感じることができます。この時のポイントは「誰でもがWBSの内容を無理なく理解できるレベルになっているか」です。
WBSの詳しい用語説明はこちらをご覧ください
3-3-4 ガントチャート
ガントチャートはWBSで抽出したタスクの開始/終了時期を横棒グラフの形で表現したものです。これによってプロジェクトの進捗の見える化が可能になります。また、ガントチャートでは、開始/終了時期だけではなく、タスクの依存関係やマイルストーンを表示することによって、スケジュールが遅延した場合の対応方法の検討にも使うことができます。なお、WBSの横にガントチャートをつける方法が一般的です。
ガントチャートの詳しい用語説明はこちらをご覧ください
3-3-5 課題管理表
プロジェクトには課題や問題がつきものです。これらを管理するために課題管理表は作成されます。この表では課題/問題の発生日、タイトル、内容、担当者、対応策、結果、完了日などを記載しますが、「対応した、していない」のみを管理するのではなく、課題への対応状況を適宜記録して更新しておくことで、将来のプロジェクトでも応用することができる情報源となりますし、新たな問題が発生した時の因果関係を分析するときの役にも立ちます。問題や課題は決して個人で抱えずに、この表で集中管理するようにしましょう。
4. プロジェクトマネジメント力はどうすれば手に入るか
プロジェクトマネジメントのスキルは「ハードスキル」と「ソフトスキル」にわけることができます。
4-1 ハードスキル
ハードスキルを身につけるために3つの方法があります。
4-1-1仮想プロジェクトを考えてドキュメントを作る
ハードスキルで意識したいことは、前述の「プロジェクトにおけるプロセスの流れ」と「プロジェクトの管理領域」を理解することに他なりませんが、それを具体化したものが上述の「プロジェクト実行計画書」と「WBS」です。この２つを作成するスキルは実際のプロジェクトではとても重要なものです。
自分でプロジェクトを想定して、仮のプロジェクト実行計画書とWBSを作成してみると現実感を醸成することができます。特にこの2つの資料を作るときは「プロジェクトのことをよく知らない人が見てもわかるレベルか」を意識することで、質を向上させることができます。
4-1-2資格取得の勉強をする
プロジェクトマネジメントの資格がいくつか存在します。有名なものは「PMP®」と「情報処理技術者：プロジェクトマネジャー」です。PMP®はPMI®が認定する資格で、プロジェクトマネジャーは情報処理推進機構が行う情報処理試験により認定されるものです。どちらの資格を目指してもいいのですが、資格を取ることよりも、そのための勉強が実務に役立つと考えるべきです。なお、PMP®の試験内容の概要書は何を学べばいいかが簡潔にまとめられており有用なドキュメントです。
参考情報：
・PMP®資格について | 一般社団法人 PMI日本支部 (pmi-japan.org)
・IPA 独立行政法人 情報処理推進機構：情報処理安全確保支援士（登録セキスペ）
4-1-3プロジェクトに参加する
プロジェクトの大きさに関係なく、また、業務領域を情報システムに限定せずに、プロジェクトに参加する機会があれば積極的に参加してください。役割はプロジェクトマネジャーでなくても、プロジェクトの構成員であればいいと思います。そこで、プロジェクトの感覚をつかむとともに、プロジェクトを俯瞰することはとても役に立つ勉強法のひとつです。
4-2 ソフトスキル
ソフトスキルについては一般の業務と同様、リーダーシップ、問題解決、クリティカルシンキングなどが挙げられますが、最も大事なスキルは「コミュニケーション力」です。
プロジェクトではコミュニケーションの相手（つまり、ステークホルダー）が以下のように多岐にわたります。
・プロジェクトオーナー（プロジェクトの内容によっては経営層）
・プロジェクトメンバー
・システム開発の受注側企業
・システムによって影響を受ける業務部門
・業務的に関係する外部の企業（特にSCMが関係する場合）
・（場合によって）顧客
・（場合によって）関係する公的機関
・（まれに）競合他社
したがって、全てのコミュニケーションの相手毎に、「適切な内容を適切なタイミングで適切な表現と適切なメディアを使ってのコミュニケーション」が必要です。そのためには、日常の業務の中でもステークホルダーとのコミュニケーションの方法を意識しておく必要があります。
5. 最後に
この記事では情報システム部門の担当者が、システムに関連するプロジェクトに携わるときに知っておきたい「プロジェクトとプロジェクトマネジメントの考え方」について説明しました。
プロジェクトマネジメントの考え方は、日々の個人の業務をこなすときにも適用できる考え方です。自分が抱えている仕事を、いつまでにどれくらいのリソースを使ってどのくらいのレベルで仕上げる必要があるのか、という捉え方をすれば、この記事で説明をしたプロジェクトマネジメントの考え方を活かして、仕事に追われることなく、自身でコントロールすることができます。
ただ、この記事の内容はあくまで原理・原則レベルです。プロジェクトの内容は千差万別で、したがって、プロジェクトマネジメントの方法も各プロジェクトによってカスタマイズが必要になります。
また、新システム導入にともなって業務改革を行う場合（BPR）などは、より複雑性の高いプロジェクトになりますし、ステークホルダーの種類も多くなるため、コミュニケーションが錯綜しないように気をつけなければなりません。
「問題の起こらないプロジェクトはプロジェクトではない」と断言するプロジェクトの専門家もいるほどプロジェクトは山あり谷ありの業務ですが、無事に完成を迎えた時の達成感は何物にも代えることができません。そして、間違いなく言えることは「プロジェクトは成長機会である」と言うことです。
この記事の内容を日常業務にも応用することでスキル向上が可能ですし、実際のプロジェクトのためのスキルの準備にもなります。
この記事をお読みいただき、プロジェクトマネジメントに興味を持っていただきたいと考えます。
この記事の編集者
武田 祥太郎
大学時代法学部で労働基準法の研究を進める中で日本の労働生産に課題を感じ、ITによる企業体質の健全化を目指して（株）グローバル・パートナーズ・テクノロジーに新卒入社。 民間企業のITガバナンス、マネジメント支援業務に従事し、同社のナレッジ活用知見を活かしてIT調達ナビで記事の展開にも携わる。
