現在社会人4年目、27歳。今のところプログラマとしてのキャリアのみで、SE経験を中々積む事ができておらず、自分の行く末を非常に危惧している。以前からのオフショア化の波に加えて、昨今のクラウドやSaaSの台頭により、プログラミング以下の仕事すらどんどん減少していく状況である。エンドユーザーとの交渉スキル等、SE経験で得られるスキル無しでは生き残れないだろうから。
うちの会社、SEのパイは一応あるにはあるのだけど…少ない。プライム案件で直接エンドユーザと遣り取り可能なポジションであれば尚更（大抵は、プライムであってもお客さんの情報システム部までしか接触できない模様）。さらにその少ないパイは、どうも社員の大半を占めるおっさんCOBOLerに優先して割り振っているみたいなんだよな。実際、上期の中間面談で「枠は無い」って言われたし、同期や1～2年上の先輩の様子見てても難しそう…。周りを蹴落とすぐらいの力がお前に無いからだ！と言われれば返す言葉も無いですが…ただ、一つ言い訳させて貰いますと、
若い社員にSE枠を付与
↓
あぶれたおっさんCOBOLerはプログラマ枠へ
↓
しかしこの人達、年功序列制度のせいで現在高給
↓
さらに、オープン系言語等の再教育コストがかかる。
てか基本的に勉強する気がない。
↓
追加コストを払ってまで、高給取りを単価の安いPGとして働かせるのは利益率悪すぎ
↓
SE枠はおっさんで
…多分、こういう事情もあるのだと思います。
他には、僕はプログラマとしては（うちの会社の中では）かなり生産性が高いので、お客さんやプライムベンダのペースに振り回されるSEとしてより、プログラマのままとしておいた方が全体最適だ、というのもあるかもしれない。
はい、前述の通り、僕はプログラマとしては（うちの会社の中では）いい仕事してきたんです。また、SEが作ってきた仕様・スケジュールに対し「このA機能を先に作った方が、かくかくしかじかで効率いいと思いますよ」とか「B機能の○○ロジックは規模がでかいので、1機能として切り出して分業させた方がよいのでは？」等、周りに比べたら積極的に発言してきた方だと自負していますし。「これでもまだ足りないのか？」「相当パイが少ないのか？」とずっと思い悩んでいた最中、最近ふと疑心暗鬼に取り憑かれた。
「できる人間だからこそ、SE経験積ませて貰えないのでは？」と。
というのは、僕が新人の頃の新人歓迎会にて、つまり歓迎されてた時「できる人間はすぐ辞めるんだよね～」と言われたからだ。新人研修での成績がズバ抜けていたらしく、また入社前にソフトウェア開発技術者資格を取得済みだったこともあり、『できる人間』と見なされたらしい。「何でうち（の会社）来たの！？」ってのもあったな。もうホント度肝抜かれましたよ。新人歓迎会でそんなこと言うか！？
つまり、僕が思うに「いつ辞めるかしれない『できる人間』に、貴重なSE経験を積ませるのは勿体ない」という考えが根底にあるのではないかと。
完全なる僕の思い込みであれば、それは本当に会社に対して申し訳ございません！って話ですが、でもそういう思い込みが発生してしまっている時点で、会社を信頼できていない事が浮き彫りに…
ということで、そろそろ転職を考えないといけないのかなと思い始めている。まぁ、この大不況にSE経験無しが飛び出した所で仕事なんて見つかるわけないだろうから、すぐには動くつもりはないですが。ただ準備だけはしておこうと、最近、これまでの技術経歴の棚卸しをしました。で、それによって発覚した驚愕の事実。
「俺、Java初級じゃねぇか！」
よくよく考えたら、仕事ではオブジェクト指向プログラミング（以下、OOP）した記憶が無く、手続型ロジックしか経験無いことに気付いたんですよ。で、Javaプログラマの初級・中級の定義を調べてみたら、わんくまの方がこう言っています。
「Javaはコーディングができるという初級者と、プログラミングができるという中級者の間に大きな壁があります」
「…クラスを利用できる初級者とクラスを作れる中級者・上級者との間の壁…」
どうやら、OO使ってクラス設計してない内は初級だと。Javaで手続き書いているだけなら初級だと。そういう内はプログラマではなくコーダーだと。
はい、僕、クラス設計したことなく、手続き書いているだけの、コーダーです…
この3年半、様々なJava案件を行ったり来たりしてきたのだが、殆どの案件が「プログラミング不要！」「OO不要！」を謳っている内製向け商用フレームワークを適用した案件だった。OOPの概念は無く、ただ手続きを羅列していくだけの作業。UMLとかの『クラス図』を見た事がないという事実が、OO使ってない事を物語っている。ていうか、FWに依存する画面系はともかくとして、共通部品くらいはOOで作ればいいものを、設計担当者が悉くOOを使おうとせず（そもそも分かってない？）。部品のロジックパターン毎にクラス分割して多態性使って呼出部品切り替えればいいところを、分割単位はメソッド、呼出切替はif文…
フレームワーク特有のスキルはかなり身についたが、スキルって言っても『可能・不可能なこと』『向き・不向きなこと』は何かとか、あとは設定パラメータをどれだけ知ってるかってなもんで、とてもスキルなんて言える代物じゃない。それに何より、マイナー（※1）。上司は「マイナーだから競合相手がいなくて良い！」って言ってたけど…単純に情けない話だと思うし、それに繰り返すが『内製向け』FWなので、お客さんも徐々に内製にシフトしており、確実に発注減ってきてますよ！今年夏の現場なんか、詳細設計すらやらせてもらえなかったんですけど！
※1：懇親会とかで聞いてみるんですけど、まあ知ってる人いませんね。唯1人知ってた方は「使いにくい！」って仰ってました…
実務経験 ：3年半
経験言語 ：Java 約3年 ※但しOOP、クラス設計、5.0以上の経験無し
他は.NET系を少々
フレームワーク：それどこの？
何てこった、俺、空っぽじゃねぇか。市場価値なんて無いに等しい。SEはおろか、プログラマですらなく…スードラの更に下に実はバリア（アンタッチャブル）という最下層階級がある事を知った時並の悲しみ、と言ったら大袈裟だけど…
果たして俺は這い上がれるのだろうか？
＊
そんな俺にも、やっと中級者へのステップアップのチャンスが。今月仕事はピュアJavaによる計算ライブラリの基本設計～単体テスト。基本設計にはクラス設計も含まれている。バージョンも初めての5.0。よっしゃ！計算ロジックは5パターンあり、全パターンで共通のロジックもあるので、これは継承と多態性の使い処だ。計算パターン毎にパラメータが異なるので、それらはそれぞれBeanクラス作って…といった感じで、今月はいつになく張り切って楽しんでいます。
ただなぁ…プロジェクト規約でクラス名を『ABCDX(0～9の連番)』とIDみたいにしなきゃいけないんですけど、その『0～9の連番』ってあるように、クラス数10個以下に抑えないといけないっぽいんですよ。前述の通り、計算パターンで5あり、それぞれのパラメータ用のBean作ったらもう在庫切れちゃうんですけど…『規約』というより『制約』だなこりゃ。全く。制約があって燃えるのは恋愛だけだっつーの。
あと単純に、Beanのクラス名がIDみたいな名前だと、分かりにくいったらありゃしない。『囚人クラス』と呼んでますよ。
ちなみに、JUnitも初めて仕事で使いました。やっぱり再テスト時は物凄く便利ですね。心置きなくリファクタしまくれる。けど、テストコードは単体テスト仕様書とは見なされない…
