人◕ ‿‿ ◕人 「僕たちのサービスで、サービスリードエンジニアになってよ！」
と、いつ言われても大丈夫なように、テックリードエンジニアとともにリードエンジニアの一翼を担うサービスリードエンジニアに関して整理してみます。
恥ずかしながら私自身もゆるふわっとしか理解していないので、いくつかの企業のインタビューなどを引用し、「サービスリードエンジニア」に求められる資質や態度を明らかにできればと考えています。
結論: サービスリードエンジニアとは？
「サービスリード」とは、その一文字を直す作業に意義、喜びを感じられること
早速の結論が引用という暴挙になりましたが、引用元の記事が素晴らしすぎるので、使わせていただきました。
サービスリードに関して調べていく中でわかったことは、
- BASE
- DeNA
関連記事を読むと、ほぼ上記２つの企業のどちらかの情報発信にあたるということです（笑）。
理解を促進するという意味でも、二社の情報発信に心より感謝を述べます。ありがとうございます！
そもそものサービスリードの定義は？
先程の結論がサービスリードの本質をすべて表していると感じましたが、下記３つの引用先で伝えているサービスリードの定義を見ることで、その大枠を掴もうと思います。
- ランサーズ
サービスリードエンジニアは、サービス開発におけるユーザー体験の向上など、幅広い面でチームをリードしていく職業です。主な仕事は、ユーザーの行動などを SQL やアナリティクスツールで解析して、そこからサービスの企画をしたり、実際に企画した機能を実装したりしています。
- DeNA
サービスを成功させるために何をすべきか自分自身で考え、技術力を駆使して率先して実現できるオールラウンドなエンジニアです。システム設計や開発はもちろん、機能やサービスの意図、目標とする数字などを理解して、それに適合するような仕様を自ら考えます。また、これから行おうとする施策について、仮説が正しいかどうかの分析、判断のサポートを行います。
引用元: DeNA採用ページ内 キャリアパス
- BASE
BASEのサービス哲学を熟知し、高い顧客体験を実現するサービスを開発することで、体験の質を通じたサービス信頼性を実現する。 顧客に支持され続けるサービスの継続的発展に寄与し、サービスづくりの模範となる役割。
上記のそれぞれの定義を見ると、サービスへの理解とコミットメントがサービスリードの軸のように思えます。
サービスを通してミッションを実現するために動く姿勢はテックリード・サービスリードともにありますが、
- 開発チームの内的要因（アーキテクチャ・開発環境）への貢献の比重
- 内的要因から育まれたものを外的要因（ステークホルダー・サービス）に伝えるための貢献の比重
上記の働きかけのバランスのうち前者が強いのがテックリード、後者が強いのがサービスリードなのかなと私は感じました。
サービスリードがいることで開発がどう良くなるのか？
シンプルに、“サービスリードエンジニア”がいないとプロダクトが劣化しますね。
前項までの項目で見たように、サービスリードはサービス開発にとって重要な存在であることがわかってきました。
その上で、いくつかの記事を読む中で良いな〜と思った２つの考え方を共有させてください。
1. サービスリードは適切な粒度の問題解決を行うという姿勢
（前略）その修正の粒度や判断力が顧客ニーズや会社のOKR達成に対して不適切であれば、その行動を誰かがマネジメントする必要があります。（中略） 目の前で困っている人、その裏側にいる人を想像し、適切な粒度の修正を行うという判断力は、テックを中心とした思想とは少し違う価値観が求められることが多いようです。
開発サイドはどうしてもビジネスサイド側からの要求を前提条件として受け入れてしまいがちになります。それは、
- サービスにおける勝ち筋への理解
- サービスにおける専門領域への理解
上記のような本質的な分野への深度がビジネスサイド > エンジニアサイドになりがちなことや、
- リファクタされたコード
- 網羅されたテストコード
上記のような負債にならない長期的な価値へのコミットメントを正とする思想がコミュニティにあるからだと思います。
しかし、サービスリードには、そのタイミングにおける適切な粒度の問題解決が必要だと記事では述べられています。
これ…もう…めちゃくちゃわかる…。
この姿勢が、最初の結論で述べたその一文字を直す作業に意義、喜びを感じられることという表現に帰結しています。
ただ、これを実現するにはどうすればよいのか？
これに関しては、下記の2つ目の考え方がヒントになると思っています。
2.「何を作るか」ではなく「どうやって作るか」のエキスパートだからこその示唆を活かす
プログラムにおける設計は、仕様を適切に整理するという過程を経ます。 経験上、その考え方は施策のプランニングにも大いに役立ちます。 だからこそ、エンジニアの強みを企画に還元させるべきなのです。
適切な粒度の問題解決を行うという上で、ビジネスサイドからの要件に対してNOという答えを出すことも重要だと1で触れました。
一方、私達がコードを書いている時に、四六時中サービスのことのみを考えているビジネスサイドの知識や理解に向き合うことはとても大変なことでもあります。
では、何がより良い解決につながるのか。
それは、どうやって作るかを突き詰める過程で、毎日何時間もサービスを触り続けているエンジニアだからこそ、気付けるサービスへの示唆やユーザー側の視点を、技術力にプラスしてビジネスサイドと協業することだと感じました。
日々開発をしていると、開発要件にない部分でも「ここ、もっとこうしたほうがよいよな〜」と気付けることはありますよね。
ビジネスサイド側では気づきにくいその小さなピースを繋ぎ合わせることができれば、より豊かなサービスへの理解をチームに共有できるのではないかと、前述までの記事を読んで感じました。
終わりに(感想)
引用させて頂いた記事のインタビュアー・インタビュイー・編集者、また担当者の方々ありがとうございます。
記事の内容として、引用中心になり、わかりにくい部分も多かったかと思いますが、読者の方のサービスリードエンジニアへの理解や興味が深まれば嬉しく思います。
引用した記事は、どれも素晴らしい内容になっていますので、ぜひ直接触れてみてくださいね！
それでは、HAPPY HACKING!