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におけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025
yoshikiiida
2
24k
エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢 / RSGT2025
yoshikiiida
5
9.6k
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
930
質とスピードを両立するログラスのホールチームQA / 20240827 QASaaS_findy
yoshikiiida
2
830
エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management
yoshikiiida
12
3.9k
スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 / Maturity and barriers in Scrum
yoshikiiida
4
2k
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
17
6.5k
ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process
yoshikiiida
7
3.8k
QA経験のないエンジニアリング マネージャーがQAのカジュアル面談に出て 苦労していること・気づいたこと / scrum fest niigata 2024
yoshikiiida
2
5.8k
Other Decks in Technology
See All in Technology
会社にデータエンジニアがいることでできるようになること
10xinc
9
1.6k
DeNA での思い出 / Memories at DeNA
orgachem
PRO
3
1.5k
Backboneとしてのtimm2025
yu4u
4
1.4k
AIが住民向けコンシェルジュに?Amazon Connectと生成AIで実現する自治体AIエージェント!
yuyeah
0
260
Claude Code x Androidアプリ 開発
kgmyshin
1
570
実践アプリケーション設計 ①データモデルとドメインモデル
recruitengineers
PRO
2
200
ドキュメントはAIの味方!スタートアップのアジャイルを加速するADR
kawauso
3
340
Goss: New Production-Ready Go Binding for Faiss #coefl_go_jp
bengo4com
0
1.1k
AIエージェント就活入門 - MCPが履歴書になる未来
eltociear
0
430
トヨタ生産方式(TPS)入門
recruitengineers
PRO
2
200
攻撃と防御で実践するプロダクトセキュリティ演習~導入パート~
recruitengineers
PRO
1
140
広島発!スタートアップ開発の裏側
tsankyo
0
240
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Become a Pro
speakerdeck
PRO
29
5.5k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
890
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Code Review Best Practice
trishagee
70
19k
For a Future-Friendly Web
brad_frost
179
9.9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
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プロダクトで解決すべき問題領域の可視化 ◦ コード量もチームも無限にはスケールしない 次にやりたいこと
強くてニューゲームをやるために、 • 負債をためないシステムは組織設計レベルで初期から取り組む 必要がある • 負債の観点ごとに正しく拾える仕組みを用意する ◦ スクラムの中で拾われるように外側の仕組みを作る • 組織の仕組み化だけでなく基礎となる技術への投資も怠らない
まとめ