読者です 読者をやめる 読者になる 読者になる

アーキテクチャをスマートに。

株式会社ネオジニア代表。ITアーキテクトとしてのお仕事や考えていることなどをたまに綴っています。(記事の内容は個人の見解に基づくものであり、所属組織を代表するものではありません)

エンジニアのお仕事

考え方

僕は大阪でITエンジニアの仕事をしています。

ここ数年は受託開発がほとんどです。

このブログでは主に、試行錯誤した体験や、考えていることについて書いていこうと思ってます。

ところで、受託系のエンジニアの仕事って、どんなものか知っていますか?

世間一般では、SEとかシステムエンジニアとか言われています。
自分で言うのもなんですが、エンジニアというのは結構大変なんですよ。


とくに最近、僕が問題を感じているのは、「設計がイケてない」システム開発が多い、ということ。

設計がイケてないと、どうなるのか?

システム開発の仕事は、ものづくりの仕事です。ものづくりには工程があります。だいたい以下のような工程です。

  • 受注
  • 要件定義
  • 設計
  • 製造
  • 試験
  • 納品

要件定義工程では、顧客が何を求めているのかをヒアリングし、どのようなシステムを作るかを決めていきます。

設計工程では、システムの全体構造を決定し、どのような仕組みでコンピュータを動かしてシステムとして実現させるのかを考え、設計図(設計書)に落とし込んでいきます。

そのあとは設計図にしたがって作っていくんだけど、設計自体に無駄が多かったり、最適な構造でなかったり、効率が悪かったりで、決められた工期ではとてもじゃないけどうまく動くものが出来ない。

けど「出来ません」とは言えないので、製造要員を増やしたり、休日出勤や徹夜をしたりで、担当エンジニアが地獄を見ることになる。

手戻り覚悟で設計工程をやり直せばいいんだけど、それを出来るエンジニアはほどんどいないし、手戻りすること自体を嫌う人が多い。

そんなわけで開発プロジェクトは炎上する。

炎上すると、優秀なエンジニアを投入して「なんとかしてくれ」と火を消そうとする。よく「火消し部隊」とか言われる。

肝心の設計を担当したエンジニアは、責任追求されるわけでもなく、顧客の目の見えないところへ追いやるかのように別のプロジェクトへ移され、教育を受けるわけでもなく、また同じことを繰り返す。

火消部隊となっている優秀なエンジニアは、理不尽な消火活動にあてがわれるので、設計工程に関わるチャンスは少なく、なかなかスキルアップできずに苛立つが、会社としてはとりあえず火を消さなくてはならないので、火消部隊を引き上げるわけにはいかない。

そんな仕事が何ヶ月も続くと、当然辞めていく人や、オカシくなってしまう人も現れる。

こういう現象は業界用語で「デスマーチ」と言うが、ここまでひどくはないにしても、多くのシステム開発の現場でこれに近いことが起こっている。


僕は、こんなITエンジニアの現状を変えていきたい。