失敗できる意思決定とソフトウェアとの正しい歩き方¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
意思決定に絶対の正解はなく、自分たちで正解にしていくしかないという前提から、失敗できる意思決定を設計する重要性を説く資料。 判断は情報を集めれば理屈で答えが出せるもの、決断は情報が不足していても選ばなければならないもの。 リーダーが担うのは決断であり、そのためには致命傷を避け、小さく試し、観測可能な仮説検証サイクルに落とす必要がある。
本文¶
資料は「意思決定に正解はない」から始まる。 失敗と成功は対ではなく地続きで、最初の仮説は多くの場合間違う。 重要なのは最初から正解を引くことではなく、ゴールに近づく仮説検証を回すこと。
意思決定が難しい理由として、ビジネスモデル、要件、法律、技術制約、組織状態、既存技術 stack が変化することが挙げられる。 今うまくいっても将来うまくいく保証はなく、未来予測は難しい。 一方でチャンスは何度もあるわけではないため、致命傷は避ける必要がある。
資料では、判断と決断を分ける。 判断は、情報を集めれば理屈で答えが出せるもの。 決断は、十分な情報を集められない中で答えを出さなければならないもの。 リーダーがやるべきなのは決断。
判断にできるものは、input、throughput、output の各段階を標準化することで判断に落とし込める。 作業マニュアル、受け入れ基準、品質の固定化などが例。 判断にできる仕組みを作ることは、意思決定者の腕の見せ所。
決断のコツは、失敗できる状態を作ること。 具体的には、必要条件を整理し、難しいなら素早く始めて小さく失敗できるようにし、失敗が難しいなら知見を集め、それでも難しいなら結論を先延ばしする。
失敗できる仮説検証には条件がある。
- 失敗しても致命傷にならない
- やり直せる
- 代替がある
- 失うリスクが許容できる
- 仮説が観測可能である
- 結果を客観的に分析できる
- すぐ試せる
- 実行後の影響範囲が明確である
技術選定でも、後から変更できる設計が重要。 コンテナで実行環境依存を分離する、REST で interface の先を変えられるようにする、CQRS で更新と参照を分ける、認証と認可を分離し IdP を活用する、などが例として挙げられている。
要点¶
- 正解を探すより、ゴールへ近づく仮説検証が大事。
- 判断と決断を分け、判断にできるものは仕組み化する。
- 決断は失敗できる形に設計すると行いやすい。
- Big bang replacement は失敗しにくく学びにくいので危険。
- 技術選定は可逆性と観測可能性を意識する。