サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development

DevelopersIO2024 TOKYO サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと

Transcript

1. サービス開発を前に進めるために 新⽶リードエンジニアが 取り組んだこと 2024.7.20 ⼩売流通ソリューション部 太⽥拓也
2. Xへの投稿の際は、 ハッシュタグ #devio2024 でお願いいたします。 2 お願い
3. ⾃⼰紹介 • 名前：太⽥拓也 • 経歴：SIer ｰ> バックオフィス向けSaaS開発 ｰ> クラスメソッド • 役割：SaaS開発チームのテックリード ◦ 開発プロセス改善 ◦ 技術的な意思決定 • プログラミングというよりもエンジニアリングが好き 3
4. セッション対象者 • リーダーになりたての⽅ • リーダーとしての振る舞い⽅に悩みがある⽅ • リーダーを⽬指している⽅ 4
5. 本⽇お話しすること リーダーだって怖い だからこそ エンジニアリングを駆使して 前に進もう 5
6. アジェンダ • 私とテックリードの役割 • チームを学ぶ • エンジニアリングしよう • チームで学ぶ • プロダクトチームへ 6
7. 私とテックリードの役割 7
8. リーダー経験 • SIer時代 ◦ リーダーというよりは連絡係 ◦ 数名規模のチームで社員が私だけだったので • バックオフィス向けSaaS開発時代 ◦ 3名ほどのサブチームのリーダーを1年ほど ◦ 所謂リーダー業務（スケジュール管理、仕様調整 技術検証、レビュー） 8
9. ところで
10. Q. テックリードの⽅？ ✋
11. Q. テックリードが⾝近にいる⽅？✋
12. • わりと幅の広い肩書きだと思っています • 各社でテックリードの定義もかなり違うはず テックリード？ 12
13. テックリードとは 「 スタッフエンジニアとし て最も⼀般的なアーキタイ プであり、タスク（課題） の着⼿と遂⾏において1つの チームまたは複数のチーム を率いる。」 13 スタッフエンジニア　マネジメントを超えるリーダーシップ Will Larson（著）、増井 雄一郎（解説）、長谷川 圭 （訳） https://bookplus.nikkei.com/atcl/catalog/23/04/07/00760/
14. 私の役割 14 ピープル テクノロジー プロジェクト プロダクト この辺り エンジニアリングマネージャ /プロダクトマネージャのための知識体系 と読書ガイド（@hirokidaichi） https://qiita.com/hirokidaichi/items/95678bb1cef32629c317 プロジェクトマネジメントにも高めに 比重を置いている
15. • おそらくみなさんがイメージするテックリードとは少し 違うかもしれません ◦ ややプロジェクトマネージャー寄り？ ◦ 技術で勝負というわけでもない • タイトルにある通り、リードエンジニアをイメージして いただけるほうが、この後の話がしっくりくるかなと 思います テックリードという名前 15
16. チームを学ぶ 16
17. • フロントエンド、バックエンドチームの2チーム体制 • 前任のリーダー1名と⼊れ替わる形で 私とPO（PdM）が加⼊ 当時の状況 17 私 フロントエンド P O バックエンド
18. • しかし、私は⼊社したばかりで、まずは会社に慣れ ようとしているフェーズ • POは異動直後で、前のチームの引き継ぎ中 当時の状況 18 私 フロントエンド P O バックエンド
19. • とりあえず簡単そうなタスクをこなしつつ ⽐較的慣れているバックエンド領域担当チームのリー ダーと全体のリーダーを兼務することに 当時の状況 19 フロントエンド P O バックエンド 私
20. 半⽉ほど過ごした結果 いくつか違和感を覚えた
21. 違和感その1 • 各⾃が週次で進捗を報告しているが、進捗がわからない • 遅れた結果何に影響があるのか、それは何か対策が必要 なのかが伝わってこなかった 21 思ったより時間かかってます。次 週で挽回します！ （※あくまで極端な例です）
22. 違和感その1 • 各⾃が週次で進捗を報告しているが、進捗がわからない • 遅れた結果何に影響があるのか、それは何か対策が必要 なのかが伝わってこなかった ◦ チームのスケジュールを誰も管理していない 22
23. 違和感その2 • 直感的でない仕様についてメンバーに聞くと 23 あーそれはAPIがこうなってるので、 それに合わせるとこうなっちゃうんで すよ そういう仕様だと聞い たのでこう作りました
24. 違和感その2 • 直感的でない仕様についてメンバーに聞くと ◦ フィードバックが機能していない ◦ ⾔われたものをそのまま作ってしまう 24
25. 違和感の正体 25
26. 違和感の正体 • 強⼒なリーダーを失ったチームは ⽅向性を⾒失っていた • 決して⼿を抜いたりしているわけではないが 各⾃が⾊々な⽅向に進もうとしていた結果 チームの成果につながっていなかった 26
27. ⽅向性を⽰す⼈が必要 • それが⾃分に求められていることもわかっている ◦ 10⼈近くのメンバーのリーダーなんて イメージ沸かない • どこに向かって進めば良いのか全く⾒当が付かない 27
28. どうしよう
29. エンジニアリングしよう 29
30. エンジニアリングしよう • エンジニアリングは不確実性と 上⼿く付き合うためのアプローチ • サービス開発の不確実性は⼤きい ◦ 何を作る（⽬的不確実性） ◦ どうやって作る（⽅法不確実性） ◦ チームで作る（通信不確実性） 30 エンジニアリング組織論への招待 〜不確実性に向き合う思考と組織のリファクタリング 広⽊⼤地 著 https://gihyo.jp/book/2018/978-4-7741-9605-3
31. エンジニアリングしよう • 真実から⽬を背けない ◦ 要求は無限に膨張する ◦ ⾒積もりは外れる ◦ システムは何もしていないのに壊れる 31
32. エンジニアリングしよう • 真実から⽬を背けない ◦ 要求は無限に膨張する ◦ ⾒積もりは外れる ◦ システムは何もしていないのに壊れる • これから向かう⽅向が正しいかどうかは誰もわからない ◦ ⾃分にはできないという理由にはならない 32
33. 不確実であるという前提で 前に進む
34. もう少し具体的に • 経験主義で進める ◦ わからないことを確かめる ◦ その結果をもって次の計画をする ◦ これらのサイクルを効率よく回す仕組みを考えて 改善する 34
35. チームで学ぶ 35
36. まずは現状を知ろう どの程度の規模の機能を、どの程度の期間で 開発できているのかを知るために、チーム横断で ⾒積もり会を実施 36
37. 失敗 37
38. 何が良くなかったか • 技術横断で⾒積もれるメンバーがいなかった • 分業していた期間が⻑く、他⽅のチームのことが ほとんどわからなかった 38
39. しかし、学びは得た • 技術横断で⾒積もれるメンバーがいなかった • 分業していた期間が⻑く、他⽅のチームのことが ほとんどわからなかった • 当初の⽬的は果たせなかったが、上記の学びを得た 39
40. 結果 • 技術横断で⾒積もれるメンバーがいなかった • 分業していた期間が⻑く、他⽅のチームのことが ほとんどわからなかった • 当初の⽬的は果たせなかったが、上記の学びを得た • 他の⼈がやってることを知れる仕組みを作りつつ まずは私が勘と経験と度胸で⾒積もることに 40
41. 学びを活かす仕組みづくり
42. 開発のリズムを作る • スプリント制&かんばんによるタスク可視化を開始 • まずは他の⼈がやってることを知る • 振り返りをする ◦ 改善に時間を使う習慣をつける 42 Sprint Sprint Sprint
43. リファインメントの導⼊ • POがチーム専任になったこともありリファインメントを 導⼊ ◦ 荒い要望から会話を重ねて具体化していく 43
44. リファインメントの導⼊ • 定期的なコミュニケーションの機会 ◦ 「ここは実装がこうなってるからこっちの仕様のほう が良い」 ◦ 「これは顧客にとって嬉しくない仕様じゃないか」 ◦ 「ここはチーム間で連携して進めないといけない」 ◦ 「この⾒積もりで⼤丈夫？」 • POと価値観を揃える 44
45. 状況を観察する
46. 状況を観察する • チームのスケジュールを誰も管理していない ◦ Good: 勘と経験と度胸から開始した⾒積もりだが リファインメントを通じてメンバーにも徐々にやって もらえるようになってきた ◦ Bad: 精度はまだそれほど⾼くない 46
47. 状況を観察する • フィードバックが機能していない ◦ Good: 振り返りで上がった課題を他⽅のチームに共有 して解決できることも増えてきた ◦ Bad: まだ私がHubになっている状態を抜け出せていな い 47
48. 状況を観察する • ⾔われたものをそのまま作ってしまう ◦ Good: リファインメントで事前の議論ができるように なった ◦ Bad: チーム全体的に誰でも議論できるレベルにはま だ達していない 48
49. 学びを計画に反映する
50. 学びを整理する • これまでの開発で得られたドメイン知識を改めて整理した • ドメイン理解が深まるにつれて、サービス特性や変更率の⾼ いモジュールなど、アーキテクチャ要件がわかってきた 50
51. バックログ作り • 時間軸に合わせた詳細度を意識する ◦ マーケットの状況で要望は常に変わりうる ◦ 中⻑期のアイテムを詳細に検討しても無駄が多い • アウトプットではなくアウトカムを常に意識する ◦ 価値とコストとのバランスを考える ◦ ビルドトラップ、フィーチャーファクトリーを避ける 51
52. アウトカムに集中する • あったら嬉しい機能は⼤体使われない • 無いと困る機能を作る • あったら嬉しい機能の仕様が、無いと困る機能の邪魔をするこ ともある 52 この前⼊れたこの仕様と ⽭盾しますがどうしま しょう？ この機能を作りたいで す そうなの！？（こっちの価 値のほうが⾼いのに）
53. アウトカムに集中する • リリースして確かめよう • ものによっては別に実装する必要すらない ◦ 紙芝居だけで確かめられることもたくさんある 53
54. もっとチームに任せる • オーナーシップが⾼まれば、仕様策定にも積極的になり ⾃律性も向上すると考えた ◦ より粒度の荒いタスクからチームに取り組んでもらう ◦ 必要なやり取りもチーム同⼠で済ませてしまったほう がやりやすいはず 54
55. 少し寄り道
56. 施策を考えるポイント • 100%を⽬指さない ◦ パレートの法則（80:20の法則） ◦ 80 -> 100にするためのコストは それまでと⽐較して跳ね上がることが多い 56
57. 閑話休題
58. ここまでのまとめ • 経験主義に基づいたプロセスを整備した • 得られた学びを計画に反映した 58
59. しかし、あまり⼿応えが なかった 59
60. マイルストーンが達成できない • 常にジワジワと遅れていく ◦ ひたすらリスケとスコープアウト ◦ 遅れた分の時間をただ消費するだけのサイクル 60
61. 原因についての仮説 • チームが分かれていることで、コード結合がスプリント を跨ぐ ◦ バグの発⾒遅れ ◦ 作業待ちを埋めるための並列作業がさらに別の仕掛 り作業を⽣み出す 61
62. 原因についての仮説 62 フロントエンド バックエンド スプリント まだAPIできてないから モックで作ろう 結合待ちの間は別のタス クをやろう APIできたよー スプリント 思ったようなデータが ⼊ってないんだけ ど。。。 このスプリントは間に合 わないので次のスプリン トで直します 別の作業やるか。。。 あっ、こっちも結合待ちだ スプリント
63. 原因についての仮説 • リードタイムの増⼤が遅れにつながっていると考えた • しかし、チーム再編は⼤変、その前にできることは ないか？ 63
64. 終わらせることをはじめる
65. • 基本的にはスプリントレビューで成果物のデモが できることをタスクの完了条件とした ◦ 成果物は全部終わったものだけ ◦ 9割終わってますは終わってない • むやみに仕掛り作業を増やさない スプリントレビューの導⼊ 65
66. そして迎えた初めての スプリントレビュー
67. ⾮常に盛り上がった 67
68. スプリントレビュー • メンバーから⾊々な意⾒が出てくる • オーナーシップが無かったのではなく 発揮する場を失っていたのでは？ 68
69. ⾏動が⽂化を作る • 思い返すと、せっかく作った機能を披露す る場は今までなかった • 改善提案は発⽣ベースで個別に共有しても らっていたが、フィードバックできていな かった • 意⾒を出す場を設定できていなかった 69
70. プロダクトチームへ 70
71. 成果物の副産物 • 技術スライスによるチーム分割の⽋点が⽬⽴ち始めた ◦ 機能が完成しましたと⾔ってAPIだけ⾒せても仕⽅ がない ◦ 相変わらず結合は開発後期に⾏われるためバグが レビュー直前に発⾒されてしまう • チームに課題感が伝わった状態でプロセスを改善する 71
72. チーム再編
73. チーム再編 • チームで機能開発が完結できるようにチームを再 編した • ここはかなり慎重に進めた • チーム改変は破壊的な施策 中⻑期で⾒ればもちろん後戻りできるが 相⼿は⼈間、少なくとも短期的には⼤きなリスク がある（実質後戻りできない） 73
74. チーム再編で気をつけた点 • 現状のスキルセットや将来の興味の確認 • 本⼈のキャラクター 74
75. チーム再編で気をつけた点 • 担当ドメインの割当 ◦ 依存関係 ◦ 変更頻度 ◦ 複雑性 ▪ 複雑系、煩雑系、単純系に分類し 偏らないように割り当てた ◦ ここで以前にやったドメイン整理が役に⽴った 75
76. チーム再編 • なるべく⾃チームでタスクを 完結できるように再編成 76 FeatureA FeatureB 私 P O フロントエンド バックエンド
77. 結果 • 遅延が徐々に減ってきた ◦ タスクの受け渡しや調整が減った ◦ リードタイムの短縮 • 分割後も意外と⼤きな混乱は無かった ◦ ドメインを綺麗に分割できていた？ ◦ キャラクター性の考慮が功を奏した？ 77
78. 結果 • 分割後、メンバーにヒアリングした印象も概ね肯定的 ◦ タスク調整が減ってやりやすくなったという意⾒ • ⼀⽅で別チームが何をやっているのか わかりにくくなったという意⾒も ◦ 元々⾃分が担当していた領域を⼿放す不安 ◦ スプリントレビューでの情報共有や ドキュメントの整備で対処 78
79. 結果 • スキルセット的にチームで完結できないタスクが どうしても発⽣する ◦ チームを跨いだレビューやスキル移転を兼ねた 共有会などで対処 79
80. こうして、バラバラの⽅向を 向いていたチームが少しずつ 同じ⽅向を向いて進み始めた
81. まだまだ課題は⼭積み • POの負荷軽減 • ビジネスKPIへの貢献 • 運⽤経験の乏しさ • QAプロセス整備 • 不⾜しているスキルの獲得 • などなど 81
82. でも私達には エンジニアリングがある
83. まとめ • リーダーの仕事には不確実性がいっぱい • エンジニアリングは不確実性とうまく付き 合うためのアプローチ • 経験主義に則って⼀つずつ対処していこう 83