経歴のスタート地点
藤本里奈さんが新卒で入ったのは、ヘルスケア領域のWeb系スタートアップだった。配属はバックエンドチーム、メイン言語はRuby、フレームワークはRails。最初の半年は既存機能のバグ修正と小さな改修を任され、次第に予約機能のリプレイスや課金まわりの新規開発も担当するようになった。
3年目に入る頃には、ActiveRecordのN+1問題を本番ログから察知して直したり、Sidekiqのジョブ設計をリードしたりと、アプリケーション層では一人前の戦力になっていた。一方で、デプロイボタンを押すのはいつも先輩のDevOps担当者だった。「ステージングにデプロイしておきました」と言えばよく、本番のEC2インスタンスにSSHで入った経験は、入社以来一度もなかった。
最初のつまずき
転機の前に、小さなつまずきがあった。あるリリースの夜、本番でバックグラウンドジョブが詰まり始めた。Datadogのアラートが鳴り、Slackでメンションが飛んできたが、藤本さんはどのEC2のどのプロセスを再起動すればいいのかさえ分からなかった。結局、DevOps担当の先輩が30分で復旧させ、彼女ができたのは事後の障害報告書を書くことだけだった。
「自分の書いたコードなのに、自分で守れない」——その感覚はずっと喉に刺さっていた。Dockerという単語は知っているし、Dockerfileを読むこともできる。けれど、CI/CDのYAMLを白紙から書くこと、AWSのセキュリティグループを変更すること、その一つひとつが「触ったら壊しそう」で怖かった。
転機となった引き継ぎ
その年の冬、DevOps担当の先輩が転職することになった。チームには専任のインフラエンジニアを採用する余裕はなく、誰かがその役割を引き継ぐ必要があった。CTOから「半分だけでいい、やってみないか」と打診されたとき、藤本さんは少し迷ってから、はいと答えた。
引き継ぎ期間の3ヶ月、彼女は先輩の隣でひたすらメモを取った。GitHub Actionsのワークフローがどこで何をしているのか、Terraformのstateファイルがどこに置かれていて誰が触るのか、本番デプロイの前後で何を確認しているのか。先輩がいなくなった最初の月は、毎週どこかで小さな事故が起きた。ステージングへのデプロイが失敗し、原因がDocker imageのキャッシュだと気づくのに半日かかった日もあった。
それでも、3ヶ月目には自分でCI/CDパイプラインを一本書き上げた。テスト → ビルド → ECRへのpush → ECSタスク定義の更新、までを通しでつないだとき、デプロイボタンを押す側の景色が初めて見えた気がした。
いま振り返る選書
最初に手を取ったのは『GitHub CI/CDガイド』だった。手元のリポジトリで動かしながら読めたのが大きく、引き継ぎ初週から実務に直結した。Dockerについては『Docker/Kubernetes実践』を通読し、コンテナのレイヤーキャッシュやマルチステージビルドの考え方が腹落ちしてからビルド時間が一気に短くなった。
本番環境の理解には『Infrastructure as Code』が効いた。Terraformのコードを「設計図」として読む視点が身についたことで、AWSコンソールを直接触る怖さが減った。継続的デリバリーの全体像をつかむために『入門 継続的デリバリー』を、自分の取り組みが組織にもたらす意味を言語化するために『LeanとDevOpsの科学』を読んだ。後者は、半年経ったタイミングでCTOへ提案書を書く際の論拠としても使えた。
これから挑む人へ
振り返ると、藤本さんを変えたのは大それた決意ではなく、「やってみないか」に「はい」と答えた小さな選択だった。アプリケーション開発者がDevOpsへ踏み出すとき、最初の壁は技術ではなく、本番環境への心理的距離だと彼女は言う。
壁を越える近道は、小さな変更を自分の手でデプロイし切ることだ。READMEのタイポ修正でもいい、CIにrubocopを足すだけでもいい。書いた人が出すという経験を1度通すと、次のYAMLを書く手は驚くほど軽くなる。3年後、彼女は今度は誰かに「やってみないか」と声をかける側に回りたいと考えている。
もう一つ、彼女が後輩に伝えるのは「最初の半年は遠慮なく手を止めて学ぶ時間に使ってよい」という助言だ。機能開発と並行で運用を引き継ぐと、調査の途中で割り込みが入り、結局どちらも中途半端になる。学習合宿のように週単位でブロックを取り、その期間はチームに事情を共有して機能開発の手を緩めることが、結果的に組織の運用力を底上げする。藤本さん自身、最初の四半期は「機能開発8割・運用2割」だった割合を、半年かけて「機能開発5割・運用5割」に戻した。最初から無理に両立を目指さなかったことが、長く続けられた理由だと振り返っている。
