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
500
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / 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
1
510
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
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
130
OCI Oracle Database Services新機能アップデート(2025/06-2025/08)
oracle4engineer
PRO
0
190
KotlinConf 2025_イベントレポート
sony
1
140
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
470
はじめてのOSS開発からみえたGo言語の強み
shibukazu
4
1k
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
290
未経験者・初心者に贈る!40分でわかるAndroidアプリ開発の今と大事なポイント
operando
6
770
20250905_MeetUp_Ito-san_s_presentation.pdf
magicpod
1
100
roppongirb_20250911
igaiga
1
260
S3アクセス制御の設計ポイント
tommy0124
3
210
slog.Handlerのよくある実装ミス
sakiengineer
4
490
測りにくい成果を測る — BtoB SaaSにおける効果検証への挑戦 / Shirokane Kougyou vol 20
sansan_randd
2
130
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
Writing Fast Ruby
sferik
628
62k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
BBQ
matthewcrist
89
9.8k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Fireside Chat
paigeccino
39
3.6k
Optimizing for Happiness
mojombo
379
70k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Why Our Code Smells
bkeepers
PRO
339
57k
What's in a price? How to price your products and services
michaelherold
246
12k
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