現場から見た「DXの真相」(4):「止まった」DXプロジェクトを再び動かすには「立ち止まること」が必要プロジェクトが頓挫する。いった事態はなるべく避けたいが、もしなってしまったらどうリカバリーすればいいのか。プロジェクトが頓挫する原因とその回避方法について解説する。});この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。これまで、DX(デジタルトランスフォーメーション)プロジェクトを立ち上げるまでの注意点や勘所について解説してきました。第4回では、DXのプロジェクトを立ち上げたのはいいが「早くも頓挫してしまいそう」「既に頓挫している」「思ったような結果が出ていない」といったDXプロジェクトのトラブル回避方法を解説します。前半戦の山場は「RFP」にあるプロジェクトが頓挫する原因は、多かれ少なかれ「想定したコストを超過した」ことに集約されると著者は考えます。コストが超過することでスケジュールも遅延し、当初立てた計画は一瞬で破綻してしまうからです。著者の経験では、コスト超過の起きる原因の多くがプロジェクト立ち上げの前段階、ベンダーによる概算見積もりにあります。DXプロジェクトに限らずプロジェクトの立ち上げ時には、全体の予算感を計るために開発ベンダーに概算見積もりを依頼することがあります。見積もりを出すためには、ベンダーが対象のシステムについて、「何を(何の機能を)」「どのくらいのレベルで作るか」といった、システムの「広さと深さ」を理解している必要があります。広さと深さを知るためには、要件や要望が見積もり可能なレベルで細分化され、理解できる状態になったドキュメントや指示がなければなりません。ご存じの通り、こうした要件や要望をまとめたものを一般的に「RFP」(提案依頼書)といいます。本来であれば、RFPがない状態で正式でも概算でも見積もりはできません。RFPに潜む「1つ目のワナ」RFPは見積もり以外にも活躍します。RFPを作成することで企業側の目指すゴールが明確になり、要件に対する企業内の合意形成がとれた状態になります。コンペ形式でのベンダー選定にも役立つでしょう。このRFP作成の作業そのものをベンダーに丸投げをしている企業があるようです。ここに「1つ目のワナ」があります。お手伝いをしてもらうこと自体はいいのですが、少なくとも企業側として目的やゴール設定、対象範囲、スケジュールの指示をすべきです。RFPは事業会社の魂そのものですから、その意思を他人にゆだねると当然、後のプロセスにおいてさまざまな不具合が出てきます。いえ、要件が明確ではなく曖昧な表現が多く残る、いわば「レベルの低いRFP」を作ってしまうのも問題です。レベルの低いRFPしか作れないということは、企業内でのゴールが合意形成されておらず、ステークホルダー間でゴールの期待値がバラバラになっているということです。したRFPでベンダーに見積もりを依頼すると、そもそもRFPに回答できない、回答するまでに何度もヒアリング会を開かなければならない、といった事態を招き、プロジェクト自体が立ち上がらない可能性もあります。企業とベンダーの利害関係から発生する「2つ目のワナ」ベンダーに見積もりを依頼する際には、企業内できちんと合意された要件や要望を記載した「レベルの高いRFP」が必要です。それだけではまだリスクがあります。一般的に、RFPに対する企業からの問い合わせに対し、ベンダーは無償で対応します。企業側は「無償だから、できるだけ調整してもらおう」という発想になり、ベンダー側は「できるだけ簡潔に、手早く終わらせたい」という発想になります。なれば企業とベンダーの関係性や利害がいつまでもすり合わず、双方にとって良くない状態になります。これが「2つ目のワナ」です。した状態では、ベンダーはできるだけ顧客の希望に沿った、仕事を受注しやすい調整をしようとします。顧客のコスト(予算感)とスケジュールから逆算した見積もりを作成します。企業側からすると、想定通りの規模感で見積もりやプロジェクト計画が提案されるので、一瞬完璧なプロジェクトが立ち上がったように見えます。それはベンダーが企業に合わせているわけですから当然です。実際のプロジェクトが始まれば、ちょっとした想定違いで簡単にスケジュールが超過し、当初の計画から乖離(かいり)してしまうでしょう。プロジェクトの頓挫はそもそもはRFPが不完全なことに起因していますが、それに対して受注ありきで調整を進めるベンダー側にも責任があります。予測不可能な作業量があることは最初からリスクとして考えるべきです。そのリスクを顧客(企業側)に説明することはベンダーの責務であると著者は考えます。実際はそんなことをすれば受注が危ぶまれるので、リスクには目をつぶり、「お任せください」「社運をかけて支援します」などの精神論でプロジェクトをスタートさせてしまうのです。設定を有効にする必要があります。難しい」なら、どう戦うか?デジタルトランスフォーメーション(DX)の潮流が高まる中、社会全体で「イノベーション」や「スピード」といった要素が注目されている。いくら「新たな価値」を生み出したところで、それがビジネス/サービスである以上、信頼に足る品質を担保していなければ意味がない。内製が難しいトラディショナルな企業にとっては、一般的なIT活用でもDXにおける価値創出でも、社外の開発・運用パートナーと組むことが不可欠となる。???——IT業界解説シリーズ、第3弾はシステム開発プロジェクトに混在する複数の「契約形態」を解説します。IoTプロジェクトを成功に導くための、先行企業からの教訓IoTで一定の成果を収める企業が増えている。一般的には環境が未成熟なこともあり、取り組みは容易ではない。ここでは、先行企業からのIoTにおける教訓をお届けする。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。