システム導入プロジェクトには,様々なタスクがある。通常,プロジェクト計画時点やフェーズ開始時点でWBSを作り,実施すべき作業とその担当者を明確化する。このときベンダーは,切り分けられた「顧客が主体となって行うタスク」を顧客に丸投げしてはいけない。

 「顧客主体タスクだから顧客がやるのは当然でしょ。それのどこがいけないの?」

 確かに,そういう見方も一理あるように思える。しかし,自分たちが主担当でなかったとしても,顧客作業を円滑に進めるための「支援」は,多かれ少なかれ発生する。例えば,「総合テストは顧客主体で実施し,ベンダーはそれを支援する」「データ移行は顧客主体で行い,ベンダーはそれを支援する」といった具合だ。

 ここで曲者なのが,顧客主体タスクの裏に隠れている「支援」の内容である。タスク・レベルで担当作業が明確になっているのが理想だが,現実には契約段階で作業内容がブレイクダウンされていないことも多い。一定工数を想定した「支援」でひとくくりになっていることもあるし,そもそも「支援」が考慮されていないこともある。

 漠然とした「支援」という言葉では,互いの期待するタスクの内容が分かりにくい。お互いが都合のよいように解釈して作業を進めた結果,「こんなことまでベンダーが支援するとは考えていなかった」「このぐらいの支援は当然やってくれると思っていた」「そんな工数は想定していない」といった認識のずれが後で発覚して問題になる。そんなケースは少なくない。

「見て見ぬふり」は単なる問題の先送り

 「支援」の中身が不明確で,どちらかが主体であることだけが明らかになっている場合,支援する側の「遠慮」がリスクを招くことがある。

 「こんな進め方ではどこかで作業が破綻するのではないか」
 「一応作業が進んではいるけれど,こんなレベルではだめなのに…」

 心の中で薄々感じていても,それを口に出すのは難しい。「その作業の責任者は自分たちではないし,自分たちもほかのタスクで忙しい。下手に口火を切ったらやぶ蛇になりかねないから,今は黙っておこう」というわけだ。

 日々の仕事に忙殺されている状況では,面倒くさいことはやりたくない,やるとしても後回しにしたいのが人情。しかし,後回しにすることで当座の現実逃避はできるかもしれないが,逃避している間にいつの間にか問題が解決した,などという都合のいいことはまずあり得ない。結局ツケは自分のところに戻ってきてしまう。

 だからと言って,何でもかんでもベンダーが手を出せばいいというわけではない。支援ばかりに手を取られた結果,大幅に工数をオーバーしてしまったり,スケジュールが遅延してしまったりというのでは本末転倒だ。

「支援タスク」に名前を付けよう

 そうならないようにするには,どんな方法が考えられるだろうか。ポイントは「支援」の必要性をきちんと認識し,具体的な作業内容と工数に落とし込むことで,表舞台に引きずり出すということだ。

  • 顧客が主体となって行うのはどんな作業で,どのくらいの工数がかかるか
  • 実施するのは誰か。兼務の場合,実際に割ける工数はどのくらいか
  • 前提となるスキルや準備物は整っているか。整っていないなら,どうやって整えるか
  • 顧客タスクに対して,ベンダー側でどんな作業(=支援タスク)が必要か
  • それには,どのくらいの工数が見込まれるか
  • ベンダー側で並行して実施しているタスクも見据え,その支援が可能か
  •  WBSを作成する際,このような点に留意しながら「主体タスク」と「支援タスク」に,それぞれ具体的な内容を当てはめる。例えば「総合テスト実施」というタスクに対して「テスト環境構築」「データ投入方法のインストラクション」などの支援が必要,というように。そして,その結果を文書化し,顧客とベンダーで共有する。そうすることで,漠然とした「支援タスク」には個別の「名前」が付き,管理可能なものとなるのだ。当然ながら,作業が始まったら実績をトレースし,予定外の作業や工数オーバーなどの問題を早め早めにとらえることで,顧客をリードしていくのも重要なポイントだ。

    顧客からベンダーへの支援も必要

     顧客側からも,同様のことが言える。「ERPパッケージのことはベンダーが一番よく知っているのだから,自分たちは関わらなくてよい」「現行業務と兼任で,プロジェクトの作業に十分な時間が割けない」と,ベンダーに何もかも丸投げしてしまうことは,結局自分たちの首を絞めることにつながる。

     なんとかカットオーバーにこぎつけてほっと一息。ところが,本格的な運用を始めてみると,システムの中身はベンダーにしか分からないブラックボックスとなっていた,ということが分かってから慌てても間に合わない。

     ベンダー主体のタスクだから自分たちは関係ないと無視するのではなく,「ベンダーは一体どんな作業をやっているのか」「それはシステム導入でどういう意味を持つのか」「運用にどのようにかかわるのか」を理解した上で,顧客が支援すべき内容や承認方法を明確にしておく必要がある。

     分かりにくいようであれば,ベンダー側に説明を求めればよい。ベンダーに言われっぱなしにならないためには,必要なトレーニングをあらかじめ受け,顧客自身がパッケージの知識を持っておくことも大切だ。出来上がったシステムを運用していくのは顧客自身なのだから,一時の手間を惜しんでも,良いことは何もない。

    ベンダーと顧客に共通する目標とは

     「ベンダー主体タスク」と「顧客主体タスク」。どちらが不十分でもプロジェクトはうまくいかない。WBSで役割を明確化するのは,責任を誰かに押し付けるためではない。各タスクに対する責任の所在は明らかにしながらも,それぞれが持つ経験やスキルを生かして,タスクの集積であるプロジェクトを成功させること。立場は違っても,ベンダー・顧客共通の目標はそこにあることを忘れてはいけない。