ソフトウェア開発者のキャリアハンドブック ―キャリアの不確実性を進み続けるためのガイド

23章暗黙の役割

あなたが今、自身初めてのスタートアップを経営しているとしよう。これまで2回のレイオフを行い、近いうちの3回目も控えているとする。業績を回復させるべく、新たにエンジニアリング担当のバイスプレジデントも雇い入れていてはいたが、そもそもテック企業を取り巻く経済状況が壊滅的に悪化していることもあり、やれることは限られている。まずは船が沈まないよう、乗っている人間をできるだけ減らすしかない。

いよいよ3回目の（そして最後の）レイオフである。今の3人のディレクターは、最初のバイスプレジデントとともに最初のレイオフを実施し、その後、暫定のバイスプレジデント（営業開発を担当していた人だった。初回とは事情がまったく違った）とともに2回目も実施した。どちらも、経営陣が最新の数字を確認した翌日の緊急ミーティングから始まった。

まずディレクターたちにこんな指示が出される。「余分な仕事をさせて申し訳ないが、君のチームの人員がそれぞれ現行のプロジェクトにどのような貢献をしているかを文書化してくれないか。少し時間がかかってもいいから」

24時間が経過する頃、経営陣が皆ディレクターたちに言う。「そろそろできたかな？」

時間がかかってもいいという話では？

「いや、今から1時間以内に文書が欲しい。重要なことなんだ」

皆、即座に作業を開始する。

それから4週間で社員1人1人に関する情報を満載した3枚のスプレッドシートが作られた。それを見ればチームにどのような人間がいて、それぞれにどのような能力を持っているのか、どのような製品を開発しているのか、個々の製品が業績にどれだけ貢献しているのかがわかる。

しかし、3枚のスプレッドシートの情報には偏りがあった。3人のディレクターはそれぞれ、自分のチームの人間を残そうとしてスプレッドシートを作ったからだ。なぜ自分のチームの人員は残る必要があるか、その証拠となるような情報ばかりを懸命に集めたのだ。企業の生き残りのための戦略を立てるという目的には合致しない文書が作られてしまったわけだ。ただ、初回と2回目のレイオフでも同じことが起きたので、経営陣はもはやどのような文書ができるかをあらかじめ予測していた。 ...