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
1
17k
エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢 / RSGT2025
yoshikiiida
5
8.9k
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
920
質とスピードを両立するログラスのホールチームQA / 20240827 QASaaS_findy
yoshikiiida
2
750
エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management
yoshikiiida
12
3.8k
スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 / Maturity and barriers in Scrum
yoshikiiida
4
2k
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
17
6.4k
ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process
yoshikiiida
7
3.7k
QA経験のないエンジニアリング マネージャーがQAのカジュアル面談に出て 苦労していること・気づいたこと / scrum fest niigata 2024
yoshikiiida
2
5.5k
Other Decks in Technology
See All in Technology
Geminiとv0による高速プロトタイピング
shinya337
1
270
「クラウドコスト絶対削減」を支える技術—FinOpsを超えた徹底的なクラウドコスト削減の実践論
delta_tech
4
170
SaaS型なのに自由度の高い本格CMSでサイト構築と運用のコスパ&タイパUP! MovableType.net の便利機能とユーザー事例のご紹介
masakah
0
110
fukabori.fm 出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話 / 20250704 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
2
7.8k
Yahoo!しごとカタログ 新しい境地を創るエンジニア募集!
lycorptech_jp
PRO
0
110
PO初心者が考えた ”POらしさ”
nb_rady
0
210
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
340
NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意
hacomono
PRO
2
160
改めてAWS WAFを振り返る~業務で使うためのポイント~
masakiokuda
2
260
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
150
スタートアップに選択肢を 〜生成AIを活用したセカンダリー事業への挑戦〜
nstock
0
200
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
2
9.4k
Featured
See All Featured
BBQ
matthewcrist
89
9.7k
How to Ace a Technical Interview
jacobian
278
23k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Scaling GitHub
holman
460
140k
Designing Experiences People Love
moore
142
24k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
970
Why Our Code Smells
bkeepers
PRO
336
57k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
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プロダクトで解決すべき問題領域の可視化 ◦ コード量もチームも無限にはスケールしない 次にやりたいこと
強くてニューゲームをやるために、 • 負債をためないシステムは組織設計レベルで初期から取り組む 必要がある • 負債の観点ごとに正しく拾える仕組みを用意する ◦ スクラムの中で拾われるように外側の仕組みを作る • 組織の仕組み化だけでなく基礎となる技術への投資も怠らない
まとめ