コードの改善からSREまで、負債に向き合うことで得たスキル
技術的負債を返済することは大事であるとはいえ、それに向き合いたいと思うのは「リファクタ大好きな一部のエンジニアぐらい」と西銘氏は言う。多くのエンジニアはユーザーにとっての本当の価値に向き合いたいと思うのは当然だ。だがこのまま放置すると、いくらエンジニアの人数が増えても、ユーザーのための課題解決に使える時間はあまり増えないことになる。さらに「本来向き合いたい課題に向き合えないつらさで、より多くの仲間が退職してしまうリスクも高まってしまうと考えました」（西銘氏）
エンジニアの仕事を「不確実性を削減し、プロダクトを確実なものとして作り上げていくこと」と捉えている西銘氏は、コドモンでどんな働き方をすると、不確実性を削減できるかを考えたという。「向き合うべき課題は技術的負債の返済だと思い、積極的に負債に取り組むことにしました」（西銘氏）
では技術的負債に向き合うことで、エンジニアとして何を得られたのか。西銘氏は「仕事」と言い切る。有名な「仕事の報酬は仕事」という言葉の意味を、技術的負債の返済を通して実感したといい、その経緯について次のように語る。
技術的負債を解消するため、まず西銘氏が取り組んだのはレガシーコードの改善である。コード修正によるリスクの低減とコードの複雑さを下げるためだ。「リリース環境に放置されていた野良コードのGit管理化とたくさんの処理が依存していた神クラスの解体を行いました」（西銘氏）
地味ながら丁寧な調査や慎重なリリースが求められる作業を繰り返してやりきった結果、可読性と変更容易性が大きく改善し、開発者体験が向上したという。
このことにより、当時のマネージャーからDX（Developer Experience：開発者体験）改善に注力してみないかと声をかけられ、西銘氏はDX改善という新しい仕事に取り組むことになった。
DX改善に取り組む中で、西銘氏は開発者の全員が行うリリース作業によるリスクに着目するようになったという。「開発者がコードを修正してリリースするまでにトイル（手作業）の手順が多数あったため、その削減に取り組むことにしました」（西銘氏）
トイルの削減のため、西銘氏は開発用、アプリ版リリース用、Web版リリース用と3つに分かれたリポジトリの統合に着手。そしてそれに伴うビルド、デプロイ運用を整備し、リリースフローをGitHub Actionsを用いて自動化することを行ったという。その結果、リリース作業の均一化、工数の削減が実現。「開発組織にGitOpsの文化を根付かせるきっかけとなりました」（西銘氏）
現在はCI/CDをはじめ、自動化できるモノはみんなで自動化する文化ができているという。
このようにリリースフローの整備というDevOpsに近い仕事に携わったことで、SREチームから「DevOpsの経験があり、アプリも触れるので、SREチームでプッシュ通知基盤の改善に携わってみてはどうか」という仕事の誘いが来たのである。この誘いを受け、現在西銘氏はSREチームで、負荷によるリスク低減や大きくなった開発組織が動きやすいよう、サービスの疎結合化を意識してプッシュ通知基盤の改善や既存サービスの負荷調査に取り組んでいるという。
最初はレガシーコードの改善に愚直に取り組み、プロダクトの深い知見を蓄積。それが次のDX改善という新しい仕事につながり、DX改善では、CI/CDツールの活用により、開発作業におけるビルド集約やリリースの自動化というスキルを習得した。これまでの経験から誘われたプッシュ通知基盤の改善では、DockerやAmazon ECSを用いたコンテナ設計のスキル、さらにはTerraformを使ったIaC（Infrastructure as Code）によるインフラ構築のスキルを身につけることができたという。
SREチームのメンバーとして日々の業務に取り組むことで、システム監視についての知見を深め、Datadogによるダッシュボードの作成やアラート設定ができるようになったり、データ分析ツールや負荷テストツールを使った負荷調査なども一人で実施できるようになったりしたという。「このように技術的負債に向き合ったことで、仕事の幅が広がり、その副産物としてスキルの幅も広がりました」（西銘氏）
技術的負債を返済すると、プロダクトの次の理想像が見えてくる。「その理想像への障壁はまた新たな負債である。そうして新たに見えてきた負債もまた返済していく。この流れを繰り返していくことでプロダクトは成長する。プロダクトが成長すると、ユーザーにより安定したプロダクトを届けるために自分が挑戦できる機会と手段が増えていく。こうして得た機会と手段に挑戦し続ける姿勢（技術的負債に向き合い続ける姿勢）が、結果的にスキルの幅の広がりにもつながったのだと西銘氏はいう。
