【第34回】会計システム刷新でプロジェクトマネジメントって何をするの？

企業IT動向調査報告書2026（一般社団法人 日本情報システム・ユーザー協会）によると、開発規模が500人月を超える大規模システム開発プロジェクトの47.8％が予定よりも遅延、42.2%が予算よりも超過しています。反対に、予定どおりの工期で完了したプロジェクトはわずか19.9%、予算内に収まったのは23.1%にすぎません。

同報告書によると、遅延や予算超過の原因として挙げられている上位3つは、「想定以上の現行業務・システムの複雑さ」「計画時の考慮不足」「仕様変更の多発」となっており、端的に言えばプロジェクトマネジメントに失敗したのではないでしょうか。

20年前以上であれば、プラットフォームからアプリケーションまで、主要ベンダー1社が仕切ってプロジェクトマネジメントもしっかりとやってくれましたが、昨今ではベンダー側のビジネスモデルも変わり、プロジェクトマネジメントの遂行やインテグレーションは、プロジェクトのオーナーである企業側の責任という考え方になってきています。

しかし、企業側の情報システム部門でも、プロジェクトマネジメントの経験者は極めて少なく、体系的な管理手法やノウハウがあるケースはまれになってきています。失われた30年の間、大規模なシステム開発は敬遠され、既存システムの改修や保守が多かった企業では、入社から10年以上たっても、一度も大規模なシステム開発プロジェクトの経験がないというシステム担当の方々も少なくありません。

最近、「自分たちの要望に合わせてシステムを構築するのではなく、これらの製品・サービスに自分たちの業務を合わせるのだ」というFit to Standardの考え方が一般的になってきていますが、これは情報システム部門のリソース不足という裏事情も一因です。

こうしたFit to Standardによるプロジェクトでは、情報システム部門のリソース不足も相まって、ユーザー部門である経理財務部門が主体的になることも多くなってきています。つまり、自分たちで作るのではなく、既製のものを買ってくれば、手間がかからずに（情報システム部門の手を煩わせずに）、容易に導入できるといった考え方です。会計システム刷新においては、経理財務部門であっても、しっかりとプロジェクトマネジメントの方法論を理解し、実践することが不可欠になってきています。

また、昨今の会計システム刷新においては、様々なクラウドサービスやパッケージ、ソフトウェアツールを組み合わせることも多くなっています。こうしたプロジェクトは、多数の技術やベンダーの組み合わせとなり、求められるプロジェクトマネジメントやインテグレーションのレベルは逆に高く、プロジェクトのリスクも高まっていると言えます。こうしたリスクを回避するためには、ERPや会計パッケージの機能を理解し、会計業務に詳しいコンサルタントにプロジェクトマネジメントを主導してもらうことも一つの方法です。

プロジェクトマネジメントには、標準的な方法論があります。特に有名なのはPMBOK（Project Management Body of Knowledge）であり、プロジェクトマネジメントの世界標準とも言えます。
PMBOK（第6版）では、立ち上げ、計画、実行、監視・コントロール、終結という5つのプロセスと、統合管理、スコープ管理、スケジュール管理、コスト管理、品質管理、資源管理、コミュニケーション管理、リスク管理、調達管理、ステークホルダー管理の10個の知識エリアでプロジェクトマネジメントが定義されています。ここでは10個の知識エリアをご紹介します。

統合管理

統合管理とは、プロジェクトの全体の方向性を定め、計画、実行、監視、変更管理を通じて目的を達成するために調整・管理する機能です。

実践上のポイント

• プロジェクト憲章とプロジェクトマネジメント計画書を早期に整備する
• 変更は必ず影響分析（スコープ・スケジュール・コスト・品質・資源・コミュニケーション・リスク・調達・ステークホルダー）を行い、定められた意思決定ルートで行う
• ステークホルダーの優先度に応じて意思決定の委譲ルールを設定する

スコープ管理

スコープ管理とは、プロジェクトのスコープを定め、目的達成のために必要なタスクと成果物を定義し、管理する機能です。

実践上のポイント

• プロジェクトの要求事項の範囲（実施すること、しないこと）を定義し、要求者（ユーザーや利用者等）と合意する
• WBS（Work Breakdown Structure）を用いて作業と成果物を分解し、責任と完了条件を定義する
• スコープの変更は正式な変更管理で対応する

スケジュール管理

スケジュール管理とは、プロジェクトの作業、作業の順序、所要期間、資源配分に基づいてプロジェクトの納期を計画・管理する機能です。

実践上のポイント

• 作業の洗い出し→作業の順序・依存関係の定義→作業見積もり（工数・期間）→スケジュール作成の順で進める
• 各作業の進捗を測る管理指標を定義する
• クリティカルパスを特定し、スケジュールを適切に管理する
• 定期的な進捗管理と早期の遅延検知を実施する

コスト管理

コスト管理とは、プロジェクトに必要な資源（人的資源、物的資源）の費用を見積もりし、予算化するとともに、プロジェクトの進捗に応じてコストをコントロールする機能です。

実践上のポイント

• コスト見積もりに必要な測定単位や見積もり方法を明確化する
• 作業別のコスト見積もりを行い、コスト計画を作成する
• 実績管理でコスト超過を早期検出し、対応策を実施する

品質管理

品質管理とは、プロジェクトの成果物が要求を満たすように計画・管理する機能です。

実践上のポイント

• 品質基準と合格基準（検収基準）を定義する
• 品質計画→プロセス保証→成果物保証（検査・テスト）を循環させる
• テストや定期的なレビューで不具合の早期発見を図る

資源管理

資源管理とは、プロジェクトの目的達成に必要な人的資源や物的資源を計画し、調達・育成、パフォーマンス管理を行う機能です。

実践上のポイント

• プロジェクト体制を明文化（図示）し、体制における各メンバーの権限と責任を明確にする
• 適材適所のアサインを実施し、スキルギャップの早期把握や育成を行う
• モチベーション管理とチームビルディングを図る

コミュニケーション管理

コミュニケーション管理とは、ステークホルダー間のコミュニケーションを円滑にするために会議や情報共有を図る機能です。

実践上のポイント

• コミュニケーション計画で対象、内容、頻度、媒体、責任者を定義する
• 会議体は、目的、参加者、タイミング、報告・調整・決定事項を定義する
• コミュニケーション不足から起因する事項を早期に発見し、対応策を実施する

リスク管理

リスク管理とは、プロジェクトに影響を与えるリスク（不確実な事象）を特定、評価、リスク対応、監視する機能です。

実践上のポイント

• 定期的にリスクを特定→定性・定量評価→対応策（予防、軽減、監視）を決定する
• KRIを設定し、トリガー発生時の具体的アクションを用意する
• リスク管理から課題管理までを一気通貫で実施する

調達管理

調達管理とは、人的資源や物的資源を外部から調達する活動（調達計画、契約管理、見積依頼、提案評価、発注、検収、評価）を管理する機能です。

実践上のポイント

• 調達戦略（内外製方針等）を明確化する
• ベンダー評価基準（事前・事後）と契約管理プロセスを定義する
• スケジュール管理、コスト管理、品質管理、資源管理と連携する

ステークホルダー管理

ステークホルダー管理とは、ステークホルダーを特定し、ステークホルダーとの関係を適切に管理する機能です。

実践上のポイント

• ステークホルダー分析（影響力×関心度マトリクス）を作成し、対応戦略（関与、情報提供、協働）を決める
• 重要ステークホルダーには定期的な報告や関与の場を設け、期待調整を図る
• 否定的なステークホルダーへの早期対応で阻害要因を減らす

【コラム】OODA型のプロジェクトマネジメントが主流に

2021年8月に『PMBOK』第7版がリリースされ、成果物主義から価値主義に大きく変化しており、業界でも大きな話題になっております。

第6版までは、『どうやって進めていくべきか、どんな成果物を出していくのか』を重視していた「成果物主義」でした。第7版では『何を大切にすべきか』、を重視する「価値提供システム」という概念が生まれ、『価値を届ける』ことが目的という「価値主義」に代わり、その価値を提供するための12の原則（プロジェクトマネジメント・プリンシプル）が定義されました。

また、第6版までは先が見える時代に対応して、『予測型のウォーターフォール』に対応した形でした。第7版では先が見えない時代に対応した『適応型のアジャイル』の考えが色濃くなりました。不確実性という概念が追加され、より不確実な状況を想定した『パフォーマンスドメイン（行動領域）』に着目した管理となっています。

このように、プロジェクトマネジメントにおいても、「計画を立て、その計画どおりにいかに実行していくか」ではなく、「不確実な状況の中で何を大事にしてどんな価値を提供していくのか」といった方向へと、推進の仕方が農耕型から狩猟型に変化してきていると言えると思います。

大規模プロジェクトでは、多くの調整課題を多チーム間で迅速かつ適切に対策化するため、プロジェクトマネジメントを組織的に編成し、PMO（Project Management Office）チームで運営するケースが増加してきています。

小規模プロジェクトの場合、PM（Project Manager）が1人でプロジェクトを管理することは可能ですが、中規模・大規模プロジェクトの場合、PMが1人でプロジェクトを管理することは不可能になります。なぜなら、プロジェクトの規模や複雑性がスケールアップするとともに、プロジェクトのステークホルダー（プロジェクトオーナー、ユーザー部門、情報システム部門、協力会社、ベンダーなど）の増加による調整や取りまとめ事項の増加に伴い、必要工数が増加し、PMが工数不足に陥るためです。そのため、例えば進捗管理や課題管理、品質管理などの取りまとめ、ポイント整理、事前調整といった代行可能なPMタスクをサポートするPMOスタッフを充てることになります。PMO導入により、PMタスクをPMとPMO（場合によってはPMO中心）で分担することが可能になり、PMがマネジメントに専念できるようになります。

また、PMは一般的にSIerやITベンダーに任せることも多く、進捗や品質に問題が発生するとPMが開発やシステム構築に専念するために、委託元であるユーザー企業の役割についてまで、十分なケアができなくなるケースも発生します。そこで、PMOをPMとユーザー側の中立的な立場に配置し、ユーザー側タスクのマネジメントを通じ、PMとの橋渡しや調整、時にはコンフリクト解消の機能を果たすことも有効な手段となります。

前述のように大規模なプロジェクトの場合、ステークホルダーが増え、ステークホルダー間の隙間がプロジェクトのリスクや課題を生み出すことも少なくありません。こうした場合もPMOがその隙間を先手で埋め、無用なリスクの顕在化や課題発生を事前に防ぐことも重要です。

今回は、ERPや会計システムパッケージによる「会計システム刷新」のキホンのキとして、会計システム刷新におけるプロジェクトマネジメントの要諦をご紹介しました。

会計システム刷新の推進役である経理財務部門も、このプロジェクトマネジメントの基本は理解する必要があります。しかし、現実的にはプロジェクトマネジメントは実践的な経験がものをいう部分が多いのも事実です。プロジェクトマネジメントについては、会計システム刷新の水先案内人であるレイヤーズ・コンサルティングに是非ご相談ください。