その設計、 本当に価値を生んでますか？

PHPカンファレンス香川2025

Transcript

1. その設計、 本当に価値を生んでますか？ 事業理解から始める設計投資のメリハリと “手軽さ”の考え方 PHPカンファレンス香川2025 akshimo
2. • あくしも • ソフトウェアエンジニア • フリーランス • 新潟から来ました
3. Excuse
4. • 今回の話は「IMO」も結構あります • 「いや、私はこう思う」というご意見大歓迎 • ”カンファレンス”なので”会議”していきましょう • 生々し過ぎる部分があるので一部ボカしてます Excuse
5. • クリーンアーキテクチャ • ポート&アダプタ • イベント駆動 • モジュラーモノリス • MVC • 大きな泥団子 • マイクロサービス いま私たちにはたくさんの選択肢がある • CQRS • Repository • ActiveRecord • トランザクションスクリプト • イミュータブルデータモデリング • 腐敗防止層 • etc…
6. 今日は一つの選択肢の Howではなく どうやって意思決定するかみたいなお話
7. かつての失敗
8. 時は201x年
9. 時は201x年 巷ではDDDが流行していた
11. 我々もレイヤードアーキテクチャ を採用した
12. 我々もレイヤードアーキテクチャ を採用した だが、いまいち価値を出せなかった
13. 我々もレイヤードアーキテクチャ を採用した もちろんDDDやその戦術が悪いのではなく 我々の「何か」が良くなかった
14. • Evans本、IDDD本、その他書籍や事例を学習・調査 • チーム内で勉強会開く • 良く検討した上で導入を決定（したつもり） 金のハンマーパターンに陥ったつもりはなかった
15. • Repositoryパターンをうまく使いこなせない • チームメンバーの理解度を上げられなかった • あまり複雑さがないドメイン層 うまくいかなった点はいくつかあった
16. • Repositoryパターンをうまく使いこなせない • チームメンバーの理解度を上げられなかった • あまり複雑さがないドメイン層 うまくいかなった点はいくつかあった
17. • ユーザー向けフロントサイト • 受注 • 配送 • 管理画面 • etc… サービスはいくつかに分かれている
18. • ユーザー向けフロントサイト • 受注 • 配送 • 管理画面 • etc… サービスはいくつかに分かれている 例えばこいつ
19. • 基本はデータをそのまま表示するだけ • 薄いドメイン層 • UIをいかにオシャレに見せるかが肝 フロントサイト
20. そもそも技術選定が よくなかったのでは？
21. そもそも技術選定が よくなかったのでは？ それは仰る通りです...
22. • ビジネスの複雑性・サービスの継続年数などが大きいほど クリーンアーキテクチャなどから受けられるベネフィットは 大きい • MVCと比較するとどこかに「損益分岐点」がある 数年前の登壇にて ちなみに発表タイトルは 「DDDで失敗した俺が異世界転生したら 最強のアーキテクトになった件について」
23. 雑なイメージ
24. 雑なイメージ 実際はこんな単純じゃないけど…
25. その設計、 本当に価値を生んでますか？ 事業理解から始める設計投資のメリハリと “手軽さ”の考え方 PHPカンファレンス香川2025 akshimo
26. その設計、 本当に価値を生んでますか？ 事業理解から始める設計投資のメリハリと “手軽さ”の考え方 PHPカンファレンス香川2025 akshimo
27. Kent Beck 「グッドハートの法則」はもっと悲観的に捉えるべきだった
28. Kent Beck 「グッドハートの法則」はもっと悲観的に捉えるべきだった
29. ソフトウェアエンジニアリングとは 時間で積分したプログラミングである Titus Winters, Tom Manshreck, Hyrum Wright Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス
31. この面積をなるべく大きくしたい （のだが、できなかった）
32. 2024年：Tidy First?の日本語版出版
34. 明日の100万円より 今日の100万円の方が価値が高い
35. お仕事ありがとう！ 今100万円の給料あげるね！ お仕事ありがとう！ 一年後に100万円の給料あげるね！
36. 米国債を100万円購入
37. 米国債を100万円購入 1年後に104万円に！ ※実際は為替や手数料などの影響がある
38. お仕事ありがとう！ 今100万円の給料あげるね！ お仕事ありがとう！ 一年後に100万円の給料あげるね！ 一年後に104万円の給料あげるね！
39. 会社が潰れました... この人はそもそもお金を払ってくれない危険も
40. オプショナリティ
41. 今の値段は100万円！
42. 今の値段は100万円！ １ヶ月後には110万円くらいになりそう！ でも大コケもするかもなぁ…
43. １ヶ月後に100万円で買う権利 を5万円で今売ってあげよう １ヶ月後には110万円くらいになりそう！ でも大コケもするかもなぁ…
44. １ヶ月後に100万円で買う権利 を5万円で今売ってあげよう 買った！
45. • １ヶ月後に110万円になったら... => 105万円で110万円のものを買える！ • １ヶ月後に90万円になったら... => 5万円の損ですむ！（権利を行使しない）
46. １ヶ月後に100万円で買う権利 を5万円で売ってあげよう
47. これが「オプション」 ※正確にはコールオプション
48. オプションはどんな時に 価値が高いか？
49. 90%の確率で105万円に 10%の確率で98万円に 100万円の株が … 60%の確率で120万円に 40%の確率で80万円に
50. 90%の確率で105万円に 10%の確率で98万円に 100万円の株が … 60%の確率で120万円に 40%の確率で80万円に 「ボラティリティ」が大きい方が オプションの価値が高い！
51. ボラティリティ 小 ボラティリティ 大
52. ボラティリティ 小 ボラティリティ 大
53. 投資は自己責任で！！！
54. • 明日の100万円より今日の100万円の方が価値が高い • オプションとは将来ある値段で株を買う権利 • ボラティリティが大きいほどオプションの価値は高い ここまでのまとめ あくまでもエンジニアリングのための説明なので 金融知識としては不十分な点はご了承ください
55. • 明日の100万円より今日の100万円の方が価値が高い ここまでのまとめ => 明日のリリースより今日のリリースの方が価値が高い 　 （明日にリリースを回すとリリースされない可能性も）
56. • オプションとは将来ある値段で株を買う権利 ここまでのまとめ => オプションとは振る舞いの変更コストを下げる設計
57. • ボラティリティが大きいほどオプションの価値は高い ここまでのまとめ => 不確実性が高いほどオプションの価値は高い
58. • 明日のリリースより今日のリリースの方が価値が高い • オプションとは振る舞いの変更コストを下げる設計 • 不確実性が高いほどオプションの価値は高い ここまでのまとめ
59. • 変化の多さ • 事業・機能がヒットするか 2種類のボラティリティ
60. • 変化の多さ • 事業・機能がヒットするか 2種類のボラティリティ 積極的に設計投資し、オプションを作る
61. • 変化の多さ • 事業・機能がヒットするか 2種類のボラティリティ 「捨てる」というオプションが 効果的な場合がある
62. 捨てやすいコードには 凝集が必要
63. LCOM1 = P − Q, if P > Q LCOM1 = 0 otherwise Project Metrics Help - Cohesion metrics https://www.aivosto.com/project/help/pm-oo-cohesion.html
64. コードを書かなければ LCOMは0 ※半分冗談、半分本気です
65. ビックバンリリース
67. 本当にこれだけのものを 得られるか不確実
68. こうしたい
69. • なるべく凝集して「捨てやすく」 • ノーコードも検討する • AIに任せたり一時的に小さな泥団子を作っても良い もう一つのボラティリティ FeatureToggleなんかも有効
70. • なるべく凝集して「捨てやすく」 • ノーコードも検討する • AIに任せたり一時的に小さな泥団子を作っても良い もう一つのボラティリティ 早く試し、早く学ぶ必要がある
71. ボラティリティ 変更が多い 捨てるかも 小 競争優位性 ◯ ? × 設計投資 積極的に投資 ひとまず消極的 消極的 オプションの価値 大 「捨てる」オプションの価 値は大 小 実装 熟練したエンジニア 小さな泥団子、AI、手オ ペ 既製品、早さ重視 参考：ドメイン駆動設計をはじめよう
72. ボラティリティ 変更が多い 捨てるかも 小 競争優位性 ◯ ? × 設計投資 積極的に投資 ひとまず消極的 消極的 オプションの価値 大 「捨てる」オプションの価 値は大 小 実装 熟練したエンジニア 小さな泥団子、AI、手オ ペ 既製品、早さ重視 参考：ドメイン駆動設計をはじめよう
73. ボラティリティ 変更が多い 捨てるかも 小 競争優位性 ◯ ? × 設計投資 積極的に投資 ひとまず消極的 消極的 オプションの価値 大 「捨てる」オプションの価 値は大 小 実装 熟練したエンジニア 小さな泥団子、AI、手オ ペ 既製品、早さ重視 参考：ドメイン駆動設計をはじめよう
74. ボラティリティ 変更が多い 捨てるかも 小 競争優位性 ◯ ? × 設計投資 積極的に投資 ひとまず消極的 消極的 オプションの価値 大 「捨てる」オプションの価 値は大 小 実装 熟練したエンジニア 小さな泥団子、AI、手オ ペ 既製品、早さ重視 参考：ドメイン駆動設計をはじめよう
75. ボラティリティ 変更が多い 捨てるかも 小 競争優位性 ◯ ? × 設計投資 積極的に投資 ひとまず消極的 消極的 オプションの価値 大 「捨てる」オプションの価 値は大 小 実装 熟練したエンジニア 小さな泥団子、AI、手オ ペ 既製品、早さ重視 参考：ドメイン駆動設計をはじめよう この移動がありうる
76. Tidy First?って 個人の整頓の話じゃないの？
77. Tidy First?って 個人の整頓の話じゃないの？ 「ソフトウェア設計はフラクタル」！
79. 数分から数時間の整頓の規模では、整頓の経済性を正確に計算できない （し、すべきでもない）。来たるべき大きな物事に備えて、私たちは2つの重要 な判断の型を鍛えている。 ・ソフトウェア設計のタイミングやスコープに影響するインセンティブを意識す ることに慣れる（「私は設計にもっと時間をかけたいのに、反対される。いった いどういうことだ？」）。 ・まずは人間関係のスキルを自分自身で練習し、そのあとで直接的な同僚や さらに遠くの同僚へと使っていく。 Kent Beck Tidy First? ―個人で実践する経験主義的ソフトウェア設計
80. 数分から数時間の整頓の規模では、整頓の経済性を正確に計算できない （し、すべきでもない）。来たるべき大きな物事に備えて、私たちは2つの重要 な判断の型を鍛えている。 ・ソフトウェア設計のタイミングやスコープに影響するインセンティブを意識す ることに慣れる（「私は設計にもっと時間をかけたいのに、反対される。いった いどういうことだ？」）。 ・まずは人間関係のスキルを自分自身で練習し、そのあとで直接的な同僚や さらに遠くの同僚へと使っていく。 規模が違うと必ずうまくいくとは限らないが、 最初に試すものとしては良い Kent Beck Tidy First? ―個人で実践する経験主義的ソフトウェア設計
81. 数分から数時間の整頓の規模では、整頓の経済性を正確に計算できない （し、すべきでもない）。来たるべき大きな物事に備えて、私たちは2つの重要 な判断の型を鍛えている。 ・ソフトウェア設計のタイミングやスコープに影響するインセンティブを意識す ることに慣れる（「私は設計にもっと時間をかけたいのに、反対される。いった いどういうことだ？」）。 ・まずは人間関係のスキルを自分自身で練習し、そのあとで直接的な同僚や さらに遠くの同僚へと使っていく。 ただし可逆性を確保する工夫は必要そう Kent Beck Tidy First? ―個人で実践する経験主義的ソフトウェア設計
83. 他にも考えるべきことは色々 Mark Richards, Neal Ford ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ
84. 話を戻そう どうすれば良かった？
86. • ボラティリティは低〜中程度 • 配送方法の追加や複数倉庫での使用は予想された • 機能追加や変更はあったが予想の範囲内が多い 配送サービス
87. • ボラティリティは低〜中程度 • 配送方法の追加や複数倉庫での使用は予想された • 機能追加や変更はあったが予想の範囲内が多い 配送サービス 「安定して価格上昇」してるイメージで ボラティリティは高くない
88. • （UIの）ボラティリティは高い • ビジネスルールの複雑性は低い ◦ 基本はバケツリレーで情報を表示する • 「力の入れどころ」をUIに集中すればよかった？ フロントサイト
89. • 利益と競合優位性を生む「中核」 • 外部接続するゆえの複雑性がある • 力の入れどころ ◦ エースエンジニアの投入 ◦ 腐敗防止層 とある外部連携機能
90. • XXしたらX割引！みたいな機能 • 効果があるかはリリースしてみないとわからない • あまり設計投資せず早く作る • 手オペ、小さな泥団子 とあるキャンペーン機能
91. どうやって事業理解し 意思決定をする？
92. 「経験」
93. といっても元も子もないので 自分が気をつけている Tipsを紹介 皆さんが意識していることも 教えてください
94. • マインドセット • WhyとWhatを理解する • KPI • フレームワークを使う • 話す
95. • 正解のない問題に立ち向かう勇気を持つ • 決断疲れしない マインドセット
96. • 正解のない問題に立ち向かう勇気を持つ • 決断疲れしない マインドセット 後から効果検証することが大事
97. • 正解のない問題に立ち向かう勇気を持つ • 決断疲れしない マインドセット ロードマップを意識しよう
98. • What：「何を」作るべきか？ ◦ 特に振る舞いの判断に有効 • Why：「なぜ」作るべきか？ ◦ 特に構造の判断に有効 WhyとWhatを理解する
99. • その設計・コードはKPIのどこに効くのか意識する • 効果検証は大事（2回目） KPIは大事
100. • その設計・コードはKPIのどこに効くのか意識する • 効果検証は大事（2回目） KPIは大事 籠落ち率?CAC?MAU? 原価率?LTV?CVR?
101. • その設計・コードはKPIのどこに効くのか意識する • 効果検証は大事（2回目） KPIは大事 Impactを出すまでが仕事
102. • その設計・コードはKPIのどこに効くのか意識する • 効果検証は大事（2回目） KPIは大事 機能を「捨てる」ことに備え 事前にメンバーの理解を得ておくことも大事
103. • 5W1H • ピラミッドストラクチャー • ロジックツリー • PDCA • MECE • SWOT • PEST • etc… フレームワークを使う
104. • ビジネスサイドの予測を真に受けすぎない • 不確実なことの微妙なニュアンスを汲み取るには話すこと が大事 話す
105. 起業家は自分にウソをつくのが得意である。 証拠もないのに誰かを説得しなきゃいけないのだから、ウソは 起業家として成功するための必要条件なのかもしれない。 何かに挑戦するときには、信じてくれる人が必要だ。スタート アップのジェットコースターのような経営をうまくやるには、起業 家は思い込みの世界に常に片足を突っ込んでおく必要がある。 Alistair Croll, Benjamin Yoskovitz Lean Analytics ―スタートアップのためのデータ解析と活用法
106. • ビジネスサイドの予測を真に受けすぎない • 不確実なことの微妙なニュアンスを汲み取るには話すこと が大事 話す 経営陣や株主を説得することも 彼らの仕事の一つ
107. ビジネス側の人と開発者は、プロジェ クトを通して 日々一緒に働かなければなりませ ん。 アジャイル宣言の背後にある原則 https://agilemanifesto.org/iso/ja/principles.html
108. ご清聴 ありがとうございました