マルチベンダー体制による大規模サイト開発プロジェクトを成功に導くポイント（1）

例えばWebサイトでの会員制ニュース配信サービスを新規構築するような場合にシステムに求められる機能としては

• コンテンツ管理　・・・記事データの作成、公開、アプリ配信など
• 会員・契約管理　・・・会員登録、属性管理、契約情報管理
• 課金・決済管理　・・・継続課金、オンライン決済、支払情報管理
• 分析・レポート　・・・ユーザー行動履歴、売上レポート、セグメント
• マーケティング　・・・DM、レコメンド、パーソナライズ
• クラウド基盤　　・・・IaaS/PaaS

大規模サイト開発が得意なSierであれば、これらのテクノロジー要素をカバーできる可能性は高いですが、限定領域ではあっても、非常に強力なソリューションを提供できる開発ベンダーも存在します。 むやみに要素を分離する事は得策ではありませんが、複数の開発ベンダーが得意領域を持ち寄り各領域でのノウハウ・実績を活用できるメリットがあります。

近年はオープンアーキテクチャが採用される事が多いため、過去に比べると程度は低いものですが、採用するパッケージやサービスによっては、いわゆる「ベンダーロックイン」となる可能性も考えられます。

基幹系システムと違って、Webサイトはユーザニーズやトレンドの変化が激しくシステム構築後にもエンハンス対応などが必要であり、特定の開発ベンダーに対する依存度が高くなってしまう事で、追加開発時のスピード感や柔軟性がかけてしまう可能性があります。

複数の開発ベンダーが得意領域を分担する事で、ベンダー依存のリスクを低減する事ができます。

また、近年はIT技術者の需要過多の状況にあり、大規模開発案件になればなるほど要員リソースの確保がプロジェクト成功の鍵と言えます。

複数の開発ベンダーを採用する事により、要員リソースを幅広く確保する事が期待できます。

ベンダー各社がそれぞれお客様との契約関係にあり、ベンダー間での商流がない場合は、プロジェクト全体の推進は、お客様自らが責任をもって実施して頂く必要があります。

各ベンダーは、お客様のご依頼（RFP）基づく、開発スコープと開発計画を前提とした契約の範囲の中で責任をもってプロジェクトを遂行しますが、仮に、特定のベンダーが開発スコープを満たさない場合や当初計画を履行できない場合に、プロジェクト全体や他ベンダーに対する影響が発生する場合は、そのリスクはお客様が負う事になります。

プロジェクト全体の立ち上げ・計画・実行の各フェーズにおいて、お客様が主体となり複数ベンダーの取りまとめ・コントロールを行って頂く事が重要です。

マルチベンダー体制を採用する場合、サブシステム単位（例えば、コンテンツ管理領域と会員・契約管理領域など）で担当を分離する事が考えられます。

システム全体としてはサブシステムが連携する事で、最終的なビジネス要件やプロジェクト目標が達成されます。

そのため、サブシステム境界を事前に明確化した上で、システム間連携の接点となる「インターフェース」には十分に注意を払う必要があります。 一般的なシステム開発工程としては、要求分析・システム化要件定義・システム設計・外部設計といった上流工程が存在しますが、複数ベンダーでサブシステムを分担する場合は、これらの上流工程で認識齟齬が発生しないように、ベンダー間のコミュニケーション強化と、サブシステム境界、インターフェース仕様の明確化と成文化を行っていく必要があります。