DevIO2025_継続的なサービス開発のための技術的意思決定のポイント / how-to-tech-decision-makaing-devio2025

[DevelopersIO 2025 Osaka](https://classmethod.connpass.com/event/361520/)で発表した資料です。

Transcript

1. [Session-B-13] 継続的なサービス開発のための 技術的意思決定のポイント 太⽥ 拓也 ⼩売流通ソリューション部
2. この発表の対象者 2 • ⽇常的に意思決定することの多いマネージャー、リーダー層の⽅ • ⾃らの意思決定についての後悔が多い⽅ • 過去の担当者の意思決定に振り回されている⽅
3. この発表で話さないこと 3 具体的な技術要素についてのトレードオフ分析
4. ⾃⼰紹介 4 • 名前: 太⽥ 拓也 • 経歴: SIer -> バックオフィス向けSaaS開発 -> クラスメソッド • 役割: 開発に関わるところ⼤体全部 • 興味: プログラミングというよりもエンジニアリングが好き
5. 実は⾃社サービスも作ってるクラスメソッド 5
6. アジェンダ 6 • サービス開発にありがちなこと • 不確実性との戦い⽅ • コンテキストをだいじに • 意思決定のコストを賢く管理する • 意思決定の質を改善する • まとめ
7. 最初に結論 7 • 意志決定にも練習が必要 • 練習するための基盤を整えよう
8. サービス開発にありがちなこと
9. サービス開発にありがちなこと 9 • 歪な設計 ◦ 明らかに⼀貫性を⽋いているが、理由がわからず怖くて修正できない • 使っていたライブラリ、フレームワークが廃れた ◦ 乗り換え先を検討しているが、元々どういう観点で選ばれたのかがわから ないので困っている • 想定と異なる成⻑ ◦ こんな使われ⽅をする想定はなかったのでパフォーマンスが問題に
10. サービス開発にありがちなこと 10 • 歪な設計 ◦ 明らかに⼀貫性を⽋いているが、理由がわからず怖くて修正できない • 使っていたライブラリ、フレームワークが廃れた ◦ 乗り換え先を検討しているが、元々どういう観点で選ばれたのかがわから ないので困っている • 想定と異なる成⻑ ◦ こんな使われ⽅をする想定はなかったのでパフォーマンスが問題に ビジネスは常に不確実でわからないことだらけ 過去の担当者がそのときの最善を尽くしたことを信じる
11. 不確実性との戦い⽅
12. 意思決定は不確実な状況下で⾏われる 12 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=51
13. 複雑系への対処法 13 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53
14. 14 意志決定にも練習が必要
15. 15 そのための仕組みを整える
16. コンテキストをだいじに
17. コンテキストをだいじに 17 コンテキストとは 背景 / 状況 / ⽂脈 Whyにあたる部分 • 競合の戦略 • 営業状況 • チームのスキルセット • 技術トレンド • etc
18. コンテキストをだいじに 18 コンテキストはすぐに失われる • 多くの場合、あなたの前に残されているのは 決して保守性が⾼いとは⾔えない設計だけ • 当時の状況は誰も知らない
19. コンテキストをだいじに 19 もしコンテキストが残されていたら？ • 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ◦ 時間のかかる内製？ ◦ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ • ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ◦ 明らかなパッチワーク？ ◦ 時間を確保して拡張性のある設計？
20. コンテキストをだいじに 20 もしコンテキストが残されていたら？ • 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ◦ 時間のかかる内製？ ◦ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ • ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ◦ 明らかなパッチワーク？ ◦ 時間を確保して拡張性のある設計？ コンテキストによって評価は変わる
21. コンテキストをだいじに 21 もしコンテキストが残されていたら？ • 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ◦ 時間のかかる内製？ ◦ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ • ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ◦ 明らかなパッチワーク？ ◦ 時間を確保して拡張性のある設計？ 判断の結果（コードや設計）は多くの場合残り続けるが 判断のコンテキストは驚くほどすぐに失われる
22. （再掲）意思決定は不確実な状況下で⾏われる 22 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 コンテキストが残ってなけ れば評価できない
23. コンテキストを残す 23 ADR(Architectural Decision Records) “意思決定、背景、決定に⾄った考慮事項を ADR という形で把握することで、現在 および将来の利害関係者は、⾏なわれた決定や各決定の背後にある思考プロセスに 関する情報を収集できます。これにより、ソフトウェア開発時間が短縮され、将来 のチームにより適切なドキュメントが提供されます。” https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/architectural-decision-records/welc ome.html
24. コンテキストを残す 24 ADR(Architectural Decision Records) “意思決定、背景、決定に⾄った考慮事項を ADR という形で把握することで、現在 および将来の利害関係者は、⾏なわれた決定や各決定の背後にある思考プロセスに 関する情報を収集できます。これにより、ソフトウェア開発時間が短縮され、将来 のチームにより適切なドキュメントが提供されます。” https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/architectural-decision-records/welc ome.html  コンテキストとともに意志決定を記録した⽂章
25. コンテキストを残す 25 マークダウンファイルをGitHubで管理 特に意識して定義したところ • ビジネス的な制約 ◦ 特にスケジュールの制約は消失しがち ◦ 時間があればこの選択はしなかった という記録は重要 チームで運⽤しているADRフォーマット
26. 26 コンテキストが⼤事なのはわかりました でもすべてにそんなコストはかけられないです
27. 意思決定のコストを賢く管理する
28. 28 すべての決定は等価ではない
29. • One-Way Door (⼀度しか通れないドア) ◦ 影響が⼤きく、変更が困難な決定 ◦ ⽴ち⽌まり、深く議論し、分析する • Two-Way Door (いつでも引き返せるドア) ◦ 影響が⼩さく、変更が容易な決定 ◦ 素早く試して学ぶことで、意思決定コストを削減する 意思決定のコストを賢く管理する 29 One-Way Door, Two-Way Door 参考: https://aws.amazon.com/jp/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/
30. 意思決定のコストを賢く管理する 30 One-Way Door, Two-Way Door • One-Way Door (⼀度しか通れないドア) ◦ 影響が⼤きく、変更が困難な決定 ◦ ⽴ち⽌まり、深く議論し、分析する • Two-Way Door (いつでも引き返せるドア) ◦ 影響が⼩さく、変更が容易な決定 ◦ 素早く試して学ぶことで、意思決定コストを削減する 参考: https://aws.amazon.com/jp/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/ こちらに投資する
31. 意思決定のコストを賢く管理する 31 開発におけるOne-Way Door • 外部公開されるAPIのIF設計 • データベーススキーマ設計 • ⾔語、フレームワーク選定 • セキュリティ ここでADR
32. 意思決定のコストを賢く管理する 32 開発におけるTwo-Way Door • 内部APIのIF設計 • 静的解析ツールやLintツールの導⼊ • 実装ルールの定義 変更影響が多岐に及ぶ場合は One-Wayに近いこともあるが、 昨今のAI Agentの台頭によって そのしきい値は⼤きく変わりつつある
33. （再掲）意思決定は不確実な状況下で⾏われる 33 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 コスパよく コンテキストを残す
34. （再掲）意思決定は不確実な状況下で⾏われる 34 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 今度はこちら
35. 意思決定の質を改善する
36. 意思決定の質を改善する 36 「〜べきか否か」という意思決定に注意 Whether or not という視野の狭窄に陥っている ？ A Aという技術を採⽤すべきか？ -> Aのことだけに関⼼を持っていかれる
37. 意思決定の質を改善する 37 「〜べきか否か」という意思決定に注意 A or B or C のように認知できていれば発想が広がりやすい B A C 決定⼒! :正解を導く4つのプロセス 早川書房 もっとよい⽅法はないか？ -> A and Cという組み合わせもある -> BとCに似たDという選択肢も  あるかもしれない D
38. （再掲）コンテキストをだいじに 38 もしコンテキストが残されていたら？ • 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ◦ 時間のかかる内製？ ◦ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ • ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ◦ 明らかなパッチワーク？ ◦ 時間を確保して拡張性のある設計？
39. （再掲）コンテキストをだいじに 39 もしコンテキストが残されていたら？ • 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ◦ 時間のかかる内製？ ◦ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ • ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ◦ 明らかなパッチワーク？ ◦ 時間を確保して拡張性のある設計？ それぞれのケースにおいて、この2択以外にも選択肢がある
40. 意思決定の質を改善する 40 選択肢を広げる • 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ◦ 時間のかかる内製？ ◦ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ ◦ 部分的にでも機能をすぐに実現できる外部サービスの導⼊ • ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ◦ 明らかなパッチワーク？ ◦ 時間を確保して拡張性のある設計？ ◦ 応急処置後に落ち着いて再設計
41. 意思決定の質を改善する 41 選択肢を広げる • 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ◦ 時間のかかる内製？ ◦ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ ◦ 部分的にでも機能をすぐに実現できる外部サービスの導⼊ （折衷案 + 枠組みの拡張） • ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ◦ 明らかなパッチワーク？ ◦ 時間を確保して拡張性のある設計？ ◦ 応急処置後に落ち着いて再設計（時間軸の拡張） 折衷案や時間軸を観点に⼊れてみる
42. （再掲）意思決定は不確実な状況下で⾏われる 42 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 選択肢を広げる
43. （再掲）意思決定は不確実な状況下で⾏われる 43 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 後は繰り返すだけ
44. まとめ
45. まとめ 45 • ビジネスは常に不確実 • 意思決定を上達させるには練習が必要 • 振り返りのためにコンテキストを残す ◦ ⼿段の⼀つとしてのADR • ただし、すべての意思決定に⼤きなコストをかける必要はない ◦ One-Way-door に投資する • 「〜べきか否か」という問いに注意して意思決定の質を改善する ◦ 選択肢を広く持つ
46. 参考 46 • ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making ◦ https://speakerdeck.com/snoozer05/software-architecture-and-decision-making • ソフトウェアアーキテクトのための意思決定術 リーダーシップ∕技術∕プロダクトマネジメントの活⽤ ◦ インプレス ◦ ISBN-10 : 4295020761 ◦ Srinath Perera (著), 島⽥ 浩⼆ (翻訳) • クネビンフレームワークとOODAループにみる「意思決定」 ◦ https://www.servantworks.co.jp/posts/consider-ooda-loop-with-cynefin-framework/ • AI時代のソフトウェア開発を考える（2025/07版） / Agentic Software Engineering Findy 2025-07 Edition ◦ https://speakerdeck.com/twada/agentic-software-engineering-findy-2025-07-edition?slide=40 • 決定⼒! :正解を導く4つのプロセス ◦ 早川書房 ◦ ISBN-10 : 4152094036 ◦ チップ ハース (著), ダン ハース (著), Chip Heath (その他), Dan Heath (その他), 千葉 敏⽣ (翻訳)
47. Appendix
48. Appendix A 48 コンテキストの重要性: OSSライブラリの選定の例 • READMEに書かれている「解決したかった課題」「思想」に着⽬する • その思想は、⾃分たちのプロダクト戦略、体制、既存資産と合ってますか？ • ⽅向性が違うと ◦ 無理な使い⽅で負債化 ◦ コントリビュートで解消しようにも、思想に合わないIssueや PRは受け⼊れられにくい
49. Appendix B 49 AI Agentの台頭によって技術的意思決定はどう変わっていくか • コンテキストの重要性が⾼まることは⾔わずもがな ◦ ドキュメントを残すことの投資対効果が⾼まった ◦ むしろ⽣成AI⽂脈でコンテキストという⽤語を知った⼈も多いのでは • フレームワークやライブラリの調査が圧倒的に早くなった ◦ ハルシネーションの存在により、引き続き信憑性の判断は求められる • ちょっとしたリファクタリングのコストが⼤きく下がった ◦ 疲れ知らずのAIに⼈だと躊躇するような特定のパターンの置き換えをひた すらやってもらえる
50. Appendix B 50 AI Agentの台頭によって技術的意思決定はどう変わっていくか • プラスにもマイナスにも急激な変化を起こすので、気がついたらプロダクトが コントロール不能、なんてことにならないように気をつける ◦ プラスの例 ▪ ⾼速な負債の返済 ◦ マイナスの例 ▪ 品質の悪いコードが真似されて⼤量増殖 ▪ 価値のない機能を⾼速⽣産