ソフトウェアにおける「捨てやすさ」の探求

Transcript

1. ソフトウェアにおける 捨てやすさの探究 Yutaka Kamei Scrum Fest Osaka2025 @関西大学梅田キャンパス KANDAI Me RISE July 19, 2025
2. Self-introduction • Yutaka Kamei • @yykamei on GitHub • @_yykamei on X • Timee, Inc.
3. Copyright © Timee All Rights Reserved 3 タイミーとは 

4. Copyright © Timee All Rights Reserved 4 タイミーの特徴 

5. Copyright © Timee All Rights Reserved 5 導入実績 

6. Copyright © Timee All Rights Reserved 6 導入企業の例 

7. 今回は私が思っている主張をぶつけていこうと 思っています。間違っていることもあると思いま すがご了承ください。
8. “ソフトウェアはソフトでなければいけない” —Robert C. Martin（著）、角征典、髙木正弘（訳）『Clean Architecture 達人に学ぶソフ トウェアの構造と設計』KADOKAWA、2018年
9. ソフトウェアの「ソフト」とは？ 簡単にいうと、 not hard ということ → 簡単に貫通させられるし、分割もでき るし、形を変えられるようなもの https://www.dictionary.com/browse/soft
10. ソフトウェアにはユーザーがいる
11. 2種類のユーザー • もっとたくさん「機能」を欲しがる ユーザー • 日常的に特定の「機能」を使って現 状に満足しているユーザー
12. ソフトウェア開発者のジレンマ
13. ソフトウェア自身も形を変えたがる — ソフトだからね • 潜在的なバグが顕在化 • 脆弱性が発見された →ユーザーに使ってもらいながらこれらに対応する必要がある
14. リファクタリング • リファクタリングは見た目や振る舞いを変えずに内部構造を改善する取り組み ◦ これは最高だ！ • しかし、リファクタリングは難しく、システムを破壊する可能性もある ◦ 振る舞いを変えないはずでは！？
15. “整頓は可愛くてふわふわした小さなリファクタリン グなので、誰も嫌いになれないはずだ” Kent Beck（著）、吉羽龍太郎、永瀬美穂、細澤あゆみ（訳）『Tidy First? ―個人で実践 する経験主義的ソフトウェア設計』オライリー・ジャパン、2024年
16. 整理と整頓 • 「整理」は不要なものを捨てること • 「整頓」は必要なものを決められた 場所に置き、取り出しやすくするこ と
17. 「捨てる」のは簡単だが「何を」「捨てる」のか？ • ソフトウェアにおける「整理」（捨てる） は、意思決定と合意があれば簡単 • しかし、「捨てる」対象の特定が難し い場合がある • 機能のリプレイスのように、既存機能 を「捨てる」際に影響範囲の特定と安 全な削除が求められる • 対象が分散していると「捨てる」難易 度が非常に高くなる
18. 最初は「適切な境界」に基づいていた（はず） • 「モジュールの分離」だとか「境界 の設定」みたいな話 • しかし、ソフトウェアは進化の過程 で当初の境界が曖昧になることが ある
19. 最初から「捨てる」ことを目指す キャップとラベルは「プラスチック」として捨てられるようになっている
20. 「捨てる」ことを目指す開発 • 「未来永劫使うわけではない」とい う前提で機能を考える • 時代や状況の変化で前提が簡単 に崩れることを受け入れる • 「あとで捨てられる機能」として導入 することで、心理的なハードルが下 がる • 「捨てる」対象が明確になり、確実 に捨てられる • Slack は Glitch というゲームからピボットし た ◦ https://www.johnnyrodgers.is/the-death-of- glitch-the-birth-of-slack/ • YouTube は最初は出会いを促すサービス だった ◦ https://en.wikipedia.org/wiki/History_of_Yo uTube Copeさんの “Stop treating code as an asset” に近い考えかもしれません
21. 「捨てる」マインドとソフトウェア原則 • 「捨てる」ことを目指すと、「捨てる」対象がどこからどこまでかが明確になる • 「意味のあるかたまりにする」「同じ理由・同じタイミングで変更されるものをまとめ る」といった原則に従う • 「同じ理由・同じタイミングで変更されるか？」という問いを「同じタイミングで捨てら れるか？」に置き換えただけ ◦ 違いはこう ▪ 「変更のタイミング」を意識するか？ ▪ 期待通りその空間はきれいになるか？
22. プラグインの話 — 「土台」自体も「捨てる」 • プラグインの仕組みは「捨てる」のに便 利だが、その「土台」を最初からつくらな い • 一度「土台」を作ると、将来より良い方法 が見つかっても置き換えが難しいのでな るべく「土台」自体も「捨てられる」ように しておきたい • 高価な決定を先送りし、「捨てる」ことで オプションを購入する ◦ オプションの行使は先送りに
23. 「作り直し」の奨励と学びの蓄積 • 「捨てる」ことを目指すことは、必然的 に「作り直し」を奨励する • これは「車輪の再発明」に見えるかも しれないが、そうではない • 「捨てる」「作り直す」を繰り返すこと で、その過程での学びが蓄積される • 関わったメンバーの経験がアップ デートされ、技量が向上する ちなみに、Copeさんはオープニングキーノートで “Move the rework to analysis” と言い、 Set-Based Design の文脈で作りなおせと言っていました
24. 品質と「捨てやすさ」 • 「捨てる」からといって「雑につくればいい」わけではない • 目の前のリリースに向けて、リリース可能な品質のものを目指す • 「捨てる」ことを目指すからこそ、品質が良くなる可能性がある • 「捨てる」ためのソフトウェア設計は、単体テストのしやすさや変更・リファクタリング のしやすさにつながる
25. まとめ • ソフトウェアはソフトだが、ユーザーが増えると変更が難しくなる • 開発者は「変更を望む」と「現状維持を望む」ユーザーの間で板挟みになりがち • 「捨てる」という考え方は、未来永劫使わない前提で機能を設計し、明確な境界を 設定する • 「捨てる」ことを目指す開発は、「作り直し」を奨励し、学習と品質向上につながる
26. Thank you!