ID:24077さん

# 概要 ある特定の機能で過剰な属人化が進んでいた。 それらを解消するため、必要な情報を整理し一元化を行う 自ら当事者がやっている仕事に飛び込み、仕事の内容を吸収し、業務フローを作成 その後チーム内で取り組めるように仕組み化を行う。 社内でも自身の行動がきっかけとなり、新たにこの機能専門で運用保守を行うチームの立ち上げが決まった。 # 課題 SDKを使用している難解なサービスの運用保守を、特定のエンジニアが意識的に情報をキャッチアップし、外部のエンジニアと誰も見えない形で英語でやり取りを行い、アップデートを慈善的に行なっていた。 またこれらの行動を社内で把握している人がいなかった。 この機能に関する問い合わせなどは全て、このエンジニアが行なっており、当人のリソースが非常に圧迫されている状態であった。 また、あらゆるところに情報が散見していたり、必要な外部サービスのアカウントも整理されておらず、 誰がどのような権限を持っているかも全てあやふやな状態であった。 当人が退職すると、いつサービスが停止してもおかしくないリスクを持っていた。 # 取り組み まず初めに、当事者であるエンジニアが問い合わせ対応を行なっているところに自ら飛び込み、 業務を理解するところから始めた。 業務を理解すると、ある一定の判断基準が見えてるようになり、深い知識がなくとも対応できる部分が見えてくるようになるので、それらを資料にまとめ自身が対応を引き継ぐようにした。 次にアップデートのキャッチアップ手段を確認した。 多くの場合、自発的に該当のGithubやブログを見に行っている。ということなので、これらのRSSを取得し、一つのSlackチャンネルにまとめることにし、チームのエンジニアはそのチャンネルに参加し業務の見える化を行った。 これらを整理したあと、 問い合わせ対応とアップデートのキャッチアップをチーム内で行なっていきたい。と意思表示を行った。 「何をして欲しいのか」を明文化し、困ったときは気軽に質問できるように、常に自身はハドルを開いておくようにした。 # 役割 フロントエンドエンジニアではなく、エンジニアとしてやるべきことを行った。 エンジニアリングマネージャーなどに近い行動かもしれません。 また、これらの改善行動をしながら通常のプロジェクトにも継続してコミットしていました。 # 成果 以降、問い合わせ対応はチームから選出された人が行い、当人の負担は非常に楽になったと言ってもらえた。また、チーム内で困った時はみんなで集まって一気に解決しよう！という雰囲気を作ることができた。 アップデートのキャッチアップも問い合わせ担当者が週ごとに行い、最終的に詳しい人間がレビューすることで安心感を担保しつつ、少しずつ業務負荷を減らすことに成功した。 まだまだ改善の途中ではあるが、自身の行動がきっかけとなり、これらの業務が属人化していることが明るみになり、業務整理を行うための期間限定のチームが発足することとなった。 私としても、これらの業務は得意とすることでもあり、 数多くいるフロントエンドエンジニアの中でも誰もしない行動であることから、強みでもあると思っており自信にも繋がった。 またエンジニアリングとは何かを考えるきっかけにもなった。