システム開発手法は変えていくものであることを中堅エンジニアは知っているのだろうか

新人で配属されたエンジニアは最初にアサイメントされたプロジェクトチームのやり方で、システム開発の方法を刷り込まれてしまうんですよ。これ自体は誰もが当たり前だと思ってしまうのだけれど、これ、ほんと怖いので。

何が怖いかというと、アジャイ開発のスクラムでも、まだほとんどのプロジェクトで採用しているウォーターフォールでも同じなのだけれど、最初に刷り込まれたシステム開発手法が、－いや、システム開発手法と呼べるものならいいのだけれど－、新人エンジニアの標準になってしまうのです。

基本的な考え方として、システム開発におけるシステム開発手法はその対象のプロジェクトに最適化しているので、テーラリングされているのです。つまり、局所最適化されているので他のプロジェクトに合わせようとすると無理無駄が生じるのです。

理想というか、あるべき姿は、基本的なシステム開発手法の雛形があって、それをプロジェクトの特性でテーラリング、個別最適化するものです。

でも、新人エンジニアが最初に出会うプロジェクトでのやり方以外を学ぶ機会がないので、現場で覚えたシステム開発手法が正だと思って覚えてしまう。

問題なのは、それは変えてはいけないものだ、そうあるべきだと位置付けてしまうことです。本来は、雛形からテーラリングで変えるのが当たり前なのですから、真逆に理解されてしまうとよりよくするために変えていくという考え方がなかったことになってしまうのです。

さらに拍車をかけるのは、チームのルールを守れと徹底すること。これはこれで必要なことなのですが、それはチームの合意を持って変えていくという方針も合わせて示さないとこれが起きるです。

今、あなたが現場でやっているシステム開発はその現場の方言でしかないのです。それもプロジェクトに最適化されているかどうかもわからない。

そうしたことを考えたことがないなら、それは多分、プロジェクトの中で無理無駄を多くやっているのです。どうしてかはすでに上述してきたとおり、テーラリングを継続的に行なっていないから。

新人エンジニアはもちろん、中堅エンジニアも今のプロジェクトで採用されているシステム開発手法がそのプロジェクトで最適、つまり、開発の無理無駄がないかを毎日疑ってかかってみなければならないのです。そして無理無駄を見つけて少しでも開発が楽に楽しく、期待する品質を確保できるやり方を探求しなければ。

ベテランエンジニアはいいのかって。ええ、言われたままやるエンジニアが多いですよね。そうならないようになって欲しいのですよ。