ハクソク

世界を動かす技術を、日本語で。

「アルトワイズ」を一握り

245日前原文(scottsmitelli.com)

概要

  • 日常の違和感 と 仕事の虚無感 を描写
  • 同僚Jim の奇妙な行動が話の軸
  • “cat turds” というメタファーで仕事の辛さを表現
  • エンジニアの業務の抽象性 と孤独感
  • やりがいの喪失 と現状維持の苦しみ

バーでの奇妙な会話

  • 仕事終わりの 賑やかなバー での出来事
  • Jim が突然「Altoids（ミント）」の話を始める
  • 話の前後を確認するが、 話題がかみ合わない 違和感
  • Jimが カバンからミントを取り出し、食べ方を実演
  • その後、 “cat turd” （猫の糞）を食べたと告白
  • “Spearmintが味を隠す” という説明で、さらに混乱
  • もう一度食べる提案を断る主人公
  • Jimは 「Altoidsが仕事のやり方を変えた」 と語る
  • 「君もcat turds食べるよね？」 と問いかけるJim
  • 「みんなそうだ」と繰り返すJimの言葉が主人公の頭で反響

“cat turds”の意味と日常への投影

  • 信号待ち中、 主人公は仕事のことを考え始める
  • 抽象的な技術用語 や 複雑な業務フロー への苛立ち
  • 業務内容を一般人に説明できない もどかしさ
  • 自分の仕事が実体のないもの に感じられる虚無
  • 小さな設計の違い や 仕様変更 で悩む日々
  • CIやPR、Jira など、現代エンジニアの苦悩を象徴
  • なぜこの変更が必要なのか という根本的な疑問
  • 「質問は摩擦を生む」 という職場の空気
  • 現状維持のために流される日々 の繰り返し

やりがいの喪失と虚無感

  • 「この問題を解決したくない」 という本音
  • 知的満足感の欠如、仕事への興味喪失
  • 「そもそもこんな事態が起こるべきでなかった」 という嘆き
  • 身体的な疲労感 と 精神的な消耗
  • 出口の見えない日常 への無力感

この物語は、 現代の知的労働者 が感じる 仕事の理不尽さ と やりがいの喪失 を、 シュールなメタファー （“cat turds”）を通して描き出す。 エンジニアリングの抽象的な苦悩 と、 職場での孤独感 がリアルに伝わってくる作品。

Hackerたちの意見

すごく良い読み物だった。ずっと心の中でモヤモヤしてた感情を美しい文章にしてくれた感じ。もしかしたら、裏にペイントする価値のあるキャビネットを探すべきかも。

└

ソフトウェアエンジニアが副業で木工をやる理由ってあるよね。実際、2000ポンドのうち、10人か12人見つければいいだけなんだけどさ。真面目に取り組んで楽しむ気持ちを持てば、工場で作るのにかかる時間の10倍で素晴らしい作品が作れるんだよ。でも、自分のやり方で、細部にまで気を使ってね。裏面をいい木で作って、塗装することもできるし。誰にもバレない、それは神様との秘密だよ。

まあ、推測するってことは、君と僕が「う」と「み」を作るってことだね。これが俺のタイプのユーモア、カタルシスな読み物だ。

└

『ロング・キス・グッドナイト』で、サミュエル・L・ジャクソンが言ってた。「仮定をするってことは、君と…そして…UMPTIONを作るってことだ！」

なんか、すごくリアルな感覚があって…この問題を解決したくないんだ。旅の終わりに知的な報酬なんてないし、興味も湧かない。これは直すべきことじゃない。そもそもこんな状況が許されるべきじゃなかったんだから。これはただ、広い状況がそうさせるから、俺が乗り越えなきゃいけない作り物のナンセンスなんだ。解決策が良いかエレガントかなんて関係ない。ほとんど機能しないかもしれないし、3週間後にまた別の問題を引き起こすかもしれない。それでも、ただやらなきゃいけないことなんだ。技術者として、これが本質だよ。俺たちがやりたいのは、素晴らしくて速くて効率的でパフォーマンスが良くて安くて洞察に満ちていて最適化された何かを作ること。でも、政府やビジネス、顧客、マネージャーや同僚、クライアントみたいな人たちと向き合わなきゃいけない。結局は、人間の非合理的な好みもあるしね。だからRMSやエッジガーが多くの人に魅力的なんだ。こういう状況だと、「もういいや、自分のやり方でやる！」って言いたくなるよね。

どのチョックファックにこのデザインの責任を押し付けようか一瞬考えたけど、正直言って、ここでの自分の時間に疑わしいプルリクエストをたくさん承認してきたから、この状況のかなりの部分は自分のせいなんだよね。これ、本当に実感する。反対しない個々の変更が、徐々に悪化させて、最終的にはゴミの山になる。だけど、誰かの変更を止めたいと思う？彼らはビジネスのために問題を解決してくれたし、後で片付けるのに1時間しかかからないかもしれない。けど、後でなんて来ないんだ。ハックは別のハックの上に積み重なって、その1時間の改善が今や1週間のリファクタリングになる。誰もそれを正当化できない。これを何度か繰り返すうちに、コードの明確さのために変更をブロックするタイプの人間になってしまう。周りの人からは細かいことにこだわる奴だと思われる。そうなると、仕事を進めるのを止めているアホになっちゃう。今回は見逃してもいいのかって自問自答する。これを繰り返す。

└

これについてよく考える、「逸脱の正規化」ってやつ。https://en.wikipedia.org/wiki/Normalization_of_deviance ちゃんとお金ももらってるはずなのに、品質を下げろって延々と言われるのは本当にイライラする。「コントロールされた反対派」ってことだね。

└

「本当にそう思う。誰かの変更に対して反対しないと、少しずつ、徐々に悪化していって、最終的にはゴミの山になっちゃう。でも、誰かが変なコードを書いたからって、その変更を阻止したいの？結局、彼らはビジネスの問題を解決してるし、後で片付けるのに1時間しかかからないかもしれない。ハッキーなコードがきちんと管理されてるか、悪影響を広げてるかによるけどね。そこで、技術的負債のチケットへの参照をコードに追加するようにお願いするのがいいと思う。そうすれば、良いプラクティスじゃないって明確になるし、チケットが実際に作成されることを確認できるから。半分の時間は、それをお願いするだけで問題が解決することが多いよ。チケットを作るより簡単だから。> 後回しは来ない。ハックは他のハックの上に積み重なっていくし、その1時間の改善が今や1週間のリファクタリングになっちゃう。誰もそれを正当化できない。でも、時にはそれも仕方ない、ソフトウェアのライフサイクルだから。ビジネスがメンテナンスをスケジュールしないなら、メンテナンスは自分でスケジュールされる。良いエンジニアの仕事は、ビジネスタイプに知識を持たせて、彼らに決めさせることだよ。

└

これはコードだけじゃなくて、組織にも当てはまるよね。子供の頃、猫のうんちをたくさん食べてた。大学の時もいっぱい食べて、それからロンドンの猫のうんち工場で働くことになった。最悪だった。猫のうんちを食べるのをやめて、キャンディ工場を始めることにした。最初の数年は、いいキャンディを作ってた。だけど、徐々に10年かけて、クライアントが猫のうんちを求めるようになって、少しずつ製品にうんちを増やしてキャンディを減らしていった。その過程で、また猫のうんちを食べる羽目になった。スタッフに配ったり、投資家がみんながまだうんちを食べてるか確認しに来たりして、私はスタッフの消化不良を防ぐためにできるだけ食べた。10年後には、フルスケールの猫のうんち工場が出来上がってた。毎日起きて、何千ものうんちを飲み込み、夜はそれを吐き出して、結局、食べられる量には限界があるってことがわかった。最終的に体が壊れ始めた。猫のうんちだけでは生きられないんだよね。だから辞めて、今はたまに猫のうんちをつまむくらい。工場は今も元気にやってる。私が辞めた後、うんちを食べることに気づかなかったスタッフはクビにされて、コプロファジーを雇って、成功した猫の下痢製品を作るようになった。

└

「でも、誰かの変更を阻止したいの？変な、ハッキーなコードを書いたからって。結局、彼らはビジネスの問題を解決してるし、後で片付けるのに1時間しかかからないかもしれない。今こそやるべきじゃない？アイデアはいいけど、コードは改善が必要だってメモを添えて拒否するのはどう？「スタイルに合わない」みたいな反応で。貢献者にアップデートさせて、後で1時間かからないようにするんだ。今1時間かけよう。」

└

ああ、これにちょうど対処したところだ。コードをレビューして承認したら、同じコードが移動してきた。差分がすごい。「なんでこれが移動したの？」って思ったけど、もうどうでもよくなった。インデントもおかしいし、指摘したいことがたくさんある（そう、リンター/フォーマッターを使って）。他の人はLGTMって感じで済ませるけど、私は実際にレビューしてるから面倒くさい存在だよ。これはあまりレビューされてないけど、雰囲気で作られたPOCだからね。

これは、ここ数年で最も共感できる読書体験だった。まるで「スタンド・バイ・ミー」のコンピュータ版みたい。

面白い事実だけど、アルトワイズは消化不良の治療に結構効果的なんだ。食べ物を飲み込むのがうまくいかない食道の人たちにとってね。

「手段の完璧さと目的の混乱が、我々の時代を特徴づけているようだ。」 - アルバート・アインシュタイン

若い頃に自分がシニアエンジニアだったチームの人たちには申し訳ない気持ちだよ。あの頃は理想や信念に満ちてた。「いや、それはやらないよ。ちゃんとやるから。」ってね。自信満々だった。「ほら、これちょうだい。自分でやるから。」って。今思うと、ほんとに調子に乗ってたな。痛いところを突かれた気分。若い頃だけがそうだったらいいんだけど、キャリアの後半でもその態度を引きずってたんだよね。

「まるで、ボードウォークのアーケードのクレーンゲームで持たれたメスで手術をしているような気分だ。プロジェクト管理のカモメたちの絶え間ない鳴き声と糞まみれで。ハハ、これはローカルでテストできないコードを書くときの気持ちをうまく表現してるね。無数のパイプラインを通ってエラーが出るまで待たなきゃいけないんだけど、そのエラーが自分のコードに関係ないこともあるし、時には単純なインフラの問題だったりする。」

他の人も自分と同じくらい不機嫌になれるって知ると、なんか安心するけど、あんまり健康的じゃないよね。たまに考えることなんだけど、数学の抽象概念ってすごくエレガントだよね。それを学ぶのが、数学を勉強する楽しさの60%くらいだと思う。でも、それを考えたり洗練させたりするのに何百年もかかったんだよね（場合によっては何千年も）。その間に、変な証明を書いたり、 awkwardで間違ってることも多い証明を試したり、うまくいかないアイデアを捨てたりしてたんだ。今でも、πを使わなきゃいけないのにτを使いたいみたいなこともあるし。ソフトウェアはまだ100年も経ってないから、最終的にはかなりエレガントで理にかなったものになると思う。それまでは、思いつくアイデア（yamlテンプレートとか）を試して、何が良いか探ってる感じだね。AIがプログラミング言語を発明して、それを使って数十年分のソフトウェア開発を再現してデザインアイデアをテストできるようになったら、もう最後のステップに進めるんじゃないかな。

└

AIがプログラミング言語を発明したら、たぶん人間向けじゃなくてAI向けになるだろうね…。