基幹システム更改や新システム構築など組織横断の取り組みを行う際はプロジェクトを組成するが、一方でその成果は芳しくなく、日経システムズ（2012年1月号）の調査報告によると9割強は何らかの問題が発生している。失敗の要因を探ってみると、技術力の欠如は1割程度で、マネジメント力の欠如が4割強、人間力（関係者との合意形成）の欠如が4割強である。関係者との合意形成がプロジェクト成功の鍵であることが分かる。

　システム開発プロジェクトの主要な関係者はIT部門の他に、経営と業務部門が挙げられる。

（1）経営：システム導入の責任者であり、新システムの移行判定をする存在。報告を欠くと「聞いてない」と言われプロジェクトが頓挫することもある

（2）業務部門：システムの利用部門であり、ビジネスに貢献するシステムを作り上げるために不可欠な存在

　この2者をうまく巻き込み、協力を引き出すためには、経営への報告および方向性を協議するための「ステアリングコミッティ」、業務部門のプロジェクト参画を明確に示す「協同プロジェクト体制」の2つの仕組みが有効である。

ステアリングコミッティ：経営を巻き込むための仕組み

　1つ目の仕組みは経営が参加する「ステアリングコミッティ」の設置である。これは経営会議にてプロジェクト計画の承認を受けた後に、以降のプロジェクトを進める上での意思決定や状況報告を行うための会議体であり、この運営がプロジェクトの成否を決めるといっても過言ではない。正しく機能させるためには「経営の意思決定事項」と「移行判定のタイミング」を理解する必要がある。

経営の意思決定事項

　経営による基本的な意思決定事項は、プロジェクトの目標設定であるIT部門と業務部門の「移行判定基準」の承認、行程の計画である「マスタースケジュール」の承認、最後に移行判定基準に基づく「移行判定」の3つである。プロジェクト開始段階で、「移行判定基準」「マスタースケジュール」を承認した後は、「移行判定」へ向けて月次サイクルで進捗状況を報告する形式が多い。

ステアリングコミッティの枠組みと経営の意思決定事項（出所：アクセンチュア）

　しかし、進捗報告のみでは経営が適切な「移行判定」を行うのは難しい。少なくともユーザー企業や現場に影響するタスクは具体的な内容まで踏み込んだ報告が必要である。以下に例を示す。

• 移行リハーサルに伴うサービス休止の内容・期間、ユーザー企業への周知方法
• 新サービス開始に伴う営業店の研修計画や運用リハーサル計画

　前述のようなタスクは、具体的な内容を報告することで、経営がリスクを正確に把握することが可能となる。

移行判定のタイミング

　移行判定のタイミングは、不可逆ポイント（進めてきた作業を戻すことが困難になる時点）を見極めた上で設定する必要がある。不可逆ポイントの分かりやすい例は、新サービス開始直前の業務・システム移行の開始である。業務・システム移行の開始直前に移行判定会議を開催し、経営による意思決定を行う仕組みは一般的に行われるようになった。

　しかし、不可逆ポイントは実際には複数あるケースの方が多い。これらを把握しておかないと、思わぬところでユーザー企業、社外、現場とのトラブルを引き起こす可能性がある。特に業務部門のタスクは見落としがちなので注意が必要だ。

移行判定の意思決定タイミング（業務部門の例）（出所：アクセンチュア）

　不可逆ポイントは、自社影響の他に、例えば次のようにユーザー企業影響、社外（調達先、業務提携先）影響、現場影響の観点から洗い出す。

• 新規サービス開始に伴う申込書などの大量印刷開始
• システム統合に伴うユーザー企業の口座情報変更の周知開始
• データ事前移行に伴う事務処理センターへの業務規制開始

　このような不可逆ポイントをプロジェクト開始時点で整理し、経営と共有することでガバナンスの効いたプロジェクト運営が可能となる。

協同プロジェクト体制：業務部門を巻き込む仕組み

　2つ目の仕組みは業務部門との「協同プロジェクト体制」の立ち上げである。これはプロジェクト組成時に業務部門の主要関係者を体制に入れ、経営に宣言してしまうことで、協同責任体制を公式化してしまう手法である。

　プロジェクトの組成は、システム単位（勘定系システム、情報系システムなど）で行う。これは最も時間と労力と要するシステム開発を中心に物事を推進するためである。システム単位でプロジェクトを組成した上で、「統合版マスタースケジュール」を整備し、「協同成果物による合意形成」を徹底することで確実な巻き込みが可能となる。

統合版マスタースケジュール

　マスタースケジュールは、IT部門・業務部門各々で整備するだけでは十分でない。両部門のマイルスートンタスクの関係性を明らかにするための統合版の整備も必要である。例示している統合版マスタースケジュールでは、上段にIT部門タスク、下段に業務部門タスクを記載している。部門間で連携が必要なタスクは関係するタスク間を線で結合して、関係性を可視化している。

統合版マスタースケジュール（出所：アクセンチュア）

　連携タスクは、IT部門を起点とするものであれば、次のように「要件定義」「テスト」「運用」「移行」の観点で洗い出す。

• 要件定義：予算内でビジネス効果の高いシステムを構築するための、機能の優先順位明確化：予算内でビジネス効果の高いシステムを構築するための、機能の優先順位明確化
• テスト：システム機能検証のためのUAT（ユーザー受け入れテスト）、運用テストと併せて行う研修：システム機能検証のためのUAT（ユーザー受け入れテスト）、運用テストと併せて行う研修
• 運用：サービス開始後の運用リハーサルのための現場職員の参画：サービス開始後の運用リハーサルのための現場職員の参画
• 移行：サービス休止に伴う顧客周知、サービス切り替えに伴う業務移行：サービス休止に伴う顧客周知、サービス切り替えに伴う業務移行

　連携タスクは、連携する成果物とタイミングをあらかじめ決めておくと業務部門との連携が円滑に進む。

協同成果物による合意形成

　連携タスクにかかる合意形成は、議事録のみで行うのではなく、要件定義書や設計書、また各種計画書などの正式な成果物に記載することを原則とすべきである。これは議事録を通常見返すことはあまりないからである。議事録は成果物の合意記録としての機能と捉えるべきだ。

　成果物作成に当たっては、連携タスクを推進するために合意しておくべきこと、および合意事項に関する両部門の検討資料や意見を全て収集した上で、成果物（素案）と、その最終化までに議論すべきこと（論点）の一覧をそろえる。その後は、分科会などで論点を１つずつ潰し、合意事項を成果物に盛り込んでいく。最後に出来上がった成果物を公式な会議で承認し、議事録でその記録を残す。

協同成果物による合意形成の進め方（出所：アクセンチュア）

　このように早めに成果物の全体像を示し、それをたたき台として協議を重ねていくことで両部門の理解が増し、合意形成がしやすくなる。

プロジェクト成功へ向けて

　プロジェクト成功へ向けて、経営によるリスク把握、ガバナンスを可能にする「ステアリングコミッティ」、IT部門、業務部門間の円滑な連携、合意形成を可能にする「協同プロジェクト体制」の2つの仕組みが有効であることが理解いただけたと思う。しかし、この仕組みを機能させるためには、運営上のポイントを理解し、関係者をリードできる人材が必須である。

　例えば、ステアリングコミッティの事務局には、経営と接点のある現場（業務部門、IT部門）で経験豊富な人材をアサインするのが望ましい。また、協同プロジェクト体制の推進責任者は、業務部門とIT部門の双方の経験を持つバランスの取れた人材をアサインするのが良いだろう。

　アサインの重要性は理解できるが、自社にそのような人材はいないという会社もあるだろう。その場合は外部パートナーの活用を検討してはどうだろうか。その際は、類似プロジェクトの経験を豊富に持つ会社を選定すれば、前述した仕組みを機能させるためのツールや人材がそろっていることが期待できるため有効性が高い。

　次回は、特に業務部門との接点におけるプロジェクト推進上の難所である、要件定義、ベンダー選定（RFP作成・見積もり妥当性検証）、受け入れテスト、システム・業務移行を、どのようなプロジェクト運営術で乗り切るのか考えたい。