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

by soudai sone

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

失敗できる意思決定

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

SimpleとEasyは違う      Simple is Beautiful 

Slide 69

Slide 69 text

Simple is Beautiful

Slide 70

Slide 70 text

Simple is Beautiful

Slide 71

Slide 71 text

SimpleとEasyは両立する      Simple is Beautiful

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

おわりに

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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