マイケル・ワトキンスの The First 90 Days。原題が示す通り、メッセージはシンプルです — 新しい役割を担ってから最初の90日が、その後のすべてを決めます。
#1年前 — 転職が決まったとき
本自体は以前から持っていましたが、ちゃんと読んだのは1年前、転職が決まった直後でした。退職旅行のニューヨーク行きフライトで一気に読み切りました。新しい会社に入ると「自分が採用された理由」を証明しなければという焦りから、早く成果を出したくなります。しかし本は、最初の30日は学習に集中しろと言っています。
前職での成功は、自分の努力や実力もありますが、見えないところで支えてくれたものの方がはるかに大きかったはずです。長い時間をかけて同僚と築いた信頼関係、組織の文脈への理解、暗黙的に共有されていた前提知識 — それらがあったからこそ実現できたことでした。新しい会社では、それがすべてゼロになります。自分自身は同じ人間ですが、周りの環境はまったく違います。最初の30日を学習に充てるべき理由は、まさにここにあります。
新しい会社に入ると、すぐに目に見える成果を出したくなります。でもそれ以上に大事なのは、意思決定の構造、チーム間の力学、表に出てこないコンテキストを掴むことです。技術的なキャッチアップはドキュメントを読めばある程度できますが、コンテキストは人と話さないと見えてきません。自分は最初の1ヶ月間、できる限り多くの人と1on1を設定し、コードより先に人とプロセスを理解することに時間を使いました。遠回りに見えましたが、その後のスピードを生んだのは間違いなくこの時間でした。
転職直後は、早く認めてもらいたいという誘惑もあります。しかし組織をまだ理解していない状態で大きな変化を仕掛けると、抵抗を生むだけです。本が言う「アーリーウィン（Early Win）」は、だからこそ小さなところから始めろという話です。自分の場合は、既存メンバーが暗黙知で手際よくこなしていたCSの対応フローを追いかけながらドキュメント化しました。大したことではありませんが、自分の学習にもなりましたし、ドキュメント化そのものが目に見える成果になりました。小さな変化を積み重ねると、自分が適応できているという実感が湧いてきて、周囲からの信頼も蓄積されていきます。それが後にもっと大きな変化を起こすための土台になります。
#最近 — リーダーになった同僚に薦めて
最近リーダーを任された同僚に薦めるために、本をもう一度開きました。1年前とは違う箇所が目に留まりました。
初めてリーダーシップを担うとき、陥りやすい罠があります。「自分が得意なことを、もっと頑張る」です。開発が得意だからリーダーになった。だからコードレビューをより丁寧にやって、アーキテクチャの意思決定にもっと深く関与する。転職時に早く結果を見せたいと思う心理と似ています。ここでも本は同じことを言っています。
昇進した人が最初にすべきことは、前の役割で成功をもたらした行動をやめることだ。
リーダーの仕事は、自分が得意なことをやることではなく、チームがうまくいく環境を作ることです。この切り替えができないと、簡単にマイクロマネージャーになってしまいます。本人は一生懸命やっているのに、チームはかえって動けなくなる。自分が初めてリーダーになったとき受けたフィードバックもまったく同じでした — 君個人のスキルはもう重要じゃない。他のメンバーが活躍できるようにすることが重要だ、と。
STARSモデルも今回改めて目に入りました。自分が率いる組織が今どんな状態にあるのかを、まず診断せよというフレームワークです。
| 状態 | 説明 | リーダーの役割 |
|---|---|---|
| Start-up | ゼロから立ち上げるフェーズ | 素早い実行、チーム組成 |
| Turnaround | 危機を立て直すフェーズ | 問題の診断、方向転換 |
| Accelerated growth | 成長を加速させるフェーズ | 仕組み化、プロセス整備 |
| Realignment | 方向を再調整するフェーズ | 危機意識の共有、変革の推進 |
| Sustaining success | 成功を維持するフェーズ | イノベーション維持、現状安住防止 |
同じ「リーダー」でも、スタートアップ初期のチームを率いるのと安定したチームを維持するのとでは、まったく異なる戦略が求められます。危機的なチームに安定期の戦略を当てはめれば失敗しますし、その逆も同様です。まず診断する。そこに合わせる。
#役割が変わるたびに手に取る本
転職のときは「まず聞いて、学べ」に線を引きました。リーダーの視点で読んだときは「前の役割の成功パターンを手放せ」に線を引きました。次にこの本を開くときには、また別の場所に線を引いているはずです。