ソフトウェア開発者の告白: もう自己検閲はしない

 (kerrick.blog)
27 ポイント 投稿者 GN⁺ 2025-11-30 | 1件のコメント | WhatsAppで共有
  • 数か月間、恐怖のために執筆とオンライン活動を止めていた開発者が、自己検閲をやめ、これまで認められなかった技術的・個人的な不足を告白する文章
  • ポリモーフィズム（polymorphism）の概念を10年以上理解できておらず、SQLの腕も失い、大半のコードを自動テストなしでデプロイしてきた事実を認める
  • 会社の技術スタック変更に合わせようとしてC#とBlazorの学習を中断したこと、今もRubyを愛しているのに仕事では使えない現実、そしてマネージャーや同僚がブログを読む状況で感じる心理的負担
  • AIで書いたPRを提出した後にサイバーいじめを受けた経験と、リモートワークに対する率直な感情、および組織内の独自開発プロセスの不要さについての率直な意見
  • 恐怖を手放し、これ以上自己検閲せずに継続的な学習と公開の文章執筆を続けていくという決意で締めくくられる

始まり: 恐怖と自己検閲をやめることにしたきっかけ

  • 4月以降、恐怖が大きすぎて文章を投稿できなかった時期があり、ソーシャルメディア、ニュースアグリゲータ、フォーラムまですべて断っていた
    • この状態をこれ以上引き延ばせないと感じ、恐怖を越えて再び書くことを決めた
  • 足りない基礎を見せたくなくて固く隠してきたが、実際には多くの開発者が似たような知識の空白を抱えたまま働いていることに目を向けるようになった
    • これまでの学び方は、使う領域だけが肥大化するスライムモールドに似ており、使わなかった知識はそのまま干からびていた
  • 最近また基礎を埋め直し始め、学んだ内容を文章や言葉で再構成しながら、「知らない」と軽く認める感覚が身についてきた
  • 基礎はまた学び直せるという確信を自分で実感し、遅すぎることはないという感覚が生まれた

ポリモーフィズムを10年以上理解できなかった時間

  • 2012年からオブジェクト指向のコードを書いているつもりだったが、つい1年ほど前までポリモーフィズムをきちんと理解していなかった事実を自分で認めるようになった
    • これまで書いてきたコードは、オブジェクト指向というより構造化プログラミングに近かった現実に向き合った
    • 条件文をクラスに置き換えて設計を変える発想は、一度もしたことがなかった
  • Sandi Metz の文章や Martin Fowler の資料を見て、遅ればせながら概念を理解し、その間に見落としてきたものがあまりにも多かったことが明確になった

  • この事実を明かしにくかった理由

    • 採用面接でオブジェクト指向の概念を見る役割を担ってきた人間が、当のポリモーフィズムを知らなかった事実を明かすのはつらかった
    • キャリア初期に原則よりもツール中心の学習に偏っていたことがそのまま露呈し、CSを専攻していない背景のせいで見落としてきた基礎があまりにも多いという事実に向き合うのは容易ではなかった

SQLを忘れてしまった経験

  • かつてはSQLの本に沿って練習問題を解き、JOINやサブクエリを手際よく書いていた時期が確かにあった
  • フロントエンド中心の実務が続き、SQLを書く機会が完全になくなると、ある瞬間にひとつの技術全体が頭の中から消えていた事実に気づいた
    • 基本的なクエリは思い出せるが、left join と outer join の違いを説明するには文書を開き直さなければならない状態になっていた

  • この事実を認めにくかった理由

    • 若い頃は、何年たっても事実や技術は小さなヒントさえあれば蘇る記憶力を自分が持っていると信じていた
    • 今ではその能力がそのまま維持されていない現実を実感しており、記憶から丸ごと抜け落ちた最初の技術がSQLだったことが大きく響いた
    • 年齢を重ねることと記憶の変化を公に書くのは簡単ではなかった

自動テストなしで開発してきた現実

  • これまでデプロイされたコードの95%以上が自動テストなしで本番運用されている事実を自分で認める
    • キャリア初期にはテストという概念に触れることがなく、Ember の時代にはテストツールをきちんと活用するのも難しかった
  • 最近はレガシーコードを扱うことが多く、コードをテスト可能にするための準備作業に十分な時間を割けていない
    • 新しく作るサブシステムでだけテストを添えられた

  • この事実を明かしにくかった理由

    • この告白はキャリアにおいて最も致命的な事実だと感じるほど重かった
    • Uncle Bob の基準では、テストなしで本番運用されるコードは非倫理的とみなされ得る態度であり、その基準と自分の現実のあいだの隔たりに向き合うのが怖かった
    • この事実が公開されれば、採用プロセスで不利な判断につながる可能性が高く見え、学習過程の記録そのものを先延ばしにしていた

Blazorを学べなかった理由

  • 会社が Angular から Blazor へ移行すると決めたとき、チームで C# の経験がない唯一の人だったため、急いで追いつくために勉強を始めていた
  • 数か月後に移行の決定が撤回されると、学習の動機がまるごと消え、本も最後まで読み切れずに止まった
  • もともと C# や .NET はサイドプロジェクトで使いたい言語ではなく、純粋に仕事のためだけに学んでいた流れがそのまま表れた

  • この事実を書きにくかった理由

    • 前の文章で続編を書くと自分で約束していた状態で、その約束を守れないまま別の文章を書くことが次第に居心地悪く感じられた
    • Blazor 関連の記事が高い閲覧数を記録していたため、方向転換した事実を認めることが敗北のように見えるのではないかと恐れていた

Rubyをもっと使いたい気持ち

  • Ruby は今でも最も気楽で楽しい言語であり、サンプル、オープンソース、カタ、ハッカソンなどで自然に手が伸びる言語だ
  • しかし2013年以降、Rubyで給与を受け取ったことは一度もなく、業務では TypeScript のような言語を使っている
  • 複数の会社で一緒に働いてきた同僚たちがあまりにも好きで、人を選ぶ代わりに言語では妥協する選択を続けてきた
  • 退勤後や週末の時間を Ruby に使いたいが、ほかの義務や学習目標に押され、Ruby を十分に使う時間がほとんど取れない現実が続いている

  • この事実を明かしにくかった理由

    • マネージャーと CTO がこのブログを見ているため、Ruby をもっと使いたいという言葉が退職のサインとして読まれるのではないかと恐れていた
    • 会社で不慣れな言語を無理に押し通そうとする人にも見られたくなかった

大人になってもつらいサイバーいじめの経験

  • あるオープンソースプロジェクトに LLM で作った小さなパッチを提出し、その経験をオンラインフォーラムで共有したとき、
    無能、気持ち悪い、脅威だといった人格攻撃が一気に浴びせられる状況に直面した
  • この攻撃はサイト内にとどまらず、ほかのウェブサイト、メール、SMS、電話にまで広がり、安全ではないという感覚を直接抱くようになった
  • フォーラム管理者に実名を消してほしいと頼んだが、むしろさらに多くの個人情報がプロフィールに付け加えられ、
    外部連絡の話をでっち上げたという虚偽の文言まで恒久的に刻まれる状況に向き合うことになった
  • 結局、アカウントを無効化してサイトを去るしかなかった

  • この事実を書きにくかった理由

    • 数日間続いたいじめは最も毒性の強いオンライン体験であり、今もその余波が残っている
    • この話を公開すれば、加害者たちが再びやって来るかもしれないという恐怖が続いている
    • プロフィールに残った虚偽情報が雇用に悪影響を及ぼす可能性まで思い浮かび、ますます語りにくかった

SaaSチームに「特別なプロセス」は不要だという考え

  • ソフトウェア業界には数十年かけて磨かれてきたプロセスがすでにあり、
    Agile、Lean、Kanban、XP のような方式はすでに検証済みの構造として存在している
  • 限られた会社の能力を新しいプロセスの創案ではなく製品開発に集中すべきだという判断が自然に根づいた

  • この考えを言いにくかった理由

    • 文章を書くときは常に自分がよく知っているテーマに基づいて書く習慣があり、この場合は同じ会社の同僚が提案したカスタムのソフトウェア開発プロセスがきっかけだった
      • 特定の同僚やそのアイデアを公に批判する文章のように見える危険があると感じた
    • Kent Beck や Martin Fowler のように、より良い協業のあり方を説明しながらも、同時に失敗した同僚を正面から狙い撃ちしない文章力がうらやましい
      • 自分にはまだそうしたバランス感覚が十分にないと感じ、書くことをためらった

リモートワークが実際の協業を妨げる仕方

  • リモートワークは多くの問題を解決してくれるが、ソフトウェア開発そのものは同じ空間にいるほうがうまく回るという感覚を拭えない
  • ビデオ通話は低帯域・低感覚のコミュニケーションであり、周辺的な認識を失うことで同僚の困りごとを察知しにくくなる
  • 助けを求めること自体もより負担が大きく、ホワイトボードや付箋のような空間的思考がオンラインツールでは簡単に崩れてしまう
  • 対立は、モニター越しの相手に敵のイメージを投影しやすい特性のため、より早く深刻化する

  • この話を書きにくかった理由

    • コロナ以降は完全リモートの会社になり、そのおかげで27エーカーの土地と家族用の乳牛までいる暮らしを築けた
    • 都市へ移るのが難しい生活構造になってしまったため、リモートワークを好まないと言うことが、
      現在の職場や今後応募するすべてのリモート職に不利な印象を与えることのように感じられた

今後の計画

  • 今回の文章で恐怖を越える最初の一歩を再び踏み出せたと感じており、
    これからも基礎学習を続け、学んだことをすべて隠さず書いていくつもりだ
  • 似た経験のある人、助けたい人、次の文章が気になる人に向けて、
    Mastodon、RSS、メーリングリストを通じて知らせを受け取れるよう案内している

関連記事

1件のコメント

 
GN⁺ 2025-11-30
Hacker Newsのコメント
  • とても頭の切れる同僚から学んだことがある。彼は知らないことを恐れず、理解できるまで質問し続ける。人前で学ぶために必要な自信と忍耐は本当にすごいと思った
  • この記事の謙虚さと率直さが気に入った。知らないことを恥じる必要はない。37年間学び続けているが、今でも新しいことを身につけている。
    私もオフィス勤務のほうが好きだが、それはRTO（オフィス復帰）を擁護しているわけではない。単に自分の性向というだけだ。
    業界の    不安感とインポスター症候群    が人を攻撃的にしているように見える。みんながもっと正直になれば、少しは楽になる気がする。
    それと告白すると、LispやHaskellでFibonacciより複雑なものを書いたことがない。頭があのやり方では動かない
    • あなたのリモートワークに関する意見には反対だが、それを個人的な意見として述べているなら問題ないと思う。
      ただ、元の記事は自分の経験を客観的真実のように一般化して書いている。特に二人称の語り方が傲慢に感じられた。
      どう言うかは内容そのものと同じくらい重要だ。リモートワークのような敏感な話題ほど、表現には慎重であるべきだ。
      私も家族の健康問題のためにリモートワークをしなければならなかったので、記事の口調が軽く感じられて腹が立った。
      結局のところ、人々が過敏に反応していると言う前に、自分の表現がどんな影響を与えるかをまず振り返るべきだ
    • 私もLispベースのプロジェクトに参加する前は、Fibonacci以上のものは書けなかった。毎日使っているうちに、結局慣れた
    • リモートワークを好むと言うと叩かれる理由？ コロナ以降に自由を得た人たちが、また拘束されると感じているからだと思う。だから反発が強いのだろう
    • 最近のYouTubeコーディンググルは何でも自分が正しいと言う。何をやっても間違っていると言われる世界だ
  • リモートワークの話を聞くたびに、IRC時代が恋しくなる。当時はすでにリモートでの協業がうまくできていた。
    廊下での会話の代わりにチームチャットで問題を解決し、みんなが積極的に助け合っていた。
    今はむしろツールをうまく使えていない気がする
    • 最近は公開チャンネルに書き込むのを恐れる人たちが多い。昔は匿名性があったが、今は実名ベースなのでより慎重になる。
      匿名で話せる場所が減るにつれて、自由に話しにくい文化が生まれている
    • 昔はオフィスでSlackを使っていたときのほうが、今よりずっと効率的だった。
      あの頃は失敗してもただ隣の席に行って解決できたが、今は失敗したらそこで終わりだ
    • コロナ期のリモートワークは本当のリモートワークではない。隔離状態だったし、文化やプロセスも整っていなかった。
      だから人々は孤独をリモートワークのせいにした
    • 変化の原因は人口動態よりも性格的な変化だと思う。昔は「変わり者の子たち」が多く、彼らは質問を恐れなかった。
      今はより社会的に調整された人が増えて、非同期コミュニケーションに弱くなっている
    • チャットでバグを直すのは、「同じ空気を吸っている」こととは違う。
      非言語的シグナルを読み取る密度が低いので、社会的な手がかりが減ってしまう
  • 同じSaaS業界にいても、まったく別の世界に住んでいる気がする。
    多くの開発者が興味よりキャリアパスに従っている。
    SQLは三度も学び直した。技術は変わり続けるから、すべてを覚えておくことはできない。
    重要なのは文法ではなく、問題を解決する能力と協働する力だ。
    AIがこれを代替するのは難しいと思う
  • 私が書いたコードの95%は**テストカバレッジ0%**だった。いくつもの国、いくつもの会社でそうだった。自分だけなのか気になる
    • 自動テストは、反復的な開発において自信を与えてくれる道具だ。一度身につけたら、もう戻れない
    • 私も似たような感じだったが、今は変えようとしている。テストのないプロジェクトに後から追加するのは本当に難しい
    • テストは過大評価されている面もある。誤った安心感を与えることもあるし、言語自体がテストに向いていない場合も多い
  • 周囲で働く人たちの雰囲気が集中を促してくれる。
    集中の伝染効果がある。いっしょに働く空間は生産性を高める
    • 私も同じタイプだ。でも会社が**「クリーンデスクポリシー」**を強制してくるので不便だ。個人化された環境が必要だ
    • 活気のあるカフェでも似たような効果を感じる。他人の生産性が自分を刺激する
    • これは**ADHDの「ボディダブリング」**に近い概念だ
    • 私もオフィス勤務を好むが、ドアのある空間が必須だ。
      ドアは協業と集中を調整する最高の道具だ。
      オンラインの「away」状態よりも、物理的なドアのほうがずっと明確なシグナルになる
    • だが、誰もがそういう環境でうまく働けるわけではない。
      誰かの集中のために、他の人を無理やりオフィスに呼び戻すのは非人間的だ
  • この記事は勇敢だ。だが、個人的経験を一般化する問題をよく示している。
    リモートワークが悪いのではなく、支援体制の悪い会社で働いた経験なのかもしれない
  • 著者は自分に厳しすぎる。知らないことを認めるのは解放感を与えてくれる。
    私も「わからない」とよく言う。それはEQの高い人の特徴だ
    • 上司は私が「わからない」と言うのを好んでいた。正直さが信頼を作る
    • 職場では問題ないが、オンラインでは評判への不安のせいで「わからない」と言いにくい
    • 面接でgit rebaseについて尋ねるときは、技術的な細部より実際に使いこなせるかのほうが重要だと思う
  • 著者の率直さが良かった。私にも似た経験がある。
    Kotlinでライブコーディングしていたとき、switch構文が思い出せずに焦った。
    毎日使っている言語でも、あっという間に忘れてしまうことがあると気づいた
    • 私もswitch構文は毎回調べる。あまり使わなければ忘れるのは当然だ
    • 年配の開発者が増えれば、こうした**「忘れてしまう瞬間」**にももっと寛容になる気がする
    • 誰でもミスはする。上司でさえ、貼り付けのショートカットを忘れることがある
    • あまり使わなければ技術はすぐ衰えるが、また使えばすぐ戻ってくる。
      概念は長く残るが、細かな構文はすぐ消える
  • 最初はこの記事がAIによる開発者消滅を扱うのかと思った。
    だが実際には、その不安を口にすること自体が難しい空気がある。
    私もClaudeでコードを書いて楽しんでいるが、同時に恐れもある。
    私たちがこれから来る変化の本質を最もよく知る世代なら、それについて議論すべきだ
    • Claudeが作るコードが人間のコードより優れているわけではない。ただ生産速度を上げてくれるだけだ。
      問題は、それが実力のない人たちの生産性だけを高めることになるかもしれない点だ
    • 今後数年は、私たちはAIエージェントのチームリードとして残るだろう。
      だが企業がAIを管理者役として使い始めれば、人間の開発者の居場所は狭くなる。
      今からAI効率コンサルタントのような役割への転換を準備すべきだ
    • 私はただAIと協働するか、別の面白いことをするつもりだ。プログラミングだけがすべてではない
    • 「AIドゥーマー」ポリシーがある会社なんて、有害な組織文化だ。今すぐ転職先を探すべきだ