1. はじめに：コーポレートITからビジネスIT、そしてDXへ
事業会社においてもデジタルトランスフォーメーション（DX）は一般化しつつある。社内にもDXの専門組織が設置され、社外にも様々なSaaS利用の機会やIaaSやPaaSなどのクラウド基盤に関するサービスも当たり前のことになりつつある状況である。多くの事業会社においてITシステムといえば会計システムや生産管理システム、人事システムなど業務効率化の手段としての活用が主であり、ITシステム開発といえば情報システム部門が担当する「コーポレート支援型IT」が主であった。このコーポレート支援型でのITシステム開発は、業務要件からシステム要件に落とし込むという特徴からウォーターフォール型のプロジェクトマネジメントが採用されることが多かった。
近年はビジネス部門が直接的にITを活用する「ビジネス支援型IT」、そしてITシステム自体で収益を獲得する「DX」へとITシステムの位置づけは変化してきている。ただITシステムを構築するためのプロジェクトマネジメントは、従来のコーポレート支援型ITをベースとしたウォーターフォール型のプロジェクトマネジメントのままであることが多いと考える。ウォーターフォール開発自体はITシステム開発の基本であり否定するものではない。どのようなITシステム開発にも適用可能である。しかし、DX領域においてはプロジェクトの特徴を把握したうえでプロジェクトを推進しなければ、プロジェクト自体が破綻してしまう可能性が高いだろう。そのため、本稿では「DXプロジェクト」に着目し、プロジェクトマネジメントの観点でDXビジネスの成功に向けた提言をする。
図1：事業会社におけるITの位置づけ
2. DXプロジェクトの特徴
2.1. DXプロジェクトの定義
DXに取り組む事業会社の狙いの一つに、新たなビジネスを創出し新たな収益の獲得をすることがある。
本稿においては、このような取り組みを進めるプロジェクト（以下、DXプロジェクト）に対して、プロジェクトの特徴と発生しうる課題と対策について述べる。
DXプロジェクトは、従来情報システム部門が主導してきた会計、生産管理、人事などの業務を効率化するためのコーポレート支援型プロジェクトとは位置づけが異なる。例えば、コーポレート支援型のプロジェクトは業務を効率化させることが目的となっており、業務とビジネスには従属の関係があると考えられるためである。一方で、DXプロジェクトにおいてはコーポレート支援型とは異なる特徴を有しており、その特徴は以下に示す事項である。本稿におけるDXプロジェクトの定義は以下のようなプロジェクトを対象とする。
■ 新たな収益を得るためのビジネス創出が目的
■ 営業系部門、経営企画系部門、新規事業部門など情報システム部門以外が主導
■ SaaS利用や社外システムとの連携など社外リソースも活用したビジネススキーム
（具体例）
- 業界横断型プラットフォームサービス
- フィンテックサービス
- リボン型ビジネスサービス など
2.2. スコープ面におけるDXプロジェクトの特徴
DXプロジェクトの特徴の一つは「スコープ」である。DXプロジェクトのスコープはビジネスとITシステムの両方を含むという点である。コーポレート支援型のプロジェクトでは、”業務を効率化するためのITシステムを構築する”ということが主目的になっているため、業務とシステムは従属した関係となっている。一方で、DXプロジェクトはビジネスとITシステムを一体のものとして検討する必要があるという点で、コーポレート支援型プロジェクトとは異なる。DXプロジェクトは「ビジネスとITシステムの不可分性が高い」という点が特徴である。
また、DXプロジェクトにおけるITシステムについても一からスクラッチでITシステムを構築することは少なく、SaaSの利用や社内の基幹システムとの連携、協業する事業会社等が所有するITシステムなどとの連携が前提として考えられていることがある。そうなると、DXプロジェクトで構築するITシステムは必然的に連携が多い仕組みとなってしまうという特徴も併せ持っている。
2.3. 体制面におけるDXプロジェクトの特徴
DXプロジェクトのもう一つの特徴は体制面にもある。DXプロジェクトは新規ビジネスの創出が目的となっていることから、プロジェクトを主導するのは営業系部門、経営企画系部門、新規事業系部門のような情報システム部門以外が主導している。情報システム部門からも一部の要員がDXプロジェクトに参画することもあるが、プロジェクトの特性からプロジェクト責任者、プロジェクトマネージャーなどのプロジェクト全体の意思決定にかかるポジションには情報システム部門以外の主導組織のメンバがプロジェクトを主導する立場を担うことが一般的である。また、コーポレート支援型が中心である情報システム部門はコストが抑えられる部門でもあり、必要最小限の要員で社内システムの保守運用を担っていることからも、DXプロジェクトに専念できる人材を割り当てることは難しいという事情を抱えている事業会社も少なくない。
また、DXプロジェクトはビジネス自体の検討がスコープに含まれることもあり、プロジェクト体制が大きくなりやすいという特徴も持っている。具体的には、ビジネス系としては売上予測、市場調査などを担う事業計画担当、知財、法務、社外提携、社内手続きなどを担うリーガル＆オペレーション担当、サービスのプロモーションや利用者動向を分析するマーケティング担当などのメンバが主要メンバとして参画することもDXプロジェクトの特徴である。これに加えてITシステム開発にかかるメンバも社内外を含めて参画することになるため、プロジェクトの体制が大きくなるという特徴がある。
図2：DXプロジェクトに関与するステークホルダの全体像
2.4. 工程面におけるDXプロジェクトの特徴
DXプロジェクトは、ビジネススキームとITシステムを一体として検討するというスコープ面の特徴があるため、工程面においても上流工程での検討事項が多くなるという特徴がある。加えて体制面の特徴であるステークホルダの多さから、上流工程の検討期間が長引くという特徴もある。コーポレート支援型プロジェクトであれば、業務要件については業務側で検討して業務要件定義として取りまとめ、情報システム部門がそれを受け取ってシステム要件定義を取りまとめた上で、業務側の承認を経て要件定義工程を完了させていく流れが一般的である。しかしながらDXプロジェクトにおいては、ITシステム側から新たな技術やソリューションが起点となってビジネス自体の検討が開始されることもある。つまり、ビジネス側の検討後にITシステムの検討をするという、コーポレート支援型プロジェクトが想定しているプロセスとは異なる特徴がある。開発ガイドラインが整備されている場合であっても、DXプロジェクトの特性を加味しているものは少ないだろう。
DXプロジェクトでは、ITシステムの開発を進める前の工程の中でビジネス側とITシステム側の双方による検討を行うことが必要となるが、このような工程は従来のウォーターフォール型開発では設置されておらず、実施するには工夫が必要となる。
このような特徴からDXプロジェクトの上流工程は難易度が高くなる。DXプロジェクトの特徴を留意せずに、コーポレート支援型プロジェクトと同様の上流工程で推進した場合に発生しやすい課題と、その課題がプロジェクトに及ぼす影響を次項で整理していく。
3. DXプロジェクトの上流工程に起因するリスクと顕在化した場合のプロジェクト影響
3.1. 上流工程での検討漏れが下流工程で判明する
DXプロジェクトは新たなビジネスを創出することが目的である。DXの特性から必ずしもビジネス側としての検討が起点となるわけではなく、ITシステム側から新技術や新たなソリューションの提案があり、それを起点にビジネスの検討が進むということもある。そのような場合は、ITシステム側の提案を受けたビジネス側がビジネス面の検討を行い、その内容をITシステム側とすり合わせ、これを繰り返して検討をしていくことが一般的である。DXビジネスの検討は、このようにビジネスとITシステムが一体となって検討を行うことがある。
ビジネスの検討は正解があるものではないため、すぐに決まるということは少ない。明確な決定権者がいれば決定までに時間はかからないかもしれないが、体制的にステークホルダが多く権限も分散されていることがあるため決定までに時間がかかる。一方で、サービス開始日やプレスリリース日などが決まってしまうという時間的な制約が設けられると、期限から逆算する形でプロジェクトが立ち上げられ、各工程に費やすことができる期間も決まってくる。このような状態でビジネスとITシステムの検討を開始した場合、DXプロジェクトでは検討が不十分なままに業務要件定義とシステム要件定義を完了せざるを得なくなる。本来はここで決定されたゴールに向かってプロジェクトを進めていくのであるが、DXプロジェクトにおいては、この時点ではあくまで「仮置きのゴール」に過ぎないことがある。
このような場合、多くの重要論点が十分に検討されないまま次工程に進んでいくことになるが、ITシステムの開発はこの時点での決定事項をベースに開発計画を立案し、ITシステム開発を進めていくことになる。しかしながら、ビジネス側の要求や検討が十分にできていないことから、主にビジネス側から変更や追加の要望が頻発することになる。ITシステム側はその都度工数の再算出やスケジュールの変更などの対応をすることになり、プロジェクトが不安定になるという影響が生じることがある。
このように、従来の上流工程で定義されている業務要件定義からシステム要件定義に落とし込んでいくプロセスは、DXプロジェクトの実態とは適合しない部分が生じてくる。
3.2. 計画の精度が低く自転車操業的なプロジェクト運営となる
上記で述べた通り、DXプロジェクトではゴール設定の難易度が高く、ゴールの検討自体に多くの工数が費やされることが想定される。また、ステークホルダが多いことから計画の調整にも非常に多くの工数がかかる。そのうえ、ビジネス系部門が主導するためシステム開発プロジェクトとして一般的に必要となるプロジェクト計画（システム全体図、体制図、スケジュール、運営ルール）の立案が十分にされておらず、多くの論点が未検討、整合性が取れていないなど計画としての精度が低く、実行力の低い計画となるリスクも生じやすい。
このように、計画として未完成というような状態であったとしても、サービス開始日を目指してプロジェクトを進めざるを得ない状況である場合にはプロジェクトが進んでいくが、計画の精度が低いためプロジェクトが進んでいく中で、目先のタスクを考えながらタスクを実行していくという自転車操業的なプロジェクト推進となってしまうことも想定される。
＜想定される事象（例）＞
① 完了予定日が現実的でなく、完了予定日にタスクが完了せずに後続工程の開始が遅延する
② 実施しなければならないタスクが漏れていて、追加の工数と期間が急遽発生する
③ チーム間の前後関係の整合性が取れておらず、スケジュールの組み換えが必要となる
DXプロジェクトには上述した通り、ゴール設定とプロジェクト全体を通した計画の立案がおろそかになるというリスクが生じやすい。そのためDXプロジェクトには、これらを確実に実行するための工程を明確に定義し、実行していくことが必要である。
4. DXプロジェクトにおける新たな上流工程設置の提言
4.1. 最上流工程「DXプロジェクト定義」工程の概要
上記で述べた、上流工程で発生が想定される課題とプロジェクトへの影響を顕在化させないようにするために、これまで述べてきた工程よりも、さらに上流となる工程を設置することが有用である。最上流工程で実施すべきことは以下の２点である。
1) スコープを明確にしステークホルダを特定する（＝スコープ＆ステークホルダ定義）
DXプロジェクトでは達成すべきゴールとして、何を達成するのか、何を作るのかという点がコンセプトレベルにとどまってしまい、プロジェクトとして何を作るのかという点が明確になっていないことがプロジェクトのリスクとなる。またDXプロジェクトの特徴である多様なステークホルダを適切に巻き込めていないこともプロジェクトのリスクとなる。
DXプロジェクトの最初の工程はスコープの明確化とステークホルダの特定を行う工程が必要である。具体的には図3の「スコープ＆ステークホルダ定義」に示した、①～⑧の項目・観点を定義していく必要がある。まずはITシステムにとどまらずDXビジネス全体のコアコンセプト・狙い・範囲を明確にする（①～③）。次にこれらに関わるステークホルダを特定し（④）、その役割・責任範囲を明確にしていく（⑤）。なお、この段階では担当者レベルでの明確化は必要なく、組織・チームレベルで十分である。ここまでを明確にしたうえで要求事項として機能/非機能レベルへの具体化・投資対効果・KPIの設定などDXビジネスとして達成すべき事項の定義を行う必要がある（⑥～⑧）。
2) ビジネス＆ITシステムの実行可能な計画の策定（＝プロジェクト計画定義）
スコープ＆ステークホルダ定義を経てDXプロジェクトとしてのゴールを明確にした後、DXプロジェクトを確実に遂行していくためのプロジェクト計画を定義する必要がある。
DXプロジェクトはビジネス関連のタスクもスコープに含まれるため、ITシステムはプロジェクト計画の一部に過ぎない点に留意する必要がある。DXプロジェクトはビジネスとITシステムが一体となって創り上げ行くプロジェクトである。このようなプロジェクトのタスクは、ビジネスとITシステムがそれぞれ単独で遂行するタスクと、ビジネスとITシステムが相互連携して遂行するタスクに大分される。プロジェクト計画として定義すべき事項は図3の「プロジェクト計画定義」に示す通りであるが（①～⑧）、その前提としてビジネスとITシステムの役割分担と整合性を確保した計画とする必要性が高い点に留意する必要がある。
図3：DXプロジェクトの最上流工程の概要
4.2. 最上流工程「DXプロジェクト定義」工程設置のポイント
DXプロジェクト定義工程を進めるに際しては、DXプロジェクト定義工程自体を一つのプロジェクトと見立てて推進することが必要である。そのため、DXプロジェクト定義工程におけるプロジェクトマネージャーを設置することが求められる。DXプロジェクト定義工程はDXビジネスのゴールを決定し、ゴールを実現するための計画を立案することにあるため、ビジネス・システム両面の知見があることが求められる。そしてもう一つ重要なスキルはプロジェクトマネジメントへの知見を有することである。つまりDXプロジェクト定義工程を成功させるには、ビジネス、システム、そしてプロジェクトマネジメントの３つの要素が必要となる。しかし、これらの３要素を満たす人材は潤沢にはいないため、実際には企画/ビジネスの専門家、システム開発の専門家、そしてプロジェクトマネジメントの専門家によって推進されるべきである。DXプロジェクト定義工程を推進していくためのモデル体制や具体的事例、成功ポイントについては別稿にて記述することとする。
5. おわりに：DXプロジェクトの新たなマネジメントスキーム構築に向けて
プロジェクトマネジメントの観点で考えると、DXプロジェクトの難易度は非常に高い。SaaSに代表されるサービスが存在し、クラウド基盤サービスの利用も一般化している中で、ITシステムを用いたDXビジネスは非常に身近なものになったと考えられる。しかし、それはビジネスとITシステムの距離が近づいただけのことであり、DXを構築していくプロジェクトマネジメントの観点ではゴール設定やステークホルダの多さなどマネジメントの難易度が高まっているのである。DXプロジェクトマネジメントは、まだまだSaaSやクラウド基盤サービスのように汎用化されているものはなく、プロジェクトの特徴を踏まえたうえでオーダーメードでのプロジェクトマネジメントを行う必要があるのが現状である。
本稿は、DXプロジェクトを成功に近づけるために必要な提言の一つとして、最上流工程を設置すべきであるという提言を行った。ただ、DXプロジェクトを成功させるためのプロジェクトマネジメントの要点はこれにとどまるものではない。DXプロジェクトの成功のために新たなプロジェクトマネジメントスキームが必要であり、今後も継続的にDXプロジェクトの成功に向けて多面的な提言をしていきたい。DXが加速していく中、DXプロジェクトが一つでも多く成功することに寄与できれば幸いである。