3プロジェクト同時にリード！どう乗り切る？：システム開発プロジェクトの現場から（10）（2/2 ページ）

» 2008年01月07日 00時00分公開

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ]

3プロジェクト並行。スケジュールを引き直す

　3つ目のプロジェクトが立ち上がったところで、「このままだとヤバイかな……」と思い始めました。そこで現状をまとめて、どうやったらうまくやれるか、再度プランを立て直してみることにしました。

　3つのプロジェクトの概要は以下のとおりです。

（1）某メーカー　基幹システムリプレース


役割	プロジェクトリーダー兼要件定義・設計担当兼移行など
カットオーバー	3月
メンバー	5人

（2）製造業　データ統合／商品別損益計算書出力システム


役割	プロジェクトリーダー兼要件定義・設計担当など
カットオーバー	4月
メンバー	2人

（1）データウェアハウス構築プロジェクト


役割	1人プロジェクトなのですべて
カットオーバー	3月

　当たり前といえば当たり前ですが、ピークをずらすようにスケジュールを組み替える必要がありました。ただし、私の考えるピークには2種類あります。1つは、プロジェクトとしてのピーク。もう1つは、私自身の作業のピークです。

　（3）のプロジェクトは1人作業でしたし、納期の前倒しの調整が可能でした。勇気のいる決断ですが……。

　そこでまず、プロジェクトのカットオーバーを（3）→2月、（1）→3月、（2）→4月というように1カ月ずつずらしたスケジュールを作成しました。それに合わせて自分自身の作業のピークも（3）→（1）→（2）となるようにプランしました。毎月カットオーバーって、いま思うとすごいですよね。

　それからもう1つ。（1）のプロジェクトは、最終的に画面をWebで閲覧できるようにする必要がありました。前回の記事「この案件、ぜひ新しいテクノロジでやりましょう！」で.NETの話をしましたが、今回もできれば最新のテクノロジを用いて……などという気持ちもありました。メンバーはJavaで作りたそうでしたが、4画面程度しかなかったこと、ビルドしてデプロイしてといった時間をかけたくなかったことなどいろいろな理由から、ASPでVBScriptでやることに決めました。苦渋の決断でした……。

そして迎えたカットオーバーの連続

　作成したスケジュールのとおり、まずは（3）のプロジェクトがピークを迎えます。これは私自身が過去に構築した基幹システムからデータウェアハウスを構築するもので、テーブル構造もすべて分かっていましたし、クライアントが望んでいるものもある程度理解できていました。なので2月のカットオーバーは、無事終えることができました。大きなトラブルもなく。

　次は（1）のプロジェクトです。3月に向けて2月の作業ピークを乗り切り、移行で残高などの数字合わせもOKとなり、カットオーバーしました。が、実は、カットオーバー初日に少しトラブりました。敗因は作業工数不足ではなく、別のところにありました。ユーザーテストの不足です。

　とはいっても、クライアントに非があったわけではないと思っています。ユーザーテストの期間は設けていたのですが、通常業務が忙しく、なかなかテストに時間を割いていただくことができませんでした。そんな中、きちんとしたユーザーテストのプランを提示することも、推進することもできなかったため、カットオーバーの際に初めて問題が露呈するという結果を招いてしまったのでした。幸い傷は浅かったため、その日のうちにプログラムの改修を行い、翌日からリカバリすることができました。しかし、その後も何件か問題を出しながらのカットオーバーとなってしまいました。そのことから得た「ユーザーテストの大切さ」という教訓は、いまも忘れることはありません。

　そして3月、最後のプロジェクトのピークを迎えました。予定では3月初めから（2）のプロジェクト全開で行くはずだったのですが、前述したように（1）のプロジェクトでだいぶ差し込まれてしまっていたため、うまくスタートダッシュを切ることができませんでした。

　そのため、おそらく社会人になって初めての徹夜も経験しました。徹夜明けでそのままロマンスカーに乗って、ということもありました。最終的には私もコーディングしていましたし、メンバーにもだいぶ迷惑をかけたと思います……。ですがその甲斐あって、無事にカットオーバーすることができました。

試練から学んだ、変化を受け入れ、道を切り開く方法

　だいぶつらかったですし、こんな状況を積極的にお勧めするわけではありません（普段は徹夜反対派です。徹夜なんて効率が落ちるだけだと思っているので）。ですがこの経験から、いろいろなものを得ることができたと思います。

ある作業から別の作業に切り替えることの難しさ

　切り替えにかかるオーバーヘッドは、やはり相当なものです。自分もそうですが、メンバーに仕事を依頼するときは特に、できるかぎり切り替えが必要ないようにしようと思いました。プログラムや設計など、知的生産物を作成しているときは特にそうです。

　しかしこの仕事をしていると、どうしても割り込みは入りやすいです。そういうときのために、自分なりの切り替え方法をつかんでおくことが大切だと痛切に感じました。

　私自身、うまい切り替え方法を確立しているとはいえませんが、タスクを細かく区切っておくことで、1個1個の終わりが短くなるようには意識しています。

楽しく

　忙しいときこそ、なおのこと楽しく仕事できるようにしたいものです。常に笑って仕事できるような雰囲気づくりって、とても大事ですよね。

変化を受け入れる

　状況はいろいろと変わります。好ましい変化であれ、好ましくない変化であれ、それを受け入れて対応しないといけないということを学びました。確かダーウィンもそんな感じのことをいっていましたよね。

どうやったらできるか常に考える

　つらい状況や難解な課題など、いろいろな困難があると思います。でも、常に「どうやったらできるのか？」をロジカルに考え続けていれば、絶対に悪い方向には進まないということを学びました。

　できないいい訳を探し出したら負けです。楽しくありません。その雰囲気は、チームにも広がってしまうのではないでしょうか。

　どうやったらできるかを考えて、成功のイメージをつくる。そうすれば道は広がっていきます。道がふさがりそうになったら、また道を探すか、さもなければ自分で道をつくっていく。そうしていけば何でもできますよね。「Can Do」の精神です。

　アクセンチュアのコアバリューの1つ、「Best people」の中にある「Can Do」という言葉を、私はとても気に入っているのです。

筆者紹介

アクセンチュア・テクノロジー・ソリューションズ

新楽清高

1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス～要件定義～開発・テスト～運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。趣味はトラブル対応。

「次回」へ

「システム開発プロジェクトの現場から」バックナンバー