システム間連携について

連携先が多いシステム開発はたいへん

　言ってしまうとコレなのですが、連携先の多いシステム開発は大変です。以前、片手を超える会社と連携のある前提でWebサイトをリニューアルしようとしたことがあるのですが、RFPを送付した会社の多くに辞退されるという状況が発生しました。

技術者の方からのアドバイス

　そんななか、RFPをお送りした会社の方から「弊社の技術責任者がお会いしたいと言っているので、お時間いただけますか？」とご連絡を頂戴しました。お会いしたところ、「数十年システムでご飯食べてます」といった風貌の方がいらっしゃいました。

　いろいろ参考になるお話をいただいたのですが、言われたこととしては、

・連携先の多いシステムは技術難度が高い
・このシステムではなく〇〇のシステムが主軸になると思われる
・このシステムもリニューアルするというのは難度がとにかく高い
・そのシステムで旗振りができないとこのプロジェクトは厳しいと思われる
・そのシステムで〇〇のところまで進捗していないと巻き込まれて炎上します
・辞退される会社が多いだろうからご説明した方が良いと思いました。
・お困りかと思います。お受けしたいのですがこの納期でこの要件だとリスクが高すぎます

すばらしい分析でございます…！

　実際、本来旗振り役であるシステムの開発はうまくいっていませんでした。で、プロジェクトの主導権も取れていないまま、周辺のサービスはリニューアルするという状況が発生していました。この状況をあのRFPから読み解けるというのは、すばらしい洞察力だと思います。

旗振り役のコントロールと役割分担が大切

　で、実際のところ、この開発は別ベンダーさんにお願いしたのですが、実際のところ、片手に余るベンダーさんに加え、クラウド系のサービスの導入なども加わって急な電話会議が組まれたり、もう、旗を振りまくって振りまくって、調べまくって考えまくって「みんなの知恵を総動員！」みたいになったので、「難度が高い」「旗振り役が必要」というコメントは当たっていたことになります。

　大変だったのは課題が発生したときの役割分担です。これだけ連携先が多いといろいろな実装方法が存在するわけで、調査にしても、まず誰がボールをもってその次に誰に、みたいなことをきちんと決めて、発注元の情シスが明確にコントロールをして、チケット一つひとつの挙動を見守っていないとすぐに宙に浮きます。

「殿、ご決断を！」

みたいな話が毎日のように生まれてくるという状況は、なかなかにスリリングですし、契約形態によって、AさんとBさんは直接やり取りできるけどCさんは情シス通さないとダメとか、考慮しないといけないこともあるわけで。

　それで本格的に導入したのがbacklogでした。ないとこんな管理はできませんでした。。。

　あとになってSIer出身の同僚から「連携先が多いほど工数は上がる」という話を聞いて改めてなるほどと思いましたが、やはり、日々いろいろなことがあります。そこでは「決断力」が必要になってくる。これで瞬時の決断力が身についた気がします。

　課題とか全部洗い出せてればいいんですけどね。どうしても「走りながら考える」という要素もあるので、連携先の多いシステム開発は、体力も必要だと考えています。