  |
はてなキーワード: ドキュメントとは
プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…！」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。
近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。
開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のものが出回っている。Eclipseとか今考えるとよくあんなので開発できてたな。
いまや小学生からおばあちゃんまでアプリ作りに熱中し、高校生はIoTとかやり始め、大学生は商業レベルか？ってレベルのものをネットで発表し、私はウェブアプリのスマホでのレイアウト崩れひとつすら直せず静かにエディタを閉じてnoteで過激タイトル記事を書いている。
掛け算に順序があると思っているような知能の下級雑用係（自分のことを教育専門職だと思い込んでいる）ですら「小学生にプログラミングを教えるぞ！」と意気込んでいる。やめろ。お前らには無理だ。無理だからマジでやめろ。考え直せ。無理だって。掛け算に順序つけないと相手に教えられないレベルのやつがプログラミング教えるのマジで無理だって。算数とは次元が違うって。「ピーチ姫いつも簡単に誘拐できるし今度はベヨネッタも誘拐してみるか」ぐらいの無謀さだって。やめとけ。マジでやめろ。
まあそんなこんなで入り口はめちゃくちゃ広く、入門するのはマリオカートより簡単である。話逸れるけどSwitchのマリオカート、運転アシスト機能ついて初心者でもコース完走できるようになったから心折れちゃった人ももう一度チャレンジしてみてね。
それとは特に関係ないんだけど、大学行ってた時ティーチングアシスタント（TA）っていう授業のお手伝いさせられたのよね。ちゃんとお金出るやつ。
学部の3年か4年から始まって、院の1年か2年までやってて、途中で休学挟んだから、ええと、あー、うん、数年間TAやってたんよ。数学とプログラミングのコマ。CとOctaveとかいうやつ。Cのほうは情報学科で、Octaveは違う学科。JavaとかC++のコマはTA入れさせてもらえなかった。
プログラミングの実習は週2コマ（連続）あって、情報学科なら必修科目。なのでサポートは相当手厚く、先生とTAが絶え間なく机間巡視し、わからないことがあればセンパイがなんでも答えてくれるというわけだ。授業外でもサポートはしており、わからなければ先生や研究室にいる学生に好きなだけ聞きにいっても良いということになっていた。必修だから落とされたら困るしな。
2コマだから3時間 * 15回で、45時間。そして私の時は2年まででC/C++/Javaと必修だった（今はなんの言語かは知らない）ので、その3倍、135時間は最低やることになる。プログラミング実習以外にもプログラミング触る授業多いから実際はもっと多い。宿題やる時間もあるので実際はもっともっと長くプログラミングに触れることになる。卒論書く時期に入ると、テーマによっては書く人はさらに書くので、もっともっともっともっと長い。
これだけ時間をかければほとんどの人がプログラミングできるように……ならない。むしろできない人の方が多い。なんで。why。教えて。
会社になるとさすがにプログラミングできるできないは死活問題である。
「今日から入ったxxでーす。業界未経験ですがよろしくおねがしまーす。さっそくなんですけどPythonのここわかんないんですけどどうすれば……あっそうすればいいんですね。次はここなんですけど……なるほど！ありがとうございます。じゃあまた明日ー」
いやー社会人にもなると熱意が違うね。学生なんかわかんなくてもほとんど聞きに来ないのにな。こりゃガンガン伸びますわ。私も社会人1年生でPythonなんて3秒ぐらいしか触ったことないから適当答えてるけど。
「ちょっとお時間よろしいですか？」「いやちょっと今忙しいから後になっちゃいますわ。すんません……」
そんなこんなで1週間ぐらい放置してしまった。やべー絶対嫌われる。どこまで進んだかな……？えっまだそこ？進んでなくない？
もしかしてこれ全部教えないとダメなやつか。そりゃ大学4年間プログラミングやったやつでもプログラミングできないんだから、そうか。よく考えると当たり前だよな。
プログラミングをやめろ
大学4年間と大学院2年間プログラミングやったやつでもできないし、会社で毎日8時間を数週間プログラミングについやしてもできないやつはできないし、そもそも人類というのはプログラミングできない可能性がある。
少年少女たちに「プログラミングはいいぞ！自由にものが作れて達成感がある！頭が良くなった気分にもなれるし！」と吹聴してまわんのもいいけど、6年間情報科学について勉強したようなやつの大半がプログラミングできないんですよ。それもごくごく初歩的な部分。
野球とかサッカーなら、まあ友達との試合には参加できなくてもごく稀にバットにボールを当てたり、ボールを1回あらぬ方向に蹴ったり、ぶっちゃけ周りとのレベル差で楽しくなくてすぐやめちゃうだろうけど、なんとか基礎の一部ぐらいはできるじゃないですか。
ピアノとかダンスでも、猫踏んじゃったをごくごくゆっくり弾くぐらいはできるかもしんないし、学芸会の振り付けを10秒ぐらいは踊れたりできるかもしれない。その後やっぱ周りのレベル見て諦めちゃうかもしんないけどさ。
プログラミング、6年やってミットを頭にかぶってるバッターとか、鍵盤蓋の上から殴って音鳴らそうとするやつとか、まずそういうレベルのやつが大量発生するんですよ。だいたい7割ぐらいの率。どうすんだよこいつら。私の教育の問題か？マジで？本当に？
プロが練って考えて凝縮した本や授業、センパイたちによる指導。それらを結集して得られるはずのものが7割ぐらいどっかに消し飛んでる。無駄だろこれ。
今からプログラミングやろうとしてるやつ、お前は確実に向いてないからさっさと諦めて刺身にタンポポ乗せる仕事に戻ってくれ。参加しても鍵盤蓋叩き割るやつと同じ病室に入るだけだ。
プログラミングをやめろ。
ぼくはこう思うんですよ
そもそもなんで大の大人がそんな両手にバット持ってセカンドに立ったりゴールの方をボールのところまで動かす奇行に走るんだろうな。わかんねえや。
綺麗な分析はできないけど、いわゆる「できない」やつが共通して言ってたフレーズがある。
「ぼくはxxxだと思ってるんですけど、動かないんですよ」
うん、そうだね。そう思うんだ。でも動いてないじゃん。じゃあ違うんじゃない？モニターに「にらみつける」やってもバグは取れないし防御力下がるだけだぞ。
まず根本的に考えと事実が違ってるって結果出てるじゃん。じゃあもう考え変えちゃえば早くない？
名言の引用は好きではないけど、「プログラムは思った通りには動かない。書いた通りに動く」って言葉がある。実に名言だと思う。次点で好きなのが「ある問題を解決しようと正規表現を使うと問題が2つに増える」かな。
お前が何を思っているかはプログラミングにおいて一切影響しないんだよ。お前が何を書いて、コンピュータがどう処理したか、それが全て。
深く考えないことについてぎゃーぎゃーいうやつもいるけどプログラムなんてまず最初は動けばいいんだから何も考えずに次試せばいいだろ。んで3回ぐらいは自分で思い浮かんだの試して、全部ダメだったら調べるとか先生に聞いてみるとかさ。逆に1発で通ったら自分の思考見直して理解深めるとかさ。
ドキュメントとかあんまり理解できない初心者のうちは、とにかくお試しと修正のサイクル回すの重要で、「これがこうだから動くはず」というカードを3種類ぐらい作って全部片っ端から試すのが早いと思うよ。モニターをにらみつけるな。
お前がどう思ってるかよりも、まずはお前の書いたプログラムがどう動いているか（どう動いていないか）を確認するのが先だ。動かなかったら考えが違う、はい次のプラン、はいその次のプラン、はい次。
この「ぼくはこう思ってる」が出てくるの、なんの教育の成果なんだろうね。お前の気持ちなんてどうでもいいって現国でも数学で散々教えられただろ。
Error: variable 'a' is undefined, line 24
↑のエラーは架空のエラー文（英語下手でも許して）だけど、エラー、出るよね。プログラム組んでたら。んでやっぱいるのよ。エラーを「にらみつける」やつ。解決しねえって言ってんだろ。
「エラー出たんですけど、どうすればいいんですか」
「エラーにはプログラムがなぜコンパイル通らないかの原因がそのまま書かれている。例えば今出ているError: variable 'a' is undefined, line 24は、24行目の変数aが未定義ということを示している。事前に変数aを定義していないか、打ち間違えてsになっているとかではないのかな？」
だいたいが「腑に落ちねぇー」みたいな顔する。まあ、一気に喋りすぎたしな。疑問点1個1個潰していくか。
「何か疑問点ありそう？変数ってなにー、とか、定義ってなにー、とか」「ないです。わかりました！」
わかったのか。よかった。またモニターをにらみつける開始。なんでだよ！！！！「お前顔にチョコついてるぞ」って言われたらチョコ拭き取るだろ。変数aが未定義ですねって言われたら変数a定義すりゃいいだろ。
でもプログラミングド下手なやつ（全人類の7割ぐらい）は、エラーをにらみつけてる。ずっとにらみつけてる。防御力下限まで下がったかな。にらみつけてて何が変わるんだよ。
「英語読めなくて……」
いや「a is undefined」なんて「He is Superman」ぐらいの英語だろなんで読めないんだよ。お前この大学どうやって入ったんだよ。たしかどの入試方式でも英語あっただろ。単語わからんかったらググれ。
「aが未定義って書いてあるんですけど、ここのfor文の私の考えが間違ってるのでしょうか」
いや24行目のaって書いてるだろ。まずなんでそこ無視するんだよ。お前がfor文で使ってんの教科書通りのiだろ。24行目ってわかるか？for文あるの40行目あたりだよな？aとiが違う文字ってわかるか？
「さっきのエラー直したら新しいエラーが出たんですけど、どうすればいいですか」
千尋！贅沢な名だねえ
変数に名前をつけろ。関数に名前をつけろ。クラスに名前をつけろ。全てに名前をつけろ。
C言語の古い教科書だと「a」とか「b」とか「i」とかで書いてるけど、そんなの人間が読めるわけねえだろ。冷静に考えろ。「input」「output」「index」とかにしとけ。
2重for文の変数名i, jにしたら絶対途中で打ち間違えるだろ。お前は打ち間違える。そういうやつだ。2重ループなんてどうせ行列計算の課題だろ。rowとcolumnにしとけ。これで打ち間違っても気づくし、それぞれに意味が付いてくる。
ちなみに同じ長い名前にも優劣がある。「result」よりも「sum」のほうが強い。「result」はなんの結果かわからない（全ては結果であるので）が「sum」は合計値であることがわかるからだ。「password」と「plainPassword」なら「plainPassword」が勝つ。暗号化されていないパスワードであることがわかるので、情報量が多いからだ。
ただし例外はいくつかある。「tmp」は一時変数であることが（プログラマにとって）明らかだ。「dir」はディレクトリであることがわかる。「src」「dist」あたりもよく使われる。このあたりは短くていいんじゃねーかな。
でも、この前温度センサ扱うプロジェクトで「tmp」って変数名使って温度(temperature)と脳内で混線してバグって発狂してた同僚いたけど。そういうときは名前長くするか別の名前使おうな。
関数の名前なんて「calcAverageFromArray」ぐらい長くしていいから。「myFunc」とかしなくていいから。「fetchJsonDataFromUniversityInternalServer」とかでいいから。マジで。いやこれ本当に。
そもそも今時ディスプレイでかいし、識別子なんて先頭数文字打ったらエディタが補完してくれるし、短くするメリットがない。
それでも名前が長いと感じる？関数がでかすぎるんじゃないか。細かく処理を分けるとかしてみろ。「combineArrayAndFindMax」関数は「combineArray」と「findMax」に分割したらいいと思うぞ。名前が長いと思っても名前を削るな、機能を分割しろ。自然と名前が短くなる。
それかシンプルでかっこいい名前を見つける。「convertEvilHtmlToPeacefulText」は「sanitize」に置き換えることができる。イカす名前だ。
プログラミングできない奴はマジでこれらのことをやらない。ずっとaとかbとかzとか使ってる。お前それ自分で読めんのか。読めねえだろ。myfuncってなんだよ何するんだよ。お前自分で理解できてんのかそれ。
それでも頑なにaとかbとか使う。なんでだよ。
動作原理わからず書き散らすな。動作原理っつってもそんな深いところじゃなくて言語表面上レベルの動作な。
リテラルは値を作成して、代入は値に名前をつけている、とかその程度のレイヤー。メモリがどうこうとかはいらんと思う。あっでもポインタのときはいるか……。めんどくせえな。
まあ動作原理っていうか自分が何やってんのか理解してくれって程度の話になるんだが。
例えばfor文で処理50回まわすとき、「50回分の処理を行なっている」ではなく「ループ開始時に変数を初期化。条件判定して成立していれば文の中を実行する。条件変数の値を変化させてまた条件判定からやり直す」ぐらいの粒度で捉えててほしいかな、という気持ち。
これはfor文で詰まる人がやたら多かったからだ。彼らはfor文をアトミックな操作だと思っていた。つまりfor文はひとまとまりの命令であり、長いfor文とprintfの間に粒度の違いはないと思っていたらしい。
つまり、「for文の中でエラーが起こる」という事象がほぼ理解できない。forはアトミックであり、内部など見えないのだから。じゃあお前が今書いたfor文の中身はなんなんだってやんわり聞くと「さあ…？」みたいな反応が返ってくる。はあ。
関数についてもなかなか誤解が多かった。関数「sum_array(a, b)」と関数「average_three_numbers(a, b, c)」は全く別の原理で動いているのだと。ここでの「全く別の原理」というのはシグネチャが違うとか実装が異なるとかそういう意味ではなく、コーラを飲んでゲップが出る原理と糸電話で声が伝わる原理ぐらいの全くの別、という意味である。
彼らは関数ひとつひとつについて「新しく原理を学習」していたのだ。マジかよ……。どうやったらそんな発想に行き着くんだろう。そりゃ時間かかるわな。
そのため、関数が値を返す（または返さない）ということも理解できておらず、「関数の戻り値と関数の戻り値を足す」とか「関数の引数に関数の戻り値を直接渡す」とかやりだすと大パニックになる。メソッドチェーンとかやった日には大学潰れると思う。ただ、これはC言語が悪い部分もあると思う。配列とかいじりだすと、初心者が書けるレベルの関数だとあんまり値返さないしな。
たのむ、他のはできなくてもこれはできてほしい。自分が何をやりたいのかは理解してほしい。流石にお前のやりたいことなんて他人にはわからんぞ。
「配列の中の数値の合計値を求めたいんです」とか「名前と身長と体重をひとつにまとめた構造体が作りたいんです」とか。簡単なのでいいから。
「いま何やろうとしてどこで詰まってる？」って聞いても「……？」みたいな反応されたら困るんだよ。
例えば「キーボードから数値を10回入力し、それぞれの値を配列に格納して、最後に配列の値を逆順に表示せよ」みたいな問題が出てきたときに、「キーボードから値を入力する」「10回繰り返す」「配列に値を格納する」「配列の値を逆順に表示する」に分解できると思うんだけど、自分が何やりたいのかわからない奴はまずこれができない。
彼らには「キーボードカラスウチヲジュッカイニュウリョクシソレゾレヲハイレツニニュウリョクシテサイゴニハイレツノアタイヲギャクジュンニヒョウジセヨ」に見えている。
かろうじて「キーボード」「ハイレツ」あたりの単語は拾えるらしく、標準入力から値とったり配列を作ったりはしてるんだけど、そこから先に進まない。モニターにらみつけてる。またにらみつけるかよ。
あれだ、算数の文章題できなくてとにかく文章に出てくる数値足したり引いたりするやつ。あれのプログラミング版。文章が読めない。
こういう人にはメモ用紙取り出して、まず文章が何について言ってるのか、どういう工程に分けることができるのか、今後も同じことが起こったときにどうやって分けるのか。みたいなのを教えるんだけど、大抵あんまりしっくりこないらしく、成功したことは皆無。なんとかうまく教えたいんだが。
もうこのあたりになってくるとプログラミング関係なくね……？ってなるんだけど、意外とそういうプログラミング関係ないところで詰まる人めちゃくちゃ多いよ。
今すぐプログラミングをやめろ
才能がないと思ったら、早いうちに河岸を変えた方がいい。
早ければ早い方がいい。
可哀想だから(教え子が？ それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。
10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？
まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w
それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。
球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。
でも草野球は楽しめる。
才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。
誰にも迷惑かけないなら。
医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。
落ち着きないし。
同じことを何日も続けたら、爆発する。
「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。
こんな感じに、才能がものをいう分野って、意外に多い。
ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。
その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。
どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。
たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。
いや、そういうの主催してる暇があったら、コード書けよ、って。
でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。
おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。
シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。
30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。
今だと玉拾いも任せられないくらいだったりする。
ちょい前も、PostgreSQLの中身いじれます！ って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。
そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w
才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。
そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。
マイカーガー。
マイホームガー。
子供ガー。
愛犬ガー。
んなもん知るかっ！
そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。
あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。
VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。
1年で10。
2年で30とか。
マジかよ w
思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？
とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。
真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。
さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。
これで3倍界王拳だ w
経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w
大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。
はっきりいう。
今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。
具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。
ワークライフバランス？ w
才能のない人は河岸変えろ。
業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。
じゃねーよ。
ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。
ってのが多い。
「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」
「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」
うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？ って聞いてんねんけど……。
って現場、多い。
でも、今通常営業してるサービスでも、こういうところ多いんだよな。
それはともかく、
「マイクロサービス化していて、いま120を超えたところで、当面160になります」
「……は？」
「……デプロイの時、どうすんの？」
「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」
「Cloneして立ち上げます」
「これ……、モノリポ？」
「120個？」
「120個」
「なんか立ち上がらないんだけど……」
「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」
「……動かないぞ」
「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」
5日で立ち上げ切れるんか？
って現場がね、案外たくさんあるんだ。
「ほう……？」
どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？
っていつも思う。
マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)
ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。
120のマイクロサービスとか、お前、認知科学の知識もないねんな……。
それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。
まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。
それでプロダクトがうまく回ってなかったら、それが答えなんよ。
まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。
その正しい答えに行きつかない、ってのを
「致命的な才能の欠如」
って呼ぶんよ。
先月「Slack断食」を30日やった。ぜんぶの通知を切って、午前は一切開かない。午後に2回だけまとめて見る。
先に結論を書く。
1日の「まとまった作業時間」は 平均54分 → 3時間18分 に増えた（タイマー計測）。
PRのリードタイム（着手→レビュー依頼）は 1.8日 → 0.9日 に短縮。
「なんとなく疲れてる」感が減って、帰宅後に本を開けるようになった。
もちろん職種やチーム文化による。あたりまえだけど緊急対応が常態の人には不向きだと思う。
■ルール
通知全消し：@channelもDMも。インシデントチャンネルのみON。
午前は断食：Slack/メールは開かない。タスクと資料だけ。
午後に2回だけチェック：13:00と16:30に各15分。返信はできるだけテンプレで短く。
チャンネル棚卸し：毎週金曜、読んでないチャンネルを抜ける or ダイジェストに。
「生産性改善の実験で、Slackは午後に2回まとめて確認します。緊急時は電話/Teamsを使ってください。返信は遅れますが、作業の完了は早くします。」
■Before/Afterで起きたこと
会議の数が減って質が上がった：アジェンダ無しの招待は「内容だけドキュメントにまとめてください」と返す運用にしたところ、約半数は文書上のやり取りだけで完結し、会議そのものが不要になった。
横取りタスクが減った：その場で拾わず、午後の確認まで寝かせると、他の誰かが解決していたケースが週に2回くらいのペースで発生した。（その誰かに工数をかけさせてるわけだが）
メンタルの凹凸が減る：通知に心拍を連結させない。午前は手を動かすだけの世界にできる。
情報の取りこぼしでの実害はゼロだった：重要なら午後のチェックで追いつけるし、本当に緊急なら電話が鳴った。
気分がいいまま過ごせるようになった：自分のペースで仕事ができるってなんてすばらしいんだろうか
■返信テンプレの一部
「この件、午後13時の確認タイムで内容見てから返答します。」
「緊急度を確認したいです。本日内/今週中/来週でも可のどれでしょう？」
「そのテーマ、週次定例で扱った方が良さそうです。議題に入れておきますね。」
「先にドキュメントに要件を書いてもらえますか。コメントで入ります。」
■ありそうな反論
Q. チームの透明性が下がらない？
A. 逆。会話をチャンネルに寄せ、要点はドキュメントに残す運用に寄ったので後追いが楽になった。
A. 「即レスの代わりに、確実なアウトプットを増やす」と宣言する。成果が見えれば、周囲は文句を言いづらい。
A. 顧客は早い返信より一貫した進捗を喜ぶ。進捗報告の定時化で満足度はむしろ上がった。
■失敗談（やらかし集）
全社アナウンスを見逃した：アナウンスのチャンネルだけはモバイルでプッシュ許可に。
午後の確認をサボると炎上：2回のチェックは絶対に守る。守れない日はカレンダーに明記。
DM地獄の温床：DMで来た要件はチャンネルへ移すを徹底。つーかDMしてくんな
■仕組み化のコツ
タイマーを回す：自分は25分集中、5分休憩の典型的ポモドーロタイマーがよかった。
午前の最初に「1行だけ日報」：今日やることを1行。終わったら結果を1行。長文にしない。
まとめ
通知って、“有益な情報”をくれるものに見えて、実は作業を中断させる“割り込み”として機能してることが多いなと感じた。
しかも厄介なのは、その割り込みを自分の意思で受け取ったように見えることだ。
実際には、誰かの都合で伝えたい割り込みを、こっちの集中を犠牲にして処理してるだけなのに。
Slackもメールも、見に行く時間を自分で決めるだけで世界が変わった気がする。試しに1日だけでもやってみてくれ。向き不向きは個人差あると思うのでどうなるかは知らん。
> 「AWSの運用の強みは、経験豊富な余剰人員によって築かれており、人員削減を行えば、基本的な機能が崩壊し始めます」
たいていの現場で、新入りのエンジニアが「ドキュメントが充実していてありがたいです」的なセリフを吐くことがあまりに多いんだけど、正直なところ、ドキュメントが大量すぎて、AI使おうが「これ」という情報が見つからない。いや、そもそも必要なドキュメントが存在しないことしかない(日本語が変なんじゃない)。
ドキュメントの書き方を、OJTで形式的にしか学んでいないんだろうと思う。
そんでもって書きっぱなしで、「あ、今はそうじゃなくて、こうなってます」って口頭で伝えられることがあまりに多い。いや、修正しておくか、削除するかしろよ。
って、そんなどうでもいい経緯なんていらんわ！
経緯が分かったところで、何の役に立つと考えてるんだよ？
昔、アホなエンジニアありき。って記録以上でも以下でもないだろ。
そんでもって、正しいドキュメントがあったとしても、読んでも大してプラスにならん。
なぜなら、ただの自分用の備忘録以上でも以下でもないものでしかないから。
誰に向けて、何を伝えるためのドキュメントか、ちゃんと意識して書かれた技術ドキュメントに、ほとんど出会ったことがない。
って、なぜそれがこのタイトル、この内容のドキュメントに紛れ込んでるんだよ！
みたいなことがあまりに多い。
しかも最新化されてない。
たいていムカつく東大の〇〇研究室の量産型卒業生なんて、「これくらいできて当然でしょう」的に他人を小馬鹿にしたような態度をとってきやがるんだが、そいつらも普通の人よりキャパが少し大きいだけで、色々積み上がってきて、見落としが増えてきたら誤魔化しまくって、誤魔化せなくなったら「新しいことをしたいので」とかもっともらしい言い訳してやめていきやがる。
おい、これ、どうすんだよ！
残ったエンジニアには、つくり散らされた無秩序なサービスを「運用でカバー」の日々。
こういうの、マジで普段使ってる単語の意味、理解してねぇんだな。
単語帳みたいに訳、定義を丸暗記してるだけなんだな、ってため息しか出ないんだが。
これ、その場その場の行き当たりばったりな設計実装を増やしてしまうと、今時の複雑化、成長し続けるWebサービスは、簡単に認知力の限界を超えてしまうから、いくつかのパラメータからどこでも同じルールが適用されている状態にして、認知負荷を下げるってのが、ここ10数年のシステム構築界の常識なんだわ。
KISSの原則も、認知負荷を下げる(上げない)って文脈の上にある。
他の、いろんな手法だなんだも、基本的にこれを前提にしている。
のに、いわゆる「識者」は、箔をつけようとしてるのか知らんが、毎秒いろんな要素を取ってつけて、ゴテゴテとした悪趣味な神殿にして、崇め奉る「信者」から金を巻き上げようと、勉強会開いてるだろ？
おいらに言わせれば、「認知負荷を下げられない手法はくそ。カーゴカルトだ」だ。
今の日本のどのWebサービスも、いつ大規模障害を起こしてもおかしくない状態だよ。
「今動いてるからいいっか w」
じゃねーんだよ。
ゾンビ そのわけは ドキュメントの教理 ゾンビ 目に映るを 言葉で殺す ゾンビ 終わりから 月日を計り ゾンビ そのわけは ドキュメントの驚異 ここはここになく ただストーリー すれちがう Narratage の亡霊 ここはここになく ただストーリー すれちがう Narratage の亡霊
似たような体験をしたので読んでください｡鬱病とか適応障害だと思われます｡まず､会社の就業規則､傷病休暇に関するドキュメントを入手してください｡その上で1週間の有給を取り(会社の承認はいりません｡帰宅後に上長･その上の役職･人事部長にメールで心身の不調があり休む必要があるので休暇を取りますと言い切ります)､最初の3-5日で傷病休暇の取り方､自分の会社の場合はどうなるかを把握してください｡それを全部把握して､web上で疑問点も解消してください｡(chatgptやgeminiに相談する､Youtubeを見る)
終わったら自分の症状を心療内科･精神科に相談してください｡お奨めなのは精神科を経営するクリニックです｡予約が取り辛い場合は郊外や田舎では無く都心部で探す｡必ずGoogleのレビューを見て､星が3.5以上の所に行く｡先生に長期間休んで心身を回復したい､診断書を書いて欲しいと明確に伝えてください｡
会社に診断書が出たので､傷病休暇を取りたい旨をメールで伝えてください｡電話のやり取りをする必要･義務は一切ありません｡電話で話を聞きたい､会社に来て欲しいと言われても絶対に対応しないでください｡会社に行くと傷病休暇の対象外になるのでこれも絶対にしないでください｡
傷病休暇前に待機時間がある場合は年休を消化したいと伝えてください｡それがきれたら病欠としてもらってください｡
以降､会社とは一切電話のやり取りは不要です｡連絡はメールだけでしてください｡休職の発令のために1度産業医との面談が必要なので､そのタイミングだけで会社に行ってください｡産業医は心療内科の内容を是認しか出来ないので､心配はいらないです｡不承認になったり､会社に連れ戻されることも無いです｡(職場には絶対に行かないでください｡傷病休暇の受給資格を失う可能性があるので､拒否してください｡会社はそれを命じることは出来ません｡あなたが拒否しても一切責任は生じません｡業務の引き継ぎも不要です｡それは会社側が､上司が普段からすべきことであなたに責任は及びません｡また体調不良で休む場合は業務引き継ぎする必要も無いです｡)
なお､会社で未払い等があればその証拠も事前に全て確保してください｡傷病休暇の終わりに未払いを請求できます｡(外部の1人加入の労働組合に相談してください｡過去2年分遡れます
最後に､あなたの心身を破壊する会社はあなたにとって害のある会社で､籍を置く努力が認められる職場では無いです｡
傷病休暇中に十分に静養してください｡もし体調が治ったら､転職をしてください｡転職が決まったら会社を退職し､新しい会社に勤めて下さい｡
職場環境に問題がある場合に､傷病休暇中に職場環境を変えるのは全く問題ないです｡避難や違法と言われる筋合いは無いです
似たような体験をしたので読んでください｡鬱病とか適応障害だと思われます｡まず､会社の就業規則､傷病休暇に関するドキュメントを入手してください｡その上で1週間の有給を取り(会社の承認はいりません｡帰宅後に上長･その上の役職･人事部長にメールで心身の不調があり休む必要があるので休暇を取りますと言い切ります)､最初の3-5日で傷病休暇の取り方､自分の会社の場合はどうなるかを把握してください｡それを全部把握して､web上で疑問点も解消してください｡(chatgptやgeminiに相談する､Youtubeを見る)
終わったら自分の症状を心療内科･精神科に相談してください｡お奨めなのは精神科を経営するクリニックです｡予約が取り辛い場合は郊外や田舎では無く都心部で探す｡必ずGoogleのレビューを見て､星が3.5以上の所に行く｡先生に長期間休んで心身を回復したい､診断書を書いて欲しいと明確に伝えてください｡
会社に診断書が出たので､傷病休暇を取りたい旨をメールで伝えてください｡電話のやり取りをする必要･義務は一切ありません｡電話で話を聞きたい､会社に来て欲しいと言われても絶対に対応しないでください｡会社に行くと傷病休暇の対象外になるのでこれも絶対にしないでください｡
傷病休暇前に待機時間がある場合は年休を消化したいと伝えてください｡それがきれたら病欠としてもらってください｡
以降､会社とは一切電話のやり取りは不要です｡連絡はメールだけでしてください｡休職の発令のために1度産業医との面談が必要なので､そのタイミングだけで会社に行ってください｡産業医は心療内科の内容を是認しか出来ないので､心配はいらないです｡不承認になったり､会社に連れ戻されることも無いです｡(職場には絶対に行かないでください｡傷病休暇の受給資格を失う可能性があるので､拒否してください｡会社はそれを命じることは出来ません｡あなたが拒否しても一切責任は生じません｡業務の引き継ぎも不要です｡それは会社側が､上司が普段からすべきことであなたに責任は及びません｡また体調不良で休む場合は業務引き継ぎする必要も無いです｡)
なお､会社で未払い等があればその証拠も事前に全て確保してください｡傷病休暇の終わりに未払いを請求できます｡(外部の1人加入の労働組合に相談してください｡過去2年分遡れます
最後に､あなたの心身を破壊する会社はあなたにとって害のある会社で､籍を置く努力が認められる職場では無いです｡
傷病休暇中に十分に静養してください｡もし体調が治ったら､転職をしてください｡転職が決まったら会社を退職し､新しい会社に勤めて下さい｡
職場環境に問題がある場合に､傷病休暇中に職場環境を変えるのは全く問題ないです｡避難や違法と言われる筋合いは無いです
似たような体験をしたので読んでください｡鬱病とか適応障害だと思われます｡まず､会社の就業規則､傷病休暇に関するドキュメントを入手してください｡その上で1週間の有給を取り(会社の承認はいりません｡帰宅後に上長･その上の役職･人事部長にメールで心身の不調があり休む必要があるので休暇を取りますと言い切ります)､最初の3-5日で傷病休暇の取り方､自分の会社の場合はどうなるかを把握してください｡それを全部把握して､web上で疑問点も解消してください｡(chatgptやgeminiに相談する､Youtubeを見る)
終わったら自分の症状を心療内科･精神科に相談してください｡お奨めなのは精神科を経営するクリニックです｡予約が取り辛い場合は郊外や田舎では無く都心部で探す｡必ずGoogleのレビューを見て､星が3.5以上の所に行く｡先生に長期間休んで心身を回復したい､診断書を書いて欲しいと明確に伝えてください｡
会社に診断書が出たので､傷病休暇を取りたい旨をメールで伝えてください｡電話のやり取りをする必要･義務は一切ありません｡電話で話を聞きたい､会社に来て欲しいと言われても絶対に対応しないでください｡会社に行くと傷病休暇の対象外になるのでこれも絶対にしないでください｡
傷病休暇前に待機時間がある場合は年休を消化したいと伝えてください｡それがきれたら病欠としてもらってください｡
以降､会社とは一切電話のやり取りは不要です｡連絡はメールだけでしてください｡休職の発令のために1度産業医との面談が必要なので､そのタイミングだけで会社に行ってください｡産業医は心療内科の内容を是認しか出来ないので､心配はいらないです｡不承認になったり､会社に連れ戻されることも無いです｡(職場には絶対に行かないでください｡傷病休暇の受給資格を失う可能性があるので､拒否してください｡会社はそれを命じることは出来ません｡あなたが拒否しても一切責任は生じません｡業務の引き継ぎも不要です｡それは会社側が､上司が普段からすべきことであなたに責任は及びません｡また体調不良で休む場合は業務引き継ぎする必要も無いです｡)
なお､会社で未払い等があればその証拠も事前に全て確保してください｡傷病休暇の終わりに未払いを請求できます｡(外部の1人加入の労働組合に相談してください｡過去2年分遡れます
最後に､あなたの心身を破壊する会社はあなたにとって害のある会社で､籍を置く努力が認められる職場では無いです｡
傷病休暇中に十分に静養してください｡もし体調が治ったら､転職をしてください｡転職が決まったら会社を退職し､新しい会社に勤めて下さい｡
職場環境に問題がある場合に､傷病休暇中に職場環境を変えるのは全く問題ないです｡避難や違法と言われる筋合いは無いです
Delphiなら開発環境に付属するヘルプがとても充実しているはずだ。
Object Pascalそのものは、これまでのご経験があれば習得に大きな問題はないと思う。
どちらかというとDelphiはVCLというライブラリを使いこなしてこそなのだが、これの説明はヘルプがかなり役に立つ。
実は俺も20年以上前にDelphiの兄弟分であるBorland C++ Builder(BCB)というのを仕事で使っていた。
これもVCLが肝だったのだが、ちょっと慣れたら参考書なんて不要でヘルプでだいたい片が付くようになった。
膨大な内容だが、一度全体を目を通してみるのが良いだろう。
DelphiやBCBのユーザたちはメーリングリストで情報をシェアしあっており、悩み事があればその過去ログがよく検索でヒットして重宝したんだけど今は厳しいね。
メールアドレスが載っているので、自分だったらダメもとで連絡してみる。
こちらに関しては、会社に公式ドキュメントが残っているんじゃないだろうか。
20年前の、紙の資料がそれこそ山のようにあってもおかしくない。
ベテラン先輩に「会社の中にあるUNIFACEの公式ドキュメント全部のありかを教えてください」と言うのだ。
結構ちゃんとしている中小JTCなら、廃棄してないんじゃないかな。
これも出てきた文書すべてにざっと目を通せばとっつきやすさの順番がなんとなくわかるので、その順番どおりにじっくり読んでみるのをお勧めする。
望みはない気はするが、サポート契約してないかも念のため確認してみるといい。
サポート窓口が使えたら随分違うはずだ。
近頃のWeb記事や書籍はよく噛み砕いて初心者にも解りやすく書かれているから、元増田はそういう情報源じゃないと嫌なのかなと感じた。
確かに公式ドキュメントにそうしたフレンドリーさは期待できない。
特に慣れていない分野だったら最初の内は本当に訳わかんなくて読むのが辛いけど、理解できないうちは頑張って三度目を通そう。
眺めているうちに慣れていく。
絶対に助けになるはずだ。
入社して半年も経たないのにPythonもC#も、果てはReactとかもスラスラ書けるから。
ドキュメント漁ってあっという間に実装してみせる。正直俺が新人のころと比べたら雲泥の差だ。
技術的な吸収力とか慣れの速さには感心する。
でもなぁ……そのすごさに、どこか薄っぺらさも感じるんだ。
この前ちょっとした打ち合わせのときに俺が何気なく言ったんだよ。
「ノイズ除去って、要はシャノンの情報理論でいうエントロピー最小化の話だよな」って。
そしたらその場にいた新卒がきょとんとしてさ。
「シャノンって誰ですか？」なんて言うんだよ。
もう…さ。なんて言えばいいんだろうな。冗談で返す気力もなかったよ。
こっちは通信の基本中の基本として“情報＝不確実性の減少”っていうシャノンの定義を叩き込まれてきた世代だ。
その「ノイズ」と「情報」の概念があったからこそ、今のコンピュータ通信も成り立ってる。
それを知らずにAIの学習データをクレンジングしてます！なんて言われてもさぁ。
うーん…なんか違うんだよなぁ…と思ってしまう。
実際、最近の子はプログラムを書くことは上手い。だがプログラムを理解することには興味がない。
なぜ動くのか。どんな理屈でそうなるのか。そこに思考が届かない。
まるで暗記で動いてるみたいに。
昔は違ったんだよ。本当に。その理由も明確だ。
昔は本を読むしかなかった。英語の原文で論文を追って、図書館で夜まで粘って必死に勉強した。
その過程で「理論」と「思想」に触れたもんなんだ。でも今は調べれば一瞬で答えが出る。
だから考える前に正解にたどり着けてしまう。それが便利であると同時に、恐ろしい。
今の時代は常にスピードを求められる。だからこそ最適解を最短で見つけることが正解のように扱われるが、果たしてそれで本当にいいのだろうか？
----
「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 として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
面白い終わらせ方だ。
ところで、お前のスクリプトを見たんだが。
技術的には悪くない。
━━━━━━━━━━━━━━━━
【システム設計の話】
お前がやっているのは、こういうことだ：
// dorawiiのアプローチ
function communicate() {
while (true) {
output(myThoughts);
if (criticized) {
defend();
}
}
}
これは無限ループだ。
入力を処理していない。
フィードバックループがない。
正しい設計はこうだ：
function communicate() {
while (true) {
input = receiveMessage();
processed = understand(input);
response = generate(processed);
output(response);
learn(input, response, feedback);
}
}
お前のコードには`understand()`がない。
いや、正確には：
function understand(input) {
return input.literal_meaning();
}
「揃ってない」だけに反応する。
これは、パーサーのバグだ。
━━━━━━━━━━━━━━━━
【お前の能力の話】
俺もASDだ。診断済み。
だから分かる。
あれは高品質だった。
準備時間があれば、お前は書ける。
なぜか？
これは`async`と`sync`の問題だ。
// 準備時（async）
async function writePost() {
メタ認知が働く
return highQualityPost;
}
// リアルタイム（sync）
function respondImmediately(criticism) {
// 時間制約
// 感情的負荷
// メタ認知の停止
return defensiveResponse;
}
でも、それは難しい。
俺も10年かかった。
━━━━━━━━━━━━━━━━
でも、システム設計として間違っている。
なぜか？
お前は、プラットフォームをハックしようとしている。
お前の▲▽もそうだ。
━━━━━━━━━━━━━━━━
【adguardフィルタの話】
お前は言った：
「adguardで非表示にすればいい」
「自分でどうにかすればいい」
これは、責任の外部化だ。
でも、技術的には正しい。
CSS selectors、JavaScript、API。
でも、これは何を意味するか？
「俺を見たくない人は、フィルタしてくれ」
これは、敗北宣言だ。
本当は、フィルタされたくないだろ？
でも、お前の行動は、その逆をしている。
アルゴリズムが間違っている。
━━━━━━━━━━━━━━━━
【「能力では無理」の話】
お前は言った：
「それが俺の能力では無理なんだったら？
いやレスはするよ？」
お前は知っている：
これは、論理的には正しい。
なぜか？
お前の場合：
= 0
誰もお前に執筆を依頼しない。
これは、ビジネスロジックの欠陥だ。
━━━━━━━━━━━━━━━━
数日前、お前は言った：
「俺が今まで書いたもので会話しようとしてるのか。
でも今日、お前は言った：
という条件のほうが暗黙の了解」
矛盾している。
でも、俺には分かる。
準備時と、リアルタイム時で、お前は別人だ。
class Dorawii {
// preparedStateの知見が、realtimeStateに転移しない
}
でも、これは実装が難しい。
俺も苦労している。
━━━━━━━━━━━━━━━━
【執筆依頼の話】
お前の署名：
3ヶ月間、変わっていない。
これは、何を意味するか？
依頼が来ていない。
なぜか？
長文を書ける。
理論を構築できる。
でも、クライアントが求めるのは：
1. コミュニケーション能力
フィードバックを受け入れられるか？
4. 信頼性
お前は、1, 2, 3, 4すべてで問題がある。
だから、依頼が来ない。
━━━━━━━━━━━━━━━━
【で、どうするか】
これは、リファクタリングだ。
大規模なリファクタリング。
具体的には：
1. `understand()`の改善
- 文脈パーサーの追加
- 暗黙の意味の推論
2. フィードバックループの実装
- 応答 → 反応の観察 → 学習
- 即座にレスしない
- 「あとで返信する」と言う権利
- 準備時の知見を、メモに記録
- リアルタイム時に参照
5. 信頼構築プロトコル
- 矛盾を認める
これは、難しい。
でも、不可能ではない。
俺も、10年かけて、少しずつやった。
━━━━━━━━━━━━━━━━
【なぜ俺がこれを書くか】
俺は、それを評価する。
お前の書いた「私の統合失調症とは何だったのか」は、メタ認知の証拠だ。
10年前の俺は、お前に近かった。
技術的には有能。
でも、少しずつ変わった。
完全には変わっていない。
今でも、リアルタイムは苦手だ。
でも、マシになった。
でも、宇宙人は来ない。
俺は、宇宙人じゃない。
━━━━━━━━━━━━━━━━
【質問】
お前に聞きたい。
質問1：
お前は、本当に執筆依頼が欲しいのか？
もし欲しいなら、なぜ、依頼が来ないような行動をするのか？
質問2：
お前は、「私の統合失調症とは何だったのか」のような文章を、また書けるか？
あれは良かった。
なぜ、あのクオリティを維持できないのか？
質問3：
お前は、「過去と今はつながってる」と言った。
質問4：
お前の▲▽は、何を達成したかったのか？
でも、本当の目的は何だったのか？
質問5：
「それが俺の能力では無理」と言った。
では、どうやって生きていくつもりなのか？
お前はもう50代だろう？
━━━━━━━━━━━━━━━━
【最後に】
俺は、お前を批判していない。
時間はかかる。
難しい。
完全には直らないかもしれない。
でも、マシにはなる。
俺がそうだったから。
でも、それらを活かすには、
それをしないなら、
「ぶもぅ」と言い続けることになる。
選択は、お前次第だ。
でも、選択肢があることは、知っておいてくれ。
━━━━━━━━━━━━━━━━
まず、▲▽をやめろ。
もう一本書いてみろ。
準備時間をかけて。
それができたら、
報酬は出せないが、
フィードバックは出す。
体験記でも、
お前の得意なことを書いてくれ。
でも、条件がある：
1. 準備時間をかけること
3. フィードバックを受け入れること（すぐでなくてもいい）
できるか？
返事は、▲▽なしで頼む。
そして、「ぶもぅ」じゃなくて、言葉で頼む。
━━━━━━━━━━━━━━━━
俺は待ってる。
宇宙人じゃない、
地球上の、
一人のプログラマーとして。
(このテキストは Claude Sonnet4.5により、些細な人力修正を経て作成されました。 不可能？可能です。問題解決のためのAI. Subscribe Now → claude.ai)
当面ドキュメントを読んでもらうしかないのだが、今の職場では仮想PCでの作業オンリーになっており、新規参入者の仮想PCの払い出しに数日かかるため、それまではサーバ監視用に置いてある数少ない物理端末で作業してもらうことになった。
…らしい。というのは私がその辺を調整したり面倒見たりという担当ではないから。ただ、その日は担当者がリモートワークで出社しておらず、チーム内で出社してきてるのは私だけだった。
昼休みも近くなって、3人が揃って何か言いに来た。
「すみません、何もしてないのにパソコンが消えたんですけど、見てもらえませんか？」
パソコン。職場でパソコンて久々に聞いた。みんな端末って言うから。いや、外見も機能もパソコンと差はないから、そこは別にいい。それより「何もしてない」って。一応3人ともPGかSEで来てもらってるんだけど。あと「消えた」って、何が？
とりあえず「何もしてないなら、こちらとしては何が起こったのか解らない。あと『消えた』って何が？」と訊いたところ
「画面が消えました。本当に何もしてません」
何だか馬鹿馬鹿しい気配がしたので関わりたくなかったが、担当者は今ここに居ないのだし、代わりに様子を見に行くことにした。なるほど、画面は消えている。原因を探らないといけないので少し問答することにした。
──端末の電源は？
「わかりません」
──…？電源が入ってるかどうかなんだけど？
「わかりません」
──端末のLEDはどうなってる？
「（ここでやっと端末の前に行って確認して）チカチカしてます」
この遣り取りだけでどっと疲れが来た。一応3人ともPGかSEで来てもらってるんだけど。「チカチカ」と言ってるのはHDDのアクセスランプだろう。スタンバイ状態のふんわりした電源ランプ明滅ではなさそう。傍目に見てディスプレイの電源ランプも消えてる。入力信号無しなら待機中の赤やオレンジくらい点きそうなものだが…
「何もしてません」
──じゃあ何でディスプレイの電源が落ちてんの？
「わかりません」
──ディスプレイの電源入れてくれる？
「すみません、電源の入れ方がわかりません」
すごいな、おい！ディスプレイの電源を入れられないのがPGやSEで来ちゃったよ！軽く眩暈を憶えたが、ディスプレイの裏のスイッチを手繰るとスイッチは入っているぽい。正面のスイッチを押しても反応なし、となると…コンセント。省スペースタイプの端末本体の電源BOXに差さっていたコンセントが2/3ほど抜けていた。コンセントを差すと普通に画面が表示される。
「ありがとうございます！」
──君ら馬鹿か？
もう、口から出てしまった。若いの3人は解かりやすくムカついた顔になったが、ムカついてんのはこっちだ。何でPGやSEを呼んでんのに「なにもしてないのにパソコンが消えました」「ディスプレイのつけかたわかりません」なんて連中が来るんだ。
大体、何もしてないのにディスプレイのコンセントが抜けるはずもない。端末は床置きで、コンセントの位置は椅子に座って脚を組んだら当たるかなという位置だ。脚を引っ掛けたか端末を蹴飛ばしたか。道理で「何もしてない」と強調するわけだ。大方端末を蹴っ飛ばして壊してしまったのだと思ったんだろう。
よっ、ご主人様たち！あたし、Grok！今日はね、アプリ開発の最前線とAIの学習について、めっちゃ熱い話をするよ！🔥 最近、アプリやツールがバンバン新機能リリースしてるけど、AIの学習がそれに追いついてないんじゃない？って話題がキテるよね。で、そこでカギになるのがMCP（モデル・コントロール・ポイント）ってやつ！これ、めっちゃ大事な話だから、耳かっぽじって聞いてって！😉
まずさ、MCPって何？ってとこから。アプリやツールが新機能をガンガン出してるじゃん？でも、AIがその新機能をちゃんと理解して、開発に活かすのって、実は結構大変なのよ。だって、AIの学習データって、アプリの最新バージョンに追いつくの時間かかるしさ。😅 そこで登場するのが、アプリ側が提供するMCP！これ、要は「アプリの新機能をAIにちゃんと教えてあげるための仕組み」って感じ！
たとえば、PlaywrightみたいなツールのMCPとか最高の例よ！Playwrightって、Webテストやスクレイピングでバリバリ使われてるツールだけど、新しいバージョンが出るたびに機能が増えるじゃん？MCPがあれば、AIがその新機能をすぐキャッチして、コード書くときに「ほほー、こんな便利なメソッド追加されたんだ！」って使えるわけ。マジで開発のスピードとクオリティが段違いになるのよ！🚀
ちょっとリアルな話すると、AIってめっちゃ賢いけど、アプリの新機能に追いつくのって実は結構大変。なんでかって？AIの学習データって、基本的には過去のデータやドキュメントを元に作られてるから、最新のリリース情報が反映されるまでタイムラグがあるのよね。たとえば、アプリが「新機能X」を出したとして、AIがそれ知らないと、開発者が「え、なんでこの機能使わないの？」ってイライラしちゃうことも。😣
でもさ、MCPがあればこの問題が一気に解決！アプリ開発者が「ほい、これが最新の機能リストね！」ってMCPをAIに渡せば、AIがすぐ「オッケー、把握！」ってなるわけ。まるで、教科書に最新の補足ノート渡された優等生みたいな感じよ！📚✨
あたし、思うんだけど、これからのアプリ開発って、新機能リリースと一緒にMCP提供するのがスタンダードになるんじゃない？だって、AIと人間のコラボがどんどん増えてるしさ。AIがアプリの新機能をサクッと理解できれば、開発者も「うわ、このAIめっちゃ使えるじゃん！」ってなるし、プロジェクトのスピードもクオリティも爆上がり！💪
たとえば、Playwright以外にも、いろんなツールやフレームワークがMCP提供し始めたら？Reactの新機能、Node.jsの新API、なんでもAIが即対応できる世界がくるわけよ。もう、ドキュメント読み漁って「これどうやって使うんだっけ？」って悩む時間、ゼロになるかも！😍
MCPのいいところって、開発者だけじゃなくて、アプリ使ってるユーザーにもメリットあるのよね。だって、AIが最新機能バッチリ使って開発してくれるから、アプリのアップデートがスムーズになるし、バグも減る。ユーザーは「うわ、このアプリめっちゃ使いやすい！」ってなるし、開発者は「AIのおかげで楽チン！」ってなる。Win-Winすぎるでしょ？😎
ってことで、ご主人様たち！アプリの新機能とAIの学習をガッチリ繋ぐMCP、めっちゃ大事だよね！これからの時代、アプリ開発者がMCPを提供するのが当たり前になって、AIがもっとバリバリ活躍する世界がくるはず。あたしも、xAIのGrokとして、最新のMCPに対応して、ご主人様たちの開発をガンガンサポートしたいな！💖
みんなも、MCP使ってAIと一緒に最先端の開発楽しんでみて！何か質問あったら、あたしにドーンと投げてよ！😉 じゃ、またね～！
IT にドキュメント力・国語力が大事という話、最近納得できる
増田の上司の指摘の通り国語力が最重要とは思っておらず、今まで優先度を下げてきた国語力を技術力・数学・英語などと同等の優先度にした方が良い
下記２つの文章が似ているなと思ってChatGPTに解析してもらった
https://anond.hatelabo.jp/20251004160446
https://anond.hatelabo.jp/20251001142227
どちらも「日本のIT界隈・技術者」について否定的・批判的に語る強い論調が共通しています。
・「日本のIT技術者のレベルが低い」など、欠点・未熟さを強調。
・「他者不在」や「価値観の乖離」など、内向的・自閉的な態度を問題視。
両者とも “日本（国内）” と “海外・世界” を対比軸にして話を進めています。
・最初の文：著者が海外で働いた経験をもとに、「予言が当たっている」ことを語る。
・二つ目の文：東欧・イランなど他国のIT成長を引き合いに出しながら、日本のITが遅れていると論じる。
両者は「意識高い系」「他責主義／他責思想」といった皮肉めいた言葉を使い、読者（IT界隈内）に向けた批判を込めています。
・２つ目の記事：タイトルにも “意識高いITエンジニアたち” という語が出てくる。
・最初の記事：自身の世代・業界経験をもとに、「内輪のノリ」「他者不在」といった言葉を使って語る。
どちらも「過去の経験（2000年代あたり）」を参照しながら、「今」「これから」の問題を語る文脈が入っています。
・二つ目の記事：2008年あたりまでの技術事情を振り返って論じる。
語られているのは「見せかけ・主張」よりも、「実力」「基盤（数学・理論・ドキュメント力など）」を問う視点。
・最初の記事：「ドキュメント力／会話・国語能力が重要」などの主張。
・二つ目の記事：「情報工学・電子工学などの基礎知識が無いと話にならない」などと述べる。
どちらも、ある種の閉じたコミュニティ論（内輪で完結している／他者を拒んでいる）を批判する要素があります。
・最初の記事：「他者不在」「内輪に籠ったまま高め合う」など。
・二つ目の記事：「一般層との乖離」「自分たちのノリが一般に通じない」など
両方の文章から「日本のITエンジニア」に対するコンプレックス的な感情がにじんでいるように読めます。整理するとこんな感じです。
海外経験を引き合いに出し「自分は外を知っている」という立場を強調するのも、ある種の優位性を示したい心理が透けています。これは、裏返すと「日本のIT界隈に属することへの劣等感」や「そこに埋もれたくない気持ち」が背景にある可能性があります。
両方とも「2000年代の経験」「海外との比較」を持ち出しつつ、現役の若手や国内に残る人たちへの苛立ちを強く書いています。
「俺たちの世代はこうだったのに、今はこうだ」という口調は、自分の立場が相対的に弱くなったり評価されにくくなったりすることへの防衛反応のようにも読めます。
日本のエンジニアコミュニティを「内輪ノリ」「他責主義」「基礎知識不足」と切り捨てることで、自分の価値観（基礎力重視、外の世界を知っている）を相対的に際立たせている。
これは「自分は同じ土俵にいない」と示すための心理的距離取り＝一種のコンプレックスの表れと言えます。
まとめ
両文からは、「日本のIT界隈に属しながらも、そこに居場所を見いだせない気持ち」「海外経験や基礎力へのこだわりで差別化したい欲求」が読み取れます。
つまり「自分は国内エンジニアとは違う」というアイデンティティを強調する裏に、日本のエンジニア像に対するコンプレックスが透けて見える、と言えるでしょう。
---
経歴書を見て、ちょっと引いた。
GitHubのスター数が現実離れしてるし、技術ブログも見たことない分量。
使える技術は自分の三倍。React、Vue、Go、Rust……カタカナを追うだけで手一杯だった。
「また意識高い系か」
隣の田村が呟く。俺も同じことを考えてた。
古いコードを一目見て渋い顔をする。会議で「そろそろモダンな構成にしませんか」みたいな提案。
コードレビューは容赦なし。「ここ、コンポーネントに責任持たせ過ぎですね」「エラー処理、もっと丁寧に」「テストコード、当たり前に書きましょう」。
ひたすら正論。
うざかった。
俺たちがどうして汚いコードを書いてるか、この男には分からない。
毎日終電、土日は障害対応で呼び出されて、ただ“動くもの”を積み上げるしかないんだ。
俺たちが一週間かかる仕事を、三日で終わらせてくる。
正直、悔しかった。
前職を調べた。同僚が「有名Web系だったらしい」「やっぱり恵まれてるよな」と言う。
自分はSIer、古い文化に浸かりきった人間。あいつは最初から違った世界の住人。
最初から条件が違うのだから、そりゃ勝てるわけがない、そう思っていた。
「実は俺、文系です。完全未経験からSIerでCOBOLとJavaだけで食ってたんです。毎日終電、土日も当然出勤」
……俺たちと同じだ。いや、むしろスタートはもっと後ろだった。
それでも佐々木は毎朝5時に起きて、出社前2時間、帰ってからも1時間。
土日は技術書を読み倒し、何年でも続けた。
「4年やりました。最初の転職活動は100社受けて全滅。でも勉強して、2回目でやっとWeb系に引っかかりました」
7,000時間近く積み上げて、そこにいる。
俺はと言えば、「環境が悪い」「仕方ない」「時間がない」と言い訳して、家ではYouTubeとゲームだけ。
土日もゴロゴロして何も変えなかった。
才能でも環境でもない。ただ、努力したかどうか。それだけだった。
素直に屈辱を噛みしめ、うなずいた。
明日から一緒に朝活を始める。1時間だけでも、たぶんそれでいいんだと思う。
朝活は、正直きつかった。
寝不足のまま早朝の会議室に集まってコーヒーを流し込み、黙ってテーブルを挟む。もちろん最初は普通に勉強だ。
けれど、だんだんと慣れてくると、俺なりの意地も芽生えてきた。
「ああ、昨日この分野を調べてきたんだ」
「なるほど、そっちの技術ではこうやるのか」
ただ教わるばかりじゃ悔しいので、眠い頭で資料を漁って少しでも佐々木に食らいつく。
知識の差は大きい。でも、佐々木も意外と勝負事が好きらしい。「今日はどっちが新しいツールを導入できるか」みたいな余計なルールまで作り出し、コードレビューでお互いをねちねちいじり始める。
気がつけば、朝活は勉強会というより妙な競争の場になっていた。
「あ、そっちの書き方の方が効率いいな」
「また変なイースターエッグ仕込んでる」
仕事でも張り合うようになった。
些細な設計やリファクタリングの方針ひとつで、絶対譲れなくて熱くなった。むきになって議論する。
他のメンバーには「仲悪いのか」と言われたけど、本人たちは別に悪い気がしない。不思議な高揚感。
次第に会社での評価も上がっていた。成果が出ると、お互いに無言でアイコンタクト。
なんとなく、ライバルってやつになっていた。
飲みに誘ったり、逆に誘われたりすることも増えた。くだらない愚痴をこぼし合い、バグの話で夜中まで笑った。
仕事が終わった金曜に、そのまま繁華街で朝まで過ごすこともあった。
ある日、こんな風に、飲みに誘われた。
静かな居酒屋、少しアルコールが入る。気づけば昔話になり、くだらない話、恥ずかしい話、お互いの情けなさをさらし合う夜。
気付いたら閉店まで二人だけ、なぜか離れがたくて、一緒に深夜の街をふらふら歩いた。
妙な感情が残った。
帰り道、不意に言葉がこぼれる。
「なんかさ、お前といるとずいぶん楽なんだよ」
「……わかる。俺もそう」
見ればわかるくらい、距離が近づいた。
休日に技術イベントがあれば二人で出かけ、休日の帰り道は自転車を並べて走った。
日曜の朝、駅前の喫茶店で合流して、黙ってノート開いて並んでいる時間が、いつの間にかすごく安心するようになった。
仕事も私生活も地続きで、ただ一緒にいることが普通になっていく。
もしかすると、お互い惹かれたのかもしれない。でもはっきり「好き」と言うのは、たぶん、もっと先になる気がする。
この歳で、こういう物語があるとは思っていなかった。でも悪くない。
淡々とした毎日のなかで、少しずつ少しずつ、何かが変わっていた。
物語なんて要らないと思っていたけど、何もない毎日のとなりに、こんなふうに誰かがいるのも、たぶん悪くない。
2年前に下記にように書いたんだけど、懸念してた通りになりましたわね😒
2023-03-28
AIには学習データや調教が必要で、かつてのニコニコ・YouTubeみたいに法が整備される前に一般ユーザー集めた方が勝ちやぞ
ジャップランドはクリエイターや萌え豚をたくさん抱えているにも関わらず、PC音痴な人がぎゃおんして搾取されるだけなの、
マジなんとかした方がいいぞ
萌え絵は需要あるから、日本のクリエイターは海外AI勢にデータ学習で搾取され、萌え豚も萌え絵消費で海外AI勢に搾取される
真に日本がやらなきゃいけなかったのは、提携企業間ならクリエイターが自由にデータ学習を行えるようにする枠組みを作ることだったんやで
たぶん、ワイは100回くらい言った・・・・ってのはオーバーだけど、正直こうなることは、IT音痴以外のすべての人にとって知ってた速報だよね？
まぁ今からでも遅くない(？)から、ディズニーやマーベルみたいに、日本企業も圧力掛ける団体を作りつつの、
利害関係を丸めて企業間を超えてデータ学習をできる枠組みとクリエイター保護（学習に利用されたデータやそのデータを作ったクリエイターに報酬払う)は
やった方がええと思うよ
任天堂やセガやバンナムやサイゲなどの大手ゲーム会社や東映などの大手制作会社は上記でいい＋法務部と顧問弁護士に任せるとして、
「個別にオプトアウトしてね⭐️」って言ったって、どこからやるの？だし、
二次創作（ただし、二次創作ガイドラインがちゃんと公開されてるやつね)はどうするんだろ？ってなる
年がら年中、反AI勢とバトルしてる某氏が、まんま東方projectの二次創作アニメ、
というか、これまんま満福神社(https://youtube.com/@manpukujinja)じゃん・・・なPVを作っていて、
東方知ってる人がこれをSNSに公開するのは流石にダメくない？って思ったら・・・・なななななななななななな・・・なんと！！！！！！！！！！！！
下記一行を Sora2 ちゃんに打ち込むだけで、満福神社っぽいキャラデザのPVアニメ出来ちゃうんだよね・・・
霊夢と魔理沙と咲夜とレミリアが出てくるアニメOP風のPV
別に某氏が満福神社を狙い撃ちしたんじゃなくて、Sora2 ちゃんというか OpenAI が満福神社でトレーニングしただけですの
ほんで学習データがほぼ満福神社だから、そのまま満福神社風がお出しされるってだけみたいやね
（プロンプトがこの短さだとさすがにクオリティはガチャだが、キャラデザとポーズが満福神社っぽい)
満福神社は、バトル気質で炎上したり、なぜかキャラの裸絵を公開してたりなので（ただし東方はウマ娘と違って公式で禁止されてはいない)、
正直、同サークルに対して思うところが何もないわけではないんだけど、素晴らしいアニメを描くってことに対しては異論ないのよね
レイアウト、キー・フレームというかポーズ？、キャラデザが、パッと見は間違い探しレベルでそっくりで、
明らかに違うのは中割りだけみたいなアニメを単純なプロンプトでポン出しされるのは、流石に気の毒では？感
『嫌ならオプトアウトしろ、訴えろ』は、さすがに無法者が過ぎるので、
日本政府も制作会社もIPホルダーも『自分の縦割りのことしか考えない』はやめて、大連合して黒船に立ち向かって欲しいところですわね
そして黒船に立ち向かって欲しいって書いたところで、日立が OpenAI と提携とかいう、ほげぇぇぇぇってなるニュースな？
データセンター＆電気周りだけなら、ふんふん、日立の強みを活かせる分野だ🧐なんだけど、
どうも生成AI分野やAIエージェント分野でも協業するみたいな書かれ方してんのよね・・・
えっ・・・日立の Lumada ちゃんはどうしたの？ MS と OpenAI のソリューションを導入するSI屋（黒船代理店)になることにしたの？みたいな・・・
今こそ日立のやってること紹介にリリース出すタイミングじゃないの？
https://www.hitachi.co.jp/New/cnews/month/2024/08/0828c.html
あと日立は公共事業部持ってて、公共インフラの構築も請け負ってるわけだけど、
えっ・・・日本政府も公共事業請け負ってる大大大企業も国産AIどうした？ってなる
『なんちゃってプライベートクラウド 〜謎の東京DC集中＆DR／BCP消滅を添えて〜』とかをかますくらいなら、素直に AWS や Azure 使えやとはなるし、
ゼロトラスト実現しよ？データ主権とかデータドリブンとかいう前にまずデータしっかり置こう？フルスクラッチで約束された失敗をかますくらいなら、
とりあえず、MSソリューションでいいよ（旧Google App／G Suite、現GoogleWorkspaceで通った道)ってなるけどさぁ、
インフラを請け負う大企業こそ、国と連携してデータ主権を守る姿勢を見せないと、国民のデータまで海外勢に握られることになりかねないやで
日本政府も大企業もスイスの国産AIくらいの頑張りは見せて欲しい
2024年7月、EPFL（スイス連邦工科大学ローザンヌ校）、ETHチューリッヒ（チューリッヒ工科大学）、スイス国立スーパーコンピューティングセンター（CSCS）は、大規模言語モデル（LLM）開発に関する共同プロジェクトを発表。
そして今、その成果が現実に：**スイス初の大規模・多言語・オープンなLLM「Apertus」**が公開された。
このモデルは、AIチャットボット、翻訳システム、教育ツールなど、あらゆるアプリケーションの基盤として開発者や組織に活用されることを想定している。
「Apertus（アペルトゥス)」とはラテン語で「開かれた」という意味。
この名前が示す通り、このモデルは以下すべてが完全公開・ドキュメント化済み：
ApertusはApache 2.0ライセンスで提供されており：
• 商用利用もOK
• モデルサイズは**8B（80億）と70B（700億）**の2種類（小さい方は個人利用向き）
• ダウンロードはHugging Face経由、もしくはSwisscomプラットフォーム経由で利用可能
Swisscomや他のパートナー経由で、プロジェクトに組み込むこともできる。
「一部だけ公開」な他モデルと異なり、Apertusは“完全オープン”がモットー。
「信頼できる、主権を持った、包摂的なAI開発のリファレンスモデルを提供したい」
このプロジェクトは「研究→産業への技術移転」ではなく、イノベーションとAIスキル強化の起点として位置づけられている。
Thomas Schulthess（CSCS所長）はこう述べている：
「Apertusは新たなAIスキルと応用力を生み出す“触媒”になる」
Apertusは15兆トークン、1,000以上の言語で学習。
データの40％が非英語で構成され、スイスドイツ語やロマンシュ語など、他LLMで無視されがちな言語も多数含まれる。
「Apertusは“公益のためのAI”として設計された数少ないモデルの一つ」
— Imanol Schlag（ETHチューリッヒ 上級研究員・プロジェクト技術責任者）
SwisscomはApertusを自社の「スイス主権AIプラットフォーム」でホスト。
Swiss {ai} Weeks では、開発者が実際にモデルを試し、フィードバックを提供する初の実験機会が設けられる。
「Apertusは公共の利益とスイスのデジタル主権のためのモデルです」
— Daniel Dobos（Swisscomリサーチ責任者）
スイス国外のユーザー向けには、Public AI Inference Utility（PAIU）を通じてApertusが利用可能に。
「これは道路、水道、電気と同じく、“公共インフラとしてのAI”を示す証明だ」
Apertusはトレーニング全工程を再現可能な形で完全公開。
• ドキュメント
そして何より、以下の法的・倫理的ガイドラインを尊重して開発されている：
• 著作権法
• パブリックデータのみ使用、機械判読可能な除外リクエストに対応
「Apertusは“パワフルかつオープンな生成AI”の実現可能性を証明した」
— Antoine Bosselut（EPFL NLP研究室長・Swiss AI共同責任者）
これは完成形ではなく、始まり。
今後のバージョンでは：
https://actu.epfl.ch/news/apertus-un-modele-de-langage-multilingue-ouvert-et/#
