■ 1. 登壇者プロフィール
- 氏名: 曽根 壮大（41歳）
- 所属:
- Have Fun Tech LLC 代表社員
- 株式会社リンケージ CTO 兼 COO
- 著書: 「失敗から学ぶ RDBの正しい歩き方」
- 経歴: 警察官 → 派遣社員 → 社内SE → インフラエンジニア → Webエンジニア → フルスタックエンジニア → CTO（第1期）→ Customer Reliability Engineer → CTO（第2期）→ 独立 → CTO（第3期）→ COO & CTO
■ 2. 失敗できる意思決定
- 意思決定の本質:
- 意思決定に正解はなく 自分で正解にするしかない
- 失敗と成功は二項対立ではなく地続きの世界である
- 正解に近づく仮説を検証して最終的にゴールにたどり着くことが重要
- 意思決定の難しさ:
- ビジネスモデル・要件・法律・技術的制約・組織の状態はすべて変化する
- 継続した成長が求められる中でチャンスは何度も与えられるわけではない
- 致命傷だけは避ける必要がある
- 判断と決断の違い:
- 判断: 情報を集めれば理屈で答えが出せる
- 決断: 情報が揃わない中で答えを出さなければならない
- リーダーがやらなければならないのは決断である
- 標準化による仕組み化:
- インプット・スループット・アウトプットの各ステップを標準化することで決断を判断に変えられる
- 具体的には作業のマニュアル化や受け入れ基準のガイドライン策定が該当する
- 失敗できる意思決定のコツ:
- 失敗できる状態にすることで決断が可能になる
- 素早くアクションして失敗のフィードバックを受け取ることで新しい決断ができる
- 決断のステップ:
- 決断するために必要な条件を整理する
- 決断が難しい場合は素早く始め小さく失敗できるように考える
- 失敗が難しい場合は社内外も含めて多くの知見を集める
- それでも難しい場合は結論をできるだけ先伸ばす
- 仮説検証で重要な3要素:
- 失敗しても致命傷にならない: やり直せる・代替がある・失うリスクに対して許容できる（ビッグバンリプレースはリスクが高く段階的な置き換えやカナリアリリースを検討する）
- 失敗から学ぶことができる: 仮説が観測可能である・結果に対して客観的に分析・判断が可能（「流行っている」は仮説として弱くサンクコストが高くなると失敗を認めづらくなる）
- すぐ試せる: 結果が素早く出る・実行までの投資リソースが少ない・実行後の影響範囲が明確（大きな変化は合意形成に時間がかかり結果が出るまでも時間がかかる）
- 後に変更可能な技術選定の例:
- コンテナ: 実行環境の依存をコンテナで分離することで実行環境を変更できる
- REST: インターフェースの先はバックエンドの分割やフロントの差し替えが可能
- イミュータブルなデータとCQRSアーキテクチャ: 更新と参照の責務を分けつつ変化に追従できる
- 認証と認可の分離: SSOでまとめることで社内システムのIdPを活用できる
■ 3. ゆっくり考えて素早く実行する
- 基本原則:
- 失敗したプロジェクトの共通点は「すばやく考えゆっくり動く」こと（BIG THINGS引用）
- 成功したプロジェクトはいずれも「ゆっくり考えすばやく動く」を徹底している
- プロジェクト期間が長くなるほどブラックスワンが飛び込んでくるリスクが増大する
- 計画と実行の対比:
- 素早く考えてゆっくり実行: 計画（短）→ 実行（長）= 外部起因の影響を受けやすい
- ゆっくり考えて素早く実行: 計画（長）→ 実行（短）= 外部起因の影響が少ない
- 実行フェーズでのブラックスワン発生時の見直しはハイコストだが計画段階での見直しはローコスト
- ゆっくり考えるとは:
- 実行前の計画段階で仮説検証を行いリスクを事前に排除すること
- 参照クラス予測法の活用: 類似事例を参照し複数のデータを元に予測し悲観的に考える（ファットテール分布を想定）
- 反証に耐えられない仮説は基本的にリスクが高い
- ロードマップを分解して大きなリスクを防ぎ小さな成果の積み重ねでゴールになる計画を立てる
- 素早く実行するとは:
- 最初から想定通りに行くわけではなくフィードバックを受け取ったら素早く変化に合わせる
- 「初めて」を極力減らす: 技術の研究・検証とプロダクト開発を同時に行わず別々のプロジェクトにする
- 小さな成果物はコントロールしやすい（WBSは作業分解のTODOリストではなく小さな成果物の定義）
- アジャイルはハンドルであってアクセルではない（素早くフィードバックを獲得して変化に対応する）
- 学習ループ:
- シングルループ: 実行結果をもとに行動を変える
- ダブルループ: 結果から前提を変えて根本から変更する
- 素早く実行するために必要な技術:
- テスト・オブザーバビリティ・CI/CDはコアコンピタンスである
- マイクロサービスは小さく実行するためのhowの一つに過ぎずモノリスなシステムでも交換可能であれば良い
■ 4. Simple is Beautiful
- SimpleとEasyの違い:
- 「難しい」には「理解できないから難しい」（知識を積めば解決できる）と「構造に無理があるから難しい」（根本的な改善が必要）の2種類がある
- この違いを理解しないとEasyとSimpleの違いが見抜けない
- SimpleとEasyは両立する
- Small is beautiful（UNIX哲学）:
- 小さなプログラムはわかりやすい
- 小さなプログラムは保守しやすい
- 小さなプログラムはシステムリソースに優しい
- 小さなプログラムは他のツールと組み合わせやすい
- シンプルであることの利点:
- 小さくシンプルな方が仮説検証しやすい（変数は少ないほうが仮説検証しやすく原則はOne change at a time）
- 最小構成のWBSがマイルストーンになる
- 小さなリリースの積み重ねが大きなプロダクトになっていく
- 意思決定との関係:
- 意思決定の選択に悩んだら小さくてシンプルになる選択肢を選ぶ
- ゆっくり考えることと意思決定できないことは違う
- 仮説を意思決定して実行するために小さくシンプルになるまで考えること
■ 5. おわりに
- 「ゆっくり考える」チェックリスト:
- 5Wをしっかりと整理する（WhyとWhatが方向性を決める・ユーザー/業務の「困りごと」は具体的か・撤退条件は明確か）
- リスクは何か
- 先行事例は何と比較したか
- データは反証に耐えることができるか
- 確証バイアスへの注意:
- 仮説を補強する情報ばかり集めると確証バイアスに陥り誤った意思決定につながる
- WhyやWhatを検証するときは反証（falsification）を必ず考える
- 例: Why「売上を伸ばす」What「新規顧客を増やす」に対する反証は「売上が伸びないのは顧客単価の低下が主因では？」「新規顧客は増えても解約が悪化していないか？」
- 組織と個人の意思決定:
- 組織は意思決定しない
- 意思決定は人がする
- 他人が決めないなら自分が決めるしかない
- 本気の失敗の価値:
- 本気の失敗をすることで失敗が好きになる
- 昨日の自分に誇れる今日の自分になることが重要