ただのバックエンドエンジニアからDevOpsエンジニアになるまで

こんにちは初めまして、株式会社ノハナでバックエンドエンジニアとして働いてる野村と申します。githubではjunpayment, twitterではjunPAYとして活動しています。

ちょっと前まではRuby,PHP,Perl,JavaScriptといったLL言語を書くことが多かったんですが、最近ではGo,TS+React+k8s,CloudRun,GAEなどなど静的型付け言語でBFFな環境を組む仕事を行うことが多くなりました。

Offersは副業先の企業を探す媒体として活用させていただいてます。

表題の内容ですが、僕はもともとバックエンドアプリケーションをガリガリ書いてしかおらず、クラウドインフラの知識や技術はほとんど身につけていませんでした。ところが転職を機にそれらを曲がりなりにも習得していきDevOpsエンジニアとなった経緯をここに書きます。

Offersエージェント」では、業界で活躍するプロフェッショナルがあなたの転職を徹底サポート。CxO経験者を含む現役エンジニア・デザイナー・プロダクトマネージャーが在籍し、職種に特化した専門的なアドバイスをご提供・非公開求人の紹介も可能です

【かんたん30秒】無料登録で転職相談する

元々どんなキャリアを積んできたのか

ソーシャルゲーム業界のバックエンドエンジニアがキャリアの始まりでした。

アプリケーションレベルでの要件定義〜設計〜実装〜テスト〜運用まではまるっと担当していたのですが、当時勤めていた会社はインフラチームと開発チームの分業が進んでいたことがあり、インフラまで手を出すことはありませんでした。

書いたコードを既に用意されたサーバに撒く」までが仕事で、せいぜいcapistranoの設定をググりながら書く程度で、ざっくり下記のようなエンジニアでした。

  • アプリケーションは書ける
  • Linuxオペレーションはできる
  • インフラ構築する経験,知識が無い

転職を機にいろんなことをやらなければならなくなった

そこから現在勤めているノハナに転職しました。

中小あるあるですが、エンジニア組織自体が分業できるほど大きくは無い事情もあって、そこでのバックエンドエンジニアの仕事は「サーバーっぽいこと全部」という感じでした。

歴史的経緯でノハナはいろんな言語(Ruby,Perl,Node.js,Go etc..)を使っていたり、AWS,GCPのマルチクラウド構成だったりします。

物理フォトブックをアプリ上で購入してもらって届けるというサービスなので、システムだけで完結するわけではなく印刷工場との連携やイレギュラーケースを含めると複雑な状態遷移になっており、ビジネスロジックの情報量もなかなかのものです。

入社時のスキルとのギャップ

前述の通り、前職ではバックエンドアプリケーションしか書いてなかったので、GCP,AWSの知識がほとんどありませんでした。学習するにしてもGCP,AWSは色んなリソースが存在してるので、どれから手をつけていいのか当初は全くわかりませんでした。

サービスのアーキテクチャの説明を受けたところで最初の方は何から覚えていけばいいのかサッパリでした。

このギャップを少しでも早く埋めるために、GCP チュートリアル 初心者などで検索して片っ端からチュートリアルをこなしていきました。その時はCouceraUdemyの存在を知らず、ひたすら公式チュートリアルをやっていた記憶があります。

当時知っていたら間違いなくそれらのサブスクをやっていたと思います。

皆さんご存知だとは思うんですが、GCP,AWSともに初期クレジットや無料枠があるので、学習にお金がかかることはありませんでした。

優先して学習したリソース

その当時僕が優先して覚えたのは下記のリソースです。

  • GCP
    • IAM
    • GCE
    • GKE
    • GAE(SE,FE), CloufFunction
    • LoadBalancer
    • GCS
  • AWS
    • IAM
    • EC2
    • ElasticBeanstalk
    • S3
    • CloudFront

最低限上記リソースをデプロイできるようになれば、なんらかのwebサービスを全世界に向けてリリースすることが(原理的には)できるようになります。(クラウドのオペレーションはpermissionが無いと何もすることができないので、IAMを初期段階で取り組んだのは良かったと思います。)

土日、妻に「午前中は僕が子供を見るから午後は勉強させてくれ」と約束をして、PCを持ち込める図書館に篭って学習していました。その甲斐もあってか職場で「なんで未経験だったのにそこまでわかるんですか?」って褒めてもらいました。「いや〜そんなことないっすよ〜」ととぼけてた記憶があります。

プライベートの時間を学習に充てることは賛否両論あると思いますが、スキルのギャップがあるなら仕事以外でもキャッチアップに勤しむべきかなあと思います。

最初に任された大きな仕事

ある程度仕事に慣れてきた頃に任された大きな仕事がAWS環境からGCP環境へのサービス移行です。

これはAWS ElasticBeanstalkにある稼働中のサービスをGKEにリアーキテクチャするというものです。

詳細についてはブログを見ていただきたいのですが、会社でもKubernetesを導入するのは初で、GKE自体もプレビュー版の機能があったりと途上段階だったこともあり、いろんな試行錯誤をしながら作業を進めました。

当時CTOやGoogle SupportやGCPの開発支援の方々に聞きまくりながら協力してもらいながら進めていき、安定稼働まで持っていくことができました。こういった大きなタスクだけでなく、小さな課題を見つけては片手間で少しずつ解決していくことを継続しました。

そういった業績を認めてもらい社内表彰もしてもらうなど、少しずつ社内的な信頼も得ていけたと思います。現在では、会社の人事的な変化もありテックリードという立場をいただくことになりました。

システムの課題が見えてくるようになった

社内での経験+技術がともなってくると今度はサービスのシステム的な課題が見えてくるようになってきました。

その一方で、ちょっと前までは課題はプログラムで解決するという思考だったんですが、手数が増えることで、開発手法の標準化や教育など直接技術とは関係ない方法も織り交ぜて解決策を考えるなど、俯瞰した視点でのアプローチが可能になったと思います。

自分自身の課題も見えてきた

割と場当たり的に必要な技術だけつまみ食いしてきたので、単純なwebサービスを作るのに必要なクラウドのリソース以外(機械学習系,ビッグデータ系など)も含めて体系的にわかってるかというとそうでもないです。

技術導入のスピードや選定根拠の説得力を考えると、やはり体系的な知識は経験よりも価値があると思います。それを課題に感じ、最近はGoogle Platform Cloud Architectureを取るなど資格試験を通じて体系的に学ぶということにも取り組んでいます。

まとめ

課外活動として技術をキャッチアップしていくことは、社内外での市場価値を上げる点で武器になると思います。

スキルが身につくと見えてくるものが変わってきます。場当たり的なキャッチアップでは限界があるので体系的な知識には価値があります。月並みな意見ではあるんですが、僕と同じようなパターンの方の助けになればと思います。


Offersエージェント」では、業界で活躍するプロフェッショナルがあなたの転職を徹底サポート。CxO経験者を含む現役エンジニア・デザイナー・プロダクトマネージャーが在籍し、職種に特化した専門的なアドバイスをご提供・非公開求人の紹介も可能です


この記事をシェア

関連記事


副業・フリーランス

プログラミング

デザイン

インタビュー

お金

採用・組織

転職

イベントレポート