DX施策の成功にはプロジェクト計画が欠かせない｜プロジェクト計画の策定方法を解説

1. DX施策の実行に欠かせないプロジェクト計画とは？

2. DXプロジェクトの成功に計画策定が必要な理由

では、DXの施策を実行するにあたって、プロジェクト計画は本当に必要なのでしょうか？なぜ必要なのか、その理由について考えてみましょう。

様々な利害関係者とベクトルを合わせるため

DXの取り組みは、社内の特定の部署内だけで完結することはほとんどありません。企業文化の変革がDXの本質であり、利害関係上対立するような別部署の社員や、コンサル、ITベンダーなど外部人材とも協働する機会も増えてくるでしょう。
様々なバックグラウンドや思想を持った人々が協働してプロジェクトを成功させるためには、足並みを揃えて進めなければならず、共通となる目標や成功への道筋の存在が欠かせません。また、文書管理や意思決定のルール、役割分担を定めておくことで、コミュニケーションロスや作業の重複を減らし、計画通りの進行が実現されるのです。

計画外のことにも柔軟に対処するため

DXに限ったことではありませんが、どんなに現実性の高い計画を立てても、計画外のことは必ずと言ってよいほど起こります。
計画と照らし合わせて進捗を把握することで、早い段階で問題に気が付きやすくなります。また、リスクと対応策をあらかじめ定めておくことで、問題発生時に迅速に対処し、影響を最小限に食い止めることができるでしょう。
例えば、スケジュールに対して遅延の傾向があれば、すぐに原因を究明しQCDに影響が出ないよう対処します。また、想定通りの品質レベルに満たない場合には、品質レベルを満たすためにコストをかけてスケジュールを延長したり、スケジュールと費用を固定し実装する機能を減らしたり（品質を下げる）といった対処が考えられます。コスト増分に関しても、役割分担に照らし合わせて遅延の原因を明確にし、誰がコストを受け持つべきかを明確にすることができます。
このように、プロジェクト計画を策定することは、課題の早期発見につながるとともに、責任の所在が明確になり早急に対処できるという利点があるのです。

3. DXプロジェクトの計画策定方法

企画内容・目的

「どのような背景でこの取り組みを行なっているのか」「取り組むことで誰のどのような課題が解決されるのか」「どのような効果があるのか」といった取り組みの目的を整理します。プロジェクトの概要を掴むために欠かせないパートであり、経営層・現場メンバー・開発メンバー・外部関係者それぞれが理解できるよう、具体的な内容にすることが重要です。

サービス・業務全体像とスコープ

サービス・業務の全体像を示した上で、今回のプロジェクトでどのサービスや業務に影響があるのかを示します。例えば、対顧客のサービスを変革する場合、対象となる店舗や地域、顧客の属性を明確にする必要があるでしょう。業務プロセスを変革する場合には、対象の業務に加えて影響がある部署などを洗い出します。検討する範囲を明確にすることは、無駄な作業を減らすだけでなく、プロジェクトメンバーの選定基準にもなります。

システム全体構成図とスコープ

まずは、全社的にどのようなシステムを使用しており、それぞれがどのように連携しているのか、システム全体像（As-Is）を明確にします。その上で、今回のプロジェクトで影響のある範囲を明示し、将来のシステム全体図（To-Be）を作成しましょう。ここでは、ソフトウェアだけでなくハードウェアやミドルウェア、通信環境、また今後導入予定のシステムなども記載しておく必要があります。各システムの関係性を明らかにしておくことで、要件整理や設計時に必要な機能の取りこぼしが少なくなります。

体制・役割

プロジェクトを推進するチームと個人名まで含めた体制図、役割・責任の割り当て表などを作成します。ここでは、社内のメンバーだけでなく、外部関係者も含めた体制を描きましょう。また、外部関係者に対しては社内の調整窓口をもれなく割り当てることも重要です。役割と責任を個人レベルで記載することで、それぞれが行うべきことが明確化するだけでなく、責任の所在が明らかになり問題発生時の迅速な対応につながります。

リスクと対策

プロジェクトで将来発生しやすいリスク（トラブル）を洗い出し、その原因や、発生する確率、発生した場合の影響度などを検討します。
洗い出したリスクに対しては、リスク軽減策をとるのか、監視するのかといった対応方針を決め、軽減策をとる場合は、誰が責任者としていつまでに何を行うのかを決定します。プロジェクト進行中も、リスクの影響が大きくなっていないか、新規リスクがないか監視を続け、最悪の事態を防ぐために更新し続けます。

スケジュール（マスター）

マスタースケジュールとは、プロジェクトの開始から完了までに必要な全ての作業を概要レベルで示したものです。どのような工程を誰がいつまでに行うのかといった作業概要、クリティカルパス（プロジェクトの全工程を結んだ時に最長となる経路）、可能な限り遵守すべきマイルストーンなどを記載します。ステークホルダー間の作業の影響を一目で理解するために重要であり、基本的には動かさないように努力すべきものです。止むを得ない理由でマスタースケジュールを変更する場合は、変更管理のプロセスにのっとり、スケジュール面、リソース（人・コスト）面の両方が実現可能なものにする必要があります。

スケジュール（詳細）

対象の施策を実行するにあたって、どのような作業をどのような順序で実施するのかを決定し、時間軸にあてはめていく作業です。直近の1～3ヶ月のタスクを対象とし、WBS（Work Breakdown Structure）という形で明示することが多いでしょう。DXの施策を着実に実行するために、このWBSは非常に重要なものです。以下で、作成ステップを紹介していきます。

①作業の洗い出し
まずは、プロジェクトとして実行すべき作業をリストアップし、その作業の結果作成される成果物を洗い出します。この時、開始条件（どのような資料や環境が整っていれば開始できるか）と、終了条件（どのような成果物が作成され誰によって検証が完了したら終了と言えるか）も明確に決めておく必要があります。洗い出す作業としては、成果物の作成作業だけでなく、そのレビューや計画の見直しなども考慮しておかなければなりません。

②作業の順序づけ
個々の作業に必要な工数（作業量）を見積もり、作業の実施順序を決定します。同時並行で進められる作業、順番にしか進められない作業、他のチームとの調整ポイントなども踏まえて順序づけをしていきましょう。

③作業担当者の割振り
役割分担に基づいて、各作業に対応するグループ・実行者を明確にします。個人のスキルや経験、育成的な視点も含めつつ、特定の人に作業が偏り過ぎてしまわないように調整することが大切です。

④作業計画
最後に、各作業の開始日・終了日を定義します。クリティカルパスが最短になるよう考慮した上で、想定外の課題に対応するためのバッファも持たせておくことが重要です。

3-1. 品質管理ルール

品質には「機能性」「信頼性」「効率性」「使用性」「保守性」「移行性」の6つの特性があり、それぞれの目標値の設定と、担保する仕組みの構築をしておかなければなりません。
品質を担保するための仕組みとしては、「自己チェック」「第三者によるチェック」の両方が行えるように、開発ルールの策定、スケジュールへの組み込み、品質管理担当者の設置などを行いましょう。

3-2. その他管理・運営方法

その他、以下のような管理・運営方法も定義しておく必要があります。

• 進捗管理の頻度・方法（レポートの提出 or 会議での報告など）
• 課題管理の方法（課題報告方法、対応策の決定方法、管理方法など）
• 会議体の目的・頻度・参加者
• コミュニケーションルール（利用するツールや、共有対象者など）
• 文書管理ルール（ファイルの命名規則や保管場所など）
• 想定のQCDからずれる場合の変更ルールなど

上記プロジェクト計画の各項目は、プロジェクトの各フェーズで見直しを行う必要があります。前提条件（企画内容・目的・スコープなど）や、マスタースケジュールは初期の設定段階からずらさないことを目指すべきですが、それ以外は、プロジェクトの状況に合わせて詳細化・見直し・改善を行なっていきましょう。

また、プロジェクト計画として定義する項目は、全て詳細に決めておかなければならないわけではありません。プロジェクトの内容や規模に応じて適切なものをピックアップした上で、情報の粒度を調節してください。

4. アジャイル手法で進める場合の計画とは？

従来のIT開発プロジェクトのように、ウォーターフォール手法で進める場合は、前述のプロジェクト計画の策定によって概ね成功までの道筋は描けるでしょう。しかし、アジャイル手法で進める場合はどうでしょうか？計画の立て方に違いはあるのでしょうか？

アジャイル手法とは

そもそもアジャイル手法とは何かについて認識を合わせておきましょう。
アジャイル手法とは、素早い改善を繰り返すことで最適なサービスやプロセスに辿り着く、仮説検証型のアプローチです。
ユーザー視点に立った開発を目的としており、作ったものを実際に使用してもらうことで、満足度を確認しながら精度を高めていきます。

アジャイル開発には複数のアプローチがありますが、代表的な手法である“スクラム”には以下のような特徴があります。

• 要求事項はプロダクトバックログという一覧表に整理され、優先順位がつけられる
• スプリントという短い開発期間ごとに実現する要求を決定し、プロダクトをつくる
• スプリントは何度も繰り返し、機能の追加や改善を行う

アジャイル手法が向いているプロジェクトの条件

では、どのようなプロジェクトにアジャイル手法が向いているのでしょうか？アジャイル手法が向いているプロジェクトの条件について見ていきましょう。

●4〜6人のチームで進められる
規模が大きく関与人数が多いプロジェクトにはアジャイル手法は向いていません。
関与する人の数が多くなると、作業の進め方やスキルレベルもバラバラになります。そうなると仕様の整合性担保や、品質レベルを一定に保つためのコミュニケーションに一定のパワーを割かなければなりません。アジャイル手法では、スプリントを回しながら要件を固めていくため、人数が多すぎると都度最適解を出すのにアジャイルならではのスピード感が活かせないどころか、余計に時間がかかってしまいます。4〜6人、多くても10人以下のチームで推進できる規模のプロジェクトが向いているでしょう。

●仕様のアップデートが容易なプロダクト・サービスの開発
利用者が購入後保有するタイプの製品や、連携先の多いシステムを開発する場合には、高いレベルの品質を担保することが求められ、仕様のアップデートも容易ではありません。逆に、プロトタイプの開発など高品質が求められないものや、影響範囲が狭く仕様のアップデートが比較的容易にできるものにはアジャイル手法が向いていると言えるでしょう。

●プロジェクトチームが意思決定できる
アジャイル手法で進めることとは則ち、素早く開発し汲み取ったニーズを基に仕様を決定していくことです。しかし、素早く仕様を決定できる体制が整っていないとその恩恵にあずかれません。意思決定者が役員クラスであると、決定のための日程調整や背景の説明などに時間がかかり、スピード感が失われてしまうおそれがあります。そのため、開発チームに一定の権限が与えられていることが一つの条件になるでしょう。

●スキルの高いエンジニアが開発チームに加わっている
素早くモノを見ながら要件を考えるアジャイル手法ですが、開発自体に時間を要す、また、プロダクトがバグだらけで要件の検証にさえ至らないのでは、本末転倒です。デジタル技術を用いて製品化するスキルだけでなく、ビジネスサイドの要求を汲み取るスキルを持ち合わせたエンジニアが必要不可欠です。

アジャイル開発におけるプロジェクト計画の策定方法

それでは、アジャイル手法で開発を行う場合のプロジェクト計画の策定方法を紹介します。PMBOKによれば、アジャイル手法で行う場合も基本的には前述したプロジェクト計画が適用できるとされていますが、スケジュールの立て方については注意が必要でしょう。ウォーターフォール型の場合、先に要求や要件が決まるため、マスタースケジュールに合わせて、詳細なWBSを作成することができます。しかし、アジャイル型では、要求や要件は最初に決めずにスプリントをこなす過程で固まっていくため、スケジュールを詳細化することができないのです。そのため、アジャイルプロジェクトでは、以下の3つのスケジュールを作成していきます。

●リリースプランニング
リリースプランニングは、どのような機能をどれくらいの期間で作るのか、といった大局的なスケジュールです。具体的には以下のような作業を行いますが、初期であるほど予測はぶれやすくなるため、数回のスプリントをこなした後で見直しが必要になるでしょう。

• プロダクトバックログの作成
  （要求の洗い出し。初期ではおおよそこのような機能が必要であろうというレベル感であり、スプリントをこなす度に詳細化されていく）
• プロダクトバックログアイテムの優先順位づけと工数見積もり
• 1スプリントあたりの期間と、必要なスプリント数の見積もり
• 初回のスプリントの準備

●スプリントプランニング
スプリントプランニングは、スプリント単位で何を開発するべきかを決定するものです。各スプリントが始まる前に開発対象を決めますが、チームの開発力に応じて対象の出し入れを行います。

• スプリントの目標定義、仮説策定
• リソースの見積もりと、開発対象の決定
• 実施するタスクの詳細化（スプリントバックログに追加）

●デイリースクラム
デイリースクラムは、その日の計画づくりです。各タスクの進捗状況や、課題をチームで共有し、スプリントの目標を達成できそうかどうか把握し、優先的に実施すべきタスクを決定していきます。

5. DXプロジェクトを計画通り進めるために

DXの促進に向けてプロジェクト計画を策定したとしても、実行されなければ意味がありません。ここでは、DXプロジェクトを計画通りに進めるためにするべきことについて解説します。

PMOの設置

プロジェクトを計画通りに進めるには、PMO（Project Management Officer）の設置が有効です。PMOとは、プロジェクト管理者と訳され、プロジェクトを円滑に進めることを主な役割とするポジションです。各チームが計画通りに進んでいるかどうかのチェックや、QCDに影響を及ぼす課題が発生した際に原因究明と解決するための支援を行います。（具体的には、課題の対応方針案策定や、関係者間の合意のアレンジメント、解決の担当者決定など）
プロジェクトの規模が大きくなればなるほど、PMOが不在または形骸化していると、課題発見の遅れや、利害関係者の間で意見を着地させることができないなど、重大な遅延やコストの増大を招きかねません。PMOを任命したら、役割と責任を明確にした上でパフォーマンスもチェックしていくことが重要です。

関係者への周知徹底

プロジェクトが始まる前に、関係者に目的や役割分担を説明し、ベクトルを合わせた上で個人が何をするべきか認識してもらうことが重要です。具体的には、キックオフミーティングや、チーム別の説明会開催などが必要になるでしょう。特に、既存業務との兼業メンバーが多い場合には徹底して行わなければなりません。目的やゴールが認識されていないと、既存業務が優先されプロジェクトの対応がおろそかになり、その結果遅延や品質低下を招いたり、改善レベルの意見や部分最適な意見に終始してしまったりするリスクもあります。兼業メンバーのプロジェクトタスクが多くなる場合には、既存業務の負荷を減らしてもらう必要もあり、現場社員の理解が欠かせません。
このように、関係者にどんな目的で、何を・いつまでに・どのような品質で実施してほしいのかを明示することが重要です。