こんにちは、クラウド会計の開発チームでスクラムマスターをしているasatoです。
私たちのチームでは、以前はフロントエンド（FE）エンジニアとバックエンド（BE）エンジニアがそれぞれの領域だけを担当していましたが、最近では互いに越境し、どちらの領域でも自立して開発を進められるようになりました。このブログでは、その越境のために私たちが取り組んだことを紹介します。同じように悩む方の助けや勇気づけになれば幸いです。
背景
私たちのチームはスクラムでWebアプリケーションを開発しています。エンジニアは職種としてFEエンジニア、BEエンジニア、QAエンジニアに分かれており、FE・BEエンジニアはそれぞれの領域のみを担当していました。
しかし、プロダクトを開発し続けていく中で以下の課題に直面しました。
- FEとBE間でのプロダクトバックログアイテム（PBI）の受け渡しの待ちが発生し、スプリント中にPBIを完成できない
- 職種とのミスマッチで優先度の高いPBIを選択できず、優先度の低いPBIを開発せざるを得ないことが多い
- 職種の考慮が必要なことでスプリントのスコープやプロダクトゴールへの見通しの検討が複雑だった
さらに、直近のプロダクトゴールを達成するためにより多くのフロントエンドの開発が必要であることがわかりました。これらの状況を打破するため、チーム全体としてまずはBEエンジニアがフロントエンド開発に越境する意思決定をしました。
越境のためにチームで取り組んだこと
プロダクトオーナーとの期待値調整
まず最初に行ったのはプロダクトオーナー（PO）との期待値調整です。 越境の取り組みは長期的視点ではチームの効果性を高めることが期待できますが、短期的視点では開発速度が鈍化します。 越境に取り組む前に、POと「長期視点での投資であること」や「いつまでにどれだけの成果が上がらなければ実験終了にするか」を話し合い、期待値を明確にしました。
リードFEエンジニアがサポート優先で動くことにチームで合意
次に、チーム内でリードFEエンジニアが開発タスクよりも越境のサポート活動を優先することの合意形成をしました。リードFEエンジニアは基本的にPBIに取り組みません。その代わり、いつでもBEエンジニアのサポートに入れるようにスケジュールに余白を持たせ、能動的にサポートできることを探し行動します。こうすることで、BEエンジニアがサポートを求めるための心理的ハードルを下げるとともに、迅速にサポートを提供することで、短い期間で越境を達成することを目指しました。 開発の見通しも、1-2ヶ月はリードFEエンジニアを除いた見通しを立て、POやステークホルダーと認識を揃えました。
Typescript & Reactチュートリアル
越境に挑戦したBEエンジニアの中には、昨今のフロントエンドの技術スタックに不慣れなエンジニアもいました。そこで、基礎部分から取り組みたいエンジニアは自身で公式チュートリアルの実施をPBI化し、取り組んでもらうことにしました。私たちのチームでは、フロントエンドの基本的な技術スタックとしてReact/Typescriptを使用していたので、以下のチュートリアルに取り組みました。
設計・実装方針の共有
フロントエンド開発と一言に言っても、組織、プロダクト、チームなどによってその設計・実装方針や思想は異なります。 そこで、リードFEエンジニアに今までFEエンジニア内で暗黙知として蓄積されていた設計・実装方針をドキュメント化し、形式知としてBEエンジニアに共有してもらいました。このドキュメントにはローカルでの実行手順や利用ライブラリの公式ドキュメントリンク、おすすめのエディタ設定（拡張機能）なども記載されており、実際にこのチームでフロントエンド開発をするための様々なTipsが紹介されています。
リードFEエンジニアとモブプロ
基礎的な技術スタックとチームの設計方針を理解したところで、実際のプロダクションコードのコーディングを始めました。まずはリードFEエンジニアと共にモブプロでコードを書き、一人でもフロントエンドのコードを書き始められるように不安を解消していきます。
このモブプロは単なる知識共有だけでなく、安心してフロントエンドのコードを書く経験を積むことを目的として実施しました。そのため、以下のようなステップで進めました。
- リードFEエンジニアが考えていることを話しながらコードを書き、BEエンジニアがそれを眺め、気になることがあれば質問する
- BEエンジニアがコードを書き、リードFEエンジニアが指示したり質問に答えたりする
- リードFEエンジニアもBEエンジニアもモブとして、対等に議論し合いながらモブプロする
いくつかのステップに区切り目的を明示することで、より短い期間で目標の状態にたどり着けました。
雑相（雑な相談）・ペアプロ歓迎
BEエンジニアが自立的にフロントエンド開発を始めたあとでも、リードFEエンジニアはサポート優先のままでいてもらい、雑相・ペアプロ歓迎の状態を維持しました。自立して間もないうちは様々な不安や懸念が出てくるため、それに素早く反応・解消するための取り組みです。特にモブプロのような取り組みで、気軽に雑相を投げかけペアプロを提案できる関係性も構築されており、リードFEエンジニアからもそれらを提案する動きを取ってもらえていたことで自立に向けての歩みを加速できました。
また、ペアプロに関してはBEエンジニア同士でもよく行っていました。これにより、自分一人で課題を抱えない状況と、エキスパートに頼らず調査し課題解決に向かう経験を積むことを同時に実現できていました。
コードレビューの共有
私たちのチームでは、エンジニア間で相互にコードレビューを実施しています。GitHubを使っているので、コード変更者がPull Request（PR）を作成し、ランダムで選ばれたレビュアーとの間で実施しています。 越境の過渡期に限り、コード変更者とレビュアー以外のBEエンジニアもコードレビューのレビュアーとして参加してもらいました。意図的に他の人が書いているフロントエンドのコードと、それに対するレビューコメントを読む時間を確保することが目的です。この取り組みは自分がコードを変更する以上にコードレビューに触れる機会が増え、BEエンジニアがより早くフロントエンド開発のスキルやお作法を会得する助けになりました。
少しつまずいたところ
モブプロやペアプロは精神的に疲れることもある
実際に越境を進めていく中で、私たちは知識共有や課題解決の手段としてモブプロやペアプロといったリアルタイムコミュニケーションを多用していました。しかし、自分がまだその領域に明るくないという自覚がある中で目の前で目まぐるしく議論が展開されていくのは、自己肯定感・自己貢献感を低下させる一因にもなります。 私たちのチームでは、メンバーの一人がふりかえりでこの課題を共有してくれたおかげで、チームに合った知識共有・課題解決を考えるきっかけがあったため大事には至りませんでした。ですが、もしあなたがこのような取り組みを推進するのであれば、この点に気をつけて取り組むことをおすすめします。
コードレビューを共有された時は全てアプルーブしないといけないの？
コードレビューの共有のために、GitHubのレビュアーにBEエンジニア全員を追加するという手段を取りました。これにより、PRを見つけやすくしたり通知を受け取ったりすることができました。一方で、全員のアプルーブがないとマージできないのかどうか、といったチーム内のルールが曖昧なまま進んでしまい、その認識齟齬によって一時的に開発が鈍化してしまいました。 今回のように、特に本来のツールの目的と異なる使い方をしようとしたときは、その目的やそれによってプロセスに変化はあるのかなど、細かいことでも認識を合わせることが大事です。このようなことがあってから、チームのプロセスについてワーキングアグリーメントで明文化する取り組みをしています。
結果
無事越境を果たし、今では職種上BEエンジニアのメンバーも自立的にフロントエンドの開発に取り組んでいます。さらに、このときの経験を活かしてFEエンジニアもバックエンドの開発に取り組めるようになりました。 この結果、背景で言及した課題は取り除かれ、以下のような状態が生まれました。
- FEとBE間でのプロダクトバックログアイテム（PBI）の受け渡しがなくなり、スプリント中にPBIを完成できるようになった
- 職種関係なく、優先度の高いPBIを選択し開発を進められるようになった
- プロダクトバックログとベロシティを指標にして、スプリントのスコープやプロダクトゴールへの見通しをシンプルに検討できるようになった
複雑さやストレスが取り除かれ、よりプロダクト開発に集中できるようになりました。
まとめ
このブログでは、フロントエンドとバックエンドの開発の越境のために実際に私たちがチームで取り組んだことを紹介しました。 今ふりかえると、特に「POも含めて越境の意思決定をしたこと」「開発よりも越境のサポートを優先するメンバーを置いたこと」というチームで越境を実現する共通認識をつくれたことが結果につながったように感じます。
この取り組みが皆様のチームの役に立てば光栄です！
広告枠
We're hiring
私たちはユーザーにより大きな価値を届け続けるために、よりよいプロダクト開発を探求・実践する仲間を探しています！ぜひ採用ページも覗いてみてください！
