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
強くてニューゲームなプロダクト開発 / Product development in new ...
Search
Yoshiki Iida
January 05, 2022
Technology
12
17k
強くてニューゲームなプロダクト開発 / Product development in new game plus
Yoshiki Iida
January 05, 2022
Tweet
Share
More Decks by Yoshiki Iida
See All by Yoshiki Iida
エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢 / RSGT2025
yoshikiiida
5
3.9k
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
810
質とスピードを両立するログラスのホールチームQA / 20240827 QASaaS_findy
yoshikiiida
2
170
エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management
yoshikiiida
11
3.4k
スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 / Maturity and barriers in Scrum
yoshikiiida
4
1.9k
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
17
6.1k
ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process
yoshikiiida
7
3.1k
QA経験のないエンジニアリング マネージャーがQAのカジュアル面談に出て 苦労していること・気づいたこと / scrum fest niigata 2024
yoshikiiida
2
4.2k
ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー / A system and culture that contributes to business through code quality in Loglass
yoshikiiida
12
2.3k
Other Decks in Technology
See All in Technology
財務データを題材に、 ETLとは何であるかを考える
shoe116
3
980
Git scrapingで始める継続的なデータ追跡 / Git Scraping
ohbarye
5
580
AWS re:Invent 2024 recap in 20min / JAWSUG 千葉 2025.1.14
shimy
1
110
自社 200 記事を元に整理した読みやすいテックブログを書くための Tips 集
masakihirose
2
370
Site Reliability Engineering on Kubernetes
nwiizo
0
140
dbtを中心にして組織のアジリティとガバナンスのトレードオンを考えてみた
gappy50
0
350
Godot Engineについて調べてみた
unsoluble_sugar
0
460
[IBM TechXchange Dojo]Watson Discoveryとwatsonx.aiでRAGを実現!事例のご紹介+座学②
siyuanzh09
0
120
iPadOS18でフローティングタブバーを解除してみた
sansantech
PRO
1
160
0→1事業こそPMは営業すべし / pmconf #落選お披露目 / PM should do sales in zero to one
roki_n_
PRO
1
2.2k
三菱電機で社内コミュニティを立ち上げた話(MAWS-UG)
kurebayashi
1
370
2025年のARグラスの潮流
kotauchisunsun
0
870
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.2k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
98
18k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Code Review Best Practice
trishagee
65
17k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.1k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Transcript
2022/01/05 #RSGT2022 Yoshiki Iida 強くてニューゲームなプロダクト開発 〜制約ゼロから長期で進化し続けられるシステムを作るチャレンジ〜
Yoshiki Iida (@ysk_118) エンジニアに始まり、スクラムマスター、プロダクトオーナー、マネージャー、執行 役員を経験し、現場のチームビルディングから部署を超えた会社全体の改善な ど、アジャイルな組織づくりの推進を行ってきました。現在は株式会社ログラスに てソフトウェアエンジニアとしてプロダクト開発に携わっています。最近またエンジ ニアリングマネージャーもはじめました。 書籍「Scrum Boot
Camp The Book 増補改訂版」コラムニスト。 一般社団法人アジャイルチームを支える会 理事。 Profile
ログラスについて は事業進捗を正確かつ迅速に可視化することで、 柔軟で高精度な経営推進を実現する経営管理クラウドサービスです。
ログラスについて
ログラスについて
2周目の開発で 繰り返したくないことBest3
• DBのデータ構造の負債 • 責務や依存度の増大したクラス • 密結合なクライアント、サブシステム 繰り返したくないことBest3
• DBのデータ構造の負債 → 時間が経過しても実態との乖離がない • 責務や依存度の増大したクラス → 小さな責務に分解され、変更の影響範囲が閉じている • 密結合なクライアント、サブシステム
→ 技術スタックの変遷に追従してリプレイスできる 繰り返したくないことBest3 の理想
• DBのデータ構造の負債 → 実態と乖離していて認知負荷が高い🔥 • 責務や依存度の増大したクラス → 責務や依存が大きく容易に変更できない🔥 • 密結合なクライアント、サブシステム
→ リプレイス不可能で技術スタックのアップデートができない🔥 繰り返したくないことBest3 の現実
「くそ!何度タイムリープしても負債に 勝てない・・!」
「くそ!何度タイムリープしても負債に 勝てない・・!」 とならないために
ウォード・カニンガムによる(元祖)負債について “Ward の言う負債の悪影響とは、開発と共に得られていく知識や理解と目の前のシステムとの 乖離が引き起こす生産性低下のことであり、自分たちが書いているコードの保守性(あるいは、 雑さ)のことではありません。” t-wadaのブログ「【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明」 https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor
負債を正しく認知する
マーティン・ファウラー による技術的負債の四象限について “だが私は、 設計の不備が負債かそうじゃないかなんて考えることが、そもそも間違ってると思 う。 技術的負債というのはメタファなのだから、 ここで問うべきなのは「負債のメタファは、 設計 上の問題を考える助けになるだろうか? そして、他人と意見交換しやすくなるだろうか?」だ。
” Martin Fowler's Bliki (ja)「技術的負債の四象限」 https://bliki-ja.github.io/TechnicalDebtQuadrant/ 負債を正しく認知する
マーティン・ファウラー による技術的負債の四象限について Martin Fowler's Bliki (ja)「技術的負債の四象限」 https://bliki-ja.github.io/TechnicalDebtQuadrant/ 負債を正しく認知する 無鉄砲な 慎重な
意図的な 不注意な 「設計する時間がない んだからしょうがない」 「今すぐリリースしない といけない。あとでどう にかしよう」 「レイヤー化?なにそ れ?」 「もっとこうすべきだった なあ」
• どんなコードも作られた瞬間は負債ではない ◦ 作られた瞬間は解決しているビジネス要求がわかっていて、どん な意図で実装したかわかっているから • 時間が経過して当初のビジネス要求や設計意図を忘れてしまう、もし くは人が入れ替わり失われることでメンテナンスできなくなったときから 負債となる(上に挙げたカニンガム、ファウラーの例では知見が失われること までカバーしていない)
メンテナンスできない = ビジネスの要求に応えられない 私の負債の解釈
• 一度メンテナンスできなくなったものをメンテナンス可能 に戻すのは非常に難しい • 理由 ◦ そのコードに触れるコストが高い(認知負荷) ◦ そのコードに触れるモチベーションを保つのが難しい(心理的負荷) ◦
そのコードに触れるコストは直接的にビジネスの成果 に結びつかない(金銭的負荷) メンテナンスできないものの課題は解決しにくい
そこで
LTV Firstな開発
• システムが長生きできるかどうかが事業の生死を分ける • ビジネスや事業を考える人がまずこの重要性を理解する 必要がある • ログラスでは「LTV First」をバリューとして定めている ◦ 長く走り続けられる意思決定を重要視する
システムのLTVを最大化する
• 基礎技術 ◦ テストは資産、リファクタリングは文化 ◦ モデリング駆動の開発とそれを反映しやすいアーキテクチャ どうやっているか • LTV Firstな仕組み
◦ 負債ではなく税金でマネジメント ▪ 技術的投資と非機能OKR ◦ 非連続な進化を生むためのプロポーザル ◦ ライブラリバージョンアップ会
LTV Firstな仕組み
• 「システムが存在する以上その維持費がかかります」ということを 大前提としている • あとから負債を返すのではなく税金として固定の枠(Story Point)を確保して いる 負債ではなく税金でマネジメント エピックごとに予算を設定している。 新しい機能開発とは別に
非機能系エピック、CSからあ がってくる細かなUX改善、技術的投資(負債返済以外 に投資も扱う)が固定で確保されている。
• 細かい技術的投資で拾いきれ ない大きなテーマを扱う • OKR※策定のタイミングで 個々がプロポーザルを提案し 重要度の高いものを投票で決 める • 非機能OKRの中で取り扱う
進化し続けるためのプロポーザル ※OKR: Objectives and Key Results、目標管 理の1手法
• 週に30分Dependabot※のPRを消化 する時間を確保している • ライブラリを古いままにしておくといざ必 要になったときにすぐにあげられない ◦ 迅速な脆弱性対応をするために必 要 ライブラリバージョンアップ会
※Dependabot: GitHubが提供するパッケージ 依存管理のサポートツール。バージョンアップ 候補をPRにしてくれる。
基礎技術
単にテストを書くというだけでなく、リファクタリングのためのテストという側面も強く意識 している。テストとリファクタリングが当たり前になるような啓蒙(emojiを大量に作るな ど)を初期からやっている。 テストは資産、リファクタリングは文化
新しい機能開発をするときに必ずお客様のヒアリングを行い、実際の業務をベースにし てモデリングを行う。また、業務がドメインモデルとして表現できているか?を複数人で ディスカッションして実装に入る。 ドメインモデルを中心に各レイヤーの責務を守りやすいアーキテクチャ。 モデリング駆動の開発とアーキテクチャ
どうやっているかのまとめ
• SRP(単一責任原則)違反指数※ ◦ SRP=R+U+((L/100)-5) ▪ R:修正リビジョンのユニーク数 ▪ U:修正ユーザのユニーク数 ▪ L:モジュールのライン数
◦ 人数増加、コード量増加に対して SRP違 反指数の増加を抑え込めている (平均だけでなく分散もみることで Fatな コードのばらつきをみている) • 2021年ハイライト ◦ テストコード量がプロダクトコード量を上 回る ◦ 追加だけでなく削除も並行している コードの状態の可視化 ※SRP違反指数について https://gihyo.jp/dev/serial/01/perl-hackers-hub/000803
• システムパフォーマンスと組織パフォーマンスの可視化 • メトリクスに基づいたエピック優先順位の意思決定の自動化 • 1プロダクトで解決すべき問題領域の可視化 ◦ コード量もチームも無限にはスケールしない 次にやりたいこと
強くてニューゲームをやるために、 • 負債をためないシステムは組織設計レベルで初期から取り組む 必要がある • 負債の観点ごとに正しく拾える仕組みを用意する ◦ スクラムの中で拾われるように外側の仕組みを作る • 組織の仕組み化だけでなく基礎となる技術への投資も怠らない
まとめ