- スタートアップのリーダー職はコードよりも不確実な責任を多く扱い、パニック発作・不安・バーンアウトが業務成果と人生全体を揺るがしうる
- 役職が上がるほど、明確なチケットの代わりに変化する要求、重なる締め切り、24/7の障害対応のような終わりの見えないプレッシャーが増える
- 「make it happen」式の文化は、無理な締め切りの受け入れ、マイクロマネジメント、深夜のPR書き直し、欠食と会議の積み重なりによってバーンアウトを悪化させる
- すべての締め切りが同じリスクではなく、規制・契約・自ら課した締め切りを区別すれば、交渉可能な圧力と実際のリスクを切り分けて見られる
- 回復は大げさな決意よりも、早期警告サインの認識、週末の保護、委任、通知の遮断、相談といった小さく繰り返せる行動から始まる
スタートアップのリーダー職から始まった不安とバーンアウト
- 2017年にHead of ITの役割を引き継ぎ、5人規模の開発チーム、パートナーに約束した多くの仕事、そして「すべてを届け、何も壊さず、誰も燃え尽きさせるな」というプレッシャーを同時に背負った
- 当時はメンタルヘルスを理由に病気休暇を取れるとは感じられず、会社のハンドブックにmental health dayがあっても、エンジニアがなおためらうことがある
- 不安が押し寄せると、Redditのr/Anxietyで似た症状を探し、長期的な解決策ではなかったものの、オフィスから飛び出さずに踏みとどまる助けにはなった
- 最終的には医師に相談して正式な診断を受け、ゆっくりと基準となる状態へ戻り、今でも緊急時のチェックリストを手元に置いている
制御しやすい開発業務から不確実なリーダーシップ業務へ
- 初期の開発業務には、明確なチケット、受け入れ基準、テスト、マージといった、比較的制御しやすい流れが多かった
- 役職が上がるほど業務定義は曖昧になり、締め切りは重なり、ステークホルダーはスプリントの途中で考えを変え、確率的な判断が日常になる
- インフラやSREの業務は24/7のページャーを抱えて生きるため、プロダクトの締め切り以上に強い常時緊張を伴う
- CEOが最大顧客に約束した機能を最優先で作れと言った翌日に、それと矛盾する別機能も最優先だと要求したことがあった
- 2つの機能が同時に最優先であるはずがないと言っても、返ってきた答えは「make it happen」だった
「make it happen」が生んだ蓄積的な損傷
- バーンアウトは単発の大事故というより、何千もの小さな自己損傷が積み重なった結果に近かった
- 精神的負担を増やした行動は繰り返し現れた
- 営業チームの面目を保つため、無理な締め切りをすべて受け入れる
- チームを守るという名目で自らコードに飛び込み、マイクロマネジメントする
- 深夜2時に銀行口座を更新し続け、給与支払いが可能か確認する
- 目の前の障害を消火しながら、同時に将来のアーキテクチャも計画しようとする
- ジュニアをコーチしながら、夜にこっそりPRを書き直す
- 連続する会議、冷めたコーヒー、抜いた昼食が続く
- 週末の朝、最初の10秒だけは平気で、その直後に不安が落ちてくる感覚が何度も繰り返された
すべての締め切りが同じリスクではない
- 昔はすべてのリリースをMars Roverの着陸のように扱っていたが、振り返れば実際に会社の存続を左右する締め切りは少数で、残りは自尊心や期待値設定の失敗に近かった
- 会社のキャッシュフローが改善し、顧客が安定すると、ワークライフバランスはそれほど非現実的には見えなくなり始めた
- 金曜の夜のデプロイが壊れて6時間対応したことがあり、顧客が契約を切ると思ったが、月曜になってみると顧客はセーリング旅行中で、ステージングのリンクすら開いていなかった
- 締め切りは3種類に分けて考えられる
- 規制上の締め切り: 交渉不可
- 契約上の締め切り: 早めに伝えればたいてい交渉可能
- 自ら課した締め切り: たいていは自尊心から生まれる
- 企業によっては週4日勤務や退勤後のSlack禁止を打ち出しており、バーンアウトを名誉の勲章のように扱う会社にだけ留まる必要はない
効果があった個人的な対処法
- 医療的助言ではないが、機能を保つのに役立った行動がいくつかあった
- 早期警告サインを探す
- 自分にとっては、doom-scrollによる不眠や、普段は好きだったコードレビューへの突然の嫌悪がサインだった
- こうしたサインが現れたら、速度を落とす
- 「ノー」をはっきり言う
- 週末は守るべきであり、ページャー通知でない限り月曜まで待ってもらう
- きちんと委任する
- 自分が抱え込んでいるすべてのPRは、メンタリングの機会を失うことであり、不安を積み上げることにもなる
- カフェインを減らす
- half-cafを経てdecafに切り替え、心臓が楽になった
- 1日12,000歩歩く
- スマートフォンの通知を切る
- 本当に本番環境が燃えているなら、誰かが電話してくるはずだと考える
人を先に見るリーダーシップ
- 感情知能について読み始めてから、人をmerge conflictマシンのようには見なくなった
- 先に聞き、あとで直すというやり方は、もう1回のスプリントレトロスペクティブより役立つことがある
- 歯の治療は恥ずかしがらずに任せるのに、メンタルヘルスだけは自分ひとりでリファクタリングすべきだと期待する態度は適切ではない
- 専門家に会った時間は、最もROIの高い時間の一つだった
- 回復は反復的なプロセスであり、今でも遅くまで働いたり昼食を忘れたりすることはあるが、今は気づいて修正し、先へ進める
コードより大切な資産
- コードは書き直せても、人はそのようには扱えない
- うつはKubernetesの稼働時間を考慮してくれず、リーダーシップが人をすり潰せば、クラスターは動いていても、そのクラスターを動かす人は持ちこたえられない
- 顧客チケットを全部自分で直したい衝動があっても、今ではまず「これは自分のコントロール範囲内か」と問い、違うなら手放す
- その結果、少し落ち着いたエンジニアになり、Apple Watchによれば夜に45分多く眠れるようになった
- つらい時期にいるなら、壊れているわけでも一人きりでもなく、助けを求め、小さな実験を試し、メンタルヘルス休暇を使うほうがよい
- バーンアウトした時間で価値を測る会社は、その時間を捧げる価値がなく、最大の資産は書かれたコードではなく、そのコードを書く人である
1件のコメント
Hacker News の意見
ソフトウェアエンジニアリングをほぼ30年やってきて、ほとんどの締め切りは完全に恣意的だという結論に達した
1週間遅れようが、場合によっては6か月遅れようが会社は潰れないし、本当に潰れるのだとしたら、自分たちの納期予測を繰り返し破るほどエンジニアリング組織が壊れていない限り、それはエンジニアリングのせいでもない
規制、顧客の概念実証、納品といった実際の締め切りはあるが、まともなエンジニアリング／ビジネス組織なら、そうした締め切りはずっと前から分かっているもので、十分な余裕を持ったスケジュールの中で実装可能かどうかが肝心だ
製品が一定の周期でリリースされないからといって顧客が離れるケースはほとんど見たことがなく、むしろ自分たちが要望した問題を直すものでない限り、アップグレードを歓迎しない顧客も多い
終わりのない週80時間労働はたいてい逆効果で、壊れ続けて捨てたくなるような低品質な製品を作ることになる
この30年を振り返って、完全に飛ばしていても長期的には何の違いもなかった作業は何％あっただろうか？ 私の場合は軽く50％を超えるし、気分の悪い日なら90％近いと言うと思う
ビデオゲームはいまだに Target や Best Buy のような小売店でも売られていて、店舗は数か月前から陳列スペースを調整しなければならない。11月15日までにパッケージ化されたゲームを物流ドックに持ち込むと約束していて、それを逃すと、君のために空けておいた棚がそのまま空になってしまう
コンシューマー向け電子機器も同様で、広告、特にテレビ広告も以前はずっと前から予約する必要があった。6か月前に広告枠を買わなければ売り切れてしまい、広告が流れる時点で製品が購入可能でなければ大金を無駄にする
一般的な IT プロジェクトの締め切りはかなりでたらめかもしれないが、小売製品ではなぜ締め切りが生じるのか理解できる
解決策は、製品が100％完成するまでは棚スペースの交渉を始めないことだろうが、企業は普通そうできない。注文代金で給与を払わなければならず、製品完成後に広告と棚を確保して6か月待つとなると、その間に従業員が何をするのか曖昧になるし、次の製品に移ってからまた以前の製品サポートに戻るコストも大きい
もっと更新頻度の低い安定版のほうがずっと好みだ
何の警告もなく、エンジニアリングが差し迫った締め切りに間に合わないと突然発表したり、「ほぼ終わっていて、あと1スプリントだけ」が延々と繰り返されたりするほうが、ずっと苛立たしい
だから「もう見積もりはしない」「終わったときが終わりだ」といった場当たり的な反応はまったく役に立たない
自分のスケジュールもタイムブロッキングや恣意的な期限で管理し、それで生産的だと感じていて、その洞察を会社全体に広げている。時間制限のある脅威がなければ作業は予定どおり終わらない、という前提がある
何かが決まった日に終わるという感覚は人間的に魅力的で、よく油を差された機械が予測可能なスケジュールで動いているような温かい感覚もある
しかし、誰かの不安やスケジュールへの強迫を管理するために、多くの人へ強制的な日程を押し付けるのは残酷だ。現実は複雑で、それをきれいな箱に収めたいという欲望は妄想的で非生産的だ
ソフトウェアエンジニアリングが、医師、弁護士、営業職、エンジニア、プロスポーツ選手、教師といった他のホワイトカラー職よりもメンタルヘルスに悪いとは、あまり確信していない。
こうした職業にはどれも固有のストレス要因があり、つらくて辞める人が多いという話もいくらでもある。境界線を引かなければ余暇を食いつぶされ、締め切りでストレスを受けるのも共通している。
「精神的につらいので1日休みます」とチームに伝えて病欠できない、という部分は読んでいてつらかった。
20年のキャリアでそんな態度を一度も見たことがなく、人々はメンタルヘルスを理由に普通に病欠を取っている。そう言えないと感じたのは残念だが、それはルールというより、はるかに例外に近い。
過去20年で、メンタルヘルスに反対だと表明した会社があっただろうか？
メンタルヘルスの問題を抱える18〜20歳の若者が多いが、あまりに簡単に休ませることが助けにならない場合も多い。専門家は、家で酒を飲んでゲームばかりさせるより、働き続けさせようとする。
仕事のストレスが増えたときに、むしろうまく反応した若者もいた。訓練所のように一生懸命働いて疲れ果てて家に帰れば眠るが、疲れていない状態で帰宅させると酒と深夜のゲームにつながり、翌日はゾンビのように出勤する。
すべての人に通用する方法ではないが、私たちが必ずしも自分自身にとって最高の治療者ではないことは受け入れるべきだ。休暇が増えると否定的な行動が増幅される人も多い。
より良い答えは「1日休まなければ」ではなく、「明日08:00にカウンセリングの予約が入っている」に近い。
悪いマネジメント、非現実的なスケジュール、興味の持てないプロジェクトについての個人的経験は認めるが、そういうものはどこにでもある。
そこに、毎日患者と家族が人生最悪の日を経験する現場にいなければならず、高圧的な意思決定をしなければならず、勤務中ずっと座る機会やトイレに行く機会さえほとんどない状況を加えてみれば違いが分かる。
そのうえ、調子の悪い1日が、長く続く調査や裁判沙汰につながることもある。
冷淡に聞こえるかもしれないが、ソフトウェアエンジニアリングは多くの医療職ほど複雑でもストレスが強くもない。精神的にも肉体的にも消耗は少ない。
ほぼ10年にわたって弁護士たちと一緒に働き、非エンジニアリング系の専門サービスを提供してきたし、ソフトウェアエンジニアリングとスタートアップでの経験も数十年ある。
ソフトウェアエンジニアリングのプレッシャーは、法律の環境で経験したものとはまったく異なり、はるかに悪かった。
概して、弁護士はマネージャーというより弁護士だ。ジュニアアソシエイトから最上位のパートナーまで階層はあるが、上下ともに弁護士である。弁護士がマネージャーの下で働く構造とは違う。
法律の環境にもプレッシャーや長時間労働はあり、配偶者たちは弁護士がいつも会社にいるか、家にいても上の空だと不満を言うが、そこでは不安発作やメンタルヘルスの問題は経験せず、ソフトウェアとスタートアップの環境では経験した。
法律の側では、全員が手続きを知っていて、その手続きを実行し、上司もその手続きを経験した人だ。
ソフトウェアでは、その手続きを知らないことが多く、自分ではすり減るような経験をしたことのない人を満足させようとして、すり減り続けやすい。以前勤めていた成功した上場企業では、まさにこの理由でシニアソフトウェアエンジニアの求人が常に出ていた。
学校で雇用に関する基本的な法律を教えれば、多くの人の助けになると思う。
糞を踏んだにせよ膝まで浸かったにせよ、結局は糞の中にいることに変わりはない。誰がより多くかぶったかを競うのではなく、互いに拭き合うほうがいいのではないか？
比較をやめるべきだ。今はトリアージが必要な状況でもないし、平均的にはより良い立場にいる人に対しても同情や共感はできる。私たちは皆人間であり、一緒にいることで得をする。
以前は若い大学中退CEOたちにある程度の畏敬の念を抱いていたが、何人かの下で働いた後は、20代がトップにいるスタートアップでは働かないことにした。
彼らは本当にマネジメントやリーダーシップを知らない。失敗への恐怖に突き動かされていて、まだ何も成し遂げていないため、他人をゴミのように扱う。避けたほうがいい。
大学アメフト／バスケットボールのリクルーティングの奇妙なバージョンだ。
難しい核心は、25歳が全般的に賢く、まれなほど自己認識と謙虚さを備え、大きな問題に挑んでいるとしても、いつチームや助言者の言うことを聞くべきか、誰の言葉を聞くべきか、いつ自分の判断で逆に進むべきかを知るのが難しい、という点にある。
良い資質をすべて備え、良いチームや助言者に接することができれば、ある程度は可能かもしれない。
ただし、多くの分野が悪い慣行や助言、露骨な欺瞞や操作に満ちていることも助けにならない。以前PGの文章を読んでいた頃は、同じ技術者であり起業家でもある人が、賢く善意ある助言で成功を願ってくれると期待できたが、今ではまったく標準ではない。
今はどこを見ても悪い助言を受ける可能性のほうがはるかに高く、個人や組織が操作しようとする場合もより多い。自分でふるいにかけたとしても、影響を受け入れた賢くまともな人たちを通じて、二次的に流れ込む影響まで受けることになる。
49歳の創業者／CEOとの経験から抜け出したばかりで、今後はゴミのような兆候をすべて探すことになりそうだ。
彼らは昇進しようと狂ったように働き、今では自分のような人たちでチームを埋められると思っている。
だが、そうではない。その「同じような人たち」は、健康を害しないだけの賢さがあったか、そうしたくなかったから昇進しなかったのだ。
より良い成果を出し、お金と権限もより多く得たことはおめでとう。しかし今や、皆がシーツをめくり、彼らが食べかすをこぼしたそのベッドに横たわらなければならない。
ある時点からは、ただキューを作り、次に優先度の高い仕事を始めるべき
進行中の作業が多すぎると破綻する
「新しい最優先機能ですね。ざっと調べたところ、この仕事は付箋20枚で表せそうです。私たちのチームの過去の処理速度は2週間で付箋10枚です。つまり、既存の進行中作業をすべて下ろせば、おそらく4週間後に終わります。既存の各付箋を見ながら、本当に止めてよいか確認してください」
ステークホルダーはそれでも意思決定できるが、チームに何を求めているのかを現実的に理解させる効果がある
数週間後、CEOに新リリースのスコープと難しさをかなり理解できたと思うと言うと、CEOは「いや、分かっていない」と言った
理由を聞くと、週末の間に新しく思いついた「必須」機能があると言い、それは明らかに技術的に非常に難しかった。そして、どんなものでも48時間以内に作れると断言した
あの職場であれほど長く持ちこたえたのが不思議だ
後で元の仕事に戻ると、すでに完了していることにいつも驚かれる
結局はバーンアウトか無関心に向かう道になる
当時 X-Files をよく見ていたので「今週の怪物」と呼んでいたが、今でもその表現が気に入っている
ごく短い時間でも、やっていたことから切り離される能力は本当に重要
散歩をしたり、コーヒーを淹れたり、ただ目を閉じて呼吸すればよい
ストレスは人為的に作られることが多く、成果を損ない、思考力も低下させる
会社が契約や売上を取れるからと仕事が「緊急」になり、この「クランチ」をやり遂げれば全員がスーパースターになれる、という状況を何度も経験した
2か月間、徹夜と3〜4時間睡眠を繰り返してプロジェクトを前倒しで納品すると、経営陣や意思決定者はこうした「贈り物」のようなクランチを与え続け、感覚が麻痺し始める
会社を助け、一歩先までやることはたいてい経験してきたし、今後もできるが、すべてのことが緊急で、すべての作業を今すぐやらなければならないなら、より大きな問題があるということ
お金、時間、労力にはたいてい限界と予算がある。その限界と許容範囲を濫用すると、人々はオオカミ少年を尊重しなくなり、仕事にも力を入れなくなる
「これを納品すれば、とてつもない大型契約が確定する」というような劇的な緊急案件でクランチするたびに、結局は契約失敗に終わった
営業担当者は、長期的な賭け一つのために研究開発組織全体を何か月も動かし、人々を燃え尽きさせても、クビになるようには見えない
もちろん、その営業担当者がその期間ずっと何週間も残業しているわけでもない
今では、自分のミスを取り返すために追加で働く場合でなければ、残業はほとんど拒否している。他の愚か者の非現実的な締め切りに合わせるために、二度と余計に働くつもりはない
会社、プロダクト、顧客のために「きちんと」やる機会が与えられないことがある。結局、今日最も重要なことは何かを尋ね、それをやったら、仕事が終わった時点できっぱり退勤することにした
意味や個人的な満足は私生活の中に見つけるべき。運動したり、ボランティアをしたり、趣味を持ったり、家族に集中すればよい
ワークライフバランスを得る最良の方法は、両者を切り離すこと。だから在宅勤務が嫌いな理由の一つもここにある。通勤の運転は、私にとって優れた切り離し装置であり、減圧装置でもある
「精神的につらいので一日休む」と病欠を取れないというのは正しくない
メンタルヘルスデーが必要だと言えばよく、大人は理解する
誰も詳細を尋ねなかった
大多数の職業ではそうではない
私のリードや上司にあんなふうに言えば、なぜ来ないのかと問い詰められるだろう
ソフトウェア開発という営みそのものに、精神疾患を引き起こす、あるいは引き起こし得る何かがあるのだと信じるようになった
何十年もの間、何人かの同僚が非常に深刻な問題を抱えるのを見てきたし、私たちの業界では本当にかなり深刻な問題だと思う
私は ADHD のあるソフトウェアエンジニアで、ADHD のソフトウェアエンジニアを異常なほど多く知っている
その程度の実行機能障害と「追いつくこと」は問題になる
しかし多くのプロジェクトは、会社や本人の気力が尽きるか、別の会社に移って同じことを繰り返すまで、年単位で終わりなく続く
Web開発ではリリース日が最も近いゴールラインだが、本当のゴールラインではない。主要指標の目標達成もある程度はそれに当たるが、テーブルや陶器を完成させたり、作物を収穫して売ったり夕食に出したりするほど心理的に満足できるものではない
だから心に悪いというのは筋が通っている
他の書き手たちがどれほど上手く適応して暮らしているかを見ればよい。特に、家賃のために価値がないと分かっている文章を長時間書かなければならない人たちのことだ
2017年に周囲のあらゆる不確実性を制御しようとしていたという描写は、ひどい会社の悪夢のような職場で持ちこたえようとして、自分を責めているように聞こえる
こういう人はリーダーの立場にいるべきではなかった
このタイプの下で働いたことがあるが、本人は優秀なエンジニアだったものの、リードとしてはひどかった
チームを信頼せず、いつも自分で処理し、議論もなく、裏で話を進め、経営陣の意向には常に屈する。すべてが「重要」か「致命的」で、最悪のマイクロマネジメントだった
同時に、自分もその立場に置かれたら、程度は低くても似たように失敗していた可能性はある。経営陣は「Xに気に入られるため」以外に特に良い理由もなく、私たちを不可能な立場に押し込むことが多い
名前も知らない中間幹部に点数を稼ごうとしてそうするなら、さらに最悪だ
だからテック業界に労組があればいいと思う。現実的な期待値を設定し、経営陣に集団としての視点で向き合える
残念ながら、最近の企業は素早いエグジットとIPOでベンチャー資金を回収することばかり狙っている。ハゲタカたちの間の一般的な見方は、労組が素早いエグジットの可能性を下げるというものらしい
組織が誰かをリーダーとして訓練もせずに昇進させたからだ
非技術系のバックグラウンドを持つマネージャーに、いきなりコーディングを始めることを期待しないのに、なぜコーダーがいきなりマネジメントを始めることを期待するのか？
リーダー候補をコーチングするときにも、よく障害になる
リーダーの役割に移ると、人々が自分のやり方ではない方法で仕事をしても構わない、と受け入れる術を学ばなければならない
部下の成果がほぼ十分、または十分に良いなら受け入れるべきだ。そしてその「十分さ」の許容幅は、学ぶ前に思っているよりずっと大きいはずだ
会社が特に機能不全だったのかもしれないが、割り当てられたプロジェクトや作業について経験が多くないことを隠してもいなかった
ところが、自分で理解しようと時間を使っていると、上司がそのまま自分でやってしまい、フィードバックはくれなかった
実際には、優先順位付け、委任、感情知能についての具体的な訓練が必要だったのかもしれない
こうした訓練が提供されることはまれだ。代わりに、成果の高い人を深い水に放り込み、耐えられるかを見るようなやり方をする
たいていは個人貢献者として多くの仕事を自分でこなしてきたから昇進する。ところがリーダーになった後は、自分でやる仕事が少ないほど、本人、会社、チームメンバーの全員にとって良い
だから、以前より暇に感じることは、仕事ができていないというサインではないと学ばなければならない
「メンタル的につらいので一日休む」とチームに伝えて病欠を取れない、ということはあり得る
私は数年前からそうするようになり、全体としては前向きな経験だった。私が先に自分の苦しさを打ち明けたから、チームの他の人たちも自分のつらさを話してくれるようになった