Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Tak...
Search
Logy
July 20, 2024
Technology
0
250
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development
DevelopersIO2024 TOKYO サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと
Logy
July 20, 2024
Tweet
Share
More Decks by Logy
See All by Logy
WebAPI Usecase for my home
nologyance
0
490
変わりゆくAPI連携仕様との付き合い方 / Good practice of using API
nologyance
1
1.1k
戦略的情報収集のすゝめ
nologyance
0
710
自己学習を支えるInoreader + Notionのその後
nologyance
0
850
自己学習を支える Inoreader + Notion
nologyance
3
16k
Nuxt.js + firebaseでハマったこと
nologyance
0
7.5k
Other Decks in Technology
See All in Technology
株式会社M2X エンジニアチーム紹介資料
m2xsoftware
0
290
【Λ(らむだ)最近のアプデ情報 / RPALT20240904
lambda
0
160
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
510
Discover Your Tailored Platform Strategy with Real-World Practice
hhiroshell
1
130
#Zenoh 完全に理解した 〜組込み純情篇〜
takasehideki
1
440
エンジニア採用ノウハウ0から継続的な採用に至るまで / Try recruiting engineers
ohageeq
0
130
New Relicで実践する外形監視
aeonpeople
1
110
Hyperledger Fabricの成長、成熟を振り返る / Looking back history of Hyperledger Fabric
gakumura
0
180
20240825_bedrock_helpdesk_jp.pdf
gamogamo
0
130
歴史と背景から改めて振り返るVPC
shotashiratori
2
210
トレタO/X アーキテクチャ移行記 Next.js App Router化への道のり / TORETA TECH UPDATE 1
okunokentaro
2
530
Oracle Database 23ai 新機能 #3 Oracle Globally Distributed Database(GDD)
oracle4engineer
PRO
1
160
Featured
See All Featured
For a Future-Friendly Web
brad_frost
173
9.3k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.2k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
165
48k
The Language of Interfaces
destraynor
153
23k
The Invisible Side of Design
smashingmag
295
50k
How to train your dragon (web standard)
notwaldorf
85
5.6k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
Testing 201, or: Great Expectations
jmmastey
35
6.9k
Mobile First: as difficult as doing things right
swwweet
220
8.8k
Optimizing for Happiness
mojombo
375
69k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
103
47k
A designer walks into a library…
pauljervisheath
201
24k
Transcript
サービス開発を前に進めるために 新⽶リードエンジニアが 取り組んだこと 2024.7.20 ⼩売流通ソリューション部 太⽥拓也
Xへの投稿の際は、 ハッシュタグ #devio2024 でお願いいたします。 2 お願い
⾃⼰紹介 • 名前:太⽥拓也 • 経歴:SIer ー> バックオフィス向けSaaS開発 ー> クラスメソッド •
役割:SaaS開発チームのテックリード ◦ 開発プロセス改善 ◦ 技術的な意思決定 • プログラミングというよりもエンジニアリングが好き 3
セッション対象者 • リーダーになりたての⽅ • リーダーとしての振る舞い⽅に悩みがある⽅ • リーダーを⽬指している⽅ 4
本⽇お話しすること リーダーだって怖い だからこそ エンジニアリングを駆使して 前に進もう 5
アジェンダ • 私とテックリードの役割 • チームを学ぶ • エンジニアリングしよう • チームで学ぶ •
プロダクトチームへ 6
私とテックリードの役割 7
リーダー経験 • SIer時代 ◦ リーダーというよりは連絡係 ◦ 数名規模のチームで社員が私だけだったので • バックオフィス向けSaaS開発時代 ◦
3名ほどのサブチームのリーダーを1年ほど ◦ 所謂リーダー業務(スケジュール管理、仕様調整 技術検証、レビュー) 8
ところで
Q. テックリードの⽅? ✋
Q. テックリードが⾝近にいる⽅?✋
• わりと幅の広い肩書きだと思っています • 各社でテックリードの定義もかなり違うはず テックリード? 12
テックリードとは 「 スタッフエンジニアとし て最も⼀般的なアーキタイ プであり、タスク(課題) の着⼿と遂⾏において1つの チームまたは複数のチーム を率いる。」 13 スタッフエンジニア マネジメントを超えるリーダーシップ
Will Larson(著)、増井 雄一郎(解説)、長谷川 圭 (訳) https://bookplus.nikkei.com/atcl/catalog/23/04/07/00760/
私の役割 14 ピープル テクノロジー プロジェクト プロダクト この辺り エンジニアリングマネージャ /プロダクトマネージャのための知識体系 と読書ガイド(@hirokidaichi)
https://qiita.com/hirokidaichi/items/95678bb1cef32629c317 プロジェクトマネジメントにも高めに 比重を置いている
• おそらくみなさんがイメージするテックリードとは少し 違うかもしれません ◦ ややプロジェクトマネージャー寄り? ◦ 技術で勝負というわけでもない • タイトルにある通り、リードエンジニアをイメージして いただけるほうが、この後の話がしっくりくるかなと
思います テックリードという名前 15
チームを学ぶ 16
• フロントエンド、バックエンドチームの2チーム体制 • 前任のリーダー1名と⼊れ替わる形で 私とPO(PdM)が加⼊ 当時の状況 17 私 フロントエンド P
O バックエンド
• しかし、私は⼊社したばかりで、まずは会社に慣れ ようとしているフェーズ • POは異動直後で、前のチームの引き継ぎ中 当時の状況 18 私 フロントエンド P
O バックエンド
• とりあえず簡単そうなタスクをこなしつつ ⽐較的慣れているバックエンド領域担当チームのリー ダーと全体のリーダーを兼務することに 当時の状況 19 フロントエンド P O バックエンド
私
半⽉ほど過ごした結果 いくつか違和感を覚えた
違和感その1 • 各⾃が週次で進捗を報告しているが、進捗がわからない • 遅れた結果何に影響があるのか、それは何か対策が必要 なのかが伝わってこなかった 21 思ったより時間かかってます。次 週で挽回します! (※あくまで極端な例です)
違和感その1 • 各⾃が週次で進捗を報告しているが、進捗がわからない • 遅れた結果何に影響があるのか、それは何か対策が必要 なのかが伝わってこなかった ◦ チームのスケジュールを誰も管理していない 22
違和感その2 • 直感的でない仕様についてメンバーに聞くと 23 あーそれはAPIがこうなってるので、 それに合わせるとこうなっちゃうんで すよ そういう仕様だと聞い たのでこう作りました
違和感その2 • 直感的でない仕様についてメンバーに聞くと ◦ フィードバックが機能していない ◦ ⾔われたものをそのまま作ってしまう 24
違和感の正体 25
違和感の正体 • 強⼒なリーダーを失ったチームは ⽅向性を⾒失っていた • 決して⼿を抜いたりしているわけではないが 各⾃が⾊々な⽅向に進もうとしていた結果 チームの成果につながっていなかった 26
⽅向性を⽰す⼈が必要 • それが⾃分に求められていることもわかっている ◦ 10⼈近くのメンバーのリーダーなんて イメージ沸かない • どこに向かって進めば良いのか全く⾒当が付かない 27
どうしよう
エンジニアリングしよう 29
エンジニアリングしよう • エンジニアリングは不確実性と 上⼿く付き合うためのアプローチ • サービス開発の不確実性は⼤きい ◦ 何を作る(⽬的不確実性) ◦ どうやって作る(⽅法不確実性)
◦ チームで作る(通信不確実性) 30 エンジニアリング組織論への招待 〜不確実性に向き合う思考と組織のリファクタリング 広⽊⼤地 著 https://gihyo.jp/book/2018/978-4-7741-9605-3
エンジニアリングしよう • 真実から⽬を背けない ◦ 要求は無限に膨張する ◦ ⾒積もりは外れる ◦ システムは何もしていないのに壊れる 31
エンジニアリングしよう • 真実から⽬を背けない ◦ 要求は無限に膨張する ◦ ⾒積もりは外れる ◦ システムは何もしていないのに壊れる •
これから向かう⽅向が正しいかどうかは誰もわからない ◦ ⾃分にはできないという理由にはならない 32
不確実であるという前提で 前に進む
もう少し具体的に • 経験主義で進める ◦ わからないことを確かめる ◦ その結果をもって次の計画をする ◦ これらのサイクルを効率よく回す仕組みを考えて 改善する
34
チームで学ぶ 35
まずは現状を知ろう どの程度の規模の機能を、どの程度の期間で 開発できているのかを知るために、チーム横断で ⾒積もり会を実施 36
失敗 37
何が良くなかったか • 技術横断で⾒積もれるメンバーがいなかった • 分業していた期間が⻑く、他⽅のチームのことが ほとんどわからなかった 38
しかし、学びは得た • 技術横断で⾒積もれるメンバーがいなかった • 分業していた期間が⻑く、他⽅のチームのことが ほとんどわからなかった • 当初の⽬的は果たせなかったが、上記の学びを得た 39
結果 • 技術横断で⾒積もれるメンバーがいなかった • 分業していた期間が⻑く、他⽅のチームのことが ほとんどわからなかった • 当初の⽬的は果たせなかったが、上記の学びを得た • 他の⼈がやってることを知れる仕組みを作りつつ
まずは私が勘と経験と度胸で⾒積もることに 40
学びを活かす仕組みづくり
開発のリズムを作る • スプリント制&かんばんによるタスク可視化を開始 • まずは他の⼈がやってることを知る • 振り返りをする ◦ 改善に時間を使う習慣をつける 42
Sprint Sprint Sprint
リファインメントの導⼊ • POがチーム専任になったこともありリファインメントを 導⼊ ◦ 荒い要望から会話を重ねて具体化していく 43
リファインメントの導⼊ • 定期的なコミュニケーションの機会 ◦ 「ここは実装がこうなってるからこっちの仕様のほう が良い」 ◦ 「これは顧客にとって嬉しくない仕様じゃないか」 ◦ 「ここはチーム間で連携して進めないといけない」
◦ 「この⾒積もりで⼤丈夫?」 • POと価値観を揃える 44
状況を観察する
状況を観察する • チームのスケジュールを誰も管理していない ◦ Good: 勘と経験と度胸から開始した⾒積もりだが リファインメントを通じてメンバーにも徐々にやって もらえるようになってきた ◦ Bad:
精度はまだそれほど⾼くない 46
状況を観察する • フィードバックが機能していない ◦ Good: 振り返りで上がった課題を他⽅のチームに共有 して解決できることも増えてきた ◦ Bad: まだ私がHubになっている状態を抜け出せていな
い 47
状況を観察する • ⾔われたものをそのまま作ってしまう ◦ Good: リファインメントで事前の議論ができるように なった ◦ Bad: チーム全体的に誰でも議論できるレベルにはま
だ達していない 48
学びを計画に反映する
学びを整理する • これまでの開発で得られたドメイン知識を改めて整理した • ドメイン理解が深まるにつれて、サービス特性や変更率の⾼ いモジュールなど、アーキテクチャ要件がわかってきた 50
バックログ作り • 時間軸に合わせた詳細度を意識する ◦ マーケットの状況で要望は常に変わりうる ◦ 中⻑期のアイテムを詳細に検討しても無駄が多い • アウトプットではなくアウトカムを常に意識する ◦
価値とコストとのバランスを考える ◦ ビルドトラップ、フィーチャーファクトリーを避ける 51
アウトカムに集中する • あったら嬉しい機能は⼤体使われない • 無いと困る機能を作る • あったら嬉しい機能の仕様が、無いと困る機能の邪魔をするこ ともある 52 この前⼊れたこの仕様と
⽭盾しますがどうしま しょう? この機能を作りたいで す そうなの!?(こっちの価 値のほうが⾼いのに)
アウトカムに集中する • リリースして確かめよう • ものによっては別に実装する必要すらない ◦ 紙芝居だけで確かめられることもたくさんある 53
もっとチームに任せる • オーナーシップが⾼まれば、仕様策定にも積極的になり ⾃律性も向上すると考えた ◦ より粒度の荒いタスクからチームに取り組んでもらう ◦ 必要なやり取りもチーム同⼠で済ませてしまったほう がやりやすいはず 54
少し寄り道
施策を考えるポイント • 100%を⽬指さない ◦ パレートの法則(80:20の法則) ◦ 80 -> 100にするためのコストは それまでと⽐較して跳ね上がることが多い
56
閑話休題
ここまでのまとめ • 経験主義に基づいたプロセスを整備した • 得られた学びを計画に反映した 58
しかし、あまり⼿応えが なかった 59
マイルストーンが達成できない • 常にジワジワと遅れていく ◦ ひたすらリスケとスコープアウト ◦ 遅れた分の時間をただ消費するだけのサイクル 60
原因についての仮説 • チームが分かれていることで、コード結合がスプリント を跨ぐ ◦ バグの発⾒遅れ ◦ 作業待ちを埋めるための並列作業がさらに別の仕掛 り作業を⽣み出す 61
原因についての仮説 62 フロントエンド バックエンド スプリント まだAPIできてないから モックで作ろう 結合待ちの間は別のタス クをやろう APIできたよー
スプリント 思ったようなデータが ⼊ってないんだけ ど。。。 このスプリントは間に合 わないので次のスプリン トで直します 別の作業やるか。。。 あっ、こっちも結合待ちだ スプリント
原因についての仮説 • リードタイムの増⼤が遅れにつながっていると考えた • しかし、チーム再編は⼤変、その前にできることは ないか? 63
終わらせることをはじめる
• 基本的にはスプリントレビューで成果物のデモが できることをタスクの完了条件とした ◦ 成果物は全部終わったものだけ ◦ 9割終わってますは終わってない • むやみに仕掛り作業を増やさない スプリントレビューの導⼊
65
そして迎えた初めての スプリントレビュー
⾮常に盛り上がった 67
スプリントレビュー • メンバーから⾊々な意⾒が出てくる • オーナーシップが無かったのではなく 発揮する場を失っていたのでは? 68
⾏動が⽂化を作る • 思い返すと、せっかく作った機能を披露す る場は今までなかった • 改善提案は発⽣ベースで個別に共有しても らっていたが、フィードバックできていな かった • 意⾒を出す場を設定できていなかった
69
プロダクトチームへ 70
成果物の副産物 • 技術スライスによるチーム分割の⽋点が⽬⽴ち始めた ◦ 機能が完成しましたと⾔ってAPIだけ⾒せても仕⽅ がない ◦ 相変わらず結合は開発後期に⾏われるためバグが レビュー直前に発⾒されてしまう •
チームに課題感が伝わった状態でプロセスを改善する 71
チーム再編
チーム再編 • チームで機能開発が完結できるようにチームを再 編した • ここはかなり慎重に進めた • チーム改変は破壊的な施策 中⻑期で⾒ればもちろん後戻りできるが 相⼿は⼈間、少なくとも短期的には⼤きなリスク
がある(実質後戻りできない) 73
チーム再編で気をつけた点 • 現状のスキルセットや将来の興味の確認 • 本⼈のキャラクター 74
チーム再編で気をつけた点 • 担当ドメインの割当 ◦ 依存関係 ◦ 変更頻度 ◦ 複雑性 ▪
複雑系、煩雑系、単純系に分類し 偏らないように割り当てた ◦ ここで以前にやったドメイン整理が役に⽴った 75
チーム再編 • なるべく⾃チームでタスクを 完結できるように再編成 76 FeatureA FeatureB 私 P O
フロントエンド バックエンド
結果 • 遅延が徐々に減ってきた ◦ タスクの受け渡しや調整が減った ◦ リードタイムの短縮 • 分割後も意外と⼤きな混乱は無かった ◦
ドメインを綺麗に分割できていた? ◦ キャラクター性の考慮が功を奏した? 77
結果 • 分割後、メンバーにヒアリングした印象も概ね肯定的 ◦ タスク調整が減ってやりやすくなったという意⾒ • ⼀⽅で別チームが何をやっているのか わかりにくくなったという意⾒も ◦ 元々⾃分が担当していた領域を⼿放す不安
◦ スプリントレビューでの情報共有や ドキュメントの整備で対処 78
結果 • スキルセット的にチームで完結できないタスクが どうしても発⽣する ◦ チームを跨いだレビューやスキル移転を兼ねた 共有会などで対処 79
こうして、バラバラの⽅向を 向いていたチームが少しずつ 同じ⽅向を向いて進み始めた
まだまだ課題は⼭積み • POの負荷軽減 • ビジネスKPIへの貢献 • 運⽤経験の乏しさ • QAプロセス整備 •
不⾜しているスキルの獲得 • などなど 81
でも私達には エンジニアリングがある
まとめ • リーダーの仕事には不確実性がいっぱい • エンジニアリングは不確実性とうまく付き 合うためのアプローチ • 経験主義に則って⼀つずつ対処していこう 83
None
85