ユーザー側が定義すべきプロジェクト管理の観点 | システム導入のエッセンス（３）

これまでのおさらい

システム導入をユーザー側の視点で考える「システム導入のエッセンス」の第３回です。
ここまで中長期的なシステム導入計画についてや、プロジェクト管理手法としてのPMBOKやPM7Keysなどを紹介してきました。

PMBOKやPM7Keyはプロジェクト管理の体系化された手法ではありますが、ユーザー側がプロジェクトをコントロールする上で企業内部とベンダーの双方に統制を利かせ、且つプロジェクトが目指すべき方向の指標とするものにするために、読み替える必要がある点がいくつかあります。

今回は前回紹介したPM7Keysをベースに、ユーザー側で定義すべきプロジェクト管理の観点を元に、ユーザー側のプロジェクト計画書の作成を考えてみたいと思います。

ユーザー側で定義すべきプロジェクト管理の観点について

ユーザー側のプロジェクト計画書の必要性

プロジェクト計画書はITシステム導入プロジェクトにおいて、プロジェクト全体の指針とルールとして定義される文書で、「プロ計」と略される場合もあります。

プロジェクト計画書はプロジェクトキックオフに先立ち作成され、ベンダー側とユーザー側の双方で合意した内容に基づきキックオフにおいてプロジェクトメンバーに公開されます。

プロジェクトの管理を主体的に行うのがどちらかと言われると、どうしてもベンダー側の比重が大きくなります。
実際に物を作ったり製品の仕様と運用のFit&Gapを行い運用提示できるのがベンダー側である以上、能動的にスコープやスケジュールをコントロールできるのはどうしてもベンダー側になります。

しかしここで管理を完全にベンダーに委ねることには二つの危険が伴います。

一つはベンダーが正しく管理を行っていることを確認しないうちに、プロジェクトのコントロールが効かない状態に陥る危険性です。
ベンダーはシステム導入の専門部隊ではありますが、100%の信頼を持って任せてよいとは限りません。
プロジェクトを立ち上げるほどの規模の投資になる以上、ベンダー側の活動に対するチェック機能を都度働かせて、取り返しがつかなくなる前に軌道修正を促すことも必要です。

もう一つはユーザー側の主体性や目的意識が欠如することにより、決定事項や課題解決の遅延、スコープの流動化など、プロジェクト推進におけるリスク要因が増大することです。
「全部ベンダーが決めてくれる」のようなスタンスで臨むことで、本来ユーザー側で検討しなければいけない事項が決まらなかったり、要望事項を投げるだけ投げてほったらかしになったりという状況が発生することが想定されます。
新システムを導入して運用するのは自分たちであり、そのシステムを利用することでどのような業務とするかはユーザー側の主要な検討項目です。
そしてコストとスケジュールの兼ね合いも含めたプロジェクト全体としての方針との整合をとして、運用をソフトに合わせる方向で進めるのか、新たな運用方法を模索して新システムに反映させるのか、既存業務を踏襲して非効率な部分だけ効率化できるように検討するのかのようなベースの考えを共有した上で検討に臨む必要があります。

こうした「全体の方針」や「チェック機能」を明示するために、ユーザー主体のプロジェクト計画が必要と考えるのです。
そしてこのプロジェクト計画はPFI／PFPと対を成すものであり、企業・団体としてのシステム導入の目的を示すものになるのです。

PM7Kyesをベースにした７つの観点

ユーザー側のプロジェクト計画に必要な観点を、PM7Keysを元に７つに纏めてみました。

ゴール

PM7Keysの「ビジネスベネフィット」に該当します。
プロジェクトの目的を指し、ここがブレると全体の計画が曖昧になります。

今回のプロジェクトが完了すると、何ができるようになるのか、あるいはなりたいのか。
例えば基幹システムを更新することで、現場の業務効率化を図りたいのか、経営層がリアルタイムに経営情報を把握できる仕組みを構築したいのか、業務負荷を分散したいのか事務を集約したいのか、1年後にどうなりたいのか、3年後、5年後にどうあるべきかなどが挙げられます。
全部やりたいのは山々ですが、費用や期間やプロジェクトに裂ける社内リソース等の兼ね合いを加味しなければいけなくなるので、優先度付けも必要です。

設定されたゴールは社内のステークホルダーで合意が取れたものであることが望まれます。
同じ方向に向いてプロジェクトを進めていくために、ここは肝になります。

メンバーの一部が軌道を外れ始めたとき、ベンダーの提案が当初の方向から変わり始めた時、ゴールとの整合を元に軌道修正をはかることができます。

当然RFI／RFPもこのゴールを基礎にしたものでなければいけません。
自社が求めているものをベンダーとも共有することで、よりニーズに適合した提案を受けることができます。

スコープ

PM7Keysの同名項目と同じです。
スコープとは簡単に言うと今回システムが対象とする範囲です。
「範囲」には業務範囲、利用者範囲、利用場所範囲など色々な範囲が含まれます。

特にベンダー側はこのスコープコントロールに細心の注意を払ってきます。
作業範囲が確定しないと開発すべきものも決まらず、見積もりもブレが出てしまいます。
後から後から当初想定にない要望が発生することで、費用もスケジュールも変動していき、当初計画からかけ離れたものになる危険性があります。

このリスクはユーザー側にとっても同様で、当初想定した費用やスケジュールの範囲で収まらなくなることで、追加費用の発生や稼働時期の変更、場合によっては既存運用への影響も発生する恐れがあります。
またベンダー側が合意したスコープの定義は正しく履行しているかどうかを確認する役目もあります。

スケジュール

PM7Keysの「ワーク&スケジュール」に該当する項目です。

打ち合わせスケジュール、開発スケジュール、研修スケジュール、稼働スケジュール、スケジュールと名前の付くものはたくさんあります。
社内メンバーへの参加依頼、会場や設備の予約・設営などのためには日単位での予定を決めていかなければいけません。
直近２～３か月の日単位スケジュールを小日程として管理します。
要件定義や基本設計、受入テストや仮稼働、研修などのフェーズ単位での開始／終了日とポイントになるイベント＝マイルストーンを元に進捗率を管理するためには中日程が必要です。
そしてそもそものプロジェクト全体の期間、システム稼働日をフェーズで区切って表現したものが大日程です。

基本的にはベンダーと共用して作成することになります。
計画に対しての遅延が発生していないか、あるいは発生させないためにどの程度の進捗が必要かを定期的に検討します。
スケジュールの管理対象は社内はもちろんベンダーも含まれます。

チーム

PM7Keysの「チーム」「ステークホルダー」に該当する項目です。
社内体制及びベンダー側の体制を明示し、管理します。

プロジェクトにおいてメンバーに「役割」を割り当てることは重要です。
その人のプロジェクトにおける立ち位置、行うべき事項を明確にすることで権限と責任が生じます。
声の大きい担当者がプロジェクトを掻き回すことは往々にしてありますが、検討メンバーと責任者（リーダー）に明確に役割の差異を持たせることで、最終決定権を持つのが誰かを組織として決めておくことでそうした事態の回避に役立てることができます。
ライン部門の担当者、責任者、それらを束ねるプロジェクト管理チームの担当者、責任者（プロジェクトマネージャー）、そしてプロジェクト全体の責を負うプロジェクトオーナーを配置し、それぞれのポジションの役割をプロジェクト計画に明記します。

ベンダー側の体制も同様に提示されますが、こちらも役割による責任を明確にする意味があります。

双方にとって体制図はキーマン選定の一助になるだけでなく、次項のコミュニケーションにおけるルール決めにも役立てることができます。

またプロジェクト管理における会議体の設置もここに含まれると考えます。
ベンダーと行う進捗会議、フェーズ終了判定、内部進捗などの出席者と頻度などを定義しておくことで、必須出席者の参加を促します。

コミュニケーション

PM7Keysに該当項目がありませんが、PMBOKには「コミュニケーション・マネジメント」として定義されています。

ここで定義するのは「マネジメント」というよりは「ルール」です。
ユーザー側の各担当者とベンダーの担当者が直接メールや電話で連絡して物事が決まっていくことが良い場合と悪い場合はあります。
全てのコミュニケーションで連絡票を用いるというのは、管理上望ましいですが実際にそこまで厳密に運用するのは難しい場合もあります。
管理レベルと窓口を定めて、閉じてはいけない情報が確実に共有されるようなルールを設けるようにしましょう。

またファイル共有ルールも作成したほうが良いでしょう。
現行資料の授受等をメール添付で行うのはセキュリティ的にも良くないですし、ファイルサイズが大きくて送れないことも想定されます。
また打ち合わせ資料も電子での授受が行えれば紙資料を削減することができます。
セキュアなファイル共有サービスやオンラインストレージを利用して公開範囲を限定する等の対策を明記するべきでしょう。

「チーム」で定義した会議体について、各会議体で報告すべき事項の取り決めやフォーマットなども決めておく必要があります。
定例の進捗報告で報告する内容・観点は何か、課題管理はどちらが記述及び管理を行うか、議事録の作成・承認ルートはどうするか等の取り決めも必要です。

こうした内容はベンダー側が過去のプロジェクトの事例として保持しているものがある可能性が高いので、まずは問い合わせてみて良いと考えます。
わざわざ新たな方法を使うのはどちらにとっても大変なので、要件を満たしている内容であれば既存の仕組みやものを使うほうが効率的です。

コスト

PM7Keysの「デリバリー」をユーザー側で見る場合、「コスト」という表現が適切ではないでしょうか。

初期導入コストや運用コストはどれくらいの予算を想定しているか、現時点での要件を実現するのにどれくらいの見積もりになるのか、契約に対しての成果物は何で、どこまでをどちらの責任範疇とするか、稼働後の瑕疵担保はどのように考えるか等、若干契約内容を含んだものになります。

単純に「安くしろ」というような要求ではどこまでいっても妥協点がないかもしれませんし、提供されるサービスには当然対価が発生します。
ユーザー側としてどれくらいの費用を見込んでいるのか、何を重視するのでどの部分をどれくらいのレベルまで削減できるのかなど、計画に基づいた「プロジェクトの財布」を常に意識する必要があります。

リスク

PM7Keysの「リスク」に該当する項目です。
管理の観点は前回PM7Keysで記載したものとほぼ同じですが、ユーザー側でのみ管理するようなリスクや課題があるか、それは全体課題と分けて管理するべきか等検討する必要があります。

あとがき

ルール通りにやっても100%成功しない。ルールが守られないなら言わずもがな

プロジェクトは基本的に放っておいたら失敗します。
普通にやるとうまくいかない事を、様々な手段を用いてうまくいくようにするために立ち上げられるのがプロジェクトです。
プロジェクト計画は、定義された方針とルールを守ればプロジェクトは成功する、というものであるべきではありますが、それでも100%の成功は保証されません。

しかしだからといってルールを守らなければそもそもプロジェクト計画で描いていたシナリオ通りにプロジェクトが進まなくなるため、どこに向かっていいかがわからなくなり失敗する確率はさらに高くなるでしょう。

通常業務に加えてこれらの事項を管理・徹底するのは並大抵の労力ではないかもしれませんが、それがプロジェクト導入の難しさであり、成功のために必要なエッセンスになります。

RFI・RFP／プロジェクト管理関連の記事を纏めています。