ここから本文です

CMS Watch : プロジェクト管理 /CMS プロジェクトはなぜ予算をオーバーしてしまうのか？

2006年4月 1日 掲載

ジャニス・ボイエ

誰も好き好んでやっているわけじゃない。にもかかわらず、あまりにも多くのITプロジェクトが、予算内で収めるということに失敗している。多くの場合は、約束した成果を達成するために追加の予算が必要になり、それでもなお、最後の最後になって、予算か納期を守るために機能が削られることもしばしばある。

一般に多くのITプロジェクトが、なぜ思っていたよりも高くつくのかについて、これまでにも多くの記事が書かれてきた。例えば、以下のようなものがある。

• "Average IT project still overruns its budget by about 43 percent"（ITプロジェクトは今もなお、予算を平均43％上回っている）（Network Computing）
• Nicholas Carr : Spend Less on IT（ニコラス・カー著：IT経費の削減）( Harvard Business Review )
• "It seems as if government IT projects are doomed to fail"（政府のITプロジェクトは、まるで失敗を運命づけられているかのようだ）（InformationWeek）

共通する理由は何か？　プロジェクト管理の弱さ、プランニングの悪さ、コミュニケーションの不足、技術にばかり目を向けてビジネスプロセスを犠牲にするという間違い、組織的な問題……。こんなくどい説明、きっと耳にタコができるほど聞いたことがあるに違いない。

もちろん、これらの欠点は、CMS プロジェクトにも当てはまる。しかし、この記事では、CMS に特有の予算オーバーの原因について、的を絞っていくことにしよう。その根本にはいくつかの共通した誤解があると、私は思っている。

• 「たかがホームページ／イントラネット／ポータルのプロジェクトじゃないか。そんなに難しいわけないだろう？」
• 「最近うちがやった検索やイメージングのプロジェクトは、スムーズに行ったんだ。これだってうまく行くに違いないさ」
• 「.NET なら、うちには経験がある。.NET ベースの CMS なら、どれだって簡単に導入できるだろう」
• 「この CMS には WYSIWYG の編集機能があるから、コミュニケーション部門の頭の良い連中なら、システムの使い方をトレーニングする必要もないだろう」
• 「社内のアプリケーション開発者なんだから、会社のネットワークやセキュリティインフラについては、よく理解しているはずだ」

複雑さに対する理解不足

今でもまだ、ウェブサイトやイントラネットが特別なものだと思っていないトップレベルのエグゼクティブはたくさんいる。彼らにしてみれば、CMS の導入は、数あるプロジェクトのひとつにすぎない。とにかく着手して、やり遂げて、終わったら次のプロジェクトに進んでいく、というだけのことだ。

企業エグゼクティブの多くは、家庭があって、子供がいることも多い。その子供たちが、自分のウェブサイトやブログを持ち、それがいかに簡単かを嬉しそうに話している。ところが、会社にやって来るコンサルタントや専門家は、結局のところそれほど簡単なことではないと言う。どうもおかしい。理解できない。

CMS を導入するのは、まったくもって簡単なプロセスではない。会社全体にわたって様々な変化を巻き起こし、ほぼすべての部門に影響する。新しい CMS というのは、たいてい、既存のIT環境に統合し、時にはパッケージ販売されているツールにも合わせる必要がある。導入に必要な期間が6ヵ月以内で収まることなど、ほとんどない。

十分に理解されていないことが多い重要な側面は、ほかにもある。例えば、以下のような点だ。

• ハードウェア要件：これは特に、コンテンツ配信（言い換えれば、コンテンツ消費）の環境に当てはまる。こうした環境が、とりわけダイナミックなページ生成には十分な能力を備えていないことが多い。そしてもちろん、コンテンツを作成する人のマシンも、非常に気短なことで知られるエディターたちのために、スピードが必要だ。ほとんどの企業では、最後の最後になってハードウェアを追加したり、よりパワフルなものに買い換えたりするのは、簡単なことではない。さらに、ハードウェアを増やすということは、通常、ソフトウェアのライセンスも買い足さなければならないことを意味する。
• 追加モジュール：当初の契約よりも後になって、追加モジュールが必要になることは、実際にある。CMS ベンダーの営業担当者の明瞭さ、というより不明瞭さは、他のソフト業界の営業担当者と大差ない。契約をまとめるためなら何だってやるし、そのプロジェクトには追加のモジュールが必要だということを言わずに、契約書にサインさせてしまうこともあるかもしれない。そして、これらの追加モジュールが、高価でしかも導入が難しいということもある。
• 継続的なパッチ、アップグレード、変更、改良の必要性：ほとんどすべての CMS では、パッチやアップグレード、変更や改良が、ほぼ絶え間なく必要となる。導入した当初の状態でみんながハッピーになることは、ほとんどない。バージョン2か3でようやくそれが達成できると考えておいたほうがいいだろう。つまりこれは、システムが存在する間ずっと、一貫して導入コストがかかることを意味する。隠れた支出のなかでも最大のもののひとつであり、リソースの巨大な排出口となる可能性もある。
• 幅広いITサポートの必要性：既存のIT環境と統合するということは、コンテンツやアプリケーションを統合するだけでなく、既存のネットワークやセキュリティインフラの中で使っていくことも意味する。これをうまく実践するには、自社の CMS チームに、システム管理者やネットワーク管理者なども含めて、幅広い知識を持ったITの人材が必要になる。特に大企業の場合は、経験豊富なアプリケーション開発者だけでは、ほとんど不可能だろう。
• 分野自体の新しさと複雑さ：コンテンツマネジメント、特にウェブコンテンツマネジメントという分野は、比較的新しく、基本的な問題の解決法ひとつを取っても、様々なアプローチが存在している。ベンダーが提供するテクニックや、確立した運用パターンも、例えば、すでにしばらくにわたって技術規範や組織的な規範が存在しているドキュメントイメージングの分野などと比べると、ずっと多様だ。Enterprise Search Report を読んでいる人なら知っているかもしれないが、検索技術もまた、一見すると複雑だが、実は驚くほど簡単にテストできる分野だ。インストールして、インデックスを付け、検索結果を示すだけでいい。結果は正しいか正しくないかのどちらかしかない。けれども、ある程度の規模の CMS プロジェクトでは、とてもそんなふうにはいかない。

経験不足のプロジェクトチーム

上に挙げた規範やパターンの欠如は、経験不足と一緒になると、さらに悪影響を拡大する。ほとんどの CMS プロジェクトでは、ITから管理畑にいたるプロジェクトチームメンバーのほぼ全員が、このようなツールを実際に導入した経験を持っていない。だからこそ、外部のシステムインテグレータ（SI）が専門知識を貸すことができるのだが、しかし、ここで御社が手を組むSIは、他のベンダーや、御社の使っているベンダーの製品であっても古いバージョンや違うバージョンでしか、経験がないかもしれない。The CMS Report の読者のみなさんならすでにご存じと思うが、小数点以下のバージョン番号が違うマイナーリリースでさえ、大きな違いをもたらすことがある。

こうした背景があるから、私は昔から、次のことを経験則のひとつにしてきた。SIは、同じベンダーの同じバージョンで3回プロジェクトを手がけて初めて、利益を上げられる。新しいバージョンで変更が導入されたり、常々つきあいのある顧客がSIの知らない CMS を選んだりすると、その誠実なSIでさえ、高望みの提案を出してしまい、プロジェクトで赤字を出さないようにするために、変更のリクエストがあるたびに高い料金を請求せざるを得なくなくなる、といったことがしばしば起こる。

これだからこそ、新しいバージョンを導入する最初の何人かの顧客になるということは、高価な提案を招く可能性がある。ニコラス・カー氏は、ITが本当に重要なのかどうかを問いかけているが、これは、競争力という点で何のメリットももたらさないからだ。単純に言って、動きの早いテクノロジーの市場では、一番乗りをするデメリットがある、ということだ。そして、その市場の最たるものが、CMS だ。

導入パートナーの正しい選び方については、私自身も過去に 記事を書いてきたので、今回は、単に次のアドバイスだけに留めておこう。パートナーが過去の顧客から良く評価されていて、少なくとも御社のベンダーの同じ製品を使った経験が3回はあることを確認することだ。

SIの多くは、技術的スキルに非常に長けていて、Microsoft の技術、Java、LAMP のプラットフォームなどに精通している。同じことは、おそらく社内のITチームにも言えるだろう。しかし、だからといって、Microsoft や Java、LAMP ベースの CMS であればどんなものであれ、問題なく導入できるなどと甘く考えてはいけない。残念ながら、現実はそれほど単純ではない。特定のコンテンツタイプやユーザインタフェース、メソッドを使った時に、そのシステムがどのように動作するのか、また、多くの場合は独自の開発環境となっているが、そのなかでどう動作するのかを、開発者はやはり学ばなければならない。

予想外のトレーニング費用

トレーニングは重要だ。社員の多くは、ブラウザ内で単純なタスクをやり遂げることには慣れているかもしれないが、ウェブ上でテキストやイメージを編集するとなると、ほとんど経験がないだろう。マーケティングや広報部門の社員は、紙に対して書くことは慣れていても、オンライン媒体に対してはそうではないかもしれない。ほとんどの CMS が、営業デモで見るよりはるかに複雑だという事実は、この問題をさらに増長する。

片方ではベンダーが、ほとんどトレーニングは必要ないと訴えている。もう一方では、社内の同僚たちが不満を感じている。彼らはできるかぎりのことをしているが、CMS とその機能を完全に理解するのは、非常に困難だ。新しいタスクや機能、そして職務を落ち着くべきところに落ち着かせるには、トレーニングに大きな投資をする必要がある。ベンダーが提供するマニュアルは、ほとんどが事業部門の管理職向けには書かれていないうえ、どちらにしても、CMS はすでにカスタマイズされている。

コンテンツ作成者が慣れて作業スピードを高めるには、時間がかかる。このため、CMS が立ち上がるわずか1週間前になって研修を始めようとするのは、きわめてリスキーだ。トレーニングの必要性が過小評価されていたと気づくには、もう遅い。テクノロジー好きの同僚数人と一緒にゴールインすることはできるかもしれないが、しばらくすると、これらのスタッフたちが、新たなウェブマスターのボトルネックとなってしまうだろう。タスクの一部を分散したいのであれば、効果的な研修セッションを開発し組織化するのに、さらなる予算が必要になる。

組織的な変更は、「トレーニング」できるものではないし、落ち着くまでに時間がかかることを、覚えておいてほしい。また、もうひとつ認識してほしいことがある。それは、トレーニングの最も重要な側面は、特に技術畑でないユーザの場合、決して特定のツールに関係したことではなく、むしろ、ウェブにふさわしいテキストを書くこと、メタデータを使いこなすこと、そして一般に、新しい媒体をどのように使うかを理解することなのだという点だ。

現実的に価値を考える

実際、多くの企業が、CMS プロジェクトの2年目になって、コストが1年目とほぼ同じになりつつあるのを知った時に、激しいショックに直面している。より成熟した市場（EPR や CRM など）の経験が示唆するところによれば、コストの大半は、初期導入の後になって発生する。だから、現実的になることだ。そして、他の企業と経験を交換しあい、不意打ちを食らうのを回避することだ。

この大きなコストを正当化するために、ベンダーや導入パートナーは、TCO （総所有コスト）や ROI （投資収益率）といったメソッドを用いてくるかもしれない。しかし、これらの計算モデルは、単純なものであれ高度なものであれ、すべてのコスト要因を考慮したものではない。予算を正当化する理由としてこれを使った挙げ句に、その予算をオーバーしてしまえば、TCO や ROI にばかり注目していたことが、あらゆる問題のタネとして責められる結果になるかもしれない。

私が勧めたいのは、プロジェクトにおける価値要因に注目することだ。会社にとって、うまく管理されたウェブサイトを持っていることが、どのような価値をもたらすのか？　より良いコンテンツやより良いオンラインカスタマーサービスが、どのような価値になるのか？　価値を高める要因とは何で、それをどうしたら最適化することができるのか？

コストは重要な要因であり、優れた管理職ならば、それを的確に計算して、慎重に抑え込むだろう。しかし、先見の明がある管理職ならば、価値のほうにより幅広い重点を置くはずだ。

ジャニス・ボイエは、Boye IT のマネージングディレクターを務めている。Boye IT は、デンマークにあるコンサルティング企業で、コンテンツマネジメントとポータルを専門としており、どのベンダーにも寄らない中立的な立場をポリシーとしている。ボイエは、前職では、企業ソフトのベンダーで様々な職務とヨーロッパ全域の顧客を担当していた。また、CMS Watch の Enterprise Portals Report も執筆している。

この記事の原文「Why do CMS projects go over budget?」は、2006年2月15日、「cmswatch.com」に掲載された。

トラックバック

このページのトラックバックURL
http://www.designit.jp/mt/mt-tb.cgi/380