PR

オープン・システムが主流になり,開発の短期化が進んでいる。厳しい納期を守るために,プロジェクト・リーダーが受けるプレッシャは想像以上だ。しかしバック・ログを抱えたままで先を急いでは,後で大きなしわ寄せがくる。

イラスト 野村 タケオ

 Cさん(32歳)は,独立系SIベンダーL社に勤務する中堅SEである。電子部品メーカーであるH社のシステム再構築プロジェクトで,初めてリーダー職を任されることになった。半年前のキックオフ以来,H社に詰める忙しい日々を送っている。

 H社がL社に委託したのは,購買管理システムの再構築だ。Web技術を採用して,見積依頼や注文書といった調達先とのやり取りや支払い業務を電子化し,調達にかかるコストや期間を削減するのが目的である。同時に,資材の在庫管理システムの刷新も計画していた。両システムを連携させて,資材ごとの在庫数があらかじめ設定した適正値を切った時に,自動的に補充発注する仕組みを整えようというわけだ。

先輩の助言に反発

 しかしプロジェクトは,開始早々から波乱含みだった。Cさんが最も頼りにしていたエンジニアが体調を崩して第一線を離脱してしまったのだ。空いた穴を埋めるために,他のプロジェクト・メンバーに残業や休日出勤でがんばってもらったものの,遅れが少しずつ発生していた。

 プロジェクト開始から半年経って,スケジュールと現実のずれは無視できないほどに広がっていた。本来ならば,システム設計を終えてプログラム開発工程に入るべき時期だったが,システム要件を詰め切れていない部分が残っていた。そのため設計の手戻りも発生していた。

 そこで,プロジェクト・チーム内で緊急会議を開き全体をレビューしたところ,当初計画より約3週間も遅延していることが判明した。それでもCさんは,「リーダーである自分がしっかり進ちょくを管理すれば,開発と並行して設計の遅れを取り戻せる」と強気の構えだった。

 レビュー会議の翌日,Cさんは久しぶりにL社のオフィスに出社した。直属の上司であるY課長に,H社プロジェクトの進ちょく状況や今後の予定を報告するためである。遅れが発生していることを伝えた後,「当初の計画通り,来週から開発工程に入らせてください。遅れは絶対に取り戻します」と頼み込んだ。Y課長は,「今までの遅れを取り戻してから,次の工程に移ったらどうかね。その方がこれ以上の遅れを出さなくて済むと思う」とあまりいい顔をしなかった。

 だが,Cさんは譲らなかった。これまで築いてきた自分のキャリアの中で,大きなスケジュール遅れや顧客との問題を起こしたことなど1度もない。「この程度の遅れは誤差のうち。十分取り戻せる」と自信満々で,「必ず上手くやります」とY課長に迫った。Y課長は,Cさんのあまりの熱意に押されて最後にはOKした。

 ほっとして自席に戻ろうとしたCさんを,Fさんが呼び止めた。Fさんは,汎用機時代のL社を引っ張ったベテランSEである。「C君,遅れたスケジュールは途中できっちり“けじめ”をつけてから次工程に入った方がいい。こういう状況の時はメンバー全員のやる気が薄れたり,モラルが低下しているものだ。生産性や品質に問題が出ないとは限らないからね」。

 こう耳打ちされたCさんは内心,「COBOLしか知らないロートルSEが何を言っているんだ」とムッとした。それでつい,「Fさんこそ,ご自分のプロジェクトを心配なさった方がいいんじゃないですか。遅れが出ているっていう噂ですよ」と言い返してしまった。さすがに自分でも「ちょっと言い過ぎたかな」とは思ったが,「汎用機の昔は開発に何年もかけられただろうが,今の時代はそうはいかないんだ」という反発心の方が強かった。

見切り発車で傷口が広がる

 Cさんは間もなく,自分がFさんに対して取った態度を後悔することになった。H社のプロジェクトが大混乱に陥ったのである。開発作業が進むにつれて,ユーザーである購買部門からの変更要求が頻発。チーム全体がその対応に大わらわとなり,遅延していたスケジュールのばん回どころではなくなった。開発メンバーたちの疲労は極限に達し,チームは険悪な雰囲気に満ちていた。

 原因は明らかだった。システム構築期間の帳尻を合わせるために,見切り発車で開発に着手したせいである。一刻も早く本番開発に移行したいと思うばかりに,業務の洗い出しやシステム要件定義といった開発の上流工程をおろそかにしたこと。納期を優先して,未決定事項が解決しないままで次の工程に入ってしまったこと。こうしたCさんの采配ミスの結果として,重複作業が多発した。メンバーたちは,常に「押せ押せ」のスケジュールを余儀なくされたため,目の前に山積する作業をこなすことに精一杯。プログラム品質までは,なかなか気が回っていないのが正直なところだった。

 さらに悪いことに,開発作業に付随するドキュメント作成を省略していた。「書類を作っている暇があったら,プログラムを少しでも書いた方がマシ」と判断したからだが,このことが突然の修正や変更といったトラブルへの対応を難しくしてしまった。

 プロジェクトが完全に行き詰まったと悟ったCさんは,Y課長に同行してもらいH社を訪れた。新システムの稼働時期を延期してもらえるよう交渉するためだった。「自分がなんとかする」と豪語した手前,何とも決まり悪い思いで事情を説明するCさんの頭に,Fさんの顔がよぎった。

 Y課長やFさんは,Cさんのやり方を危なっかしく思って見ていたに違いない。彼らはかつての汎用機時代を支えたヒーローである。これまでに数え切れない修羅場をくぐり抜けてきたはずだ。Cさんは,そんなヒーローたちの“急がば回れ”という助言を「時代が違う」の一言で退けた。豊富な経験に裏打ちされたアドバイスを軽んじた代償は大きかった。

今回の教訓
・どんなに優秀なエンジニアでも,リカバリーできる状態には限度がある
・プロジェクトに予期せぬ問題はつきもの。リスクを加味して計画を作れ
・時には年長者の自慢話に耳をかたむけろ

岩井 孝夫 クレストコンサルティング
1964年,中央大学商学部卒。コンピュータ・メーカーを経て89年にクレストコンサルティングを設立。現在,代表取締役社長。経営や業務とかい離しない情報システムを構築するためのコンサルティングを担当。takao.iwai@crest-con.co.jp