35歳から挑戦するインフラエンジニアのアプリケーション開発

こんにちは！

介護職向け求人情報サイト「カイゴジョブ」のアプリケーション開発と、全社共通インフラの仕事をしている伊藤です。

さっそくですが、みなさんはこのブログのタイトルを見てどんな印象を持たれましたか？
昨今ではだいぶ認識が変化している気がしていますが、一昔前にはプログラマ35歳定年説というものもありましたね。

そんな定年説があるなかで、私はインフラエンジニアでありつつもアプリケーション開発へも挑戦している真っ只中です。

この記事では今まで自分はどんなことをしてきたのか、なぜアプリケーション開発をやりたいのか、チーム内でどうたち振る舞っているのか等をお伝えできればと思っています。

同じように新しいことに挑戦しようとしている、実際に挑戦中の方へ少しでも後押しできればとても嬉しいです:)

今までどんなお仕事をやってきたの？

私は現在35歳ですが、秋頃には36歳になります。

2010年の新卒からインフラエンジニアとして継続して働いて、気がつけば今年で13年も経過していました、早すぎますね・・・

※直近4年ほどではDevOpsやSREという職種でもお仕事をしてきましたが、インフラの業務がほとんどでした。

• 2010年 - 2018年: SIer/ソシャゲ/ISP/オンライン英会話の会社でオンプレやAWSを使ったインフラエンジニアとして働く
• 2019年: HRの会社で初めてDevOpsとして働く
  • この辺りからgemを作ってみたり趣味でコードを書くことが増え始める
• 2020年: ECにおける在庫管理システムの会社でSREとして働く
• 2023年4月: エス・エム・エスで、アプリ開発・インフラの兼務で働く

アプリケーション開発に挑戦したいと考えたきっかけ

実は明確に何かがあって挑戦したいと感じたわけではなく、 以下のような小さなことの積み重ねで挑戦したい気持ちが湧き上がりました。

趣味でコードを書くことの楽しさ

必要性を感じて自分でググりながらコードを書いて日々の業務に活かすことの楽しさを少しずつ感じていました。 例えば、以下のような具合です。

• AWSのマルチアカウント構成でチェックボックスにチェックをいれると上位に表示してくれるChrome拡張
  • マルチアカウント環境でインフラエンジニアだと数十個表示されことがありますが、常用アカウントは数個で都度アカウント検索がめんどくさくて作りました
• ランチャーアプリのRaycastでKibelaを表示するプラグイン
• Googleカレンダーに入力したスケジュールで作業時間を計算するgem
  • 日報に活動内容や時間を計算するのがめんどくさくて作りました
• フィヨルドブートキャンプさんでアプリケーション開発を学ぶ
  • 過去に退職後の有給消化のタイミングで勉強していたことはあったのですが、仕事が始まるとなかなか時間を取れなくて休会していました
  • 現在は少しずつ再開しています🏃

知識欲(特に仕組み)の渇望

元々自分の性分として全てのレイヤーを知りたいという欲求がありました。

例えば、自宅から目的のサーバまでのネットワーク経路や、NICにパケットが着信してからLinux Kernel、プロセスに渡るまでの流れやプロセスそのものの仕組みといった具合です。 オンプレ時代であればMHA for MySQLでフェイルオーバーするときにネットワークレイヤでは何が起きてどういう仕組みでアプリケーション側から影響がほとんどないように見えるのかを検証するのもとても面白かったと記憶しています。

当時、O’ReillyのUnderstanding Linux Network Internalsを見てARPのキャッシュ管理方法としてGCの仕組みがあることや、デバイスドライバからユーザーランドまでパケットが処理されていく図を見て、こうなってるのか！とワクワクした記憶があります。

細かいところはまだまだ知らない世界は山のようにありますが、日々のインフラの業務をこなす上で必要最低限の知識は少しずつ身についていた感覚があります。 その一方で、プロセスから先のデータ処理については一部のコードを見ることはあっても通しで全体を理解するところまでは踏み込めていませんでした。

仕事への慣れ

2018年頃からインフラエンジニアとしての仕事にも慣れてきて、よくある構成の構築や運用はあまり苦労することなくできるようになってきました。

例えば、新規でサービスを作るためにサーバーを一式用意してほしいと依頼があったとします。 サーバーはクラウド、監視やデプロイ周りはSaaSで要件を整理しながらAnsibleで書けば1週間くらいあれば開発環境は用意できそう。といった形でゴールまでの道筋や手数がやる前から大体掴めますし、多少想定外があってもtcpdumpとstraceがあれば問題の切り分けくらいはおおよそつくといった具合です。

俗に言うコンフォートゾーンに突入し始めてしまったのがこの時期で、少しずつ危機感と日々の業務に退屈さを感じ始めていました。そうしたなかで、新しいことを始めていきたいと考えるようになりました。

---

こうして振り返ってみると、コードを全く書いてなかったわけではないですし、アプリケーション開発を主としても働けるのではないの？と思われる方もいらっしゃるかもしれません。

しかし、実はここまで書いているコードにはテストコードはほぼありませんし、コード自体もいわゆるシェルスクリプトの延長くらいの書き方しかしたことがありませんでした。

また、まともにフレームワークを使ってWebシステムを作ったことはありませんでしたし、 数ヶ月に1回程度しか思い起こさないので、初歩的な書き方すら都度思い出すような状態です。アプリケーション開発を本職とするには経験が不足していたことをお分かりいただけると思います。

転職活動について

転職ドラフトで指名を頂いたことがきっかけになります。

会社としてどういう期待・見通しでの指名だったのか

最初はインフラエンジニアとしての立ち位置で指名を貰っていました。ただ、カジュアル面談でRubyを使ったアプリケーション開発をしていきたいことを伝え、正式な選考ではインフラチームとカイゴジョブチームの責任者と面接をしていました。

カイゴジョブチームでは専任のSREがいなかったこともあり、アプリケーション開発に携わりながらインフラ面を強化できる立ち位置として期待されていました。 インフラチームでは、今までのインフラエンジニアとしての経験と合わせてカイゴジョブチームで得られたSREとしての経験を全社に展開できることを期待されています。

入社後について

働き方

月曜日〜水曜日はカイゴジョブの開発をしており、木曜日と金曜日はインフラチームの業務を行っています。

稼働日は厳密に定めているわけではなく、カイゴジョブのタスクを優先したり、逆にインフラタスクを優先したりと裁量を持った上で働けています。

入社してみてどうだったか

10年ぶりくらいに毎日知らないことだらけの世界に飛び込んで、正直必死です（笑） ですが、チームの雰囲気はとても良く、ペアプロ、ペアワークを推奨していてとても楽しくお仕事できています。

私がメインで働いているカイゴジョブチームはとても大人なチームで、いわゆるHRTの原則をとてもよく体現されています。 また、隔週でスプリント・プランニングを開いているのですが、タスクのゴールまでのイメージのすり合わせがとても丁寧に感じています。

今まで私が所属していた組織では個々が独立して動くことが多かったため新鮮で、とても助かっています。

※インフラエンジニアとアプリケーション開発エンジニアの職種の違いというのもあるかもしれません

入社後に意識していること

無理に一人で仕事を進めようとしすぎない

先述の通り、カイゴジョブチームではペアワーク・ペアプロを推奨しています。

一人で進めていくことも大事ですが、無理に一人で進めてチームとしての生産性が上がらないのも困ってしまいます。

こんな感じでSlackで投稿するとメンバーが反応してくれますし、 朝会等で今日は手が空きそうなのでペアプロ求める人がいたらお声がけください〜！といった呼びかけも当たり前に発生しています。

わからない、つまづいているときは素直に周りに助けを求めて、逆に自分が手助けできるところは積極的にやっていくぞ〜！という気持ちになります💪

自分の過去の経験や強みを貢献して積み重ねていく

当たり前のことではあるのですが、私は周りと比較するとアプリケーション開発のみでは成果を出せません。 また、会社としての期待もアプリケーション開発のみではなく、SREとしての振る舞いを期待されています。

そこで、今までの経験からどうしたらチームに対して成果を出せそうかは常に考えるようにしています。 私の場合は、一例として次のようにインフラエンジニアとしての知見を共有できるように意識しています。

• インフラエンジニアとしての振る舞いを伝える
  • ペアワークで障害対応を行う
    • 障害の予兆を検知した場合や発生した時にペアワークを行いメトリクスの読み方を伝えることでインフラレイヤのわかるエンジニアの動き方を少しでも伝えられるようにしています
      • 例えばCPU使用率ひとつとってもユーザーランドなのか、Linux Kernelなのか、iowaitなのか、どういう時にこれらのパラメータが上がってどのくらいになると怪しく感じ、どう問題の切り分けを行っていくか等
  • ポストモーテムをドキュメント化する
    • 障害対応についてドキュメント化することでペアワークしてないメンバーにも伝えられるようにします
• インフラ設定の改善
  • サービスの監視をどのようにすると良さそうかをドキュメント化する
  • ECSオートスケーリングの改善

エス・エム・エスに入ってみて感じる強み

インフラエンジニアとしてキャリアを積み重ねてきたメンバーをアプリケーション開発へも挑戦する機会を設けてチャレンジさせられるのはとても強いなと感じています。

ミドル・シニアクラスのメンバーの場合は過去の積み重ねがあり、そこを期待したうえで入社している都合上、 組織として期待値に沿うパフォーマンスをすぐには発揮しづらいであろう業務に時間を割り当てることを許容できる組織はなかなか多くはないのではないでしょうか。

時間が余ったら個人の裁量でアプリ開発のタスクを取ってもOKというのを見かけることはありますが、 日々の割り込み業務、開発タスクの期限、マネージメントへの期待というものがあるなかで、なかなか継続的に時間を確保するのが難しいのが現実だと思います。

入社して今日にいたるまで、実際にはインフラ業務を優先してアプリケーション開発の時間が割り当てられなかったということは一度もありませんでした。 入社前にアプリケーション開発もやっていきたいと伝えているので当然なのかもしれませんが、ちゃんと組織として対応できているのは凄いなと感じています。

最後に

この記事の執筆時点(2023/07/05)で3ヶ月経過し、試用期間も終わりました。 まだ3ヶ月弱ではあるものの、振り返ってみると大きな会社としての良さは享受しつつチームで仕事をしているときは大きな会社特有の難しさみたいなものはあまり感じていません。

たとえば、継続的にRuby Kaigiをスポンサーしているのはもちろん、Rails Girls Japan、PHPerKaigi、iOSDC等様々なイベントにスポンサーしています。イベントに参加するときの経費は会社負担で、参加している日は出勤扱いですし、宿や交通機関のチケット手配もお願いすることができます。

また、技術書はSlackで呟くと購入手配してもらえますし、オライリーのサブスクリプションサービスを使わせてもらえる制度があったりと、技術に対する投資が活発な印象があります。

その一方で、ひとつひとつのプロダクトはチームとして独立性が高いためチーム内で合意形成できればスピード感を持って新しいものを導入したり変更しやすいと感じています。

※もちろん、全社で利用している基盤のようなものであれば調整が必要になります。

大きい会社としての良さを享受しつつもスピード感を持って、一緒に働ける仲間を募集しているので、興味を持っていただけたらTwitterでもリアルでも気軽にお声がけいただけたら嬉しいです！！