震災はプロジェクトに想定外の事態をもたらし、現場にはそれに対処するためのタスクが次々に発生した。

 危機対応時には、平時の作業に、想定外のタスクが加わることになる。こうした計画外のタスクに手間取れば、危機がまた新たな危機を呼ぶ。プロジェクトを先に進めるには、これらのタスクの処理を避けて通れない。

タスクが山積みになった危機を克服するには、「さばき方を変える」のが有効だ。

さばき方を変える
役割を変えて並行させる

 想定もしていなかったタスクが山積みになったとき、従来と同じやり方でこなそうとしても、なかなかその山は減っていかない。元々計画していたタスクを消化していく必要がある上に、それまでのやり方はあくまで平時を出発点に考えられたものだからだ。タスクのさばき方を見直すべきだろう。

現場に出向いて問題解決

 モバイル向け広告の配信を手掛けるディーツー コミュニケーションズ(D2C)は2010年夏、NTTドコモのiモードの検索機能と連動した広告配信システムの開発で、テスト担当者から質問・不具合報告が殺到する危機に見舞われた。プロジェクトは2009年10月に開始。開発規模は1000人月にもなる。

 開発はベンダー側の拠点で行われていた。テスト担当者からの質問や障害報告に対応していたのは、同じベンダーの要件定義担当者。仕様の確定や調整など本来の作業を進めながらだった。

 単体・結合テストで4万以上の項目をチェックするため、新規のテスト担当者が大量投入された。ここで状況は一変する。当初は要件定義担当者だけで対応できていた質問や不具合報告が、増員後に急増。未解決の件数は数百に積み上がった。「3カ月先の稼働時期はずらせない。解決には従来とは違うやり方が必要だった」と、D2Cの和賀勝彦氏(事業開発本部 メディア・ストラテジー・グループ ITアーキテクト担当 上席エキスパート)は話す。

図1●テスト担当者から寄せられる質問・不具合報告への対応を変える
図1●テスト担当者から寄せられる質問・不具合報告への対応を変える
ディーツー コミュニケーションズ(D2C)のメンバーは、自社のモバイル向け広告配信システムの開発で、テスト担当者からの質問や不具合の報告が頻発してプロジェクトが進まなくなる事態に直面した。開発ベンダーの要件定義担当者が受け持っていたテスト担当者への対応を、急遽D2C側が担当。山積みだった問題をさばいて、無事3カ月後にシステムを稼働できた
[画像のクリックで拡大表示]

 D2C側のメンバーは、開発ベンダー側の拠点に場所を移し、要件定義担当者に代わってテスト担当者に直接対応することにした(図1)。それまでに基本設計書を丹念に確認していたので、質問や不具合報告に即座に答えられると考えたからだ。

 現場に出向いたD2C側のメンバーは、仕様を把握していれば不具合ではないと判断できるものが「不具合」として多数報告されていることに気付く。そこですぐにテスト担当者向けにオリエンテーションを実施し、業務の仕組みやデータ構造など新システムの仕様の詳細を解説した。

 テスト担当者の席も回った。「このデータ項目を登録できないのはバグではないか」といった疑問に「未設定の項目がほかにあるので登録できないだけ。バグではない」とその場で答えていった。未解決の問題は解消し、3カ月後に無事システムを稼働させた。