こんにちは、STORES ECでフロントエンドエンジニアをしている@daitasuとバックエンドエンジニアをしている@phayacellです。
STORES ECでは、今年の5月よりエンジニア内の大きな体制変更がありました。 その変更では、フロントエンド/バックエンドで分かれていたチーム体制から、デザイナーやプロダクトマネージャーも含めた職能横断型のチーム体制へと変更になったのですが、この記事では、その際に生じた、今まで各チームで行っていた開発の進め方とのギャップや手法をマージしていく上での課題について、またそれらをどのように解決していったのかについてをお話しします。
チーム改善までの背景
組織体制の変更
元々STORES ECでは、フロントエンド/バックエンド/デザイナーは独立したチームとして動いており、PJTとしてメンバーが切り出されてはいますが、活動の主体としては職能で分かれている組織構成になっていました。
組織変更の詳細については、また別記事で折に触れると思いますが、
- 職能間のコミュニケーションコスト削減
- チーム内での意思決定完結の幅を広げる
- 自己組織化する事で、継続して進化していく組織にする
などあり、5月以降、下記のようにフロントエンド/バックエンド/デザイナー/プロダクトマネージャーを横串にした職能横断型のチーム体勢となりました。
筆者らが所属するラインは、いついつからこの組織体制に変わります、という始まりではなく、今まで同様の1つのPJTを進める過程で、バックエンド主体のチームに1人ずつメンバーが増えていき、少しずつ職能横断型へと変わっていきました。
理想のチームって？
今までのチームと異なり、職能も混ざり、人数も2倍となったため、今までの方法だと立ち行きません。 開発の進め方、スクラムイベントの行い方など、いろいろな手法について、新規の職能横断型チームとして対応していく必要が出てきました。
理想のチーム状態というのは組織によって様々あると思いますが、今回の体制変更の趣旨も踏まえると、大枠として下記のような事が重要になります。
自己管理できる組織であること
職能がマージされても、チームとしての意思決定がうまくいかず、スピードが落ちてしまったり、結局他のチームに意思決定を依存してしまったりすると意味がありません。
チームが持つ責務、意思決定範囲をメンバーが理解し、自分たちのゴールや役割を認識できていることが重要です。
チームとしての課題が表面化でき、改善サイクルを回せること
チームが横串となり、多くの課題が出てくるはずです。
それらを洗い出し、その解決をナレッジとして蓄えていければ、他のチームとシェアしたり、今後も会社として役立てていく事ができます。
そのためにも、チーム内で共通の価値観を持って話せること、議論の心理的ハードルが低いことなども重要になります。
さて、ここからはそんなチームを目指すべく、職能横断となり出てきた様々な課題をどのように解決したかをお話ししていきます。 タックマンモデルだと、形成期~混乱期をどのように乗り越えていくのかのお話です。
① チームとしての共通認識をつくる
課題
新たにチームができたので、チーム自体にまとまりができるには時間がかかります。
また、今回はコロナウイルスの影響もあり、フルリモート体制でのチーム変更となりました。 人によってはまだ一度もあった事がないなど、全員の顔が分からないままのスタートでした。
施策: チームキックオフ
少しずつメンバーが増えて今のチームへと変化したため、「このチームでやっていくぞ！」というようなタイミングもなかったため、改めてキックオフMTGの時間を設けました。
このMTGでは、チームの目的や役割分担の共通理解を持つように試みました。
各メンバーの自己紹介だけでなく、チームとしての目的を会社から見たチームの役割を改めて言語化したり、これから行うPJTの認識合わせをしました。
また、チーム内の役割分担として、プロダクトオーナー、デザイナー、バックエンド、フロントエンドのそれぞれに対し期待していることを挙げ、お互いの役割を再認識することで、チームとしての共通認識を持ちました。
② MTGガイドラインを作成する
課題
チームが肥大化した後も、しばらくは今まで元々の母体であったバックエンドチームでのMTG方式をそのまま引き継いでいたので、新チームとして再度MTGの進め方を定義し直しました。
施策: デイリースクラム（昼会）の改善
毎日行っている昼会は、Slackで今日やることだけを報告する形でした。
これには以下のようなデメリットがあります。
- 作業の連絡のみで、何に向けた取り組みかがわからない
- メンバーが感じている懸念を拾い上げることができない
- コミュニケーションロス
リモートということもあり、より気軽に相談しあえる形にしたい思いがありました。
下記のように変更しました。
- 昨日やったこと
- 今日やること
- 共有事項/困ったこと/雑談
こうすることで、共有/相談をしやすくなり、雑談もどんどん増え、最近やっているゲームの進捗や低気圧にやられている話など、昼会の活気がとても高まり、相談しやすい場が形成されました。
施策: スクラムイベントガイドラインの作成
スプリントレビュー、スプリントレトロスペクティブ、プランニングについても、各イベントで何を行うのか、ガイドラインを新たに作成しました。
このガイドラインを引くにあたり、事前にSlackで下記の観点で懸念事項やあるべき姿を洗い出し、一通り議論が進んだところでMTGをして最終Fixをするように進めました。
- このイベントが必要などうか/必要な場合どのくらいの時間を取るべきか
- このイベントには誰が参加すべきか。全職能いた方が良いのか、特定職能に絞るべきか
- このイベントで何が解決したらゴールとなるのか。また、そのために必要な事前準備などはあるか
これらの定義をガイドラインとしてまとめ、各スクラムイベントでの取り組み内容とゴールラインを明示化したことで、「この時間は何をする時間なのか」がはっきり分かり、メンバーそれぞれの議論する内容が同じ方向を向いて話せるようになり、準備やMTGの進め方についてもやることが分かりやすく、スマートに進むようになりました。
③ 振り返り手法を統一する
課題
ベロシティの見積もり方法や振り返り手法が職能ごとに異なり、一緒にスクラムイベントを行いつつも、今まで通りの職能ごとのMTGもそのまま残ったままだったため、MTG量が倍になりました。
施策: 振り返りフォーマットの統一
上述のガイドラインで、職能ごとのイベント、合同イベントを整理していく中で、一番難しかったのが振り返り方法の統合でした。
それぞれ議論しているツールが異なり、ベロシティの振り返り方法も異なっていたため、ベロシティの感覚値がズレていた為、良いのか悪いのかが分かりにくい状態でした。
対策としては大きく2つです。
1. ベロシティの記録方法の統一
毎週スプレッドシートに記録を残し、平均値などを出すやり方で、職能統合しやすい形にフォーマットを整形して、同じスプレッドシートで管理することにしました。
筆者らのチームでは、複数PJTが並行して走ることが多いのですが、職能ごとの進捗や作業内容が見え難かった状態から、
- 今週の進捗
- 何をやっていたか
- ベロシティの鈍化のブロック要因は何か
といったことが分かるようになり、課題を表面に出してすり合わせしやすくなりました。
2. KPTのルール統一
今まで振り返りは各職能ごとにKPTを行っていたのですが、統合するとチームとしての話がメインとなり、職能内で議論したい内容(フロントで言うとTypeScriptの設計やPJTに限らないフロント全体で感じている課題感の議論など)を議題に上げにくくなります。
そのため、
- 職能別振り返り(30m)
- 合同振り返り(30m)
と続ける形で時間を取り、職能別の課題もこぼれないようにMTGを組み直しました。
しかし、このようにすると振り返りの時間は膨大になります。
合同MTGで議論したい内容だけに絞って話したいので、MTG始めに黙読の時間を取り、気になった内容や「いいね！」と思った内容にはスタンプを押し、それらを中心に議論するようにしました。
これによって、KPTは発散させつつも、より全員で詰めたい内容に時間を裂き、Tryに繋げやすくなりました。(Tryは毎週1~2個に絞り、達成しやすくしています)
結果
上記のような施策をおよそ数ヶ月続けてきたことで、チームとしての共通認識を持って議論しやすくなり、各スプリントで課題出しと改善サイクルを回せる体制が整ってきました。
それに伴い、スクラムでやるべきこと、分けて進めた方が良さそうなことなどの棲み分けなども見えてきて、まだまだ改良の余地がありそうです。
私たちが目指す理想のチームとしては、自己管理できる組織であること、課題を洗い出すことができ、それらの改善サイクルを柔軟に回せること が必要になります。
チームの形成から最初の段階は、この課題の表面化や改善サイクルを回しやすくするまでが長い道のりですね。
まだチームは混乱期を抜け、統一期として足元の整備をしている状態。成果が上がりやすくなるまでには、色々な挑戦をしていく必要がありそうです。
今後も健全な成長を続けられるよう、柔軟に変化していけるチームづくりをみんなで目指していこうと思います！
heyではエンジニアのみならずデザイナー、PM、CS、セールス、コーポレートなど全職種で採用活動を促進中です。
興味のある方は是非とも採用ページをご確認ください！
