「その仕事、全部やめてみよう」を読んだ
著者である小野さんは、起業したベンチャーを老舗金融起業に売却してその老舗企業でCTOを務めた人物である。私が現在、所属している企業と似たような状況にあるのではないか？と予想して読んでみた所、示唆に富んでいるところが多々あったので、久しぶりにブログにメモを残しておく。
第１章「谷」を埋めるな、「山」を作れ
特にベンチャーにおいては、競合他社がすでに実現している機能を実装するのに時間を費やすのではなく、自分たちの特色となる「山」に時間を費やすのが大事
コンサルを入れて実績のある方法論を導入して失敗するチームもある。
第２章「ハンマーと釘」の世界の落とし穴
新しい技術が日々生まれ、私たちエンジニアは「手にしたハンマーで釘を打ってみたい」衝動にかられながら仕事をしている。
とある企業のプロジェクトでは、新技術が出るたびに「新技術で既存の製品を作り替える」ということを繰り返していた。「新技術が出たからといってむやみに使わない」をチームの方針として周知徹底した。
「これから来そうだという技術は習得しておき、使うべきときがくるまでは無理して使わないように」という号令を出した。
ダメなアイデアが生まれる５つのパターン
- プレッシャーを受けて無理やり考えるとき
- 役職者の思いつきを取り入れるとき (的外れかどうかを吟味していない)
- 変に差別化しようとする (差別化を目的にする)
- 流行に安易に寄せるとき
- 「この機能が追加されれば大型案件がとれる」というとき
ベンチャー企業と老舗企業をつなぐバイモーダル戦略
２つのモードをうまく活かし合いながら、切磋琢磨する
- モード１: 失敗が許されない領域に適した安定性重視
- モード２: 時代の変化にいち早く対応するスピード重視
稟議書を見直す２つのタイミング
うまくいっておらず、うまくいかないことが見えているのに計画が立てられているからといってそのまま進めるべきではない。リセットボタンを押すしかない。どういう時か
- ぜんぜんうまくいっていないとき
- 外敵要因が変わったとき（業界にイノベーションが起きた、など)
会社は大きくすべきか？
「スパン・オブ・コントロール」（人員適正範囲）を超えているなら大きくすべきではない。
第３章「ラストマン戦略」で頭角を表せ
「ラストマン戦略」とは、グループ内で自分が一番になれそうな領域を決め、最後の砦とも言うべきスペシャリストを目指す成長戦略。
領域は、最初は一つのツールや技術といった小さなものからスタートして良いし、一番を目指す範囲は最初は所属チームのような小さな範囲からで良い。そこから徐々に大きくしていく。
全ての要素について満点を目指すの止め、代わりに特定分野では満点のさらに上を目指していく。
マニュアルにとらわれず、むしろマニュアルがないことにこそ取り組む
いろいろなエンジニアのタイプがいる。同じタイプのエンジニアを集めるよりもいろいろなタイプのエンジニアを集めるのが良い。他人の劣っている能力ではなく、優れた能力に目を向ける。
戦略的に「見せ場」「強み」を見せる。信頼残高を増やしていく。
第４章 「To Stop リスト」を作る
To Stop リストを作る３つのタイミング
- 何かを新しく始めるとき
- 忙しすぎて業務が回らなくなってきているとき
- 非効率な仕事が増えてきているとき
To Stop リストに加える５つのこと
- 定例会議
- 引き継がれた業務 (そのままで良いのか見直す）
- 手作業のデータ集計・資料作成業務
- 社内向けに提供しているシステムやサービスで利用者の少ないもの
- 事故の再発防止策を重ねた結果、慎重になりすぎているもの
パフォーマンスを高めるために力を抜く
- 常に全力疾走すれば、パフォーマンスはかならず落ちる
第５章 職場は「猛獣園」である
人を傷つけずに、問題点を指摘する ー「ひよコード」
- 優しく言う（語尾）
- 自分が過去に同じミスをした話から入る
- 相手に敬意を払う
人を動かすコツは、相手を全力で理解すること
- 「相手の言い分」を徹底的に受け止めてから、話をする
「俺がやったほうが早い病」の直しかた
- 俺がほめたほうが早い
- 俺が教えたほうが早い
- 俺が見本を見せたほうが早い
マネージャータイプも二つある。自分がリーダーシップ型を目指しているからと言って、調整型マネージャーが劣っているわけではないし、その逆もしかり。フェーズと場面によって必要がタイプが異なる。
「ファインプレー」を称え合う
感想
私（そのっつ）は、バイモーダル戦略、エンジニア風林火山、２つのマネージャータイプ、と全部を高水準でやろうと思っていたので、自分のスタンスをもう少し偏らせて、別のタイプは別のメンバーを頼るようにするのも良いかもしれないと、本書を読んで思い始めた。
自分と同じタイプのエンジニアだけを集めると自分のコピーのようなチームになるだけなので、もっと多様性をもたせて、自分ができないこともできるようなチームにしていくことを考えたいと思い始めた。自分とタイプが違うメンバーを育てるのは難しそうだが、チャレンジしてみる価値はありそうだ。
