2 ポイント 投稿者 GN⁺ 2024-12-24 | 1件のコメント | WhatsAppで共有
  • 大学と職場を通じて繰り返し出会った Julius は、自信とプレゼン力には優れているものの、技術理解と実際の貢献は一貫して疑問視される人物だった
  • Cプロジェクトで C仮想マシン を語ったり、インターネット上のサーバーにはIPアドレスがないと顧客に話したりするなど、基本概念と噛み合わない発言が繰り返された
  • チームは彼のコードと文書を毎回再確認し、顧客への約束まで火消ししなければならなかったが、上司とHRはプレゼン力と態度を高く評価した
  • Juliusは会社を移るたびに経歴と報酬を伸ばし、LinkedInやメディア露出を通じて大きく貢献した人物のように見えるキャリアを積み重ねていった
  • 会社が生産性向上を理由に複数の AIソフトウェア を導入し、無効化を禁じると、語り手は周囲が何十人ものジュリアスで埋め尽くされたような職場環境に耐えがたさを覚える

大学で最初に見たジュリアス

  • Juliusは大学で出会った同級生で、落ち着いていて親切で、いつも笑顔をたたえた人物だった
  • 彼は人の話を遮らず、間違いを指摘されても受け入れ、質問にもためらいなく答えた
  • すべての授業に出席し、自分のノートと見比べたいと言って、ほかの学生のノートをよく求めていた

Cプロジェクトで現れた最初のほころび

  • 学生チームはC言語で比較的複雑なシステムソフトウェアを作るプロジェクトに取り組んでいた
  • Juliusはすべての会議に参加していたが、語り手は彼がコードを1行でも書いている場面を思い出せなかった
  • 最終的にJuliusは報告書の書式を担当したようで、その仕事は非常によくできていた
  • 発表もJuliusが担当し、彼は非常に自信たっぷりにプレゼンを進めた
  • 発表中には、プロジェクトで使われた C仮想マシン について語り、見覚えのないロゴや無関係なスクリーンショットを見せた
    • Cはコンパイル言語なので仮想マシンは必要ない
    • C仮想マシンというのは、電気自動車のキャブレターを語るようなもので、まったく筋が通らない
  • 語り手は席を立ってJuliusの話を遮り、とっさに冗談だったことにしてその場を取り繕った
  • 教授たちの間では、Juliusは優秀だという評価と、根本的な理解が欠けているという評価に分かれ、彼はいくつかの科目で不合格になったものの、最終的には一緒に卒業した

会社で再び出会ったジュリアス

  • 数年後、語り手は大企業で責任ある役割を担っており、上司は採用担当者がチームに珍しい人材を見つけたと知らせてきた
  • 新しく来た人物は大学時代の同期Juliusで、彼は相変わらずカリスマ性と自信に満ちた様子だった
  • 彼はいくつもの会社に長くは在籍せず、たいてい1年かそれより短い期間で移っていた
  • 履歴書は印象的で、コンピューティングのさまざまな分野を経験してきたように見えた
  • のちに語り手は、Juliusが似たような職位でありながら自分の2倍の年収で採用され、自分には知らされていなかったボーナスまで受け取っていたことを知る

チームが背負ったレビューコスト

  • 語り手は当初、Juliusにプロジェクトと社内プロセスを教え、仕事を任せた
  • Juliusは質問をたくさんしたが、必ずしも的を射た質問ばかりではなかった
  • 彼はコードや文書を書き、さまざまな分野の質問にも答えたが、その成果物は時に良く、しばしば平凡で、場合によっては完全に意味不明だった
  • チームは、Juliusのあらゆる成果物を別のメンバーが完全にレビューし修正しなければならないことに気づいた
    • チームの専門外の領域なら外部レビューが必要だった
    • Juliusの文書はチーム外に出す前に2人が校正するという非公式ルールまで生まれた
  • その一方で 書式、プレゼン、会議運営 には秀でており、上司は彼をチームへの大きな貢献者だと見なしていた

顧客への約束の後始末をしたチーム

  • 語り手はJuliusがチームの仕事を理解していないと上司に伝えようとしたが、うまくいかなかった
  • チームはJuliusを数時間引き離すために役に立たない会議へ送り込むこともあったが、その戦略にも限界があった
  • Juliusが顧客に対し、インターフェースをたった1つのボタンに単純化して、望むことを正確に実行させられると約束したあと、チームは失望した顧客をなだめるため 1週間にわたる危機管理会議 を行うはめになった
    • 顧客の複雑な要求をボタン1つで満たすには、心を読む機械を開発しなければならないレベルだと説明して収拾した
  • ハッキングを心配する顧客には、セキュリティ上、インターネットに接続されたサーバーにはIPアドレスがないと話した
    • IPアドレスの「I」はInternetを意味する
    • インターネットとは、IPアドレスを持つコンピュータ同士が相互接続されたネットワークである
    • IPアドレスなしでインターネット上にいるというのは、電話番号なしで電話連絡ができると言うのと同じである
  • チームはJuliusが1人で顧客に会えないようにした
  • あるプログラマーが上司に問題を直接訴えたが、上司はそれを嫉妬だと受け取り、そのプログラマーは叱責されたのち、まもなく退職した

Juliusの退職とキャリア拡大

  • Juliusは断れない提案を受けたと言って会社を去った
  • 上司とHR部門は、彼が辞めることを心から惜しんだ
  • JuliusのLinkedInアカウントは非常に活発で、何百ものコメントが寄せられていた
  • 彼が在籍した1年はLinkedIn上で驚くべき経験としてまとめられ、事実を誇張してはいないものの、チームに大きく貢献したかのような印象を残した
  • その後Juliusは、多国籍企業に買収されたスタートアップの副CEOになり、やがて暫定CEOとなった
  • 経済紙が彼を取り上げ、その後は大臣級の人物のチームに加わった

AIソフトウェアになった「何十人ものジュリアス」

  • 語り手はJuliusを忘れようとしていたが、上司はある会社の営業担当者に会ったあと、生産性を高めてくれる 人工知能ソフトウェア に感嘆した
  • 会社には複数のAIツールが導入された
    • コーディングを助けるAIソフトウェア
    • 情報検索を助けるAIソフトウェア
    • メールを要約し作成するAIソフトウェア
  • 語り手はこれらのツールを無効化できない
  • 彼は一瞬一瞬、何十人ものJuliusに取り囲まれているように感じ、コンピュータのクリック音やスマートフォンの通知がすべてJuliusから来ているかのように思える
  • 上司は、チームの生産性が危険なほど落ちているので、AIをもっと効果的に使うべきだと言う
  • さらに、競合他社は最新のAIを使っているはずで、新しい 時間・生産性管理AI を導入するコンサルタントを雇ったと話す
  • 語り手が「また別のジュリアスだ」と泣き出すと、上司は自分もJuliusが恋しいし、この困難な時期を乗り切る助けになってくれただろうと答えた

1件のコメント

 
GN⁺ 2024-12-24
Hacker Newsの意見
  • Juliusに似たキャリア最適化型の人物を何度か見たことがあるが、説明するのが難しい。
    新しいチームに加わると、Peteというシニアエンジニアがいて、新製品の初期バージョンを作った天才として紹介される。ところがコードベースを開いてみると、デモ用にかろうじて動くスパゲティの泥団子で、ドキュメントもテストもなく、理解するだけでも時間がかかる。だが経営陣は「Peteは2週間で作ったのに、なぜ機能追加にこんなに時間がかかるんだ」と見る。
    経営陣に状況を説明しても、Peteを気に入りすぎていて批判を受け入れない。Peteは何度も会社を救った人物だと見なされ、実際には他の人たちが彼についていけないのだと判断される。結局、残った人たちがPeteの作っためちゃくちゃのコストを払い続ける一方で、Peteはもっと大きなプロジェクトへ移り、問題が明るみに出る前に昇進と昇給を手にして去っていく。このパターンはあまりに具体的で、意図的な行動に見える。こういう人を何と呼ぶのか気になる。

    • ああ、その人を知っている……それはまさに自分だ。
      20年ほど小さな会社で「コンピュータ関係の仕事」をしてきて、ネットワーク配線からサポート、プログラミング、管理業務まで何でもやってきた。今の職場では、たまに倉庫でフォークリフトも運転する。
      10年間同じ会社でソフトウェア生態系の大きな部分を作ってきたが、専門家として見れば、これはダクトテープでつぎはぎしたルーブ・ゴールドバーグ・マシンだ。何一つきちんと計画・実装・テストされておらず、金曜の午後に社長が「機能X / 問題Yの解決 / バグZが本当に急ぎだ」と持ってくることが多かった。その原因が以前の緊急パッチの副作用であることも珍しくない。
      それでも作ったし、動いている。社長には「このシステムは倉庫の裏に引っ張っていって銃で撃ち、苦しみを終わらせた方がいい」とよく言っていたが、とにかく動く。これからは船を乗り換えて昇進と昇給を確保するPete式の技術を学ぶべきなのかもしれない。
    • John Osterhoutはこういう人を戦術的トルネードと呼んでいる。戦術的なことしかやらないプログラマという意味だ。
      彼の著書『A Philosophy of Software Design』は、この問題の技術的側面を考えるための語彙をうまく与えてくれる。特に第3章「Working Code isn't Enough」が有用で、人を攻撃せずに問題に取り組み始められる程度の言葉を与えてくれる。
      こうした人たちの心理については単一の良い資料を見つけられていないが、彼らが属するシステムが、その行動を強化するフィードバックループを提供しているのは確かだ。Big Fiveのような性格モデルでは、秩序性のような要素も影響していそうだ。
    • これはPeteの問題というよりマネジメントの失敗に近い。
      Peteにできるだけ早くデモを作れと言ったのなら、彼はその仕事をしただけだ。実際、多くの場合、経営陣がそう指示すること自体は悪くない。プロダクト・マーケット・フィットを見つけることが、たいてい技術的負債より優先されるからだ。
      ただし経営陣は、ざっくり継ぎ合わせたデモを実運用システムに変えるのがどれほど長く難しいかを理解していなければならない。
    • 大企業でも似たパターンを見てきた。たいていは、マネージャーが「仕事をやり遂げる」と好む中堅エンジニアなのだが、実際にはコードの上を押しつぶして進むブルドーザーに近く、その横には「リリースしろ」と承認してくれる同僚がいる。
      彼らが「速く動ける」理由は、他の人が複雑さを抑えようと努力する一方で、彼らは抽象化に穴を開けて突き進むからだ。そうして昇進すると、元コメントのPeteになる。
    • 「問題が明るみに出る前に船を降りる感覚」は、要領の良さではなく、時間をかけて身につけた操作的な技術だ。
      同僚の犠牲の上で自分の評判を輝かせるやり方であり、Peteのような人たちは本当にひどい。
  • 結末はずっと前から見えていたが、文章がうまくて楽しく読めた。コンピュータサイエンスの准教授としては、この話にかなり共感する。
    大規模言語モデルは学生にとって複数の面で頭痛の種だ。最初は自分より優れているように見えて自信をくじき、そのせいで学生は学ぶより道具を使いたがるようになり、やがてそれが自己成就的予言になり始める。この技術が将来もたらす影響が心配だ。Juliusだらけの社会は長く続きにくい。

  • 素晴らしくて面白く、とても共感できた。
    中年に近づいて自分があまりにシニカルになったのかもしれないが、こうした現象は、企業で最終的な意思決定権を持つのがビジネス側の人間だから起きるように思える。企業は運営する人たちの自我と目標のために存在し、その観点では、技術力や誠実さよりも、事業成果を生み出したり上層部に印象を与えたりすることの方が重要になりがちだ。Juliusは、ただコードがうまいだけの哀れなプログラマたちより、その点ではるかに優れている。
    別の選択肢があり得ると信じたいが、世の中はこういう方向に進むよう強いインセンティブを持っているように見える。多くの人にとって最善なのは、あまり壊れておらず、個人の境界を尊重し、そこそこの給与をくれる職場なのかもしれない。そういう場所で働けることをありがたく思いつつ、別の可能性も夢見てしまう。

    • よくある反論は、「もしもっと良い選択肢、たとえば実際に物を作ることの基本を理解している人たちが運営する会社があるなら、怠惰で自己中心的なビジネス人間を競争で打ち負かすはずだ」というものだ。
      実際、そういう会社は数多く現れ、競合を圧倒したこともあったが、その後には自分たちが打ち負かしたまさにそのビジネス型の人間たちに内部から侵食される姿を見てきた。
      それを見ても何もできないのがもどかしい。Juliusは本当に多い。それでも、仕事がアイデンティティのすべてである必要はない。運よく正しい時と場所にいられたなら、一生ものの経験をしただろうが、そうでなくても構わない。今でも誇れる仕事はできるし、こういうことに振り回されすぎない方がいい。Juliusにはそういう選択肢がないのかもしれない。
    • 好むと好まざるとにかかわらず、Elon Muskは、市場が誰もを苛立たせる自閉的な技術リーダーにも報いることがあり得ると、かなりよく示してきた。
      Andrej KarpathyがElonのマネジメントスタイルを説明した最近のバイラル動画: https://www.youtube.com/watch?v=aSiJ4YTKxfM
      もちろんElonの欠点はよく知られており、崇拝すべきではない。ただ、従来の管理慣行がインセンティブによって必然的に決まるという主張には懐疑的だ。
  • この分野で Julius 寄りに生きるようになってから、ずっと幸せになった
    開発者やエンジニアは、ツールを自分の必要に合わせて非常に精密に調整できるので、他の人もそうできるはずだと考えがちだ。だが実際はそうではない。大半の人は、うまく機能しない技術的な継ぎはぎの解決策の中で生きていて、ソフトウェアがどう動くべきかについての期待値が極端に低い
    これを理解してから Julius になった。経営陣はソフトウェアがどう、なぜ動くのか、あるいは動かないのかを気にしない。彼らが欲しがるのは 自己啓発風の警句 とカリスマ性だ
    Julius を会議に送り込み、残りの人たちが問題を直すというくだりが特に刺さった。会議は役に立たないが、そこでみんなが握手し、関係を築く。そうして社交性の高い人たちが好印象を与える
    違いがあるとすれば、それでも自分はかなり仕事ができると思っていることだ。純粋な 達人級の開発スキル だけではキャリアのはしごは作られないという事実を認めているだけだ。むしろ邪魔になることさえある。皮肉っぽい反応なのかもしれない

    • 経営陣がソフトウェアがどう、なぜ動くのか、あるいは動かないのかを気にせず、警句とカリスマ性だけを求めるのなら、業界や 管理職の選抜方法、さらに広く言えば富と影響力と機会の分配のされ方に何か問題があるということだ
  • 実際に読む価値があり、とてもよく書かれた文章だ
    本物の Julius たち が存在すること、そして人工知能を職場に持ち込むために使われるメカニズムが、世の Julius たちが出世するために使うやり方と同じだと言っているように思える

  • 本当に最高だった。キャリアを通じて Julius たち にかなり多く会ってきた
    宇宙はそういう人たちを豊富に生み出して回しているようで、たぶんかなり気に入っているのだろう

  • 非技術分野では、こういう人たちは ごますり と呼ばれる
    元スポーツ選手だったり、機転が利いたり、見た目が良かったり、話がうまかったり、生意気なタイプだったりした。みんな無能だと分かっていたのに、感じが良いのでいつも切り抜けているように見えた
    プロジェクトで手に負えない状況になると、いつも誰かが付いて救ってやり、そのせいで他の人の仕事量を増やして恨みを買っていた。たいてい役に立ったのは彼らが昇進した瞬間で、その時からはこちらがプロジェクトを制御できるようになり、むしろ有用になった

  • うちも Julius を採用した。1年後の結果は、生産的な人たちは解雇され、口先だけの人たち は残り、売上は伸びず、稼いだ額より使った額のほうが多かった
    会社の残り資金は6か月分だ。Julius、いったいなぜなんだ。プレゼンは最高で、まるで映画を見ているようではあった

    • そういう状況の問題は Julius ではなく、彼を採用して貢献を誤って理解した マネージャーたち にあるのではないか
  • Julius は ピーターの法則 を繰り返し適用したようにも聞こえるが、そもそも一度も有能なレベルに達していないという違いがある
    洗練されているが無能な人だ

  • とても良くて、楽しく読んだ
    大学でも職場でも Julius をかなり多く見てきて、そのたびに自分のやっている仕事をなぜ気にかけるべきなのか、よく疑問に思わされた