大地震後の計画停電は、被災地以外のプロジェクトの開発現場にも大きな影響を及ぼした。PCやサーバーへの電力がストップし、作業を止めざるを得ない事態に陥ったのだ。

 システム開発プロジェクトでは、想定外の課題が発生して、一時的に作業を止めることがある。膨らんだ工数で、システム稼働までの開発期間が大幅に不足してしまうことも多い。本来必要な時間を確保できないという危機的な状況を、「最短距離を走る」という策で切り抜けた現場を紹介する。

最短距離を走る
効果の大きい作業に集中する

 プロジェクトに課題が発生したとき、通常は本来踏むべき解決の手順がある。しかし危機的状況といえるほど時間に限りがある場合には、その手順を省略してでも、最短距離を走ることを考えざるを得ない。最も効果の大きい進め方は何か、システムの実現手段を見直すことで開発工数を減らせないか。手順通りの解決策とは違う対処の方法も検討したい。

不備のある設計書を修正しない

 NTTデータ セキスイシステムズの相崎泰氏(システム開発統括部 システム開発グループ 課長)は昨年携わったプロジェクトで、基本設計書の不備が原因の危機を、基本設計書を修正することなく乗り切った。

 このプロジェクトでは、オフショア開発先から届いたプログラムの受け入れテストで仕様の不備が多発。基本設計書に、必要な分岐処理が正しく書き出されていなかったことが原因だった。システムの稼働予定日まで残り2カ月。その期間で不備を修正し、テストを終えなければならない。

図1●基本設計書の不備をフローチャートで補う
図1●基本設計書の不備をフローチャートで補う
NTTデータ セキスイシステムズの相崎泰氏が携わったプロジェクトでは、オフショア先から届いたプログラムの受け入れテストで、分岐処理に不備が多いことが判明した。稼働時期が迫っていたため、基本設計書を修正せずに、分岐処理のフローチャートを作成してオフショア先に修正を依頼。2カ月後の稼働に間に合わせるこ とができた
[画像のクリックで拡大表示]

 本来ならば、基本設計書の内容を見直して、分岐処理の不備を書き直すことになる。しかし「修正した設計書を送り直しても、オフショア先が修正箇所を把握するのに時間がかかり、稼働には間に合わない」(相崎氏)。

 そこで相崎氏らは、基本設計書は修正せず、新たに分岐処理のフローチャートを数十種類作成することにした。それをオフショア先に送り、プログラムを修正してもらう(図1)。オフショア先の担当者も「図解されていて分かりやすい」と修正に応じてくれた。オフショア先からの質問にも2時間以内に回答し、作業の流れを止めないよう気を配った。その結果1カ月で修正のめどが立ち、2カ月後には無事システムを稼働できた。