Slide 1
Slide 1 text
2022/01/05 #RSGT2022 Yoshiki Iida
強くてニューゲームなプロダクト開発
〜制約ゼロから長期で進化し続けられるシステムを作るチャレンジ〜
Slide 2
Slide 2 text
Yoshiki Iida (@ysk_118)
エンジニアに始まり、スクラムマスター、プロダクトオーナー、マネージャー、執行
役員を経験し、現場のチームビルディングから部署を超えた会社全体の改善な
ど、アジャイルな組織づくりの推進を行ってきました。現在は株式会社ログラスに
てソフトウェアエンジニアとしてプロダクト開発に携わっています。最近またエンジ
ニアリングマネージャーもはじめました。
書籍「Scrum Boot Camp The Book 増補改訂版」コラムニスト。
一般社団法人アジャイルチームを支える会 理事。
Profile
Slide 3
Slide 3 text
ログラスについて
は事業進捗を正確かつ迅速に可視化することで、
柔軟で高精度な経営推進を実現する経営管理クラウドサービスです。
Slide 4
Slide 4 text
ログラスについて
Slide 5
Slide 5 text
ログラスについて
Slide 6
Slide 6 text
2周目の開発で
繰り返したくないことBest3
Slide 7
Slide 7 text
● DBのデータ構造の負債
● 責務や依存度の増大したクラス
● 密結合なクライアント、サブシステム
繰り返したくないことBest3
Slide 8
Slide 8 text
● DBのデータ構造の負債
→ 時間が経過しても実態との乖離がない
● 責務や依存度の増大したクラス
→ 小さな責務に分解され、変更の影響範囲が閉じている
● 密結合なクライアント、サブシステム
→ 技術スタックの変遷に追従してリプレイスできる
繰り返したくないことBest3 の理想
Slide 9
Slide 9 text
● DBのデータ構造の負債
→ 実態と乖離していて認知負荷が高い🔥
● 責務や依存度の増大したクラス
→ 責務や依存が大きく容易に変更できない🔥
● 密結合なクライアント、サブシステム
→ リプレイス不可能で技術スタックのアップデートができない🔥
繰り返したくないことBest3 の現実
Slide 10
Slide 10 text
「くそ！何度タイムリープしても負債に
勝てない・・！」
Slide 11
Slide 11 text
「くそ！何度タイムリープしても負債に
勝てない・・！」
とならないために
Slide 12
Slide 12 text
ウォード・カニンガムによる(元祖)負債について
“Ward の言う負債の悪影響とは、開発と共に得られていく知識や理解と目の前のシステムとの
乖離が引き起こす生産性低下のことであり、自分たちが書いているコードの保守性（あるいは、
雑さ）のことではありません。”
t-wadaのブログ「【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明」
https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor
負債を正しく認知する
Slide 13
Slide 13 text
マーティン・ファウラー による技術的負債の四象限について
“だが私は、 設計の不備が負債かそうじゃないかなんて考えることが、そもそも間違ってると思
う。 技術的負債というのはメタファなのだから、 ここで問うべきなのは「負債のメタファは、 設計
上の問題を考える助けになるだろうか？ そして、他人と意見交換しやすくなるだろうか？」だ。
”
Martin Fowler's Bliki (ja)「技術的負債の四象限」
https://bliki-ja.github.io/TechnicalDebtQuadrant/
負債を正しく認知する
Slide 14
Slide 14 text
マーティン・ファウラー による技術的負債の四象限について
Martin Fowler's Bliki (ja)「技術的負債の四象限」
https://bliki-ja.github.io/TechnicalDebtQuadrant/
負債を正しく認知する
無鉄砲な 慎重な
意図的な
不注意な
「設計する時間がない
んだからしょうがない」
「今すぐリリースしない
といけない。あとでどう
にかしよう」
「レイヤー化？なにそ
れ？」
「もっとこうすべきだった
なあ」
Slide 15
Slide 15 text
● どんなコードも作られた瞬間は負債ではない
○ 作られた瞬間は解決しているビジネス要求がわかっていて、どん
な意図で実装したかわかっているから
● 時間が経過して当初のビジネス要求や設計意図を忘れてしまう、もし
くは人が入れ替わり失われることでメンテナンスできなくなったときから
負債となる(上に挙げたカニンガム、ファウラーの例では知見が失われること
までカバーしていない)
メンテナンスできない = ビジネスの要求に応えられない
私の負債の解釈
Slide 16
Slide 16 text
● 一度メンテナンスできなくなったものをメンテナンス可能
に戻すのは非常に難しい
● 理由
○ そのコードに触れるコストが高い(認知負荷)
○ そのコードに触れるモチベーションを保つのが難しい(心理的負荷)
○ そのコードに触れるコストは直接的にビジネスの成果
に結びつかない(金銭的負荷)
メンテナンスできないものの課題は解決しにくい
Slide 17
Slide 17 text
そこで
Slide 18
Slide 18 text
LTV Firstな開発
Slide 19
Slide 19 text
● システムが長生きできるかどうかが事業の生死を分ける
● ビジネスや事業を考える人がまずこの重要性を理解する
必要がある
● ログラスでは「LTV First」をバリューとして定めている
○ 長く走り続けられる意思決定を重要視する
システムのLTVを最大化する
Slide 20
Slide 20 text
● 基礎技術
○ テストは資産、リファクタリングは文化
○ モデリング駆動の開発とそれを反映しやすいアーキテクチャ
どうやっているか
● LTV Firstな仕組み
○ 負債ではなく税金でマネジメント
■ 技術的投資と非機能OKR
○ 非連続な進化を生むためのプロポーザル
○ ライブラリバージョンアップ会
Slide 21
Slide 21 text
LTV Firstな仕組み
Slide 22
Slide 22 text
● 「システムが存在する以上その維持費がかかります」ということを
大前提としている
● あとから負債を返すのではなく税金として固定の枠(Story Point)を確保して
いる
負債ではなく税金でマネジメント
エピックごとに予算を設定している。
新しい機能開発とは別に 非機能系エピック、CSからあ
がってくる細かなUX改善、技術的投資（負債返済以外
に投資も扱う）が固定で確保されている。
Slide 23
Slide 23 text
● 細かい技術的投資で拾いきれ
ない大きなテーマを扱う
● OKR※策定のタイミングで
個々がプロポーザルを提案し
重要度の高いものを投票で決
める
● 非機能OKRの中で取り扱う
進化し続けるためのプロポーザル
※OKR: Objectives and Key Results、目標管
理の1手法
Slide 24
Slide 24 text
● 週に30分Dependabot※のPRを消化
する時間を確保している
● ライブラリを古いままにしておくといざ必
要になったときにすぐにあげられない
○ 迅速な脆弱性対応をするために必
要
ライブラリバージョンアップ会
※Dependabot: GitHubが提供するパッケージ
依存管理のサポートツール。バージョンアップ
候補をPRにしてくれる。
Slide 25
Slide 25 text
基礎技術
Slide 26
Slide 26 text
単にテストを書くというだけでなく、リファクタリングのためのテストという側面も強く意識
している。テストとリファクタリングが当たり前になるような啓蒙(emojiを大量に作るな
ど)を初期からやっている。
テストは資産、リファクタリングは文化
Slide 27
Slide 27 text
新しい機能開発をするときに必ずお客様のヒアリングを行い、実際の業務をベースにし
てモデリングを行う。また、業務がドメインモデルとして表現できているか？を複数人で
ディスカッションして実装に入る。
ドメインモデルを中心に各レイヤーの責務を守りやすいアーキテクチャ。
モデリング駆動の開発とアーキテクチャ
Slide 28
Slide 28 text
どうやっているかのまとめ
Slide 29
Slide 29 text
● SRP(単一責任原則)違反指数※
○ SRP＝R＋U＋((L/100)－5)
■ R：修正リビジョンのユニーク数
■ U：修正ユーザのユニーク数
■ L：モジュールのライン数
○ 人数増加、コード量増加に対して SRP違
反指数の増加を抑え込めている
（平均だけでなく分散もみることで Fatな
コードのばらつきをみている）
● 2021年ハイライト
○ テストコード量がプロダクトコード量を上
回る
○ 追加だけでなく削除も並行している
コードの状態の可視化
※SRP違反指数について
https://gihyo.jp/dev/serial/01/perl-hackers-hub/000803
Slide 30
Slide 30 text
● システムパフォーマンスと組織パフォーマンスの可視化
● メトリクスに基づいたエピック優先順位の意思決定の自動化
● 1プロダクトで解決すべき問題領域の可視化
○ コード量もチームも無限にはスケールしない
次にやりたいこと
Slide 31
Slide 31 text
強くてニューゲームをやるために、
● 負債をためないシステムは組織設計レベルで初期から取り組む
必要がある
● 負債の観点ごとに正しく拾える仕組みを用意する
○ スクラムの中で拾われるように外側の仕組みを作る
● 組織の仕組み化だけでなく基礎となる技術への投資も怠らない
まとめ