IT業界でのプロジェクトマネジメント(管理)の基本がわかる

SE中級・上級へスキルアップする方向け
IT業界でのプロジェクトマネジメント(管理)の基本がわかる

目次

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

ITシステムの開発では、プログラムを作る技術だけではプロジェクトを成功させることはできません。
プロジェクトとは、明確な目的を持ち、一定の期間や条件の中で成果物を作り上げる活動です。

プロジェクトでは、「決められた納期までに完成させる」「予算を守る」「求められている品質を確保する」「関係者と認識を合わせる」といった、さまざまな要素を管理する必要があります。
そこで重要になるのがプロジェクトマネジメント(Project Management)です。
プロジェクトマネジメントは、明確な期限と目標が定められた「プロジェクト」を成功に導くための管理手法です。
予算、スケジュール、人材などのリソースを最適に配分し、「品質」「コスト」「納期(QCD)」のバランスを管理・コントロールしながら目標達成を目指す一連の活動を指します。

プロジェクトは、まったく同じプロジェクトは無いといわれています。
例えば、会計システムはどの会社でも導入されていると思いますが、そのシステムを導入するためのプロジェクトは、同じものがありません。
たくさん経験を積んだり、データを残せば、流用できるパターンはあります。

プロジェクトマネジメントの3つの基本要素

プロジェクトマネジメントの大きな目的は、プロジェクトを計画どおりに進め、要求された成果を実現することです。
このため下記基本要素について、計画と実際の状況を比較し、問題があれば早期に発見して対応することになります。

  • QCD(Quality・Cost・Delivery)の管理
    • 品質(Quality): 求められる成果物のレベルや仕様を満たしているかの管理。
    • コスト(Cost): 予算や人員などの資源(リソース)が超過しないようにするための管理。
    • 納期(Delivery): 決められた期限内にプロジェクトを完了させるためのスケジュール管理。
  • スコープ管理
    • プロジェクトで達成すべき目標や実施する作業の範囲(スコープ)を明確にし、不要な作業の追加や仕様のブレ(スコープクリープ)を防ぐこと。
  • リスク管理
    • 進行の妨げになる潜在的な問題(メンバーの離職、スケジュールの遅延など)を事前に予測し、回避策や対応計画を準備しておくこと。

QCD、スコープ、リスクについては、別々のものではなく関連があります。
リスクは事前に想定されるリスクを管理しますが、もしそのリスクが顕在化すると納期遅延・品質悪化・スコープのブレなどが発生します。
この対応のために増員、機器増設等を実施すると、コスト(費用)が追加発生してしまいます。

プロジェクトをマネジメントするうえで、知っておきたい代表的な知識体系がPMBOK®です。
PMBOKは、Project Management Body of Knowledgeの略で、プロジェクトマネジメントに関する知識を体系的に整理したものです。
PMBOK®ガイドは、Project Management Institute(PMI)が発行しているプロジェクトマネジメントの代表的な標準です。現在は第8版が公開されており、2025年11月に発行されています。

PMBOKとシステム開発工程の違い

システム開発工程とPMBOKは、同じものではありません。

  • システム開発工程:
    • 「システムをどのように作っていくのか」という開発作業の流れです。
    • 開発工程=何を作るか・どのように作るか
  • PMBOK:
    • 「プロジェクトをどのようにマネジメントするのか」という考え方・知識・実践方法を整理したものです。
    • プロジェクトマネジメント=プロジェクトをどのように成功させるか

PMBOK®ガイドは、Project Management Institute(PMI)が発行するプロジェクトマネジメントの標準です。
現在の最新版は第8版で、PMI公式サイトでは第8版について、従来の原則・パフォーマンス領域を基礎としながら、実務に適用しやすいプロセスガイダンスを再整理したものと説明されています。
PMBOK®はProject Management Institute, Inc.の登録商標です。

プロジェクトマネジメントを実施する上で、PMBOKは世界標準として提供されており、参考にするとよいでしょう。

PMBOK第7版で示された8つのパフォーマンス領域

第7版では、次の8つのパフォーマンス領域が示されています。
これらは、システム開発工程のように「順番に一つずつ実施するもの」ではありません。
プロジェクト全体を通して、相互に関係しながら管理していく領域です。
PMBOKは「開発工程そのもの」ではなく、開発工程を含むプロジェクト全体を成功に導くための考え方です。

  1. ステークホルダー
    • 顧客、利用者、経営者、開発メンバー、運用担当者など、プロジェクトに関係する人を把握します。
  2. チーム
    • プロジェクトマネージャー、SE、プログラマー、テスターなどの役割を明確にし、チームとして活動できる環境を作ります。
  3. 開発アプローチとライフサイクル
    • ウォーターフォール、アジャイル、ハイブリッドなど、プロジェクトに適した開発方法を選択します。
  4. 計画
    • スケジュール、体制、コスト、品質、リスク、コミュニケーションなどを計画します。
  5. プロジェクト作業
    • 実際の開発作業を進めながら、課題、変更、コミュニケーション、リソースなどを管理します。
  6. デリバリー
    • 単にシステムを完成させるだけではなく、利用者や組織に価値を提供できる状態にすることを意識します。
  7. 測定
    • 進捗、品質、コスト、課題などを測定し、計画との差異を確認します。
  8. 不確実性
    • リスクや予測できない問題、環境変化などに対応します。

この考え方は、プロジェクト未経験者や経験が浅い方には難しいですよね。
各々のパフォーマンス領域を定義することで、プロジェクトを具体化できます。
また、手法・ツールを活用し、管理しやすくしていきます。

PMBOK第6版以前で定義されている5つのプロセス群(5つの実施フェーズ)

PMBOK 第6版までは、5つのプロセス群としてまとめられていました。
「ウォーターフォール型」や「アジャイル型」といったシステム開発手法の基礎として考えやすいので、記載しておきます。

  • 立ち上げ(Initiating):
    • プロジェクトの目的と目標を定義し、関係者の合意を得る。
  • 計画(Planning):
    • 目標達成までのスケジュール、予算、リソース配分、WBS(作業分解構造)などを詳細に策定する。
  • 実行(Executing):
    • 計画に基づいて実際の作業を進め、チームを牽引する。
  • 監視・コントロール(Monitoring & Controlling):
    • 進捗状況や予算を定期的にチェックし、計画からズレが生じている場合は迅速に軌道修正を行う。
  • 終結(Closing):
    • 成果物の納品や完了手続きを行い、プロジェクトを正式に終了させる

5つのプロセスを、回していきプロジェクトを進めていきます。
このサイクルを回す切り口は、全体から各チームの作業まで適用されます。
小さい規模では、多少割愛することもあります。

プロジェクトを管理するうえで重要な管理ポイント

プロジェクトマネジメントで重要な「進捗管理」

ITプロジェクトでは、進捗管理が非常に重要です。
計画を立てただけでは、プロジェクトが予定どおり進んでいるとは限りません。
そのため、定期的に、
「予定どおり進んでいるか」
「遅れている作業はないか」
「今後問題になりそうな作業はないか」を確認します。
そのため、単純な作業件数だけではなく、重要な工程やクリティカルな作業を確認することが大切です。

代表的な手法・フレームワーク

進捗管理を実施するうえで、利用されている手法やフレームワークは、下記のようなものがあります。

  • WBS(Work Breakdown Structure):
    • プロジェクトのタスクを階層的に細分化し、作業のモレや重複を防ぐ構造図。
  • ガントチャート:
    • WBSで洗い出したタスクとスケジュールを横棒グラフで可視化し、全体の進捗を一目でわかるようにした表。
  • アジャイル / ウォーターフォール:
    • 開発手法の一つ。ウォーターフォールは計画重視で段階的に進める手法、アジャイルは柔軟性とスピードを重視して計画を修正しながら進める手法。

進捗管理は重要です。納期のある仕事では必ず進捗管理を実施します。
進捗管理の最低メッシュは、数日以内が理想です。
ただ、細かく管理が必要な場合(遅延作業等)では、1日をさらに細分化して管理することもあります。
ただ、メッシュが細かいとタスク(作業)が細分化され、膨大な管理資料となるため、同様のタスクを取りまとめ月単位の大きな進捗管理でも管理していきます。

課題管理と問題解決

プロジェクトを進めていると、必ずと言ってよいほど問題や課題が発生します。
発生した問題を放置すると、後工程に大きな影響を与える可能性があります。
そこで、課題を一覧化して、課題の内容・発生日・担当者・期限・対応方法・現在の状況・解決日などを管理します。
このような管理を行うことで、課題の見落としを防ぎ、プロジェクト全体で情報を共有できます。

プロジェクトが稼働すると、いろいろな課題が発生します。
例えば、上流工程では想定外の追加の要望が発生したり、開発工程では、基本設計書間での矛盾や、開発環境では実施できない事象等様々な課題が発生します。
この課題を都度解決してプロジェクトは進んでいきます。
課題については、発生した工程内(要件定義、基本設計等)で解決していかないと、次工程へ進むことができなくなります。
*開発工程については、別記事で説明していますので、こちらも参考にしてください。

プロジェクトの体制を表現した体制図

プロジェクトを進めるためには、「誰がどの役割を担当しているのか」を明確にする必要があります。
そこで利用されるのがプロジェクト体制図です。
体制図とは、プロジェクトに関係する組織やメンバーの役割、責任範囲、指揮命令・連携関係などを図で表したものです。
体制図を作成することで、プロジェクトに関する責任や役割が明確になります。
また、新しくプロジェクトに参加したメンバーにとっても、体制図を見ることでプロジェクト全体の構造を理解しやすくなります。

体制図に記載する主な役割

  • プロジェクトスポンサー・責任者
    • プロジェクトに対して最終的な責任を持つ立場です。
    • 予算や重要な方針について判断する場合もあります。
  • プロジェクトマネージャー(PM)
    • プロジェクト全体を管理します。
    • スケジュール、コスト、品質、課題、リスクなどを管理し、プロジェクトを成功に導きます。
  • プロジェクトリーダー(PL)
    • 開発チームなど、担当するチームをまとめます。
    • PMとメンバーの間に入り、具体的な作業を管理する役割を担います。
  • システムエンジニア(SE)
    • 要件定義、設計、顧客との調整など、システム開発に関する幅広い業務を担当します。
  • プログラマー(PG)
    • 設計書などをもとにプログラムを作成します。
  • インフラ担当者
    • サーバー、ネットワーク、クラウド、ミドルウェアなどの環境を構築・管理します。
  • テスト担当者
    • システムが要求された仕様どおりに動作するかを確認します。
  • 運用・移行担当者
    • システムのリリースやデータ移行、運用開始後の業務などを担当します。

体制図は、自分の立場が、プロジェクトのどの位置にいるかがわかります。
大きなプロジェクトでは、メンバーの参画、退場が随時行われていきます。
この際にもプロジェクトを説明するうえで体制図は必要になります。

プロジェクトにおける会議体

プロジェクトを円滑に進めるためには、関係者が定期的に情報を共有し、問題や課題について確認する必要があります。そのために設定されるのが会議体です。
会議体とは、単に「会議をする」という意味ではありません。
誰が、何の目的で、どのような頻度で集まり、何を確認・決定するのかをあらかじめ決めた仕組みのことです。
ITプロジェクトでは、関係者が多くなるほど情報共有が重要になります。

代表的な会議体

ITプロジェクトでは、目的に応じて複数の会議体を設定することがあります。

  • プロジェクト定例会
    • プロジェクト全体の状況を確認するための定期的な会議です。
    • 一般的には、週1回などの頻度で開催し、プロジェクト全体の状況を関係者で共有します。
    • 議題例:プロジェクト全体の進捗、スケジュール、課題、リスク、品質状況、今後の予定、顧客からの要望
  • 進捗会議
    • 開発チームなどの作業状況を確認するための会議です。
    • 進捗に遅れがある場合は、その原因や対応策についても検討します。
  • 課題・リスク会議
    • プロジェクトで発生している課題や、将来的に問題となる可能性があるリスクを確認するための会議です。
    • 重要な課題については、担当者や対応期限を明確にし、解決まで追跡します。
  • ステアリングコミッティ
    • プロジェクトの重要事項を判断するために、プロジェクト責任者や顧客側の責任者などが参加する会議です。
    • 通常のプロジェクト定例会よりも、経営・責任者レベルでの意思決定を目的とします。
    • プロジェクトマネージャーだけでは判断できない事項を取り扱います。
  • 分科会・ワーキンググループ
    • 特定のテーマについて詳しく検討するための会議です。
    • プロジェクト全体の会議では時間が足りないような専門的な内容を、関係するメンバーで集中的に検討します。

会議体を設定するときのポイント

会議が多すぎると、会議そのものに時間を取られ、実際の作業時間が減ってしまいます。
そのため、会議体を設定するときには会議の目的を明確にし、必要な会議、参加メンバーの選定が必要です。
また、会議の議事録は必ず作成しましょう。

プロジェクト全体の情報を共有するのは難しいです。
このため会議体を取り決め、リーダークラス以上での必要最低限の情報共有を行います。
数名のチーム内では、会議体とは別に、必要に応じ打合せを実施し、情報共有、問題点の共有・解決などを行っていきましょう。

会議体と体制図の関係

会議体と体制図は、それぞれ別のものですが、プロジェクトマネジメントでは密接に関係しています。
体制図によって「誰がどの役割を担当するのか」を明確にし、
会議体によって「誰がどのような情報を共有し、何を決定するのか」を明確にします。
体制図と会議体をセットで考えることが、プロジェクトを円滑に進めるポイントになります。

プロジェクトのリーダーとしてのプロジェクトマネージャーについて

プロジェクトでは、プロジェクトマネージャー(PM)が中心となってプロジェクトを管理します。
プロジェクトマネージャーは、単にメンバーへ仕事を割り当てるだけではありません。
プロジェクト全体を見ながら、さまざまな判断を行います。

プロジェクトマネジメントに必要なスキル

プロジェクトマネジメントスキルとは、目標達成に向けてQCD(品質・コスト・納期)を管理し、チームを成功へ導く総合力です。
計画立案やリスク管理などの実務能力(ハードスキル)に加え、関係者間の合意形成や課題解決を図る対人能力(ソフトスキル)が求められます。
これらのスキルは、実務を通じて磨くことはもちろん、体系的な学習によって飛躍的に向上します。

具体的に求められる重要スキル

  • 計画・実行力(プロジェクト管理)
    • プロジェクトのゴールから逆算し、達成すべきタスクを細分化(WBS)し、ガントチャート等を用いてスケジュールや予算を最適に配分・管理する能力です。
  • リスク対応力
    • プロジェクトの進行に伴う課題を予測し(リスクの特定)、問題が発生した際にも迅速に原因を追及して被害を最小限に抑える能力です。
  • コミュニケーション・交渉力
    • クライアントやチームメンバー、ステークホルダーと円滑な意思疎通を図り、仕様変更や予算に関する困難な調整・合意形成を行うスキルです。
  • リーダーシップと問題解決力
    • チームのモチベーションを高め、主体性を引き出しながら、プロジェクトに発生する障害を冷静に分析し、最適解を導き出して実行する力です。

当然、上記スキルは必要ですが、プロジェクトマネージャーになるには、経験も必要です。
いろいろな立場でプロジェクトを経験を積んでいき、プロジェクトマネージャーの資格にも挑戦したほうが良いと思います。
IT業界で開発に携わっている方には、目標となる仕事になると思います。

プロジェクトマネジメント資格として、代表的な2つを記載しておきます。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次