今回のアンチパターンはパッケージ適用プロジェクトでの失敗。パッケージ利用の断念による打撃は大きく、巨額のロスコストが発生する。なぜそんな事態に立ち至るか典型例を挙げて徹底解説する。

 今回は、業務パッケージソフトウエアを使ってシステムを開発するプロジェクトに関連するアンチパターンです。ここでは、業務パッケージソフトウエアを単にパッケージと称することにします。図1にパッケージ適用プロジェクトのイメージを示しました。

図1 パッケージを適用したシステム開発

 ロスコストマネジメントの観点からは、パッケージ適用断念による作り直しや、アドオンの大幅な増加を防止することがポイントとなります。こうした現象が起きるとプロジェクトは混乱し、大きなロスコストにつながります。どのようなところに気をつければよいか、アンチパターンを基に見ていきます。

パターン1:パッケージ頼みのコスト低減

 図2に最初のアンチパターンPK001を示しました。タイトルは、「コスト低減要求×合意のないパッケージ適用×アドオン増→パッケージ適用断念」です。パッケージ適用プロジェクトでは、まずパッケージ適用に合意を得られているかどうかがポイントになります。ロスコストに至る経緯は、以下のような流れです。

図2 合意のないパッケージ適用
[画像のクリックで拡大表示]

経緯

 RFP(提案依頼書)の提示を受けて見積もったが、見積額は、顧客の想定範囲から大きく乖離していると感じられた。これでは失注することから、コスト低減策としてパッケージの適用を提案することとした。

 受注に成功し、パッケージについては「業務要件を満たせば手段は不問」ということで適用することになった。しかし基本設計段階のレビューで、利用部門からパッケージの仕様では使えないという評価を受け、パッケージの適用を断念することになった。この結果、スクラッチ開発(一から開発すること)となり大幅なロスコストとなった。

 パッケージが提供する機能は開発する必要がありませんので、コスト低減につながる可能性はあります。思惑通りにコスト低減できるケースもあることは確かですが、このアンチパターンのようにパッケージが使えなくなると、大きなロスコストにつながります。

 まずパッケージによるコスト低減を見込んでいた分、つまり、当初の見積額までコストが膨れ上がることを覚悟しなければなりません。加えて、前提条件が大きく変わることに伴う手戻りが発生しますので、これもロスコストになります。

 こうした状況になると通常、プロジェクトは仕切り直しです。プロジェクトの打ち切りも選択肢に含めて検討しなければなりません。このときに問題になるのが、パッケージ適用に関する合意です。この例のように合意がなされていないと、ITベンダーはペナルティーを支払ってプロジェクトを打ち切るか、多大なロスコストとなることを承知のうえでプロジェクトを進めるかしかなくなります。

 「えっ、そんなことが起こるの?」と感じる読者もいるかもしれませんし、重大なトラブルとなる事例ですので、アンチパターンに加え図3のVTA(バリエーション・ツリー・アナリシス)で補足し解説します(VTAについては2018年4月号参照)。引き合いから内示までの約1カ月間の経緯を記しています。ステークホルダーは顧客、営業、プロジェクトマネジャー、上長の四者を軸にしていますが、プロジェクトマネジャーを中心に見ていきます。比較的経験の浅いプロジェクトマネジャーを想定してください。

図3 パッケージ適用に合意を得られなかった経緯(VTA)
[画像のクリックで拡大表示]

 営業からは「大切な顧客であり、絶対に受注すべき案件。価格については、顧客から示されていないが、受注のためには○○円程度に抑える必要がある」と言われています。これを受け、RFPを基に見積もりましたが、とても目標の価格に収まりません。営業に相談すると「何としても○○円まで持っていってくれ」と依頼され、チームで調査したところ、Z社のパッケージが使えそうなことがわかりました。

 早速、Z社の技術者と会って確認したところ、RFPで要求されている機能のほとんどはサポートされており、アドオンの開発量を含めても設定した価格に収まりそうです。日本では適用実績がないものの海外での適用実績は多く、この分野でメジャーなパッケージであることもわかりました。

 この結果を営業に報告したところ、グローバル化を志向する顧客にとっても魅力的な提案になるはずとのことでパッケージの適用を決定します。再見積もりを行った結果、価格も○○円内に収まり、わずかですが利益も確保できそうです。この内容で上長に報告し、決裁も得られました。

 第4週目で、提案書と見積書をまとめ期限通りに顧客に提出しています。その後のプレゼンテーションでも提案内容、価格とも顧客の感触は良く、顧客内での評価の結果、内示を受け受注に至りました。受注時、顧客からは「業務要件を満たすなら実現手段にはこだわらない。パッケージを使うのは問題なし」との言葉があったので、パッケージ適用については、認められたと思い込んでいました。

 ところが、プロジェクトが始まってからの顧客の評価は、前述の通りです。「業務要件を満たすなら」という条件がクリアできず、パッケージの適用を断念せざるを得なくなりました。

 以上のような経緯ですが、一番の反省事項はパッケージの適合性について詰めが甘く、リスクに対する認識も甘かったことです。この時点では、十分な調査時間もなく、パッケージに関する知識はカタログスペックのみです。もちろん実際の適用経験もありません。フィット&ギャップ分析を行っていませんので、業務についても把握しきれていない状態です。

 せっかく「何とかしたい」と思って発案した解決策も、詰めが甘いと重大な結果を招いてしまいます。受注を優先して、深く吟味することなく決裁を通してしまった上長にも問題があります。

 リスクを見過ごすと、顕在化するのも遅れがちです。どうしようもない段階になってから報告が上がってくれば、スコストは大きくなります。顧客が期待する以上の提案になっていて、かつリスクに気付いていれば、Z社も巻き込んでパッケージを評価し、再度見積もるという案も受け入れられたかもしれません。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら