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
490
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / 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
DevIO2025_継続的なサービス開発のための技術的意思決定のポイント / how-to-tech-decision-makaing-devio2025
nologyance
0
180
WebAPI Usecase for my home
nologyance
0
600
変わりゆくAPI連携仕様との付き合い方 / Good practice of using API
nologyance
1
1.3k
戦略的情報収集のすゝめ
nologyance
0
780
自己学習を支えるInoreader + Notionのその後
nologyance
0
990
自己学習を支える Inoreader + Notion
nologyance
3
17k
Nuxt.js + firebaseでハマったこと
nologyance
0
7.9k
Other Decks in Technology
See All in Technology
ChatGPTとPlantUML/Mermaidによるソフトウェア設計
gowhich501
1
120
進捗
ydah
2
230
Grafana MCPサーバーによるAIエージェント経由でのGrafanaダッシュボード動的生成
hamadakoji
1
1.3k
AI開発ツールCreateがAnythingになったよ
tendasato
0
110
「魔法少女まどか☆マギカ Magia Exedra」のグローバル展開を支える、開発チームと翻訳チームの「意識しない協創」を実現するローカライズシステム
gree_tech
PRO
0
540
AIのグローバルトレンド2025 #scrummikawa / global ai trend
kyonmm
PRO
1
230
Kubernetes における cgroup v2 でのOut-Of-Memory 問題の解決
pfn
PRO
0
460
おやつは300円まで!の最適化を模索してみた
techtekt
PRO
0
270
Function Body Macros で、SwiftUI の View に Accessibility Identifier を自動付与する/Function Body Macros: Autogenerate accessibility identifiers for SwiftUI Views
miichan
2
170
なぜテストマネージャの視点が 必要なのか? 〜 一歩先へ進むために 〜
moritamasami
0
110
AI エージェントとはそもそも何か? - 技術背景から Amazon Bedrock AgentCore での実装まで- / AI Agent Unicorn Day 2025
hariby
4
1.1k
機械学習を扱うプラットフォーム開発と運用事例
lycorptech_jp
PRO
0
160
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
Faster Mobile Websites
deanohume
309
31k
Agile that works and the tools we love
rasmusluckow
330
21k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
51
5.6k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
186
54k
The Art of Programming - Codeland 2020
erikaheidi
55
13k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Writing Fast Ruby
sferik
628
62k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
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