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

技術選定を突き詰める Online Conferenc e ―― 逆境を乗り越える意思決定プロセス   失敗できる意思決定と  ソフトウェアとの正しい歩き方  -
変化と向き合う選択肢 

意思決定に正解はない      What is it? 

意思決定に正解はない  ↓  自分で正解にするしかない  What is it? 

失敗と成功は対ではなく    地続きの世界  What is it? 

What is it?  成功  失敗  OR  よくある間違い 

What is it?  失敗  失敗  成功  実際の成功への道筋  やってみないと  わからない  わかったことから改
善する  仮説検証を繰り返す  

失敗から学び    正解にしていくための意思決定のコツ  What is it? 

1. 自己紹介  2. 失敗できる意思決定  3. ゆっくり考えて素早く実行する  4. Simple is Beautiful 
5. おわりに  あじぇんだ 

自己紹介  曽根壮大（41歳）  Have Fun Tech LLC 代表社員  株式会社リンケージ CTO
兼 COO    そ  • 日本PostgreSQLユーザ会勉強会分科会担当  • 3人の子供がいます（長女、次女、長男）  • 技術的にはWeb/LL言語/RDBMSが好きです  • コミュニティが好きたけ  ね  とも 

経歴高校卒業  浪人  警察官  派遣社員  社内SE  インフラエンジニア  Web エンジニア  フルスタック 
エンジニア  CTO（第1期）  Customer Reliability Engineer  CTO（第2期）  独立  ここから東京いまここリーマンショックと警察官の退職タイミングが重複する   ソフトウェアエンジニア   CTO（第3期）  COO & CTO 

意思決定とは        失敗できる意思決定

意思決定とは  ↓  目的を達成するために  複数の選択肢から選択肢を選び決定すること  失敗できる意思決定

• 正解を探すことは難しい  ◦ ビジネスモデルも変わるし、要件も変わる  ◦ 法律も変わるし、技術的な制約も変わる  ◦ 組織の状態も変わるし、前提条件の技術スタックも変わる  • ビジネスは一発当てればOKではない 
◦ 継続した成長が求められるし、当てて終わりではない  ◦ 今は上手くいっても、将来も上手く行く保証はない  ◦ 未来を予想するのは難しい  • チャンスは何度も与えられるわけではない  ◦ 致命傷だけは避ける必要がある  意思決定の難しさ

リーダーがするべき意思決定は    決断  失敗できる意思決定

判断と決断の違い      失敗できる意思決定

“判断の話で言うとぼくはそーだいさんがしてくれた「判断と決断は違う」   という話がだいぶ実になっていて、   「情報を集めれば理屈で答えが出せるのが判断、今は情報を集めることができない中で答えを出さないといけないのが決断、リーダーがやらなけれ
ばならないのは決断」という話を  かなり大事にしている”   https://soudai.hatenablog.com/entry/2022/01/04/151923

　インプット、スループット、アウトプットのそれぞれのステップにおいて標準化を行うことで ”判断”にすることができる。  具体としては作業のマニュアル化だったり受け入れ基準のガイドラインだったりする。   同じ材料で品質を固定化するのも標準化の一つ  

判断にできる仕組みの作り方は    意思決定者の腕の見せ所  失敗できる意思決定

失敗できる意思決定

正解を探すのではなく    ゴールに近づく意思決定が大事    失敗できる意思決定

失敗できる意思決定正解  正解  正解  正解  正
解  正解  正解  正解 

失敗できる意思決定正解  正解  正解  正解  正
解  正解  正解  正解  多くの選択肢から  自分の求める正解を探すのは難しい  

失敗できる意思決定ゴール  正解に近づく仮説を検証して、  最終的にゴールにたどり着く  最初の仮説は  多くの場合、間違う 

つまり重要なのは    ゴールに近づく仮説検証のサイクル  失敗できる意思決定

https://soudai.hatenablog.com/entry/2022/01/04/151923 結論から言えば、決断のコツは失敗できるようにすることだ。失敗できる状態なら決断することができる。そして素早くアクションして、失敗のフィードバックを受け取ることで新しい決断をすることができる。  (中略）  もう少し具体的に踏み込むと決断をするとき、自
分は次のようにステップを踏む。   1. 決断するために必要な条件を整理する   2. 決断が難しい場合は、素早く始め、   小さく失敗できるように考える   3. 失敗が難しい場合は、   社内外も含めて多くの知見を集める   4. それでも難しい場合は、   結論をできるだけ先伸ばす  

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

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

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

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

• コンテナであれば、実行環境を変更できる  ◦ 実行環境の依存をコンテナで分離することができる  • RESTであれば、インターフェースの先は変更可能  ◦ 例えばbackendを分けたり、Frontを差し替えたり  • データがイミュータブルでCQRSなアーキテクチャであれば、更新と参照の
責務を分けつつ、変化に追従することができる  • 認証と認可を分ける  ◦ アカウント管理が自分たちのメインのバリューではない場合  ◦ 例えばSSOでまとめることで社内システムのIdPを活用できる  後に変更可能な技術選定の例

？？？「現実はそんなに簡単ではない」      失敗できる意思決定

？？？「現実はそんなに簡単ではない」  ↓  リスクの少ない意思決定ばかりじゃない  失敗できる意思決定

それでも意思決定しないといけない    その時にどのように考えるべきか  失敗できる意思決定

小さく素早く開始することは重要    ただし、無計画は違う  ゆっくり考えて素早く実行する 

ゆっくり考えて素早く実行する

https://www.amazon.co.jp/dp/476314037X “失敗したプロジェクトの共通点は、「すばやく考え、ゆっくり動く」ことだ。一方、成功したプロジェクトはいずれも「ゆっくり考え、すばやく動く」ことを徹底している。”  “複雑性と相互依存性が増している現代世界では、ノーマルアクシデントが起こる確率が高まっているが、それは今に始まったことではない。中世のことわざにも、「釘が抜けて蹄鉄が外れ、蹄鉄が外れて馬が倒れ、馬が倒れて乗り手が死に、乗り手が死んで戦に負け、戦に負けて国が滅んだ」とある。 
（中略）  スピードアップしてさっさと終わらせれば、窓が開いている時間を劇的に短縮することができる。  これは、あらゆるプロジェクトでリスクを下げる主要手段である。     

“プロジェクト期間を「開いた窓」と考えるとわかりやすい。  期間が長くなればなるほど、窓は大きく開く。  そして窓が大きく開けば開くほど、大きく邪悪なブラックスワンが窓から飛び込んできてトラブルを起こすリスクも増大する。”    – BIG THINGS P.44  ゆっくり考えて素早く実行する 

ゆっくり考えて素早く実行する実行  計画  計画  実行  素早く考えて、ゆっくり実行   ゆっくり考えて、素早く実行   実行時間が短いほうが 
外部起因の影響が少ない 

ゆっくり考えて素早く実行する実行  計画  計画  実行  素早く考えて、ゆっくり実行   ゆっくり考えて、素早く実行  

ゆっくり考えて素早く実行する実行  計画  計画  実行  素早く考えて、ゆっくり実行   ゆっくり考えて、素早く実行   ブ
ラック・スワン 

ゆっくり考えて素早く実行する実行  計画  計画  実行  素早く考えて、ゆっくり実行   ゆっくり考えて、素早く実行   ブ
ラック・スワン  実行の見直しはハイコスト  計画段階での見直しは  実行に比べてローコスト 

ゆっくり考えて素早く実行する実行のフェーズを短くするために    計画はしっかりと考える  これがゆっくり考える 

ゆっくり考えて素早く実行するゆっくり考える  ↓  計画も仮説検証を行う 

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

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

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

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

ゆっくり考えて素早く実行するゆっくり考えた計画を    素早く実行する 

ゆっくり考えて素早く実行するアジャイルはハンドルであって、アクセルではない  https://architectelevator.com/transformation/agile-steering/

ゆっくり考えて素早く実行する RapidとQuickは違う    素早くフィードバックを獲得して、  変化に対応する 

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

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

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

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

ゆっくり考えて素早く実行する前提行動結果シングルループは実行結果に元に行動を変える

ゆっくり考えて素早く実行する前提行動結果ダブルループは結果から、前提を変えて根本から変更する

ゆっくり考えて素早く実行する素早く実行するために必要な技術    そこが自分たちのコアコンピタンス 

ゆっくり考えて素早く実行する素早く実行するために必要な技術    そこが自分たちのコアコンピタンス  マイクロサービスは小さくやるためのhowの一つでしかない   モノリスなシステムでも交換可能なっていれば良い   テストだってオブザーバビリティだって、CI/CDだってそう  

ゆっくり考えて素早く実行するゆっくり考えるのと    何も検証しないのは違う 

ゆっくり考えて素早く実行する事前にと検討した仮説を    素早く実行して検証し、計画を修正する 

シンプルなモノは美しい      Simple is Beautiful 

シンプルなモノは美しい  ↓  コントロールしやすい  Simple is Beautiful 

SimpleとEasyは違う      Simple is Beautiful 

Simple is Beautiful

SimpleとEasyは両立する      Simple is Beautiful

Small is beautiful.    小さいものは美しい  Simple is Beautiful

Small is beautiful. 小さなプログラムという発想  1. 小さなプログラムはわかりやすい   2. 小さなプログラムは保守しやすい  
3. 小さなプログラムはシステム  リソースに優しい  4. 小さなプログラムは他のツールと組み合わせやすい    https://amzn.to/33QPAdv

単一な小さい形に落とし込む    最小構成のWBSがインチストーンになる  Simple is Beautiful

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

小さくシンプルな方が    仮説検証しやすい  Simple is Beautiful

小さくシンプルな方が    仮説検証しやすい  Simple is Beautiful 変数は少ないほうが仮説検証しやすい原則は One change
at a time

小さなリリースの積み重ねが    大きなプロダクトになっていく  Simple is Beautiful

ゆっくり考えるのと    意思決定できないのは違う  Simple is Beautiful

ゆっくり考えるのと    意思決定できないのは違う  Simple is Beautiful 仮説を意思決定して、実行するために小さくシンプルになるまで考えること

ゆっくり考えるのと    意思決定できないのは違う  Simple is Beautiful 仮説を意思決定して、実行するために小さくシンプルになるまで考えることスコープを削るのも選択肢の一つ

意思決定の選択に悩んだら    小さくてシンプルになる選択肢を選ぶ  Simple is Beautiful

失敗できる意思決定のコツは    ゆっくり考えて素早く実行  おわりに

• 5Wをしっかりと整理する  ◦ Why、Whatが方向性を決める  ◦ ユーザー/業務の“困りごと”は具体的か  ◦ 撤退条件は明確か  • リスクはなにか 
• 先行事例は何と比較したか  • データは反証に耐えることができるか  「ゆっくり考える」チェックリスト

https://soudai.hatenablog.com/entry/5w1h 仮説を補強する情報ばかり集めると確証バイアスに陥り、誤った意思決定につながります。これを避けるため、WhyやWhatを検証するときは反証（falsification）を必ず考えます。   　例をあげるとWhy「売上を伸ばす」、What「新規顧客を増やす」とします。それに対して反証は「売上が伸びないのは顧客単価の低下が主因では？」「新規顧客は増えても解約が悪化していない
か？」などになります。      

組織は意思決定しない    意思決定は人がする  おわりに

おわりに

おわりに引用元『鋼の錬金術師』第41話 

難しいことかもしれない    他人は決めないなら、自分が決めるしかない  おわりに

おわりに引用元『宇宙兄弟』11巻 

本気の失敗をする    失敗が好きになる  おわりに

昨日の自分に誇れる    今日の自分になろう  おわりに

ご清聴ありがとうございました      おわりに

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

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

Resources

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

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

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

Agile Is the Steering Wheel, Not the Gas Pedal

More Decks by soudai sone

Other Decks in Technology

Featured

Transcript