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
16k
強くてニューゲームなプロダクト開発 / Product development in new game plus
Yoshiki Iida
January 05, 2022
Tweet
Share
More Decks by Yoshiki Iida
See All by Yoshiki Iida
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
660
質とスピードを両立するログラスのホールチームQA / 20240827 QASaaS_findy
yoshikiiida
2
120
エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management
yoshikiiida
10
3.1k
スクラムの成熟と壁 〜スケーリングの議論から見えたもの〜 / Maturity and barriers in Scrum
yoshikiiida
4
1.7k
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
17
5.6k
ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process
yoshikiiida
7
2.7k
QA経験のないエンジニアリング マネージャーがQAのカジュアル面談に出て 苦労していること・気づいたこと / scrum fest niigata 2024
yoshikiiida
2
3.4k
ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー / A system and culture that contributes to business through code quality in Loglass
yoshikiiida
12
2.1k
エンジニア採用責任者と人事の邂逅 / Engineer hiring manager meet HR
yoshikiiida
1
550
Other Decks in Technology
See All in Technology
2ヶ月かかるDBアップグレード検証を最大2週間に短縮した自作Go製CLIツール「Platinum」を紹介する / Introducing Go CLI tool "Platinum" for shortened DB upgrade validation
vtryo
2
220
【虎の穴ラボ Tech Talk #1】Ansible Lintの警告への対処
toranoana
1
110
FastAPIでのasync defとdefの使い分け
takashi1029
3
550
CDK Pipelinesをざっくり理解する
smt7174
0
190
GraphQLを安全に使うためにやっていること
hayashikengo
1
170
GC24 Recap: Interface Internals
task4233
0
430
iOS 18 がやってきた!
kno3a87
1
110
BLEA v3.0.0の新しいベストプラクティスを取り入れた効率的なAWS CDK開発/jawsug_cdk16
mhrtech
2
200
あなたのアプリケーションをレガシーコードにしないための実践Pytest入門/pyconjp2024_pytest
mhrtech
3
280
LLMマルチエージェントのフローエンジニアリングを支えるLLM Ops
pharma_x_tech
4
1k
GraphQLでの型渡しとデータフェッチの最適化
hayashikengo
1
130
go:wasmexport
askua
1
120
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
663
120k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Producing Creativity
orderedlist
PRO
340
39k
How GitHub Uses GitHub to Build GitHub
holman
472
290k
Build The Right Thing And Hit Your Dates
maggiecrowley
30
2.3k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Git: the NoSQL Database
bkeepers
PRO
425
64k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Speed Design
sergeychernyshev
22
450
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
39
9.2k
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プロダクトで解決すべき問題領域の可視化 ◦ コード量もチームも無限にはスケールしない 次にやりたいこと
強くてニューゲームをやるために、 • 負債をためないシステムは組織設計レベルで初期から取り組む 必要がある • 負債の観点ごとに正しく拾える仕組みを用意する ◦ スクラムの中で拾われるように外側の仕組みを作る • 組織の仕組み化だけでなく基礎となる技術への投資も怠らない
まとめ