システム開発現場の人材不足と慢性的残業の悪循環について

HOT WIRED JAPAN - 前川徹氏の記事「人材不足と慢性的残業の悪循環を断ち切る」より
（※情報源 : BONGOLE BLOG; さん）

上記記事は、システム開発者にとっては常識であるものの、開発職場の上司／上層部や、一般的には認知されていないであろう、

プログラマの生産性は、できるヤツとできないヤツで天地ほど差がある
でもその能力と給与（報酬）に関連性は無い。昇給はあくまで「年次」ベースである

事について、統計的分析結果を踏まえてそれが事実である事を証明してくれています。自分が常に不満に思っている事について、理路整然と語ってくれていたので興奮気味にご紹介。

同記事ではさらに

できないプログラマが引き起こすさまざまな「プロジェクト全体に対するマイナス要素」

について述べた上で、これらすべてが

• 優秀な人材のシステム開発業界離れ
• システム品質の悪化
• 過酷な労働環境

を引き起こしている原因であると論じています。で、最終的には「どうしたらソフトウェア産業（企業）がそこから脱して成長できるか」に繋げています。筆者さん、これまた良い事言ってるんですよ♪も〜、システム開発系企業のお偉いさん、みんなこの記事読む！佐々木さん（ウチの部長さん）もじっくり読む！

え〜煽るのはコレくらいにして、ここでは「イケてない開発者がシステム作るとどんな影響があるのか」について、記事文中からの引用文＆自分の経験をもとに、リアリティを加味したうえでより詳しく述べてみました：

ソフトウェア開発の場合、できないというのはプログラムが1行も書けないのではない。山ほどプログラムを書いているのだが、それがきちんと動かないのである。できないプログラマに割り当てられた仕事をするはめになったできるプログラマは、バグだらけのプログラムと格闘するか、ゼロからプログラムを組むことになる。

できないプログラマは汗水垂らして必死に作り上げるものの、不備が多く、かつ余計に複雑で無駄の多い記述のプログラムを書き上げてしまいます。

不備が多い事を認めて、他のメンバーに対して「カミングアウト」してくれる場合だと、できるプログラマが出来上がったプログラムの中身を見て、不備を直そうとします。このとき初めて「な、なんじゃ！このわけわかんな（略」となるわけです。大抵はできるプログラマが１から組みなおす羽目に（＝できるプログラマに余計な負担がかかる）。

不備が多い事、自分のプログラムがイケてない事を認識できない／あえてしない人だった場合だと、納品一歩手前の「システム結合テスト」フェーズにて、テスト実行者の手によって不備が発見されます。で、

　ここって「ヤツ」が作った部分だよな？
　うん、そうだね。
　プログラムソース（中身）見てみるか...
　こ、こえぇ〜

　（中身見てしばし絶句）

　...いいよ、俺が直すわ。

ってなる場合が多い。結合テストの段階で発覚するパターンは、全体的に後戻り（テストやり直し等）が多くて、余計タチ悪いです。

つまり、できないプログラマの生産性は、実験であればゼロなのだが、現実のプロジェクトでは他のメンバーの仕事を増やしてしまうためマイナスになるのである。

プロジェクト進行中（システム納品前）の「生産性がマイナス」な人は前述のとおりなんですが、僕はもうひとつ重要なポイントとして

保守業務／納品後のメンテナンス業務における生産性のマイナス

にもできないプログラマ君は大きく貢献している、と感じます。それは彼の書くプログラムが「不備が多く、かつ余計に複雑で無駄の多い記述のプログラム」なのでは無く、

不備は無いんだけど余計に複雑で無駄の多い記述のプログラム

な場合に起こります。以下、具体例：

不備は無いのでプロジェクト進行中は誰も文句をつけない

↓

システムが無事納品される。プロジェクト終了。
別途 メンテナンスチームが結成され、以降の追加要件や障害対応に応じる。

↓

いくらか時がたった後にクライアントから「＊＊＊の機能を追加してください」
との改修要望がくる。

↓

メンテナンスチームＡ君が、機能追加で作業工数がどれ位かかるか把握する為、
プログラムの中身を見始める。

↓

（できないプログラマの作ったソースを見てしばし絶句）

↓
「こいつぁトンでもねぇ書き方してくれたもんだ...」

↓

※メンテチームＡ君がユーザに作業工数／見積もりを伝える電話にて :
Ａ君「ご依頼のあった追加要望を実現するには ****万円、nヶ月 ほどかかります」
クライアント「すざけんな。だいたいコレ位の機能でなんで（略」

みたいな。クライアントも、Ａ君が所属する開発会社も、もちろんＡ君も、みんな不幸せな状態に陥ってしまいます。原因はもちろん最初に該当プログラムを書いた「できないプログラマ」君にあるんだけど、プロジェクト進行中は表面的にはなんら問題が無い様に見える。納品後もなんら問題も無い様に見える。クライアントからの追加要望がきて初めて、できないプログラマの作ったものが「生産性マイナス」に貢献するわけで。こういうのって、システム開発ならではの落とし穴だと思います。そして開発者全員がこの事認識しているわけではありません（特に上部層の方々）。

※bashiの関わるプロジェクトでは、こういった「地雷」を事前に潰す為に、できるプログラマが他人の作ったプログラム記述を一字一句チェックしまくる作業をプロジェクト進行中に行ったりします（ソースレビュー）。こうすると地雷は防げるものの、チェックしてくれる人に多大な負担がかかるので「生産性マイナス」であることに代わりはありません。

お互い信頼しあえるメンバー同士だけで仕事できる環境が理想ですね。
でも、そうすると今度は大規模案件に対応できなくなる（人数不足）デメリットも出てきますが。ん〜難しい...

関連サイト

ryyoさんの同記事に対する感想エントリ
前半部分はとっても良いこと言ってると思う。