業務系プログラマを目指すということ

雑談

自分が業務系プログラマになって約半年が経過した。

結論から言うと自分が業務系プログラマになったのは失敗だったと断言できる。

 

もし業務系プログラマをこれから目指そうと思う人がいるなら、

この記事の内容を一つの参考にしてほしい。

 

まず、自分が考えてる業務系プログラマの適正項目は

  • プログラムが苦手で可能ならコーディングしたくない
  • 単純作業が好き
  • 新しい技術に興味が無い
  • スーツを着ることに抵抗がない

最後のは怪しいけど、まず上の3項目に関しては然程外れてはいないと思う。

その根拠となるのが業務系システム業界の体質になる。

業務系システム開発で頻繁に登場する言語は

この辺りが鉄板になってくる。

これ以外の言語はまったく使われず、むしろ却下される事が多い。

詰まるところこの3つさえ使えれば大体の案件には就くことができてしまうので

勉強をする必要がなくなってしまう。

更にある程度経験を積んで30代を迎えると肩書はシステムエンジニア(SE)になり、

設計や顧客との打ち合わせに業務がシフトするのでコーディングは不要になっていく。

業務系プログラマにとってプログラムとは

SEになるための手段となってしまっているわけだ。

なので、少なくともプログラムが好きですという人は絶対に目指してはいけない。

 

もう一つ、顧客側にも問題がある。

それは納品物に対する品質の保証を開発側に要求してくることだ。

勿論品質の保証を求めることは顧客側にとっては当然のことだし

それを否定するつもりは毛頭ない。

ただ、「品質の保証」の仕方に問題があるのは間違いない。

 

品質の保証には俗にいうエビデンスが用いられる。

エビデンスが何かを説明すると...

作成したシステムが正常に動いているかどうかを確認するために

テストを行い、その結果を画面をキャプションしてExcelに貼り付けていく作業のことだ。(会社やプロジェクトによって方法は違うけど、大体こんな感じ)

開発規模にもよるけど大体1機能30枚ぐらいのキャプションが貼り付けられる。

機能数が50なら1500枚。

それも顧客に納品するものなので綺麗に取って綺麗に貼り付ける必要がある。

....聞いただけでも効率が悪くて生産性が無いことがわかる。

この辺に文句をつけ始めるとキリがないので割愛するけど、

とりあえず物凄い規模の単純作業だということは理解できると思う。

(勿論テストが不要な訳ではないのでテスト自体は必要)

 

なら別の形の「品質の保証」をすればいいんじゃないか？

とも思うけど、残念なことに顧客がExcelのエビデンスを求めている以上、

それは諦めるしか無い。

いくら効率的な方法を見つけても、顧客側に受け入れられなければ意味は無い。

だから永遠とExcelエビデンスは量産され続ける。

業務システム開発に携わる限りこのExcelエビデンスという地獄から逃れる術はない。

 

ここからは主観も混じるけど、

業務系プログラマ及びSEはサラリーマンと大差がないといっても過言じゃない。

ちょっとプログラムが出来るサラリーマンで、エンジニアではない。

勿論、それが駄目だと言うつもりはない。

実際、SEになれば収入もある程度安定していているし、

会社によっては休みもしっかりと確保されている。

普通に生きていくには悪く無い選択肢だと思う。

ただ、技術者として生きていくというのなら話は別で、

そういう人が業務系プログラマになると悲惨な思いをすることになる。