(cache) 知ってる？大規模vs小規模プロジェクトの常識・非常識

メンバー内の人間関係・トラブル対処法・スケジュール管理etc.　知ってる？　大規模VS小規模プロジェクトの常識・非常識

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

（取材・文／鎌江友香　総研スタッフ／山田モーキン）作成日：06.06.21

　まずＴｅｃｈ総研が100人のエンジニアにアンケート調査した中から、右図の円グラフを見てもらおう。これは同業種・同職種に転職した際に、仕事の進め方などで違いを感じた人たちの割合だ。なんと転職者の半数近くが同じ職種にもかかわらず仕事の進め方が「違っている」と答えている。

　あなたも同じような思いを、転職だけでなくプロジェクトが変わるたびに感じたことはないだろうか？エンジニアを何年もやっていればおのずと経験も増え、大規模・小規模さまざまなプロジェクトにかかわったことがあるはず。「同じ職種」とひとくくりにされることが多いが、プロジェクト内の管理者側とメンバー側、双方の声から、大規模・小規模プロジェクトで異なる常識・非常識を、今、暴いていく！

ここではプロジェクトリーダーお二人をお呼びした。年代も具体的な仕事内容も異なるお二人だが、悩みはプロジェクト内の“コミュニケーション”と“リスク管理”に集中した。

Ａさん
35歳。セキュリティカードのサーバーシステムやシステム周りの設計開発などを担当。大手研究所からハード系会社の現職に転職経験あり。

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

プロジェクト内のコミュニケーションに関しては、主に大規模の欠点・小規模の利点についてお二人の意見が集中した。早速、それぞれの理由について聞いてみたい。

編集部：

大規模におけるコミュニケーション上の特徴は、どんな点でしたか？

Ａさん：

400人くらいの大規模プロジェクトでチームリーダーや事務局周りを担当していました。大規模だと、例えば営業系のSE部署や開発系など、いろいろ部署が入って横のつながりですとかスケジュールとかプロジェクトをどう進めていくか、みたいなのが割と重要になってくるんですね。全体を見る方はいるんですけれど、お互いが全然見えなくなってきて、中での意思疎通ってなかなかできないんですよ。それでズレがどんどん生じてきたり。

Ｂさん：

大規模になると「意思疎通する」人、つまり媒介者が必要になってくるんです。それが何人もいると媒介者同士のコミュニケーションがまた必要になる。関与する人間が増えてくると、現場もやりづらいんですよね。「この件はだれに話せばいいのだろう」といった。

編集部：

大規模では外部の協力会社も増えると思いますが、協力会社の方たちとのコミュニケーションはどうでしょう？

Ｂさん：

外部に依頼したコーディングをする方々っていうのは、割と「夜型」の人間が多いので放っておくとエンドレスにやり続けるんですよ（笑）。だから常々「今日は早く帰って休んで」とか指示したりしなきゃいけないし。本当にパンクしそうなチームは夜食事に誘ったりもしなきゃいけないし、リーダークラスになると現場の仕事よりも、メンバー同士の意思疎通を図ることに比重が傾きますね。

Ａさん：

あと、こちらに対して何かと“遠慮”するベンダーさんもいて、さっき言われたように飲み会をしてお互い仲良くすることが重要。仕事に関係ないんですけど趣味の話とかしてお互いの壁を低くして、「ささいなことを聞いても怒られない」雰囲気をつくるとか（笑）。そういう雰囲気をつくらないと自分で勝手に判断していいだろう、というふうになるんです。
自社に帰ってやっていただく場合は、どうしてもロスがあるじゃないですか。メール送って返ってくるのに一日かかると、その間、全く作業を進められないので彼ら自身で判断して、ということになってしまうんです。

Ｂさん：

その人は「一般的にはこうだろう」と自分の知識で判断してやっているんでしょうけど、この業界、何をもって一般的とするか難しい点がありますから。
私の場合、いちばんびっくりしたのは販売管理などのトータルシステムで、マネジメントをしてたとき。「在庫の原価計算を月次移動平均方式で算出する」というのがお客様のルールだったはずなんですが、いつのまにか協力会社のこれまでの経験でまったく違う算出方式になっていて……。つまりロジックがゴロっと変えられてたんです。
在庫管理のサブリーダーを呼んで話を聞くと「あの会社ならやってくれるから大丈夫」と丸投げしていたんですね。それはコミュニケーションが取れていなかった私の責任でもあるんですけど。

編集部：

では小規模ではいかがでしょう？

Ａさん：

逆に小規模で３～４人とかだとメンバーの相性やベクトル、あとチームの年齢構成とかいろいろ役割分担がうまくできていると、非常に効率よくできたりするんですよ。

Ｂさん：

極端な話、ここにパソコンがあったとして販売管理の人、生産管理の人、経理の人、みたいな感じで同じテーブルの上で作業しながら「今こんな状況だよ」なんてしゃべりながらできる。現場の設計なり製造なりの仕事をしながら意思疎通も図れるし、それはマネジメントする立場としても非常に楽ですよね。

Ａさん：

やっぱり小規模だと決定権がある程度、現場に与えられているわけですよね。
後はプロジェクトマネジメント管理の方法で、普通はウォーターフォールを使うんですよ。要件定義から基本設計、詳細設計といった流れを１回だけ流すんですね。それじゃなくて、最近はスパイラルとかアジャイルといって、何回も繰り返しながらやっていくという方法があるんですけど、少人数だとそういうやり方が組みやすいというのがあって。

編集部：

それはトライアンドエラーが、大規模に比べ小規模のほうが有利ということですか？

Ａさん：

そうですね。要はスピーディに対応できることが重要だと思うんです。大規模と違い、決定権もあるし判断も早く、決められる範囲も広いっていうのが小規模ならではのメリットかなと思っています。

プロジェクトにおけるリスク管理に関しては、主に大規模の利点・小規模の欠点についてお二人の意見が集中した。早速、それぞれの理由について聞いてみたい。

Ｂさん：

小規模だと例えば、新たな技術にぶつかったときに「お前知ってる？」「いや、知らない」と（笑）、それの繰り返しになってしまいますね。で「あれ、これだれに聞く？」とか「だれを呼べばいい？」という感じで難題にぶつかることは、たまにありますね。

編集部：

結局、だれも知らない場合はどうするんですか？

Ｂさん：

私の場合、外部の人脈をかけめぐって１日２日、空き時間を無理につくってちょっとお話聞かせてもらって。例えば「業務のポイントはどこに置けばいいか」だとか、そういう“個人レッスンの日”を設けて、学びつつ進めるといった具合ですね。

編集部：

Ａさんはいかがでしょう。

Ａさん：

小規模では管理が薄くなって、スケジュールが遅れがちになるケースが多いですね。
例えば４～５人で固まって仕事をする場合、隣にコーディングしている人がいて、「コーディングしているから何％くらいできてる」とか「どれくらいデバッグできてる」とかわかりますが、逆に“なあなあ”になってしまうんです。
組織だと「きちんと約束しましたよね」みたいに、ルールを盾に強く言ったりもできるんですけど「明日までに終わります」とか言って「まあ明日までだったらいいか」みたいになれ合いが起きてしまって、管理する側としてはやりにくい場合もありますね。

編集部：

コミュニケーションがだらしなくなるのも逆によろしくない、と。

Ａさん：

ええ、あとは課題があったときも吸収できる人数がいないので、急にポコっと問題が発生したときにそこから3日徹夜が続いたりとか（笑）。なんとしても間に合わせなきゃいけないときに負荷が集中してしまうケースがあって正直、スケジュールを見比べながらいつもヒヤヒヤしています。
それに少人数だと個人の差ってすごく大きいんですよ。例えば3人だと、人のスキルに完全に依存しちゃうんですよね。だからスキルセットがないと、もうどこをどう直していいかわからなくなっちゃうとか（笑）。

Ｂさん：

逆に、本当にものすごいスキルの人はとことん走っちゃう。「もう帰れば？　何やってるの？」って聞くと「ちょっとこのソースが汚いので直してます」とか（笑）。「いいよ、それはもう」みたいな（笑）。
自分もそうでしたけどエンジニアって潜在的に“こだわり”ってあるんですよ。大規模だと組織がまず前提にあるのである程度抑制できたりするんですけど、小規模だとその“こだわり”がもろに仕事に出てきて、時にそれが「個人の暴走」につながったりもして……。ただ、こだわりもエンジニアに必要な重要スキルだと思ってますけど。

編集部：

では大規模プロジェクトならではの特徴はありますか？

Ｂさん：

やっぱりシステムを作り上げるためには、ソフトウェアの知識だけじゃダメなんですね。「在庫管理とは何か」とか、業務知識に精通している人が必要になってくる。大規模だと割と関与する人間が多いので、それに長けている人間が割と必然的に何人か出てくるわけですよ。
だから先ほど小規模のケースで述べた、「個人レッスン」のような日を自分から作る必要なく、わからなければ社内にいる「その道のスペシャリスト」に直接聞けばすむんです。

Ａさん：

担当する仕事の規模が大きくなるので、外部との交流が増える感じはありますね。例えば電子マネーを担当しているときは金融機関の方と話すことが多くなったり。

Ｂさん：

あとは大規模プロジェクトとなると、新しい技術に触れる機会が多いですね。やっぱり技術屋さんである以上、新しい技術に触れるというのは刺激になります。少人数でやる業務系のソフト開発ではそういうことがなくて……。
もちろん新技術に携わるのは最初は不安ですけど、さっき言ったように社内にスペシャリストがいるので、そうした方々のサポートを受けながら「こんなふうになっているんだ」と理解を深めることができるのは、仕事に対するモチベーションも上がりますし単純に楽しいですね。

ケース２では、現場で実際に仕事をするSEたちにお話を伺った。年齢も同じお二人、困った上司やルール、情報共有についてなど共通の悩みも多かった。より現場レベルに近い大規模・小規模ならではの常識を紹介していく。

Ｃさん
27歳。保険系のWebシステムで設計工程・プログラミングを担当。携帯電話の開発プロジェクトでは大規模システムに携わる。

Ｄさん
27歳。現在はIT関連企業の社内SE。前職では原子力発電所の点検保全システムに携わる。Ｃさんと同じく、詳細設計からプログラミング・テストまでを行う。

プロジェクトにおけるルールドキュメントに関しては、主に大規模の利点・小規模の欠点についてお二人の意見が集中した。早速、それぞれの理由について聞いてみたい。

編集部：

ルール・ドキュメントで、大規模の特徴を教えてください。

Dさん：

例えば「スケジュール的に間に合わないので人を増やします」と言われたときに、難なく入っていけるのが大規模のほうですね。ドキュメントとかも全部ちゃんとあるから。

編集部：

それは逆に言えば、小規模の場合はドキュメントがしっかりしてないケースが多いということでしょうか。

Dさん：

しっかりしてないですね。だから新入社員とか入れられないんですね。小規模には。

Cさん：

新入社員に勧めるとしたら、最初は大規模ですね。大規模だと「どこどこの工程」っていうふうに限定的に入るので、とっつきやすいんです。それにわからないことがあれば周りに聞けるメンバーが多いので、やりやすいと思うんですよ。私が入ったときも同期と一緒に入ったので話しやすいし、同じ仕事・同じ工程をしているメンバーもいっぱいいましたから、それで結構助かりました。

編集部：

実際プロジェクトを進めていくうえで、ドキュメントの影響は大きいですか。

Cさん：

あれば非常にいいですよね。大規模、小規模問わず。問題はなかなかドキュメントを完全にすることができない。

Dさん：

前の会社のときに携わった大規模プロジェクトでは、比較的ドキュメントがかっちりしてたんですね。だから今携わっている小規模プロジェクトではもう全然ないので、びっくりしましたね。人によっては要件定義を聞いてきたら、もういきなりプログラムを書くんですよ。だから引き継いでって言われて、「何を見れば」って言うと「コードを見て」と言われて（笑）。

Cさん：

ドキュメントもすぐ劣化していきますからね。たぶんどこの人でも結局はソースコードを見て……。動いているものが真実なので。

編集部：

なるほど。では小規模の場合はどうですか？

Cさん：

ありますね（笑）。いちばんつらかったのは、当時リーダーをやってらした方が急に長期間休まれるということがあって。そのときはすべての管理をそのリーダーひとりにお願いしていたので、代わりにだれかをリーダーに立てないとプロジェクトが進まない。じゃあ現場の仕事をいちばん知ってる僕が代わりにリーダーということに……。まだ2年目の初めくらいで（笑）。でまた、リーダーがお客様に約束した内容とかをドキュメントに一切残してなくて、非常につらかったですね。あのとき初めて夢の中でも仕事してて……。夢で仕事やってるんですもん、びっくりしますよ（笑）。

編集部：

Ｄさんはそういうご経験はありますか。

Dさん：

１回ありますけどね。そのときはリーダーさんと私が合わなかったんですけど。やり方が違ったんですよね、私の場合は。その人はCOBOLからやってきている人で。Webシステムはこういうふうには作れないと言っているのに、JavaをCOBOLで書けって言われて。それは無理だと（笑）、どうしてもしたいならCOBOLで書いてくださいって言ったんですけど。結局、部長が来たときに「無理です」と言ってなんとか回避しました。

プロジェクト内の情報共有・仕事の進め方・やりがいに関しては、主に大規模の欠点・小規模の利点についてお二人の意見が集中した。早速、それぞれの理由について聞いてみたい。

編集部：

情報共有という点ではいかがでしたか。

Dさん：

前の会社（大規模プロジェクト）で、外部からリーダーを連れてきたことがあって。リーダーが外部だと教えられないデータがあるんです。発注元の規定として一次請けまではいいんですけど、その下はダメだったんですね。そのことでメンバー内の情報共有に支障が出て、非常に仕事がやりにくかった記憶があります。

編集部：

Ｃさんはいかがですか？

Cさん：

大規模になると情報共有しきれないですよね。メーリングリストとかでメールが飛ぶんですけど、1日100件～200件とか飛んでくると全然見切れない。それでリーダーから「前、メールしたけど」とか言われても（笑）。

Dさん：

私の場合は掲示板で、自分に関係するところだけはチェックしてましたね。それ以外はもういいやって。

編集部：

なるほど。現場レベルではどうにもできない問題点はほかにもありますか。

Dさん：

プロジェクトが5年あって、結構最初から携わっていればここがおかしいとか言えるんですけど。その中のテスト段階の１年とかだと、おかしいと思っても現場レベルではどうにもならないんですよ。「この動きは明らかにおかしいし、ユーザビリティの点でも使いづらいだろうな」と思っても、上からの指示どおりに作らないと。ただおかしいと思ったら、リーダーには言いますけどね。
でももう無理なんじゃないですかね。本当におかしかったら戻す必要はあるんでしょうけど。大規模の場合、実際使っておかしいと思っている人の顔も自分からは見えない訳ですから。今みたいに小規模でおかしいとわかったら、それは焦りますよね（笑）。怒られるし、作り直さないとだし。

編集部：

お客様の近くで仕事したいというのはひとつの大きな動機になりますか。

Cさん：

なると思いますね。いちばん小規模のときは2人で半年くらいずっとやっていたんですけれども。お客様に直接電話したりですとか、仕様も「こういう仕様のほうがいいんじゃないですか」というのはすぐ言えますからね。システムを作っているという実感があるのは、やっぱり小規模のほうだと思います。

Dさん：

大規模だと段階的になっているじゃないですか。詳細設計する人、プログラム設計する人と。以前、詳細設計している人は、理解しても設計書には書かれなかった仕様があったんですね。その設計書がそのまま下に行って「作れない」ということがあって混乱しました。今の職場ではもう本当にユーザーから直接来たのを、小さければそのまま直してしまいますし。

Cさん：

仕事をしているという実感がありますね。よく言われますけど作業と仕事ってあるじゃないですか。仕事は作業にプラスアルファして、自分の価値を埋め込んで仕事に育てるというような意味合いがあって。そういったところでいうと、大規模よりは小規模のほうが仕事をしているという感覚は強いかもしれない。あまり作業という言葉を使うのが僕は好きではないですね。

　最後に今回のアンケート調査で100人のエンジニアに質問した「大規模・小規模、どちらのプロジェクトにかかわりたい？」の結果を見てもらおう。ほぼ半数が「どちらでもよい」という回答だが、それに肉迫するのが「小規模」を選択した人たちだ。

　もちろん大規模・小規模、どちらもメリット、デメリットを多く含んでいる。「小さくてもいいので、ユーザーの顔がちゃんと見える、反応がダイレクトにわかるところで、一から十まで面倒を見たいと思う（27歳／SE）」という人もいれば「どちらでもPJの業務内容に大差はないが、大規模のほうが達成感がある（40歳／プロジェクトリーダークラス）」という方もいる。

　皆さんは、それぞれの仕事内容によってこの記事の中で共感する部分が違うだろう。片方でしか得られない「常識」、つまりもう一方から見れば「非常識」。またどちらにも共通している「常識」もある。自分の今までの業務内容や周囲の環境をあらためて思い出して、自分のやりたいプロジェクトを今一度、考え直してみてはいかがだろうか。「なによりも経験することが大事で、えり好みするべきではない（31歳／SE）」の言葉どおり、今日苦労したことは必ず次につながっていくはず。

あなたを求める企業がある！

まずはリクナビNEXTの「スカウト」でチャンスを掴もう！

山田モーキン(総研スタッフ)からのメッセージ

今回の取材やアンケートで最も印象に残っているのは、「大小問わず、どちらもやりたい」と考えている方が当初予想していたよりも多かったこと。要するに最終的に仕事の質ややりがいを決めるのは、プロジェクトの規模ではないのかもしれません。また今回の企画、実は以前掲載した公開企画会議にご出席いただいたＬｉｓｐｅｒさんのご提案により実現しました。この場を借りて御礼申し上げます。