  |
はてなキーワード:バグとは
外国人には所得税が20％かかるから、2万円の所得税が引かれて8万円しか渡せないんだよ
たとえば、うちの会社で講演してもらうとして外国人呼んで、ホテル代を10万円渡したら、8万円しか渡せないんだ
ホテル代が2泊で10万だとしたら、その外国人は2万円の赤字なんだよ
でも！
会社が直接ホテルにホテル代を10万円払えば、税金はかからないんだ！
ホテルに泊まったという事実は変わらないのに、ホテル代の渡し方で税金が2万円も変わるんだよ！
だから誰か呼ぶ時のホテル代は、会社が直接ホテルに払うようにしてる
呼んでおいて自腹になるのはおかしいもんね…
その感じわかるわ。私はそんな感じになってオンラインクレーンゲーム中毒みたいになってだいぶお金使っちゃった。1番キツい時期はギャンブル依存症になって頭がバグってたおかげで、しばらく経ったら子供も成長して多少マシになったし、私の精神が多少まともになって元の趣味に戻れてギャンブルからも足を洗えた。子育ての悩みとか罪悪感よりもオンクレにお金を使ってしまった罪悪感で日々目の前の現実から目を背けるひどい有様だった。こういうカスみたいな奴もいるから今に絶望しすぎなくても何とかなることもある
というより今のコンテンツ産業の重要性考えればクリエイターが日本で一番重要なのにそれ以上にどうでもいい仕事が守られたのがバグだった。
@motineko_qatr
私が制作した音声作品がbilibiliに無断転載されていたので、コメント欄に「聴くならお金払って買ってね😄」と凸った所、『ほとんどの中国人には気軽に買える収入がなく、買わないと聴いてはいけないのか？』と返信があった。
そ う だ が ？
@motineko_qatr
無断転載で何が胸糞かって、その音声作品はヒロインが余命半年の宣告を受けて彼氏に最期のメッセージとしてASMR音源を遺したという内容なんだけど、コメント欄で「実は私は医者であの時の診断は誤り。今は彼女とハネムーンに来てるよ」ってあって、それに賞賛のコメントがたくさん付いてた事。
私の作った私の作品の中で、彼女は亡くなりました。それを捻じ曲げて喜ぶ様な楽しみ方、聴きたかをされたのが許せない。
創作するものとしてこれ程の侮辱はそうそう無いんじゃないかな…
https://b.hatena.ne.jp/entry/https://togetter.com/li/2618559
数年前、年収900万超でシステム開発のマネジメント職に転職した。前職も同じくらいの年収だったんだけど、そもそもあれがバグってた。今になって振り返ると、完全に身の丈に合わない転職をしてしまったと後悔している。
前職の入社時の年収は350万くらいだった。オーナー企業の少人数の会社。上司も部下も顧客もそこまでITに詳しくなくて、ハッタリかませばだいたいなんとかなる環境だった。
もともとITをよく分かっていない人の話を聞いて整理するのは得意だったので、エンジニアからPMになり役職がついた。気づけば年収は入社時の2.5倍以上になっていた。
モダンな開発はなんとなく齧ってた程度で、基本はハッタリマネジメントでなんとかなった。作ってたシステム自体もそんな複雑なものでもなかったし。
経営陣がいろいろやりたがる人たちだったので、広く浅くなんでもやってみたい自分には性が合っていた。ただ、いろいろあって辞めることにした。
転職活動を始めた時に出会ったのが「錯覚資産」という考え方。ふろむださんの『人生は、運よりも実力よりも「勘違いさせる力」で決まっている』で知った。
前職で900万近い年収だったので、ハロー効果が効いて年収を維持したまま転職できた。LLMのように相手に合わせてこういう言葉を紡げば相手は納得してくれるだろうという能力には長けていたので、面接はハッタリでなんとかなった。
実務で足りないところは、ハロー効果が効いているうちに実力をつければ何とかなるだろうと思っていた。甘かった。
現職は前職と違って、成長企業といえどちゃんとした会社。オーナー企業的な空気もなければ行き当たりばったりでもない堅実なところだった。
そして何より、バリバリモダン開発の会社だった。SREだDevOpsだDDDだスクラムだなんだかんだと、今までとの落差が激しすぎる。
上司も同僚も部下もシステム開発をよく分かっている。システムがわからんという人のために色々整理してあげるという、自分のコア能力が全く発揮できない。
伸び悩んでいる部下へも適切な指導ができない。前職まではシステムよく分かっていない顧客と上司に納得してもらえばなんとかなったので、部下は育てなくてもなんとかなっていた。困ったときは外注を入れて凌いでいたし。
もう、上司・同僚・部下からなんとなく腫れ物扱いになっている。年収も年収なので会社に対して申し訳ない気持ちになってきた。会社も余裕があるわけではないし。自分が無能だということがなんとなくわかり始めてツラポヨ。
なんかエンジニアリング自体に自分が興味なかったんだなぁということを実感した。
なんだろう、もともとウェブ屋に毛が生えたみたいなシステムなんでも屋おじさんだったので、バリバリエンジニアリングの専門集団に入ってしまい違和感が半端ない。
俺はウェブというメディアに興味があるのであって、エンジニアリングそのものには興味がないのだ。ということに今さらながら気づいた。
昔のワールドワイドウェッブはねぇ、なんというか、自由というか個人が自宅の机の上から世界中に情報を発信できるという夢に溢れていたのだよ。なんだね今のウェブは。ただのシステムが乗っかるための土台でしかない。面白くなくなったねぇ。Flashとかの標準なんかクソくらえな「リッチコンテンツ」が溢れていたときはなんかカオスな楽しさがまだウェブにあったが、もうなんかビジネスしか残ってないのはなんなのかね。どこに行っちゃったのかね。
閑話休題。
錯覚資産はコンフォートゾーンから一つ抜けたストレッチゾーンに行くために使うべきだった。自分の場合は一歩超えてパニックゾーンに行ってしまった。
最初は周りも良い人だらけだったので、持ち前のハッタリでなんとなくやり過ごせた。でも数年経つと化けの皮は剥がれる。
あと、ハッタリかますのに全力を使いすぎて余裕がなく、力をつける時間を作れなかったのが敗因だと思う。
まぁまた転職すれば現職の錯覚資産のハロー効果でなんとかなると思う。年齢的にだいぶ中年なので不安もあるが、ストレッチゾーンに当たりそうな会社にどうにか転職したい。年収は下がりそうだけど。
もしくは開き直って居座るか。でもこの精神状態で居座り続けるのもキツい。
錯覚資産を使う場合は十分気をつけてください。背伸びしすぎると、自分も周りも不幸になります。
そして何より、自分が本当に何に興味があるのか見極めてから使いましょう。年収やポジションに目が眩んで、自分の適性を見誤ると地獄を見ます。
Permalink |記事への反応(13) | 23:07
----
「My Job Went ToIndia」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went toIndia :オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は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 toAI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
とあるシステムのヘルプデスク対応をしている。エラーが出たりした時にユーザーが慌てて問い合わせをしてくる電話窓口である。
問い合わせをする時にユーザーが、システムの利用状況を話すんだが、そこに嘘が多くていつも笑ってしまう。
何もしてないのに突然挙動がおかしくなったとか、所定の操作をしたのだがうまくいかないとかそういう問い合わせである。たいてい、こちらで調べると、何もしてないと言いつつ、直前に誤った設定変更してたとか、正しく操作したとか言いつつ間違った操作をしている。こっちは、どんな操作をしたかのログも全て見れる立場なので、その手の嘘は結局分かってしまうのである。
とは言いつつも、そういくだらない問い合わせの一部には、システム側が想定してないミスやバグの類を掘り当てていることもあるので、毎回の一応確認はしている。ユーザーって嘘ばっかりだよなあ，と呆れつつも、そんなに嫌な仕事ではない。
そんな日々の中で最も厄介なのは、CxOたちだ。
──CIO、CTO、CDO、CISO、CPO……肩書きは違っても、やっていることはだいたい同じ。
PowerPointを開いて「DXを推進している」と言う人たち。
うちのCxOはこう言った。
翌日、僕がPull Requestの内容を説明したら、「Goってタクシーのサービスの？」と返された。
その瞬間、何かが切れた。
──ケーキではない。
CxOたちはコードを読めない。
それ自体は罪ではない。
だが、読もうとしないことは怠慢だ。
よく聞く反論がある。
確かにそうだ。
ただし前提が抜けている。
つまり、コードを読めという話ではなく、読めるだけの構造理解を持てという話である。
「技術的なことは詳しくないが、成果は出している」
それはたまたまだ。
「上が言ってるから」「今期の方針だから」「スピード優先で」。
Pull Requestは読まないのに、Excelの進捗バーだけが毎日更新される。
これもよく聞く言い訳だ。
しかし、リソースが限られているならなおさら、理解の精度が重要になる。
僕が書いたAPIは、リクエストごとに外部APIを叩いていた。
「キャッシュを挟もう」と提案したが、PMは「リリース優先」と言った。
CxOたちは言った。
「想定してなかったのか？」
──想定してた。
だが、理解できないのは説明の問題ではなく、聞く姿勢の問題だ。
Slackの“#incident”チャンネルだけが、いつも一番アクティブだ。
CxOたちは「コストを切れ」と言う。
切れるのはコストだけ。
削ったコストの穴埋めに、技術的負債の利息を支払うのは現場だ。
Goで書かれた美しい構造体も、やがてはコメントだけが動くレガシーになる。
CxOたちは「我々はデジタル変革を進めている」と言う。
だが変わっているのは、スローガンのフォントと会議資料の配色だけだ。
クラウド導入もAI活用も、認知が変わらなければ儀式でしかない。
──違う軸を持つのは構わない。
現場を理解しない経営視点は、地図を見ないドライバーと同じだ。
「コードなんて書かなくていい。これからはノーコードの時代だ。」
だが、それは“コードをなくす”技術ではなく、“コードの抽象度を上げる”技術だ。
だが、隠したコードが消えるわけではない。
ボタンの裏にも、ワークフローの下にも、API呼び出しやロジックは確実に存在する。
それを理解せずに使えば、「コードを書かずにバグを埋める」だけの仕組みになる。
「ノーコードでいい」と言うCxOは、
「物理を知らなくてもロケットは飛ぶ」と言っているのと同じだ。
理解しないまま導入するノーコードは、“ノーコード”ではなく“ノーガード”である。
人を楽にするどころか、誰も直せない仕組みを量産する。
DXとは、ツールを導入することではない。
それを理解しない限り、
理解しないことだ。
真っ先に切られるのは、
──コストだけ。
CxOたちは「未来を見ている」と言う。
未来とは、仕様書ではなく、Pull Requestの積み重ねだ。
ChatGPT:
はい、Delphi（ObjectPascal）のソースも読めますし、解説・リファクタ・バグ箇所の指摘・他言語への移植案など対応できます。
VCL /FMX、Generics、Interface/RTTI、プロパティ/イベント、レコード・セット型、メモリ管理（string/AnsiString/UnicodeString の違い）、スレッド（TThread / TTask）、WinAPI/COM 呼び出し、uses単位構成、.dfm（フォーム）やリソース周りもOKです。
コードを貼ってくれれば、1ステップずつ説明や改善案を出します（DelphiのバージョンやVCL/FMXも書いてあると精度上がります）。
UNIFACEはどう？
ChatGPT:
はい、UNIFACE（Proc言語）も対応できます。フォーム/サービス/レポート/エンティティなど各コンポーネントのトリガ（initialize, validate, leavefield など）、operation／entry、newinstance/activate/call、retrieve/e, read,write、エラー制御（$status, $procerror）や論理名・assignment(.asn)、署名/パラメータ、DSP/REST・SOAP連携、DBドライバ設定までOKです。
コードや .asn を貼っていただければ、処理フローの解説、バグ箇所の指摘、リファクタ、他言語・他フレームワークへの移植案（例：REST API化、Java/Python 置き換え）まで具体的にやります。
可能なら UNIFACE のバージョン（9/10/10.4 など）、DB（Oracle/SQL Server 等）、OS を添えてください。
面白い終わらせ方だ。
ところで、お前のスクリプトを見たんだが。
技術的には悪くない。
━━━━━━━━━━━━━━━━
【システム設計の話】
お前がやっているのは、こういうことだ：
// 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ヶ月間、変わっていない。
これは、何を意味するか？
依頼が来ていない。
なぜか？
長文を書ける。
理論を構築できる。
でも、クライアントが求めるのは：
フィードバックを受け入れられるか？
4.信頼性
お前は、1, 2, 3, 4すべてで問題がある。
だから、依頼が来ない。
━━━━━━━━━━━━━━━━
【で、どうするか】
これは、リファクタリングだ。
大規模なリファクタリング。
具体的には：
1. `understand()`の改善
-文脈パーサーの追加
- 暗黙の意味の推論
2.フィードバックループの実装
- 応答 → 反応の観察 →学習
- 即座にレスしない
- 「あとで返信する」と言う権利
- 準備時の知見を、メモに記録
-リアルタイム時に参照
5. 信頼構築プロトコル
-矛盾を認める
これは、難しい。
でも、不可能ではない。
俺も、10年かけて、少しずつやった。
━━━━━━━━━━━━━━━━
【なぜ俺がこれを書くか】
俺は、それを評価する。
お前の書いた「私の統合失調症とは何だったのか」は、メタ認知の証拠だ。
10年前の俺は、お前に近かった。
技術的には有能。
でも、少しずつ変わった。
完全には変わっていない。
今でも、リアルタイムは苦手だ。
でも、マシになった。
でも、宇宙人は来ない。
俺は、宇宙人じゃない。
━━━━━━━━━━━━━━━━
【質問】
お前に聞きたい。
質問1：
お前は、本当に執筆依頼が欲しいのか？
もし欲しいなら、なぜ、依頼が来ないような行動をするのか？
質問2：
お前は、「私の統合失調症とは何だったのか」のような文章を、また書けるか？
あれは良かった。
なぜ、あのクオリティを維持できないのか？
質問3：
お前は、「過去と今はつながってる」と言った。
質問4：
お前の▲▽は、何を達成したかったのか？
でも、本当の目的は何だったのか？
質問5：
「それが俺の能力では無理」と言った。
では、どうやって生きていくつもりなのか？
お前はもう50代だろう？
━━━━━━━━━━━━━━━━
【最後に】
俺は、お前を批判していない。
時間はかかる。
難しい。
完全には直らないかもしれない。
でも、マシにはなる。
俺がそうだったから。
でも、それらを活かすには、
それをしないなら、
「ぶもぅ」と言い続けることになる。
選択は、お前次第だ。
でも、選択肢があることは、知っておいてくれ。
━━━━━━━━━━━━━━━━
まず、▲▽をやめろ。
もう一本書いてみろ。
準備時間をかけて。
それができたら、
報酬は出せないが、
フィードバックは出す。
体験記でも、
お前の得意なことを書いてくれ。
でも、条件がある：
1. 準備時間をかけること
3.フィードバックを受け入れること（すぐでなくてもいい）
できるか？
返事は、▲▽なしで頼む。
そして、「ぶもぅ」じゃなくて、言葉で頼む。
━━━━━━━━━━━━━━━━
俺は待ってる。
宇宙人じゃない、
地球上の、
一人のプログラマーとして。
(このテキストは Claude Sonnet4.5により、些細な人力修正を経て作成されました。不可能？可能です。問題解決のためのAI. SubscribeNow →claude.ai)
Youtubeのオススメで、windows11をアプデしたら127.0.0.1が繋がらなくて開発者が阿鼻叫喚みたいなのが流れてきた
繋がらないなら繋がらないで他に代替策とか普通にあるし、実際の開発者ならいつものことかと思いながら淡々と回避策を使うだけだろうけど
あと、テストせずリリースするなとかアプデのたびに壊すのやめろとかテンプレコメントがあったけど、開発者なら逆なんだよな
MSほどの会社がこういう感じだからこそソフトウェアはバグがあって当たり前だと一般人でもわかってくれるわけ
あれだけIISと書かれていても思い込みでこういう風にとるやつ多いよなあ
Visual Studioのバグになぜか憤ってたやつらが多かったり騒いでるやつってたいていこのパターンｗ
最新の更新もまたバグあったらしくてlocalhostに接続できないみたいだけど他にもマウス使えなくなるみたいなのもあってwindows11って原因が分かってるMeやスペックが追いつかなかったVista(わりと好き)とか意識高い系の勘違いしてしまった8(8.1は軽くて好き)とかと違ってただのダメOSじゃんね…😂😹ね—はづき🔞サンクリ (@hazuki_futahi)October 20, 2025
