前から書いている「項目移送おじさん」系の話しの続きです。取り敢えず、書いてみましたが、わりと駄文になってしまったので、暇な場合に読んでみて下さい。
<項目移送おじさん>
Twitterを始めてみて知ったんですが、
世の中にはいろんな「おじさん」がいるんですね。
- staticおじさん
- jenkinsおじさん
- strutsおじさん
- カール(curl)おじさん
なんて言う
tweetを発見して「XXXおじさんとは、旧世代のテクノロジをdisるツールか。」なんて思いました。しかし、私の良く言う「項目移送おじさん」は、最新のテクノロジを使っていても「項目移送おじさん」(略して項おじ)ですケドね。残念ながら。
IDEインストールすれば誰でも自称エンジニア。アプリ・エンジニアの良くないところは、インフラ・エンジニアと違って敷居が低過ぎることなんじゃないか?と思います(しかも、人月単価で差がつかない)。
そう言う背景があった上で、世の中、IT土方とか、デジタル炭坑夫なんて言う用語がありますが、確かに、私も、「
RFC見ながらネット検索しつつライブラリ開発している時ってプリミティブやスニペットを採掘(マイニング)している感あるなぁ。」と思うので、きっと、私も「デジタル炭坑夫」だと思います。
そう言えば、褒めてるか貶してるか解らないけど、「海外のデータは正規化されて無いことが多いので、NoSqlやETL需要が高いらしい。」なんて話を聞いたことがあります。日式「項目移送おじさん」の平均的レベルは高いんだと思いますが、給料的には厳しいものがあります。また、能力&給料的に上に振れるのが少ないのは良くないと思います。
...色々と不満が多い界隈だと思うので、得してるブルーカラー・ソフトウェア・エンジニア、損してるホワイトカラー・ソフトウェア・エンジニア。損得関係なく、ソフトウェア・エンジニアに向いている人 / 向いていない人。のグラフに自分をプロットしてみるとイイかもしれません。
そして、 " 転職 " か、「脱!項おじ」して、
" 天職 " をGETできたら良いのでは?と
♨<UIサブシステムとフレームワーク>
で、
これも前から書いている「UIサブシステムとフレームワーク」系の話の続きですが、「項目移送おじさん」と「UIサブシステムとフレームワーク」と切っても切れない仲です。何故なら、画面とDB間の項目移送処理を実装ボリュームは、画面側が7・8割行くからです。これはもう殆どが、UIサブシステムとフレームワークと戯れている感じですね。
UIサブシステムとフレームワーク系、色々ありますが、その知識自体を「売り」にすると、プロダクト化して売るという話にならないので、面積仕事になります。しかし、面積仕事なのに、非常に速いライフサイクルと流行り廃りのため、淀みに浮かんで、かつ消えかつ結びて、久しくとどまりたるためしのない「泡沫(うたかた)」感が強くリスキーで、私は、不幸を生んでいるように見えて嫌なんです(好きでやっているのは否定しないですが)。
で、面積仕事なら生産性が高いモノの使いたいのだケド、一番マトモなのが、何年前の技術だか解りませんが、未だにWindows Forms(若しくはWPF)なんじゃないか?と。思ったりします。そう言えば .NET Core3.0 にもWindows Forms(、WPF)入ったし。そう言う意味で、トレンドの形成は、モノが良いか悪いか。では無い気がします。
先日、デスクトップ系もUI部分のデザインは、HTML/CSS系にシフトして行く。みたいな話をキャッチ・アップしていますが、まだ揺れそうですので、今回は、これに対しては言及しません。
一方で、私は、最近、シェアとか面積とか、あまり気にしなくなりました。v1は面積系(基幹系スクラッチ開発のサポート)だったケド、v2からはサーバー系ミドル(サービス向けの認証基盤)に振りました。コレはコレで「認証おじさん」と呼ばれる界隈だったりしますが。
プラットフォーム、ランタイム、基盤の類は面積が必要ですが、サーバーやアプリは、あまり面積系の話の影響が無いと思います。Lua(というスクリプト言語)で頑張ってるプロダクトもありますし。
<オチ?>
オチは特にありませんが、技術やるのも大変なので、技術者としては、色々キャリア・パスは考えていきたいものです。色々考えると、サプライサイドは縮小の一途だと思うので、デマンドサイド(≒ユーザ)の「IT活用」をイメージして仕事した方がイイんじゃないか?と思ったりしています。