エンジニアのやる気は報酬だけじゃ維持できない：開発チームを作ろう（2）（2/3 ページ）

[佐藤大輔，オープントーン]

「中・元請け企業の体質」について考える

　多くの場合、ある程度の規模のプロジェクトで「ある程度の数の技術者」を集めるとなると、必然的に複数の会社をまたがって作業をする技術者が現れます。すると、どうしても、「元請け、1次請け、2次請け、……」という構造にならざるを得ません。

　簡単なことですが、非常にコストの掛かる技術者を1つの企業で（開発作業の）ピークに合わせて雇用していたのでは、企業の維持コストにおける人件費率が跳ね上がり、企業体力・競争力を著しくそいでしまいます。かといって、そういった体制を維持しながら人件費を圧縮しようとすれば、必然的に人材の質の低下を招きます。「人材の質の低下」が高コストと高リスクに直結してしまうこの業界では、その行為自体が無意味ですし、むしろ危険であることは皆さんもご存じのとおりです。

　そこで、必然的に2次請け以降の「出向技術者」が必要になってきます。

　ここにあるプロジェクトがあります。開発から結合テストまでで6カ月の短期プロジェクトです。業務内容は金融システム開発の案件。チームはプロジェクト全体で50人ほどですので、「中規模」といったところでしょうか。

　このプロジェクトにNさんが入ってきました。Nさんは2社の仲介を得てこのプロジェクトに参加してきました。Nさんは36歳、経験からいえば中堅エンジニア。オブジェクト指向での3年程度の実装経験があります。彼は本来フリーのエンジニアです。今回元請け企業との間に2社の仲介を挟んでいます。実際にNさんの実装作業を見ていると、「手続き指向の実装をJavaに押し込んでいる」感があり、品質に対する若干の不安を感じました。ですが、一実装者として、仕様書を基に実装を行い、テストを一通りこなすという1人月のタスクはこなせるタイプです。先進性や、技術的指向が高いわけではないので、フレームワークなどの基盤部分は任せられませんが、1人月分の作業者としては「悪くない」範囲でした。

　しかし、彼のプロジェクト内での評判は良くなく、実装作業のピークが過ぎ次第、予定を前倒しして「お引き取りいただいた」次第です。幸いプロジェクトで「表立って問題になる」ほどの状況には至りませんでしたが、プロジェクトにかかわってもらった以上、惜しまれながら去る程度の評価は残していただけたらばと思いました。

　なぜ、Nさんはこの人手不足の業界で、一応水準程度の能力を持ちながら「お引き取りいただく」ことになったのでしょうか？ 十分に作業が残っているにもかかわらずです。なぜ？ 「普通の人」では活躍の場がないほどITプロジェクトとは過酷なものだったのでしょうか？

　投票結果第1位である「元・中請企業の体質」。ここで、その問題の本質をこのNさんを題材に考えてみましょう。

図2 関係図

「プロジェクトの成否には興味がない実装者Nさん」

　さて、彼のプロジェクト内での状況はどうだったのでしょう？ 彼は、設計から実装までを担当するSEを期待されてプロジェクトに呼ばれました。すなわち外部設計の後半部分の担当者ということです。インターフェイスやエンティティの設計はだいたい終わっていましたので、外部設計の中でも、詳細部分から実装までの担当者として呼ばれたわけです。

　開発初期で上流工程が追い付かないという、短期案件でありがちな状況が発生し、Nさんのレイヤー（詳細設計から実装）まで、あまりスムーズに作業が落ちてきません。そのような状況で、Nさんは心配するわけでも、状況の改善を図るわけでもなく上流工程作業の完了を日々座って待っていました。

　こういった場面でモチベーションが高い技術者は、技術調査の手伝いや、あるいは外部設計の手伝いを行い、プロジェクトに貢献しようとします。さらにモチベーションの高い人はプロセス全体をどうにかしようと考え始めるものです。しかし、Nさんの場合はあくまで「自分の作業」が落ちてくるのを待ちます。

　実際今回のプロジェクトも30人ほどの実装技術者のうち、半分ほどのメンバーは積極的に「自分にできること」を探してチームとプロジェクトへの貢献を図ろうとしていました。そんな日々の中、ようやく、上流工程の作業が進み、Nさんの担当分野に作業が落ちてきました。しかし、今度は上流工程が押した分、当然納期までの詳細設計実装の作業は苦しくなってしまいます。もちろん「Nさんのせい」ではありません。だからNさんには定時に帰る権利があります。

　彼の分担が期限までに終わっているか否かは彼にとっては問題ではありません。時間でお金をもらって時間で作業しているのです。プロジェクトの成否という面では、彼は最初から最後まで責任を負っていないのです。

　なるほど……、正論です。しかし、同じ立場の他の技術者たちが「正論を吐いて」一定量の作業を一定の時間内だけであくまで実施する彼の作業を大幅に肩代わりし始めると、さまざまな問題が起き始めました。

　彼の作業を待っているのが工程的に無理なので、彼の作業をほかの人がオーバーラップして行い始めます。特に品質が優れているわけでもなく、「動くから合格」という程度の品質です。なのでほかのチームメンバーは「もういいや、自分たちで作ってしまおう。土日いっぱいあれば結構いけるさ」と思い始めます。

　こうして彼はプロジェクトのお荷物になり始めました。最低限度合格点だったはずなのに。何もおかしなことはいっていないのに……。なぜか、急速に彼はチームの「お荷物」になっていきます。

　平均して1人4ユースケースほど担当していたのですが、いつの間にか彼の手元には1ユースケースだけになりました。

　「上流工程の完了が遅かったので、テストまでは無理、この機能も無理……」という彼の説明を尻目に、モチベーションの高い面々が「間に合わせる」ために、深夜土日もつぎ込んでアプリケーションを完成させていってしまいます。

　さらには、結合テストにおいて、複数の障害が出たときに「彼の実装を直すより作り直す方が早い……」という人が現れ出し、ますます、彼の「実績」は消去されていきます。

　最後に、彼の手元には彼に対するチームメンバーの冷たい評価と、仕様が早く固まった簡単で小さな機能1つが残りました。

　もともと、彼は正論を述べていますので、報酬や契約にまで言及されることはありませんでした。しかし、明らかにメンバーの誰一人、あるいは顧客（本記事では顧客＝元請け企業）の誰一人、彼に対しての感謝の念も尊敬も親愛の情も何も抱いていないように見えました。おそらく「もう1度Nさんと仕事をしたい」とは思っていないでしょう。彼が、「何らかの階段」をプロジェクトの経過とともに上っているとはいえなかったでしょう。