TISでの6年間を振り返る — 社会人としての土台を作った6年
はじめに
TISに新卒で入社してから6年、そのほとんどを金融機関のシステム開発現場で過ごしてきた。間もなく次の環境(SREロール)に移ることもあり、一度立ち止まって、この6年で何をやってきて、何を得られて、何を得られなかったのかを言葉にしておきたい。
正直なところ、「良い6年間だった」と素直に言い切れるかというと、そこまでの自信はない。エンジニアとして大きく成長できたのか、まだ自分でもよく見えていない部分がある。だからこそ、この記事を書く過程で見つめ直したい。
これは未来の自分に向けた、整理用のメモでもある。
印象に残った3つの仕事
1. TiDB PoC — 検証から登壇・寄稿まで一気通貫で
TISで関わった仕事の中で、最も対外的にインパクトがあったのがTiDBのPoC検証だった。
きっかけは部内での呼びかけ。決済ネットワーク領域を支えるDBはOracleを採用していたが、増え続けるデータ量に対して性能とコストのバランスが悪化しつつあった。Oracleに代替できる選択肢を探しているという話があり、自分から手を挙げて参画した。同業のPayPayが採用しているという事例も後押しになった。
このPoCを通じて得られたのは、何より分散DBアーキテクチャに関する知見だった。Raftによるレプリケーション、TiKVのリージョン分割、PDによるスケジューリング — すべてが新鮮で、Oracleで培ってきたDB観を一度ほぐして再構築するような体験だった。今では細部を忘れてしまった部分もあるが、「分散DBはこう考えるのか」という感覚が身についたことは、エンジニアとして大きな成長だったと思う。
そして何より、検証の初期段階から社内の表彰、DB Tech Showcase 2022での登壇、Software Designへの寄稿まで、一気通貫で関わることができた。社内で完結していた頃の自分と、登壇後の自分とで一番違ったのは、「もっと社外に発信したい」という気持ちが強くなったことだった。準備は大変だったし登壇は緊張もしたが、自分が検証したことを世の中に届けられる楽しさは、代えがたいものがあった。
2. ミッションクリティカル領域のOracle DB構築
決済ネットワークを支えるOracle DBの構築・テストフェーズを担当した。関わったのは構築から単体テスト、そして結合・システムテストの中の障害試験と性能試験。運用フェーズには入っておらず、レビューサイドに回ることもなかった。
「ミッションクリティカル領域に求められる確実性・耐障害性」という言葉は入社時から何度も聞いていたが、それを現場で実感したのは障害試験のときだった。
特に印象に残っているのは、片系のRACノードを意図的に落とす障害試験で、Oracle内部の reconfiguration(GRD再構成)処理が想定よりも長時間化していたという事象。原因はインターコネクトのネットワーク帯域不足にあったのだが、リリースまで時間が限られている中で原因が特定できず、冷や汗をかきながら分析を進めたことを覚えている。クリティカルな問題で、「ここを越えなければリリースできない」という状況だった。
もうひとつ、技術的というより組織的な学びとして強く残っているのが、スクリプトのコード管理にまつわる失敗だ。新設のDBチームに一人で配属されていた状況で、DBチームが扱う各種スクリプト群が正しくコード管理されていなかった。リリース直前になって「実は古いバージョンのものを使っていた」ことが発覚し、大事になった。原因は、コード管理を担当していた別チームとの間でうまく連携が取れていなかったこと。
「自分でもっと積極的にコード管理を整えるべきだった」「そもそもチーム間のコミュニケーションが足りていなかった」 — この反省は、今に至るまで自分の中で引きずっている教訓になっている。
正直、Oracle特有のテクニカルな知見で「今でも他の場面で活きている」というものは、思い返してみるとそこまで多くはない。ただ、ミッションクリティカル現場で身についた「確実に動かすために何を確認すべきか」という姿勢のほうが、特定のプロダクト知識以上の資産になっていると感じる。
3. GitLab Runnerを使ったAWSリソース自動構築
銀行の現場に常駐していた時期に担当したのが、GitLab Runnerのパイプラインを使ったAWSリソースの自動構築化だった。
それまでも自動構築の仕組みはあるにはあった。Excelベースで手順がすべて文書化され、手順の中でシェルスクリプトを動かすようになっていた。しかし、シェルスクリプトを動かすためには資材準備や承認が必要で、その承認プロセスが非常に多かった。結果、リソース一式を構築するのに1ヶ月以上かかっていた。
これをGitLab Runnerでパイプラインジョブ化することで、承認の数を減らして自動構築を一気に走らせる、というのが案件の主旨だった。
技術的には、ひたすらシェルスクリプトを開発する仕事で、目新しい技術を学ぶ機会はそれほど多くなかった。むしろ、レビューが緩い環境で、テストコードもきちんと整備されていなかった。「シェル開発であってももっとテストの自動化を進められたのではないか」という反省は、プロジェクトを離れた今でもときどき思い出す。
ただ、この仕事を通じて「AWSリソースを自動構築できる」という感覚を掴めたことは大きかった。これからSREとしてアプリケーションチームに価値を届けようとしたときに、「アプリチームが必要に応じてボタンひとつでリソースを払い出せる」ような環境を提供することは、おそらく重要な役割になる。そういう未来の仕事につながる感覚は、確かにここで得られた。
6年間で変わったこと
「目指すエンジニア像」が変わった
入社時は「プログラムも書けるインフラエンジニア」になりたいと漠然と考えていた。Oracleに深く関わるようになってからは、「データベーススペシャリスト」が次の目標になった。
しかし、データベース自体のサービス化(Auroraに代表されるマネージドDB)が進み、生成AIによってコードを書く作業の意味合いも変わってきた。「DBに深く詳しい人」という方向性だけで自分の価値を出していくのは難しいかもしれない、と感じるようになった。
今は、プロダクトに近い場所で働くSREという像のほうが、自分の価値を発揮しやすいと考えている。AIに置き換えられにくい領域 — システム全体を見て、信頼性をどう設計するか、組織的にどう運用していくか — そこで活躍したい。
技術的な知見と、SIerならではの仕事の進め方
DBやインフラ周りの技術的な知見は、確実に積み上がった。Oracle RAC/DataGuard、TiDBに代表される分散DB、Terraform、AWS、GitLab CI/CD、シェルスクリプト。一通りの引き出しはできた。
技術以外で言えば、SIerというステークホルダーが多い環境での立ち振る舞いを学べたのは大きい。「この打ち合わせに誰を呼ぶべきか」「最終的に誰の合意を取れば案件は前に進むのか」といったキーパーソンを見極める感覚は、若いうちから多くの関係者の中で揉まれた経験ならではだと思う。
もっとこうしておけばよかった
ここからは反省の話になる。この記事の中で、一番書いておきたかった部分でもある。
報連相と期待値調整 — 「自分のための仕事」になっていた
エンジニア以前に、社会人として未熟だったと思うことが多々ある。一番大きいのは報連相、そして期待値調整。
特に反省しているのは、障害が起こったときにすぐに報告できなかったこと。「自分を守るために報告を先延ばしにしてしまった」という瞬間が、確かにあった。
今振り返って思うのは、捉え方の問題だったということだ。「自分のための仕事」になっていたから、自分を守る方向に意識が向いてしまった。何のためにこの仕事をしているのか — 顧客のため、プロダクトのため、チームのため — そこを念頭に置いて行動できれば、報告のタイミングも自然と早くなったはずだ。
障害を学びの場として捉えればよかった
別の話として、障害対応そのものから距離を取ってしまっていたことも反省している。「自分の担当外だから」「自分には関係ないから」と無意識に線を引いていた。
しかし、障害は最も濃密な学びの場だ。普段見えないシステムの境界、依存関係、運用の前提が、障害のときに一気に表に出てくる。あのときもっと積極的に首を突っ込んでいれば、エンジニアとしての成長速度はだいぶ違ったはずだ。
これはまさに、これから入っていくSREロールで取り戻したいテーマでもある。
学びを「自分事」として言語化する習慣
そして、学んだことを自分事として捉え直し、言語化する習慣を早く身につけるべきだった。
言語化できるということは、再現性があるということだ。同じパターンに次に出会ったときに自分の引き出しから取り出せるし、人にも伝えられる。
この習慣があれば、社外発信ももっと早くから充実させられたはずだし、何より自分自身が「6年間で何を学んだのか」をもっとはっきり言語化できていたはずだ。今こうして振り返り記事を書きながら、「もっと早くから書く習慣をつけておけばよかった」と痛感している。
次の環境と個人開発で意識したいこと
ここまで書いてきた反省を、次の環境(SREロール)と個人開発でどう形にするか。最後にそれを言葉にしておきたい。
報告は早く、目的志向で
「自分のための仕事」に陥らないこと。これが出発点になる。何かトラブルが起きたとき、自分を守る方向に意識が向きそうになったら、「何のためにこの仕事をしているのか」に立ち戻る。報告のタイミングは、迷ったら早いほうへ倒す。期待値調整も同じで、「言わないリスク」のほうが「言うリスク」より大きい場面はとても多いはずだ。
障害・インシデントの中心に身を置く
SREというロールは、まさに障害から学ぶことを職務にしているような領域だと思う。今度こそ、「自分の担当外だから」と線を引かない。ポストモーテムを書く、ふりかえりを主導する、そこで得た学びを次の設計やSLOに反映する — そういう循環を自分のものにしたい。
言語化を業務のリズムに組み込む
学んだことを自分事として言語化し、外に出す習慣。これは「時間ができたらやる」では絶対に続かないと、この6年で痛感した。週次のふりかえりで言葉にする、月に一本は技術記事を書く、いずれは英語でも書く — 業務のリズムの中に組み込んでしまう以外にない。
個人開発は「自分事」の訓練場として
個人開発は、業務として誰かに発注されたものではない。だからこそ「自分事にする」ことの本質的な訓練になると思っている。想定ユーザーの話を聞き、機能の優先順位を自分の頭で決め、撤退ラインも自分で引く。SIerの中では味わいにくかった「すべてを自分の責任で動かす」感覚を、ここで積みたい。
そして、開発過程そのものを技術記事として残していく。それがそのまま、上の3つの実践にもなるはずだ。
おわりに — 社会人としての土台を作った6年
この6年を一言で表すなら、「社会人としての土台を作った6年」だったと思う。
エンジニアとしてどれだけ成長できたかは、正直まだはっきりとは見えていない。技術的な知見は積み上がったが、それが今後の自分のキャリアにどう活きるかはこれから次第だ。「6年間良い過ごし方ができたのか」と問われれば、はっきり「Yes」とは答えづらい。
ただ、社会人としての地盤 — 関係者と合意を作ること、ミッションクリティカル現場の重さ、報連相の本当の意味、そして自分の弱みを見つめる目線 — こうしたものは、この6年で確かに身についた。
この記事を書きながら気付いたのは、自分の中で反省の比重がやや大きいということだ。それは多分、よく言えば次の環境で取り組みたいことが明確になっているからで、悪く言えばまだこの6年を100%肯定できていないからだろう。
それでいい、と今は思う。次の環境で、ここで芽生えた「もっと発信したい」「もっと自分事にしたい」「もっと早く言語化したい」という気持ちを、ちゃんと形にしていく。それがこの6年間に対する、いちばんの恩返しになるはずだ。