職場で何もしないこと
(seangoedecke.com)- ソフトウェアエンジニアの成果は、より多くの時間やコード量よりも、適切なタイミングでの高インパクトな仕事に左右され、普段は1日の業務の約20%をコンピュータから離れて過ごす80%活用が有効である
- 大規模なエンジニアリング組織では、大口契約の支援、インシデントの緩和、主要機能のリリースのような時間依存の機会が大きな価値を生み、すでに忙しいとこうした機会を逃しやすい
- 優先度の低いチケットを処理し続けると、他チームの状況、チームの更新、進行中のインシデントを見られず、マネージャーも余裕のある人だと判断しにくい
- 何もしない時間は、ストレスからの回復、インシデント対応中の冷静さ、新しいアイデア、重要な仕事への集中力を可能にする
- 普段は意図的に余力を残し、報酬が非常に大きい時期にだけ100%の強度で没頭するやり方は、高成果のエンジニアになりやすい条件を作る
高インパクトな機会
- 多くのエンジニアはもっと少なく働くべきであり、これはコードや変更量を減らせという意味ではなく、1日のうち実際に働く時間を減らし、働くときももっとゆっくりした速度で働けという意味である
- 基本状態では80%の稼働率を目標にし、高圧のプロジェクトがないときは勤務時間の20%をコンピュータから離れて過ごす
- テック企業の成果は例外的な出来事に大きく左右され、最大の影響を生んだ変更の多くは、驚くほど少ない作業量で実現できることがある
- ソフトウェア開発では努力そのものに点数はなく、重要なのは適切な問題を適切な時点で解くことである
-
大規模組織で起こり得る3つの例
- 大口のエンタープライズ契約を成立させようとしている瞬間に、機能追加やバグ修正を支援すれば契約成立に役立つことがある
- 機能が必ずしも素晴らしい必要はなく、具体的な変更を作る意思と能力を示すだけで十分な場合もある
- インシデントを初期に予防または緩和できれば、インシデント中の即時の売上損失と、その後の顧客離れや契約拒否による売上損失を減らせる
- 正しい機能フラグをオフにすべきだと知っているだけでも、大きな金額を節約できる
- 会社が重要な機能をリリースしようとするとき、成功と失敗は些細だが見つけにくい変更にかかっていることがある
- ユーザー設定に新しいフィールドを素早く追加したり、何年も手が入っていない古いエンタープライズ向けデータエクスポート機能を直したりするのが例である
- システムへの習熟度は、数時間で済む変更と1週間かかる変更の違いを生む
-
時間依存性
- こうした機会はすべて時間依存であり、朝ログインしてから任意に大口契約を解決したり、インシデントを緩和したり、主要機能をすばやく作ったりできるわけではない
- 適切な場所と時点にいるだけでは不十分で、すでに忙しくない状態でなければならない
余裕を保つ
- 優先度の低い作業を処理し続けて100%稼働の状態を維持すると、高インパクトな仕事の機会を2つの形で逃すことになる
- 第一に、忙しすぎると機会そのものに気づけない
- 他の仕事をしている人と話したり、チームの更新を読んだり、進行中のインシデントを見たりする時間が減る
- 高インパクトな仕事に参加する最善の方法は、自分の専門性を自ら提供することである
- 第二に、いつも忙しそうに見えると、マネージャーが代わりに参加させにくい
- マネージャーやプロダクトマネージャーが「ここを手伝える余裕がある」と判断してつないでくれる形が、2番目に良い参加経路である
- マネージャーやプロダクトマネージャーは、エンジニアが参加しない会議に入るため、どんな高インパクトな仕事が進んでいるかをよりよく把握していることが多い
何もしないこと
- 高インパクトな仕事のために時間を空ける必要があり、チケット処理だけを続けてはいけないなら、分単位では本当に何もしなくてもよい
- ソフトウェアエンジニアリングはストレスの大きい職業になり得るが、通常は継続的にストレスが高い職業ではない
- ストレスは、ときどき起こるインシデント、緊急で高圧な仕事、最近のレイオフのような状況で発生する
- 比較的プレッシャーの低い業務区間まで緊急時の強度で取り組むと、高圧な状況に対処しなければならないときには、すでに疲れ切って神経が尖った状態になってしまう
- 高圧な業務区間でも、何もしない姿勢は役に立つことがある
- オンコールに慣れていないエンジニアは、急がず、通話に入る前や話す前に何度か深呼吸したほうがよい
- インシデント対応では、全体として「ゆっくり動いて考える」ことが必要である
- ほとんどのインシデントは自然に解決し、インシデント中に急いで入れる「役に立つかもしれない」変更は、状況を良くするより悪くすることが多い
- 一般に、パニックを避けるだけでも、インシデント対応では大半のエンジニアよりうまくやれている状態になる
- 何もしない時間は、物事が起こり得る余白になる
- 脳が休む機会を得ると、新しいアイデアが浮かぶ可能性が高まる
- 重要な仕事を任されたとき、裏で進行中の3つの仕事を同時に処理せず、完全に集中できる
- 忙しくないときは、ただ物事を眺めて新しいデータを受け取る時間が生まれる
特定の仕事を意図的にしない
- 多くのエンジニアは、やるべきことが見えているのにやらない状況を不快に感じる
- こうした傾向は多くのソフトウェアエンジニアに共通する心理的特徴であり、ある程度はこの職務に適性を持たせる要素でもある
- 何もしない時間を作るには、ときには意図的に割り込まないよう自分を強制しなければならない
-
グルー仕事を避ける
- エンジニアは一般にグルー仕事を避けるべきである
- グルー仕事とは、人々が互いに会話するようにすること、自分がリードしていない仕事の文書更新、技術的負債の解消リソースなどを指す
- ほとんどのグルー仕事は、組織がその仕事を明示的に優先していない事実を反映している
- 組織が優先事項にしているなら、個人が自発的に引き受ける必要はない
- 組織が優先していないことが問題ない仕事なら、それを引き受けるのは時間の無駄であり、マネージャーをいら立たせることもある
- 組織が優先していないことが大きな誤りだったとしても、個人が代わりに処理すると、会社は自分の誤りの結果を経験せず、個人のキャリアと精神的な健康がそのコストを支払うことになる
- これは個人にとっても悪い取引であり、ジュニアの同僚にとっても悪い手本であり、燃え尽きた後に別の誰かが同じ位置に入るという悪い前例にもなる
- 結果が本当に深刻なら、組織が痛みを感じて方針を変えられるよう、その結果が発生するに任せるべきである
-
過剰な手助けは脆弱性を生む
- 助けになりすぎようとする姿勢は、無報酬労働を引き出そうとする人たちに対して脆弱にする
- テック企業には、ソフトウェアエンジニアから報酬の出ない仕事を引き出そうとする人が多い
- これは通常ルートで入り、昇進、ボーナス、通常の給与で報われる仕事とは異なる
- 問題になる仕事は非公式ルートで入ってきて、その仕事を公式に本人の実績として記録する能力や意思のない人から来る
- 他組織のプロダクトマネージャーがデータクエリが得意だとして、特定の統計を出してほしいと頼んでくるのが一例である
- 他チームのエンジニアがペア作業を頼むが、実際にはすべてのコードを書かせて、変更は自分の名前で提出するのが一例である
- この種の仕事をある程度するのは問題なく、可能なときに人を助けてもよい
- ただし、断ったり、数時間または数日遅れて返信したりする形で逆圧力をかけられなければならない
-
消える可能性が高い仕事に過剰投資しない
- 消える可能性が高い仕事には、あまり多くを投資しないほうがよい
- プロダクトデザイナーが望むものをリアルタイムで詰めている状況では、毎時間ページを完全に書き直してはいけない
- 午前9時にページヘッダーをある形で望み、10時に修正し、11時にまた変える流れがその例である
- こういう場合は散歩に出るなど何もしないで、午後に最新のデザインを基準に一度書き直すほうがよい
- 政治的な推進力が弱いマネージャーの大きなアイデアもよくある例である
- プロジェクトが中止されるまで時間をやり過ごせることが多い
- ただし、プロジェクトの政治的支援の強さを見誤ると、怠け者のように見えたり、急いで結果を出さなければならない状況になったりすることがある
結論
- ソフトウェアエンジニアリングの助言やツールは、同時により多くのことをこなし、より大きな範囲のプロジェクトを担い、より多くのコードを書くような、技術的努力を拡張する能力に合わせて作られていることが多い
- ソフトウェアエンジニアリングの成功は、そのような要素では決まらない
- 成功は、正しいことを正しいタイミングで行う能力で決まり、そのためには日常業務の中で意図的に一部の余力を残しておく必要がある
- 80%の努力でも高成果のエンジニアになることは可能であり、むしろストレスから来る愚かなミスを減らし、大きな利益を生む高インパクトな仕事に飛び込みやすくなる
- 100%の努力で没頭すべき時期もあり、年に2〜3回ほどは、長時間、強い集中、1日中問題を考える形で働くこともできる
- こうした働き方は、本当に報酬が大きいときのために残しておき、それ以外の期間は比較的余裕を持って働くほうがよい
1件のコメント
Hacker Newsの意見
良い文章だが、結局またインセンティブが問題として浮かび上がる
事故を早めに防いだり被害を和らげたりすれば大金を節約できる、というのはその通りだが、複数の会社で繰り返し見てきたのは、問題の予防は評価されず、焚き付け用の薪を山ほど積み上げてから必然の火事を消すと二度評価される、ということだった。"良い"組織でもそうだった
意図的にひどいコードを素早く出してその手柄を取る、ゲーム理論的な政治には最後まで没頭できなかった。自分の仕事への誇りが強すぎたからだ
前の製品バージョンを悩ませていた問題群をなくすためのフレームワークを5年以上管理し育ててきたが、ひどいコードをデプロイして障害を起こし、それを直したパートナーチームは公に称賛され、うちのチームはそうした障害がなかったという理由で何の手柄にもならなかった。測定できない予防だからだ
Thread.sleep(100000)を入れておいて、壊れるまで待てばいい。そうすればリリース後の金曜深夜まで長く勇敢に火消しをした人になれるなぜ報われるのかは聞かないほうがよいし、もちろん時には組織が評価基準を別のものに変えることもある
誠実なアプローチとしては、複雑だが不可欠なツールをいくつか作って、他のエンジニアが継続的に自分を頼ってくるようにする方法がある。特定のツールの誤用を見抜くのがうまくなり、他人のコードのバグを数秒で指摘できれば、実際以上にずっと賢く見える
理想的には、そのツールは信頼できて有用だが複雑であるべきだ。他の開発者がそのツールを使っていてバグにぶつかると、引き続き自分のところに来るようになり、自分は彼らのミスを指摘できる。この戦略が機能するには、ミスはほぼ常に相手側になければならず、自分のコードは堅牢でなければならない
自分のコードで本物のバグ、できれば小さな境界ケースが見つかったら、とても謙虚に、申し訳なさそうに振る舞い、チーム会議でその複雑なバグを見つけた開発者を称賛すべきだ
自分のバグだらけのコードを直して手柄を得るやり方よりはましだ。それは管理職やジュニアには通じるかもしれないが、他のシニアエンジニアには嫌われる
複雑だが安定したツールを作るやり方なら、繰り返し、しばしば二度どころではないほど多く評価されるし、他の開発者からの評価はいずれ管理職の耳にも入る。賢いリーダーは、派手なデモよりこのシグナルのほうが優れていると分かっている
特定の開発者が素早くプロトタイプを作るというだけで称賛をばらまくリーダーたちは、結局その誤りを学ぶことになる。若い創業者は、表面的なものを称賛するこの段階をよく通るように思う
製品や機能のまとまりを作る仕事の一部は、優れたエンジニアリングというより探索に近い。ときには、堅牢な機能を1つ作るより、ユーザーにとって何が価値あるのかを見極めるために、十分にまともな機能を2つ作るほうが良い
自分はいつも「まずやってみて確かめよう」派だった。ただ、自分と違う姿勢の誰かが git を作ってくれたことには感謝している
ここにはバランスがあり、今扱っている問題がどれだけ探索の問題かによって変わる。ここでいう「堅牢さ」とは、純粋なエンジニアリングの観点での可用性、保守性、ユーザーのセンシティブな写真が流出する可能性、といった意味だ
「報われない仕事を搾り取ろうとする人たち」についての部分は額に入れて飾るべき
特に、別組織のプロダクトマネージャーが「データクエリが得意なら、Xについての統計を出してもらえますか？」と言ってきたり、別チームのエンジニアが「ペア」を頼んでおきながら、結局は自分がコードを全部書き、相手が自分の名前でこっそり変更を提出するような状況のことだ
彼の戦略は、人を助け、手柄を積極的に譲ることだった。1:1や複数階層の管理職がいる会議で、チームメンバーの仕事の価値を継続的に強調し、そのおかげでチームの好感を得ていた
数年後、大金がかかったプロジェクトが予定より遅れ、複数の中核エンジニアが退職したとき、彼は残業しながらそのプロジェクトを成功に導き、次の評価で肩書と昇給を得た
そのプロジェクトが最後のひと押しになったのは確かだが、残業したエンジニアは彼だけではなかった。彼は自分の昇進を、在籍期間中に他人に手柄を譲ることで積み上げた好意のおかげだと見ている
職務記述書にあるかどうかに関係なく、問題を見て解決策を提案する人たちと働きたい
自分の仕事が評価されないなら、それはリーダーシップの問題だ。仕事をきっぱり断るやり方は、硬直した遅い組織文化への道のように感じる
同じように、いつか自分も同僚に何か必要になるかもしれないし、そのとき「正式なチャネルで来てください」と追い返されるより、積極的に助けてもらえたほうがありがたい。正式なチャネルのほうがずっと時間がかかることもある
昼食の席での会話が、人々の理解を助けるようなものだ
ただし、誰かのために何時間もかかる作業を引き受けるのは、また別の問題かもしれない
皮肉で言うのではなく観察に近いのだが、十分に大きい、あるいは官僚的な組織では、事故を未然に防いでも手柄や可視性を得にくい。そうした成果は「本来やるべき仕事」に分類される
だから社内政治に長けた人たちは、むしろ事故が起きるに任せて、事後対応項目で大げさに動くほうを選ぶ。コツは事故を大惨事にまで育てないことで、かなり繊細な作業になる
営業契約を救っても拍手を受けるのは営業チームで、手数料も彼らが受け取る。私はその一部すら受け取れない
いくつか燃え尽きるに任せれば、上司の上司の上司がその火を見ることになり、改善されるかもしれない。たぶん彼らと意思疎通するいちばん簡単な方法でもある
以前からこの方向の文章を半分ほど書きかけていて、ファンタジーRPGの比喩を使っていた。こういうゲームでマナを使うキャラクターをやると、些細な戦闘のたびにマナを使い切って空のまま歩き回り、本当に必要な時に何も残っていない、ということをすぐ学ぶ
仕事で使う精神的エネルギーも大きくは違わない。タンクに少し残しておけば、予期しないことが起きた時に健康、つまりバーンアウトを危険にさらさず、戦略的に使える
こういうゲームでマナ管理ができないプレイヤーとパーティーを組むと、その人があまり良いチームメイトではないことも分かる
どの分野でも、自分の能力が頂点だった時期というのは、目の前に十分な仕事があって機械のように安定して処理でき、目標に向かって邪魔されずに働けるだけの信頼があり、説明のために何度も止められずに済んでいた時だった。技術は野火のように伸び、作業は予想より早く終わった
残念ながら、そうした構造を活用する職場は非常にまれだ。実際のディープワークに入れないようにする遮断要因や妨害が多すぎる
システムを壊したいなら、基準運用を**100%**で回せばいい。余裕がなく、新しい需要を受け止める容量もないので、システムに小さな攪乱が入るだけで常時失敗モードに入ることになる
この種の文章や Peopleware / Slack のような本の問題は、会計担当者が別のアプローチを試してみるだけの説得力を持つ実際の指標を示していないことにある
見方を変えてくれた比喩は、「The Power of Full Engagement」にあったものだった。だいたい「君はオフシーズンのない世界トップクラスの持久系アスリートのように振る舞っている。やめろ」という内容だ
ここには多くの知恵がある。本当に価値の高い仕事が来たときのために一部の容量を残しておくことに加えて、ソフトウェアエンジニアリングはただ忙しくし続ければうまくできる仕事ではないと思う
できるだけ速くコードを書こうとしても、良い設計になることはめったにない。この記事はもう一つの重要な側面、つまりマネージャーに叱られずに80%の容量で働く方法を扱っていない
ここではコミュニケーションと作業見積もりに少し注意が必要だ。最初の本格的なプログラミング職場で、年上の熟練開発者たちから聞いた良い助言の一つが今でも残っている。何かにどれくらい時間がかかるか見積もったら、マネージャーやユーザーに伝える前にそれを2倍にしろ、というものだ
経験が積まれればその倍率は2倍ではなく1.5倍くらいまで下がるかもしれないが、原則は依然として当てはまる
最適化し、前例にすべきなのは、長期にわたって着実に、持続可能なペースで届けるという点だ。長いゲームであり、過剰な約束は信頼を削るだけだ。その信頼こそが、開発者が必要な余地を得るための最大の手段でもある
少なく約束し、言ったことはやり切るという信頼を作り、バーンアウトせずに済む余地を得るべきだ
シニアになればなるほど、特にリードになれば、境界設定と注意力の保全、バーンアウト防止が仕事になる。自分を壊す方法が多すぎるからだ
ホフスタッターの法則を考慮しても、物事は常に予想より長くかかる
https://en.wikipedia.org/wiki/Hofstadter%27s_law
顧客接点の仕事を多くしてきた立場から言うと、何度も直面した最悪の落とし穴は、お金を払う顧客と親しくなってしまうことだった。専門家として雇われて助ける立場では、顧客が本当にいい人だと断るのが狂おしいほど難しくなる
さらに悪いのは、その人自身は意思決定者ではなく、私に何かを押し付けるよう強いられている立場である場合だ。信頼された専門家として、顧客本人が悪いアイデアを出す時は断りやすいが、一度も直接相手をしないその上司が指示を出すと、私は役に立たないコストのように見えるか、怪物を残していくイエスマンになるかの立場に置かれる
主に社内業務をしてきた人たちが時々うらやましい。少なくともどこか上の誰かを説得してみることはできただろうから
グルー作業に関する部分は興味深い。大企業で働いていたとき、これは年次業績評価の明示的な一部だった。Googleではこれを「citizenship」と呼んでいて、本質をよく捉えた表現だと思う。つまり「会社の他の人たちのために、何をより良くしたか」ということだった
一方では少し奇妙でもあった。自分の職務記述書には入っていなかったので、厳密には無報酬の仕事だったが、同時に公式な期待事項の一部でもあった。とはいえ、全員が少しずつ時間と労力を使って、皆のために環境を改善する職場で働くのは良いことでもあった
これを全員への明示的な要求事項にすると、「自分はロックスターエンジニアだから重要な仕事で忙しい、グルー作業は他の誰かがやればいい」という有害な文化を回避しようとする試みにもなる。しかもその「他の誰か」はたいてい女性で、ほぼ確実にそのロックスターエンジニアより給料が低かった
元記事は、会社がグルー作業をする人を正式に雇うべきだという含みを持たせているが、実際にはあまりに多様な断片の寄せ集めなので、一人を採用して任せるのはほぼ不可能だ。たとえば「文書作成、ソフトウェアエンジニアの面接、チームのオフサイト行事の運営」をすべて包含する肩書きが何になるだろうか
しかし、そうした作業はどれも必要であり、citizenshipの要件はその負担をより公平に分担できるようにしていた
より良い言い方は「グルー作業をするな」ではなく、「報酬のないグルー作業を一人で引き受ける都合のいい人間になるな」だと思う。つまり、皆がその一部を担い、それが公式に 仕事として認められる文化 を後押しすべきだ
80%の稼働率で運営するのは良い習慣で、毎日一日中100%を要求する監視的な管理者がいないときには役に立つ。そういう人たちは、ソフトウェアエンジニアが静かに落ち着いて考えている様子を、怠惰で何もしていない状態だと誤解する
だからリモートワークは、ある程度の稼働率を予備として残し、メンタルヘルスを守るうえで最良のやり方だ
少しのグルー作業は、皆の仕事上の生活をずっと良くし、しかも誰もそのやり方を知らないなら、チーム内で自分を不可欠な存在やヒーローにしてくれることがある
自分は学び、考え、取りかかるまでに苦労するタイプなので、自分の80%は、技術的により強い同僚の80%とはまったく同じではない
神経多様性の傾向まで少しでも考慮に入れれば、ある人の80は別の人の 120 になりうる