  |
はてなキーワード: プログラマーとは
突き詰めれば、なんでも生成AIでいいじゃん、は当たり前な気がする。
伝えたいことが伝わればいいから、ポスターはAIイラストでいい。
まぁ、ソシャゲもアニメも漫画も物語だけ人間が考えた方が面白くなりそうだね。それ以外はAIでいいよ。キャラクターがどんな姿であろうと内容変わらないんだから、指6本でもいいじゃん。
プログラマーも今ほどの数いらないよね。コード読める数人がいたら十分。
モデルもいらないよ。AI使えば商品紹介プロモーションビデオくらい作れるでしょ。トップレベルに有名な人なら使いたいかもね、モデルに。それ以外はいらんでしょ。エキストラとかいる？いらんよね。
言い始めたらきりなさそう。
多分、それで企業は赤字になることないんだろうし、余った人間は肉体労働すればいいじゃんって。
儲かるのって企業側だけじゃん。
企業がコンテンツたくさん用意しても、金ないのに誰が買うの？状態になるんじゃないかなぁ。
とある地域イベントで、大学と提携して学生がアプリを作ることになったのね。
そこで大学側から要請があって、地方でしがないプログラマーをやってる俺こと増田が学生が作るアプリの面倒を見ることになったのね。
~~どうでもいいけど追記~~
その大学のゼミから手伝いの要請があって、外部の増田が手伝ってる。
知らない人は知らないかもだけど、別に珍しくもないよくある話。
別に信じてもらわなくてもいい部分だけど。
~~~~~~~~~~~~~~~~~~~~~
さすが学生たちは若くて吸収する力があって、プログラミング初学者ながらもAIを駆使してアプリを完成に導いたわけ。
「これだけAIが発達してきたらプログラマーも厳しいんじゃないですか？（お前ができてることを学生たちがこんなに簡単にできるようになってしまっては）」的なニュアンスのことを。
そりゃそうだよね。
こちとら30年も地方でプログラマーやってて初老にもさしかかる頃にできてることを、かたや学生たちは20代前半でAI使って1ヶ月でアプリ開発できちゃうんだもん。
そこで俺は言ってやったわけよ。
「そうですね。（サッカーだって小学生や幼稚園児だってできます。
"うちの学生たちだってサッカーボールを蹴ったらゴールに入れられますよ、どうです？すごいでしょう？"
そうですか？私はそうは思いません。
サッカーができたからといって、ゴールにボールを入れられたからといって、プロサッカー選手にはなれませんし、誰もその試合を見たいと思ってお金を払ってくれません。
プログラマーも同じです。アプリが稼働したから仕事があるわけではありません。
とね。
実際、イベント中にWEBアプリとして稼働するために多くのことを増田がサポートしたし、それはプログラミング初学者が1ヶ月の中で想定して稼働にまで導くには無理な部分だったし、絶対に30年の経験がないと先回りできないところだったりするわけで。
お年寄りから子供まで参加する地域イベントで、ペアレンタルコントロール化のスマホでもアクセスできるようにlet's encryptでHTTPSにしておいたり、データーの持ち方的にイベント中にgitの更新がかかるとデーターが飛ぶ恐れがあるんで先回りしてガードしてたり、スムーズなイベントの進行を妨げないようなバックドアを仕込んでおいたり、あえて決め打ちのハードコードを仕込むことで印刷工程に間に合わせたり。
休日出かけるとホモソの底辺みたいな父親が息子にぶつぶつ嫌味垂れてたり「そんなこと言ってっと引っ叩くぞ？」とか凄んでたりとにかく不細工で社会の底辺みたいな小汚い男が子供育てるのが害悪だとよくわかる。
娘連れてる底辺パパは小学校高学年くらいの娘からベタベタされてまんざらでもないみたいな顔してUFOキャッチャーに金吸い込まれまくってる。
娘は西松屋だかバースデイの型落ちみたいなボロボロな服や靴を着せられてる。ゲーセンに吸い込まれた金でいい服買ってあげればいいのに。
息子連れてる底辺パパは一様に、底辺SEみたいな顔と体型してる。コーディングの本質理解できないのでテスターしかやらせてもらえないプログラマーに片足突っ込んだ40歳SEみたいな顔。小太り。
娘連れてる底辺パパは底辺IT営業みたいな顔と体型してる。背が低くてパーマかけてる髪はツヤがない。太ブチメガネとガリガリな体型。自分を売ることばかり考えて本質的な顧客への問題解決が提案できず自社サービスのエンハンスにもついていけなくて孤立してる感じ。飲み会にはしがみつくように参加する。
でもさ、そんなわけ無いじゃない。
こんなわずか数年で完璧とは程遠いとは言え曲がりなりにも動くコード書けるようになってるのに、5年後にもっと発展してないわけ無いじゃない？
あと生成AIって書いたけど世の中で研究されてるAIってそれだけじゃないだろうしな。
とにかく社会全体がAIに全フリし始めていて、そりゃバブルだろ？って疑いの目も持たないといけないけど、同時に危機感を持ってないのは感度悪すぎるよ。
自分は5年後もプログラマーの仕事をしてる。とか確信してる人は正直ちょっと怖い。
だからさ、ホント今から打てる手は打っておいたほうが絶対にいい。
マジで。
具体的になにをしているかというと、リーダーの考える通りのWebサイトのコンテンツを作成できるように黒い画面で英文をカタカタする仕事だ。なんてつまらなさそうな仕事紹介だろう！
この熱量の無さからわかる通り、プログラミングとかいう行為が好きではない。じゃあなんでそんな仕事を選んだかというと、学歴と体力のない人間の消極的選択である。
頭を動かすことは得意なので現場からもそれなりの評価を頂いている、が。今それなりに危機に瀕している。
人手が足りないから別のチームに応援に呼ばれた。これはいい。意思の確認とかされなかったけど。まあいい。
問題は別チームのやり方が本当に別すぎてなんもわからんことだ。
言語は同じなのだ。しかし書き方が違う。曰くフレームワークをゴリゴリに使用している書き方らしい。
IT業界でない人に説明するなら、同じアルファベットを使ってるはずなのに文法が全然違くてわからん。無理。
すごく頑張った。AIも駆使した（うちの現場では推奨はされていないが、非推奨でもない）。最低限求められている動きをしているものができた。
そして脳内のお嬢様が叫ぶ。「自分で何を実装しているのか、わたくしさぁ～～～ぱり、わかっておりませんわぁ～～～～！！！」
求められているものができているなら良いだろうと思うだろうか？しかしこの次の工程でレビューというものがおれを待ち受けている。
おれはこれが嫌いだ。諸々仔細は省くが嫌いだ。省く理由はおれのレビュー担当者への怨嗟で埋まるからだ。（別チームの応援におれのレビュー担当者=チームリーダーも一緒に来た）
そもそもおれはおれの上に立つ人間を好ましいと思ったためしがないので社会人が向いてない。終わりだ。
しかし時は無常。作業はまだまだある。ひとつめの壁で立ち止まっている場合ではないのだ。
終業時間ギリギリにレビュー依頼をぶん投げ今日の仕事は完了させた。
ある伝説によると、とある国のとあるプログラマーの退職後に残ったスクリプトを社員が見たら、恐ろしいレベルで自動化してたそうだ
https://github.com/NARKOZ/hacker-scripts
うちのビルドエンジニアが別の会社に行った。あの男は文字通りターミナルの住人。Vimを愛用して、Dotで図を作成し、Markdownでwiki記事を書くようなタイプ。
どんなものでも、90秒以上かかるならそれを自動化するスクリプトを書く奴。
それで今、我々は奴の「遺産」を見ているわけだ。
これ、お前も気に入ると思うぞ。
奥さんに「仕事で遅くなる」というテキストメッセージを送る。文字列の配列から理由をランダムに自動で選ぶ。cronジョブとして動作。奴のアカウントで午後9時以降にサーバーでアクティブなSSHセッションがある場合にジョブが実行される。
「Kumar」（うちのクライアント）からのメールを受信箱でスキャン。「help」、「trouble」、「sorry」などのキーワードを探す。キーワードが見つかると、スクリプトはクライアントのサーバーにSSH接続し、ステージングデータベースを最新のバックアップにロールバックする。「直したぞ。次からは気を付けろよ」という返信を送る。
特定の日に設定された別のcronジョブ。「体調が悪い/家で仕事をする」といった自動メールを送る。別の事前定義された文字列の配列からランダムな「理由」を追加。午前8時45分にサーバーで対話型のセッションがない場合に実行。
正確に17秒待ってから、うちのコーヒーマシンにtelnetセッションを開き（コーヒーマシンがネットワークに繋がっていて、Linuxが動いていて、TCPソケットが立ち上がっているなんて、誰も知らなかった）、sys brewのようなコマンドを送る。判明したところ、これでミディアムサイズのハーフカフェラテを淹れ始め、カップに注ぐまでさらに24秒待つ。この時間は、奴のデスクからマシンまで歩くのにかかる時間と完全に一致している。
----
「My Job Went To India」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went to India : オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went to AI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
