見出し画像
Photo by ia19200102

マルチベンダーの問題は契約の問題

ikemo

はじめに

先日、マルチベンダーについてのツイート(今はツイートと言わないんでしたっけ)が盛り上がっていました。

自分は前職では結構別のベンダーと直接、あるいは間接的にやり取りをする機会がありました。

その上でやりにくいと思ったのですが、やりにくい原因は「マルチベンダー」そのものではないと考えています。

マルチベンダーは責任の押し付け合い

ググって見つけた記事ですが、この記事がマルチベンダーの問題点を端的に表しています。

この記事のこの記述です。ゼロ回答です。自分も同様の経験が何度もあります。

そもそもクライアント様から依頼いただいていないです。
また商流がないので質問にもお答えできません。

製品についての質問なら普通に質問して、普通に回答をもらえます。問題は複数のベンダーが1つのプロジェクトに関わっているときです。

自分の一番酷かった経験を書きます。10年前くらいの話です。

壊れたAPIを無理矢理直した話

ここは技術的な話だけなので、分からない人は適当に読み飛ばしてください。

ベンダーがとあるAPIを提供していました。自分は当時Javaを使っていて、jarファイルで提供されていました。そのAPIの仕様が酷いものでした。

  • JavaScriptを返すAPI(JSONではない)

  • しかもHTMLコメント付き(<!-- -->)

せめてコメントがなければ<script>で返せるのですが、HTMLに埋め込むしかありませんでした。

そしてこのAPIにバグがありました。

よくよく調べてみると、そのJavaScriptを返すAPIはオンライン通信をしておらず、なんとJavaScriptの雛形がjarファイルに含まれていました。APIでは雛形の一部の値を計算して書き換えるだけのようです。その値を返すAPIを提供すればいいのに。

このJavaScriptファイルを直接変更できなくもないのですが、さすがに自分の担当領域でないと判断して、ベンダーに「このJavaScriptファイルを直して欲しい」と言いました。

しかし「直せない」の一点張りでした。

相手は検討する気もさらさらない感じだったのと、こちら側の開発者は自分一人だったため、APIから返ってきたJavaScriptをバックエンドで文字列置換で修正しました。その場限りの汚い改修です。

相手ベンダーの対応に呆れました。相手ベンダーは大手SIerでしたが、ただの手配師で、何も出来ない人たちだと判断しました。

この件以来、相手ベンダーが話が通じない所だと判断したら回答に期待せず、「ゼロ回答」になることを前提に代替案を最初から考えています。

ベンダー間の協力が必要なシステム連携

この件で自分がその場限りの汚い改修をしたのは理由があります。このプロジェクトはPoC(概念実証)で、書いていたのは使い捨てのコードだったからです。普通のプロダクト開発なら絶対やりません。

現代のシステムでは、システム間の連携は標準的な約束(プロトコル)で作られます。例えばTCP/IPを使い、HTTPSでAPIを提供し、JSONで返します。

実際にはもっと細かい仕様がたくさんあり、技術的なものもあれば、運用に関わるものもあります。システム間の取り決めは様々で、通常はシステム連携する当事者が直接やりとりをします。

そして通常は、本来仕様がどうあるべきかが議論されます。議論のテーブルにも着かないゼロ回答はあり得ません。

複数の矛盾したゴールがあるゲーム

ゼロ回答は技術者としては論外ですが、そうならざるを得ない事情があります。それは請負契約です。

請負契約では最初に仕様を決め、「完成」にお金を払います。すなわち仕様変更はやりたくないことです。

ごく小さなプロジェクトなら仕様変更があっても大した影響はありませんが、大規模プロジェクトでは関係者が多く、請け負った側のリスクが大きすぎるので仕様変更は慎重になります。

マルチベンダーで請負契約だと最悪です。複数の請負契約があるということは「完成」が複数あることです。そして、ベンダー間の調整が必要になるのは、その「完成」のどれかが間違っていた、そんな状況になってしまったからです。

先ほどの記事も次のように、請負契約を愚直に守ったベンダーのせいで、プロジェクトのスコープが縮小されることになりました。

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

(中略)

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

プロジェクトマネージャーという救世主信仰

この手の話だと必ず「優秀なプロジェクトマネージャー(PjM)が必要」という発想が出てきます。しかしそれでは解決になりません。

もちろん全体を見れて、適切な意思決定をする人は必要です。一般にはプロダクトマネージャー(PdM)、スクラムではプロダクトオーナー(PO)が該当します。

しかし「優秀なプロジェクトマネージャー」を求めるのは救世主信仰、ないものねだりです。

なぜなら、プロジェクトマネージャーに求められるのは「幼稚園児のお守り」だからです。自分の子供ならかわいいですが、横柄な中年(中身は幼稚園児未満)の介護はしたくありません。だからプロジェクトマネージャーという職種は人気がなくなり、人手不足になっています。

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

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

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

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

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

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

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

理論上はクライアントのPjMが機能していれば問題ないですが、そもそもプロジェクトマネージャーは過度に責任ばかり負わされる職種です。最低でも役員クラスの権限がないと釣り合いません。

結論

結論としては「請負契約やめろ」です。アジャイル開発以前の話です。請負契約にこだわっている限り、まともなシステムは作れません。

2007年に書かれた記事があります。かつては請負契約はマイナーなものでしたが、20年前、1987年頃から請負契約が台頭してきました。

システム開発の発展経緯を見ると、約20年前までは圧倒的に委任型の契約が多く、請負契約は一般的な契約形態として普及しなかった。その後「SI（システムインテグレーション）契約」と呼ばれる、ソフト開発の請負を含むシステム構築請負契約が誕生した。筆者が所属していたIBMの「システム・マネジメント・サービス（SMS）」というシステム構築請負契約がその先駆けとなって、爆発的に普及した。

この記事では「システム開発技術を急速に発展させるきっかけになった」と書かれていますが実際は真逆で、丸投げのクライアント、プロジェクトマネジメント偏重によるシステム開発技術の急速な劣化といった諸悪の根源が請負契約だと確信しています。

自分は、請負契約を「ゴミを作ることを約束する契約」だと言っています。それくらい変化が当たり前の世界です。

この記事が気に入ったらサポートをしてみませんか？