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
6.4k
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
860
質とスピードを両立するログラスのホールチームQA / 20240827 QASaaS_findy
yoshikiiida
2
270
エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management
yoshikiiida
11
3.6k
スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 / Maturity and barriers in Scrum
yoshikiiida
4
1.9k
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
17
6.3k
ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process
yoshikiiida
7
3.5k
QA経験のないエンジニアリング マネージャーがQAのカジュアル面談に出て 苦労していること・気づいたこと / scrum fest niigata 2024
yoshikiiida
2
4.9k
ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー / A system and culture that contributes to business through code quality in Loglass
yoshikiiida
12
2.4k
Other Decks in Technology
See All in Technology
更新系と状態
uhyo
7
1.5k
От ручной разметки к LLM: как мы создавали облако тегов в Lamoda. Анастасия Ангелова, Data Scientist, Lamoda Tech
lamodatech
0
710
【Λ(らむだ)】最近のアプデ情報 / RPALT20250422
lambda
0
100
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
0
280
Cross Data Platforms Meetup LT 20250422
tarotaro0129
1
570
技術者はかっこいいものだ!!~キルラキルから学んだエンジニアの生き方~
masakiokuda
2
260
Goの組織でバックエンドTypeScriptを採用してどうだったか / How was adopting backend TypeScript in a Golang company
kaminashi
6
5.7k
食べログが挑む!飲食店ネット予約システムで自動テスト無双して手動テストゼロを実現する戦略
hagevvashi
3
420
ブラウザのレガシー・独自機能を愛でる-Firefoxの脆弱性4選- / Browser Crash Club #1
masatokinugawa
1
470
【2025年度新卒技術研修】100分で学ぶ サイバーエージェントのデータベース 活用事例とMySQLパフォーマンス調査
cyberagentdevelopers
PRO
5
7.3k
Writing Ruby Scripts with TypeProf
mame
0
140
Automatically generating types by running tests
sinsoku
2
2.9k
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Into the Great Unknown - MozCon
thekraken
37
1.7k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Agile that works and the tools we love
rasmusluckow
328
21k
A Modern Web Designer's Workflow
chriscoyier
693
190k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
135
33k
Building Flexible Design Systems
yeseniaperezcruz
329
38k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
9
750
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プロダクトで解決すべき問題領域の可視化 ◦ コード量もチームも無限にはスケールしない 次にやりたいこと
強くてニューゲームをやるために、 • 負債をためないシステムは組織設計レベルで初期から取り組む 必要がある • 負債の観点ごとに正しく拾える仕組みを用意する ◦ スクラムの中で拾われるように外側の仕組みを作る • 組織の仕組み化だけでなく基礎となる技術への投資も怠らない
まとめ