OSS Consortium


 

日本語 | English

開発基盤部会 Blog

開発基盤部会 Blog >> Article details

2018/10/18

「項目移送処理の実装」後のキャリアパスを考える。

Tweet ThisSend to Facebook | by nishino
 前回アプリケーション開発で、項目移送処理(≒ UIとDB間のデータのIO処理)を実装するだけだと、価値が低い的なことを言ったので、その後どういうキャリアパスがあるのか?を考えてみました。

<アウトライン>

  1. アーキテクト、標準化チームへの移籍
  2. プロダクト開発組織への移籍
  3. R&Dや要素技術担当組織への移籍
  4. デマンド・サイドからユーザ・サイドに移籍
  5. 一般的なキャリアパス、PMになる。


<1. アーキテクト、標準化チームへの移籍>

 ある程度の規模の会社になると、標準化チームなど、SIのサポートなどを行う専門組織があるケースがあると思います。専門家集団ということで一瞬かっこ良さそうですが、実態としては、プロフィット・センタでないコスト・センタで、SIサポートの性質上、単独マネタイズできないので、どうしても業績に引き摺られますし、昨今は、予算圧縮と戦うことになるので大変だと思います。

 私のミッションの根底は、ココ(生産技術)にあるのですが、ココとかココに書いたように、昨今、技術の多様化に追随するために、シフトを図っています。あと、後継育成のために若手に席を譲らないといけないですよね(引き受け手が居ないと言う話もありますが(笑))。

<2. プロダクト開発組織への移籍>

 一般的には、ウワモノ(上位スタック)より、プラットフォーム(下位スタック)の方が価値があると言われているので、こう言うパスも良いのではないかと思います。私も、もう10年以上前からフレームワーク開発を行ってきて、最近、ココに書いたような純ミドルウェアの開発も進めています。

 しかし、昨今、プロダクト部分は、OSSが主流になっているのと、ITビッグ5が強過ぎるので、コモディティ化が激しく、競合するようなものは、下手すると、ウワモノより食えない、プラットフォームになってしまうことも多いように思います。

 「垂直統合型事業モデルを貫いたメーカー系が撤退・縮小」しているぐらいなので、適切にマーケティングを行い、勝てる理屈が適切に構築されているプロダクトを開発して行く必要があります。

<3. R&Dや要素技術担当組織への移籍>

 私も、ビッグデータや、IoT、AIなどに興味があります。しかし、これら、ココとかココとかココで、チョットやってみたんですが、片手間が難しそうなので、若手と同じスタート・ラインに立って、ゼロ・スタートで進むぐらいの気概が必要そうです。

 私の場合は、上記の「1.」、「2.」をやり切って、アプリケーション開発、標準化、認証、フロントエンド系などの各種インテグレーション経験が生きるような形で、ビッグデータや、IoT、AIなどに関わることができるように、今後とも、キャリアパスを検討して行きたいと考えています。

 あと、最近は、要素技術のコモディティ化に伴い、ウワモノとプラットフォームの垣根が低くなってきている気もします。例えば、フルスタック・エンジニアという言葉がありますが、ウワモノ屋さんも、プラットフォームに詳しい必要がありますし、プラットフォーム屋さんも色々なシーンでデマンド・サイドの知識が必要になります。

<4. デマンド・サイドからユーザ・サイドに移籍>

 実は、広島に引っ越す前に、一度、ユーザ企業への転職活動を行って、内定をもらったことがあります。色々ネットの情報を見ると、人材は不足しているようなので、転職市場に出れば、色々と求人はありそうです。

 反面、「ユーザ企業で無双」とか、「ひとり情シス」とか、ネガティブ・ワードもありますが、裁量がある方が魅力に感じるなら、コチラのほうがイイかも知れません(ただ、コスト・センタなので本体の業績が良い所を選ばないと、あまり良くないかも知れませんが)。

<5. 一般的なキャリアパス、PMになる。>

 プラットフォームやプログラミングなどのITスキルに特化していなければ、経験を積んで、PMになるというキャリアパスが一般的だと思います(なお、PMは業務SE出身者が有利らしい)。

 しかし、昨今、PMにあまり魅力を感じないのは、SIerのPMって多重下請け構造の中の難しいポジションで多方面から様々なdisりを受けているタメのような気がします。が、本質的には、PMって「必要な資質に人間性も含まれていたりするので」、非常に難しい仕事なのだと思います。

 ...SIerでは猫も杓子もPM、そして、日式的年功序列制度の中では猫も杓子も管理職というキャリアパスしか無いので、「天は人の上に人を造らず、人の下に人を造らず」だけど人の世界では差がつくから、同じ(会社の)人間なのに権限に差が出て来ます。

 こういう権限を、能力が低い人や、人間性が疑われる人に与えたら不幸になる人が産まれて、≒ 悪になるわけで、「人の上に立って、」「人を動員する。」ってのは、そうならないように責任をもってやるべき、難しい仕事なんだよなぁ。などと考えたりしました。



 ...実は、この記事を書いた動機に、1年ぐらい前の話になりますが、フレームワークと言うかテンプレートと言うか、海の物とも山の物ともつかない、オレオレ的何かを指して、「それが無ければ10倍の生産性で書ける。」と自称する人にTwitterで突っ込み入れたら即ブロックされたという話があります。

 しかし、この辺を見ると、やっぱり、それはエンジニアリング的にダメだと言う話だと思います。簡潔に言えば、「オレオレ的何かの品質の問題は別の問題であって、個人レベルの素書きでプロジェクトが上手く行けば誰も苦労はしないよな。」と言う話です。これは、解り易い論点のすり替えで、無責任な事を言うなよ。と思いました。

 究極、多重下請け構造が無い商習慣にすれば良いと思うのですが、昨今、
  1. 再委託禁止の一括外注・フルオフショア
  2. ICT需要の多様化(ユーザ、Web、ゲーム系)に伴う転職市場の活性化
  3. 労働集約的な働き方への手入(働き方改革)
 などがあり、案外、徐々に解決するのかもしれません。
09:00 | Impressed! | Voted(0) | Comment(0) | ご報告