2025-08-21

AIがもたらす週80時間労働と996とは

AI時代のエンジニアとして、いかに生き残るか。その答えを模索する中で、ひとつの重要な視点が見えてきました。

AI時代は“短距離走”より、3〜5年の時間軸で適応した人と組織が勝つ、ということです。

Agentic AIがもたらす働き方の逆説

Agentic AIの登場により、働き方に大きな変化が起きています。興味深いことに、海外のAIスタートアップでは「996」（午前9時から午後9時まで週6日働く）という働き方が再び注目を集めています。

AIは人間の労働を軽減するはずでした。皮肉なことに、現実は違います。

Devinを提供するCognition社CEOのScott Wu氏は、こう述べています。

「私たちは週末もオフィスにいることが日常的で、夜遅くまで最高の仕事をすることもあります。多くの社員が文字通り職場に住んでいます」

People have asked about our culture and recent employee communications. Cognition has an extreme performance culture, and we’re upfront about this in hiring so there are no surprises later. We routinely are at the office through the weekend and do some of our best work late into…
— Scott Wu (@ScottWu46) 2025年8月5日

さらにWindsurfの買収においても、従業員は週6日出社し、80時間を超える勤務時間をこなすことが求められていると報道されています。

8時間×5日=40時間ですから、13時間×6日=78時間でもまだ80時間には到達しません。

なぜ今、AIスタートアップは「働き方改革」に逆行するのか

この一見矛盾した状況には、明確な理由があります。

今がまさに、AIという新しい世界の「覇権」を決める重要な時期だからです。AGI（汎用人工知能）開発競争の最前線では、デファクトスタンダードを確立した企業が次の時代を支配することになります。

ChatGPTがLLMによる革命を起こして以降も、AGIはまだ発展途上です。実装力では一般的なエンジニアを凌駕しつつも、細部のミスや設計力の課題は残っています。この「まだ完璧ではない」状況こそが、激しい開発競争を生んでいるのです。

スピードこそが生存戦略なのか？

エンジニアなら誰もが知っています。長時間労働は生産性を下げ、燃え尽き症候群を招くことを。それでもAIスタートアップが猛スピードで開発を進める理由は明確です。

彼らは、AI時代の勝者になるには「スピードがすべて」だと考えているからです。

いかに早く実用的なAI製品を市場に投入できるか。この競争に勝った企業が、次の時代のスタンダードを作る、そう信じて、限界まで働いているのです。

AIに任せればいいのでは？　しかし、AIにはできないから人間がやるのです。

しかし、「スピードのために長時間労働する」これが唯一の道なのでしょうか？

別の道：「適応」という選択肢

2025年8月21日現在、AnthropicのClaude CodeがTeam/Enterpriseプランで利用可能になりました。

私がVPoEを務めるHRBrainでは、この発表に先立ち、社内メンバーへの提供準備を進めてきました。Agentic AIがしのぎを削る現在の状況は、必ずすべてのプロダクト開発企業にClaude Codeが波及すると確信していたからです。

Claude Codeのようなツールは、エンジニアの仕事を根本から変えました。これまで設計に多くの時間を費やし、頭の中のコードをそのまま実装していた作業が、驚くほど高速化されています。

以前ならWebサイトを開発し公開するのに数日という時間を要していましたが、今ならClaude Codeに構成を伝えNetlifyにデプロイするまで1時間程度で済みます。

設計さえ終わっていれば実装は分単位で終わるようになったからです。

頭の中で設計するという本質は変わりません。しかし、設計をコードや実行に落とし込む時間は確実に短縮され、設計を壁打ちする相手も人間からAIに変わってきています。

AIは人間の能力を底上げするのではなく、あくまでも「そもそもできる人の力をより引き出すもの」に過ぎません。

なぜなら、AIがあろうと知らない知識は活かしようがないためです。

ですから、元々コードを書けない人が「書けるようになった」と錯覚するような間違いも起きてはいます。

AIは頭の中にあるものをより素早く具体的に出力できるツールに過ぎません。考えの範疇にないものは出力しようがないからです。

情熱と持続可能性のバランス

かつてゲーム会社で働いていた頃、机の下に寝袋を敷いたり、会議室で椅子を組み合わせて寝ることは当たり前でした。それだけの時間と情熱を費やしてゲームを創っていたからです。

しかし今、この働き方を続けることは現実的ではありません。そして、それは必ずしも必要ではないのかもしれません。

AIを活用する企業にとって重要なのは「996」を推奨することではなく、AIツールを正しく活用することで、より効率的に、より創造的に働く方法を見つけることです。

見据える時間軸を伸ばす：本当の生存戦略

インターネット黎明期、スマートフォンの登場。私たちは幾度となく技術革新の波を経験してきました。そして今、AI時代という新たな激動期を迎えています。

ここで重要な気づきがあります。この変化にどう対応するかは、AIに聞いても答えは返ってこないということです。

必要なのは、人間の経験と洞察力。いかに先を読み、備えるか。その判断力こそが、AI時代を生き抜く最大の武器となります。

見据えるべき時間軸は半年といった短さではありません。最低でも1年半後、できれば3〜5年先を見据えて物事を考えていくべきです。

見据えている時間軸が短くなると、プロダクトだけではなく組織に影響がでます。目の前のことだけに集中するだけでは前進はできても、いつの間にかプロダクトも組織も変化に追従できなくなります。

見据える時間軸は油断するとすぐに近視眼的になります。直近の問題を解決し続けるのは「fire-fighting mode」とも呼ばれ英雄視されることでもあります。故に、意識的に長期的に物事を見据える訓練を積まなければならないのです。

エンジニアとしての新しい価値

AIを恐れるのではなく、正しく理解し、活用する道を選ぶ。これが今、エンジニアに求められている姿勢です。

Claude Codeのような最新のAgentic AIを積極的に導入し、変化の最前線に立つことで、新しい価値を創造していける。そんなエンジニアだけが、この激動の時代を生き抜けるでしょう。

求められているのは、長時間働くエンジニアではありません。AIと共に進化し、より高い価値を生み出せるエンジニアです。

変化の先にあるもの

変化を恐れず、むしろチャンスと捉える。そんな時代が到来しています。

AIスタートアップの極端な働き方を見て、不安を感じるかもしれません。しかし、それは一つの選択肢に過ぎません。

私たちには別の道があります。AIを味方につけ、より賢く働く道が。

長期的な視点を持ち、技術の本質を理解し、人間にしかできない価値創造に集中する。これこそが、AI時代を生き抜くための真の戦略だと考えています。

時代の変化は加速していますが、焦る必要はありません。大切なのは、3年後、5年後の自分がどこにいたいかを明確にし、そこに向かって着実に歩みを進めることです。

とはいえ、ゆっくりしている余裕もないでしょう。AIと共存する未来は、もう始まっているからです。

2024-12-23

成長組織で取り組むべき「標準化」について

不動産テックで事業部CTOをやっていたと思ったら、HRBrainでEngineering Managerになってそろそろ３ヶ月が経とうとしています。
HRBrainはEQTという約37兆円の資産を有する投資会社が資本参画したHR系のSaaSスタートアップです。CTOやマネージャーを長年勤めてきたことで、タレントマネジメントや評価、労務管理のためにHR系のプロダクトを触る事が多くなり、元々ドメインには興味を持っていました。

常々これらのプロダクトを「もっと良くできるのでは？」と感じていたのもあり、今回転職をすることにしました。入った直後からやるべき事は多くありなかなか大変な状況ですが、「採れる選択肢」も多いことで、楽しく働いています。
人材データプラットフォーム関連市場は約8兆円もあると言われており、日本の労働人口問題と絡めて考えてもまだまだこれから伸びていく市場だと実感してます。

本題ですが、新しい組織に飛び込むたびに考えているのは「何をいつどう標準化するか？」の話です。
スタートアップでは「自主性」を尊ぶわけですが、ある程度の規模のサイズまで組織が成長すると「標準化」と「属人化」のバランスを取らなければならなくなります。
何もかも自由だった時代とは別れを告げなければいけません。
そうでなければ、結局速度が出せなくなり組織としてもチームとしても成長が鈍化するからです。

そもそも「標準化」とは？

手順や水準を定め、社内で認識を統一することです。
例えば、新機能を開発する際において「まず、PdMがPRDを書く。全社からレビューやコメント（Request for Comment）を受け付ける。その後、意志決定者からレビューを受け開発承認される」というフローを定めます。

このフローを決めることの最大のメリットは「早期に重要なフィードバックを得て無駄を省ける」ことです。

「何を作るのか」がチーム内で共通の認識となりますし、「何の機能が、いつ、どのようにリリースされ、どう使われるのか」が関連部署（他のチームやセールスなど）に共有されやすくなります。
新入社員であっても「PRD一覧」をチェックすれば何の機能がどのチームで開発されているか、いつリリースするつもりなのかを知ることができます。

デメリットとしてはチームが「あれやろう」「これやろう」というレベルで意志決定をしていたときに比べると「めんどうくさい」と感じるようになることです。

どうして「標準化」などという面倒なことをやらなければならないのでしょうか？
あれこれ決めるのはチームで好きにやった方が早いのではないでしょうか？

実際には成長組織において属人化が増えると都度都度意志決定が必要になるだけでなく、認識がバラバラのまま組織全体が違う方向に進んでしまったり、防げたはずの間違いを犯しての手戻りも多くなるため加速度的に非効率化が進みます。

標準化を行うのはあなたの大切な時間を節約するためでもあります。

まず標準化を検討すべきもの

これは３つあります。

人材、等級、期待値
コミュニケーション
パーパス、ミッション、バリュー

人材、等級、期待値の標準化

小さなスタートアップだった時は面接や評価のやり方も判断も何も標準化されていません。
採用であれば知り合いに声をかけたり、仕事が出来そうな経歴の人が組織に加わったりします。
評価も「今期は頑張ったね、来期も頑張ろう」で終わったりします。
やがて、人が増えると徐々に組織に不満が生まれます。

「評価のされ方が明確ではない」
「何を期待されているかわからない」
「新しく入ってきた人のスキルレベルが低い」
「人が足りないのにチームには人がアサインされない」
（以下、無限に続く）

決めなくても何もかもうまくいっていた時代は遠い昔のことになります。

この標準化の第一歩は意志決定者（できればあなた）が「採用のフィルター」「評価のオーナー」になることです。
「どういう人材を、どういう期待値で、何をやってもらうために、いくらくらいの給与で採用するのか」
「誰をどのチームに配置し、リーダーに任命し、どういう行動や成果を高く評価するのか」

必要なポジションの採用のためにJDを明確にしたり、社内での等級や給与レンジなどを踏まえて、期待値を明確にし、キャリアラダーを記述することになるでしょう。
目標設定の妥当性や、従業員の成長実感、評価の納得感などは「説明可能」で無ければならず、「評価者Aさんはこう言ってたけど、評価者Bさんは違うことを言ってて、あそこのチームはズルい」といったことはなくすべきです。

採用や評価に一定の基準を設けることで、組織をより強い状況に導くことになりますし個人の成長にも大きく影響します。

コミュニケーション

コミュニケーションにまでルールが必要でしょうか？

もちろん、必要です。
人が増えてくると、「聞いてなかった」「知らなかった」「共有されていないのはおかしい」「必要なMTGに呼ばれていない」などと、様々な問題が生じます。
組織が拡大するにつれ、人間が認知できる人数の上限（ダンバー数）を超えることになるからです。

人が増えればチーム間のコミュニケーションパスが標準化される時もやってきます。
Slackでチームチャンネルを作って、その中で話をしていれば良かった時代は終わりです。
「オープンに話されているんだから、必要な人は情報を持って行ってね」では組織は回りません。

プル型の情報、プッシュ型の情報整理は不可欠です。
普段から情報の洪水に襲われている私たちが「必要な情報を必要な場所からつかみ取る」なんてことはできません。

プル型：この最新情報（例えば、各チームの体制や取り組んでいる機能）はNotionのプロダクトページに置いてあるから必要に応じて見てください。
プッシュ型：Aさんがチームリーダーになりました。これからはHogeプロジェクトの開発の牽引と○○機能の開発を推進していただきます。

……のように使い分けをするべきです。

特に複数チームが連携をするようになると途端にパスが複雑になります。
「聞いている」「聞いていない」だけではなく、「思っていたのと違った」ということが頻発します。

これを何とかしようと思って会議を増やすと「共有ミーティング」だらけの毎日に突入し、あっという間に時間を浪費します。
にも関わらず「共有していたはずなのに」複数チームが絡むような開発が遅延したり、失敗するようになります。

コミュニケーションパスを適切に標準化するのはあなたの「認知負荷」を下げるためです。

パーパス、ミッション、バリュー

パーパス、ミッション、バリューも標準化されるべきものです。
これは簡単に言えば「文化と価値観の標準化」です。

これらを定めなければ「組織が何に魂を持っているのか？　何と戦っているのか？　どうやったら勝つのか？」がわからなくなります。

特にバリューは日々の判断基準や評価、言動にも深く関わってきます。
これらを宗教的だ、気持ち悪いといって敬遠する人もいますが、バリューが本当に上手く機能している時は「組織に異物がない」と感じるようになります。
なぜなら、全社員が同じ方向を向き、同じ判断基準の下で同じことのために仕事をしていると感じられるからです。

スポーツで想像してみてください。
サッカーというスポーツはボールをゴールに入れ、その点の多寡で勝利を競います。
もしこのルールが定まってなければ、選手はフィールドに立ちすくむだけでボールを手でつかんで投げたり、キャッチボールを始めるかもしれません。ルールが無ければゴールの前にキーパーはいないでしょうし、誰かがネットによじ登って遊び始めてもおかしくありません。

そのための組織のルール制定が「文化と価値観の標準化」です。

組織とは、得意不得意が違う人たちが集まって、１人ではなし得ないような大きな目的を達成するためにあるのです。

他に標準化が検討できること

プロジェクトの管理や目標設定、マネジメントラインなど標準化を検討できることは山ほどあります。

オンコール体制やインシデント対応、問い合わせ対応、セキュリティ対策なども検討すべき項目です。これをしない場合、「特定の人だけが対応している」という状況に陥り、○○さんにお願いするしかない、ということが頻発します。

最初からすべてを上手く標準化することはできないので、「単純なことで失敗した」という経験の積み重ねから、誰かが手を挙げて実行することも重要です。

都度都度で意志決定をしたり、誰かに判断を仰いだりするようなことが減ればそれだけ日々の仕事は快適になっていきます。

ただし、完全な標準化はできないため、常に例外も含めて想定すべきです。
組織が成長する限り「標準化は陳腐化する」ことを忘れてはいけません。

絶対に標準化してはいけないこと

反面、標準化を絶対にしてはならないこともあります。

例えば個人の働き方に関して「子供のことなど気にせず、業務時間は業務に集中すべきだ」などと言えば家庭は崩壊し、やがて生産性の低下を招きます。
働き方を標準化しても逆効果なだけです。
同様にチームの中で完結するような細かいやり方を標準化しても意味がありません。

優秀な人材にも「標準」を当てはめない方が良いです。
時には遊撃隊のように動き、時には組織全体の問題に取り組み、対外的な個人活動も行う。
これは「特別扱い」や「好き勝手にやっている」とみられることもあるのですが、トップパフォーマーというのは平均的な開発者と比べて数倍の効率を持っているので、それを妨げるべきではありません。

給与もテーブル上の上限はこれだから、といって制限することも間違っています。
その小さな拘りによって、最大の戦力を失う羽目になります。
最終的に組織が勝ちきるためには「組織を牽引できる存在」が必要なのです。

理由なき標準化もまた悪です。
「他の企業がやっているので」という理由で「誰も困っていないのに」標準化しようとすると、反発を招きます。
特に「本で読んだので」「こないだAという会社でやっていると聞いたので」というような理由で「俺の考えた最強の組織にします」などとすることは止めるべきです。

最後に

大切なのは「標準化すること」と「標準化すべきでないこと」の判断を明確にし、組織の成長にあわせてうまくバランスを取っていくことです。
困ってなければ標準化すべきではありません。すべきことに集中してください。

これらのバランス感覚は物事が変化し続ける環境に身を置き、判断を重ねることで身についていくものですが、特に新しい環境に飛び込んだとき、リーダーシップを持ってこれらに取り組むと良い効果を得やすいので、是非試してみてください！

本記事は、HRBrain Advent Calendar 2024 シリーズ2の23日目の記事でした。

qiita.com

2023-12-12

CTOやVPoEと違いEMには再現性がある

こちらはEngineering Manager Advent Calendar 2023 12日目の記事です。

こんにちは、Isoparametric（Yuki Tamura）といいます。
今回はEMはCTOやVPoEの下位互換ではないということについて書きます。

私は今estieというスタートアップでEMをしております。
前職では不動産テックのCTOをしていて、その前はスマートニュースという会社でEMをしてました。
その前は、ディライトワークス、gumiという会社でCTOだったりしたこともあります。

では、CTO/VPoEとEMの互換性/再現性についてなのですが、
皆さんはEM(Engineering Manager)というとどんなイメージを持つでしょうか？
「マネジメントのキャリアパス」「CTOやVPoEの下で働くマネージャー」といった感じでしょうか？

「EMのキャリアパスはEMのEMになって次はVPoEだよ」などという話を聞いたことがあるかもしれません。
まるで、EMはVPoEやCTOの下位互換のように扱われていますが、最初に言ったとおりそれは違います。
なぜなら、EMにはCTO/VPoEとは異なり高い再現性と互換性があるからです。

CTO/VPoEとEMの違い

晴れてCTOの肩書きを手に入れたとして、CTOやVPoEの集いに顔を出せばわかる通り、それぞれの会社で求められているCTOやVPoEの役割というのは大きく違ってきます。
CTOという肩書きでも実質的にはテックリードだったりしますし、メンバーがいないVPoEなんていうケースだってあります。
逆に現場には一切関わらない上意下達だけをする存在ということもあるでしょう。
しかし、EMはそうではなく「どこにいても役割は大きく変わらず再現性がある役割」なのです。

何故かといえば「EMの責務は、チームのアウトプットを最大化すること」だからです。
もちろん、CTOもVPoEもマネージャーロールではありますが、彼らが見ている単位は「チーム」ではなく「組織」です。
「組織」という単位は非常に曖昧で、その数も形も一定ではありません。

しかし、EMは違います。
「高いアウトプットを出せるチーム」と限ってしまえば、その定義は比較的明確に定まるからです。

では、どういうことか説明していきましょう。

生産性の高いチームの定義

「生産性の高いチーム」を生み出したい場合、EMはおおよそ6~8人のエンジニアをマネジメントする必要があります。それが１チームの適性人数範囲だからです。
もしこれ以上のエンジニアをマネジメントすれば、業務過多になりチームやチームの責務に積極的に関わることは難しくなりますし、少なければチームとして機能しにくくなり出力も限られます。
例えば、私は最大23名のレポートラインを持っていたことがあり、それらのメンバーは4~5のチーム（プロダクト）に跨がって関わっていたので、どのチームを主軸にして良いか分からなくなりました。（マトリクス型組織だったのもあります）
また、それぞれのチームに対して新しいメンバーをアサインするために採用を行わなければならないため、採用のニーズは4~5倍になりどうしてもチームに対する関与が薄くなります。

勿論、スタートアップは常に変容する生き物のようなので一時的にこのような大人数を引き受けることも合理的な判断なのですが、長く続ければ将来的には必ず組織的負債を抱えることになります。

マネージャーはチームを拡充し開発力を最大化しなければならないので、チームを8人から10人くらいに成長させ、やがてこれを半分の人数に割るということを行います。
ただ、考えもなしに成熟したチームに対してそんなことをすれば、チームの生産性は台無しになると言っても過言ではありません。
また、頭数だけを揃えたチームを半分にしても生産性はでないでしょう。

スタートアップが「EMが必要です！」と言っている場合、それは「組織を成長させたいから」に他なりません。
「組織を成長させたい」というのは単に「頭数を増やしたい」ということではなく、「生産性の高いチームを複数生み出して、必要なことを同時にやりたい」ということですから、１人のマネージャーが大量のメンバーを引き受けて、それを分割していくようなやり方では絶対にうまくいかないのです。

チームにも状態がある

そもそも、チームには「状態」があります。
例えば、あるチームは常に「人手が足りません」と言っていますし、よくいるPdMたちは「新しくやりたいことがあるんだ」と言いますし、長く所属したエンジニアは「技術的な負債が大変なんです！」と言ったりします。
こういう状況が複雑に絡み合った状態がチームには常に存在しています。

ただ、これらのチームが目指していることはたった１つで「安定的に高い生産性を発揮すること」であり、「新しい機能に取り組みながら、技術的負債を返済し、ユーザーに向き合うためのゆとりが欲しい」と言っているわけです。

残念ながら、物事はそう理想通りに動くことはありません。

チームが「人が足りない！」と悲鳴をあげている状況の時、EMは「自分もコードを書くよ」といってチームに飛び込むべきではなく、あくまでも俯瞰して症状を適切に把握し、戦術的にチームが適切な状態になるように状況を導くことが必要になります。
では、いくつかの症状を見てみましょう。

そもそも人が足りていないチーム

チームが与えられた仕事を十分にこなせていないときは、そもそも人が足りていない可能性があります。この人が足りていないというのは人数だけでなく、必要なスキルセットの人がということもあります。
勿論、単純にやり方が拙いということもありますから、良い人を「採用する」「他のチームから人を移動させる」ことが常に最適解とはなりません。
EMは状況を正しく把握し、足りない人材（メンバーなのか、リーダーなのか、それとも特殊なスキルなのか、の）適切なJDを書き、必要なHC（ヘッドカウント）を確保して、チームの拡充に舵を切るべきなのです。
そうでなければ、いずれ誰かが辞めることでチームが崩壊してしまうでしょうし、いつまで経っても高い生産性など得られる筈もありません。

人数がいる筈なのにチーム

では、人数が既に6人〜8人いるチームはどうでしょう。それぞれのスキルセットを見ても、決して悪くないようです。
しかし、チームの話を聞いてみると「既存の仕組みが良くない」などの声があがったりします。
「技術的な負債がありすぎて、ちょっとしたことをするのにも凄く時間がかかるんです！」と泣きつかれることもあるでしょう。
「○○さんにお願いしないと物事が進まないんです！」なんてこともあります。
これもよくある症状で、アウトプットを出したくてもボトルネックが凄くてブレーキをべた踏みしながらアクセルを吹かしているようなことになっています。
このような状態で闇雲にチームに人を追加してもさらに空回りをするだけですから、EMはチームの優先順位を整理する必要があるでしょう。
もし、技術的な負債が原因なら「新規開発を完全に止めてでも負債の返済に集中するべき」なのかもしれませんし、「チーム外から常に何らかのタスクが割り込んでくる」ようであれば、その露払いをしなければならないかもしれません。
もしくは、「チーム内でブリリアントジャーク（優秀だけど周囲に悪影響を与える人）が暴れている」なら、その人を諫めるのかチームから外す必要があるでしょう。

そこそこうまくいっているチーム

時に何の文句もないチームというのもあります。
このときにメンバーは「何も問題はありません」と答えたりしますし、傍目にもやるべきことはないように思えますが、そうではありません。
チームが一定以上の十分な生産性を有している時は、マネージャーは「新機能の開発」と「技術的負債の返済」のバランスを保つ必要がでてきます。
もしくは、「育成」や「成長」、「挑戦」のバランスをとる必要があるかもしれません。
このような状態は安定しているように見えますが、問題が無いチームというのはほとんどなく、単に「うまくいっているように見えるだけ」かもしれません。
ある日突然、テックリードが「成長を感じられないから辞めたい」と言い出して、突然慌てる羽目になるかもしれないからです。
このような不意打ちを食らわないためにも慎重に見極める必要があります。

チームが完璧に機能している！

いやいや、うちのチームはモチベーションが高く挑戦もできているし、負債も溜まってない。
本当に最高の状態なんだ、ということがあるかもしれません。
この場合にマネージャーは何かをする必要がないように見えますが、実際にはチームを維持し続けるために水面下で様々な努力をする必要があるでしょう。
何故かと言えば、問題はチームの中だけにないからです。

有事に備える

EMはどれだけチームが機能していても決して油断してはいけません。
突然CTOやVPoEが「組織改編だ！」「レイオフだ！」と叫び出すかもしれないからです。
勿論、ビジネス側の都合で「プロジェクトAはもう止めだ、チームは解散する」なんてことが起こりえたりもします。
こういう寝耳に水の事態に備えるのもまたEMの仕事です。

EMがチームをマネジメントしているのとよく起こるのが鶴の一声です。
力のあるCEOが突然「○○という機能を月末までにリリースするぞ！」と言い出したりします。
こうなったら大変です。チームを解散するとまではいかないまでも、タスクフォースいう名の下のチームのエースが招聘されたり、先月まで最優先だと言われていた機能の開発が止まったりと、すべてのチームが大混乱に陥ります。
勿論、EMにこの鶴の一言を覆すような権限はありませんから、やれる対策としては「備える」ことに他なりません。
また、CTOと話をしてチームを守ることを検討できるかもしれません。
「最近のCEOは何を考えていますか？」と訪ねることで事前に予測ができるかもしれませんし、いざ起こってしまった後でも、「うちのチームから○○は出せません。なぜなら、今○○がチームから離れたら主軸となっている××の開発は確実に遅れますし、それが他のチームにとっても大きなブロッカーになります」などと直談判に向かうことで全体の崩壊だけは避けられるかもしれないからです。
このように様々な内的要因、外的要因によってすべてのチームは常に危険にさらされていますから「チームを最大パフォーマンスで動かし続けられる」企業は存在しません。
この危ういバランスをとっているのはEMという仕事なのです。

意図しない人員追加に対応する

上記のような危険なことが起きなかったとしても、あなたが成長する企業で働いている場合、CTOが突然言い出すかもしれません。
「新卒採用をしよう！」「インターンをやろう、どっかに受けいられるチームくらいあるだろう？」「もっと人が必要だから外国人採用をしよう」
こういう時に「もう人はいりません」「いまは難しいです」などと断るのもEMの仕事です。
「人が追加されるんだったら嬉しいでしょ？」と思うかもしれませんが、嬉しいのは「組織の都合」であり「チームの都合」ではありません。
チームが「組織の都合」に振り回されればやがて疲弊し、輝きを失っていきます。

要するに成長する組織からチームを守るのも立派なEMの仕事なのです。

EMの仕事はCTOやVPoEが命じた通りにチームに対して大鉈を振るうのではなく、そのチームがいかにすれば最大のパフォーマンスを維持できるのかを常に考え続けることなのです。

CTO/VPoEとEMの違い

ここまで話してきた通り、EMは常に「チームファースト」であるべきです。
自律性が高く持続性があり高い生産性を出せるのは「チーム」という単位であり、このチームという単位のパフォーマンスを維持しつつさらに向上させるのがEMの責任です。
このチームに人を入れるのも、チームから人を抜くのも、もしくは２つのチームに分けるのも本来はEMの判断次第ということになります。
しかし、人には人の人生があり時にライフイベントによって退職を決意したり、チームの移動を願い出られたり、新しいテックリードの擁立を余儀なくされることもあるでしょう。
いついかなる時にどこからチームに脅威が忍び寄っているかは分からないのです。
それに常に警戒し続けるのがEMの仕事です。

そして、CTO/VPoEはこの視点を持てないことがほとんどです。
なぜなら、視座も違えば解像度も違うので、チームの細やかな内情など考慮に入れることが難しくなってきますから。

適切な評価を与える

また、CTO/VPoEと異なりEMだけに与えられたさらなる苦難があります。
それは、チームに対して適切な評価を勝ち取ることです。
多くの企業においてEMは評価者でありますが、最終的な評価決定者ではありません。
よって、自身のさじ加減によってチームの評価を良くするということはできず、チームの評価はCTOやVPoEから勝ち取る立場なのです。
特に、EMが苦労するのはチームが"keeping the lights on" （灯りを点し続ける）と呼ばれるような地味な仕事をしている場合でしょう。
「今期、君のチームは何も新機能をデリバリーしてないから」と低評価をつけられようとしているチームがいたとしたら、EMは必死で「そうではないこと」を立証しなければならないのです。
実際に「灯りを点し続ける」というのは偉大な仕事であり傍目に何も変わっていないように見えても、そんな筈はありません。
現実世界だって、灯りが燃えるには燃料が必要なことくらい誰にだって分かるでしょう。
時にチームは灯りを吹きすさぶ風から守ったり、それがもし消えてしまった時に備えていたり、より明るく広範囲を照らせるようにしていたり、様々な努力を重ねています。
ただ何もしていないのに、そこに灯りが燃え続けることはありません。
そして、それを知りうるのもCTOやVPoEではなくチームをマネジメントするEMなのです。

最後に

自分はEM（エンジニアリング・マネージャー）だけれどもそんなこと考えたことがない、という人もいるでしょう。
それは、おそらく所属している企業自体の変化がとても緩やかだからです。
そういう意味では環境が違えばEMには互換性がなくなってしまうように感じるかもしれませんが、私はそうは思いません。
学び続けているEMはどこの企業でだって高い再現度でチームをマネジメントすることができます。

スタートアップは半年や１年で社員数が倍増することが多く、１年ごとに別の会社になった、と感じることも少なくありません。
要するに、気がつけばやってきたことはすぐ古くなってしまうのです。
であるが故に、多くの学びがありますし、その濁流の中でそれに飲み込まれないようにチームが成功することを助けるのは最もやり甲斐のある仕事の１つだと私は思っています。

急成長する組織の中でチームをうまく支えるというのは、「銀の弾丸」を見つけるような仕事ではなく、小さく成功を積み重ねていく地道な道しかありえない仕事です。
この地味さ故に実際にはEM自身が"keeping the lights on" という仕事に最も近く、大変苦労する要因でもあるのですが、それだけにEMが正しく理解されることを願ってやまないのです。

2022-01-04

EMに転職して1年と5ヶ月が経ちました

ということで、2020年の8月に転職をしましてEngineering Managerになりました。

あっという間に、1年と5ヶ月が経過した（2022年1月現在）感じです。

転職理由は色々ありますが、一番の理由は「人間お金を持つとおかしくなる」ということでしょうか。
希有な機会を与えてくれたことに少なからず恩義を感じているのではありますが、「いつ誰とバスに乗るか」が重要であるように「おかしさを感じてでも同じバスに乗り続けるか」もまた重要でしょう。

また、狂っていくのは本人には自覚できない故に自分も狂っているのではないかということもまた重要です。

もちろん、40を超えて新しいことをしなければならないという気持ちもありました。

さて、今回の私自身の新しいチャレンジは「英語でのマネジメントを身につける」ということです。

私が最初に入社したときの構成は、チームメンバーが5人。そのうち、英語話者は1人でした。

英語での仕事などやったことがない人間がそもそもそのようなチームを受け持ちよくしていけるのか、成果を最大化していけるのかと考えさせられる日々です。

それがこの一年半の間にチームは20人になってしまいました。英語話者も9人になりました。

マネージャーとしては1on1をどのようにしていくのかが何より大きな課題です。
日本語なら簡単にできることも英語になった途端どうすれば良いのか解らなくなることもしばしばあり、英語向上のために始めたCamblyも348時間に達したようですが、まだまだ能力が足りない状況です。

紹介コードありのものをリンクにしておいたので、良かったら試してみてください。10分間の無料レッスンがプレゼントされます。
Camblyの強みは「ネイティブであり、かつ教育に熱心なTutorが多く登録している」ことであり、彼らの指摘は非常にためになってます。

Tutorが「CamblyはTeacherではなくTutorだから、役立ててくれ」ということを言っており、なるほどと思いました。

そんなこんなで、Camblyは2020年の9月から週5の1時間でやっています。

ということで、備忘録代わりにCamblyで何をやっているのかを書いていくことにしました。

今日はCamblyで初めての講師を選び様々な会話をしていました。講師はボストンに住んでいるのですが、旅が好きで、ベトナムなどに住んでいたこともあり、このコロナ禍ではあるが、15の国に旅がしたいと言っていました。
また、MMOが好きで、FF14がfavoriteだと言っていたのでゲームの話をしました。
新しいエキスパンションがでるけど、旅行にいくから遊べないんだよね、というような他愛のないことを話しました。
こういう初対面のTutorと何を話すかというのはTutorに任せっぱなしになってしまうので、もっと質問力をあげるべきという気持ちになるやりとりです。

言っていることは解るが伝えられないということもよくあるので、今ある語彙で何とか説明するということを心がけていますが、最終的には自然に受け答えできるようになりたいものですね。

2016-03-01

リーダーを簡単に辞めさせる方法

幾つもプロジェクトを持っている会社であればチームに必ずリーダーやエースがいると思います。

場合によっては簡単にモチベーションを下げ、辞めさせる事ができる方法を1つ紹介します。

「リーダーをそのプロジェクトから強制的に外し、燃えているプロジェクトに何人かリーダーを投下し、誰がやってもいいような仕事をアサインする」

です。これでまず１００％デモチして、かつ退職を考えるようになります。

リーダーはリーダーだからモチベーションを持っている

これは一見当たり前の事ですが、誰にでも自尊心があります。仕事を奪い、どうでもいい仕事をアサインする事がその自尊心を傷つけることに十分すぎる効果があります。リーダーからリーダーを意に反して奪うことは非常に強い効果を持ちます。そして、退職を考えます。

誰にでもできる仕事を与える

これも非常に効果的で、誰にでもできるスキルレベルに見合わない仕事を与えることで、無気力感を与えます。燃えているプロジェクトでは仕事に融通が利かないことが多く他にも元リーダーがアサインされているので動きづらくなります。自分はいなくても良いのではと思い始め、そして、退職を考えます。

指示を出す側から指示を出される側に変える

今までスケジュールを考え、タスクを考え、アサインを考えていた人を逆に仕事を与えられる立場にします。スケジュールは考えなくてよくなり、タスクも分解せずに済み、アサインに頭を悩まされる必要もなくなります。そして、退職を考えます。

こんな事がありえるのだろうか？

アサインの権限者がバグってると往々にしてありえます。

よくあるシチュエーションとしては1つのプロジェクトが無茶苦茶燃えていて、それを何とかしようとして他のプロジェクトからリーダーを連れてきて何とかしようとする場合です。現場のリクエストとしては多くの場合「出来る人をアサインしてほしい」となり、通常は「出来る人＝リーダー」となるパターンが多く、リーダーを複数連れてくるケースなどがあります。