この記事は Kubernetes Advent Calendar 2023 の15日目の記事です。

これは何？あなたは？

会社員になって8年目くらいの三十路突入おじさんの(エンジニア)復活記(ポエム)です。
某緑色の会社(今は黒のイメージもあるかも？)でエンジニアをしています。入社時はバックエンド採用&子会社出向でしたが紆余曲折し、現在は親会社に戻りプライベートクラウドでKaaS基盤開発に従事しています。

復活する前は何をしていたの？

復活する前はテクニカルコンサルタントとして、子会社の事業開発の技術面で横断的にサポートする役割を担っていました。
仕様書策定やスケジュール管理、外部の開発会社との打ち合わせで、いわゆる上流工程の仕事を担当することが多かったです。事業開発に重きをおいていたので市場調査やPL等の作成も一部担当していました。
もっと遡ると、動画配信サービスのパブリッククラウドのインフラエンジニアをしていたので、その流れでサーバー構築などの業務も担当していました。

復活するきっかけは？

入社時は技術指向が強かったのですが、事業開発において技術で解決出来る問題の幅の限界を痛感することがあり、そこから事業計画や組織計画に興味を持つようになりました。
その延長でテクニカルコンサルタントに2~3年従事していたのですが、外部の開発会社(案件の性質上オフショアが多かったってのもあります)を利用するため、納品形式や運用面を考えると、どうしても技術的に枯れたアーキテクチャを採用せざるを得ないことがほとんどでした。
またコンサルタントという名前がついている以上ビジネス的な知識理解のキャッチアップも必須です。
これに加えて、最新の技術をキャッチアップ、自分で手を動かして検証といったことをプライベート含めてやっていくのが、業務が比較的多忙だったという言い訳をする形になるのですが、難しくなっていたのが実情です。
新しい技術から取り残された焦燥感があったこと、担当していたいくつかの事業開発も会社の状況変化、市況感の変化により規模縮小や開発凍結になることがあり厳しさを感じており、三十路突入し新しい事にチャレンジするにはちょうどよい機会かもと思っていたのも重なりました。
異動自体は社内の異動制度を利用し比較的スムーズに異動することが叶いました。制度が整備されている弊社に感謝感激という感じです。

復活するにあたって

業務コードを書くことから離れて6年弱、チーム開発から離れて2~3年程度の人間がいきなり最新鋭のKaaS基盤開発にジョインするに当たってもちろんスキルのギャップがあるわけですが、この差を埋める必要が出てきます。
復活前のスキルは以下のような状態でした。

パブリッククラウドインフラ(AWS)
中~大規模サービスのアーキテクティング&運用経験
AnsibleやCloudFormationを用いた自動化
Python, Rubyを用いたツール開発
機能要件、非機能要件を仕様書に落とし込み開発会社選定し、開発を進める
開発進捗管理

KaaS開発では以下のスキルが求められていました。

Kubernetesの思想Kubernetesそのものに対する深い知識、周辺エコシステムの知識
オンプレミスで用いているアプライアンスの基本的な知識
go言語のスキル
カスタムコントローラの知識

未経験のものが多く、かつスキルギャップがかなりあり、Kubernetes自体も1.13から触っておらずCRDもGA前だったので知らずで、浦島太郎もびっくりの何も分からん状態からのスタートでした。

この状態でも受け入れてくれた今の事業部には本当感謝しかありません。ギャップを埋めるために以下のことを実施しました。

Kubernetesに触る絶対時間を増やす
最新情報のキャッチアップの時間を強制的に増やす
自分で手を動かして開発する感覚を取り戻すために、趣味開発を再開する。goでなるべく書く

Kubernetesに触る絶対時間を増やす
当たり前ですが、実際に手を動かさないと知識は血肉になりません。Kubernetes自体を理解したかったことと、ランニングコストを低く抑えたいなどを考えた結果、ミニPCにUbuntuを入れmicroK8sやk0sなどのディストリビューションを用いて構築するのが良いだろうとなり、N100とメモリ16GBが搭載されたミニPCを購入し自宅で稼働させることにしました。
VPNも張ってどこからでもアクセス出来るようにし、いつでもどこからでも同一のクラスタを触れるようにしました。
また好きこそものの上手なれと言われるように、自身の興味関心の方向と合わせた方が知識習得も早いと考え、今までAnsibleでVMにセットアップしていたような内容もKubernetesのマニフェストを書いたりし、昔書いていたwebAPIをDeploymentにしてみたり等を実施しました。

最新情報のキャッチアップの時間を強制的に増やす
現チームで既に行っていたKubernetesキャッチアップ会と呼ばれる、LWKDとKubeweeklyを読む時間のファシリテーションを任せてもらいました。
事前に読んでおき、関連するKEPやわからない所を調べるようにしていましたが、比較的マイナーなリソースや、前提知識が必要となる内容はやはり理解の解像度が低かったため、メンバーに質問し解答をもらったりを繰り返しました。

自分で手を動かして開発する感覚を取り戻すために、趣味開発を再開する。goでなるべく書く
前述の通り、単一または少数で終わるようなスクリプトはずっと書いていましたが、サービスやソフトウェアとみなされる単位での開発は久しくしていませんでした。
自身で考えた設計を自身で作り切り、運用することが重要なので、趣味でもサービス開発を再開することにしました。たまたまタイミングよく旧友に声をかけてもらい、内々で使う分析ツールを作ることにしました。
これがかなり効果的でgo言語の習得速度の向上に寄与しました。手に馴染むという表現が合っているかは分かりませんが、やりたいことや実現したいことはまあ実装出来るだろうという自信に繋がりました。
(余談ですが、goの知識習得にはchatGPTやGitHub Copilotが大いに貢献してくれました。新しい事の学習にはもってこいだと思います本当に)

業務では、大きなものではKubernetesのカスタムコントローラーを開発するタスクを担当することになりました。
RBACと監査ログを利用する内容なのですが、Role/ClusterRoleはもちろんKubernetesのよく出てくるリソースの理解も曖昧だったので、チームメンバーに1on1やレビューをお願いし、その過程で知識を深めていく形になりました。
最初からカスタムコントローラーの開発はスキル的に厳しかったので、一旦はCLIのようなものを作り計算処理部分の考え方や基本的なgoの知識などを確認してもらいました。
必要があればKubernetesや周辺ソフトウェア自体のソースコードを読んだり、Upstreamにコントリビュートするのが文化として根付いているチームのおかげもあり、私も自然とそのような動きが出来るようになっていきました。

で、復活できたの？

半年あればその業界のトップランカーになる人も少なくない中、そのようなレベルの復活は成し遂げられなかった事は事実です(まあそこは高望みしすぎですがｗ)
そこまでいかず、Kubernetes、CloudNativeを利活用し、適切なアーキテクチャ提案、実装が出来るかを復活の定義だとしても、正直まだまだです。

ですが、KubernetesのReconcileの設計の美しさ、Kubernetesを通して様々なものをas a Serviceとして開発出来る可能性の広さに改めて感銘を受け、利用していかない手は無いという感覚になれたことは非常に大きいと考えています。業界の流れも早く生成AIの兼ね合いもありデファクトはどんどん変わっていきます。
コンサル自体からやっていた、時流を読み都度適切な情報収集をし最大効果をもたらす動き、を活かしつつ、エンジニアリングに関してもたゆまず成長していければと考えています。