複雑なシステム構成,短納期――。そうした難しいプロジェクトをどうさばくかは,マネジャーの腕の見せ所だ。厳密な管理ルールを作っても,現場の実情を無視していては逆効果。エンジニアにしわ寄せがいき,かえって開発の生産性を下げてしまう。

イラスト 野村 タケオ

 A君(29歳)は,流通業向けシステム開発を得意とするSI企業のO社で働くSEだ。学生時代までITとは無縁だったが,社会人になってからプログラム開発やシステム設計スキルをこつこつと身につけてきた。その努力が報われ,入社7年目にして大規模開発プロジェクトのサブ・マネジャーに抜擢された。

 A君がサブ・マネジャーを務めるのは,2003年2月にスタートしたG社におけるシステム開発プロジェクトだ。G社は,年商200億円の輸入食器販売会社。国内に5カ所の物流拠点を持ち,デパートや専門店を通じて製品を販売する中堅企業である。

 今回のプロジェクトの目的は,数千品目におよぶ商品在庫をリアルタイムで把握し,受注業務と直結させるための販売管理システムを開発すること。実現すれば,受注から納品までのリードタイムを従来の21日から10日以内に短縮できる。G社が新システムに寄せる期待は大きく,2003年末までにカットオーバーさせることが契約時の絶対条件だった。

 初めての大役に,A君は「自分に務まるだろうか」と不安でしかたなかった。なにしろ,大規模システムを10カ月で作り上げなければならない。プロジェクトには協力会社から多くのエンジニアが参加していることも,A君の心配の種だった。それぞれのスキルや仕事ぶりが未知数だからだ。膨大な開発量を思い,A君は当初から焦り気味だった。

 さらに,プロジェクト・マネジャーにKさんが着任したことが,A君にとって重圧になった。Kさんは,20年にわたり大きな開発プロジェクトをいくつもこなしてきたベテランだ。A君が尊敬する大先輩である。「Kさんに認められるような仕事をしなければ。開発スケジュールに遅れが生じたり,ドキュメントに不備があってはならない」。生真面目なA君は,そんなことばかり考えるようになった。

現場にオーバーワーク強いる

 開発本番に入ると,A君はますます余裕をなくした。仕事中に自分の手が少しでも空くと,開発メンバーたちに作業の進ちょく状況を聞きまくった。「今,手が離せないので後にしてもらえませんか」というメンバーに対しては,「進ちょく状況をこまめに報告してもらうルールだから」と言って,否応なく作業を中断させた。すべてを自分の目や耳で確かめなければ気が済まなかった。

 その結果,A君がメンバーに作成させるドキュメントはかなりの数に上っていた。「開発と同時進行では,とても手が回らない」という悲鳴は,「短納期なんだから,マルチタスクで進めるのは当然」と無視した。「僕は現場とプロジェクト・マネージャーであるKさんの橋渡し役。現場をしっかり指揮せねば」と気負っていた。

 1カ月ほど経った4月ごろから,深夜まで残業したり休日出勤するメンバーが目立ってきた。不審に思ったKさんがその1人に理由を聞くと,「進ちょく報告やドキュメント作成に多くの時間をとられて,平日の日中は仕事にならない」という返事が返ってきた。確かに,現場の様子を見ると疲労のためモラールが下がりつつある。Kさんは,「これはまずい。なんとかしなければ」と直感した。

 案の定,Kさんに不満や苦情を直接申し入れるメンバーが増えてきた。「進ちょく管理やドキュメント作成の重要性は理解できる。けれど,Aさんのやり方はあまりにも自分本位だ」という声だった。中には,「こんな調子が続くなら,プロジェクトからおりる」と言い出すメンバーまでいた。

実情よりルールを優先する

 Kさんはさっそく,A君を呼び出した。「君のやり方に,現場から拒否反応が出ている」。Kさんがこう切り出すと,A君は逆に「待ってください。文句があるのはこっちです。プロジェクトを予定通りに完成させるためのルールを,他のメンバーが守ってくれないんです」と訴えた。

 「それはルールが実情に合わないからじゃないか?君の行き過ぎた管理ルールが,かえって生産性を落としていると聞いたが」と,Kさんはこれまでに届いた不満の内容を話して聞かせた。憮然として聞いていたA君は,「今回のような短納期プロジェクトは,きめ細かい進ちょく管理が不可欠です。それに,顧客への業務引継ぎを考えると,ドキュメントをきちんと整備しておかなければなりません」と言い返した。

 Kさんはすぐに,「短納期のプレッシャは分かる。ドキュメント作成を優先するのも,君の真面目さからだと思う。でも,現場の負荷をむやみに増やして本来の業務に支障をきたすようでは,マネジャー失格だ」と説得しようとした。A君は自分の苦労を理解してもらえないショックのあまり,「そうおっしゃいますが,常に担当者の作業状況を厳格に管理していないと,遅れやトラブルに素早く対応できません」と声を荒らげてしまった。

 Kさんは小さくため息をつくと,「何のためにメンバー全員に週報を提出させているんだい?進ちょく具合をある程度そこから推測するのも,マネジャーに必要なスキルの1つだよ」と言い,「それともう1つ。ドキュメント類は,多ければいいってもんじゃない。内容をよく吟味して重複分をカットすれば,現場の負荷は随分減るし,顧客への引継ぎもシンプルになるんだ」と続けた。

 A君は,だんだんうつむき加減になっていった。マネジャーとしての自分の未熟さをずばりと言い当てられ,落ち込んでしまったのだ。そんなA君の様子を見てKさんは,「プロジェクトを動かすのは,人の力だ。現場の言いなりになる必要はないが,開発メンバーが仕事しやすい環境を作ってサポートしてあげて欲しい」と励ました。そして最後に,「まあA君,あまり肩に力を入れず,リラックスすることだ」と笑いかけた。

今回の教訓
・ルールのために働くのではない。ルールはプロジェクトの目的達成のためにある
・ルールがプロジェクトの現状に合わなければ,勇気をもって修正・変更すべし
・プロジェクトの中で1人だけが目立っても良い成果を期待できない

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