[Session-B-13] 継続的なサービス開発のための 技術的意思決定のポイント 太⽥ 拓也 ⼩売流通ソリューション部 

この発表の対象者 2 ● ⽇常的に意思決定することの多いマネージャー、リーダー層の⽅ ● ⾃らの意思決定についての後悔が多い⽅ ● 過去の担当者の意思決定に振り回されている⽅ 

この発表で話さないこと 3 具体的な技術要素についてのトレードオフ分析 

⾃⼰紹介 4 ● 名前: 太⽥ 拓也 ● 経歴: SIer -> バックオフィス向けSaaS開発 -> クラスメソッド ● 役割: 開発に関わるところ⼤体全部 ● 興味: プログラミングというよりもエンジニアリングが好き 

実は⾃社サービスも作ってるクラスメソッド 5 

アジェンダ 6 ● サービス開発にありがちなこと ● 不確実性との戦い⽅ ● コンテキストをだいじに ● 意思決定のコストを賢く管理する ● 意思決定の質を改善する ● まとめ 

最初に結論 7 ● 意志決定にも練習が必要 ● 練習するための基盤を整えよう 

サービス開発にありがちなこと 

サービス開発にありがちなこと 9 ● 歪な設計 ○ 明らかに⼀貫性を⽋いているが、理由がわからず怖くて修正できない ● 使っていたライブラリ、フレームワークが廃れた ○ 乗り換え先を検討しているが、元々どういう観点で選ばれたのかがわから ないので困っている ● 想定と異なる成⻑ ○ こんな使われ⽅をする想定はなかったのでパフォーマンスが問題に 

サービス開発にありがちなこと 10 ● 歪な設計 ○ 明らかに⼀貫性を⽋いているが、理由がわからず怖くて修正できない ● 使っていたライブラリ、フレームワークが廃れた ○ 乗り換え先を検討しているが、元々どういう観点で選ばれたのかがわから ないので困っている ● 想定と異なる成⻑ ○ こんな使われ⽅をする想定はなかったのでパフォーマンスが問題に ビジネスは常に不確実でわからないことだらけ 過去の担当者がそのときの最善を尽くしたことを信じる 

不確実性との戦い⽅ 

意思決定は不確実な状況下で⾏われる 12 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=51 

複雑系への対処法 13 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 

14 意志決定にも練習が必要 

15 そのための仕組みを整える 

コンテキストをだいじに 

コンテキストをだいじに 17 コンテキストとは 背景 / 状況 / ⽂脈 Whyにあたる部分 ● 競合の戦略 ● 営業状況 ● チームのスキルセット ● 技術トレンド ● etc 

コンテキストをだいじに 18 コンテキストはすぐに失われる ● 多くの場合、あなたの前に残されているのは 決して保守性が⾼いとは⾔えない設計だけ ● 当時の状況は誰も知らない 

コンテキストをだいじに 19 もしコンテキストが残されていたら？ ● 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ○ 時間のかかる内製？ ○ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ ● ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ○ 明らかなパッチワーク？ ○ 時間を確保して拡張性のある設計？ 

コンテキストをだいじに 20 もしコンテキストが残されていたら？ ● 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ○ 時間のかかる内製？ ○ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ ● ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ○ 明らかなパッチワーク？ ○ 時間を確保して拡張性のある設計？ コンテキストによって評価は変わる 

コンテキストをだいじに 21 もしコンテキストが残されていたら？ ● 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ○ 時間のかかる内製？ ○ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ ● ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ○ 明らかなパッチワーク？ ○ 時間を確保して拡張性のある設計？ 判断の結果（コードや設計）は多くの場合残り続けるが 判断のコンテキストは驚くほどすぐに失われる 

（再掲）意思決定は不確実な状況下で⾏われる 22 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 コンテキストが残ってなけ れば評価できない 

コンテキストを残す 23 ADR(Architectural Decision Records) “意思決定、背景、決定に⾄った考慮事項を ADR という形で把握することで、現在 および将来の利害関係者は、⾏なわれた決定や各決定の背後にある思考プロセスに 関する情報を収集できます。これにより、ソフトウェア開発時間が短縮され、将来 のチームにより適切なドキュメントが提供されます。” https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/architectural-decision-records/welc ome.html 

コンテキストを残す 24 ADR(Architectural Decision Records) “意思決定、背景、決定に⾄った考慮事項を ADR という形で把握することで、現在 および将来の利害関係者は、⾏なわれた決定や各決定の背後にある思考プロセスに 関する情報を収集できます。これにより、ソフトウェア開発時間が短縮され、将来 のチームにより適切なドキュメントが提供されます。” https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/architectural-decision-records/welc ome.html  コンテキストとともに意志決定を記録した⽂章 

コンテキストを残す 25 マークダウンファイルをGitHubで管理 特に意識して定義したところ ● ビジネス的な制約 ○ 特にスケジュールの制約は消失しがち ○ 時間があればこの選択はしなかった という記録は重要 チームで運⽤しているADRフォーマット 

26 コンテキストが⼤事なのはわかりました でもすべてにそんなコストはかけられないです 

意思決定のコストを賢く管理する 

28 すべての決定は等価ではない 

● 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 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 開発におけるOne-Way Door ● 外部公開されるAPIのIF設計 ● データベーススキーマ設計 ● ⾔語、フレームワーク選定 ● セキュリティ ここでADR 

意思決定のコストを賢く管理する 32 開発におけるTwo-Way Door ● 内部APIのIF設計 ● 静的解析ツールやLintツールの導⼊ ● 実装ルールの定義 変更影響が多岐に及ぶ場合は One-Wayに近いこともあるが、 昨今のAI Agentの台頭によって そのしきい値は⼤きく変わりつつある 

（再掲）意思決定は不確実な状況下で⾏われる 33 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 コスパよく コンテキストを残す 

（再掲）意思決定は不確実な状況下で⾏われる 34 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 今度はこちら 

意思決定の質を改善する 

意思決定の質を改善する 36 「〜べきか否か」という意思決定に注意 Whether or not という視野の狭窄に陥っている ？ A Aという技術を採⽤すべきか？ -> Aのことだけに関⼼を持っていかれる 

意思決定の質を改善する 37 「〜べきか否か」という意思決定に注意 A or B or C のように認知できていれば発想が広がりやすい B A C 決定⼒! :正解を導く4つのプロセス 早川書房 もっとよい⽅法はないか？ -> A and Cという組み合わせもある -> BとCに似たDという選択肢も  あるかもしれない D 

（再掲）コンテキストをだいじに 38 もしコンテキストが残されていたら？ ● 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ○ 時間のかかる内製？ ○ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ ● ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ○ 明らかなパッチワーク？ ○ 時間を確保して拡張性のある設計？ 

（再掲）コンテキストをだいじに 39 もしコンテキストが残されていたら？ ● 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ○ 時間のかかる内製？ ○ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ ● ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ○ 明らかなパッチワーク？ ○ 時間を確保して拡張性のある設計？ それぞれのケースにおいて、この2択以外にも選択肢がある 

意思決定の質を改善する 40 選択肢を広げる ● 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ○ 時間のかかる内製？ ○ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ ○ 部分的にでも機能をすぐに実現できる外部サービスの導⼊ ● ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ○ 明らかなパッチワーク？ ○ 時間を確保して拡張性のある設計？ ○ 応急処置後に落ち着いて再設計 

意思決定の質を改善する 41 選択肢を広げる ● 数ヶ⽉先には資⾦が尽きるかもしれないスタートアップの機能開発 ○ 時間のかかる内製？ ○ 悪評は多いがすぐに機能が実現できるライブラリの採⽤？ ○ 部分的にでも機能をすぐに実現できる外部サービスの導⼊ （折衷案 + 枠組みの拡張） ● ⼤規模サービスの緊急のバグ修正が必要で数分でも早く復旧したい ○ 明らかなパッチワーク？ ○ 時間を確保して拡張性のある設計？ ○ 応急処置後に落ち着いて再設計（時間軸の拡張） 折衷案や時間軸を観点に⼊れてみる 

（再掲）意思決定は不確実な状況下で⾏われる 42 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 選択肢を広げる 

（再掲）意思決定は不確実な状況下で⾏われる 43 ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making?slide=53 後は繰り返すだけ 

まとめ 

まとめ 45 ● ビジネスは常に不確実 ● 意思決定を上達させるには練習が必要 ● 振り返りのためにコンテキストを残す ○ ⼿段の⼀つとしてのADR ● ただし、すべての意思決定に⼤きなコストをかける必要はない ○ One-Way-door に投資する ● 「〜べきか否か」という問いに注意して意思決定の質を改善する ○ 選択肢を広く持つ 

参考 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 (その他), 千葉 敏⽣ (翻訳) 

Appendix 

Appendix A 48 コンテキストの重要性: OSSライブラリの選定の例 ● READMEに書かれている「解決したかった課題」「思想」に着⽬する ● その思想は、⾃分たちのプロダクト戦略、体制、既存資産と合ってますか？ ● ⽅向性が違うと ○ 無理な使い⽅で負債化 ○ コントリビュートで解消しようにも、思想に合わないIssueや PRは受け⼊れられにくい 

Appendix B 49 AI Agentの台頭によって技術的意思決定はどう変わっていくか ● コンテキストの重要性が⾼まることは⾔わずもがな ○ ドキュメントを残すことの投資対効果が⾼まった ○ むしろ⽣成AI⽂脈でコンテキストという⽤語を知った⼈も多いのでは ● フレームワークやライブラリの調査が圧倒的に早くなった ○ ハルシネーションの存在により、引き続き信憑性の判断は求められる ● ちょっとしたリファクタリングのコストが⼤きく下がった ○ 疲れ知らずのAIに⼈だと躊躇するような特定のパターンの置き換えをひた すらやってもらえる 

Appendix B 50 AI Agentの台頭によって技術的意思決定はどう変わっていくか ● プラスにもマイナスにも急激な変化を起こすので、気がついたらプロダクトが コントロール不能、なんてことにならないように気をつける ○ プラスの例 ■ ⾼速な負債の返済 ○ マイナスの例 ■ 品質の悪いコードが真似されて⼤量増殖 ■ 価値のない機能を⾼速⽣産 

No content