SHIFT　ITコンサルティング部の久野(きゅうの)です。
SHIFTの中堅コンサルタントのお悩み相談を通して、PMOサービスで起こりがちな課題について考える当シリーズも第3回を迎えました。今回はマルチベンダー体制のシステム開発について皆さんと一緒に考えたいと思います。

<第1回のおさらい>
第１回　大規模プロジェクトの立ち上げに挑戦
　　ポイント１： スピードと品質の両方の要求に応える
　　ポイント2： お客様のビジネス視点で意思決定を促す
　　ポイント3： ビジネスの目標と一致したプロジェクトの目標を設定する

<第2回のおさらい>
第2回　本当に必要な品質保証を考える
　　ポイント１： 全行程を通じた品質保証計画を策定する
　　ポイント2： サービス提供対象に応じたサービス品質を作りこむ

（登場人物）
中堅くん・・・小中規模のプロジェクトをいくつか経験してプロジェクト管理に自信をつけてきたSHIFTの若手コンサルタントです。

先輩さん・・・七難八苦を経て、海千山千のPM業務をこなしてきたSHIFTのベテランコンサルタントです。

第3回　マルチベンダー体制のシステム開発に四苦八苦

中堅くん：先輩さん、大変です！助けてください！
先輩さん：落ち着けよ、中堅くん、どうした？
中堅くん：それぞれのチームがバラバラで全く協力してくれなくて。体制図を見てもらっていいですか？

（プロジェクトの体制図）

先輩さん：ほう。見事に分権独立だね。

【ベンダー間でスケジュールにずれがあることが発覚】

中堅くん：先輩さんのおかげで品質保証計画もできて、大日程もできました。でも、開発プロセスはベンダーごとに違っていて、パッケージチームはプロトタイピング、IF開発チームはウォーターフォール型、画面開発チームはAgileといった具合です。それで、中日程はベンダー毎に作ってもらいました。
大日程に合わせれば問題は起こらないと考えたのですが、いざ設計フェーズが始まったら、IF開発チームから問題の指摘があがってきて、チーム間でスケジュールが合っていないことが分かってきたんです。

先輩さん：その問題って、具体的には？

中堅くん：IF開発チームが、DB設計のために画面開発チームに項目定義の打合せを申し込んだところ、画面開発チームからは「Agile開発なので項目を決めるのはまだまだ先だ」と言われたそうで、決められる時期すら回答が無いそうです。
パッケージチームには受け渡す連携ファイルの仕様を決める打合せを申し込んだそうなのですが、こちらもプロトタイピングの評価が出るまでは決められないと言われたそうです。「全てが待ちになっていて何も進められない！何もできないまま進捗が遅れてしまう！」と、PMOに苦情が来ています。

先輩さん：なるほどね。まず、確認したいんだけど、それぞれのチームは大日程に合わせて中日程を作っているのかい？なるほどね。

中堅くん：どのチームも合わせて作ったと言っていますが、開発プロセスが違うので本当に合っているのか分かりません。

先輩さん：開発工程で使われる用語というのはベンダー毎に定義が違っているものだよ。「基本設計」と「詳細設計」の切り分けとか、「結合テスト」と「総合テスト」もベンダー毎に定義が違う。

中堅くん：そうなんですか？IT業界で共通の言葉だと思っていました。

先輩さん：同じ言葉でも具体的な作業内容は会社によって違うんだよ。「基本設計」という同じ言葉を双方が違う意味で使っていたら会話は成り立たないよね。マルチベンダー体制でシステム開発を行う場合には、プロジェクトで使用する用語を定義することから始める必要がある。

中堅くん：そうなんですね。

先輩さん：その上で中堅くんの相談に対する答だが、チーム間で決めないといけない項目は明確になっているのかな？まず確認項目を洗い出して、次にそれぞれの項目を決める時期を定義していく。これは設計フェーズだけではなくて、テストフェーズなど他の工程にも当てはまることだ。そのためには、各ベンダーの開発プロセスを理解しないといけない。
また、時期を決めるにあたってはプロジェクト全体のクリティカルパスを見極める必要がある。全てのチームの言い分を聞いていたら、どんどん先延ばしになってしまうからね。調整の結果によっては、中日程の見直しや、場合によっては大日程の見直しを行わないといけないから、全チームの協力が必要だ。

中堅くん：大変ですね！

先輩さん：大変だけど、まだ始まったばかりだから早く手を打てば大きな問題にならない。問題が発覚するのが早くて幸運だったと思った方がいいよ。あとになればなるほど、影響が大きくなる。中堅くんも知っているように、SHIFTはDAAE（※）の概念に基づくAgile開発と従来型の開発プロセスを組み合わせたハイブリッド型のシステム開発も提唱しているけど、ハイブリッド型の技術ポイントの1つは「フロント(DAAE)と基幹系(QCD)との連携の仕組みの担保」なんだ。参考にするといい。

（※筆者註　SHIFTの提唱するシステム開発の概念。Design（デザイン） Agility（迅速性） Assembly（組み合わせ） Economic Quality（経済品質）の略。）

中堅くん：分かりました。

【ベンダー間で設計に漏れがあることが発覚】

中堅くん：もう１つ困っていることがあるんです。今日から業務部門の設計レビューが始まったんですが、設計の抜け漏れがあちこちで見つかっています。

先輩さん：具体的には？

中堅くん：例えば、IF開発チームが開発したインタフェースからパッケージへのデータ連携で、マスタチェックをどちらも行っていなかったんです。

先輩さん：業務部門に見てもらう前に内部レビューはやった？
中堅くん：はい。IF開発チームの内部レビューも「問題なし」、パッケージチームの内部レビューも「問題なし」でした。

先輩さん：PMOチームのレビューは？

中堅くん：IF開発チームの内部レビュー結果とパッケージチームの内部レビュー結果をチェックしていました。

先輩さん：なるほどね。シングルベンダーでシステム開発を行う体制であればそれで良かったかもしれないが、マルチベンダー体制の場合はそれでは不充分だ。

中堅くん：詳しく教えてもらえますか。

先輩さん：シングルベンダーであれば、サブシステム内→サブシステム間とチェックすれば良かったのが、マルチベンダーの場合は、それに加えてベンダー間の境界線もチェックのポイントに追加する必要がある。

中堅くん：ベンダー間ですか？

先輩さん：まず事前に、各ベンダーの担当範囲を定義する際に、ベンダー間の境界を明確にしておくことが重要だ。
その上で、PMOチームはベンダー間の境界をまたぐインタフェース仕様を重点的にチェックする。必ず不具合が発生するところだからね。
それに加えて、ベンダー間で関連のある機能に関しては、仕様の抜け漏れや認識の齟齬が無いことをチェックしておいた方がいい。それには、双方の担当者に仕様の読み合わせをしてもらうと相互チェックが働くから、不具合を見つけやすい。PMOだけで仕様をチェックするのは難しいからね。

中堅くん：おっしゃる通りですね。

先輩さん：マルチベンダー体制の場合は、PMOチームの役割も今まで以上に重要なんだ。進捗や成果物の管理だけではなく、システム全体の整合性をチェックする役割も担うことになる。PMOチームにはシステム全体を俯瞰的にとらえる力も求められる。
今までにも話してきたけど、プロジェクト全体としてお客様のビジネス視点の目的と目標を達成できるかどうかがプロジェクトの成否を決める。それを監視するのもPMOチームの役割だ。特定のベンダー単独では保証できないからね。

中堅くん：責任重大ですね。
先輩さん：むろん中堅くん1人だけではできないことだから、PMOもチームとして品質を保証する体制にする必要がある。
SHIFTは、特定のベンダーに依存しない第三者の視点で見ることができるし品質保証のスキルや経験もあるから、マルチベンダー体制のシステム開発案件のPMOとして適任なんだ。

【境界線上の問題は、誰の問題か？】

先輩さん ：「ベンダー間の境界を明確にして境界を跨ぐインタフェース仕様を重点的にチェックする」という話をしてきたけれど、実はそれだけではまだ充分ではない。

中堅くん：どういうことですか？

先輩さん ：もちろん、送り手がチェックするか受け取り手がチェックするか、ルールを決めておかないといけない。けれども、どちらの責任範囲か切り分けられないようなベンダー間の境界線上に発生する問題も多いんだよ。

中堅くん：境界線上の問題ですか？その場合はどうすればいいですか？

先輩さん ：どちらかに対応してもらうことになる。

中堅くん：やってもらえますか？

先輩さん ：どちらも「やらされたら損」と思っていたら難しいよね。

中堅くん：そうですよね。

先輩さん ：でも考えてほしいんだけど、プロジェクトを成功させたいという思いは皆同じだ。誰一人としてプロジェクトを失敗させたいと思っている人間はいない。そうじゃないかい？

中堅くん：それはそうです。

先輩さん ：ベンダー間の利害関係を超えて運命共同体としてワンチームになれるかどうかが、プロジェクトの成否を分ける。所属する会社が違っていても、ベクトルを合わせられればワンチームになれるはずだ。

中堅くん：そんな簡単にできるでしょうか？

先輩さん ：そのためには、普段からのコミュニケーションが大事なんだ。困った時だけ助けを求めても誰も手を指し伸ばしてはくれないよね。相手のことをよく理解して協力し合える関係を築くことができていれば、問題が起こった時に助けを求めてもノーとは言われない。一緒に解決策を考えてくれるはずだ。

中堅くん：プロジェクトの成功に向けて一致団結できる関係を作っていかないといけないんですね。よく分かりました。

【困った時には】

中堅くん：実はもう１つ困っていることがあるんです。各ベンダーから独立した構成管理の担当者を置かないといけないという話が出ています。リリース作業は各ベンダーで実施してもらう想定だったのですが、リリースのスケジュール調整だとか、複数環境のバージョン管理は、特定のベンダーの開発者には引き受けてもらえないんです。構成管理のルールを厳しく守らせるためにも、ベンダーから独立していた方が良いという意見もあります。でも、ベンダーから独立した人を探すのって、どうしたらいいのか分からなくて。

先輩さん：なるほどね。そういうことなら、SHIFTの要員を提案できると思うよ。

中堅くん：えっ！そうなんですか？

先輩さん：SHIFTには多様な人材がいるからね。マルチベンダー体制で、どのベンダーも担当しないようなハザマに落ちた作業を拾うこともできる。もちろん計画段階で必要な要員を計画しておくことが重要だけど、計画外の作業が必要になった場合には解決策を提案することができるんだよ。
構成管理であればシステム環境を管理できるアーキテクト、操作マニュアルのレビューにはドキュメントのインスペクションの経験者、運用設計にはシステム運用の経験者、移行推進、ジョブ設計、ジョブ監視、パフォーマンスチューニングなど、One SHIFTでサポートすることができる。

中堅くん：すごい！それ本当ですか？

先輩さん：本当さ。俺が担当した案件で実際にあったことだよ。

中堅くん：それに全部応えたのですか？

先輩さん：もちろん。SHIFTは、優秀な人材を集めて、お客様が必要としているサービスを提供する会社だからね。必ずプロジェクトを成功に導くことができる。

中堅くん：先輩さん、ありがとうございました。これで安心してプロジェクトを進められます！

今回はマルチベンダー体制のシステム開発で必ず起こる課題と、その解決策について考えてきました。

ポイント１：
各ベンダーの開発プロセスの整合性を取り、プロセス品質を保証する
プロジェクト全体のクリティカルパスを見極めて、各ベンダーの開発プロセスをすり合わせる。

ポイント2：
第三者視点で設計の抜け漏れをチェックして、プロダクト品質を保証する
ベンダー間の境界を明確にして、境界に跨る機能を重点的にチェックする。

ポイント３：
ベンダー間の利害関係を超えて、ワンチームの関係を築く
普段からのコミュニケーションによって、協力し合える関係を作る。

このシリーズは今回が最終回です。
最後まで読んでいただき、ありがとうございました！
少しでも皆さまの参考になれば幸いです。

お客様のビジネスニーズに応え、ビジネスの目標を達成するため、品質保証を強みとするSHIFTでは、あらゆるアプローチでの品質保証のサービスを提供しています。ぜひともSHIFTをご活用ください。

<ご参考>
マルチベンダー体制での基幹システム刷新プロジェクトにてSHIFTに期待した事とその成果
https://service.shiftinc.jp/case/yaoko/

▶前の記事
《第2回》中堅ITコンサルタント奮闘記｜本当に必要な品質保証を考える
《第1回》中堅ITコンサルタント奮闘記｜大規模プロジェクトの立ち上げに挑戦

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/