システム開発プロジェクトに参加すると、必ず他のシステムに関する付帯作業が発生する。緊密に連携するシステムならまだよいが、あまり影響しない外部システムであっても、その担当者から「接続テストに付き合ってほしい」と言われることがある。もし先方のシステムに不具合が見つかれば、修正のたびにこちらも繰り返しテストしなければならない。その分余計なリソースを割り当てる必要があり、当初予定していないコストは膨らむ一方になる。
こうした状況は現場における「セグメント意識」の強さから来るものだろう。もちろん自分たちの仕事が増えることを素直に歓迎できない気持ちは分かる。しかしシステムを構築する上で、もはや外部システムとの連携は避けられない。連携先との関係を軽視すると、結局は問題を生み出し、手痛いしっぺ返しを食らうことになる。今回は、こうした失敗を未然に防ぐためのルールである「外部システムに関与せよ」について紹介しよう。
出された仕様をうのみ 不備に気付かず“御役御免”
外部システムに関する付帯作業が増えると、本来の自分たちの仕事がはかどらなくなり、イライラが募る。問題は、外部システムに対するプロジェクトメンバーの意識が薄いことだ。自分たちのシステムに関係するインタフェース仕様が確定したら、あとは連携先のシステムの状況などお構いなしに、自分たちの開発だけに集中してしまうことが少なくない。リーダーはここにメスを入れる必要がある。
過去の失敗を話そう。このプロジェクトでは、外部システムとのインタフェース仕様の度重なる変更で、現場が疲弊した。そもそもスケジュールがとにかく厳しかった。そのためインタフェース仕様については、ユーザーから提示されたものをそのまま使い、特に仕様の確認や調整などはしなかった。時間が限られているので、指定された仕様を信頼し、開発に当たったのである。
ところが、開発がだいぶ進んだところで、どうもそのインタフェース仕様がおかしいことが判明した。連携元と連携先のデータ項目間で不整合があったのだ。筆者らはあわてて仕様の不備をユーザー側に指摘したが、「今さら遅いですよ。私たちも日々の仕事が忙しいので、あとはそちらでよろしくお願いします」とあっさり断られた。
何が正しいのか判断できない。筆者らは、できる限りの手を尽くしたが、バグを含んだシステムを作り上げてしまった。外部システムとの接続テストはもちろん、担当システム内のテストでさえ、ことごとく失敗した。メンバーは修正作業に追われ、システムのリリースは予定を大きく遅れた。
その後、ユーザー側とは責任のなすり合いとなった。結局双方がコストを分担することで決着。だが、ユーザーとの信頼関係は完全に失われた。ギクシャクした関係が続き、筆者らは最終的に“御役御免”となった。
こんな失敗もあった。あるシステムのリリース後に、外部システムとオンライン接続したときだった。接続する外部システムの仕様の確認や、事前のテストは行ったはずだった。ところが、その外部システムが想定外の動きをしたため、こちらのシステムの共有リソースがパンク。その結果、オンライン接続した外部システムのサービスが停止した。さらに、連携先システムの先にある別のシステムにも影響が出た。
サービス全体に障害が及んだ事態は重く、「どうして連携先のシステムの仕様をちゃんと確認していなかったのか」と、あちこちから責められた。
リーダーは勇気を持って他人の領域に踏み込め
皆さんも、多かれ少なかれこうした失敗をしているかもしれない。原因は、自分たちの都合を優先し、外部システムの状況をきちんと確認しなかったからである。人や時間といったリソースは有限であり、リーダーは常にコストやスケジュールを守るというプレッシャーと向き合う必要がある。よく分からない他人の領域に踏み込む勇気は、なかなか持てないものだ。
しかし、そこに踏み込むことで、見えてくる世界がある。自分たちの知識は広がり、それが品質の高いモノ作りへとつながる。相手への理解が深まれば、相手からの信頼も厚くなる。そうなれば、互いにとって仕事のしやすい環境が生まれ、効率良くシステムを構築できる。リーダーが勇気ある一歩を踏み出せば、それまで暗かったプロジェクトの明日を明るくできるのである。
