ハクソク

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

アップルで初めて解雇されそうになった時

325日前原文(engineersneedart.com)

概要

  • 1995年、Appleの「QuickdrawGX」グラフィックスエンジニアとして入社した体験談
  • 68KからPowerPCへの移行に伴うColor Pickerの移植と新規開発
  • 複数のカラーピッカー（HSV, HTML, Crayonなど）の独自実装
  • イースターエッグとして詩を仕込んだが、著作権問題で危機一髪
  • その後もAppleで20年以上勤務し、新人への教訓となったエピソード

1995年Apple入社と初期の苦悩

  • 1995年10月、Apple にグラフィックスエンジニアとして入社
  • 当時は「 Apple危機説」が飛び交う時期
  • QuickdrawGX プロジェクトへの配属
  • カンザスからカリフォルニア への引越し体験
  • Appleのエンジニア達の 高度な技術力 に圧倒される日々

QuickdrawGXからColorSyncチームへ

  • QuickdrawGXプロジェクトの崩壊 後、ColorSyncチームに異動
  • Color Picker（カラーピッカー） のPowerPC対応が新たなミッション
  • 既存の 68Kアセンブリコード をC言語に書き直す作業
  • PowerPCの高速性 により、アセンブリ不要となる

カラーピッカーの独自開発

  • HSL/RGBカラーピッカーの コールバック処理 理解のため、独自実装を決意
  • HSVカラーピッカー を新規開発
    • アーティスト視点でHSVの方が直感的と判断
  • HTMLカラーピッカー も開発
    • RGB値を16進数で表示し、Webデザイナー向けに配慮
  • クレヨンピッカー も実装
    • 60色のクレヨン、色の直感的選択を重視
    • Crayola商標 やデザインの権利調査も実施
  • CMYKカラーピッカー も追加
    • 印刷業界ユーザーへの対応

Appleのエンジニア文化

  • エンジニア主導 で機能追加が進む社風
  • 自分が欲しいものを作る姿勢
  • マーケティングやデザイナーの指示なしで出荷決定

イースターエッグと著作権問題

  • イースターエッグ としてT.S. Eliotの詩をリソース名に仕込む
  • 公開されない隠し要素と考えたが、 著作権リスク を見落とす
  • OSリリース直前に 詩の引用が発覚 し、問題化
  • マネージャーと上司から厳重注意
  • 「 CDの焼き直しコスト」など現実的な被害も指摘される
  • 幸いリリース前に発覚し、 解雇は免れる

教訓とその後

  • 以降、 著作権や企業リスク への理解を深める
  • 新人エンジニアへの 反面教師的存在 に
  • Appleで20年以上勤務 し続けることに成功

新人エンジニアへのアドバイス

  • 独自性や遊び心 は大切だが、 企業のルールやリスク も理解必須
  • チームや上司への相談 を怠らない姿勢
  • 自分の失敗から学び、 次世代へ知見を伝える 重要性

Hackerたちの意見

なんかこの人、すごく従順に聞こえるよね。いたずらが特に悪影響を及ぼさなかったのに、なんでクビにならなかったのか不思議がってるの？部門の責任者がイラついてただけなのに。ここでの教訓はプロ意識を学ぶことだと思ってるのかな？権力に酔った理不尽な上司の世界を嘆くべきだよ。誰かが怒ったからって、正しいことの考え方を歪める必要はないよ。

└

CDの制作が中止になったみたいだから、実際には「悪影響がなかった」ってわけじゃないよね。でも、プロジェクトが中止になって新しいマネージャーが来るのは、いつも良い兆候じゃないよね。

└

いたずらが特に悪影響を及ぼさなかったのに、なんでクビにならなかったのか不思議がってるの？ 上司が怒ったからって、論理的に正当化されてるかどうかに関係なく、クビになることもある会社はたくさんあるよ。著者は従順というより、むしろ未熟な感じがする（それを自覚してるし、結構話してるしね）。 > 誰かが怒ったからって、正しいことの考え方を歪める必要はないよ。大人になるってことは、理想の世界と現実をうまく折り合いをつける能力でもあるんだよね。たとえ理論的には正しかったとしても、振り返ってみて自分の決定が最適じゃなかったと認めるのは、全然合理的だよ。これは「歪める」っていうより、人生を前に進めるってことだよ。

└

いたずらが特に悪影響を及ぼさなかったのに、なんでクビにならなかったのか不思議がってるの？ 著作権侵害の訴訟は実際にあって、違反した会社（Apple）や、潜在的な違反者として特定されたすべての関係者が含まれる可能性があるんだ。つまり、経営陣はこの人が非常に高額な訴訟に名前を挙げられないように助けた可能性があるってことだね。

└

これは1990年代の話。仕事に対する考え方が違ったんだ。この時代はまだ（ほとんど）「上司がジャンプしろって言ったら、どれくらい高く飛ぶか聞く」って感じだった。

└

カール・セーガンは、前年にAppleを訴えたんだ。彼の名前をプロジェクトのコードネームとして使っただけで、どこにも公開されることも顧客製品に含まれることもなかったから。ジョンは、まだ著作権があるテキストの抜粋をリソースフォークに入れて、顧客に出荷する予定だったんだ。実際、すでにディスクに焼かれていたしね。彼をクビにするのは過剰反応だったと思うけど、あり得る結果の範囲内ではあったね。

彼のインタビューに関するリンク記事もすごく面白かった！以前、機械工学のエンジニアが、タイプした履歴書の代わりに前のプロジェクトの印刷した写真を持ってインタビューに行ったら、うまくいったって話を聞いたことがある。誰かを面接したことがあると、面接官も面接を受ける側と同じくらい緊張してることが多いから、アイスブレイクは大事だよね。 https://engineersneedart.com/blog/interview/interview.html

イースターエッグを導入して、それを指摘された後、著者はこう言ってる：私は警告の例になってしまって、新しく入った人たちに似たようなことをしないように時々注意してたんだ。そして、約束通り、その日以降はApple本社が私の行動についてどう思うか、そしてその結果（意図的かどうかに関わらず）に気をつけながら、非常に慎重に行動するようになった。経営陣は、著者の組織に対する価値と、この特定の状況を修正するためのコスト（実際のものか、認識されたものか）を天秤にかけた可能性が高い。最終的に実現した追加の価値は、著者が「現場レベル」で組織の方針の延長になったことだ。私見だけど、これは最適な解決策で称賛されるべきだと思う。経営陣は20年のリターンを得て、著者は職を守ったんだから。

└

IBMの初期の頃に起こった話を思い出すな（少しバリエーションがあるけど）。ある男が高額なミスを犯したけど、トーマス・ワトソンは彼をクビにしなかった。「私たちはあなたを教育するのにお金を使ったばかりなんだから！」って言ったんだ。人は失敗から学ぶもので、それが最高の教訓になることもある。

└

最適な解決策とは言えないけど、そもそも管理側の完全な過剰反応だったからね。オプションとしては、著者に「ここではそれは受け入れられないから、もうやらないでね」と優しくでもしっかり伝えることだったと思う。そんな小さな事件で彼の上司が大声で叱る必要はなかったよ。

この投稿の著者はHNでの常連コメント者、JKCalhounだよ。いい投稿だね、JKCalhoun！Dithering Heightsの壁にぶら下がってる三十数個のドングルが好きだよ。Coplandのビルドに含まれていたこれらのカラーピッカーのバージョンには、「Hey what?」（HSLピッカー用）や「Scheherazade」（クレヨンピッカー用）って文字列が含まれてたんだ。もしかして、これらは君のものだったのかな？ https://rezmason.net/chattin_with_jkcalhoun/copland_colorpic...

└

彼は自分のことを「マッキントッシュ用のゲームを書いていた」と言っているけど、それは控えめすぎるよ。彼は「グライダー」を書いたんだから！

企業の法務部だけが、80年前の詩の一節を12のリソース名に隠すことに対してパニックになるなんて、ありえないよね。もしそれがフェアユースじゃないなら、そうすべきだと思う。

└

その使用がフェアユースに該当するかどうかを裁判所で争うことになりたくないよね。「フェアユースであるべきか」という立場を取るのは、会社のリソースの使い方じゃない。

これはクラシックなソフトウェアエンジニアリングの例だね。コードを書く人が、なぜそれをやっているのかを理解して、成功させて、ちょっとした遊び心を加えて、結果的に製品が素晴らしくなるって感じ。強力なプロダクトリードの重要性を否定するわけじゃないけど、この記事で示されているような才能や規律がないエンジニアのための一時的な対策になってることが多いよね。（イースターエッグは別として。）

└

製品リードを置くことの意図的な結果の一つは、エンジニアが製品を完全に理解できないようにすることなんだよね。これは階層に組み込まれた政治であって、「才能や規律が足りない」わけじゃない。

著者の質問に答えると、クレヨンピッカーが最高だから！本当に役立つんだよね。この記事でも触れられているけど、これはソフトウェア開発の別の時代だったんだ。1995年には「出荷する」っていうのは文字通り「出荷する」ことを意味してた。実際の在庫を作って、いろんな流通チャネルに出さなきゃいけなかったんだ。問題のあるイースターエッグが遅すぎるタイミングで見つかると、実際に物理的なリコールが必要になることもあった。だからみんながパニックになるのも無理はないよね。

└

それと、1980年代後半には、少なくとも一つの科学的なグラフィックスパッケージがあって（BSD4.3の下でmicrovaxenで使ってた）、クレヨンベースのカラーピッカーがあっただけでなく、簡単なキャリブレーションメカニズムとしても使われてたんだ。安いクレヨンの箱を買って、画面の色を合わせることができたからね。だから、「クレヨラがこれで訴えてくることはないだろう」という現実的な証拠があったんだ。名前は忘れちゃったけど、覚えているのはウィンドウが0.0-1.0の浮動小数点でサイズ指定されていて、ピクセルじゃなかったこと。調べてみると、PHIGSかGKSだったかもしれないし、1992年にFoilTeXがクレヨラの色名を使っていたというTugboatの記事も見つかったから、当時思っていたよりも人気のあるハックだったみたい。

└

昔は、ソフトウェアのアップデートや修正をするために、技術者をお客さんのオフィスに飛ばさなきゃいけなかったんだ。あのバグを直すのはめっちゃ高くついてたよ！

一般の人々（ソフトウェアエンジニアも含めて）って、映画みたいに大失敗したら即クビになる可能性を過大評価してると思う。もしその失敗が（1）悪意のあるものでもなく、（2）仕事に対して明らかに無能を示すものでなければね。ほとんどの大失敗は、善意で知識のあるソフトウェアエンジニアが単に誤りを犯した結果なんだ。会社や管理側から見れば、正しい対処法はその失敗をした人をクビにすることじゃなくて、修正する機会を与えること（他の人の助けを借りることも含めて）だよ。実際、ほとんどの場合そうなる。もちろん、こういう状況で誰かをクビにするような管理がひどい会社もあるけど、そういうのは少ないはず。具体的な名前は出さないけど、2000年代後半から2010年代初頭にかけて、当時の最も注目されていた急成長中のテックスタートアップで働いてたことがあって、そこで私は実際に数百万件のユーザーレコードを壊すようなミスを犯したことがある。この事件は社内では会社の歴史の中で最も厄介な技術的な出来事の一つとして知られていた。製品の性質上、データの更新が非常に速く行われていて、更新は重要だった（例えば、ユーザーの支出に影響を受ける）。だから、前日のDBバックアップから復元するのは現実的じゃなかった。私たち全員が数週間かけてユーザーのデータを手作業で修正し、ユーザーが製品を使いながら修正するためのアルゴリズムやコードを考え出さなきゃいけなかった。で、予想通り、私はクビにならなかったし、この事件の後もユーザーデータを修正するために懸命に働いたチームの一員だった。そして、その後の数年間、会社で良いキャリアを築いていったよ。

└

雇用の種類によって、基準やリスクレベルが違うと思う。皮肉なことに、最低賃金のファーストフードの仕事からクビになるのは、Googleの六桁の給料の仕事からクビになるよりずっと簡単なんだよね。

└

ヨーロッパのほとんどの国では、アメリカや労働法が弱い国のように、気まぐれで人をクビにするのは確かに難しいよね。初めてヨーロッパのチームを率いるとき、そういう国のチームマネージャーから困惑した表情をよく見かけるし、彼らが何かクレイジーなリクエストをしても、いつもNOが返ってくる。

└

「一般の人々（ソフトウェアエンジニアも含めて）が、大きなミスを犯して解雇される可能性を過大評価していると思う。この誤解は、労働者保護が強い国でも管理職によって広められているのを見た。特に、強い労働倫理や内面的な不安を持っている人には効果的で、それが火に油を注ぐんだ。従業員は、失敗が解雇につながるかもしれないと思って、特に緊急時には必死に働く。そういう管理職は、これを「モチベーション」ツールとして使う（顔にハンマーをぶつけるようなモチベーションだけどね）。彼らはチームからもっと成果を引き出して、昇進を狙ったりする。人々がそのプレッシャーが多くの場合は偽物だと理解するのを見るのは興味深い。内部のSLAですら、彼らが恐れているよりもずっと緩いことがあるから。」

脱線するけど、フラットなUIについて文句を言ったり、ベゼルのある昔の良き時代を懐かしんだりしてるけど、あの昔のカラーピッカーは本当にフラットだよね！

└

あの頃は、良い時代とは言えなかったな。

特にビジネスが厳しい時に、「低い地位の開発者」が意見を持っていて、もっと良いものを目指すことがどれだけ脅威になるか、想像できる？現実を見ようよ。製品の結果に最も直接的に関わっていて、知識があるのは開発者以外に誰がいる？もし一生懸命働いていないなら、意図的であれそうでなかれ、製品を誤って表現していることになるし、愚か者だよ。これは常に真実で、投資家ほどそれをよく知っている人はいない。私たちがバカだと思ってるの？

└

これは常に真実で、投資家ほどそれをよく知っている人はいない。私たちがバカだと思ってるの？えっと、えぇ…い、いやぁ…