Upgrade to Pro — share decks privately, control downloads, hide ads and more …

失敗できる意思決定とソフトウェアとの正しい歩き方_-_変化と向き合う選択肢/ Designin...

失敗できる意思決定とソフトウェアとの正しい歩き方_-_変化と向き合う選択肢/ Designing for Reversible Decisions

Avatar for soudai sone

soudai sone PRO

February 23, 2026
Tweet

Resources

仕事を前に進めるためのコツ - 判断と決断と共有 / Aim for the goal

https://speakerdeck.com/soudai/aim-for-the-goal

言語化のコツ - AIも人間も5W1Hで上手くいく

https://soudai.hatenablog.com/entry/5w1h

判断と決断の違いと決断のコツ

https://soudai.hatenablog.com/entry/2022/01/04/151923

Agile Is the Steering Wheel, Not the Gas Pedal

https://architectelevator.com/transformation/agile-steering/

More Decks by soudai sone

Other Decks in Technology

Transcript

  1. 自己紹介
 曽根 壮大(41歳)
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO

    兼 COO
 
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます(長女、次女、長男)
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

  2. 経歴 高校卒業
 浪人
 警察官
 派遣社員
 社内SE
 インフラエンジニア
 Web エンジニア
 フルスタック


    エンジニア
 CTO(第1期)
 Customer Reliability Engineer
 CTO(第2期)
 独立
 ここから東京 いまここ リーマンショックと警察官の退職 タイミングが重複する 
 ソフトウェア エンジニア 
 CTO(第3期)
 COO & CTO

  3. • 正解を探すことは難しい
 ◦ ビジネスモデルも変わるし、要件も変わる
 ◦ 法律も変わるし、技術的な制約も変わる
 ◦ 組織の状態も変わるし、前提条件の技術スタックも変わる
 • ビジネスは一発当てればOKではない


    ◦ 継続した成長が求められるし、当てて終わりではない
 ◦ 今は上手くいっても、将来も上手く行く保証はない
 ◦ 未来を予想するのは難しい
 • チャンスは何度も与えられるわけではない
 ◦ 致命傷だけは避ける必要がある
 意思決定の難しさ
  4. 失敗できる意思決定 正 解
 正 解
 正 解
 正 解
 正

    解
 正 解
 正 解
 正 解
 多くの選択肢から
 自分の求める正解を探すのは難しい 

  5. https://soudai.hatenablog.com/entry/2022/01/04/151923 結論から言えば、決断のコツは失敗できるように することだ。 失敗できる状態なら決断することが できる。 そして素早くアクションして、失敗のフィー ドバックを受け取ることで新しい決断をすることが できる。
 (中略)
 もう少し具体的に踏み込むと決断をするとき、自

    分は次のようにステップを踏む。 
 1. 決断するために必要な条件を整理する 
 2. 決断が難しい場合は、素早く始め、 
 小さく失敗できるように考える 
 3. 失敗が難しい場合は、 
 社内外も含めて多くの知見を集める 
 4. それでも難しい場合は、 
 結論をできるだけ先伸ばす 

  6. • 失敗しても致命傷にならない
 ◦ やり直せる
 ◦ 代替がある
 ◦ 失うリスクに対して許容できる
 ◦ 失敗の許容範囲を決めることができる


    • 失敗から学ぶことができる
 ◦ 仮説を検証可能である=観測可能である
 ◦ 結果に対して、客観的に分析・判断が可能である
 • すぐ試せる
 ◦ 結果が素早くでる
 ◦ 実行までの投資リソースが少ない
 ◦ 実行後の影響範囲が明確である
 仮説検証で重要なこと
  7. • 失敗しても致命傷にならない
 ◦ やり直せる
 ◦ 代替がある
 ◦ 失うリスクに対して許容できる
 ◦ 失敗の許容範囲を決めることができる


    • 失敗から学ぶことができる
 ◦ 仮説を検証可能である=観測可能である
 ◦ 結果に対して、客観的に分析・判断が可能である
 • すぐ試せる
 ◦ 結果が素早くでる
 ◦ 実行までの投資リソースが少ない
 ◦ 実行後の影響範囲が明確である
 仮説検証で重要なこと ビックバンリプレースなどはリスクが高い 
 段階的な置き換えやカナリアリリースなど検討する必要がある 

  8. • 失敗しても致命傷にならない
 ◦ やり直せる
 ◦ 代替がある
 ◦ 失うリスクに対して許容できる
 ◦ 失敗の許容範囲を決めることができる


    • 失敗から学ぶことができる
 ◦ 仮説を検証可能である=観測可能である
 ◦ 結果に対して、客観的に分析・判断が可能である
 • すぐ試せる
 ◦ 結果が素早くでる
 ◦ 実行までの投資リソースが少ない
 ◦ 実行後の影響範囲が明確である
 仮説検証で重要なこと 「これが流行っている」は仮説として弱い 
 成功指標が不明確だと成否の判断も遅れる 
 →サンクコストが高くなると失敗を認めづらい 

  9. • 失敗しても致命傷にならない
 ◦ やり直せる
 ◦ 代替がある
 ◦ 失うリスクに対して許容できる
 ◦ 失敗の許容範囲を決めることができる


    • 失敗から学ぶことができる
 ◦ 仮説を検証可能である=観測可能である
 ◦ 結果に対して、客観的に分析・判断が可能である
 • すぐ試せる
 ◦ 結果が素早くでる
 ◦ 実行までの投資リソースが少ない
 ◦ 実行後の影響範囲が明確である
 仮説検証で重要なこと 大きな変化は合意形成に時間がかかる 
 →結果が出るまでに時間もかかるし、失敗が難しくなる 

  10. • コンテナであれば、実行環境を変更できる
 ◦ 実行環境の依存をコンテナで分離することができる
 • RESTであれば、インターフェースの先は変更可能
 ◦ 例えばbackendを分けたり、Frontを差し替えたり
 • データがイミュータブルでCQRSなアーキテクチャであれば、更新と参照の

    責務を分けつつ、変化に追従することができる
 • 認証と認可を分ける
 ◦ アカウント管理が自分たちのメインのバリューではない場合
 ◦ 例えばSSOでまとめることで社内システムのIdPを活用できる
 後に変更可能な技術選定の例
  11. ゆっくり考えて素早く実行する 実行
 計画
 計画
 実行
 素早く考えて、ゆっくり実行 
 ゆっくり考えて、素早く実行 
 ブ

    ラ ッ ク ・ ス ワ ン
 実行の見直しはハイコスト
 計画段階での見直しは
 実行に比べてローコスト

  12. • 実行前の計画の仮説検証はリスクが少ない
 ◦ 例えば契約してしまうと破棄するのは難しい
 ◦ リリースしたプロダクトをクローズやピボットするのは難しい
 • 参照クラス予測法を活用する
 ◦ 類似の例を参照する


    ◦ 複数の事例のデータを元に予測する
 ◦ できるだけ抽象化してシンプルな事例で広く比較する
 ◦ 悲観的に考える(ファットテール分布を想定する)
 • ブラック・スワンを防ぐ
 ◦ どうやったら素早く窓を閉めることができるか
 ◦ ロードマップを分解する、大きなリスクを防ぐ
 ◦ 中断するようなクリティカルパスを事前に整理する
 ゆっくり考える
  13. • 実行前の計画の仮説検証はリスクが少ない
 ◦ 例えば契約してしまうと破棄するのは難しい
 ◦ リリースしたプロダクトをクローズやピボットするのは難しい
 • 参照クラス予測法を活用する
 ◦ 類似の例を参照する


    ◦ 複数の事例のデータを元に予測する
 ◦ できるだけ抽象化してシンプルな事例で広く比較する
 ◦ 悲観的に考える(ファットテール分布を想定する)
 • ブラック・スワンを防ぐ
 ◦ どうやったら素早く窓を閉めることができるか
 ◦ ロードマップを分解する、大きなリスクを防ぐ
 ◦ 中断するようなクリティカルパスを事前に整理する
 ゆっくり考える ロールバックできなくなるポイントを整理する

  14. • 実行前の計画の仮説検証はリスクが少ない
 ◦ 例えば契約してしまうと破棄するのは難しい
 ◦ リリースしたプロダクトをクローズやピボットするのは難しい
 • 参照クラス予測法を活用する
 ◦ 類似の例を参照する


    ◦ 複数の事例のデータを元に予測する
 ◦ できるだけ抽象化してシンプルな事例で広く比較する
 ◦ 悲観的に考える(ファットテール分布を想定する)
 • ブラック・スワンを防ぐ
 ◦ どうやったら素早く窓を閉めることができるか
 ◦ ロードマップを分解する、大きなリスクを防ぐ
 ◦ 中断するようなクリティカルパスを事前に整理する
 ゆっくり考える 自分たちの仮説に対して反証になるデータが大事
 反証に耐えれない仮説は基本的にリスクが高い

  15. • 実行前の計画の仮説検証はリスクが少ない
 ◦ 例えば契約してしまうと破棄するのは難しい
 ◦ リリースしたプロダクトをクローズやピボットするのは難しい
 • 参照クラス予測法を活用する
 ◦ 類似の例を参照する


    ◦ 複数の事例のデータを元に予測する
 ◦ できるだけ抽象化してシンプルな事例で広く比較する
 ◦ 悲観的に考える(ファットテール分布を想定する)
 • ブラック・スワンを防ぐ
 ◦ どうやったら素早く窓を閉めることができるか
 ◦ ロードマップを分解する、大きなリスクを防ぐ
 ◦ 中断するようなクリティカルパスを事前に整理する
 ゆっくり考える 小さな成果の積み重ねでゴールになる計画を立てる

  16. • 見直すほうが早く終わる
 ◦ 最初から想定通りに行くわけではない
 ◦ フィードバックを受け取ったら素早く変化に合わせる
 • “初めて”を極力減らす
 ◦ 新しいことはリスクが大きい


    ◦ 技術の研究・検証とプロダクト開発を同時に行わない
 ▪ それぞれ別々のプロジェクトにすれば良い
 ◦ 反復で熟練していく過程を用意する
 • 小さな成果物はコントロールしやすい
 ◦ WBSは作業の分解したtodoリストではない
 ◦ カレーのWBSは温かいカレーのルーと温かいご飯
 ▪ 作ってもいいし、レトルトでもいい
 素早く実行する
  17. • 見直すほうが早く終わる
 ◦ 最初から想定通りに行くわけではない
 ◦ フィードバックを受け取ったら素早く変化に合わせる
 • “初めて”を極力減らす
 ◦ 新しいことはリスクが大きい


    ◦ 技術の研究・検証とプロダクト開発を同時に行わない
 ▪ それぞれ別々のプロジェクトにすれば良い
 ◦ 反復で熟練していく過程を用意する
 • 小さな成果物はコントロールしやすい
 ◦ WBSは作業の分解したtodoリストではない
 ◦ カレーのWBSは温かいカレーのルーと温かいご飯
 ▪ 作ってもいいし、レトルトでもいい
 素早く実行する 素早く実行はAgile開発そのもの 

  18. • 見直すほうが早く終わる
 ◦ 最初から想定通りに行くわけではない
 ◦ フィードバックを受け取ったら素早く変化に合わせる
 • “初めて”を極力減らす
 ◦ 新しいことはリスクが大きい


    ◦ 技術の研究・検証とプロダクト開発を同時に行わない
 ▪ それぞれ別々のプロジェクトにすれば良い
 ◦ 反復で熟練していく過程を用意する
 • 小さな成果物はコントロールしやすい
 ◦ WBSは作業の分解したtodoリストではない
 ◦ カレーのWBSは温かいカレーのルーと温かいご飯
 ▪ 作ってもいいし、レトルトでもいい
 素早く実行する イチローのバットを使ったからといってイチローになれるわけではない。 
 野球の練習をしてから試合に出る 

  19. • 見直すほうが早く終わる
 ◦ 最初から想定通りに行くわけではない
 ◦ フィードバックを受け取ったら素早く変化に合わせる
 • “初めて”を極力減らす
 ◦ 新しいことはリスクが大きい


    ◦ 技術の研究・検証とプロダクト開発を同時に行わない
 ▪ それぞれ別々のプロジェクトにすれば良い
 ◦ 反復で熟練していく過程を用意する
 • 小さな成果物はコントロールしやすい
 ◦ WBSは作業の分解したtodoリストではない
 ◦ カレーのWBSは温かいカレーのルーと温かいご飯
 ▪ 作ってもいいし、レトルトでもいい
 素早く実行する イチローのバットを使ってもイチローにはなれないが、 
 イチローを呼んできてもいい。 
 イチローがダメなら大谷翔平でも良い 

  20. Small is beautiful. 小さなプログラムという発想
 1. 小さなプログラムはわかりやすい 
 2. 小さなプログラムは保守しやすい 


    3. 小さなプログラムはシステム
 リソースに優しい
 4. 小さなプログラムは他のツールと組 み合わせやすい
 
 https://amzn.to/33QPAdv
  21. • 5Wをしっかりと整理する
 ◦ Why、Whatが方向性を決める
 ◦ ユーザー/業務の“困りごと”は具体的か
 ◦ 撤退条件は明確か
 • リスクはなにか


    • 先行事例は何と比較したか
 • データは反証に耐えることができるか
 「ゆっくり考える」チェックリスト