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

by Logy

Embed

Start on current slide

Slide 1

Slide 1 text

サービス開発を前に進めるために新⽶リードエンジニアが取り組んだこと 2024.7.20 ⼩売流通ソリューション部太⽥拓也

Slide 2

Slide 2 text

Xへの投稿の際は、ハッシュタグ #devio2024 でお願いいたします。 2 お願い

Slide 3

Slide 3 text

⾃⼰紹介 ● 名前：太⽥拓也 ● 経歴：SIer ｰ> バックオフィス向けSaaS開発ｰ> クラスメソッド ● 役割：SaaS開発チームのテックリード ○ 開発プロセス改善 ○ 技術的な意思決定 ● プログラミングというよりもエンジニアリングが好き 3

Slide 4

Slide 4 text

セッション対象者 ● リーダーになりたての⽅ ● リーダーとしての振る舞い⽅に悩みがある⽅ ● リーダーを⽬指している⽅ 4

Slide 5

Slide 5 text

本⽇お話しすることリーダーだって怖いだからこそエンジニアリングを駆使して前に進もう 5

Slide 6

Slide 6 text

アジェンダ ● 私とテックリードの役割 ● チームを学ぶ ● エンジニアリングしよう ● チームで学ぶ ● プロダクトチームへ 6

Slide 7

Slide 7 text

私とテックリードの役割 7

Slide 8

Slide 8 text

リーダー経験 ● SIer時代 ○ リーダーというよりは連絡係 ○ 数名規模のチームで社員が私だけだったので ● バックオフィス向けSaaS開発時代 ○ 3名ほどのサブチームのリーダーを1年ほど ○ 所謂リーダー業務（スケジュール管理、仕様調整技術検証、レビュー） 8

Slide 9

Slide 9 text

ところで

Slide 10

Slide 10 text

Q. テックリードの⽅？ ✋

Slide 11

Slide 11 text

Q. テックリードが⾝近にいる⽅？✋

Slide 12

Slide 12 text

● わりと幅の広い肩書きだと思っています ● 各社でテックリードの定義もかなり違うはずテックリード？ 12

Slide 13

Slide 13 text

テックリードとは「スタッフエンジニアとして最も⼀般的なアーキタイプであり、タスク（課題）の着⼿と遂⾏において1つのチームまたは複数のチームを率いる。」 13 スタッフエンジニア　マネジメントを超えるリーダーシップ Will Larson（著）、増井雄一郎（解説）、長谷川圭（訳） https://bookplus.nikkei.com/atcl/catalog/23/04/07/00760/

Slide 14

Slide 14 text

私の役割 14 ピープルテクノロジープロジェクトプロダクトこの辺りエンジニアリングマネージャ /プロダクトマネージャのための知識体系と読書ガイド（@hirokidaichi） https://qiita.com/hirokidaichi/items/95678bb1cef32629c317 プロジェクトマネジメントにも高めに比重を置いている

Slide 15

Slide 15 text

● おそらくみなさんがイメージするテックリードとは少し違うかもしれません ○ ややプロジェクトマネージャー寄り？ ○ 技術で勝負というわけでもない ● タイトルにある通り、リードエンジニアをイメージしていただけるほうが、この後の話がしっくりくるかなと思いますテックリードという名前 15

Slide 16

Slide 16 text

チームを学ぶ 16

Slide 17

Slide 17 text

● フロントエンド、バックエンドチームの2チーム体制 ● 前任のリーダー1名と⼊れ替わる形で私とPO（PdM）が加⼊当時の状況 17 私フロントエンド P O バックエンド

Slide 18

Slide 18 text

● しかし、私は⼊社したばかりで、まずは会社に慣れようとしているフェーズ ● POは異動直後で、前のチームの引き継ぎ中当時の状況 18 私フロントエンド P O バックエンド

Slide 19

Slide 19 text

● とりあえず簡単そうなタスクをこなしつつ⽐較的慣れているバックエンド領域担当チームのリーダーと全体のリーダーを兼務することに当時の状況 19 フロントエンド P O バックエンド私

Slide 20

Slide 20 text

半⽉ほど過ごした結果いくつか違和感を覚えた

Slide 21

Slide 21 text

違和感その1 ● 各⾃が週次で進捗を報告しているが、進捗がわからない ● 遅れた結果何に影響があるのか、それは何か対策が必要なのかが伝わってこなかった 21 思ったより時間かかってます。次週で挽回します！（※あくまで極端な例です）

Slide 22

Slide 22 text

違和感その1 ● 各⾃が週次で進捗を報告しているが、進捗がわからない ● 遅れた結果何に影響があるのか、それは何か対策が必要なのかが伝わってこなかった ○ チームのスケジュールを誰も管理していない 22

Slide 23

Slide 23 text

違和感その2 ● 直感的でない仕様についてメンバーに聞くと 23 あーそれはAPIがこうなってるので、それに合わせるとこうなっちゃうんですよそういう仕様だと聞いたのでこう作りました

Slide 24

Slide 24 text

違和感その2 ● 直感的でない仕様についてメンバーに聞くと ○ フィードバックが機能していない ○ ⾔われたものをそのまま作ってしまう 24

Slide 25

Slide 25 text

違和感の正体 25

Slide 26

Slide 26 text

違和感の正体 ● 強⼒なリーダーを失ったチームは⽅向性を⾒失っていた ● 決して⼿を抜いたりしているわけではないが各⾃が⾊々な⽅向に進もうとしていた結果チームの成果につながっていなかった 26

Slide 27

Slide 27 text

⽅向性を⽰す⼈が必要 ● それが⾃分に求められていることもわかっている ○ 10⼈近くのメンバーのリーダーなんてイメージ沸かない ● どこに向かって進めば良いのか全く⾒当が付かない 27

Slide 28

Slide 28 text

どうしよう

Slide 29

Slide 29 text

エンジニアリングしよう 29

Slide 30

Slide 30 text

エンジニアリングしよう ● エンジニアリングは不確実性と上⼿く付き合うためのアプローチ ● サービス開発の不確実性は⼤きい ○ 何を作る（⽬的不確実性） ○ どうやって作る（⽅法不確実性） ○ チームで作る（通信不確実性） 30 エンジニアリング組織論への招待〜不確実性に向き合う思考と組織のリファクタリング広⽊⼤地著 https://gihyo.jp/book/2018/978-4-7741-9605-3

Slide 31

Slide 31 text

エンジニアリングしよう ● 真実から⽬を背けない ○ 要求は無限に膨張する ○ ⾒積もりは外れる ○ システムは何もしていないのに壊れる 31

Slide 32

Slide 32 text

エンジニアリングしよう ● 真実から⽬を背けない ○ 要求は無限に膨張する ○ ⾒積もりは外れる ○ システムは何もしていないのに壊れる ● これから向かう⽅向が正しいかどうかは誰もわからない ○ ⾃分にはできないという理由にはならない 32

Slide 33

Slide 33 text

不確実であるという前提で前に進む

Slide 34

Slide 34 text

もう少し具体的に ● 経験主義で進める ○ わからないことを確かめる ○ その結果をもって次の計画をする ○ これらのサイクルを効率よく回す仕組みを考えて改善する 34

Slide 35

Slide 35 text

チームで学ぶ 35

Slide 36

Slide 36 text

まずは現状を知ろうどの程度の規模の機能を、どの程度の期間で開発できているのかを知るために、チーム横断で⾒積もり会を実施 36

Slide 37

Slide 37 text

失敗 37

Slide 38

Slide 38 text

何が良くなかったか ● 技術横断で⾒積もれるメンバーがいなかった ● 分業していた期間が⻑く、他⽅のチームのことがほとんどわからなかった 38

Slide 39

Slide 39 text

しかし、学びは得た ● 技術横断で⾒積もれるメンバーがいなかった ● 分業していた期間が⻑く、他⽅のチームのことがほとんどわからなかった ● 当初の⽬的は果たせなかったが、上記の学びを得た 39

Slide 40

Slide 40 text

結果 ● 技術横断で⾒積もれるメンバーがいなかった ● 分業していた期間が⻑く、他⽅のチームのことがほとんどわからなかった ● 当初の⽬的は果たせなかったが、上記の学びを得た ● 他の⼈がやってることを知れる仕組みを作りつつまずは私が勘と経験と度胸で⾒積もることに 40

Slide 41

Slide 41 text

学びを活かす仕組みづくり

Slide 42

Slide 42 text

開発のリズムを作る ● スプリント制&かんばんによるタスク可視化を開始 ● まずは他の⼈がやってることを知る ● 振り返りをする ○ 改善に時間を使う習慣をつける 42 Sprint Sprint Sprint

Slide 43

Slide 43 text

リファインメントの導⼊ ● POがチーム専任になったこともありリファインメントを導⼊ ○ 荒い要望から会話を重ねて具体化していく 43

Slide 44

Slide 44 text

リファインメントの導⼊ ● 定期的なコミュニケーションの機会 ○ 「ここは実装がこうなってるからこっちの仕様のほうが良い」 ○ 「これは顧客にとって嬉しくない仕様じゃないか」 ○ 「ここはチーム間で連携して進めないといけない」 ○ 「この⾒積もりで⼤丈夫？」 ● POと価値観を揃える 44

Slide 45

Slide 45 text

状況を観察する

Slide 46

Slide 46 text

状況を観察する ● チームのスケジュールを誰も管理していない ○ Good: 勘と経験と度胸から開始した⾒積もりだがリファインメントを通じてメンバーにも徐々にやってもらえるようになってきた ○ Bad: 精度はまだそれほど⾼くない 46

Slide 47

Slide 47 text

状況を観察する ● フィードバックが機能していない ○ Good: 振り返りで上がった課題を他⽅のチームに共有して解決できることも増えてきた ○ Bad: まだ私がHubになっている状態を抜け出せていない 47

Slide 48

Slide 48 text

状況を観察する ● ⾔われたものをそのまま作ってしまう ○ Good: リファインメントで事前の議論ができるようになった ○ Bad: チーム全体的に誰でも議論できるレベルにはまだ達していない 48

Slide 49

Slide 49 text

学びを計画に反映する

Slide 50

Slide 50 text

学びを整理する ● これまでの開発で得られたドメイン知識を改めて整理した ● ドメイン理解が深まるにつれて、サービス特性や変更率の⾼いモジュールなど、アーキテクチャ要件がわかってきた 50

Slide 51

Slide 51 text

バックログ作り ● 時間軸に合わせた詳細度を意識する ○ マーケットの状況で要望は常に変わりうる ○ 中⻑期のアイテムを詳細に検討しても無駄が多い ● アウトプットではなくアウトカムを常に意識する ○ 価値とコストとのバランスを考える ○ ビルドトラップ、フィーチャーファクトリーを避ける 51

Slide 52

Slide 52 text

アウトカムに集中する ● あったら嬉しい機能は⼤体使われない ● 無いと困る機能を作る ● あったら嬉しい機能の仕様が、無いと困る機能の邪魔をすることもある 52 この前⼊れたこの仕様と⽭盾しますがどうしましょう？この機能を作りたいですそうなの！？（こっちの価値のほうが⾼いのに）

Slide 53

Slide 53 text

アウトカムに集中する ● リリースして確かめよう ● ものによっては別に実装する必要すらない ○ 紙芝居だけで確かめられることもたくさんある 53

Slide 54

Slide 54 text

もっとチームに任せる ● オーナーシップが⾼まれば、仕様策定にも積極的になり⾃律性も向上すると考えた ○ より粒度の荒いタスクからチームに取り組んでもらう ○ 必要なやり取りもチーム同⼠で済ませてしまったほうがやりやすいはず 54

Slide 55

Slide 55 text

少し寄り道

Slide 56

Slide 56 text

施策を考えるポイント ● 100%を⽬指さない ○ パレートの法則（80:20の法則） ○ 80 -> 100にするためのコストはそれまでと⽐較して跳ね上がることが多い 56

Slide 57

Slide 57 text

閑話休題

Slide 58

Slide 58 text

ここまでのまとめ ● 経験主義に基づいたプロセスを整備した ● 得られた学びを計画に反映した 58

Slide 59

Slide 59 text

しかし、あまり⼿応えがなかった 59

Slide 60

Slide 60 text

マイルストーンが達成できない ● 常にジワジワと遅れていく ○ ひたすらリスケとスコープアウト ○ 遅れた分の時間をただ消費するだけのサイクル 60

Slide 61

Slide 61 text

原因についての仮説 ● チームが分かれていることで、コード結合がスプリントを跨ぐ ○ バグの発⾒遅れ ○ 作業待ちを埋めるための並列作業がさらに別の仕掛り作業を⽣み出す 61

Slide 62

Slide 62 text

原因についての仮説 62 フロントエンドバックエンドスプリントまだAPIできてないからモックで作ろう結合待ちの間は別のタスクをやろう APIできたよースプリント思ったようなデータが⼊ってないんだけど。。。このスプリントは間に合わないので次のスプリントで直します別の作業やるか。。。あっ、こっちも結合待ちだスプリント

Slide 63

Slide 63 text

原因についての仮説 ● リードタイムの増⼤が遅れにつながっていると考えた ● しかし、チーム再編は⼤変、その前にできることはないか？ 63

Slide 64

Slide 64 text

終わらせることをはじめる

Slide 65

Slide 65 text

● 基本的にはスプリントレビューで成果物のデモができることをタスクの完了条件とした ○ 成果物は全部終わったものだけ ○ 9割終わってますは終わってない ● むやみに仕掛り作業を増やさないスプリントレビューの導⼊ 65

Slide 66

Slide 66 text

そして迎えた初めてのスプリントレビュー

Slide 67

Slide 67 text

⾮常に盛り上がった 67

Slide 68

Slide 68 text

スプリントレビュー ● メンバーから⾊々な意⾒が出てくる ● オーナーシップが無かったのではなく発揮する場を失っていたのでは？ 68

Slide 69

Slide 69 text

⾏動が⽂化を作る ● 思い返すと、せっかく作った機能を披露する場は今までなかった ● 改善提案は発⽣ベースで個別に共有してもらっていたが、フィードバックできていなかった ● 意⾒を出す場を設定できていなかった 69

Slide 70

Slide 70 text

プロダクトチームへ 70

Slide 71

Slide 71 text

成果物の副産物 ● 技術スライスによるチーム分割の⽋点が⽬⽴ち始めた ○ 機能が完成しましたと⾔ってAPIだけ⾒せても仕⽅がない ○ 相変わらず結合は開発後期に⾏われるためバグがレビュー直前に発⾒されてしまう ● チームに課題感が伝わった状態でプロセスを改善する 71

Slide 72

Slide 72 text

チーム再編

Slide 73

Slide 73 text

チーム再編 ● チームで機能開発が完結できるようにチームを再編した ● ここはかなり慎重に進めた ● チーム改変は破壊的な施策中⻑期で⾒ればもちろん後戻りできるが相⼿は⼈間、少なくとも短期的には⼤きなリスクがある（実質後戻りできない） 73

Slide 74

Slide 74 text

チーム再編で気をつけた点 ● 現状のスキルセットや将来の興味の確認 ● 本⼈のキャラクター 74

Slide 75

Slide 75 text

チーム再編で気をつけた点 ● 担当ドメインの割当 ○ 依存関係 ○ 変更頻度 ○ 複雑性 ■ 複雑系、煩雑系、単純系に分類し偏らないように割り当てた ○ ここで以前にやったドメイン整理が役に⽴った 75

Slide 76

Slide 76 text

チーム再編 ● なるべく⾃チームでタスクを完結できるように再編成 76 FeatureA FeatureB 私 P O フロントエンドバックエンド

Slide 77

Slide 77 text

結果 ● 遅延が徐々に減ってきた ○ タスクの受け渡しや調整が減った ○ リードタイムの短縮 ● 分割後も意外と⼤きな混乱は無かった ○ ドメインを綺麗に分割できていた？ ○ キャラクター性の考慮が功を奏した？ 77

Slide 78

Slide 78 text

結果 ● 分割後、メンバーにヒアリングした印象も概ね肯定的 ○ タスク調整が減ってやりやすくなったという意⾒ ● ⼀⽅で別チームが何をやっているのかわかりにくくなったという意⾒も ○ 元々⾃分が担当していた領域を⼿放す不安 ○ スプリントレビューでの情報共有やドキュメントの整備で対処 78

Slide 79

Slide 79 text

結果 ● スキルセット的にチームで完結できないタスクがどうしても発⽣する ○ チームを跨いだレビューやスキル移転を兼ねた共有会などで対処 79

Slide 80

Slide 80 text

こうして、バラバラの⽅向を向いていたチームが少しずつ同じ⽅向を向いて進み始めた

Slide 81

Slide 81 text

まだまだ課題は⼭積み ● POの負荷軽減 ● ビジネスKPIへの貢献 ● 運⽤経験の乏しさ ● QAプロセス整備 ● 不⾜しているスキルの獲得 ● などなど 81

Slide 82

Slide 82 text

でも私達にはエンジニアリングがある

Slide 83

Slide 83 text

まとめ ● リーダーの仕事には不確実性がいっぱい ● エンジニアリングは不確実性とうまく付き合うためのアプローチ ● 経験主義に則って⼀つずつ対処していこう 83