inFablic | Fablic, inc. Developer's Blog.

フリマアプリ フリル (FRIL) を運営する Fablic の公式開発者ブログです。Fablic のデザイナー・エンジニア・ディレクターが情報発信していきます。

Fablicでのエンジニアリーダーの役割

こんにちは!サーバサイドエンジニアの@sinamon129です。

寒くなって熱燗が美味しい季節になりましたね。

さて、2017年10月から、Fablicのエンジニア組織にて、リーダーという役割をいただきました。

弊社でのリーダーの役割や普段の仕事、やりたいことや課題などを紹介しようと思います。

組織づくりの参考になればと思います。

Fablicのエンジニア組織について

弊社のエンジニアの職域は非常に広いです。

人数も増えたため、組織づくりのために社内教育の促進や技術広報などに責任をもつ三種類の役割が追加されました。

  • マネージャー
    • 社内情報の認識、整理、共有・ 問題の発見~解決までの橋渡し・レポートライン(1 on 1の実施など)
  • プリンシパル
    • コンピュータサイエンスなど一般的な開発知識に基づいた提言/助言・その教育/育成、勉強会の実施・外部発表等によるFablic技術プレゼンスの向上
  • リーダー
    • 業務ドメイン開発/運用知識に基づいた提言/助言・教育/育成/勉強会の実施・緊急障害時などの主体的対応

三種類の役割を持つ人達は、もちろん通常の開発・ファシリテーション(会議だけでなく常日頃)も行います。

リーダーの仕事について

実際の私の今の仕事をざっくりと紹介します。特に、リーダの役割として認識しているものについて詳しく後述します。

  • カスタマーサポートチームの業務効率化のための機能開発
    • webアプリケーションの開発
    • ↑をするにあたって、問題のヒヤリングと解決方法の提案
  • カスタマーサポートチームからのエスカレーションへの対応
    • 不具合と思われるお問い合わせの調査
    • アプリ・web版・管理画面等の仕様への疑問に答える
  • システムの安定稼働を保つための対応
    • パフォーマンスチューニング
    • アラート・エラー発生時にシステムの状態を確認し対応(一次・恒久)
    • パフォーマンスミーティングの実施
      • 週1日、みんなでインフラ周りのメトリクスを見る会
    • システムの問題点を見つけて共有し、修正を検討する
    • SRE部署の準備
  • その他
    • システム構成・仕様等に関するみんなの疑問に答える・相談にのる
    • コードレビュー
    • ドキュメント化されていない仕様をドキュメントにまとめる

(※ もちろんこれは担当1人でやってるということではないです)

カスタマーサポートチームの業務効率化のための機能開発

通常の開発にあたります。 カスタマーサポートチームの追っているKPIを見たり状況を聞きながら、工数を減らしてミスなく対応数を増やせるようなシステムを一緒に考えて実装します。

システム構成・仕様等に関するみんなの疑問に答える・相談にのる

業務ドメイン開発/運用知識に基づいた提言/助言にあたります。これは毎日高頻度に発生します。 もちろん仕様は全部覚えられるわけではないので、索引的に覚えていて、ドキュメントを引っ張り出しながら回答しています。 ドキュメントが無い場合は作成もします。

アラート・エラー発生時にシステムの状態を確認し対応

緊急障害時などの主体的対応にあたります。 障害時はすぐに復旧できることが多いですが、解決に時間がかかることも多いので、その時は分担して調査対応したり、 カスタマーサポートチームに連絡してお知らせを作成してもらうこともあります。

リーダーになるまで

私は2015年4月にFablicにJOIN*1したのですが、 入社から現在に至るまでずっとフリルのサーバサイド開発に携わってきました。

JOINした時会社はサービスは3年目、社会人2年目でした。 Githubに切られている細かいissueをひたすら拾って直す役割をしていました。

そんなことをやるうちに、商品検索に興味を持ち、検索チューニングやElasticsearchサーバの管理等を手を上げてやるようになりました。 (その後検索チームに引き継ぎ、沢山改善されました 👏)

少しずつ成長して大きめの開発案件をやるようになったり、不具合修正の調査の一貫でサービスのありとあらゆるところのコードを読む必要が出てきて来るようになりました。読んだり説明しているうちに、自分の書いていない部分の仕様を把握するようになってきました。

また、サービスの成長と共に悲鳴を上げてくる部分にも同僚と立ち向かっているうちに、 クラウドインフラやパフォーマンスチューニングの知見も得られるようになりました。

その中で大事にしてきたのは、絶対誰よりも早く問題を解決するぞ!*2という強い気持ちです。

そんな背景でちょっとずつ力をつけ、今年に入ってからは新しい人も増えた事により、 歴史的背景等も踏まえて説明したり改善案を提案することが増えたため、リーダーの役割をいただきました。

やっていきたいこと

我々のサービスは業務ドメイン知識が多く、入社したての人がサービスの全容をつかむことは極めて困難であると思います。

日が経過するに連れて、仕様やデータはどんどん増えていきます。新規メンバーが入るアイドルグループにおいて、 後に加入すればするほど覚える曲数が多いように、一般的に新しく入社する方が全貌を把握するほうが大変です。

最近サービスの成長に伴い入社する方が増えているので、入社した方が業務を始める前に迷わないような状態にしたいと思い、 以下の様なことを考えています。

長く在籍している人も、特定のコンポーネントのみを触ることが多い人には役に立つのではないかと思います。

  • サービスのシステム仕様を俯瞰して把握できる状態を作る
  • サービスの中核となる主要機能に関して概要や構成をまとめて共有を行う
    • ドキュメントの作成・更新
    • 定期的に勉強会の実施

これを行うことによって、入社したての人が全貌をざっくり把握することを助けるだけではなく、 システムの新規構築・改修時もしくはレビュー時に考慮できる点が増えて、品質を向上させる事ができるのではないかと思います。

また、特定の誰か聞かないとわからない知識は基本的にないようにしていくこと(SPOFを作らない)が、 スケールする組織には必要なことだとおもうので、そういう観点でも良さそうです。

たまにこういったドキュメントを作成するのですが、ちょっとした歴史を入れるようにしています。 入れることで当時の設計者の気持ちがわかるので、コンテキストの理解を助けてくれることがあります。

課題

普段の業務をしながらこれらのドキュメントを作成・更新するのは大変です。

スタートアップから急成長してきたシステムの仕様を継続的に作成・更新していくのはどういう風に行っていくべきなのか、考えることは多いです。 テストコードは仕様書といいますが、システムの背景を全てコードに反映することは出来ません。 全部を暗記しているわけではないので調べまくる必要があります。

主要コンポーネントごとにチームを分割して、各コンポーネントごとに連携を取るようになる未来がいいのだろうかなど、どうすればいいのか日々迷います。

先の未来に思いを馳せながら少しずつより良い状態を作っていきたいものです。

組織の拡大に伴って、システム仕様の共有をこういう風にやったら良かったよ!この本が役に立ったよ!というものがあったら、ぜひ教えてください。

まとめ

弊社でのリーダーの役割や普段の仕事、私がリーダーになるまでの道のり、そしてやりたいことや課題などをざっくばらんに書かせていただきました。

自分もこういう役割しているよ!興味あるよ!ということはぜひ情報交換したいです。

何かの参考になれば幸いです。

*1:実は大学4年生の時に半年間インターンしていたので、これは二度目のJOIN

*2:ユーザさんに安定したサービスを提供したいですし、ベテランの皆さんと働いてるので気がついたら早く原因を見つけられてしまう