いまの開発体制に満足していますか？ 〜 チームの成長に合わせた開発プラクティスの再設計 〜

Transcript

1. いまの開発体制に満足していますか？ 〜 チームの成長に合わせた開発プラクティスの再設計 〜 2025/10/04　株式会社タイミー 嵐田 高志, 髙木 薫 @arashi_d @kt__kg
2. 目次 • はじめに • チームが直面した課題 • 解決へのアプローチ • まとめ
3. 1 はじめに
4. Copyright © Timee All Rights Reserved 4 タイミーとは 

5. Copyright © Timee All Rights Reserved 5 タイミーの特徴 

6. Copyright © Timee All Rights Reserved 6 導入実績 

7. Copyright © Timee All Rights Reserved 7 導入企業の例 

8. 自己紹介
9. 自己紹介 嵐田 高志（Takashi Arashida） 機械整備や接客業を経て、 IT業界へ。客先常駐で開発業 務に従事した後、 FinTech企業やHRTech企業にてWeb サービスの開発に携わる。さまざまな開発プロジェクト経験 を経て、2023年10月タイミーに入社し、バックエンドエンジ ニアとして活動中。 インタビュー記事 https://productpr.timee.co.jp/n/n3e3e991984b0 髙木 薫（Kaoru Takagi） 株式会社ディー・エヌ・エーに新卒入社し、ライブコミュニ ケーションアプリのフロントエンド開発に携わる。新たな開 発環境で知見を広めるために転職を決意し、 2025年4月に タイミーへ入社。フロントエンド開発のみならず、バックエン ド開発など、幅広く活動中。 最近インタビュー記事が出ました https://productpr.timee.co.jp/n/n15c918a66d2d
10. Job Health Squadの紹介 • 安心・安全なプラットフォームの実現 ◦ タイミーが安心・安全なプラットフォームであり続けるために頑張るチーム • 主なリリース内容 ◦ 事業者の本人確認 ◦ 求人のチェックの強化 ◦ コンプライアンスチェックの強化
11. 開発体制 チーム全員でモブプロ @Meet, ハドル スプリント プランニング レビューやリリースが同 期的に進められる 学びを深め合える
12. 2 チームが直面した課題
13. チームの人数が増えてもアウトプットの量が変わらない • 毎月のようにメンバーが増えていった • チーム組成時は3人だった開発者が7人になった • 人が増えた割に、アウトプットの量が増えていないのでは？という声が出てきた
14. メンバー全員が主体的に学べているか分からない • 最大7人のモブプロで、誰がどういう立ち回りをするのかが不透明 • 全員が主体的に参加できているのかが分からない • 学びの場として適切なのかも分からなかった 議論に 参加しづらい... 自分は何をしたら いいんだろう...
15. 開発体制への価値観がバラバラ • 学習を重視するメンバーと、とにかくアウトプットを早く出したいメンバーの混在 • ワーキングアグリーメントがない状態だったため、暗黙の了解で動いていた • 人数が増えても惰性でモブプログラミングを続けていたため、納得感の醸成がなされていない
16. 課題 1. チームの人数が増えてもアウトプットの量が変わらない 2. メンバー全員が主体的に学べているか分からない 3. 開発体制への価値観がバラバラ
17. 3 解決へのアプローチ
18. 試したこと 1. ✅開発体制の話し合い 2. ✅モブプログラミングの分割 3. ✅プランニングと開発方針決めの分割 4. ✅開発体制をもう一度振り返る 5. ✅ソロワークの導入 6. ✅モブプログラミングの役割の明確化 7. ✅並行して進めていたプロジェクトの優先度見直し 8. ✅AIの活用 9. 🫛タイムキーパーの導入 10. 🫛目標の設定の共有 11. 🫛DSとスクラムイベントを分割 12. 🫛チケットサイズの最小化 13. 🫛振り返りの内容の見直し 14. 🫛チケットのサイズ見積もりをやってみた 15. 🫛1スプリントで終わらないものが増えてきたのでアラートをあげた時にリアクションを取る
19. チームの人数が増えてもアウトプットの量が変わらない
20. 従来の開発フロー チーム全員で モブプロ プランニング
21. サブチーム制の導入 プランニング 2チームに分かれて モブプロ
22. サブチーム制の導入 よかったこと • アウトプットの量は少し増えた • 主体性が増し、1人あたりの発言量が増え、学びが大きい状態になった のびしろ • チーム分けやバックログアイテムへのアサインに時間がかかる • サブチーム間の連携コスト、コミュニケーションが取りにくい • 他のサブチームが何をやっているのか少し追いづらい
23. 実装方針決めの導入 2チームに分かれて モブプロ プランニング エンジニア全員で 実装方針決め 属人化の 防止 手戻りを 防ぐ
24. 実装方針決めの導入 よかったこと • 「もう一方のチームが何をやっているか分からない」という状況は緩和できた のびしろ • プランニングの日のMTGの負担は増えた ◦ 方針決めが数時間にわたることも、、、
25. 従来のプロジェクトの進め方 待ち時間 待ち時間
26. 優先度を見直した結果 新規実装なので見通しが立ちやすい プロダクトとしての優先度は同じくらい 外部への依存が解消され、待ちがない 既存のロジックに手を加えるので 想定外の工数がかかる
27. 優先度を見直した結果 新規実装なので見通しが立ちやすい プロダクトとしての優先度は同じくらい 外部への依存が解消され、待ちがない 既存のロジックに手を加えるので 想定外の工数がかかる Aに集中！
28. 優先度を見直した結果 新規実装なので見通しが立ちやすい プロダクトとしての優先度は同じくらい 外部への依存が解消され、待ちがない 既存のロジックに手を加えるので 想定外の工数がかかる Aに集中！ 想定より早く リリース！
29. 並行して進めていたプロジェクトの優先度見直し よかったこと • 優先度の判断基準として不確実性の高さを考慮した ◦ 新規実装 or 既存フローに手を加える • 1つのプロジェクトに集中したことで、想定より早い段階でリリースができた • コンテキストスイッチがなくなり、開発者へのストレスが軽減した のびしろ • もっと早い段階から、1つのプロジェクトに集中できたかもしれない
30. メンバー全員が主体的に学べているか分からない
31. 従来の開発フロー チーム全員で モブプロ プランニング
32. 全員でのモブプロにおける個々の役割の明確化 Driver Mobber Navigator Driverに指示を出す 実際にコードを書く 気づいたことを 自由に発話する
33. 全員でのモブプロにおける個々の役割の明確化 Driver Mobber Mobber 公式ドキュメントには こう書いてあった ここに〇〇と書いてく ださい この関数の意味って なんですか？ 昔似たような実装を したことがある Navigator
34. 全員でのモブプロにおける個々の役割の明確化 よかったこと • Navigatorが一人なので、煮詰まったときに先導してくれる ◦ Driverが困惑することはなくなった • やることに対して経験が浅いメンバーが Navigatorをすると学びが多い のびしろ • Mobberとしての振る舞いが難しい（どこまで話すべきなのか） • 人数が多ければ多いほど、主体性が薄まる • 役割に徹するのが難しい（自由度がなくなり、活発な議論が減ったかも）
35. ソロワーク 1人で作業 プランニング 全員で 同期的にレビュー
36. ソロワーク（ 1人開発）の導入 よかったこと • 深掘りできたという声も上がった • もくもく自分のペースで作業ができる のびしろ • めっちゃいいじゃん！にはならなかった • 同期的におこなうレビューに時間がかなり取られた • レビューの時間までに作業が終わらない、同期的に集まれないメンバーもいた • 休んだり、個人のタスクをしづらい雰囲気になった
37. AIの導入 ◯◯という感じで 実装お願いします！ 〇〇の実装は どのような仕様になっ てますか？ AIとの共生
38. AIの導入 よかったこと • コードの補完がすごい • コードリーディング（調査）がものすごく早いので、工数削減に繋がった • 開発ドキュメントをNotebookLMにくわせて、対話することで仕様理解が進む • プロンプトの大切さを知る のびしろ • 自律型AIを活用するとWIPなPRが複数立ってしまい、進捗管理が難しい • 自身で考える力が弱まった気がする
39. 開発体制の価値観がバラバラ
40. 開発体制の話し合い • 1ヶ月半ほど実験をした • 毎週スプリントの振り返りは行っているが、実 験については深堀りできず • お互いの思いを吐き出す会を行った
41. 開発体制の話し合い モブプロばっかで 一人でなにもできな いのではという 不安が出てきた わりとPBIを さばけるように なってきた 我々は学習のために モブプロを やっているのでは？ みんなどんな感じの 目標設定にした？
42. 開発体制の話し合い 実験 振り返り 繰り返す
43. 開発体制の話し合い よかったこと • 各々が思っていることを知れた • 即実験、即振り返り、を繰り返す、新しい取り組みを恐れない開発体制になれた • 実験と対話を繰り返すことにより、チームの方向性が揃った
44. 楽しいチームは、強い。
45. 楽しいチームは、強い。 「楽しいチームは、強い。」という前提のもと、楽しいチームを構成する要素をまとめた 1. 挑戦：新しいことに臆せず挑戦できる風土 2. 学習：互いに学び合える環境 3. 成長：個人の向上心や成長意欲を尊重 4. 成果：チームとしての成果を重視 5. 対話：自由に意見や雑談ができる雰囲気
46. 4 まとめ
47. やったこと サブチーム制の導入 ソロワーク 全員でのモブプロにおける 個々の役割の明確化 めちゃくちゃ 振り返った
48. 現在のチームの姿 サブチーム制をベースにPBIの特性に併せて 全員でのモブプロやソロワークを取り入れている
49. 学び 開発プロセスに「銀の弾丸」はない
50. 真の安定とは停滞ではなく 「絶え間ない進化」の中にある
51. あなたのチームの「当たり前」は 今のチームに本当に合っていますか？
52. 変化を恐れず、自分たちのやり方を 再設計してみるのもいいかもしれません
53. ご清聴ありがとうございました