ユーザー系システム子会社におけるエンジニアのキャリア形成②
この記事の目的
この度10数年をいわゆる金融系のユーザー系システム子会社にて過ごしつつ、某外資のテック企業に転職をしました。スキルが付きにくいと言われるユーザー系子会社において技術的なスキルをどう付けれたのか？過去経験したプロジェクトなどでどのような事が有効に働いたのか？などを振り返りたく情報をまとめるものです。自身のキャリアの整理であるとともに、同様にユーザー系システム子会社に勤める方や、これから就職を検討している新卒の方に何か再現性のある気づきや情報を残せたら…と思い書き始めました。複数回(3回)に分けて書く予定です。今回は入社して５年〜10年目ほどのキャリア中期の振り返りです。
前回はこちら
担当していた業務
5年目になると、そこそこの中堅として扱われ任される仕事も幅が出てきました。その中で、業務の幅や範囲が広がってがきたのがこの頃です。
会社の開発案件・工数・お金を管理するコアシステム改定
親会社のシステムインフラ担当
色々作って試してもらう(まず動くものを作って見せる)
1.社内の開発案件・工数・お金を管理するコアシステム改定
当時、部内でアプリも基盤も含めて一番手を動かせる人になっていた事もあり、当プロジェクトのアーキテクト面を突然任されました。このシステムは親会社で発生する毎年の何億円という開発予算や、そこに付随して発生する開発工数を管理するというシステムでした。
基本社員の内製開発の前提で、言語やフレームワーク、サーバーOS、ミドルウェアから、コード管理、開発標準の策定までなんでもやらせてもらいました。基本的なアーキテクチャと初期のプロトタイピング実装が終わった段階から、基盤の実装や運用設計周りにシフトしたのですがかなり大きなシステムを０から考えて作らせてもらったのは本当に自分の財産になっています。大きな会社って基本誰がやっても品質をある程度保つためにさまざまなルールがあるのですが、当時そういったルール面から含めてやっていいよという事でこの点もとても貴重な経験させてもらいました。
ただ、正直当時はプロジェクトマネジメントという観点ではかなり不味く、アジャイルを認識できないオーナーによる典型的なダメアジャイルになっていたのが痛くかなり炎上しました。。ただ、当時本当に優秀なコンサルの方が投入されたり、ベトナムのオフショアもあったりと立て直し結果作られた成果物としてはとても良いものが出来上がりました。かなりの長期に亘り利用されていますが、性能問題や大きな障害を抱える事なくユーザーからの評判もよく良いものを作れたなーという内容でした。その後だいぶ長い事運用メンテナンスもあまりかからず安定して動いてくれたのですが、アーキテクチャがしっかりしていると結果そのような状態になるという話も聞きました。作った結果が見れるという観点で、設計・開発・運用まで一気通貫でできるという点はシステムに関わる仕事をする以上一度はどこかでやっておけると基準になると思う経験でした。
2.親会社のシステムインフラ担当
最初の5年ちょっとは子会社の方で使うシステムの開発運用なので、これまで書いてきた通りかなり自由にそれこそ小規模な会社のようになんでも色々触って作れる場所にいました。しかし、その後インフラを色々できるぞという話が出たのか親会社側のコアシステムのインフラ担当になるようになりました。
正直、当時若手の自分としては技術の話ではなくて面白くなさそうだし、開発とかもいろんな制約でるからなぁ…と全然乗り気ではなかったです。そして、業務を実際にやっている間も。
しかし、システムを開発運用するにあたっては必ず使うユーザーやビジネスそしてそこから生み出されるお金が必ず関わる訳でそういったレイヤーを意識できたのはとても良い経験でした。いま、転職してスキルが高い人に囲まれてやっているのですが、その中で生きているなーと思うのが実はここだったりします。というのも、ベンダーでキャリア形成した方は開発に関するスキルなどはとても高い人がいらっしゃいます。しかし、やはりこういったビジネスとの関わり方が違うようでその点で他の方にはない経験や強みになる可能性はありそうです。あるべき論に対してビジネスサイドとどうやって落とし込むか？という点は実際やってみると本当に辛い…のですが、そういった辛い判断の連続でシステムはできていると感じる部分もありそういった背景を知っているのはまた同じ話になるのですが判断の基準になります。
3.色々作って試してもらう(トイレのIoT、ログ分析)
インフラ担当になりながらも、色々作って試せる環境があったのがとても良かった話なのですが色々自信の学習を兼ねてものを作って動かしていました。スキルは自分で勉強できる、はその通りなんですが実際のデータや環境を使ってできるとやはり得られる経験が段違いです。そのために、自分が担当している業務で苦痛だったプロキシログ調査(当時は信じられないことにvimやgrepで生ファイル加工)を勝手に立てたPCレベルのスペックのサーバでElasticsearchの環境作りKibanaで可視化して使ったり、Raspberry piにマグネットスイッチをつけてトイレの扉の開閉をセンシングしてアプリで可視化などしました。
1000人以上の規模の会社でこれをやると、結構皆さんフィードバックをくれます。そして、そのフィードバックがもらえる事で試した結果に対して理解が深まり、学習効率が本当によくなるんですよね。ユーザー系子会社であれば、自社の業務とかでこういった改善できる余地ってあったりするのでそういったことをコストかけずにまずはやってどんなプロトタイプでも触ってもらうと、意外と話を進められたりします。また、お前こんなことできるのか、とアピールに繋がり他の仕事がアサインされたりといいサイクルに繋がるのでこういったムーブはユーザー系子会社はやりやすいし結構いい効果を生みそうだなと思った内容でした。
また、大きな会社ほど承認に時間がかかるしなおかつこれまで存在しない概念はなおさらハードルが上がります。でも、こうやっておもちゃレベルでもまず動くものがありちょっと試せるとそこから効果を実感してもらってすんなり通せるというのがとてもよくわかりました。やっぱり人は自分で見て触ると一気に実感できるんですよね。
結果何が良かったのか？
ユーザー系子会社で得られる/得やすい経験として上記踏まえると以下３点があります。
開発から運用まで含めた一気通貫の経験
ビジネスに寄り添ったシステムの感覚と判断の経験
ユーザー系子会社の業務や社員を対象としたプロトタイピング
現在、私は外資のクラウドサービス提供会社にいるのですがその中でもやはりビジネスサイドでシステム開発や運用をした経験がある方は意外といないんだなーというところがあります。
以前のブログで書いたように、やはり日本のユーザー系子会社はベンダー丸投げでとりあえず業務を回しがちな部分があるというのもあると思います。ただ、ここを逆手に取ると意外と市場においてちょっと変わった色を持った人材になれたなというのを今は実感しています。ユーザー系子会社で技術をちゃんと自分から学ぶ姿勢でいく、そしてそれを実践してビジネスでも使ってもらう。もちろん結果、それができる環境だったと言われればそうなのですが自分からやりたいアピールをする、プロトを作って既成事実化するなど方法はいくらでもあるのでそういったことで再現は可能だなと思う部分であります。
まとめ
キャリアを振り返りながら思うのは、エンジニアのキャリア形成としてニッチなポイントを狙うということかもしれません。正直、前提として私は世の優秀なIT人材と真正面から殴り合いをして勝てるようなスキルや地頭はないという点があります。なので、そこで勝負をせず組み合わせで特殊性を出すような動き方をしてキャリアを形成しているんだな、と今になって思います。
もちろん、そういった真正面を切ってスキルを極限まで高めて弛まぬ努力をして強強エンジニアになることはとても憧れます。一方で、実際のITの現場ってそれだけでは本当に成果を出せるとは限らなくて、さまざまなレイヤーのITスキル(アプリ、インフラ、NW、フロントエンド、バックエンドetc…)やビジネス(利用する会社の規模・文化、担当のレベル、その時に確保できる人員etc)さまざまなものを加味して繋ぎ成果を出していきます。
そういった実世界を考えると、複数のあまりない組み合わせで何かスキル・経験で持つことで市場に求めれるようになるのかなと思います。
ユーザー系子会社にいると、逆にこうったところって経験やスキルを得やすいような気がしておりうまく立ち回ることで実は市場に求められるスキルをつけれるかもと思うところです。改めて思うと、ユーザー系子会社でキャリア形成を始めるのは新人の教育や研修(費用の補助など)実は意外と手堅く良い方法なのかなと思ったりもします。
ここまで２回書いてきましたが、おそらく残りは後２つになりそうです。
ユーザー系システム子企業で成果を出すには
どんなユーザー系システム子会社に入るべき？
今回もお付き合いいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか？