LASSIC Media らしくメディア
プロジェクト管理システム開発を外注する勘所
LASSIC IT事業部｜元請（プライムベンダー）としてプロジェクト管理システムの開発・導入を支援
この記事のポイント
- プロジェクト管理システムは、WBS(作業分解構造)による計画と工数入力・原価集計による実績把握を一体で扱う点が、汎用のタスク管理ツールとの違いです。
- 進捗を定量把握する手法としてEVM(アーンドバリューマネジメント)があり、情報処理技術者試験のシラバスでも進捗管理ツールとして位置付けられています。
- 工数管理・原価管理まで踏み込む場合は、勤怠・会計システムとの連携方法と、現場が入力を続けられる設計が定着の分かれ目になります。
目次
プロジェクト管理システムとは、複数案件の進捗・工数・原価を一元管理する仕組み
プロジェクト管理システムとは、WBS(Work Breakdown Structure。作業を階層的に分解した構造)による計画づくりと、メンバーの工数入力・集計、プロジェクトの原価や採算の把握までを一体で扱うシステムを指します。情報処理推進機構(IPA)が公開するプロジェクトマネージャ試験のシラバスでは、WBSを「プロジェクトフェーズで実施する作業を、成果物に基づき、管理しやすいより小さな作業に階層的に分割して作成する」ものと定義しています*1。
この4段階を一つのシステム上でつなぐ点が、単体のタスク管理ツールとの大きな違いです。計画づくりだけで完結せず、日々の工数入力という実績データを積み上げ、原価や稼働率という経営指標へと変換する仕組みが求められます。
WBSの最下位のレベルに定義される作業はワークパッケージ(WP)と呼ばれ、WBS・WP・スコープ規定書をあわせてスコープベースラインとします*1。この階層構造をシステム上でタスクや工数入力の単位として扱えるかどうかが、プロジェクト管理システムを選ぶ際の土台になります。
汎用のタスク管理ツールとの違い——管理対象の広さ
タスク管理ツールの多くは、個人やチーム単位でのToDo消化を主眼に設計されています。一方でプロジェクト管理システムは、IPAのシラバスが示すように、スコープ・スケジュール・コスト・品質・リスク・資源という複数のマネジメント対象を横断的に扱う前提で組み立てられています*1。
資源の見積りについてIPAのシラバスは、「活動リストの活動ごとに必要なメンバー、施設、サービス、インフラストラクチャ、ツールなどの資源を見積もって決定する」と説明しています*1。要員という資源の割り当てと、その稼働実績である工数入力とを結び付ける機能は、汎用ツールにはあまり組み込まれていません。
両者の違いを整理すると次のようになります。
| 項目 | 汎用のタスク管理ツール | プロジェクト管理システム |
|---|---|---|
| 管理の単位 | 個々のタスクの完了状況 | WBS・工数・原価を横断して管理*1 |
| 進捗の把握 | チェックリスト形式が中心 | EVMなど定量指標を用いる例がある*1 |
| 原価・採算 | 対象外であることが多い | 工数と単価から積み上げる設計*1 |
| 要員配分 | 手動での個別調整が中心 | 資源の見積り・稼働率で可視化*1 |
| 主な利用者 | 現場メンバーが中心 | PMO・情シス・経営層まで含む |
主要機能——WBS・ガントチャート・工数入力・要員配置
プロジェクト管理システムの中核機能は、WBSとガントチャートによる計画、工数入力とその集計、要員のリソース配分の3つに整理できます。IPAのシラバスでは、スケジュールの作成について「プロジェクトの活動の開始時間及び終了時間を算定し、マイルストーンを設定して、プロジェクト全体のスケジュールのベースラインを確定する」と説明されています*1。
工数入力の機能は、メンバーが日々どの案件にどれだけの時間を投入したかを記録する仕組みです。コストの見積りは活動別に必要なコストを積算して行うとされており*1、予算の作成ではこの総コストをWBSの該当するレベルに配分してコストベースラインを確定します*1。工数入力によって蓄積される実績データは、このコストベースラインと突き合わせる際の基礎情報になります。
要員のリソース配分では、メンバーごとの稼働状況を横断的に把握し、特定の担当者に作業が偏っていないかを確認します。複数プロジェクトを掛け持ちする体制では、この機能が備わっていないと過負荷や手待ちの発生が見えにくくなります。
活動の順序付けでは、先行作業との依存関係やリード・ラグを明らかにし、ネットワーク図を用いてクリティカルパスや適切な予備を決定できるように関係を整理します*1。ガントチャートは、この順序関係を時系列の棒グラフとして表示する画面であり、WBSで洗い出した作業をどの順番で進めるかを担当者やステークホルダに共有する役割を担っています。クリティカルパス上の作業が遅れると、プロジェクト全体の完了期日に直接影響するため、プロジェクト管理システムの多くはこの経路を強調表示する機能を備えています。
進捗を定量把握する——EVM(アーンドバリューマネジメント)の指標
進捗を定量的に把握する手法として広く使われているのが、EVM(アーンドバリューマネジメント)です。IPAのシラバスでも、プロジェクト作業の管理やスケジュールの管理、コストの管理という各プロセスにおいて「進捗の状況を把握するツール(EVM、トレンドチャートなど)」として位置付けられています*1。
EVMでは、PV(計画価値。スケジュールに沿って積算した各時点での計画上の予算額)、EV(出来高。ある時点までに完了した工程を金額換算した値)、AC(実コスト。その時点までにかかった実際のコストの積算値)という3つの指標を組み合わせて評価します*3。EVからPVを引いたSV(スケジュール差異)が負の値であれば遅延を示唆し、EVからACを引いたCV(コスト差異)が負の値であれば予算超過を示唆します*3。EVをPVで割ったSPI、EVをACで割ったCPIという効率指標もあり、いずれも1.0を下回ると対応が必要な状態とされています*3。
IPAのシラバスは、コストの管理プロセスにおいて「実コスト及び完成時見積コストなどのパフォーマンスデータとコストベースラインの差異の要因を分析する」ことを求めています*1。工数入力のデータが正確でなければACの算出精度が下がり、EVMそのものの信頼性が損なわれることになります。
プロジェクト原価・採算管理と勤怠・会計連携の要件
プロジェクトの原価は、多くの場合メンバーの工数に人件費単価を掛け合わせて積み上げます。IPAのシラバスにおけるコストの見積りでも、「活動別に、必要なメンバーと資源量や資源単価などを基にコストを積算」すると説明されています*1。この積算の元になるのが工数入力の実績であり、入力の粒度や精度がそのまま原価・採算管理の精度を左右します。
工数管理・原価管理まで踏み込む場合、勤怠システムとの連携が論点になります。勤怠管理は労働時間の適正把握が目的である一方、プロジェクト管理システムの工数入力は案件別の稼働配分の把握を目的とした運用です。両者の数値にずれが生じると、原価の集計や残業実態の説明に手間がかかるようになります。連携方法をあらかじめ決めておくことが、二重入力の解消につながります。
会計システムとの連携では、案件別に集計した原価を仕訳や請求データへどう橋渡しするかが検討事項です。プロジェクト単位の採算をリアルタイムに近い形で把握したい場合、工数集計から原価計算、会計データへの連携までの一連の流れをどこまで自動化するかが、システム選定の分かれ目になります。
原価管理を精緻に行う場合、見積りの精度が低い段階では予備費や引当金をあらかじめ確保しておく考え方も参考になります。IPAのシラバスは予算の作成において、経営層による管理や特定したリスクへの対応を目的に、活動やその他の作業スコープに割り当てられない引当金又は予備費の項目を作成すると説明しています*1。プロジェクト管理システム上でこの予備費を独立した費目として扱えるかどうかも、原価の実態を正しく把握するうえで確認しておきたい点です。
稼働率は、メンバーの標準的な稼働時間に対して、案件に投入した工数がどれだけの割合を占めるかで算出します。複数プロジェクトを掛け持ちする体制では、稼働率が低いメンバーと高いメンバーが同時に発生しやすく、工数入力データを集計して初めてこの偏りが見えるようになります。
内製・パッケージ・外注——導入方式を選ぶ視点
プロジェクト管理システムをパッケージ製品で導入するか、スクラッチで開発するかは、自社の案件特性によって判断が分かれます。パッケージは短期間で導入できる一方、WBSの階層構造や原価の集計ロジックが自社の管理方式と一致しない場合、運用でカバーする範囲が広がる点には注意が必要です。スクラッチ開発は自社仕様に合わせられますが、要件定義から運用開始までの期間とコストが相応にかかります。
どちらの方式でも、実際に運用が続くかどうかを左右するのは、現場メンバーが日々の工数入力を継続できる設計です。入力項目が多すぎたり、入力のタイミングが実際の業務の流れと合わなかったりすると、入力が形骸化し、原価や進捗の数値が実態を反映しなくなります。IPAのシラバスが示すように、見積りの精度は初期は簡易な手法から始め、段階的に高めていく考え方が前提になっており*1、初期段階から完璧な粒度を求めすぎない設計も選択肢の一つです。
外注してシステムを構築する場合は、WBS・工数入力・原価集計・進捗指標のうち、どこまでを標準機能でまかない、どこから自社の管理方式に合わせて個別に集計ロジックを組み込むのかを、要件定義の段階で切り分けておくことが重要です。既存の勤怠・会計システムとの接続方式や、複数プロジェクトを横断する権限設計も、外注先とすり合わせておきたい点です。エクセルや個別のスプレッドシートで案件を管理してきた場合は、過去のWBSや工数の実績データをどこまで新システムへ引き継ぐかも検討課題になります。過去実績を移行しないまま稼働を始めると、原価の期間比較や、過去実績を踏まえた見積り精度の向上がしにくくなるためです。
まとめ：プロジェクト管理システム導入で押さえる3つの判断軸
本稿ではプロジェクト管理システムの位置付けと、外注を検討する際の判断軸を整理しました。要点は3つに集約できます。第一に、プロジェクト管理システムはWBS・ガントチャートによる計画と、工数入力・原価集計という実績把握を一体で扱う点が、汎用的なタスク管理ツールとの違いです*1。第二に、進捗の定量評価にはPV・EV・ACを組み合わせるEVMが広く用いられ、情報処理技術者試験のシラバスでも進捗管理の手段として位置付けられています*1*3。第三に、工数管理・原価管理まで踏み込む場合は、勤怠・会計システムとの連携方法と、現場が入力を継続できる設計が定着の分かれ目になります。
よくある質問
プロジェクト管理システムと汎用のタスク管理ツールは何が違いますか。
汎用のタスク管理ツールは個々のタスクの完了状況を追うことが中心です。プロジェクト管理システムは、IPAのシラバスが示すスコープ・スケジュール・コスト・資源といった複数のマネジメント対象を横断し、WBSによる計画と工数・原価の実績集計を一体で扱う点が異なります*1。
EVMを導入するには、どのようなデータが必要ですか。
EVMにはPV(計画価値)、EV(出来高)、AC(実コスト)の3つの指標が必要です*3。ACの算出には工数入力の実績データが欠かせないため、工数入力の運用が定着していない段階でEVMを導入しても、指標の精度が上がりにくい点に注意が必要です。
工数入力を現場に定着させるにはどうすればよいですか。
入力項目を必要最小限にし、実際の業務の流れに沿ったタイミングで入力できるようにすることが基本です。IPAのシラバスでも見積りの精度は段階的に高めていく考え方が前提になっており*1、初期段階から詳細な粒度を求めすぎない運用も選択肢になります。
勤怠システムと工数管理はなぜずれが生じるのですか。
勤怠管理は労働時間の適正把握を目的とし、工数管理は案件別の稼働配分の把握を目的とするため、記録の粒度や単位が異なることがあります。連携方法を事前に決めておかないと、原価集計や残業実態の説明の際に二重入力や数値の不整合が生じやすくなります。
パッケージとスクラッチ、外注する場合どちらを選べばよいですか。
案件特性が定型的でWBSの階層構造や原価集計ロジックが標準機能でまかなえる場合はパッケージが有力です。自社の管理方式に合わせた集計ロジックや既存システムとの連携要件が多い場合はスクラッチ開発が向きます。どちらを選ぶ場合も、標準機能でまかなう範囲と個別に開発する範囲を要件定義の段階で切り分けておくことが重要です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA「情報処理技術者試験 プロジェクトマネージャ試験（レベル4）シラバス Ver.7.1」（https://www.ipa.go.jp/shiken/syllabus/nq6ept00000014gb-att/syllabus_pm_ver7_1.pdf）
- *2 出典：IPA「プロジェクトマネージャ試験」（試験情報ページ）（https://www.ipa.go.jp/shiken/kubun/pm.html）
- *3 出典：Promapedia「アーンド・バリュー・マネジメント（EVM）とは何か？」（https://ssaits.jp/promapedia/method/evm.html）
