ベンダーには何を求めるか？
山田は、ベンダー選定にあたり、田中部長から「プロジェクトはベンダーに任せて、ベンダー管理をすれば良い」と言われた。
しかし、山田には若かりし頃のベンダーにいた時の経験から、あの時のような仕事では、期待に応えられる結果が出せない不安になっていた。ベンダーにいた時は、納期に間にあわせるために連日の徹夜での突貫工事であった。やりきった感はあるが、お客様に期待した通りの開発ができたと思えなかったからである。要件定義を担当していた先輩に言われたことを設計・開発していたが、仕様変更が相次いだ。どうも、いろいろとお客様から指摘されていたようである。
振り返ってみると、お客様から言われたことを並べていただけの要件定義で、議事録と変わらず、ヒアリングの羅列でしかなかった。ビジネスは線であり広がりがあることを無視していたようである。
このような経験から、自分たちで納得するシステム化になるように、ベンダーには任せられないと思っていた。
改めて田中部長に相談してみたが「無理だ。ベンダーに任せろ！」と言われてしまった。
そこで、こっそりとコンサルタントの小林に相談してみた。
D社小林「田中部長の言われる背景には、皆さんには、通常業務があり、時間を割いてプロジェクトに参加している。情報システム部含めて全社員がプロジェクト以外の業務がある。だから、片手間ではプロジェクトを推進するのは厳しいので、ベンダーに任せることを指示していると思いますよ。しかしながら、山田さんの意見も理解します。失敗プロジェクトの多くは、山田さんの経験されたことと一致するからです。ベンダーは、コンサルティングをすると売り込むが、実際はシステムエンジニアが担当するので、コンサルティングというよりは、何を作るかヒアリングをまとめるだけである。ヒアリングが結果に矛盾があろうが、業務が非効率になろうが、疑問を感じない。全てのベンダーが、ダメというわけではなく、正直言えば、担当する人の当たり外れで決まるのが、現実です。」
プロジェクトにおけるベンダーの役割を考える
山田は、小林の話に納得しているもののベンダー選定をどうして良いか困っていた。
D社小林「山田さん。具体的にどうすれば良いか考察してみましょう。プロジェクトを成功させるには『人数ではなく、必要なスキルを持ったチームであることが重要です。』わかり易くいえば、プログラミングに強い人だけのチームでは、要件定義ができないので、プロジェクトは成功しませんよね。まずは、情報システム部の社員スキルを確認しましょう。」
- 田中部長は大手SI企業でプロジェクトマネジャー
- 山田も中堅のSI企業でプロジェクトマネジャー兼システムエンジニア
- 他の情報システム部部員は小さな開発会社で大手SI企業の下請けで設計と開発を担当
D社小林「情報システム部のメンバーの経験はわかりました。では、このプロジェクトを成功させるために何が不足しているか考えてみましょう。」
山田「小林さん。プロジェクトには、どのようなスキルが必要ですか？」
山田と小林で話し合った結果、上流含めた開発以外は、社員とコンサルタントを主軸とし、ベンダーには開発を主軸に期待することにした。
山田「PMOには、小林さんにも参画してほしいのですが、いいですか？」
D社小林「良いですよ。ただ、わたし一人では人数が足りないので、丁度わたしの会社に良い人財がいますので、参画させます。」
山田「でも、予算が・・・」
D社小林「開発ベンダーの予算から捻出してはどうでしょうか？ もともとベンダーに依頼する予定の上流工程の予算があるので、この費用を使えると思いますよ。」
山田「そうですね。同じお金を払うなら、適材な企業・人財に投資をした方が期待できます。」
D社小林「田中部長には、ベンダー丸投げにならないように注意するように、うまく伝えておきます。」
- プロジェクトマネジャーを補佐するPMO・ベンダーコントロールは、D社も参画
- 課題整理・ASIS、TOBEの可視化は、社員、プロジェクトメンバー、D社が担当
- 開発のための要件定義以降は、ベンダーが担当
ベンダーにはベンダーの価値がある。企業がベンダーに求めている価値とベンダーが得意とする領域がマッチしているとよいが、必ずしも成功するとは限らない。
情報システム部が、広域に渡るITスキルとビジネスとの親和性が高い設計をすることで、コストを抑えベストなシステムを作ることができる。理想かもしれないが、全従業員で稼いだお金は大切にしなければならず、無駄なコストは申し訳が立たない。できる限りでも理想を求めても良いかもしれない。悪い言い方をすれば、丸投げは失敗します。使うのは、皆さんであり、ベンダーではありませんからね。
