ビッグテック企業で「仕事を終えた（Done）」ことの本当の意味

• ビッグテックで本当に 仕事を終える とは、無限に改善可能なシステムの中で 会社が満足する状態まで仕上げて、そこを離れること を意味する
• 有能でも 主体性に欠けるエンジニア は、些細な改善ばかりを繰り返し、本当の成果を逃してしまう
• 意思決定者に 目に見える、明確な成果物 を届けてこそ、「仕事をした」と認められる
• 自分の仕事が 上位管理職に読まれ、評価されうる形 になっているかを常に点検すべき
• すべての仕事を整理しきることはできず、ある時点では 「勝利を宣言して去る能力」こそが中核的なスキル になる

---

「仕事」は完結しえない性質を持つ

• 数学の問題や課題と違い、現実世界の仕事は 無限に改善可能な開かれたシステム である
• サービス開発は木を植えることのように、その後も 継続的な手入れが必要なプロセス である

罠にはまった有能なエンジニア

• 自分ひとりですべてを抱え込み 小さく連続的な改善だけを繰り返す エンジニアは、成果を出していると感じていても
• 上位管理職の立場から見ると 「会社にとっての可視的な価値創出」がないと判断される
• 結果として 成果のない忙しい人だと誤解される可能性がある

「終える」の実際の意味

• 会社（意思決定者）が満足する地点まで到達させて、次へ進むこと
• リファクタリングや些細な改善を続ける代わりに、明確な 成果リスト を作るべき
• 「終わった」と宣言し 次の仕事へ進む決断力 が重要である

仕事の「可読性」を確保する

• 管理職がすでに知っている、あるいは依頼したプロジェクトや、大きな障害への対応は 可読性が高い
• 基本的に大半の技術的な仕事は、管理職にとって 判断しにくい技術的ノイズ にすぎない
• したがって、成果を目に見える形にしたり、金銭的な効果を強調したりする など、読まれるように調整 しなければならない

「終える」は社会的な概念

• 哲学的には「終えた」という概念も 社会的構築物 だが、現実では 非常に実質的な力 を持つ
• これを無視すると正当に評価されず、最終的には解雇される可能性すらある

要約

• 働いているからといって終えたことにはならない
• ほとんどの仕事は終わらず、継続しうる
• 庭師ではなく 成果重視の戦術家になるべき
• 「終えた」の基準は 会社／管理職の満足
• 「勝利宣言 → 去る → 次の仕事へ」 が中核戦略

[aer0700]

勝利宣言ができるような仕事を選ぶことも、重要なスキルのようです。

[elbanic]

範囲を絞ることをスコーピングといいます。勝てるようにうまくスコーピングすることが能力なのです。

[bakyeono]

ハンシン vs ソハ

[doolayer]

細部ではなく、数値化された可視的な成果

[GN⁺]

Hacker Newsの意見

• この記事の主張に全面的に反対というわけではないが、ビッグテックや複数のスタートアップ、ユニコーン企業などさまざまな場所で働いた経験からすると、あまり実践的な助言には感じない。ここ10年で開発者の仕事はあまりにも専門化され、意思決定者や顧客のニーズから切り離されている。この現象は、Product Managerがエンジニアと会社の他の部分との間に入り込むことで起きている。私は常に価値ある成果を出したいと思っているが、実際にそうしようとすると絶え間ないストレスを受け入れなければならない。私の貢献は必ず意思決定者と話す人のエゴを通って調整される。この5年で本当の達成感を得た唯一の時期は、9か月間、臨時でProduct Managerの役割を担ったときだった。その期間、私たちのチームは、それ以前に別のチームが何度も失敗していた3つのプロジェクトを成功させた。秘訣は利害関係者と実際に話してニーズを把握したことであって、自分のやり方を押し通そうとしたことではない。だから私はこれからも求められたものだけを提供し、バグについては非難され、機能については評価されないままだろう。それでも報酬は悪くない。今もなお、自分がきちんと貢献できる場所を探し続けている

  • この「報酬は悪くない」という部分が妙に印象に残った。ビッグテックで働くとき、「停滞している」状態もそれほど悪くないという自分なりの見方がある。たとえばGoogleやMSのような会社で年収30万ドルをもらいながら、10年間ずっと同じ退屈なプロジェクトだけを担当していても、その経歴はどこでも通用する。昔の自分のような野心家なら不満を持つかもしれないが、そういう性格ならもっと小さな会社に移ろうとするはずだ。年を取るにつれて関心は会社より家族や友人へと移っていく。もし誰かに昇進はないと言われても、「だから何？」と思うだろう。私は家族のために十分なお金を稼ぎ、ワークライフバランスも確保している。正直なところ、会社でいちばん良い部分は給料と、それによって残りの人生が良くなることだ
  • Product Managerという職種は、理想的に説明される姿とは違って、実際には板挟みになって両側をうまく代表できていないことが多いと感じてきた。その結果、自分でプロダクト管理の能力を身につけるようになったが、このスキルは無駄な仕事を避けるのに本当に役立つ。だから大きな仕事をするエンジニアなら、プロダクトマネジメントも必須スキルであるべきなのかと考えてしまう
  • もう一つ考えるべきなのは、このままではバーンアウトへの道を歩んでいるということだ
  • どんな組織でもコミュニケーションが最高のスキルセットだと気づいた。9か月の臨時業務だけでその真価を理解するには十分ではない。この記事自体、他のエンジニアと同じようにかなり苛立った状態で、自分は組織の他の人たちより賢いと思っているように読める。実際にはそうでないことも多く、このマインドセットは協業に悪影響を与える
  • どんなよく動くWebアプリケーションの裏にも、必ず庭師のような人がいる
  • なぜProduct Managerを続けなかったのか気になる
  • 会社によって本当に千差万別だ。エンジニアの影響力がもっと大きい場所も多い。特にビッグテックでも、顧客と切り離されていない例は存在する
  • Product Managerたちを解雇すべきという意味か？
  • Product Managerの役割、つまりエンジニアと会社の間を仲介する仕事をしていて、自分の貢献もまた自分のエゴでフィルタリングされていたのは事実だが、それがそんなに満足感のあるものだったという話にも聞こえる……かなり満足できる仕事だったのだろう

• 私は、権力者を満足させることだけを成功の基準にすることに根本的な異議がある。私たちは滑稽な地位構造に縛られてはいるが、Jiraでチケットを「完了」に変えたり、コンパイラ警告を消したりすることがすべてではないと思う。誰も「40年間、毎回上司を満足させてきたから後悔はない」とは言わない

  • 私は40年のうち30年働いてきたが、上司とその上司たちを満足させることにも確かに価値はあった。皮肉な見方が人生のすべてではないにせよ、この皮肉な観点を知っていることは真実に近づくことを意味する
  • 実際、「上司とその上司たちを満足させること」こそが雇用の定義だと思う。誰かに言われたことをやって金を受け取るということだ

• 全体的には同意するが、一つ付け加えるなら、マネージャーが何を望んでいるかを理解するには会社のビジネス構造を把握しなければならない。会社がどうやって金を稼いでいるのか、何を価値あるものと見なしているのかを、必ず自分で把握する必要がある。会社の価値観と一致する場所で働くと、報酬も高く満足度も大きい。顧客はもちろん、営業、マーケティング、できる限り経営陣にも直接会ってみることが重要だ。内部システムだけを担当していても、そのシステムがどこに価値や保護を与えているのかを知ることが核心だ。もし自分の部署が明確な価値創出をできていないなら、価値のあるチームへの異動を考えるべきだ。会社のニーズとずれた仕事はいつも大きな失敗だった

  • 自分を大工だと考えても構わないと思う。開発は仕様に合わせて実装すればよいが、その仕様が馬鹿げていたり不可能だったりするなら、問題を自分で指摘すべきだ。ビジネス側が自分たちの仕事を明確に説明できないなら、本人たちも分かっていないのだ。しかも、開発者がビジネスまでよく知っている必要が本当にあるなら、それに対する報酬が必ずあるべきだ。その時間があれば技術的にもっと成長できるのだから、機会費用もある
  • 「マネージャーが本当にビジネスを理解し配慮してくれる」という前提自体が成り立たないことも多い

• 筆者は「意思決定権者に見える結果を出す必要がある」と言っていたが、私はこの人の「ビジネス」マインドには共感する。多くの開発者は、自分の仕事にどんなビジネス上の効用があるのかを説明する方法が分からず苦戦している。リファクタリングもその一例だ。コード改善は短期的にはまったく意味がないように見えることもあるが、状況によっては組織に莫大な利益をもたらす。結局のところ、自分の仕事を組織の収益やコスト削減につなげ、さらにそれをどう伝えるかを考える必要がある、というのが核心だ

  • 開発者はビジネスの言葉を学び、問題をビジネス側の人たちが理解し、気にかける形でフレーミングしなければならない。ほとんどのビジネス上の意思決定は結局、コスト対便益だ。実際、多くのビジネスパーソンはソフトウェア自体をコストとして扱っている。つまり、「ソフトウェアがどうして収益創出の中心ではないのか」という開発者にとって当然の考えとは違い、ビジネス側はソフトウェア自体に関心がない。無料で売れるならすべてのコストは0なので、利益率は無限大だというのがビジネス側の本音だ。営業は理性よりも空気、関係性、さらには賄賂でさえ成立しうる領域だ。不合理に聞こえても、これを必ず理解しなければならない

• 「こうした心構えが、多くのエンジニアがコード品質、テスト、ドキュメントなどに気を配らない理由なのだろうか？」という疑問がある。もし上の人の即時の満足だけを気にするなら、誰が長く保守可能なコードを書こうと努力するだろうか。規格以上の品質は不要でも、最低限の投資だけで数十億を節約できることもある

  • ますます多くの人が職人気質や品質を気にしなくなっている。「給料分しか働かない」という声が聞こえる状況だ。昔は給与に関係なく仕事は丁寧にやるという感覚があったが、それがかなり失われたように思う
  • みなそれぞれの役割を担う理由がある。映画制作の現場のように、エンジニアたちもそれぞれ目的が異なりうる。もしエンジニアが情熱を発揮できないようにすれば、金だけで動く人ばかりが残る。リスクは大きい
  • わざと悪いコードを書く人はいないと思う。無関心やバーンアウトは、繰り返し報われない環境で生まれると、誰も追加の努力をしなくなる。そして多くの開発者は、単純に基礎的な能力が低いこともある。保険数理士ほど高度に競争的な職業ではないので、どんな背景からでも参入でき、そもそも有能になるのも難しい
  • 多くのProduct Managerは、とにかく速さだけを求める。私たちはテストやドキュメントを望むが、CFOたちはそうした付随作業を「機能ではないから不要だ」と見なして無駄扱いする
  • エンジニアが会社に長く居続けることを前提にしていないので、将来の責任を負うつもりがない。頻繁に転職していると、前職で自分が書いたコードの問題を自分で被ることがなく、失敗を経験せずに繰り返してしまう。私は20年近く同じ会社にいて、ずっと繰り返される失敗を見てきた。本質的な問題をそのままにして表面だけを変えるような変化にも飽き飽きしている。本当の問題を直さない限り、変化に意味はない。私の目的は本当の問題解決だ

• この現実と問題点は十分に経験してきたし、理解もしているが、それでも異議はある。多くのプロジェクトが始まり、「解決完了、done!」という声とともにチームは解散する。だが製品には依然として課題が残り、機能追加も必要で、会社も変化し続ける。結局、管理不全のまま技術的負債だけが積み上がる。新しいマネージャーが来て昔のプロジェクトを作り直し、同じ失敗を繰り返す。このやり方は非効率だ。エアコンにたとえるなら、温度を何度も切ってまた下げるより、一定に保つほうが効率的だ。実際、私が作った管理ツールには経営陣は関心を持たなかったが、内部ユーザーは500人を超えるほど必要とされていた。保守に大きな時間をかけなくても、信頼を維持し続けることが重要だった。放置すれば分散し、ツールの信頼性も失われる。数分かけるだけでも一貫性は保てた

  • エアコンのたとえは、実は熱力学的には間違っている。切ったあとでまた下げるほうが効率的だ

• いろいろと複雑な気持ちがある。visibilityや昇進という点ではこの記事の言うことは正しいが、実態としては管理者を満足させろという管理者中心の助言だ。では、明確な方向性がなく、優先順位が絶えず変わるとしたらどうなるのか。意味のある結果を出すのは難しくなり、管理者と部下の関係は完全な「イエスマン」構造になってしまう。これは良い結果ではない

  • 答えは簡単だ。愚かな上司の下で働いていると感じたら、さっさと辞めることだ。苦労は一時的だが、結局はもっと良くなる。馬鹿に自分の仕事を説明するために時間を無駄にするより、ずっとましだ
  • 逆に、本当に良いマネージャーと働けば、「管理者を満足させる」だけでもキャリアも成果物も早く伸ばせる

• unagentic engineerとは、自律性のないエンジニアを意味する。もしエンジニアがこのような形で働けば、非効率や深刻な問題（過大なクラウドコスト、セキュリティ事故、顧客の不満など）につながりうる。決して終わらない仕事の例として、セキュリティパッチ、ミスの修正、コスト最適化、顧客フィードバックへの対応が挙げられる。会社がこの価値を理解しないなら、転職が答えだ

  • この記事の要点はまさにそこだ。現実中心の組織もあれば、地位中心の組織もある。現実中心の組織は長期的に合理的で、地位中心の組織は上司を満足させることだけが目的だ。製品の品質や顧客との関係より序列がすべてになる。こうした組織が必ず崩壊する必要はないが、ある瞬間に一気に崩れることはある
  • Unagenticは、自律性（agency）のない従業員を意味する。自分から主体性を発揮することが期待されているのに、実際には開発者が自分の存在そのものを見えなくしてしまう落とし穴でもある
  • 必ずしもこうなるわけではないが、経営陣が気にかけないと、基本的にはこうした文化が根付く。たとえば私はインターフェースデザインの細部にこだわるのが好きだ。しかしそうした配慮が組織で価値として認められるときにだけ報われる。多くの場所では気にも留められない
  • unagentic engineerは、自発的に意思決定して引っ張っていく特性が乏しく、ただ流れに身を任せるタイプを指す
  • 自律的ではない、つまり判断権の少ないエンジニアを指す
  • high agencyではない、つまり賢く有能に見えても、常に指示を待ち、自分から主導できない人を意味する

• 私はalignmentのようなバズワードが大嫌いだ。それでも、本質的に重要な概念であることは確かだ。理想的には、自分とマネージャー、そしてその上の経営陣までが、何が最も重要な仕事なのかについて合意しているべきだ。もしそうでないなら、所属する組織の一員としては問題だ。それが正しいことか、公平かどうかは別として、私たちはそれに合わせて生きていく。結局のところ、上から言われたことをやるのが給料をもらう理由だ。ごく少数の人だけが上に影響を与えられるという特権を持つ。それがいわゆるmanaging upだ

• 原文は有用だが、もっと重要な核心が抜けている気がする:

  • 正しい仕事をすることよりも、正しいチームで働くことのほうが重要
  • 良いPMとマネージャーは、良い業務内容よりも重要
  • 良い報告ラインは、成果そのものの価値よりも重要
  • リーダーシップの目標に合った仕事は、実際のビジネス運営の支援よりもはるかに高く評価される
  • いつでも自分で全部やる覚悟が必要であり、大企業の政治には常に協業への逆インセンティブがつきまとう

[heal9179]

むしろこちらの意見のほうが核心を突いていますね

[roxie]

そうですね（笑）