【経験談】こんな人が開発メンバーにいるとシステム開発は失敗する

私は現在、ホームページの制作やブログの運営などで収入を得ていますが、以前はシステムエンジニアとして会社で働いていました。

システム開発は難しく、スケジュールに間に合わなくて開発コストが膨れ上がったり、システムのリリース後に障害が多発したりと、プロジェクトが失敗することも珍しくはありません。

システム開発が上手くいかない理由は色々あると思います。この記事では、開発メンバーにこんな人がいると失敗するという私が経験した事例を紹介します。

システム開発ではこんな人に要注意

私が気をつけた方が良いと思う人は、すぐに怒る人です。コミュニケーション能力以前の問題として、常にイライラして他人に強く当たる人です。

このような人が大規模なシステム開発の中心メンバー、例えば顧客と打ち合わせをして要件定義を行う人や、開発環境を構築したり開発マニュアルを作成したりする技術部門のトップなどにいると、プロジェクトが失敗する可能性があります。

私が経験した大規模システムの開発では、技術部門のトップがすぐに怒る人でした。その人を「Aさん」として、もう少し詳しく紹介していきます。

不必要な物音を立てる

仕事をしていると、やたらとキーボードを叩く音がうるさかったり、貧乏ゆすりをしている人がいます。

それはまだ仕方のない部分もありますが、意図的に不快な音を出す人は要注意です。

Aさんは、仕事中にずっとペンをカチカチ鳴らすだけにとどまらず、そのペンを意図的に何度も机に落とすことが日常でした。

話しかけにくい雰囲気づくり

個人的には、上司は部下が話しかけやすい雰囲気づくりをすべきだと思います。

基本的に上司の方が知識や経験があるので、部下が自分で調べても分からないようなことは相談してもらえば、無駄に考える時間が減ります。

しかし、Aさんは真逆でした。常に忙しいアピール、残業で疲れているアピールをして、絶対に話しかけるなというオーラを出していました。

どうしても分からないことがあって誰かが相談しに行くと、露骨に嫌な顔をしてため息をつき、「結論は？」「そんなことも自分で考えられないの？」とすぐに怒っていました。

自分に優しく他人に厳しい

大規模なシステム開発になると、プログラミングのスキルも人によって差があります。

なぜなら、プログラミングは基本的に人件費の安い若手がするものだからです。入社してから何年も修行を重ねて、システム開発にデビューするわけではありません。

私の場合も、ほとんどプログラミングが未経験の状態したが、入社して二年目には大規模システム開発の中心メンバーとしてプログラミングをしていました。

経験が少なければ、当然ながら開発スピードが遅かったり、バグがあったり、ソースコードが分かりにくかったり、無意味な処理が書かれていたりと、悪い部分があるでしょう。

Aさんは、暇そうに他人が書いたソースコードを眺めては、「なにこれ」「めちゃくちゃじゃん」と言っており、それを書いた人を呼び出して文句を言っていました。

純粋にアドバイスとして伝えるなら良いことですが、尋問するような口調で怒ることが目的になっていると感じました。

また、厳しいスケジュールで毎日遅くまで残業しているのに、人員を増やしたりアドバイスをするわけでもなく、スケジュールが遅れているプログラマーを呼び出して「いつ終わるの」と建設的ではない怒りをぶつけていました。

どのような結果が待っているか？

Aさんだけが原因とは思いませんが、結果としてプロジェクトは失敗しました。

数年間の開発を経て一応リリースは終わりましたが、大幅にスケジュールが遅延して、システム障害が多発しました。

プログラミングをしていると分からないことが出てきます。技術的な実装方法が分からないこともありますが、私の場合は仕様が分からない、業務要件が分からないことの方が多かったです。

なぜなら、顧客と打ち合わせをしてシステムの仕様を決めるのは、プログラマーではないからです。

詳細設計まで要件定義をした人がやってくれるなら良いですが、実際には抽象的な基本設計書があるだけで、プログラマーが詳細設計、プログラミング、単体テストを行っていました。

ひどいときは、基本設計書も何もなく、口頭でこんな感じの機能を作ってくれと言われたこともあります。

仕様が分からなければ、当然ながら上司に確認すべきだと思います。しかし、誰もがAさんに話しかけにくい雰囲気だったので、確認せずに何となくで機能を作っていました。

また、将来的に大きな問題になるであろう全体的な不具合に気がついても、それを報告すれば自分で対処するように怒られるだけなので、誰も報告せずに黙っていました。

その結果、テスターが結合テストや総合テストをする段階で仕様との相違やバグが多発して、予定にない大幅なスケジュールの遅延が発生しました。

後の工程になればなるほど、影響範囲が広がってシステムの修正は大変です。ある部分を修正することによって別の関係ない部分にも不具合が発生する「デグレード（デグレ）」もあるので、テストケースが増えて時間がかかります。

問題はスケジュールの遅延だけではありません。Aさんと一緒に仕事をしていた人は、ストレスでうつ病になったり、会社を退職する人が続出しました。

このように、すぐに怒る人がシステム開発のトップにいると、スケジュールが遅延したり、会社の退職に追い込まれる人が出る可能性があります。

まとめ

このような社員はそもそも出世できなかったり、システム開発の中心メンバーにならないと思うかもしれませんが、そんなことはありません。

例えば、これまでは比較的小さい案件を担当して一人でシステム開発をしていたときは良かったけれど、メンバーが増えて立場が変わることで問題が顕在化するかもしれません。

また、すぐに怒るけれど技術力はずば抜けていることもあるでしょうし、他に良いメンバーがいないから仕方なくというケースも考えられます。

このような人を開発メンバーの中心にするかは、基本的に上司が決めると思います。運が悪ければその人の下でシステム開発をすることになり、地獄の時間が待っています。

理不尽な要求にも耐えて自分を成長させるという考えもありますが、精神的な病気になってしまったら意味がありません。部署異動の希望を出したり、転職をすることも選択肢の一つとして考えるのが良いでしょう。

また、副業が許可されている会社であれば、コツコツと副業を続けて、退職できる準備を進めるのもおすすめです。