  |
はてなキーワード:プログラマーとは
tmux（ターミナルマルチプレクサ）が「苦行」と感じられる理由は、その学習コストの高さ、特有の操作体系、そして初期設定の手間が大きな要因です。非常に強力なツールである一方、使いこなすまでに多くの試練があります。
具体的に、なぜ苦行とされるのか、その主な理由は以下の通りです。
Prefixキー（Ctrl-b）の壁: 全ての操作の前に、必ずCtrl-bを押す必要があります。これが直感的ではなく、操作数を増やします。
デフォルトキーが非直感的に: 画面分割やウィンドウ切り替えのキーが、初期設定では押しにくい場所に配置されていることが多いため、設定ファイル（.tmux.conf）を編集して自分用にカスタマイズしないと使いづらいです。
概念の理解: 「セッション」「ウィンドウ」「ペイン」という3つの概念を理解し、それぞれを制御するコマンドを覚える必要があります。
モードの概念: 通常の入力モードと、コピーモード（スクロールやコピーをするためのモード）が分かれており、特にコピーモードの操作が複雑で混乱しやすいです。
最初はただの黒画面:tmuxはインストールした初期状態では、色使いや操作性が便利とは言えません。使いやすくするためには、.tmux.confをネットで調べて設定する必要があります。
メンテナンス:バージョンが変わるたびに設定が効かなくなったり、新しい設定方法を調べ直したりする必要があるため、メンテナンスが面倒です。
マウス操作・スクロール: 通常のターミナル（iTerm2やWindows Terminal）とは異なり、デフォルトではマウスでのスクロールが直接できないなど、使い始めの利便性が低いです（※設定で対応可能）。
クリップボード連携:ターミナルのコピー・ペーストをtmux内で行う際、うまくクリップボードと連携できず、苦労することがあります。
5. 「慣れ」という壁
導入当初は非効率: 慣れるまでは、普通にターミナルを複数立ち上げた方が速いため、その便利さを実感する前に挫折しやすいです。
まとめ：なぜそれでも使われるのか？
苦行とされる一方で、それを乗り越えると「SSH接続が切れても、サーバー上の作業が強制終了されずに残る」「画面分割をキーボードだけで爆速に操作できる」という、インフラエンジニアやプログラマーにとって強力なメリットがあります。
「プログラミング」自体が好きだった人々に問いかけたい。 今の仕事は、楽しいか？
幼少期から「何かを作る」のが好きで、段ボールや使い終わったペットボトルでいつも何かを作っていた。
そのうち、両親からパソコンとVBの入門本を与えられて、プログラミングにハマった。ビリビリになるまで本を読んでは、毎日のようにコードを書いていた。
そんな自分が将来なりたかった仕事は、他でもない「プログラマー」だった。
2021年の夏、大学のリモート講義中に腕試しで受けた長期インターンに合格して、初めてプログラミングでお金を稼いだ。
社員の人たちはみんなギークで、自分もこんな「プログラマー」になりたいと心から思った。 「性格はめちゃくちゃ悪いけれど、技術だけは誰よりもある」人もいた。そんなブリリアントジャークに、どこか強く憧れていた。
いろいろな企業のインターンや面接を経て、9月、晴れて「Webエンジニア」の内定をもらった。 「自分もやっとプログラマーの入り口に立てた」と思った。言葉にならないほど嬉しかった。
一方で、その頃にはもうChatGPTが流行り出し、GitHub CopilotのTab補完が広まるなど、AIの夜明けを感じてはいた。だが、当時はまだ「コードを書くのが速くなって嬉しいな」くらいにしか思っていなかった。
それが、2024年になり、世界は一変した。 某Zenn記事を皮切りに、Clineが爆発的に流行し始め、AIコーディングのトレンドは「補完型」から「自律型」へと移行していった。あれよあれよという間にCursor・Devin・Claude Codeといったツールが台頭し、瞬く間に「コードを書く」仕事を奪っていった。
2025年4月。自分が会社に入る頃には、開発現場にはすでにClaude Codeが浸透していた。 「自分ではコードを書かない」――いわゆるバイブコーディングが当たり前になっていた。
それらを全部やり終えても、実装はすべてClaude任せ。自分は技術的なことを何もしていない。「何が面白いんだ？」という自問自答が頭を離れない。
もちろん、事業会社のエンジニアとしては、ひたすらコードを書くよりも今の姿のほうが健全なのだろう。それは分かっている。
しかし、「AIの台頭によって技術力が要らなくなった」わけではない。それは百も承知だ。 適切な技術選定のため、AIのコンテキストから外れた事項を考慮するため、あるいはAIの生成物を監督するために、技術力はこれからも必要とされる。
しかし、その技術力は「自分で使うもの」ではなくなってしまった。
一昔前の中堅エンジニアには、「管理職に上がってしまいコードを書かせてもらえなくなる」といったことがよくあったらしい。けれど、今は、新卒も含めたすべてのエンジニアが、最初からその状態にいる。
逆に問いたい。あなたは転職活動でこう言えるだろうか？ 「技術に自信があるので、ひたすらにコードを書き続けたいです。要件定義や社内調整はやりたくないです」 そんな人を雇ってくれる会社はもうほとんどないし、いずれはゼロになると思う。
「Webエンジニア」という仕事は、これからも残り続けるだろう。 けれど、自分がかつて憧れた「プログラマー」は、もう必要ないのだ。いまや「作れる」だけの人に価値は無く、「課題解決ができる」人だけが求められている。
「Webエンジニア」は、自分がなりたかったものではないことが分かってしまった。 だから、自分はエンジニアとしてのキャリアパスを諦めて、早々に退場したいと思う。
自分が心から「楽しい」と思える何かを、自分の手で生み出したい。
そんな夢を追い求めて、旅に出ようと思った。
※この記事はGeminiと壁打ちしながら書きました。
マジレスすると
例えばミズホちゃんならあんなでかい規模のプロジェクトは世界でも少ないしマネージメントの問題であってITがどうこうとは違う
世界一の天才プログラマーがいても何作るのかわからない、そもそも要望聞くだけで100年かかるなら無理なもんは無理
天才プログラマーたちは例えばエクセルはつくれるがエクセルでここの売り上げの打ち込み方がわかりません！とか数億人に言われたらそりゃ対応するの無理
あとはUI（画面）
画面がどう動くかとかは要望されたように作ってるだけであってそれがユーザーの思うように動かないとか知らんがなって話
これが一般人の考える「ITのレベル」だが、実はそれ以前の問題で例えば金融系の一般の人が見ないような部分で実際に何十億何百億っていう金がかかった場面で新しいものを適切に設計して適切にコードをかいた人間は確かに日本には少ないから外人部隊になってる
「英語圏の人間がそんなにいるのにレベルが低い日本のITって一体なんなんだ？」
という疑問はそれを踏まえて自分で考えてくれ
その一言で知的勝利宣言した気になれるなら、ずいぶんコスパのいい人生だ。
「理解してない人ほど語気だけ強くなる現象」が可視化されたところなんだよね。
作れない・判断できない・でも笑いたい――この三点セット。
少なくとも使いこなす側と外野で茶化す側の溝は、前よりくっきりした。
まあ安心しなよ。
AIがどれだけ進化しても、「何も生み出さないでニヤつく役」は当分自動化されないから。
そこは人力のままでいける。
これは私自身が、また私以外の業界から転職されてきた方々を見てきて、これではないかな？と思うことがあります。
それはプログラマー以外の仕事は、常に本番環境である、ということです。
たとえば営業であれば、取引先との打ち合わせも見積もりも、ひとつひとつが「本番」です。やり直しはききませんし、次の瞬間には社外の人の評価や信頼がかかっています。接客や教育、医療、建築…どの仕事もそうです。人や社会に直接つながっている以上、テスト環境など存在しません。常に結果が「本物」として記録されていくのです。
その点、プログラマーの世界は少し違います。そこには「テスト環境」があり、「デプロイ」という明確な境界があります。エラーが出ても、まずはコードの中で直せばいい。実験と修正を繰り返しながら、本番に近づけていける。失敗から学ぶ仕組みが、仕事の構造として組み込まれているのです。
もちろん、だからといってプログラマーが気楽だという話ではありません。むしろ「テストできる」ことが前提だからこそ、完璧なシミュレーションを作り上げる責任が生まれます。本番環境を一歩でも誤れば、大きなシステム障害につながることもある。
けれど、「試すことが許されている」という点で、プログラマーの仕事は他の仕事とは質的に異なる、と私は感じます。多くの職業では「やってみること」そのものがリスクになるのに、プログラマーだけは「やってみること」が日常の一部として制度化されているのです。
たとえるなら、プログラマーの仕事は「楽屋のある職業」なのだと思います。
多くの仕事は、目を開けた瞬間からステージの上に立たされるようなものです。接客業ならお客さんの前に立った時点で本番が始まっていますし、教師なら教室に入った瞬間に舞台袖はありません。間違えば生徒が戸惑い、客が離れ、取引が破談する——それらはリハーサルのない一回きりの公演です。
一方で、プログラマーは楽屋での準備が長く、ステージに出る時間は驚くほど短い。コードを書く、テストする、修正する。その多くは「誰にも見られない暗闇の中」で進んでいきます。そして、いざデプロイという名の本番を迎えるときには、すでに何十回ものリハーサルを終えているわけです。
そう考えると、プログラマーの面白さは「安心して失敗できる時間」が保証されていることかもしれません。社会の多くの仕事が「失敗しないための緊張」で成り立っているのに対し、プログラマーは「失敗を前提とした反復」で完成に近づいていく。
この違いは、単に働き方の差ではなく、「世界との関わり方の構造の違い」にまで広がっているように思うのです。
その境界線こそが、プログラマーとそれ以外の仕事を分ける根本なのかもしれません。
プログラマーの失敗は、基本的にログに残ります。誰が、いつ、どんなエラーを出したのかが正確に記録されます。でもそのログは、「修正可能な痕跡」であり、「過去をなかったことにできる記憶」です。失敗は恥ではなく、改善のためのデータとして保存される。むしろ失敗を残さない方が恐ろしい——なぜなら、それは検証も再現もできないバグだから。
一方、他の多くの仕事での失敗は、ログではなく「印象」として残ります。顧客の言葉、上司の記憶、誰かの評価。修正パッチは配信できませんし、「新しいバージョンをリリースしました」と言っても、その印象が上書きされるとは限りません。世界が自動でキャッシュをクリアしてくれることはないのです。
だからこそ、非プログラマーの人々は無意識のうちに「失敗を避ける設計」で働くようになります。完璧に準備してから発言する、波風を立てないように動く、見せ方に細心の注意を払う。彼らの本番環境には“try-catch”構文が存在しないのです。
一方で、プログラマーは「例外処理」を書くことを前提に思考する。すべての失敗を想定し、起こり得るエラーを受け止める枠組みを最初から組み込む。そこには、世界を「壊れ得るもの」として見る柔軟さと、「壊れても直せる」という信念がある。
その考え方の違いが、やがて人の思考様式や言葉の慎重さ、さらには生き方そのものにまで影響していくのではないか——そんな気がしています。
覚えておいてください。これから踏み出す世界には、「実行ボタンを押す前にコンパイルしてくれる親切な仕組み」はありません。人の言葉も、会話も、メールも、一度送ったら基本的に戻ってきません。Undoはありませんし、Gitもありません。世界は常にmasterブランチで動いています。
ですから、まずはその“冗長な曖昧さ”を恐れないでください。コードの世界ではif文で整理できたことが、現実の人間社会ではあいまいなまま動いています。それを「エラー」だと考えないでください。人間は仕様書なしで動いているシステムです。バグだらけで当たり前なのです。
現実の世界では、修正にも時間がかかりますし、再デプロイにも人の気持ちというプロセスが関わってきます。あなたが「パッチを当てました」と言っても、相手の心がそれをすぐに適用してくれるとは限りません。
ですから、焦らずに。ログを読むより、人の表情や沈黙を読む方が大切になります。
そして何より大事なのは、「テスト環境がない」という世界でどう生きるかを考えることです。
あなたの言葉は、すべて本番環境に直接デプロイされます。その恐ろしさの裏側には、同時に大きな自由もあります。本番だからこそ、本気が伝わります。人間関係も仕事も、常にリアルタイムで最適化されていくのです。
プログラマーらしい慎重さと、非プログラマー的な即興性。その両方を持てる人は、なかなか多くありません。もしあなたがその橋渡し役になれたなら、どんな職場でもきっと大きな価値を発揮できるはずです。
世界はtry-catchのないシステムです。しかし、恐れることはありません。catchできない例外に出会ったときこそ、人は成長します。これからのあなたのフィールドには、テスト環境の代わりに「出会い」と「経験」が用意されています。それもまた、悪くない環境だと思います。
息子はプログラマーになりたがってるけど、これからの時代はどうも論理的思考力とか数学力、英語力よりコミュ力がプログラミングに必要になってくるっぽい。
