エンジニアのお仕事 - アーキテクチャをスマートに。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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