太平洋戦争開戦の仕組み

以下が悪魔合体して開戦した

• 倍プッシュ: 負けそうになったら掛金倍増で延長戦
• 短期思考: 目の前の問題を解く
• 分権政治: 互いの特権を取り引きして目標達成
• 多忙: 資源不足で忙しい

分権構造なので複雑な目標を達成するには他の特権者と取引する必要がある。だから内部政治のコストが高くつく。
目の前の課題解決を優先して長期の青地図は重視しない。なので視野が狭くなりがち。
資源不足で多忙なため、見落としがちょいちょい発生する。

これにより、各アクターがそれぞれの意図で取引して目の前の課題に取り組むことになる。
このやり方は全体の行き先が思わぬものになりがちであり (=局所最適)、かつ多忙なのでそれを見落としがち。
そのためマズい 1-way door をちょこちょこ開けてしまう。

ここまではまだいい。挽回のために出直せばいいから。
しかし倍プッシュ精神と悪魔合体するとマズい。出直さず今の状態を維持しつつデカい目標を掲げてデカく取り返そうとする。デカい目標は青地図と無関係なので結局デカい目の前の目標を追うことになる。
でもまた同じ構図でマズい 1-way door を開き、破綻するまでエスカレーションし続ける。

The デザイン「気持ちよく探求し続ける方法論を気持ちよく探求し続ける」

好奇心
現物主義
構造化への喜び

→ 知識欲を満たすことを最大の喜びとしつつ、自然に現物での検証や創造に手をつける。知識に関しては整理したがる。
「真理の探求」

→ 未知への戦略を立てるのに向いた性質。負荷なくこれが出来うる。
今の好奇心の対象をじーっと見て、対象の真理や理想像に対する戦略を立てる癖を付ければ、有用だしハッピー。

欲望: 気持ちよく探求し続けたい
（「なぜ真理の探求がしたいのか」は問わない。感覚的にこれが根源的感情。過剰分割しても personal history を掘ることになるだけそう）

30年生きてきた経験則として、この欲望の実現は相当に難易度が高い。
だからこの欲望を満たす方法論をデザインする。

戦略:『気持ちよく探求し続ける方法論を気持ちよく探求し続ける』ブートストラップ

方法論は環境に依存するし、不完全な人間が設計するので常に不完全。
となると取れる方向性がいくつかに絞られる：

• 設計しない
• 設計する
  • 出来うる限り厳密に設計する
  • 設計し直しまくる

「設計し直しまくる」は「探求」の一種と言える。だからブートストラップが可能。
これを最上位戦略に設定しておけば欲望が自然と満たされていく（欲望が戦略立案実行を求め、戦略立案実行が欲望を下支えし、滾る欲望がさらなる戦略を...）

飽きなどから「探求とは感じるが、あまり気持ちよくないな…」も全然有り得る。
成功を欲望に置いていないので、この際はスッパリ諦めれば良い。

戦略を描き慣れる

戦略の欠如、あるいは戦略案への拘泥。
真逆に見えるこれら戦略上の失敗、実は同根である。
根本原因は「戦略を描き慣れていない」ことにある。

戦略を描き慣れていないから、そもそもマトモな戦略を立てない。
戦略を描き慣れていないから、思い入れのある戦略案に拘泥してしまう。
どちらも経験不足、描き慣れてないがゆえの過ちである。
これは戦略に関わらず万事で起きる失敗であり、それが戦略レベルでも起こっただけ。経験が無ければ運用が歪むのは当たり前なのである。

解決策はシンプルで、手癖で戦略を描きあたりまえに更新・修正する習慣を付ければいい。日々戦略を立てて回して経験値を積むしかない。

負けパターン: 大敗するまで勝ち続ける

ギャンブル、戦争、政治、ビジネス。どこにでも見られるパターン

集団の内実: 思想家と活動家

集団の中身は一様でない。

思想家: 集団が掲げる思想を元々心に持ち、思想の実現のために集団に加わっている人達
活動家: 集団に属し集団の正義を為すこと自体を目的として集団に加わってる人達

思想家は思想を常に見つめている。
思想に疑義が生じた場合、思想を取り下げるか、盲信して過激派に進化する。

活動家は集団そのものを常に見つめている。
思想がブレても大して気にしないが、集団がブレることを恐れる。集団が落ち目になると次の集団へ引っ越していく。

道具ではなく利用者の責任

責任は道具に無い。利用者にある。

記者会見で「委託会社が〜」という説明がしばしばあり、評判が悪い。
これは道具への責任転嫁に聞こえるから悪い印象に繋がってる。委託すると決めたのは自社であり、委託会社の制御や納品検査は自社マターである。委託は道具の一種なので、利用者たる自社に責任がある。だから上記の言い訳は責任転嫁に見える。

FastAPI 並行処理のキホン

デフォルト設定の場合、シングルプロセス。
なので non-parallel concurrent になる。

path op を def で定義した場合、thread pool に突っ込まれる。ブロッキング I/O をスレッド切り替えで逃がせるのでこれは合理的な設計。とはいえ Python の GIL がデフォルトで 5 msec 掴み続けるので、小さなブロッキングが発生してしまう。CPUリソースの意味でもスレッド切り替えコストが掛かってる。

なので async I/O 化してシングルスレッドで回すのが1番効率が良い。ゆえに path op を async def で定義した場合、単純に call される (thread pool 使わない)。