DXプロジェクトの標準的な工程の成果物について説明します。

プロジェクト立ち上げ前の調査や超概算見積もりを経てプロジェクトが承認された後、プロジェクト憲章を定義する工程です。

プロジェクト憲章とは、プロジェクトの目的、スコープ、計画の前提条件/制約事項、プロジェクト体制、予算、スケジュール、投資効果目標などを定義し、プロジェクトの開始を正式に認める文書です。

プロジェクトオーナーやプロジェクトマネージャーが作成し、プロジェクトの指針とします。

プロジェクト憲章は、プロジェクトの「骨格」として、経営層/CxO層/ステークホルダー/プロジェクト内の認識を共有し、プロジェクトを円滑に遂行するための礎となります。

プロジェクト立ち上げ工程では

• プロジェクト憲章
• 次工程計画(要求定義工程計画書)
• レビュー記録表
• 成果物承認証跡(全行程成果物をキーパーソン全員が承認した記録)

を作成/整備します。

またプロジェクト立ち上げ工程ではプロジェクト立ち上げ工程の計画書や工程完了基準を定義せず、全成果物が承認されたことを持って工程完了判定とします。

もし、次工程で、外部コンサルタント等を調達する場合は

• RFP
• 入札主体分析評価レポート

を作成します。また、大規模プロジェクトにおいては、

• 社内各ルール/標準ガイドの整備
• プロジェクト辞書("対向システム"⇔"周辺システム"等の表記の揺れを排除し、ミスリードリスクを排除する)
• アーキテクチャー方針書
• インフラ方針書

などをベータ版として整備されるとよいでしょう。

経営層/CxO層/ステークホルダー/PJメンバーが一意に組める定性的な文章で表記する。

定量的目標は後述の効果目標章にて定義する。

例）XXXXXシステムがYYYY年MM月DD日に保守切れを迎えるため、それまでに新たにXXXXシステムを再構築する。パッケージ/SaaSを優先採用し、オペレーションコストの省力化、運用保守費用の低減を目指す。また機能のモジュール化を意識したアーキテクチャーとし、自社コアコンピタンスを維持しつつ、長期的観点で業務環境変化への柔軟な且つ廉価な対応を可能とする。

AsIsのシステム構成図をベースにプロジェクトスコープを示す。

プロジェクトスコープ周辺エリアまで図解し、プロジェクト内で認識を合わせる。

計画には必ず不確定事項が伴います。プロジェクト憲章作成時の計画は流動的であるとも言えます。

そこで、どういう前提/制約の上で計画を立案しているのか宣言します。

前提条件：不確定事項の仮置き

　例）晴れる前提でキャンプの計画を立てる

製薬事項：固定された動かせない条件

　例）現行システムはYYYY/MM/DDに保守切れとなる

では、これらはどこまで、定義すればよいか？巨大地震や火山噴火が来ない前提まで定義すべきか？

一般的に経営層＝予算の承認権限者は”突然の悪い知らせ”を嫌います。

「聞いてないよ！」となるのを避けるべきなのです。

逆算すると、巨大地震が発生したときに、経営層は「聞いてないぞ！」とはなりません。

この考え方が前提条件に明記する閾値の考え方です。

また、参考までに、前提条件や製薬事項に変化点が発生したら、即時エスカレーションし、計画を変更する必要があります。対応策をプロジェクト内で合意し、予算やスケジュールの変更管理を申請します。

プロジェクトオーナー/ステークホルダーから、これから調達する開発要員等も調達できる前提で、プロジェクト全体の権限ロール/チームをツリー図で表現する。

各チームの役割は各工程毎に異なるため、おおざっぱに

• マネージメント層
• IT部門
• 業務部門
• ベンダー

で構成する。

プロジェクト承認を得た時点の予算計画を記載する。

ただし、プロジェクト憲章を外注ベンダーも照会できる場合、予算コンテンツはプロジェクト憲章からドロップする。

プロジェクト開始～完了までのチャート図を作成する。

各工程と仕様凍結等の重要マイルストーン、外注ベンダーの請負契約期間など、プロジェクト全体のスケジュールと大まかなタスクが俯瞰できる表記とする。

プロジェクト完遂時に期待する効果目標と測定方法/測定者/測定タイミングを定義する。

一般的に新システムのGoLive直後はシステムの安定度や業務ユーザーの習熟度がこなれてないため、1年後や2年後に効果測定し、プロジェクトの採点をする。

KPIだけでなく、定性的な目標設定も可能であるが、投資承認者が腹落ちできるリターンを説明できることが必達となる。