マルチベンダー案件の作業分担

こんにちは、たごです。

先日書いた「デザイナーとプログラマの共同作業」で比較した二つの案件ですが、どちらも複数の開発会社が関わる仕事でした。しかし作業分担の切り口が違っていたので、今回はマルチベンダーでの作業分担についてふりかえってみようと思います。

作業の分担

マルチベンダー案件とは、読んで字のごとく複数のベンダーが関わる案件ですね。

一社でまるっと案件を請けられると面倒は少ないんですが、開発規模や開発期間、リスク対策、政治的な理由まで含め、様々な理由からシステムの開発に複数の開発会社が絡んでくる事があります。 複数の開発会社で一つのシステムを開発しようとすると、何らかの方法で作業範囲を分担する事になります。

では、それぞれの案件でどういう分担をしていたのかふりかえってみます

ケース１　レイヤーごとの分担

Webアプリならプレゼンテーション層、ビジネスロジック層＆データ層、インフラといったレイヤーごとに横割りで分担するケースです。 この案件では、我々はプレゼンテーション層全般を担当しました。

まず、設計段階でビジネスロジック担当のベンダーから結合部のインターフェース仕様の提示を受け、それを承認してから実装に入るようにしました。

実装途中でUIの都合でビジネスロジックの変更が必要になった場合、担当ベンダーの作業も増えるのでその都度調整が必要になります。 要件を満たすために避けられない場合は対応してもらっていましたが、ホントはビジネスロジック側でやるのがいいんだけど、プレゼンテーション側でもできない事はない様な類いの変更依頼は受け入れられず、メンバーの不興を買ったりしました。

メリット

このケースのメリットとデメリットを考えてみようと思います。 まずはメリットから

• レイヤー間の連携を疎結合にしやすい（というより疎結合するように強制される）。
• 同じレイヤーでの設計・実装に一貫性を持たせやすい。

デメリット

続いてデメリット

• スケジュールが他のベンダーの影響を受けやすいため、比較的時間がかかる。
• 上位のレイヤーほど単独でのテストがしにくい（スタブのメンテが大変だったり）。

ケース２　機能ごとの分担

システムを構成する機能ごとに縦割りで分担するケースです。担当するアプリは上から下まで全レイヤーを担当します ^*1 この案件ではシステムの構成要素のうちWebアプリケーション２本を担当しました。

同じシステムの一部である以上それぞれのベンダーが担当する機能間で全く連携が無いということはあり得ませんが、我々の担当箇所ではDBを介したデータ連携以外は機能間の連携が少なかったので ^*2、DB設計を共有しておけば ^*3あとは自社の開発に集中する事ができました。 開発期間が短かったため、レイヤーごとの分担をしていたらおそらく期間内に終わらなかったでしょう。

メリット

ケース１と同じようにメリット・デメリットを考えてみます。まずはメリット

• 他社担当機能との連携が限定されたため、開発のスピードが上がりやすい。
• 単独で一つのアプリをほぼ完成させられるので、End to Endのテストがしやすい。

デメリット

続いてデメリット

• それぞれの機能で同じ処理の実装をしてしまったり、実装方法がバラバラになったりする。
• 担当外の範囲の理解不足により、仕様変更の影響範囲を見誤りやすい。

どっちが良いの...?

ではどっちのケースが良かったのかということなんですが、ケースバイケース、状況次第ではないでしょうか。 また大雑把に二つのケースに分けましたが、実際の案件は大抵両方のケースが混ざっていて、どちらの傾向が強いかという事になると思います。

それぞれのケースでメリット・デメリットを挙げましたが、どちらも表裏一体です。デメリットをカバーするためには、システム全体を俯瞰して設計・実装・テストをどうするかという視点が欠かせませんし、後々揉めないように責任範囲も明確にする必要があります。また、ベンダー間でのコミュニケーションのしやすさも非常に重要ですね。

どちらにしてもそういった点をおろそかにしてしまうと、どこかで綻びが出てきてしまうんじゃないかと思います。

脚注