はじめに
atama plusで働くエンジニアのミッチーです。
最近、私のチームで初めて業務委託エンジニアの方にJoinいただきました。atama plusのプロダクトチームは、スクラム開発を採用しており、密なコミュニケーションを取りながら日々働いています。フルタイムで動くスクラムチームと週2-3日稼働の業務委託エンジニアが協力しながらどのように開発を進めていったか、いくつか工夫があったのでその点について書いてみようと思います。普段スクラム開発をしていて、これから業務委託の方にJoinいただくことを検討している方に、少しでも参考になれば嬉しいです。
採用とオンボーディング
採用プロセスについて細かくは書きませんが、面談時には働き方のイメージがすり合わせられるよう、どのようなチケットを渡す予定か簡単に説明しました。
- チケットの種類は、バグの調査・修正や、その他開発テーマの実装が主になること
- 基本的には、ある程度要件定義が固まったチケットを渡すこと
- 要件が固まりきっていないチケットもあるが、その時は柔軟にコミュニケーションを取りながら進めたいこと
特に最後の点は、普段スクラムチームで開発している時、サッとコミュニケーションを取りながら進めていることがよくあったため、要件がカッチリ固まっていないチケットでも柔軟に進めることに抵抗がない人だとやりやすいと思いお伝えするようにしていました。
採用後はスムーズに業務に入れるようにキックオフミーティングを行いました。チーム体制の説明、メンバーとの顔合わせ、チケットの管理方法やコードレビューフローについて説明をし、スムーズなスタートが切れるようサポートしました。
開発環境構築や各種アカウント発行等の情報は、業務委託エンジニア向けのオンボーディング情報がConfluenceに丁寧にまとめられていたので、そちらを渡すだけで完了しました。
atama plusのドキュメント文化に感謝です。
また、コミュニケーション面でのハードルを下げるため、
「わからないことがあれば、いつでもSlackでメンションしてください！」
ということを明確にメッセージとしてお伝えしました。
稼働日数の関係でデイリースクラムなどのセレモニーを共にできないため、情報の同期が取りにくかったり、親睦を深めるような機会も基本的にありません。そんな中で少しでも働きやすくなってもらうことも大切だと考えていました。
定例ミーティング
業務がスムーズに進むよう、週1回の定例ミーティングを行うことにしました。アジェンダは以下の内容です。
- チケットのステータス確認
- お悩み解決・対応方針の決定
- 完了したチケットの稼働実績ポイントをつける
- 新規にお渡しするチケットの説明
- ミニレトロスペクティブ（活動の改善のため）
この中でも「稼働実績ポイントを付ける」というところについて少し補足します。
ベロシティ計測
ベロシティは、1スプリントあたりに消化できるポイント数の目安です。
私のチームでは、to B向けの事業を担当しているのですが、事業の特性上、半年程度の中期的な開発スケジュールを引くことがあり、その際業務委託リソースを開発戦略へ組み込む為にベロシティの把握が必要でした。
完了したチケットに対して稼働実績ストーリーポイントを付けることで、業務委託エンジニアがこなせるベロシティを把握し、開発スケジュールを見積もれるようにしました。
普段スクラムチームで開発する時は、実装着手よりも前にリファインメントをしてポイントを付けるという活動をしますが、業務委託エンジニアの方と共にスクラムのセレモニーを一緒に行っていくことは難しかったため、今回は作業完了時に一緒にポイントをつけるという取り組みを行ってみました。
直近の自分のチームのポイント感覚を言語化し、それを共有してから実績ポイントを付けてみました。その時共有したポイント感覚は以下のようなイメージです。
- 0.5pt ラベル修正程度の半日以下で終わるもの
- 1pt: 1人1日程度で終わる作業
- 1ptと3ptの間
- 3pt: 1人で1週間程度時間かかるぐらい？
- 5pt: 1スプリント（1週間）をまたぐイメージ
1、2回は上記のポイント感覚を意識しながら一緒にポイントを付けましたが、それ以降は他の作業との相対評価でポイントを付けました（厳密にやろうとせずにこれぐらいですかね〜の感覚です）。
上記の基準だと作業時間ベースでの表現になっているため、そのまま使い続けるとチケットの工数感が正確に把握できないと考えました。例えば業務委託エンジニアの方がシステムへの習熟が進み、作業効率が上がっていった時、本来ベロシティが上がっているのにもかかわらずそれがベロシティの計測結果に表れてこないため、本来のベロシティが正確に測れなくなると考えたからです。
このやり方は手探り的に行っているので、正直どこまで正確にベロシティが測れるのか、長期にわたって有効なやり方なのか、それとも大きく誤差が生じうるのか、このあたりはあまりわかっていません。しかし、開発スケジュールを立てるためにもベロシティの把握は重要です。完璧な精度ではないとしても、スケジュールの見通しを立てて、PO、ビジネスのメンバーと会話をするために必要な取り組みでした。
その他気をつけたこと
- コミュニケーションをスムーズにするため、いつでも質問しやすい雰囲気を意識して作りました
定例の様子
- 業務委託エンジニアのブロックにならないよう、質問、レビュー依頼に対しては当日か翌日には返答することを心がけていました
- 業務委託リソースの管理にかける自分の作業時間はなるべく週の作業時間の約1割程度に抑えるように意識しました
- PRレビューは一人に集中しすぎないようチームのメンバーで分担して行いました
- スプリントごとに担当を回すなどの運用をすると負担が偏りにくくできます
業務委託エンジニアリソースを追加することで感じたメリット
atama plusでは、セオリー通りにスクラムを実践し、プランニング、デイリーMTG、リファインメント、スプリントレビュー、レトロスペクティブといった多くのセレモニーを行っています（状況によっては実装作業を優先するためにセレモニーの調整をすることもあります）。
これらの活動はチームで一丸となって開発を進めていく上で大切なものですが、セレモニーに参加せず、実装に集中しているメンバーがいることでチームの開発速度が加速する部分もあると感じました。
ある程度具体の内容が決まっているものは積極的に業務委託の方にお願いし、逆に他チームとの重めの調整が発生するようなものをスクラムチームで対応することで、バランス良く開発を進めていけると感じました。
おわりに
フルタイムで働くatama plusのスクラムチームと週2-3日稼働の業務委託エンジニアがどのように一緒に働いているかの一例を紹介しました。
定例を実施する、などは業務委託エンジニアの方と働くときには割と一般的に行われることかと思いますが、その中でも小さな工夫をしていたのでそのことを中心に書いてみました。
チームとして初めて業務委託の方と働くことになるので、うまく活躍してもらえるか心配でしたが、現在はチームの成果の拡大に大いに活躍していただけています。
これからも運用を改善しながら、業務委託エンジニアの方の力も活用して、一緒にatama plusのプロダクトのさらなる進化を加速させていきたいです。
We're hiring!
atama plusは教育を一緒にテクノロジーで解決していけるエンジニアを探しています！
興味があればぜひご応募ください！
Discussion