「止まった」DXプロジェクトを再び動かすには「立ち止まること」が必要：現場から見た「DXの真相」（4）

プロジェクトが頓挫する。そういった事態はなるべく避けたいが、もしなってしまったらどうリカバリーすればいいのか。プロジェクトが頓挫する原因とその回避方法について解説する。

» 2020年01月27日 05時00分公開

[渡邉信之，株式会社ゴルフダイジェスト・オンライン]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　これまで、DX（デジタルトランスフォーメーション）プロジェクトを立ち上げるまでの注意点や勘所について解説してきました。第4回では、DXのプロジェクトを立ち上げたのはいいが「早くも頓挫してしまいそう」「既に頓挫している」「思ったような結果が出ていない」といったDXプロジェクトのトラブル回避方法を解説します。

前半戦の山場は「RFP」にある

　プロジェクトが頓挫する原因は、多かれ少なかれ「想定したコストを超過した」ことに集約されると著者は考えます。コストが超過することでスケジュールも遅延し、当初立てた計画は一瞬で破綻してしまうからです。著者の経験では、コスト超過の起きる原因の多くがプロジェクト立ち上げの前段階、ベンダーによる概算見積もりにあります。

　DXプロジェクトに限らずプロジェクトの立ち上げ時には、全体の予算感を計るために開発ベンダーに概算見積もりを依頼することがあります。見積もりを出すためには、ベンダーが対象のシステムについて、「何を（何の機能を）」「どのくらいのレベルで作るか」といった、システムの「広さと深さ」を理解している必要があります。

　広さと深さを知るためには、要件や要望が見積もり可能なレベルで細分化され、理解できる状態になったドキュメントや指示がなければなりません。ご存じの通り、こうした要件や要望をまとめたものを一般的に「RFP」（提案依頼書）といいます。ですので本来であれば、RFPがない状態で正式でも概算でも見積もりはできません。

RFPに潜む「1つ目のワナ」

　RFPは見積もり以外にも活躍します。RFPを作成することで企業側の目指すゴールが明確になり、要件に対する企業内の合意形成がとれた状態になります。コンペ形式でのベンダー選定にも役立つでしょう。ただ、このRFP作成の作業そのものをベンダーに丸投げをしている企業があるようです。ここに「1つ目のワナ」があります。

　お手伝いをしてもらうこと自体はいいのですが、少なくとも企業側として目的やゴール設定、対象範囲、スケジュールの指示をすべきです。RFPは事業会社の魂そのものですから、その意思を他人にゆだねると当然、後のプロセスにおいてさまざまな不具合が出てきます。

　とはいえ、要件が明確ではなく曖昧な表現が多く残る、いわば「レベルの低いRFP」を作ってしまうのも問題です。レベルの低いRFPしか作れないということは、企業内でのゴールが合意形成されておらず、ステークホルダー間でゴールの期待値がバラバラになっているということです。

　こうしたRFPでベンダーに見積もりを依頼すると、そもそもRFPに回答できない、回答するまでに何度もヒアリング会を開かなければならない、といった事態を招き、プロジェクト自体が立ち上がらない可能性もあります。

企業とベンダーの利害関係から発生する「2つ目のワナ」

　ベンダーに見積もりを依頼する際には、企業内できちんと合意された要件や要望を記載した「レベルの高いRFP」が必要です。ただ、それだけではまだリスクがあります。

　一般的に、RFPに対する企業からの問い合わせに対し、ベンダーは無償で対応します。企業側は「無償だから、できるだけ調整してもらおう」という発想になり、ベンダー側は「できるだけ簡潔に、手早く終わらせたい」という発想になります。そうなれば企業とベンダーの関係性や利害がいつまでもすり合わず、双方にとって良くない状態になります。これが「2つ目のワナ」です。

　こうした状態では、ベンダーはできるだけ顧客の希望に沿った、仕事を受注しやすい調整をしようとします。つまり、顧客のコスト（予算感）とスケジュールから逆算した見積もりを作成します。企業側からすると、想定通りの規模感で見積もりやプロジェクト計画が提案されるので、一瞬完璧なプロジェクトが立ち上がったように見えます。

　しかし、それはベンダーが企業に合わせているわけですから当然です。実際のプロジェクトが始まれば、ちょっとした想定違いで簡単にスケジュールが超過し、当初の計画から乖離（かいり）してしまうでしょう。

　プロジェクトの頓挫はそもそもはRFPが不完全なことに起因していますが、それに対して受注ありきで調整を進めるベンダー側にも責任があります。予測不可能な作業量があることは最初からリスクとして考えるべきです。そして、そのリスクを顧客（企業側）に説明することはベンダーの責務であると著者は考えます。

　ただ、実際はそんなことをすれば受注が危ぶまれるので、リスクには目をつぶり、「お任せください」「社運をかけて支援します」などの精神論でプロジェクトをスタートさせてしまうのです。

頓挫したプロジェクトの立て直しで取るべき4つの対策

　このような原因でコスト、スケジュールを超過して頓挫してしまったプロジェクトの対処方法は4つです。

1．超過したコスト、スケジュールを飲み込む

2．スコープを削り、プロジェクト計画を修正する

3．RFPを作り直す

4．プロジェクトを停止する

超過したコスト、スケジュールを飲み込む

　この方法には資金力とプロジェクトに関するコミットメント（決定的な理由）が求められます。例えば「事業継続に大きく影響し何が何でも成功しなければ生き残れない」といった理由が必要です。あらかじめリスクを見越したコンテンジェンシープラン（緊急時対応計画）を作成している場合はそちらに切り替えます。

スコープを削り、プロジェクト計画を修正する

　スコープ範囲を絞り、予算とスケジュールをプロジェクト計画内に収めます。もし、余計な機能やサービスがスコープとして入っていて、なくても影響が軽微な場合は積極的に削るべきです。ただ、大抵の場合、計画のズレが大きく、多少削ったくらいでは追い付かないのが実情でしょう。あまりお勧めできない対処方法です。

RFPを作り直す

　頓挫する理由の大半は「RFPの不完全性」にあります。ですので、基本となる考え方（グランドデザイン）を作り直し、RFPの完成度を上げることが頓挫したプロジェクトを正常化させる一番の処方箋となります。

　グランドデザインの作り直しには、プロジェクト憲章とスコープ定義（参考記事：DXプロジェクトの意思は誰が握る？　「体制図を制するものがプロジェクトを制す」理由）が必要です。これらの「プロジェクトの目的と範囲」をブレークダウンし、RFPにまとめます。この作業を実施するためには既存機能や既存業務の理解や可視化が必要でしょう。そうです、この「既存業務や機能の整理」こそがプロジェクト期間中において最も重要な作業となります。

　この作業は原則として他人任せにできません。「既存機能や業務が俗人化、ブラックボックス化していて、まとめられない……」といった悩みは理解できますが、その場合はあるべき姿の業務フローや機能について文書化します。つまり「現状が何であるか（As Is）」ではなく「これからどうあるべきか（To Be）」で分析します。

プロジェクトを停止する

　この方法について多くの説明は不要でしょう。残念ですが傷が浅いうちに撤退することもオプションとして検討すべきです。

コラム：システムの作り直しに「既存機能の理解」は必要なのか

　システムを作り直すようなプロジェクトは、なぜか既存ベンダーやエンジニアを外し、全てを新たに任せられるベンダーを探しがちです。特に担当者や上層部が変わると、こういった「心機一転企画」が増えるのではないでしょうか。

　こうしたプロジェクトは多かれ少なかれ「既存機能の理解」というプロセスを踏みます。新たに開発を依頼されたベンダーは、企業の要望をかなえるために、既存のシステムや業務内容を丁寧にヒアリング、解析して、仕様を決めていきます。この作業はもちろん有償ですし、基本的に時間がかかりますので企業は膨大なコストを支払うことになります。

　ただ、もともとのゴールを思い出してみてください。「既存機能や業務をそのまま構築し直すこと」ではないはずです。戦略や戦術を変えつつ、DXを実現することがゴールです。抜本的な変革が求められる以上、既存業務や機能はほどほどにして、あるべき姿を定義することに時間を使うべきです。

　とはいえ「そんな余力はない」という企業もあるでしょう。「あるべき姿の定義」は難易度が高く、経験も知識も豊富な人材やチームにしかできない作業だからです。別の言い方をすれば、この作業ができるかできないかが、その開発ベンダーと付き合いを続けるべきかどうかを判断する基準になります。もし既存業務の理解だけで終始してしまうベンダーであれば、プロジェクトのゴールに到達することが難しいため、できるだけ早く次を探した方がいいでしょう。著者の経験上、ベンダーが提示する要件定義のタスクに「ヒアリング」「既存機能の理解」あたりが多く存在する場合は注意が必要です。

　企業が求めているのは、ゴールに到達するための戦略や戦術の変更を中心とした業務、システム、事業構造の変更です。そのため「企業の将来像を描ける人材」がベンダー側にいるかどうかがDXプロジェクトの成功可否の鍵を握るといえます。ベンダーの視点でいえば、このような人材を豊富に持つことができれば、ベンダーとして価値を上げ、同時に顧客からの信頼も得られる。結果として、長期的なパートナーシップを作ることができるでしょう。

後半戦で気を付けるべき「テストフェーズへの時間配分」

　ここまでは主に要件定義の前後で発生するトラブルについて解説しました。次に問題が発覚しがちなのはテストフェーズです。それぞれの機能やサービスでは稼働するものの、本番に近い環境で運用テストを行うとまったく動かない、機能しないといった問題です。最終段階である顧客を交えたテストのフェーズで発生することが多く、対応には注意が必要です。

　特にこの問題は、複数の部門やサービスにまたがるケースやサイロ型の組織の複数組織がまたがったプロジェクトに多く発生する印象があります。

　プロジェクトのマスタースケジュールでよく見掛けるのが、前半戦（グランドデザインや要件定義）で時間を使ってしまい、後半戦のスケジュールを「気合」で短縮したものです。テストフェーズに十分な時間が取れず、テストフェーズのタスク同士が重なってしまう、といった明らかに一つの問題で破綻してしまうようなスケジュールには注意が必要です。

　それでも問題が発生してしまったら回避する方法は2つです。

1．スケジュールを見直す（同時にコストも調整する）

2．部分的リリースを検討する

　1は分かりやすく、最もスタンダードな対応方法になるかと思います。

　2の部分リリースは、最初からある程度検討した状態でプロジェクトをスタートしていないと難しい部分があります。完成した部分だけをリリースできる構造にしておけば、幾つかのサブシステムやサービスリリースは遅延するかもしれませんが、被害を最小化できます。ただし、細分化しすぎた構造はテストを複雑にします。Aだけが遅延したケース、AとBだけ遅延したケースといったパターンの網羅性を担保することがテストに求められます。

プロジェクトはそもそもリスクを内包している

　頓挫するプロジェクトの多くは、プロジェクト立ち上げ前にリスクを内包しています。既に走り始めたプロジェクトを止めるのは非常に勇気がいる決断でもありますが、立ち止まる回数が多ければ多いほど、プロジェクトのリスクを減らせるといえます。現場のメンバーは意外と敏感にリスクを察知しています。にもかかわらずプロジェクトマネジャーには伝わらないことも多いでしょう。立ち止まるポイントの設計も含め、全体計画の再設計を検討してください。

　その際はRFPの重要性にも着眼し、「将来頓挫するリスクを最小化したグランドデザイン」を企業の主導で策定することがプロジェクトを成功に導く第一歩となります。頓挫したプロジェクトも立て直しすれば成功に導けます。今なら間に合うかもしれません。ぜひ一度プロジェクトを総点検し、プロジェクトを成功させてください。

　最終回の第5回では、DXプロジェクトの本質的な目的について解説します。

筆者紹介

渡邉信之（わたなべのぶゆき）

株式会社ゴルフダイジェスト・オンライン

20年間IT業界に身を置き、ITベンダー時代はプログラマーからSE、プロジェクトマネジャーに従事。2016年に今のゴルフダイジェスト・オンライン（以下GDO）に入社。GDOではIT責任者として、多くの大規模プロジェクトの陣頭指揮を執る。現在は自ら新規事業を立ち上げ、タイにおけるゴルフ場予約サービスの事業責任者を務める。

DXも台無しにしかねない日本企業の「ソーシング問題」――「内製化が難しい」なら、どう戦うか？
デジタルトランスフォーメーション（DX）の潮流が高まる中、社会全体で「イノベーション」や「スピード」といった要素が注目されている。だが、いくら「新たな価値」を生み出したところで、それがビジネス／サービスである以上、信頼に足る品質を担保していなければ意味がない。特に内製が難しいトラディショナルな企業にとっては、一般的なIT活用でもDXにおける価値創出でも、社外の開発・運用パートナーと組むことが不可欠となる。そうした中でも、今のスタンスのままで本当に「ビジネス価値」を生み出すことができるのだろうか？
システム開発プロジェクトに存在する複数種類の契約形態
受託、派遣、準委任？？？――IT業界解説シリーズ、第3弾はシステム開発プロジェクトに混在する複数の「契約形態」を解説します。
IoTプロジェクトを成功に導くための、先行企業からの教訓
IoTで一定の成果を収める企業が増えている。だが、一般的には環境が未成熟なこともあり、取り組みは容易ではない。ここでは、先行企業からのIoTにおける教訓をお届けする。