f:id:yusuke_y:20211223002403p:plain こんにちは。TRILL開発部でバックエンドエンジニアをしている安尾です。

この記事はdely Advent Calendar 2021 22日目の記事です。

昨日はクラシル開発部SREチームの松嶋さんの「クラシルのSREをチーム化するときに意識した3つのことと半年間の実績」という記事でした。SREに興味がある人、開発チームの立ち上げに興味がある人、是非参考にしてみてください！

今日は僕が所属するTRILL Backendチームにおけるアウトソーシングを有効活用した適材適所爆速開発術について紹介したいと思います！今回の記事ではTRILL開発チーム全体のことではなく、僕が所属するBackendチームにフォーカスした事例の紹介になりますが、他の職種でも活用いただけるのではないかと思っています。

昨今どこの企業でもエンジニア不足という課題がある中で思うような開発速度が出なかったり、機能開発でいっぱいいっぱいになってしまい中長期を意識した技術的負債の解消や新しい技術の検証などといった重要度は高いけれど緊急度は低いタスクが後回しになってしまっている企業やチームは多いのはないでしょうか？

今回の記事はそういった方々に少しでも参考にしていただると嬉しいです！

TRILL Backendチームの責務

まず前提を揃えるためにまずTRILL Backendチームについて少し紹介させてください。

僕たちのチームの役割についてですが、TRILLにはSREやインフラチームが現状存在しないため、サーバーサイドの開発に加えてインフラ（AWS）の構築や運用保守も含めて責任を持っているチームになります。

最近はアプリにフォーカスしているため機会は少ないですが、Webのフロントエンドの開発も必要に応じて行います。

TRILL Backendチームの体制

そんな割と責任範囲が広めなTRILL Backendチームですが、現状僕を含め社員は2名しかいません。（僕も今年10月にクラシルから移動してきたばかりなのでそれまではたった1名でした！）

月間利用者数が2500万を突破するTRILLのサービス規模からすると、社員2名というのはかなり少ない方ではないでしょうか。

移動後直近3ヶ月での成果

社員2名のBackendチームですが、9〜12月の直近3ヶ月間で約15個の新機能リリースに加え、Rubyのバージョンアップ、自動テストの充実、CI・CDの改善など優先度が高いいくつかの技術的負債の解消も行うことができ、プロダクトチームとしての目標KPIも無事達成することができました 🙌

どうやっているのか？

では、いよいよ本題のどうやって少人数で爆速開発を行っているのかについてお話ししていきたいと思いますが、タイトルにもある通り最も効果があったことがアウトソーシングの有効活用になります。

現在社員以外でBackendの開発に関わっているのは、インターン1名、業務委託1名、オフショア開発会社所属の3名の合計5名です。社員2名をあわせると合計7名のエンジニアで構成されていることになります。

先程ご紹介した成果も2名では到底不可能ですが、エンジニアが7名いると考えるとかなり現実的に思えてきます。

とは言え、アウトソーシングを活用したことがある方ならイメージがわくかもしれませんが、人数が増えたからと言ってそれに比例した成果が簡単に出せるかというとそうでもないのでないでしょうか。

多かれ少なかれ下記のようなことに頭を抱えた経験がある人は多いと思います。

社外のエンジニアに依頼したタスクがスケジュール通り出来上がってこない
依頼したタスクの進捗が分からない
出来上がったものが想定と全然違う
コードのクオリティが低く、レビューに想定以上の時間が取られる
常に社外エンジニアの稼働を埋めるほどのタスクを社員が作ることができない
レビューが間に合わずリリースされない機能が大量に溜まってしまう

僕自身もちろん最初からすべてうまく行ったわけではなく前職も含めて過去これらの課題を経験してきました。

その都度改善を繰り返してきたのですが、その中でも有効だと考えていることをいくつかご紹介できればと思います。

カンバンで全体像の可視化と疑似スクラムの導入

改善と言えば、最初にやるのはやっぱり可視化です。

ステークホルダーが増え、さらには直接顔を合わせることがない社外メンバーが過半数を占めている状態なので、意識して可視化を行っていないとすぐに誰が何をしているのかが分からなくなってしまいます。

僕たちのチームも可視化を行う前は、機能ベースで担当がアサインされていたため、お互いが何のタスクに取り組んでいて、どんな進捗になっているのかは、直接担当者に聞かない限り分からない状況になっており、進捗の把握にコストがかかったり、それぞれの機能がいつリリースされるのか把握するのが困難な状況でした。

カンバンで各タスクの担当者、進捗、StoryPointを可視化することで各エンジニアが何のタスクに取り組んでいて、それがいつ終わる予定なのかを誰でも把握できる状態を作ることができました。

次に擬似スクラム（以下、シンプルにスクラムと呼ぶ）を導入しました。疑似とつけているのは、Backendチームだけで行っており、プロダクトオーナーやアプリエンジニアが含まれていない状態で行っているため正確にはスクラムとは呼べないと思ったためです。ではスクラムの何を取り入れたのかというとスプリントという概念とスクラムイベントを取り入れました。

スクラム導入前はざっくり下記のようなフローで開発を行っていました。

社内エンジニアがPMと相談しながら、全員分のタスクを作成し、開発依頼
社外エンジニアはタスクに取り掛かり、終わったら社内エンジニアにレビューを依頼する
社内エンジニアはレビューをしつつ、手が空いた社外エンジニア用のタスクをPMと相談して決めアサインする
2と3の繰り返し

このフローには以下のような課題がありました。

社外エンジニアの人数分、2と3が五月雨に発生するため、社内エンジニアは自分のタスクを計画的に進めづらい
社内エンジニアのレビューや新しいタスクの作成が遅れると社外エンジニアに待ちの時間が発生してしまう
社外エンジニアの着手中のタスクに問題が発生した際に気づくタイミングが遅れる
開発フローに関する振り返りが行われないため、フロー自体の改善がされづらい

そこで、スクラムイベントを導入し、

スプリントプランニングでタスク作成
デイリースクラムで各自のタスクにおける課題の確認
スプリントレトロスペクティブで1スプリントを振り返りKPTの実施

というような決まったサイクルを作ることで、Backendチームで感じていた課題の多くを解消することができました。

設計レビュー会導入で属人性の排除と手戻り防止

次に出てきた課題は属人性と開発における手戻りでした。

これはもともと社内エンジニアが1人のときには存在しない課題でした。なぜから実装をアウトソーシング場合でも設計とレビュー、リリースの工程は必ず1人の社内エンジニアが行っていたためです。

ところが、僕がジョインしたことで社内エンジニアが2名になりました。各機能の設計はどちらかの社内エンジニアが行い、実装はそのまま自分でやるかアウトソーシングされることになります。

設計者自身が実装した場合、もう1人の社内エンジニアがコードレビューを行うことになるため、属人化は防げますが、実装をアウトソーシングした場合はコードレビューは設計者が行い、そのままリリースされていました。

前者の場合は、コードレビュー時に設計変更を伴う指摘が行われると大きな手戻りが発生してしまいます。

後者の場合は、1人のエンジニアはまったく関与しない状態でリリースが行われてしまうため、属人化が起こりその機能でなにか問題が発生したり、機能の変更を行う場合に対応できるエンジニアが限られる（または機能に関与していなかったエンジニアがキャッチアップから入る。しかもドキュメントがないためコードを1から読んだり口頭での引き継ぎが必要）状況が発生します。

そこで、これらの課題を解決するために設計レビュー会というフローを新たに追加し、実装前に設計の合意を社内エンジニア間で取ることを必須としました。設計レビュー会は指定フォーマットに従った設計ドキュメントをもとに行うため、新たな機能にはかならずセットで設計ドキュメントが存在する状態になります。そのため、現在のチーム内での属人性が排除されることはもちろん、今後新たに入ってくるエンジニアも過去の機能に関するキャッチアップが容易になります。

適材適所のタスク割り振り

最後に紹介するのが適材適所のタスク割り振りです。つまり各タスクを最も適した人にアサインするということです。

一例ですが、僕たちの場合は以下のような基準で判断をしていたりします。

不確実性が高いタスクは社内向き
- 例: 使ったことがないAWSの機能やSaaS、ライブラリを用いた開発
- 例: UXに関わる作りながら細かい調整が必要な機能開発
不確実性が低いタスクは社外向き
- 例: UXに関わらない基礎機能の開発
実装が重いものは社外向き
- 例: ログイン機能の実装
実装が軽いものは社内向き
- 例: 既存機能の微調整
重要度が高いが緊急度が低いものは社外
- 例: Rails version up等の技術的負債の解消