『小さなチーム、大きな仕事』読んだ
Ruby on Rails開発者DHHの本。タイトル通り、いかにチームを小さく保ちつつ仕事の成果を最大化させるかについて、サービス・事業と組織の両面から述べられている。
全体的な感想としては、スタートアップで資金調達をしながら急成長を目指すものとは反対の思想が多く、新鮮だった。特に人を雇う観点で顕著だった。ただ、スタートアップにおいても人を雇うことは人数を増やすことが目的ではない。より難しい課題を、より早く解決するために採用している。逆にいうと、それが達成されない新規の採用に意味はない。むしろコストを増やし、生産性を落として従業員のエンゲージメントに悪影響を与えている分マイナスでしかない。
予算があったとしても、本当にそれは採用の手段でしか解決できないのか？と自問自答しつづけたいと思った。
以下、気になったポイントのメモと感想
初めのうちは詳細を気にしない
デザインする時、普通のペンではあまりに細かすぎてまだ気にしなくていい細部を気にしてしまうから、太線のマーカーを使うという話。
複数人で議論をしていると、今はまだ気にする必要のない具体レイヤーの話に入りこんでしまい、時間を無駄にしてしまうといった経験は誰しも心当たりがあると思う。具体レイヤーに話がいかないよう、ここでいう太線マーカーのように具体の話にいかないための仕組みが作れたらいいなと思いつつ、ぱっと妙案は思いつかなかった。
決断することで前に進む
決断をしないと、仕事は山積みになる。「考えよう」ではなく「決断しよう」と思おう。問題が起こるのは、後に完璧な答えが得られると期待して決断を先延ばしにする時。完璧な答えは待っててもこない。明日決断するも今日決断するも同じ。という話。
直近、自分の仕事における意思決定の比重が大きくなっており、スピード感のある仕事ができていない実感がある。今現在まさに向き合っている課題でいうと、開発組織の体制をチームトポロジーベースでやっていくぞという大枠の方針はCTO含め合意してはいるが、各チームにどんなミッションを持たせるのか、チーム間インタラクションの定義をどうするか等具体レイヤーの話は事業や組織の変数が多く、またうまくいかなかった時に「やっぱりやめます！」がしづらいので、慎重になってしまっている。
、、、という言い訳をしている自分に刺さりまくる章だった。決断していくぞ。
まずは自分から
自分がやったことある仕事なら、他の人に任せてもマネジメントできる。いつ注意し、いつサポートすればいいかが分かる。だから、畑違いであってもまずは自分でやってみて雇うかどうかを決めよう。という話。
内容としては100%同意。ただ現実問題として、新しいケイパビリティを獲得する手段として「まず自分でやる→どうしても無理なら採用」という手順を毎回踏めるほど時間的余裕があるわけではない。初手から採用する選択をし、自分がやったことのないポジションのマネジメントを今年は経験した。
とはいえ、目先の忙しさ解消や未来への投資という名目においても安易に人を増やす選択をしがちな場面は多いのも事実。まずは自分含めた今いるメンバーでなんとかならないか？という発想を持つようにしたい。
会社を、「知人のいないパーティー」にしない
知人のいないパーティーは、退屈だし、当たり障りのない会話に終始してしまう。しかし、気心知れた友人だけのパーティーでは面白い話や熱い議論が生まれる。短期間で人を雇いすぎると知人のいないパーティーになってしまいがち。ゆっくり採用しよう。という話。
これはめちゃくちゃ分かる。組織の熱量や文化みたいなものは、今いるメンバーの関係性の深さや積み上げてきた歴史が作っている。短期で人が増えるとその歴史が薄まってしまう。
とはいえこれも、急成長を目指すのであればそうも言ってられない場面はある。人を増やしつつも「知人のいないパーティー」にしないを両立させる。難易度は高いが向き合っていきたい。
文章力のある人を雇う
文章がはっきりしているということは、思考がはっきりしているということ。文章力があるとこはそれ以上の多くを持っている。という話。
100%同意。組織でパフォーマンスが高い人は、みな総じて文章がうまい。1人で圧倒的な成果を出すが言語化は得意でないタイプの人は一定数いると思うが、自分の考えを他者にうまく伝えられないと組織全体のパフォーマンスは上がらない。
逆にいうと、自分含めすでに組織内にいる人には、文章がうまくなってほしいと思う。文章がうまくなり、テキストコミュニケーションの効率が上がることによる生産性の向上は測り知れない。