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

by Keiichi Nomura

Slide 1

Slide 1 text

開発チームリーダーとしてやってきたことのふりかえり 2 0 2 3 / 0 8 産業⽀援グループ⼩売流通ソリューション部野村啓⼀

Slide 2

Slide 2 text

⾃⼰紹介 2 産業⽀援グループ⼩売流通ソリューション部 prismatix 注⽂/決済サービス担当野村啓⼀

Slide 3

Slide 3 text

prismatix とは 3 • EC / CRM特化型プラットフォーム • クラスメソッドのB 2 B⾃社サービス • エンゲージメントコマース • 伴⾛型コンサルティング https://prismatix.jp/

Slide 4

Slide 4 text

今回お話すること 4 私が開発チームリーダーを数年続けたなかでの学びをふりかえります皆さんのチーム開発において進め⽅の参考にできれば幸いです

Slide 5

Slide 5 text

アジェンダ 5 •開発チームリーダーとして主にやってきたこと •私が考えるチームの理想形 •チーム開発で直⾯した課題‧取り組みとそこから得た学び • 課題に対してどのようなことを取り組んできたか • 取り組んだことから得た効果、学び •次に取り組むこと

Slide 6

Slide 6 text

6 開発チームリーダーになって主にやってきたこと

Slide 7

Slide 7 text

チームリーダーになるまで 7 •2017年10⽉クラスメソッドJOIN • prismatix 決済サービスの開発を担当 • 最初はテックリードと⼀緒に２⼈３脚で開発 • テックリードが離れ、他チームから決済サービスを担当する仲間が増えてチーム化 •2019年7⽉〜 • 決済サービスのチームリーダーを担当決済領域を担当

Slide 8

Slide 8 text

チームリーダーになるまで 8 •2021年7⽉〜 • 注⽂領域のサービスを担うチームと統合し、注⽂決済チームとして引き続きリーダーを担当注⽂領域も担当することに

Slide 9

Slide 9 text

主な役割 9 •注⽂決済領域の課題から、優先すべき開発タスクを計画‧ リード •顧客環境で発⽣した障害の司令塔、問い合わせやアラートの窓⼝ •各タスクをメンバーに委譲 •新規メンバーのオンボーディング、フォローアップなど

Slide 10

Slide 10 text

1 0 私が考えるチームの理想形

Slide 11

Slide 11 text

チームの理想形 1 1 •チームメンバーが課題や顧客が求めているものを認識し、そのための対応をチーム内で協⼒してできること • 各メンバー個⼈が↑まで出来ることではなく、「チーム内で協⼒しあって」できることが理想

Slide 12

Slide 12 text

1 2 これまでの開発で直⾯した課題‧取り組みとそこから得た学び

Slide 13

Slide 13 text

直⾯した課題 1 3 •新しいチームメンバーへのケア •担当領域の説明が頻発して時間を取られる •個⼈スキルのサイロ化 •リーダーとしての所作に迷い •想定以上に時間がかかるプロジェクト etc …

Slide 14

Slide 14 text

取り組みとそこから得た学び 1 4 各課題に対してチームで取り組んだこと、   そこから得た効果‧学びを紹介していきます。学びになったこともあれば、効果が⾒込めなかったことも

Slide 15

Slide 15 text

新しいチームメンバーへのケア 1 5

Slide 16

Slide 16 text

新しいチームメンバーに対する悩み 1 6 •リーダーを担って以降、新しいチームメンバーが続々と⼊るようになった • チームメンバーに対するフォロー経験が当初は少なく、⼊ったばかりのメンバーが何をしてよいかわからない状態が続いてしまった • 逆に私がチームメンバーに対して、何をすれば⽴ち上がりをフォローできるか、当初は明確にできていなかった

Slide 17

Slide 17 text

•それまではちゃんと実施していなかったが、チームメンバーと毎⽇話す機会として朝会‧⼣会（デイリーミーティング）を実施することにした • 朝会ではメンバーがその⽇やることを確認、困っていることがあればフォローする • ⼣会ではその⽇予定してたことの状況、新しい困りごとを確認して明⽇以降の対応について決める取り組み①デイリーミーティングを実施 1 7

Slide 18

Slide 18 text

取り組み②スプリントごとにふりかえりを実施 1 8 •スプリントごとに以下をふりかえり、次のスプリントで実施するアクションを決める • 対応してよかったこと • 課題と感じていること • 次のスプリントでやること

Slide 19

Slide 19 text

取り組み③オンボーディング資料の整備 1 9 •オンボーディングとしてやるべきことを資料化 • 初めてチームに⼊ったメンバーが最初にやること、準備することをまとめた • 新しいメンバーが⼊ったときはその資料をもとに説明することに

Slide 20

Slide 20 text

チームメンバーのケアで取り組んだことの効果 2 0 •メンバーと⽇々コミュニケーションを取る機会を作ることで、特に新しいメンバーが何に困ってるかを早めに把握できた •ふりかえりをすることによって、メンバーが課題と感じることや学びと思えることが可視化できた •オンボーディングの資料を整えたことで、私だけでなく他のメンバーも新規メンバーの受け⼊れができた

Slide 21

Slide 21 text

担当領域の説明が頻発して時間を取られる 2 1

Slide 22

Slide 22 text

悩み 2 2 •チームメンバーへのケアをしていく中で、メンバーが決済サービスそのものの仕様の理解に苦しんでいる •顧客や社内の他チームからも仕様の問い合わせが尽きない • ⾃分やチームが本来開発にあてる時間も割いてしまっている

Slide 23

Slide 23 text

担当領域の説明資料を作った 2 3 •会社ブログやイベントで決済のシステムについて説明

Slide 24

Slide 24 text

説明資料を作った事による効果 2 4 •担当領域の仕様をより⼀般向けに説明できる形にしたことで、チーム内外に説明しやすくなった •この資料はそのまま、新しく⼊ってきたメンバーへのオンボーディングとして利⽤できた

Slide 25

Slide 25 text

まだ残っている課題 2 5 •元々の悩みだった問い合わせが減ったかというと、そうでもない •個⼈のスキルに依存していることがまだ残っている • 利⽤する外部サービスごとの詳細仕様 • 外部サービスを追加する上での決めごとなど

Slide 26

Slide 26 text

個⼈単位でスキルがサイロ化（属⼈化） 2 6

Slide 27

Slide 27 text

属⼈化している悩み 2 7 •2021年にチーム編成が変わり、決済だけでなく注⽂領域のサービスも担当することになった • 元々いたチームの担当サービス以外の仕様理解が難しい • 顧客から問い合わせやアラートを受けても対応できるメンバーが限られる • 問い合わせが集中するとそのメンバーの負荷が⼀気に⾼くなる

Slide 28

Slide 28 text

モブプログラミングを検討 2 8 •属⼈化解消の⼀環としてモブプログラミングの導⼊を検討 • 狙い • チームのフロー効率向上 • 知識‧スキルのメンバーへのトランスファー • レビュースピード向上

Slide 29

Slide 29 text

モブプログラミングを検討 2 9 •モブプロ講座を外部の講師に頼んで開いてもらう • 試しにチームの課題の中で1⽇数時間モブプロのやり⽅を導⼊してみた

Slide 30

Slide 30 text

モブプロをやった効果（良い点） 3 0 •知識あるメンバーからの指摘をその場ですぐにもらうことで学びになることはあった •その⽇やること、ゴールを共有する習慣がついた

Slide 31

Slide 31 text

モブプロをやった効果（⾟かった点） 3 1 •反⾯、メンバーによってはモブプロでつらいと感じる点はあった • オンラインで⼤⼈数で⾃分の作業を⾒られているという感覚 • 取り組む課題に対する知識があるメンバーに質問が集中してメンバーが対応に追われた • しばらく⽬に⾒えた成果が⾒えないため、将来的に狙い通りの効果が出てくるのかという不安

Slide 32

Slide 32 text

モブプロをやった効果‧学び 3 2 •1⽇必ずモブプロを実施することはやめて、必要に応じてメンバーを募り都度実施することにした •メンバーからの声やチームでのふりかえりで早めに課題に気づき、⽅針を変更できたことが良かった

Slide 33

Slide 33 text

ただし 3 3 •元々の悩みだった属⼈化についてはまだ解決に⾄っていない •私⾃⾝も新たな領域で対応すべき課題に対して判断に迷うことが増えてきた

Slide 34

Slide 34 text

リーダーとしての所作に迷い 3 4

Slide 35

Slide 35 text

リーダーの⽴場として悩み 3 5 •対象領域が増えた中で、対応すべきことの判断に迷うことが増えた • この課題は何ができていれば良いか？ • 経験が少ない領域に対して問い合わせが来ていて、何を回答すれば良いか？ • わかりそうなメンバーには他の対応を優先してもらいたいので、気軽に聞けないことも

Slide 36

Slide 36 text

マネージャーに 1on 1 を直訴 3 6 •マネージャーに 1on 1 を直訴。⾃分の不明確なところや対応に⾃信ないところについて壁打ち相⼿となってもらい、相談を繰り返した • 細かくフィードバックもらうことでマネージャーの期待と⾃分の考えのズレを修正していった

Slide 37

Slide 37 text

1 on 1 を繰り返した効果‧学び 3 7 •⾃信がないところを都度マネージャーとの話し合いの中で明確にしてもらい、マネージャーとの認識が合った状態でチームへの⽅針展開など進められた •メンバーも同様に抱え込みすぎないように、こちらから 1on 1 を提案 • メンバーのやりたいことや不明瞭なところをヒアリングして、メンバーの意⾒を元にしたチーム開発の改善にも活かせた • リーダーである⾃分が相談のアクションを適宜取っていったことにより、チーム内でも「相談」に対するハードルは下がった

Slide 38

Slide 38 text

1 on 1 を繰り返した効果‧学び 3 8 •相談に乗ってくれる⽅の時間も有限、ということを忘れずに • 課題に対する仮説‧対応案を以て相談に望むと良い

Slide 39

Slide 39 text

想定以上に時間がかかったプロジェクト 3 9

Slide 40

Slide 40 text

プロジェクト遂⾏に関する悩み 4 0 •とある機能開発で、当初の⾒積もりよりも⼤幅に時間を使ってしまいスケジュール遅延が発⽣ •顧客への早い提供を実現しようと、無理にスケジュールを詰めてしまった •テストで確認すべき項⽬が想定以上に膨れ上がった • すべてを限られたスケジュール内で対応することが困難

Slide 41

Slide 41 text

スコープの調整 4 1 •該当機能の要望があった顧客とヒアリングして、スケジュールの調整や最低限何ができてるとよいかを決めた • 当初⾒積もった機能すべて対応せず、最低限必要な機能にスコープを絞って提供することにした

Slide 42

Slide 42 text

他チームからヘルプ要員を⼊れた 4 2 •開発マネージャーと相談の上、他チームからヘルプを⼊れた • 該当機能の関連サービスに詳しい⽅に、⼀時的に⼿伝ってもらった • 膨⼤なテストケースに対応するため開発できるメンバーを増やして分担してもらった • 予めテスト要件が固まっており分担が可能なレベルまで作業を落とし込んでいたため、⼀時的に⼈を増やすことで対応できた

Slide 43

Slide 43 text

プロジェクト完了のタイミングでふりかえり 4 3 •数ヶ⽉にも及ぶ期間をその開発に要したため、タイムラインを利⽤したふりかえりを実施 • [参考] タイムラインを使って、振り返りの材料をうまく集めよう - freee Developers Hub • 時系列でこのとき何をしていたか、何が問題だったか、何が功を奏したかなど関係者間でふりかえった

Slide 44

Slide 44 text

プロジェクトを通して学んだこと 4 4 •プロジェクト初期の段階で達成条件や開発ボリュームが不明瞭なまま進めていたことが要因の⼀端としてあった • 不明瞭なことが残ってる状態でスケジュールをコミットしない • 開発チーム外のステークホルダ（プロダクトオーナーや顧客のサポート担当など）と課題のゴールや不明瞭な点を都度相談して合意することを意識できた

Slide 45

Slide 45 text

プロジェクトを通して学んだこと 4 5 •⼈員追加は効果的だったか？ • 仕様理解ができていないメンバーを開発にそのままアサインするのは難しい • 対応内容や関連する仕様そのものが難しく、他のメンバーに説明‧理解してもらうことが⼤変 • テスト対応については各ケースが明確で説明‧分担しやすかったこともあり、⼈員追加により早く対応できた

Slide 46

Slide 46 text

まだある悩み 4 6

Slide 47

Slide 47 text

まだある悩み 4 7 •主に以下の点でまだ課題を感じている • 個⼈単位でスキルがサイロ化（属⼈化） • チーム間で対応の⽬的‧ゴールの共通認識ができていない

Slide 48

Slide 48 text

スキルのサイロ化（属⼈化） 4 8 •まだまだ個⼈単位でのスキルのサイロ化は改善はできていないと思っている •対応できる⼈の偏りが続き、ある領域に詳しい⼈がいなくなるとその領域に関連する課題の開発ができなくなる状態が続いている

Slide 49

Slide 49 text

対応の⽬的‧ゴールの共通認識 •下記をチーム内で共通認識持つための仕組みがまだ整備できていない • 優先すべき内容を把握してリリース計画ができているか • ステークホルダと対応内容の合意が取れているか • 何が検証できていれば良いか 4 9

Slide 50

Slide 50 text

5 0 今後の取り組み

Slide 51

Slide 51 text

スキルのサイロ化に対する取り組み 5 1 •オンボーディング資料の整備 •仕様勉強会 • 特に知識が偏りがちなドメインに対して、定期的に関係者集めて勉強会を開く •対応履歴や相談した際の記録‧履歴を残す • その対応に携わらなかったメンバーでも内容が把握できること

Slide 52

Slide 52 text

対応の⽬的‧ゴールの共通認識に対する取り組み •開発チームから、顧客と接点が多いステークホルダとのコミュニケーションできる機会を増やす • 課題の⽬的‧要件を双⽅で認識合わせる活動をしていく 5 2

Slide 53

Slide 53 text

対応の⽬的‧ゴールの共通認識に対する取り組み •対応する課題に対し、チーム内でキックオフミーティングを開き、ゴールの共通認識を作る • チームメンバーが不明瞭な点があれば、それを解消するためのタスクも作る • 何ができてるとよいか、何が検証できていればリリース OKとみなせるか？といった要件を先に明確にする 5 3

Slide 54

Slide 54 text

まとめ 5 4

Slide 55

Slide 55 text

まとめ •チーム開発が理想に向けて回るように様々なことを取り組んでみた • その中で効果が得られたものもあれば、逆にチームに負担を強いることもあった •取り組んだことからふりかえり学びを得た上で、チーム開発の理想に向けて次の取り組みを検討していく 5 5

Slide 56

Slide 56 text

チームの理想形（再掲） 5 6 •チームメンバーが課題や顧客が求めているものを認識し、そのための対応をチーム内で協⼒してできること • 各メンバー個⼈が↑まで出来ることではなく、「チーム内で協⼒しあって」できることが理想

Slide 57

Slide 57 text

No content