OKRが防ぐイマイチ管理

イマイチ管理を挙げて、OKRの良さを炙り出す

• 細部こだわりアンバランス
  • 「メインほったらかして細部こだわっちゃった…」
• あらぬ方向全速力
  • 「気づいたら変なとこに…」
• 頭パンパンぜんぶぽーい
  • 「考えることがありすぎてフリーズしたった」
• 言葉にできない神プラン
  • 「こう…頭の中にはあるんすよ、全体像が」
• 完璧プラン使われない
  • 「あぁ、綺麗なやつ作りましたね、どこだっけ」

行き先と主要目標の簡易リスト、その定期利用

O

目標/objective
価値があり優先度が高く目指すべき到達点・状態のこと

objをガンガン達成してけば大成功

到達点や状態を示す表現を使用します。

組織は優先度の高い目標に集中的に取り組めるようになります。

目標は 3～5 個に絞ります。目標が多すぎるとチームにとって過度な負担になり、気が散って集中できなくなることがあります。

チームやその顧客が本当に必要としていることを目標にする

目標の価値が低い - OKR では、明確なビジネス上の価値を示すことが不可欠です。そうでなければ、目標達成に向けてリソースを投入する必要はありません。目標の価値が低いと、たとえそれが完全に達成されたとしても組織に大きな違いは生まれません。

OKR はチェックリストではありません。チームがこの四半期に取り組むべき事項の一覧ではないのです。

現実逃避の様式

成功は全てを癒す、ずっと上手くいかないのは辛い。
なので人間はしばしば壊れる。
その様式を列挙して壊れを検出できるように備えよう。
自分の陥りやすい壊れ方を把握して補正しよう。

• 意思疎通困難
  • 支離滅裂
  • 無言
• 細部への拘泥 = 全体像の無視
• 確率誤認
  • 希望的観測
  • 悲観的観測
  • 多段予想 (積認知困難特性との絡み)
• フリーズ
• 計画依存 = 実行放棄
• 実行依存 = 計画放棄
• 完璧主義
• 脇道逸れ

電撃戦の背景と狙い

背景: 前線で総力戦
狙い: 新兵力を最大投入した機動戦

背景: 塹壕と総力戦

WW I の塹壕戦。
難攻の前線塹壕、攻め落としても無限に補給される予備兵、敵に地形がバレバレな占領塹壕。
全勢力を前線へ向けて注ぎ込み物量で勝つ思想な時代。

機動戦的な戦術として浸透戦術があったが、あくまで点突破&混乱を軸とした塹壕地区攻略の戦術。
地区は取れても戦略的な旨味が小さかった。

狙い: 超火力浸透戦術

前線に全力なら、前線を超え切って後衛の戦略拠点をぶっ叩けばいい。それだけ。

機動戦が出来る部隊を並べて前線の一部を食いちぎる、そこに機動戦が出来るランドパワーをぶつけて前線を越え切る、スカスカの後衛にある戦略拠点をぶっ叩く。
あとは有利状況を活かして殲滅戦するか講和するか.

航空優勢を気合で取り、航空爆撃・空挺で地上前線のぬるい防衛拠点を破壊する。
弱った前線に機甲部隊をぶつけてその部分を突破、その機動力で縦深し、戦略拠点 (schwerpunkt) を撃滅。
指揮と補給を失った敵を包囲殲滅したり、そのまま首都を攻めたりして機動優勢を戦況優勢に変える。

前線総力な時代 (そうしないと塹壕が持たないと考えられてた時代) なので、一度食い破れば手薄な後衛で足を生かせたのが成功の背景にある。
マジノ線は戦術目的を達成していたけど、避けられる上に後衛が手薄になる点が戦略レベルでの弱点。
電撃戦はその弱点を狙う戦略なのでフランスは負けた。

TypeScriptのArrayはRecord<number, _>型です。

配列がRecord型…という思わぬ罠になる時があるので注意.

例

type N2S = Record<number, string>;

// No error. Both are valid.  
const obj: N2S = { 0: "hello" };
const ary: N2S = ["hello"];

// Reasonable
const obj1 = obj[0];
const ary1 = ary[0];

要素へのアクセスにはdot記法（obj.0）とブラケット記法（obj[0]）がある。
要素名がNumberのときdot記法が禁じられているため、配列は一切のdot記法が利用できない。
でも意味論として確かにRecord<number, _>になっている（ブラケット記法がその証拠）.

罠

ハマったことのある罠（普通は起きない）.

要素削除

// array
const ary = ["hello", "world", "!!"];
delete ary[1];
JSON.stringify(ary); // '["hello",null,"!!"]'

// object
const obj = {0:"hello", 1:"world", 2:"!!"};
delete obj[1];
JSON.stringify(obj); // '{"0":"hello","2":"!!"}'

配列だと要素削除はnull化だが、オブジェクトだとattributeの存在が消える.
Immerとかの関係でdeleteを使う際に注意.

Rustの思想

「最大速を出せる最大の安全性・抽象化」

静的な仕組みで安全性・高抽象度を求めることで動的なオーバーヘッドを0にしつつ上を目指す.

メモリ管理は動的GCでなく静的な所有権モデル.
動的ディスパッチじゃなくてX.

プログラミング: 所有権と借用

要件: free memory Just Once
0回だとメモリリーク、2回以上もダメ.

1人の所有者を決めて、その人が一元管理→所有権
スコープの概念を用いてdrop場所を静的解析できる→実行前にfreeのコードを埋め込み

毎回所有権を取り回してると分岐に弱くなる→借用

所有者は1人

理由: 2重解放の防止

所有者が2人でそれぞれがfreeするとそれだけで二重解放
変数代入をmoveじゃなくてポインタコピーとして扱うだけで発生.

メモリ管理をどの段階で仕込むか

1. マニュアルメモリ割り当て: コーディング時
2. 所有権/借用チェッカー: コンパイル時
3. GC: 実行時

mallocとfreeは必ず実行される。性能差無し.
1と2はfreeタイミングを設計可能、理想的なGCは完璧なタイミングでfreeするので時系列メモリ消費量差なし.
1と2はfree差し込みが静的 (実行前) 、3は動的。動的判断が必要なので必ずオーバーヘッド発生.