マルチベンダの問題とその解決案 〜現場が感じる不満を添えてお届けします〜

Web業界で働いている方へ質問です。

みなさんは、マルチベンダという言葉をご存知でしょうか。

 

チェーン展開している小売業のレジのシステム（POSレジ、POSシステムなどと呼ばれることが多い）を導入していたり、基幹系システムと連動しているようなサービスを導入している事業会社は、マルチベンダであることが多いです。

 

僕はもともとSI業界でプログラマーとして働いていたことから、Webディレクターである現在もシステム色が強い案件にアサインされるので、クライアントがマルチベンダの事業会社であることがほとんどです。

 

マルチベンダが原因でプロジェクトが上手く立ち行かないと経験を何度もしてきたので、「つらすぎる、、、もう会社を辞めよう」と思ったことが何度もあります。

 

それでも自分自身に「ネガティブな理由で仕事を辞めるのは逃げである」と言い聞かせて何度も踏みとどまり、会社を退職するまでにアサインされたプロジェクトをすべてやり切りました。

 

システムがあまり絡まないようなプロジェクトで成功体験を収め、出世・昇給していくWebディレクターと比べると、経験しなくてもいいような苦労もありました。ですが、振り返ってみると、このつらい経験があるからこそ、今の自分があると思っています。（そう思わないとやってられません。。。涙）

 

そんな僕の苦虫を潰すような重いで耐えた、マルチベンダ案件のプロジェクト体験について紹介したいと思います。

 

マルチベンダとは

僕はマルチベンダを、

 

複数のベンダが一丸となって、クライアントのサービスを請け負うこと（ベンダ間には商流はない）

 

と定義しています。

 

SI会社にいたこともあるのでマルチベンダというワードを好んで使っていますが、改めて言葉の意味を確認しておこうと思います。

 

マルチベンダとは、様々な企業の製品を選んで組み合わせ、システムを構築する手法のことである。

メーカー的統一性にこだわらず部品ごとに製品を選りすぐることで、選択の幅が広がり、うまく組み合わせれば効率のよいシステムを安価に構築することができる。あるいは、システムを利用する環境に適した柔軟なシステムを構築することもできる。いわば製品のいいとこ取りであるが、他面システムの設計者には十分な知識が要求される。また、他企業製品の接続に際して相性の問題などが発生する可能性もあり、運用は難しいとされる。

これに対して、単一企業の製品でシステムを構築することはシングルベンダと呼ばれる。

引用：IT用語辞典　マルチベンダの意味・解説 

 

うん、僕の理解と同じですね。

 

それでは、過酷だったマルチベンダ案件について紹介します。

 

最悪だったマルチベンダ案件

僕は29歳のときに、当時のWeb制作業界では5本の指に入る会社に転職しました。

 

入社して1年が過ぎようたある日、とある大手飲食系事業展開をしているクライアントから、新たに「イントラネットで運用されているサイトのリニューアルの案件がある」という相談を受け、僕がアサインされたことが悪夢の始まりでした。

 

蓋を開けてみると、僕が今まで見たこともないようなマルチベンダ具合でした。

 

まず、大きなところでネットワーク・OS以下はA社、ミドルウェアはB社、POS端末はC社、カスタマーセンターはD社、、、etc

 

さらには、店舗オペレーションや社内事務系のベンダーとして、e-Leaning、商品の在庫管理、勤怠管理、給与の管理、社長のブログ、、、などなど実に20以上のベンダーが入り乱れる状態でした。

 

社名は出せませんが、誰もが知っている主要な大手システムベンダーは一通り入っており、相談を頂いたイントラネットで運用されているサイトはC社が管理しているCMSがベースになっていました。

 

そのため、サイトのリニューアルにはC社との連携することが前提条件でした。

 

サイトのリニューアルプロジェクトがキックオフされ、C社含め全ベンダーとの顔合わせを行い、PMPの資格を有する凄腕のPM集団を前に圧倒されつつ、プロジェクトはスタートしました。

 

商流の壁（ベンダ同士に商流がない）

要件定義を行い、画面設計・ビジュアルデザインを作成するフェーズになり、C社への実装可否確認のをしていく必要がでてきました。

ところが、クライアントは「技術的なことは聞いてもわからないから」ということで、「C社に直接話して問題があれば報告する」ということになり、打ち合わせに臨みました。

 

打ち合わせ開始前から、ちょっと感じの悪い空気が流れていましたが、構わずスタートしました。

一通り説明を終えた後に、C社から

 

そもそもクライアント様から依頼いただいていないです。

また商流がないので質問にもお答えできません。

 

とピシャリと言われ、完全に険悪な状態となりMTGは終了しました。

 

MTG後、エレベータの中で僕を含めたメンバーは意気消沈。。。

多くの場合、小声で「お疲れ様でした。あの件だけどさぁ〜」といった形で軽いラップアップが行われますが、その時は誰も一言も発言しませんでした。。。

 

とりあえずクライアントに状況を報告するか、ということで伝えたところ、

 

あ、ごめん。C社に言うの忘れてた。

 

と一言。

 

「えー、大丈夫かよこの会社。。。」という心の声が口から漏れかけましたが、そこはオトナの対応を行い、改めてクライアントを交えてC社とのMTGををセットすることになりました。

 

クライアントのPMワークが機能していない

クライアントは少数精鋭で仕事をされいたこともあり、主要なプロパーの仕事をサポートしているベンダーが常駐でアサインされていました。

 

サポートと言うと聞こえはいいですが、平たく言うと開発スキルを有していながら雑務もこなすという、クライアントからしていれば使い勝手が良いベンダーでした。このベンダーだけは比較的温和なメンバーで構成されており、僕も懇意にさせていただいていました。

 

そのサポート業務もこなすベンダーに、C社とのMTGでの出来事を話したところ、「クライアントはベンダーに丸投げするスタイルで、細かい調整含めて”ベンダー同士でよろしくやっておいて”というコミュニケーションが当たり前である」ということを教えてくれました。

 

確かに、思い当たるフシはあります。

クライアントからは常駐もしていない僕らに対してプロジェクターのレンタルや、MTG時のメンバー調整、及び会議室の予約といった事務作業もすべて外注に丸投げするという徹底ぶりでした。

（いくらクライアントと言えども、クライアント先の会議スペースを取ることまで依頼することはあまり聞かないかと思います）

 

_{ちなみに、僕らはそのような作業が発生することは見込んでいませんので、やればやるほど稼働が取られる状態。追加請求しづらいタスクだし、また断りづらいタスクでもあるので完全に泣き寝入りでした。}

 

また、そのようなクライアントなので当然ベンダーからも嫌われており、「降りかかる火の粉はすべて払わなければならぬ」状態なので、クライアント抜きのMTGを行うとかなり殺伐とする、などなどいろいろな予備知識を与えてくれました。

 

この入れ知恵（！？）により、このクライアントのプロジェクトの立ち回り方を見直し、次回のアクションプランを計画することができるようになりました。

 

ベンダーの受発注の徹底

仕切り直しのMTGで、設計フェーズで考えた画面設計書を説明しながら、表示要件や機能要件など技術的な視点で実装可能かどうか、追加開発が必要な場合のコストとその対応時期など検討の余地はあるのか、などC社へ伝えるとその場での返答は「持ち帰り確認します」で、実際に返事が来たのは2週間後、、、、

 

う〜ん、

この調子では計画してたスケジュール感では無理だ。。。

このタイムラグについても課題だけどどう対処しよう。。。

と途方にくれたことを覚えています。

 

なぜ時間がかかっていたかというと、C社は影響確認タスクを都度請負にしていたので、毎回見積もりして「クライアントと合意してからでないと作業はしない」というフローになっていました。

 

Web業界はスピード重視なこともあり「要件や仕様がFIXしてない状態で見積もって、口頭合意だけで作業着手」なんてことが当たり前だと思っていましたので、この考え方がそもそもマッチしていませんでした。

 

結局、スケジュールはC社に合わせて伸ばしましたが、それを理由にスケジュールの遅延と追加コストが認められないと言われ、QCDSの考えのもと、延長するたびにスコープを調整することでプロジェクトの計画変更を余儀なくされました。

 

メンバーで徹夜をして一生懸命考えた提案が、こんなつまらないことで徐々にスコープアウトされ、ほとんどが実現しない状況が見えてくると、もはやお金の問題ではありません。

 

当時は、まだ若かったことので「こんなに無駄なプロジェクトがあっていいのか！？」といつも憤りを感じていました。

 

_{余談ですが、以前にWebディレクターの役割や定義にこだわっている人へで、僕はWebディレクター/プロジェクトマネージャーを他の人がやらないことを全部やる人として定義しましたが、そこで触れた商流が複雑な案件というのが、実はマルチベンダでした。（もっと言うと、会社を辞めてフリーランス(個人事業主)を選択したキッカケ・理由で紹介した最悪なクライアントでもあります）}

 

最終的に、納品対象は「イントラネットサイトのトップページの1画面をリニューアル」だけとなり、それだけで当初計画していた3ヶ月のスケジュールを費やしました。

 

僕だけでなく、一緒に稼働してくれたメンバーにも申し訳無いと思うプロジェクトとなりました。

ちなみに上司は、1ページの成果物でこれだけの売上を上げた！として喜んでました。（金が入れば問題なしというその考えに反発を覚えたことは言うまでもありません）

 

マルチベンダの問題点とその解決案

先の実体験から、問題点をまとめると以下のとおりです。

• ベンダ同士に商流がないこと
• クライアント側のPMワーク（ベンダを取りまとめ）が機能していない
• 受発注の徹底による作業内容・範囲の明確化

 

それぞれの問題点について、解決案を紹介していきます。

 

なお、「そもそもクライアントが各ベンダに嫌われている」という事象は、自身で気づき是正していく内容なので、ここでら除外しています。

 

商流の壁（ベンダ同士に商流がない）

商流を通せば解決するのですが、大手システムベンダーが社員200人規模のWeb制作会社のアンダーにつくことは、与信や中間管理コスト（販売管理費・外注管理費など）を考えると想像できません。

 

よって、対応方法としては「クライアントからベンダーに依頼をしてもらう」ということになります。

 

ただし、それは「クライアント側のPMワークが機能していること」が条件となります。

 

クライアント側のPMワークが機能していない

クライアント側のPMワークが機能していないと、ベンダの取りまとめがなされません。

 

だからといって、丸投げスタイルのクライアントに「PMワークをちゃんとやってください」などと依頼しても「バカにしてるのか？」となるのでおすすめできません。

 

どうしたもんかなぁ〜ということで、僕が最初に理想として考えていたこととしては、別ベンダーに作業して貰う必要がある場合、クライアントからベンダーに作業依頼を行い、それを受けたベンダーが内容を確認し、必要に応じで僕らと細かいすり合わせを行い、見積もりを出して正式にGO、というステップにすることだと考えていました

 

口で言えばとっくにやってると思いますので、根本的に駄目なのです。

 

では「どうしたらいいのか」なのですが、まずクライアントを分析し、やってくれることとやってくれないことを明確にしました。

 

すると、やってくれるのは「判断」と「必要そうなベンダーの引き合わせ」のみだとわかりました。。。

 

要するに社長（もしくは横柄な上司）ですね。

 

これがわかるだけで、取りうる対応も明確になります。

 

僕が取った手法は、

 

ベンダ同士が連携し、それぞれ自社の作業が発生する場合、当該ベンダーが依頼の経緯と作業内容をクライアントに報告し、その分の作業を正式に請け負えるような状況にする

 

です。

 

クライアントに「あのベンダにこの作業をさせてください」という依頼をするよりも、各ベンダーから「あのベンダーからこういう依頼がありましたので、弊社で○○という作業が必要です。この分は、追加△△万円で請け負いますがよいですか」というやり取りをされれば、クライアント的には判断すれば良いだけなので話が早いです。

 

もちろん、最初はうまく行きませんでしたが、クライアントはとにかくMTGに参加させ、依頼先のベンダの前でYesかNoかだけ判断できるような提案資料にしていたので、相手ベンダーの仕事の依頼がちゃんとなされる状況を常に作り続けました。

 

例えば、

• □□の作業は、A社の製品に改修をいただかないとお客様が作りたい成果物を作ることができません。よって、A社には対応の可否の判断と、可能な場合の工数とスケジュールをお客様にご提示ください。
• △△の作業は、A社製品の領域になりますので改修をお願いします。ただし、△△’という案であれば、弊社で対応が可能です。△△と△△’とどちらで実装すべきかを判断するためにも、A社にてそれぞれの対応工数とスケジュールをお客様に提示をお願いします。

といった感じで依頼をしました。

 

「あのベンダーが対応してくれなかったら納期が遅れている」という状況を作り上げるように心がけ、常に先手先手を打ち続けることで、ちょっとづつ実現できました。

 

とはいえ、僕の担当するプロジェクトが無事納品できるようにすることが目的なので、ベンダー同士の関係が良好になったわけではなく、あくまでしぶしぶという感じです。

 

また、商流の壁を超えることはできませんが、結果として「クライアントの前で、ベンダーからベンダーに依頼をする」ということが実現できたので、こちらも解消しました。

 

受発注の徹底による作業内容・範囲の明確化

そもそもこの問題は、「作業が発生するベンダー側が作業・工数を見積もる」というタスクがスケジュールから漏れていたことが原因です。

 

よって、プロジェクト計画に上記タスクを組み込むことで解消されます。

 

_{結果論ですが、スケジュールに組み込まれていたところで、「影響調査の都度見積もり・都度合意」に時間がかかるという事実は変えられませんが、事前に打ち手を考えておくことは可能です。}

 

ですが、プロジェクトは計画通りに進まないのはみなさんご周知の通りかと思いますが、必ず、追加作業や仕様変更が発生します。

 

その場合に、やはり都度の工数見積りが発生します。

でもご安心ください。そんなときに打ち手があります。

 

実はベンダーは自社製品のイニシャル（初期構築）だけではなく、その後の運用も請け負っているため、月額の運用コストをクライアントに請求しています。

 

そのため、少々の追加作業であれば、この月額の運用コストの中で対応することが可能です。

（もちろん、ベンダーからクライアントに対して「この作業は運用の作業として実施させていただきます」という合意がなされることが前提ですが、都度営業が介在して見積もり合意のためのコミュニケーションを考えると圧倒的に短い期間で済みます）

 

改修内容が軽微であることが前提ですが、スケジュールへの影響を最小限にすることが可能です。

最後に

Web制作会社、いわゆる受託会社であれば、インフラ部分やPOSシステムなどをベンダーに丸投げしている場合や、マルチベンダ体制で、事業展開しているクライアントの案件に出会うこと多いかと思います。

 

その場合、クライアントの対応次第では「手を切る」「請け負わない」という選択をしたほうが得策な場合もあります。

 

当時はサラリーマンだったので会社の判断に従うほかありませんでしたが、フリーランスとなった今、そのような仕事はもちろんお断りします。

 

もちろん、受託側としては請負うことで売上をあげたいわけですが、マルチベンダ案件は上記の体験談の通り、クライアントや他ベンダーの調整事項、つまりコミュニケーションなどの中間管理タスクが見積もれないので結構なリスクです。

 

おそらく皆さんの会社でも見積もりには「ディレクションフィー」や「進行管理費」といった名目で載せている利益分があると思いますが、それではまかなえないくらいの被害を被ることが予想されます。

 

実タスクだけではなく見えない工数も含めて「そういう案件が得意である」という人であれば話は別ですが、、、

 

もし、マルチベンダ案件でお悩みの方がいましたら「請け負わない」という選択肢があることも勘案いただければ幸いです。