「止まった」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つの対策

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。