開発チームリーダーとしてやってきたことのふりかえり

DevelopersIO 2023のビデオセッションにて「開発チームリーダーとしてやってきたことのふりかえり」というテーマで発表をしました。

私が開発チームリーダーを数年続けたなかでの学びをふりかえった内容となります。この内容が皆さんのチーム開発において進め方の参考にできれば幸いです。

Transcript

1. 開発チームリーダーとしてやってきたことの ふりかえり 2 0 2 3 / 0 8 産業⽀援グループ ⼩売流通ソリューション部 野村啓⼀
2. ⾃⼰紹介 2 産業⽀援グループ ⼩売流通ソリューション部 prismatix 注⽂/決済サービス担当 野村啓⼀
3. prismatix とは 3 • EC / CRM特化型プラットフォーム • クラスメソッドのB 2 B⾃社サービス • エンゲージメントコマース • 伴⾛型コンサルティング https://prismatix.jp/
4. 今回お話すること 4 私が開発チームリーダーを 数年続けたなかでの学びをふりかえります 皆さんのチーム開発において 進め⽅の参考にできれば幸いです
5. アジェンダ 5 •開発チームリーダーとして主にやってきたこと •私が考えるチームの理想形 •チーム開発で直⾯した課題‧取り組みとそこから得た学び • 課題に対してどのようなことを取り組んできたか • 取り組んだことから得た効果、学び •次に取り組むこと
6. 6 開発チームリーダーになって 主にやってきたこと
7. チームリーダーになるまで 7 •2017年10⽉ クラスメソッドJOIN • prismatix 決済サービスの開発を担当 • 最初はテックリードと⼀緒に２⼈３脚で開発 • テックリードが離れ、他チームから決済サービスを担当する仲間が増えてチーム化 •2019年7⽉〜 • 決済サービスのチームリーダーを担当 決済領域を担当
8. チームリーダーになるまで 8 •2021年7⽉〜 • 注⽂領域のサービスを担うチームと統合し、注⽂決済チー ムとして引き続きリーダーを担当 注⽂領域も 担当することに
9. 主な役割 9 •注⽂決済領域の課題から、優先すべき開発タスクを計画‧ リード •顧客環境で発⽣した障害の司令塔、問い合わせやアラートの 窓⼝ •各タスクをメンバーに委譲 •新規メンバーのオンボーディング、フォローアップなど
10. 1 0 私が考えるチームの理想形
11. チームの理想形 1 1 •チームメンバーが課題や顧客が求めているも のを認識し、そのための対応をチーム内で協 ⼒してできること • 各メンバー個⼈が↑まで出来ることではな く、「チーム内で協⼒しあって」できるこ とが理想
12. 1 2 これまでの開発で直⾯した課題‧取り組みと そこから得た学び
13. 直⾯した課題 1 3 •新しいチームメンバーへのケア •担当領域の説明が頻発して時間を取られる •個⼈スキルのサイロ化 •リーダーとしての所作に迷い •想定以上に時間がかかるプロジェクト etc …
14. 取り組みとそこから得た学び 1 4 各課題に対してチームで取り組んだこと、 
 そこから得た効果‧学びを紹介していきます。 学びになったこともあれば、 効果が⾒込めなかったことも
15. 新しいチームメンバーへのケア 1 5
16. 新しいチームメンバーに対する悩み 1 6 •リーダーを担って以降、新しいチームメンバーが続々と⼊る ようになった • チームメンバーに対するフォロー経験が当初は少なく、 ⼊ったばかりのメンバーが何をしてよいかわからない状態 が続いてしまった • 逆に私がチームメンバーに対して、何をすれば⽴ち上がり をフォローできるか、当初は明確にできていなかった
17. •それまではちゃんと実施していなかったが、チームメンバー と毎⽇話す機会として朝会‧⼣会（デイリーミーティング） を実施することにした • 朝会ではメンバーがその⽇やることを確認、困っているこ とがあればフォローする • ⼣会ではその⽇予定してたことの状況、新しい困りごとを 確認して明⽇以降の対応について決める 取り組み①デイリーミーティングを実施 1 7
18. 取り組み②スプリントごとにふりかえりを実施 1 8 •スプリントごとに以下をふりかえり、次のスプリントで実施 するアクションを決める • 対応してよかったこと • 課題と感じていること • 次のスプリントでやること
19. 取り組み③オンボーディング資料の整備 1 9 •オンボーディングとしてやるべきことを資料化 • 初めてチームに⼊ったメンバーが最初にやること、準備す ることをまとめた • 新しいメンバーが⼊ったときはその資料をもとに説明する ことに
20. チームメンバーのケアで取り組んだことの効果 2 0 •メンバーと⽇々コミュニケーションを取る機会を作ること で、特に新しいメンバーが何に困ってるかを早めに把握でき た •ふりかえりをすることによって、メンバーが課題と感じるこ とや学びと思えることが可視化できた •オンボーディングの資料を整えたことで、私だけでなく他の メンバーも新規メンバーの受け⼊れができた
21. 担当領域の説明が頻発して時間を取られる 2 1
22. 悩み 2 2 •チームメンバーへのケアをしていく中で、メンバーが決済 サービスそのものの仕様の理解に苦しんでいる •顧客や社内の他チームからも仕様の問い合わせが尽きない • ⾃分やチームが本来開発にあてる時間も割いてしまってい る
23. 担当領域の説明資料を作った 2 3 •会社ブログやイベントで決済のシステムについて説明
24. 説明資料を作った事による効果 2 4 •担当領域の仕様をより⼀般向けに説明できる形にしたこと で、チーム内外に説明しやすくなった •この資料はそのまま、新しく⼊ってきたメンバーへのオン ボーディングとして利⽤できた
25. まだ残っている課題 2 5 •元々の悩みだった問い合わせが減ったかというと、そうでも ない •個⼈のスキルに依存していることがまだ残っている • 利⽤する外部サービスごとの詳細仕様 • 外部サービスを追加する上での決めごとなど
26. 個⼈単位でスキルがサイロ化（属⼈化） 2 6
27. 属⼈化している悩み 2 7 •2021年にチーム編成が変わり、決済だけでなく注⽂領域の サービスも担当することになった • 元々いたチームの担当サービス以外の仕様理解が難しい • 顧客から問い合わせやアラートを受けても対応できるメン バーが限られる • 問い合わせが集中するとそのメンバーの負荷が⼀気に⾼ くなる
28. モブプログラミングを検討 2 8 •属⼈化解消の⼀環としてモブプログラミングの導⼊を検討 • 狙い • チームのフロー効率向上 • 知識‧スキルのメンバーへのトランスファー • レビュースピード向上
29. モブプログラミングを検討 2 9 •モブプロ講座を外部の講師に頼んで開いてもらう • 試しにチームの課題の中で1⽇数時間モブプロのやり⽅を 導⼊してみた
30. モブプロをやった効果（良い点） 3 0 •知識あるメンバーからの指摘をその場ですぐにもらうことで 学びになることはあった •その⽇やること、ゴールを共有する習慣がついた
31. モブプロをやった効果（⾟かった点） 3 1 •反⾯、メンバーによってはモブプロでつらいと感じる点は あった • オンラインで⼤⼈数で⾃分の作業を⾒られているという感 覚 • 取り組む課題に対する知識があるメンバーに質問が集中し てメンバーが対応に追われた • しばらく⽬に⾒えた成果が⾒えないため、将来的に狙い通 りの効果が出てくるのかという不安
32. モブプロをやった効果‧学び 3 2 •1⽇必ずモブプロを実施することはやめて、必要に応じてメ ンバーを募り都度実施することにした •メンバーからの声やチームでのふりかえりで早めに課題に気 づき、⽅針を変更できたことが良かった
33. ただし 3 3 •元々の悩みだった属⼈化についてはまだ解決に⾄っていない •私⾃⾝も新たな領域で対応すべき課題に対して判断に迷うこ とが増えてきた
34. リーダーとしての所作に迷い 3 4
35. リーダーの⽴場として悩み 3 5 •対象領域が増えた中で、対応すべきことの判断に迷うことが 増えた • この課題は何ができていれば良いか？ • 経験が少ない領域に対して問い合わせが来ていて、何を回 答すれば良いか？ • わかりそうなメンバーには他の対応を優先してもらいた いので、気軽に聞けないことも
36. マネージャーに 1on 1 を直訴 3 6 •マネージャーに 1on 1 を直訴。⾃分の不明確なところや対応 に⾃信ないところについて壁打ち相⼿となってもらい、相談 を繰り返した • 細かくフィードバックもらうことでマネージャーの期待と ⾃分の考えのズレを修正していった
37. 1 on 1 を繰り返した効果‧学び 3 7 •⾃信がないところを都度マネージャーとの話し合いの中で明確に してもらい、マネージャーとの認識が合った状態でチームへの⽅ 針展開など進められた •メンバーも同様に抱え込みすぎないように、こちらから 1on 1 を 提案 • メンバーのやりたいことや不明瞭なところをヒアリングして、 メンバーの意⾒を元にしたチーム開発の改善にも活かせた • リーダーである⾃分が相談のアクションを適宜取っていったこ とにより、チーム内でも「相談」に対するハードルは下がった
38. 1 on 1 を繰り返した効果‧学び 3 8 •相談に乗ってくれる⽅の時間も有限、ということを忘れずに • 課題に対する仮説‧対応案を以て相談に望むと良い
39. 想定以上に時間がかかったプロジェクト 3 9
40. プロジェクト遂⾏に関する悩み 4 0 •とある機能開発で、当初の⾒積もりよりも⼤幅に時間を使っ てしまいスケジュール遅延が発⽣ •顧客への早い提供を実現しようと、無理にスケジュールを詰 めてしまった •テストで確認すべき項⽬が想定以上に膨れ上がった • すべてを限られたスケジュール内で対応することが困難
41. スコープの調整 4 1 •該当機能の要望があった顧客とヒアリングして、スケジュー ルの調整や最低限何ができてるとよいかを決めた • 当初⾒積もった機能すべて対応せず、最低限必要な機能に スコープを絞って提供することにした
42. 他チームからヘルプ要員を⼊れた 4 2 •開発マネージャーと相談の上、他チームからヘルプを⼊れた • 該当機能の関連サービスに詳しい⽅に、⼀時的に⼿伝って もらった • 膨⼤なテストケースに対応するため開発できるメンバーを 増やして分担してもらった • 予めテスト要件が固まっており分担が可能なレベルまで 作業を落とし込んでいたため、⼀時的に⼈を増やすこと で対応できた
43. プロジェクト完了のタイミングでふりかえり 4 3 •数ヶ⽉にも及ぶ期間をその開発に要したため、タイムライン を利⽤したふりかえりを実施 • [参考] タイムラインを使って、振り返りの材料をうまく集 めよう - freee Developers Hub • 時系列でこのとき何をしていたか、何が問題だったか、何 が功を奏したかなど関係者間でふりかえった
44. プロジェクトを通して学んだこと 4 4 •プロジェクト初期の段階で達成条件や開発ボリュームが不明 瞭なまま進めていたことが要因の⼀端としてあった • 不明瞭なことが残ってる状態でスケジュールをコミットし ない • 開発チーム外のステークホルダ（プロダクトオーナーや顧 客のサポート担当など）と課題のゴールや不明瞭な点を都 度相談して合意することを意識できた
45. プロジェクトを通して学んだこと 4 5 •⼈員追加は効果的だったか？ • 仕様理解ができていないメンバーを開発にそのままアサイ ンするのは難しい • 対応内容や関連する仕様そのものが難しく、他のメン バーに説明‧理解してもらうことが⼤変 • テスト対応については各ケースが明確で説明‧分担しやす かったこともあり、⼈員追加により早く対応できた
46. まだある悩み 4 6
47. まだある悩み 4 7 •主に以下の点でまだ課題を感じている • 個⼈単位でスキルがサイロ化（属⼈化） • チーム間で対応の⽬的‧ゴールの共通認識ができていない
48. スキルのサイロ化（属⼈化） 4 8 •まだまだ個⼈単位でのスキルのサイロ化は改善はできていな いと思っている •対応できる⼈の偏りが続き、ある領域に詳しい⼈がいなくな るとその領域に関連する課題の開発ができなくなる状態が続 いている
49. 対応の⽬的‧ゴールの共通認識 •下記をチーム内で共通認識持つための仕組みがまだ整備でき ていない • 優先すべき内容を把握してリリース計画ができているか • ステークホルダと対応内容の合意が取れているか • 何が検証できていれば良いか 4 9
50. 5 0 今後の取り組み
51. スキルのサイロ化に対する取り組み 5 1 •オンボーディング資料の整備 •仕様勉強会 • 特に知識が偏りがちなドメインに対して、定期的に関係 者集めて勉強会を開く •対応履歴や相談した際の記録‧履歴を残す • その対応に携わらなかったメンバーでも内容が把握でき ること
52. 対応の⽬的‧ゴールの共通認識に対する取り組み •開発チームから、顧客と接点が多いステークホルダとのコ ミュニケーションできる機会を増やす • 課題の⽬的‧要件を双⽅で認識合わせる活動をしていく 5 2
53. 対応の⽬的‧ゴールの共通認識に対する取り組み •対応する課題に対し、チーム内でキックオフミーティングを 開き、ゴールの共通認識を作る • チームメンバーが不明瞭な点があれば、それを解消するた めのタスクも作る • 何ができてるとよいか、何が検証できていればリリース OKとみなせるか？といった要件を先に明確にする 5 3
54. まとめ 5 4
55. まとめ •チーム開発が理想に向けて回るように様々なことを取り組ん でみた • その中で効果が得られたものもあれば、逆にチームに負担 を強いることもあった •取り組んだことからふりかえり学びを得た上で、チーム開発 の理想に向けて次の取り組みを検討していく 5 5
56. チームの理想形（再掲） 5 6 •チームメンバーが課題や顧客が求めているも のを認識し、そのための対応をチーム内で協 ⼒してできること • 各メンバー個⼈が↑まで出来ることではな く、「チーム内で協⼒しあって」できるこ とが理想