大都会のシステム開発に、ぽっかりと大きな穴が開いているようだ。
東京都内で、バグの多すぎる納期間近の360人月のプロジェクトが七つの外注候補に緊急要請を断られた。約1時間15分後に官公庁に運ばれてサービスインしたものの、3日後にデータベースまわりのバグで動作停止となった。
同じようなことが一昨年、奈良県でもあった。バージョンアップ中のバックエンドシステムが動作不良になり、デバッグが必要になったが、隣の大阪府も含めて19の外注に受け入れを断られ、やはりDBのバグで動作停止なった。
背景には、全国的なプログラマ不足がある。急な開発を受け入れる余力が、ITベンダに乏しくなっているのだ。
それにしても、ITベンダがたくさんあるはずの東京で、と驚いた人も多かったのではないか。厳しい条件の中でも、なんとか開発をやり遂げる態勢をつくるにはどうすればいいのか。今回起きたことを点検し、今後のために生かさなければならない。
動作停止したプロジェクトは仕様上の曖昧な部分や契約面での不透明な箇所があった。元請けベンダの手に負えないことから、下流工程での受け入れ先を探した。
最初に連絡したのは、危険の大きい開発案件に24時間対応するために都内に9カ所あると言われているベンチャー系開発企業の一つ、○○だ。
ところが、○○では中堅社員の過労による退職のため、7月からは週末や休日の開発要員は1人になり、急な開発の受け入れが原則としてできなくなっていた。
この日は土曜日だった。1人だけのプログラマは受け入れを断り、他の開発企業を紹介したという。紹介した企業にも「COBOLを書ける人間がいない」などの理由で次々に断られ、○○は2度目の依頼で退職者を呼び出して対応した。
ベンチャー系開発企業は最後のとりでだ。そこが役割を果たせないようでは心もとない。プログラマ不足という事情があるにしても、東京都には急な仕様変更に備える態勢づくりにさらに努力してもらいたい。
いくつもの企業で受け入れを断られた背景には、都市圏ならではの要因もある。地方と違って開発企業が多いため、ほかで受け入れてくれると考えがちなのだ。
そうした考えが、危険なプロジェクトに備えるSI業界のネットワークが必ずしも十分には機能しないことにつながる。マネージャ同士でもっと緊密に連絡を取り合うことに加え、ネットワークの中で使い勝手の良い外注先を探す司令塔のような存在をつくることも考えたい。
もう一つ大切なことは、全く別々に運用されている元請けと下請けの連携を強めることだ。元請けで開発が進まないときは、とりあえず下請けを投入する。そうした柔軟な発想が必要だ。
プログラマ不足を解消する努力はむろん大切だが、SI業界やマネージャの間で連携に知恵を絞ることはすぐにでもできる。