上司は必見！部下とプロジェクトの管理方法

「こんなプロジェクトやってらんねぇ！」と嫌気が差す原因のひとつに、実は“プロジェクトの規模”が影響しているかも……。そこで今回は大規模と小規模プロジェクトそれぞれの裏に潜む、常識・非常識に迫りたい。

「メンバーをマネジメントすることの大小ギャップ」・・中堅リーダークラスの場合
ここではプロジェクトリーダーお二人をお呼びした。年代も具体的な仕事内容も異なるお二人だが、悩みはプロジェクト内の“コミュニケーション”と“リスク管理”に集中した。
----------------------------------
Ａさん
35歳。セキュリティカードのサーバーシステムやシステム周りの設計開発などを担当。大手研究所からハード系会社の現職に転職経験あり。

Ｂさん
SE一筋20年の42歳。去年、大手企業からソフトハウスに転職したばかりで、理由はずばり現場に近づきたいから。販売管理システムをメインとしたシステム設計を担当。
----------------------------------

コミュニケーションの常識・非常識

プロジェクト内のコミュニケーションに関しては、主に大規模の欠点・小規模の利点についてお二人の意見が集中した。早速、それぞれの理由について聞いてみたい。
編集部： 大規模におけるコミュニケーション上の特徴は、どんな点でしたか？
Ａさん： 400人くらいの大規模プロジェクトでチームリーダーや事務局周りを担当していました。大規模だと、例えば営業系のSE部署や開発系など、いろいろ部署が入って横のつながりですとかスケジュールとかプロジェクトをどう進めていくか、みたいなのが割と重要になってくるんですね。全体を見る方はいるんですけれど、お互いが全然見えなくなってきて、中での意思疎通ってなかなかできないんですよ。それでズレがどんどん生じてきたり。
Ｂさん： 大規模になると「意思疎通する」人、つまり媒介者が必要になってくるんです。それが何人もいると媒介者同士のコミュニケーションがまた必要になる。関与する人間が増えてくると、現場もやりづらいんですよね。「この件はだれに話せばいいのだろう」といった。

編集部： 大規模では外部の協力会社も増えると思いますが、協力会社の方たちとのコミュニケーションはどうでしょう？
Ｂさん： 外部に依頼したコーディングをする方々っていうのは、割と「夜型」の人間が多いので放っておくとエンドレスにやり続けるんですよ（笑）。だから常々「今日は早く帰って休んで」とか指示したりしなきゃいけないし。本当にパンクしそうなチームは夜食事に誘ったりもしなきゃいけないし、リーダークラスになると現場の仕事よりも、メンバー同士の意思疎通を図ることに比重が傾きますね。
Ａさん： あと、こちらに対して何かと“遠慮”するベンダーさんもいて、さっき言われたように飲み会をしてお互い仲良くすることが重要。仕事に関係ないんですけど趣味の話とかしてお互いの壁を低くして、「ささいなことを聞いても怒られない」雰囲気をつくるとか（笑）。そういう雰囲気をつくらないと自分で勝手に判断していいだろう、というふうになるんです。
自社に帰ってやっていただく場合は、どうしてもロスがあるじゃないですか。メール送って返ってくるのに一日かかると、その間、全く作業を進められないので彼ら自身で判断して、ということになってしまうんです。
Ｂさん： その人は「一般的にはこうだろう」と自分の知識で判断してやっているんでしょうけど、この業界、何をもって一般的とするか難しい点がありますから。
私の場合、いちばんびっくりしたのは販売管理などのトータルシステムで、マネジメントをしてたとき。「在庫の原価計算を月次移動平均方式で算出する」というのがお客様のルールだったはずなんですが、いつのまにか協力会社のこれまでの経験でまったく違う算出方式になっていて……。つまりロジックがゴロっと変えられてたんです。
在庫管理のサブリーダーを呼んで話を聞くと「あの会社ならやってくれるから大丈夫」と丸投げしていたんですね。それはコミュニケーションが取れていなかった私の責任でもあるんですけど。

編集部： では小規模ではいかがでしょう？
Ａさん： 逆に小規模で３〜４人とかだとメンバーの相性やベクトル、あとチームの年齢構成とかいろいろ役割分担がうまくできていると、非常に効率よくできたりするんですよ。
Ｂさん： 極端な話、ここにパソコンがあったとして販売管理の人、生産管理の人、経理の人、みたいな感じで同じテーブルの上で作業しながら「今こんな状況だよ」なんてしゃべりながらできる。現場の設計なり製造なりの仕事をしながら意思疎通も図れるし、それはマネジメントする立場としても非常に楽ですよね。
Ａさん： やっぱり小規模だと決定権がある程度、現場に与えられているわけですよね。
後はプロジェクトマネジメント管理の方法で、普通はウォーターフォールを使うんですよ。要件定義から基本設計、詳細設計といった流れを１回だけ流すんですね。それじゃなくて、最近はスパイラルとかアジャイルといって、何回も繰り返しながらやっていくという方法があるんですけど、少人数だとそういうやり方が組みやすいというのがあって。

編集部： それはトライアンドエラーが、大規模に比べ小規模のほうが有利ということですか？
Ａさん： そうですね。要はスピーディに対応できることが重要だと思うんです。大規模と違い、決定権もあるし判断も早く、決められる範囲も広いっていうのが小規模ならではのメリットかなと思っています。

■まとめ■　コミュニケーション編
大規模：人が多いだけに意思疎通が困難
　　　　メンバー同士の雰囲気づくりが重要
　　　　判断が一人でできない
小規模：なんといってもスピーディに対応
　　　　決定権がある程度現場にある
　　　　相性がよければ効率もよい

リスク管理の常識・非常識
　：
　：
この記事の続きは[livedoor キャリア]で


■関連リンク
・livedoor キャリア
・SE究極のレジュメ - 学歴・資格・試験
・SE究極のレジュメ - 希望条件・自己PR・キャリアプラン
・【女の転職】「即採用！」を引き出す自己PR大作戦
・「働けども給与は上がらない」と感じている社員は半数に昇る！