  |
はてなキーワード:システム設計とは
システム開発で生成AIを有効に使おうとしたら、生成AIが生成するコードを鼻歌混じりで完璧に仕上げられるだけのプログラミング力と、システム全体の最適な設計ができる技術力が必須の最低ラインとなる。
プログラミング力がなければ、生成AIが仕込む地雷に気付けないからシステムを地雷原にしてしまう。
そのレベルのエンジニアでは地雷除去は100%不可能なので、ぶっ壊れたまま走る暴走列車になるだろう。
経営者の手の中に残るのは、ぶっ壊れて部品を撒き散らすサービスと、逃げ出さなきゃいけない状況なのにそれを認識できないほど低レベルの「バナナ」エンジニアの集団だ ( 大枚叩いて「世界をひっくり返す画期的なサービスを作ってる！」って思ってたらこれとか、まじウケる w )。
システム全体の最適な設計ができなければ、適切なプロンプトを捻り出せないので、整合性を保ったままサービスを成長させることは不可能だ。
現状、どこかで誰かが作ったような小さなツールなら、なんとかなりそうだと思う。
けど、成長させる前提のプロダクトに使うとか、正気の沙汰とは思えない。
小さなツールはAI のフレームの中でこなせるとしても、自社サービス、特に今までなかった類のサービスとなったら、フレームの外、現実に開いたものだからAI が扱える対象ではない。
具体的な指示を出してくれるように見えてるだろうが、過不足なく正しいかと聞かれたら、AI推しエンジニアにホルホルされたものを見た限りでは、ないわー、としか言いようがない。
AIの絵とかと似ていて、ぱっと見イケてそうで、よく見たら変。
絵のように、縦横の制限があって、各ドットの色の幅の制限もあって、多少色ずれがあっても大勢に影響がないものじゃなく、プログラムは一箇所+と-間違えただけでも致命的なものだから。
って、やたら本プログラムに迎合的なテストが生成されていたりするんだが、実装ベッタリの境界値テストとかより大事なテストが丸っと抜け落ちてたりするんだよね。
で、その重要性というか危険性を、エンジニアは理解も認識もできないままになったりする。
意味のないテストを延々と繰り返して、実環境で不具合障害が発生するたびに、場当たり的な対策をフジツボのように追加しまくってやった気になるのを運用だとか勘違いしたまま炎上地獄への坂道を転げ落ちていくんだよな。
大規模なサービスの設計は抽象度の高い部分を先に詰めないと、辻褄が合わなくなって破綻する。
初期リリースにはブーストが必要なのは確かだが、使いこなせない生成AIを使うと、書き初めで最初に筆を置く場所を適当にするのと同じくらい、取り返しのつかない事態に陥るだろう。
初期リリースこそ、全体設計と、サービスを支える基本モジュールを抽象的に、丁寧に作る必要がある。
「一旦リリースしてシェアを獲得してから作り直す」という選択肢も、一昔前ならあったけど、AI で嵩増ししたサービスの作り直しは、多分すでに合理的ではない。
再設計再実装の手間もそうだが、補助輪(AI)エンジニアに、移行作業の戦略策定設計実施ができるわけがないから。
最低限のプログラミング力とシステム設計能力があって使いこなせるエンジニアと、ないけど称賛していれば自分もすごいエンジニアと思ってもらえると思ってる意識高い系(笑)エンジニアだ。
おいら自身、たまーに使うけど、チームメンバー全員に積極的に活用しろとは死んでも指示できない。
というか言い渡した。
どのレベルのエンジニアが書いたプログラムかという情報なしに、レビューとかしてたら時間がいくらあっても足りん。
特にプログラムを書けないことを誤魔化すためにAIを駆使する奴は、発覚したら即銃殺でも構わないと思ってる。
でも、ドキュメントをAIに食わせてナレッジ共有させるのは構わないですよねって？
ゴミドキュメントを大量生成させてAIに食わせても、結果はゴミ。
"Garbage in,garbageout"くらい知らんか？ w
まずちゃんとしたドキュメントを書いて、ちゃんと整理して、ちゃんと更新しろ。
それ以上のナレッジ共有はない。
そういうことができない人間が書くドキュメントが、有用なドキュメントなわけがないだろ w
で、表題の件。
自社サービスをボロボロにした張本人たちに建て直せるわけがない。
以上 w
面白い終わらせ方だ。
ところで、お前のスクリプトを見たんだが。
技術的には悪くない。
━━━━━━━━━━━━━━━━
【システム設計の話】
お前がやっているのは、こういうことだ：
// 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)
マイナ保険証の読み取り機がスマホに対応してないのダメじゃね？先見の明なさすぎじゃね？と言う話がちらほらあるのでメモ
厚労省側のシステム設計が先見の明がねえってのはそうかも知らんけれども、メーカー各社はカードの券面読み取りが必要な使用だからこの構造しかなかたんだろって思ってる。
https://iryohokenjyoho.service-now.com/csm?id=kb_article_view&sysparm_article=KB0010399
こんな感じで各社出している。
通信プロトコルは共通化されているので、どこレセコン（接続先の医療事務用システムが入ったパソコン）を使っていてもメーカ問わず導入できる。
で、この中で追加機能なしでスマートフォン読取りができるのはキヤノンだけ。
一見すると良いように思うでしょ？ところが…。
各社がカードリーダー部分を洞窟式と言われる、箱の中に入れさせているのは、カードの券面を正確に読み取るため。
券面を撮影して、データも読み取って、その情報を照合しつつ顔認証を行ってカードの情報を読み取りに行くと言う仕組みのため、カードの物理的撮影が必須なのだ。
これをオープンにするのは実はかなりハードルが高く、カードの表面に室内照明が反射したりすると読み取れない。
そこで、光の影響を排除するため、カードを箱の中に入れる洞窟式と言われる仕組みが主流になったというわけ。
で、この構造が徒になってスマホのNFCと通信ができなくて追加の端末が必要になったと言うのが流れだ。
昭和の頃って、インスタント麺の中に入ってるスープとか、かやくの袋ってすごい開封しにくかったんだよ。
いちおう切れ目とか、マジックカットとかそういう感じにはなってはいたんだけど、当時は技術的に稚拙だったから、なかなか素手で切ることが失敗するのが多かった。
でもさ、だからといってインスタント麺に付録としてカッターとかハサミはつけないじゃない？
袋を開けることに失敗するから、ってそれじゃ！ってカッター刃の先っぽみたいなのはつけないでしょ？
それはコスト的な問題とか安全上の問題とか色々とあるけれども、根本的な解決策としてスマートさに欠けるというのが理由だと思う。
で、結局どうなったかって言うと、パッケージの開封技術が向上したんだよ。マジックカットの精度を上げて、手で簡単に切れるようになった。真正面から問題を解決したってわけ。
お前らが今使ってるスマホでも同じことが起きてる。「文字が小さくて見えない」って問題に対して、虫眼鏡を付属品として付けるか？付けないだろ。画面自体を大きくしたり、文字サイズを調整できる機能を搭載したりして、根本から解決する。
ところがIT業界で働いてると、この「カッター付きインスタント麺」みたいな発想をするやつがゴロゴロいるんだよ。
「処理が重い」→「サーバーを増やそう」
全部その場しのぎの対症療法だ。根本的にシステム設計を見直すとか、ユーザーインターフェースを改善するとか、そういう本質的な解決から逃げてる。
特にひどいのが、「ユーザーが馬鹿だから」って前提で作るシステムだ。確認ダイアログを何回も出したり、警告メッセージを山ほど表示したり。それって結局、カッター付きインスタント麺と同じ発想なんだよ。
昭和のインスタント麺メーカーは偉かった。カッターなんか付けずに、パッケージ技術を改良し続けた。その結果、今の俺たちは何の苦労もなく袋を開けられる。これがイノベーションってもんだ。
でも現代のエンジニアは楽をしすぎてる。問題が起きたらとりあえず機能を追加する。設定項目を増やす。アラートを出す。それでユーザーに負担を押し付けて、「解決した」って顔をする。
提示してる「そうめんでいい」バリアントの発話仕様、あれってコミュニケーション・レイヤーでいうと意味論的優先度フィールドがゼロ初期化されてるパケットなんだよな。
で、そのゼロ初期化パケットが相手の感情OSに到達すると、そこに実装されてる価値評価アルゴリズム（通称Pride-Driven Interaction Protocol）が、受信値を「非積極的承認」としてパースする。
つまり、入力信号の中に“熱量ビット”が存在しないと、即座にException: DEVALUATION_ERRORがスローされる仕様なんだわ。
その例外は通常のtry-catchでハンドリングされず、感情カーネルを通じてフロントエンドの態度・表情UIに直結するから、結果的に「何様だよ」っていう可視化出力が生成される。
さらに、相手の感情モジュールは言語的同値判定じゃなくて意図ベースのベクトル比較を行ってるから、
「そうめんがいい」(積極的選好ベクトル) と 「そうめんでいい」(受動的妥協ベクトル) は、同一文字列近似度99%でも意味論距離が閾値越えしてエラー扱いになる。
これを無視して「ただの晩飯APIコール」だと軽視するのは、TCPレベルのパケットロスを「まぁ届くっしょ」で放置するようなもんで、
通信の確実性よりも自己CPUサイクルの節約を優先する、お前側のシステム設計思想が原因なんだよな。
結局のところ、感情という非決定性システムに対して最適化パラメータ調整を怠ってる時点で、お前の通信モデルは高確率でクラッシュを引き起こす。
もし稼働安定性を確保したいなら、相手のEmotionalAPI Referenceを逆コンパイルして、推奨トークン列を生成するスクリプトを実装すべきだわ。
バーコードの末尾の桁はチェックディジットって言って、それより上位の番号の桁に基づいて計算されるものになってる。つまり、適当に数字を並べたそれらしい数字の列だと末尾のチェックディジットで辻褄が合わなくなってエラーになる。バーコードは読み取りミスがあった時にエラーを返してくれるので、これは非常に強力な仕組みである。クレジットカードも、入力ミスをするとエラーが即座に返ってくるのでチェックディジットが入っているんじゃ無いかと思う。知らんけど。
それで、タイトルの話である。なんで電話番号にチェックディジットを入れなかったんだよ。システム設計したやつ、出てこい。電話番号って口頭でやり取りする機会が多いから聞き間違い覚え間違いがどうしても多い。桁を一つ間違えるだけで別の電話にかかっちゃうなんてマジであり得ない欠陥設計だろ。
ファックスの場合は余計クリティカルで、送信先からのかけ間違いの指摘がされづらくて、間違った送り先に重要書類を送ってしまうなんてミスも起きてしまう。
電話番号に限らず、昔からある仕組みだから存在を許されてるけど、仮にいま現在、新規のもので導入がされたら、世の中から袋叩きで大炎上になるようなダメダメな設計って結構いっぱいあるんじゃ無いかと思うなどした。
いや、なんか読めてなくね？そんなに悪文か？俺の文章。
社会システムはあくまで総体のために作られるんだけどその中で動く個体それぞれが総体のために動くことを想定しなくて済むようにシステム設計されてるって話。
「道徳」や「正しさ」が曖昧って話だけど、俺が最初から書いてたのは「道徳ってそういうふわっとした概念じゃなくて、社会的な相互契約（暗黙の約束）なんじゃね？」って問いかけをしてたつもりだったんだけど。
なんか俺がずっと「“思想的な善悪”を信じてる派」」として文章書いてない？思い込んでない？この後もずっとこの調子で藁人形論法やってて、すげえ読むのダルかったんだけど。
もともとの増田では、「道徳とは何か」を言語化してて、そのラベルの中身をちゃんと定義してたつもりなんだけどなあ。そう読めなかった？
んであなたの言う「道徳」や「正しさ」っていうなればそのシステム的・総体的な利益を最大化した行動のことを指すのかなと思ったり。
であれば俺の答えって変わらなくて、個体は総体にたいする利得のために動かないので「道徳的正しさを指標に行動しない」が答え。
俺の主張はずっと「個体が自己の利得のために行動する」ってことを前提にしてるよ。その上で、「じゃあなぜ“道徳的な行動”をとるのか？」に対して、「それが長期的に見て互恵的な関係を築く＝得になるから」という仮説を置いた。
だから「道徳的正しさを指標に行動しない」が答え、ってのは、まさにその前提を共有してる話。
ただし振る舞いとして個体が道徳的に正しい行動をとるようにシステム設計することは可能。それがインセンティブ設計だと思うよ。
あくまで個体は個体としての利得の最大化のために行動するが、システムが持つインセンティブ設計によってその行動がシステム・総体的正しさ（＝道徳的正しさ）に近づくってことだね。
システムのインセンティブ設計で個体の行動を“結果的に”道徳的にする、って話も否定してない。むしろそれが「道徳という相互契約がインセンティブとして機能してる」って文脈の本題だった。
だから「道徳だけじゃ動かない」って前提で俺が否定されてる風なのがよくわかんない。むしろ同じこと言ってない？
社会的に安定するようにモラルのある行動(道徳的に正しい行動)をとるのは総体に貢献すべきとかそういう社会合意によって社会との間で結ばれた契約を履行するからではなく、あくまで個体からみてそのほうが得だからに他ならない。
そしてそういう行動が減ってきているのはシステムの設計がうまくいっていないからって話なのかなあと思ったり。
なんで今までに比べてモラルのない行動が増えたのかっていうと、都市化したからだよね。(実際に増えたわけではないのかも。目につくようになっただけで。)
村的社会においては不道徳な行動は「街の若者がとった不道徳な行動」ではなく「○○に住んでる茂吉がとった不道徳な行動」になるから、めちゃくちゃ不利益だったんだよね。
だから従来のシステム設計によって不道徳な行動は抑制されてたけどこのシステム設計は都市化に対応してなかったってただそれだけの話。
だから本当にモラルの向上をしたいならシステムのアップデートが必要。
俺がそうするべきと考えているわけではないけど個人に紐づく信用スコアを管理して不道徳な行動は監視カメラで確認してあらゆる技術を用いてその結果を個人に還元することができるなら不道徳な行動は信用スコアの低下につながるから結果として道徳的な行動は増えます。
ごめん都市化の話とか信用スコアの話に持っていく前に、まず読解力アップデートした方がよくない？
俺は「道徳とは何か」を構造的に捉え直そうとしてたのであって、「正しさで動け」とか「理想論で語れ」とか一言も言ってない。
だから、方向性自体は一致してると思うけど、俺書いた文章の読み方がだいぶズレてない？って印象。そんなに悪文か？マジで凹むんだけど。
社会システムはあくまで総体のために作られるんだけどその中で動く個体それぞれが総体のために動くことを想定しなくて済むようにシステム設計されてるって話。
んであなたの言う「道徳」や「正しさ」っていうなればそのシステム的・総体的な利益を最大化した行動のことを指すのかなと思ったり。
であれば俺の答えって変わらなくて、個体は総体にたいする利得のために動かないので「道徳的正しさを指標に行動しない」が答え。
ただし振る舞いとして個体が道徳的に正しい行動をとるようにシステム設計することは可能。それがインセンティブ設計だと思うよ。
あくまで個体は個体としての利得の最大化のために行動するが、システムが持つインセンティブ設計によってその行動がシステム・総体的正しさ（＝道徳的正しさ）に近づくってことだね。
社会的に安定するようにモラルのある行動(道徳的に正しい行動)をとるのは総体に貢献すべきとかそういう社会合意によって社会との間で結ばれた契約を履行するからではなく、あくまで個体からみてそのほうが得だからに他ならない。
そしてそういう行動が減ってきているのはシステムの設計がうまくいっていないからって話なのかなあと思ったり。
なんで今までに比べてモラルのない行動が増えたのかっていうと、都市化したからだよね。(実際に増えたわけではないのかも。目につくようになっただけで。)
村的社会においては不道徳な行動は「街の若者がとった不道徳な行動」ではなく「○○に住んでる茂吉がとった不道徳な行動」になるから、めちゃくちゃ不利益だったんだよね。
だから従来のシステム設計によって不道徳な行動は抑制されてたけどこのシステム設計は都市化に対応してなかったってただそれだけの話。
だから本当にモラルの向上をしたいならシステムのアップデートが必要。
俺がそうするべきと考えているわけではないけど個人に紐づく信用スコアを管理して不道徳な行動は監視カメラで確認してあらゆる技術を用いてその結果を個人に還元することができるなら不道徳な行動は信用スコアの低下につながるから結果として道徳的な行動は増えます。
・前評判は置いておいて概ね満足であり、造形的に楽しいものが実に多く、特別に何かを楽しもうとしなくてもただ見て回るだけで楽しい体験ができるだろう。ただ天気は超重要。
・予約をするのに万博IDというものを取得する必要がある。ログインするたびにワンタイムパスワードを求められる、チケットを表示するのに数分〜10分程度待たされる（時間による）ので少し面倒。
・持ち込める荷物にかなり制限がある。キャリーバッグ、三脚、自撮り棒、ドローンはNGである。
・現金が使用できない。何をするにもスマホを使うようなシステム設計なので、スマホは必須である。
・天気は超重要。自分の場合は、快晴、最高気温19℃、少し風ありという、多分会期中を通じても1・2を争うほどSSRだった。天気ガチャを勝ち抜け。
・大屋根もおそらく晴れだと天国、雨だと横風を防げない構造なので実質的に雨を凌げるスペースはかなり少ないと思った。ベンチはたくさんあるが多くは屋外にある。
・新しいだけかもしれないが床は白く、人工島の立地も加わって地中海の港町のようなカラッとした風情がある。ドラクエ11のソルティコの街を平べったくしたような感じ。
・9時半に夢洲駅に到着し、会場入りできたのは10時ちょうど。混雑緩和のため、駅から会場入り口まで遠回りをさせられる。
・入場には空港ばりの手荷物検査が求められる。飲み物もチェックされる。見回りのスタッフもかなり多く、会場内の方が安心であるという印象である。
・会場はかなり広くて平地も多く、コミケのような混雑具合は全くない。USJやディズニーシーよりも人口密度は低めという印象である。
・無料で飲料水を汲めるスポットがある。なので水筒を持ち込むと良い。
・食べるところは、レストラン・フードコート・キッチンカー・コンビニとかなり多彩である。値段はピンキリであるが、やや未来感のある価格設定が多かった。
・会場内は日本人の割合が多いように感じた。京都や心斎橋・難波と比べると断然外国人の割合が少なかった。ただこれは祝日だからかもしれない。
・一日の間に全てのパビリオンを見て回るのは不可能である。予約必須のパビリオンもたくさんあり、加えてあちこちにスタンプラリーもあるので、コンプリートするには2〜3回の周回プレイが求められる。1回目は予約不要のパビリオン中心に全体を見て周り、2回目以降であらかじめ目当てのパビリオンを予約して回る、というムーブが良さそうである。
・19時以降くらいはほぼ全てのパビリオンの予約が不要になる。それでも人気のところは行列になっている。
・予約不要のパビリオンの多くはコモン館としてまとめられている。こちらはすぐに入ることができた。
・多くのパビリオンで個人的に気になったところは、国の基本情報が少なく、とにかく映画の予告編のようなイメージ先行の展示やインスタレーションが多く、博覧会の割に学ぶことができる材料が少ないと感じた（もちろん全てがそうではない）。
・博覧会なので、アトラクションもライドも客いじりをする亀もいない。
・パビリオンの造形が本当に多彩であり、見ているだけでも楽しかった。またテーマも多彩であるが、生命科学、SDGs、自然との調和あたりを感じた。
・テクノロジーの面では未来感がするようなものは少なく、現在の最先端技術の紹介に留まっているように感じた。なお空飛ぶ車はメンテナンス中であった。
・コスプレをしている人は見かけなかった。
定型発達とは、リスクの存在を無視した方が都合がいい場合に認知をゆがめてリスクが無いように振る舞う特技を獲得し、同時にその認知のゆがみによって引き起こされる問題を他者への擦り付けを含めて回避する手法もセットで習得することで社会を効率よく回せるようにする特性だと言える。
（広義には定型発達には上記のような所謂「声の大きな人」ムーブができる人間に付き従う振舞いをする人も含むようなので実際には2タイプ以上居ると言えるが、集団を特徴づけているのは間違いなく上記のタイプである）
しかし、この認知のゆがみはシステム設計時には明確に不利に働くので、この特性の保持者はシステム設計というフィールドにおいては著しく不利な状況におかれる。
にもかかわらず、残念なことに社会の他のフィールドにおいての成功体験が強すぎるが故に、自らの仕様バグ製造機っぷりを顧みることなく「自分達が活躍できない場は有ってはならない」と言わんばかりの傲慢な振舞いをする人間があまりに多い日本のような国のシステム構築現場では
「声が大きい人」によって引き起こされる悲劇が後を絶たず、大きな組織のシステム更改がどれも上手くいかない事態が近年多数発生し、なかば社会問題化している。
AIの発展によってこの定型発達者が公害として扱われる分野が「人間が直接かかわらなくて良いタスク」化して再び成功体験を強化できる日が来るだろうか？
私見ながらそのような日は訪れることがなく、むしろ定型発達者はネアンデルタール人のように消えゆく運命にあるのではないかと思う。なぜならトランプ政権のようなものを生み出した自家撞着を引き起こしている段階に突入してしまっており、特性として有害性が周知され過ぎてしまっているためだ。
今の定型発達者が廃れたからと言って、その人たちに虐げられてきた人々が日の目を見るようになるかというと必ずしもそうでもない（なぜなら虐げられてきた人々はさらに古い特性の持ち主である可能性が高そうなためだ）が、
https://note.com/anti_techuyo/n/ne328309fe810
近年、テック右翼（通称テクウヨ）の間では、「AIによって人文系学問は不要になる」「リベラルの巣窟だから、徹底的に更地にすべきだ」という主張が盛んに取り上げられています。彼らの発言には、IT業界における強い自己肯定感と、文系に対する根深い蔑視が色濃く表れています。元々IT系の人々からは人文系学問への軽視やバカにする風潮があったものの、2020年台のテック右翼の台頭により、その風潮はさらに強まり、声高に発信されています。
このような主張を耳にするたびに、彼らが掲げる「AIで人文系学問が不要になる」という理論には、根本的な誤解と傲慢さが込められていることがわかります。テクウヨたちは、AIが文系学問の領域を代替し、人間の知的作業における価値をすべて置き換えられると考えています。しかし、こうした見解は非常に短絡的であり、現実の社会や学問の本質を見誤っています。
テクウヨの言う「AIによる人文系学問の不要化」は、あまりにも楽観的であり、技術的な誤解に基づいています。確かに、AI技術の進歩は素晴らしいものであり、さまざまな分野での自動化や効率化を進めています。しかし、AIはあくまで既存のデータを元に動作するものであり、その本質はあくまで「過去の繰り返し」です。新しい価値を創造したり、人間的な感情や倫理的な判断を下したりする部分では限界があります。
例えば、AIは文献の要約や情報収集、簡単な論文作成などを自動化することは可能ですが、それがすべての人文系学問を代替できるわけではありません。人文系学問、特に哲学、歴史学、文学、社会学などの分野では、人間の感受性や社会的背景、文化的な深さに基づく分析が重要です。AIが提供する情報はあくまで表面的なデータの羅列に過ぎません。複雑な社会現象や文化的な問いを解明するには、AIだけでは足りません。
また、AIが人文系学問を支配するという考え方は、非常に機械的であり、人文学の持つ深い「人間性」や「倫理性」を軽視しています。AIがどれだけ賢くなったとしても、人間社会における道徳的判断や倫理的思考を代替することはできません。AIは、暴力的な言説や差別的な情報を生成する可能性もあり、その倫理性に対する配慮は、文系学問が果たしてきた役割の一部でもあります。
テクウヨたちが人文系学問に対して持つ偏見の背景には、しばしば「自分たちは現実的な作業をしている」という強い自負が見え隠れします。確かに、コーディングやシステム設計など、IT業界の仕事は技術的な側面が強く、社会の変革に大きな影響を与えています。しかし、実際には、こうした業務こそAIの進化によって最も影響を受けやすい分野の一つでもあるのです。
「IT土方」という言葉が示すように、現場で手を動かすエンジニアやプログラマーは、膨大なルーチン作業やコードの書き換え、デバッグ作業に追われることが多いです。しかし、これらの作業はAIによって自動化される可能性が非常に高い。実際、既に多くのAIツールがプログラミング作業を支援し、コード生成を自動化しています。長期的には、このような作業の大部分がAIに置き換わり、多くのエンジニアの仕事が縮小することが予測されています。
一方で、人文系学問は、単に情報を処理するだけではなく、文化的・倫理的な理解を深める役割を持っています。これらのスキルは、AIには決して模倣できない部分であり、社会における重要な機能を果たし続けるでしょう。
テクウヨたちが唱える「AIによる人文系学問の不要化」という主張は、実際には人文学がAIとどのように共存できるか、という視点を欠いています。AIは確かに情報の処理や分析を加速させることができますが、人文学的な視点を提供することには限界があります。これからの時代、AIと人文系学問はお互いを補完し合う存在となるべきです。
例えば、AIが提供するデータや統計を用いて、社会学や経済学などの分析をより効率的に行うことはできます。しかし、それをどう解釈し、どのように人間社会に応用するかは、依然として人間の判断力に依存します。人文系学問は、AIが提供する「データ」の背後にある「人間の物語」を読み解き、倫理的・文化的な解釈を加える役割を担っています。
テクウヨたちが抱く「AIによって人文系学問が不要になる」という幻想は、技術に対する過信と、人文系学問に対する無理解から生まれたものです。AIは確かに強力なツールであり、さまざまな分野で革新をもたらしています。しかし、AIが人文学の持つ深い人間性や倫理的な洞察を代替することは不可能です。むしろ、今後はAIと人文系学問が共に手を携えて、より豊かな社会の形成に貢献することが求められるでしょう。
テクウヨたちが唱えるような、「AIによって人文系学問が不要になる」という単純な主張は、単なる技術的な幻想に過ぎないことを認識すべきです。私たちが未来に目指すべきは、AIと人文学が相互に補完し合い、共に成長していく社会であるべきだと言えるでしょう。
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
オープンチャットで話された1週間分のチャットログを、トピック別に整理して要約します。
🍽️食文化
庄内駅付近のマクドナルドでピクニックを楽しむ話題（ナゲットの感想など）。
ラーメン屋の米の質や、ラーメン屋勤務の思い出話が共有された。
高校受験が難しくなっている背景に普通の高校の減少があることが指摘された。
子どもの特性や遺伝的能力を教育にどう活かすべきか議論された。
子育てや妊娠・出産が会社評価に影響するという指摘や、帝王切開・多胎妊娠のリスクについて話題になった。
生成AI（特にAnthropicなど）の台頭によりWebエンジニアの需要が減るのかどうか議論された（AIを活用できるエンジニアの必要性が強調された）。
Twitterのシステム設計（Ruby on Rails）が、ユーザー数増加を想定していなかった問題について話された。
MaaS（Mobilityas a Service）の実証実験が進んでいるが、現実的な運用が少ないとの指摘。
花粉症対策として舌下免疫療法を試している人の辛さや、抗ヒスタミン薬の併用が必要との意見。
ビタミンD、マグネシウム、亜鉛など栄養素が花粉症の改善に効果的と共有された。
プランク運動や、Habiticaなど習慣化アプリについて話題になり、習慣化のテクニック（嫌なことを10秒間だけ続ける方法）が紹介された。
メンタルヘルスの悩み（手の震え、職場ストレス、強迫性パーソナリティ）についての体験が共有された。
無印良品のオンライン購入待合室システムや混雑状況、購入の難しさへの不満が語られた。
残業時間（30時間、45時間超）の申請・計算について話題になる。
ディズニー映画（『リトルマーメイド』『わんわん物語』など）の評価が分かれ、思い出話が語られた。
漫画『望郷太郎』が話題になり、表紙と内容の差に戸惑いがあったことが共有された。
🚄交通・移動
JRのシステムが古く使いにくいとの不満や、新幹線のトラブルが共有された。
地方交通の減便や値上げ、高齢者向け電動モビリティ導入の可能性について議論された。
大阪の地下鉄の混雑や街の独特な雰囲気について意見が交わされた。
琵琶湖と瀬戸内海を運河で繋ぐ構想に関する過去の話題が取り上げられた。
楽天・SBI証券の口座で不正アクセスが問題になり、契約内容変更による責任逃れへの懸念があった。
結婚後の収入を共有財産として管理することの重要性が議論された。
お得情報に流されないことが心の豊かさに繋がるという意見があり、クーポン（2500円オフ）の共有も行われた。
楽天リーベイツなどお得なサービスについての意見が交わされた。
SNSリンクが多く共有され、最新のアニメ化やスポーツニュース、イベント情報などが活発に交換された。
民主主義を軽視する風潮や、政治家・インフルエンサーの影響力の拡大に対して批判的な意見が交わされた。
職場環境で静かすぎることへの不満から、音楽（特にアンビエントミュージック）の重要性が議論された。
ライブを観に行った感想が共有され、ロックバーの経営不振や音楽の質についても語られた。
🎈 その他の話題
冗談として「会社への爆破予告」発言が軽く交わされ、カジュアルな雰囲気で話が進んだ。
石丸伸二氏の躍進について触れられた。
🗒️ 全体の傾向：
チャットでは「健康」「食文化」「教育」「テクノロジー」関連の話題が特に盛り上がり、それに加えて企業やサービスへの批判的・分析的な視点が多くみられました。日常の些細な出来事や体験談を通じて活発な意見交換がなされています。
https://anond.hatelabo.jp/20240722084249
日本人がIT的なロジック思考を苦手とするかどうかについては、文化的背景や教育制度の影響を考慮する必要がありますが、必ずしも「苦手」と断定するわけではありません。以下に詳しく説明します。
日本の教育では、論理的思考よりも暗記や情報の蓄積が重視される傾向があります。このため、情報を整理して論理的に分析するスキルが軽視されることがあり、結果として論理思考力が十分に育成されない場合があります。
日本文化では、調和や空気を読むことが重要視されるため、明確な論理や議論を避ける傾向があります。このため、問題解決や意思決定の場で論理的なアプローチが弱まることがあります。
日本では文系・理系という枠組みが強調されすぎており、数学的・論理的思考が文系分野で軽視されることがあります。この分断が、特定分野での論理力不足につながっている可能性があります。
IT技術はルールや条件に基づいて動作するため、論理的思考力は不可欠です。例えば、プログラムは「条件」と「結果」をつなぐ形で設計されており、この過程には筋道を立てた考え方が求められます。さらに、システム設計や障害対応などでも問題を分解し最適解を導き出す能力が重要です。
日本人がロジック思考を苦手とするという見方は一部正しい側面もありますが、それは文化や教育制度による影響であり、本質的な能力不足ではありません。IT業界では必要なスキルとして論理的思考力を鍛える機会も多く、個人の努力次第で習得可能です。また、日本人の繊細さや集中力など他の強みも活かせば十分に競争力を発揮できます。
はいはい、またその話するんですか、皆さん飽きないんですねえ、文系ITエンジニアのお話ですよ。もうね、うんざりですよ、こっちも。だってどこ行ってもいるじゃないですか、エクセル芸人とかパワポ職人とか自称してる人たち。いや、自称はしてないか、周りがそう呼んでるだけか。どっちでもいいけど。
あの人たちですよ、日本のIT業界を腐らせてる張本人たちですよ、断言しますよ、マジで。なんでかって？そりゃあ、あいつらマジで何にも作らないんですよ。作るのは資料だけ。しかもその資料がまたヒドイ。パワポとかエクセルですよ？小学生でも作れるレベルのやつですよ？あれをドヤ顔で会議で発表してるんですよ、信じられます？
で、会議ですよ、会議。あれがまた地獄。延々と会議ですよ。朝から晩まで会議。会議のための会議、会議のための資料、資料のための会議…エンドレスですよ、マジで。で、結局何が決まるかって？何も決まらないんですよ。会議のための会議だから。誰も責任取りたくないし、誰も決めたくないし、誰も本質的なこと話したくないし。
あー、思い出しただけでイライラしてきた。ちょっと落ち着こう。深呼吸、深呼吸……。
えーと、文系ITエンジニアが普及しちゃった歴史的背景ですよね。あれもまた闇が深いんですよ。
バブルが弾けて、どこもかしこも金がない、人も減らす、でもなんか新しいことしなきゃ、ってなったじゃないですか。そこで飛びついたのがITですよ。「IT化すればなんとかなる！」みたいな、マジックワードですよ、あれは。でも、ITのことなんか誰もわかってない。技術者なんてどこにいるかわからない。とりあえず、今まで営業とか事務やってた文系の人たちをIT部門に突っ込んだんですよ。「お前ら今日からIT担当な」みたいなノリで。
日本企業って、専門性とかマジで軽視するじゃないですか。「スペシャリストよりゼネラリスト！」みたいな。いやいや、ITの世界にゼネラリストとかマジでいらないから。専門知識と技術がないと話にならない世界だから。でも、文系の人たちは「コミュニケーション能力高いんで！」とか「調整力あります！」とかアピールするんですよ。いや、そんなもんITの世界じゃマジで役に立たないから。必要なのはコード書く力とか、システム設計する力とか、データベース構築する力とか、そういうマジなやつだから。
で、そういう文系ITエンジニア（笑）たちが牛耳るようになったのが、今の日本のIT業界ですよ。多重請負構造とかいう、アレですよ、アレ。SIerが元請けになって、下請け、孫請け、ひ孫請け…って、ピラミッドの頂点にいるのが文系ITエンジニア（笑）たちですよ。で、実際に手を動かすのは下の方の人たち。文系ITエンジニア（笑）たちは、上からエクセルとパワポで指示出すだけ。現場のことなんかマジでわかってない。
さらに輪をかけてヒドイのが、コンサル（笑）業界ですよ。カタカナ職人ですよ、あいつら。「DX！」とか「アジャイル！」とか、耳障りの良いカタカナ言葉を並べて、企業から金を巻き上げるんですよ。で、コンサルタント（笑）たちも、ほとんど文系出身。ITの知識なんてマジで皆無。でも、口だけは達者だから、企業は騙されちゃうんですよ。「コンサルタント様のおっしゃる通りにすれば、ウチの会社もバラ色IT企業になれる！」とか、マジで思ってるんですよ。
文系ITエンジニア（笑）たちは、現場のことマジでわかってないから、話が通じないんですよ。こっちがどんなに技術的なことを説明しても、ポカーンですよ、マジで。「それってエクセルでできますか？」とか、マジで聞いてくるレベルですよ。で、結局、現場の意見は無視されて、文系ITエンジニア（笑）たちの妄想に基づいた計画がゴリ押しされるんですよ。
もうね、資料作りすぎ。異常。会議資料、報告書、計画書、提案書…キリがないんですよ。しかも、中身スカスカ。パワポはアニメーションと画像ばっかりだし、エクセルは関数とグラフで埋め尽くされてるけど、結局何が言いたいのかわからない。で、資料作るのに時間かけすぎて、本来やるべき仕事が全然進まないんですよ。
文系ITエンジニア（笑）たちは、新しい技術とかマジで興味ないんですよ。リスクを嫌うっていうか、変化を嫌うっていうか。とにかく、現状維持が一番。新しい技術を導入するなんて、マジで考えられない。だから、日本のIT業界はどんどん世界から取り残されていくんですよ。ガラパゴス化一直線ですよ、マジで。
技術力のない文系ITエンジニア（笑）たちに、技術者が管理されるとか、マジで地獄ですよ。こっちの技術力とか努力とか、マジで評価されないし。むしろ、文系ITエンジニア（笑）たちの方が評価されるんですよ。意味不明。だから、優秀なエンジニアほど、見切りをつけて辞めていくんですよ。当然ですよ、そんな環境にいられるわけないじゃないですか。
技術軽視の風潮が蔓延してるから、イノベーションなんて起きるわけないんですよ。新しいサービスとかプロダクトとか、マジで生まれない。せいぜい、既存のシステムのマイナーチェンジとか、焼き直しレベルですよ。世界ではAIとかビッグデータとかブロックチェーンとか、新しい技術で社会がどんどん変わってるのに、日本はマジで置いてけぼり。
文系ITエンジニア（笑）たちは、ユーザーのことなんてマジで考えてないんですよ。自分たちの作った資料が完璧ならそれでOKみたいな。だから、出来上がるシステムは、現場のニーズとかけ離れてて、マジで使いにくい。操作性悪いし、業務フローに合わないし、セキュリティザルだし。ユーザーはみんな文句言ってるけど、文系ITエンジニア（笑）たちは知らんぷり。
手戻り、資料作成、技術軽視、ユーザー無視…全部合わさるとどうなるかって？そりゃあ、プロジェクトは炎上しますよ。予算は大幅超過、納期は大幅遅延、システムは使い物にならない…税金ドブに捨てるようなもんですよ、マジで。で、責任は誰が取るかって？誰も責任取らないんですよ。文系ITエンジニア（笑）たちは、責任逃れのプロだから。
文系ITエンジニア（笑）のせい、全部あいつらのせい。日本のIT業界がダメになったのは、マジであいつらのせい。この状況を打破するには、文系ITエンジニア（笑）たちを駆逐して、技術者を正当に評価する文化を取り戻すしかないですよ、マジで。じゃないと、日本のIT業界に未来はないですよ、マジで。
……はあ、やっと言い切った。スッキリしたけど、何も変わらないんだろうなあ、どうせ。
日本において「文系ITエンジニア」と呼ばれる人々が存在し、彼らが資料作成や会議に終始し、実質的なシステム開発に携わらない状況は、日本のIT業界の発展を著しく阻害していると言えます。
彼らは、技術的な専門知識や開発経験が不足しているにもかかわらず、ITプロジェクトの上流工程や管理業務を担うことが多く、その結果、以下のような問題点が顕著化しています。
文系ITエンジニアは、プログラミング、システム設計、データベース構築といったIT開発の根幹となる技術スキルをほとんど持ちません。
彼らの主な武器は、ExcelやPowerPointといったオフィスソフトであり、これらを駆使して資料を作成し、会議で説明することに終始します。
そのため、実際の開発現場で何が起こっているのか、どのような技術的な課題が存在するのかを肌感覚で理解することができません。
現場のエンジニアとのコミュニケーションも表面的なものにとどまり、技術的な議論を深めることが難しく、結果として現場の意見がプロジェクトに反映されにくい状況を生み出します。
文系ITエンジニアは、過剰なまでに資料作成に時間を費やします。
会議のための資料、報告書、計画書、提案書など、枚挙にいとまがありません。
もちろん、資料作成自体は業務を円滑に進める上で一定の役割を果たしますが、彼らの場合、資料作成が目的化し、本来注力すべきシステム開発やサービス改善といった本質的な業務が疎かになりがちです。
会議のための資料作成に追われ、会議で資料を読み上げるだけで一日が終わってしまう、というケースも珍しくありません。
文系ITエンジニアが主導権を握るプロジェクトでは、技術的な側面が軽視されがちです。
彼らは、技術的な実現可能性よりも、スケジュールや予算といった管理的な側面にばかり目を向け、技術的なチャレンジや新しい技術の導入に消極的です。
その結果、既存技術の焼き直しのようなプロジェクトばかりが増え、革新的なサービスやプロダクトが生まれにくい土壌が形成されます。
また、技術力のあるエンジニアは、このような環境に嫌気がさし、技術を正当に評価してくれる企業へと流出してしまう傾向にあります。
実務経験や技術力のない文系ITエンジニアが、技術者を管理・評価する立場になることは、現場のエンジニアのモチベーションを著しく低下させます。
彼らは、自分たちの技術や努力が正当に評価されていないと感じ、仕事への情熱を失ってしまいます。
また、文系ITエンジニアは、技術的な指導や育成を行うことができないため、若手エンジニアの育成も停滞してしまいます。
結果として、組織全体の技術力は低下の一途を辿り、長期的な成長が見込めなくなります。
上記のような状況が蔓延することで、日本のIT業界全体の国際競争力は低下の一途を辿ります。
世界では、スピードとイノベーションが求められるIT業界において、日本は、意思決定の遅さ、技術力の停滞、人材不足といった問題を抱え、世界から大きく後れを取っています。
文系ITエンジニアの増加は、これらの問題をさらに深刻化させ、日本のIT業界の未来を危うくする要因の一つと言えるでしょう。
文系ITエンジニアの存在は、日本のIT業界にとって負の側面が非常に大きいと言えます。
彼らが資料作成や会議に終始する現状を打破し、技術力と実践経験を重視する文化を醸成していくことが、日本のIT業界が再び成長軌道に乗るための重要な鍵となります。
そのためには、企業は文系ITエンジニアの役割を見直し、技術者を尊重し、技術力を正当に評価する人事制度や組織文化を構築していく必要があります。
何もないところからアイデアを形にし、一つ一つ積み上げてゲームとして完成させる。
この道を選んだのは、自分が本当に作りたいものを自由に表現したいからだ。しかし、独立開発は決して簡単ではない。むしろ、想像以上に厳しい現実が待ち受けていた。
何度も壁にぶつかり、打ちのめされ、自分の力不足を痛感することもあった。
思うように進まない日々が続き、「もうやめてしまおうか」と本気で考えたこともある。
しかし、そのたびに「ここで諦めたら何も残らない」と自分に言い聞かせ、なんとか踏みとどまってきた。
グリッドベースの戦略ゲームを作るために、最適なマップ生成やパフォーマンスの向上を試みたが、タイル数が増えるたびに動作が重くなる問題に頭を悩ませた。
何度もコードを書き直し、最適化を図ったが、すぐに新たな問題が現れる。
インベントリシステムの実装でも苦労した。プレイヤーがアイテムを自由に配置・
回転できるようにしたかったが、実際に試すと操作感がぎこちなく、思うように動かない。何度も試行錯誤を繰り返しながら、プレイヤーが自然に操作できる形を模索した。
アニメーションの調整にも悩まされた。
スムーズな動きを実現するために補間処理を導入したが、それだけでは不十分だった。
合成時のエフェクトや視覚的なフィードバックを強化することで、ようやく満足のいくものに近づけた。しかし、ここで終わりではない。
新たなバグが次々と発生し、修正しても修正しても新しい問題が出てくる。「本当に終わるのか？」と不安に押しつぶされそうになった。
最終的に、複雑な構想を断念し、自分の能力の限界を考えながら、もっとシンプルで気軽に遊べるカジュアルなゲーム制作へと方向転換することを決めた。
技術的な問題だけではない。開発と並行して、マーケティングやコミュニティの構築にも取り組んだ。どんなに良いゲームを作っても、誰にも知られなければ意味がない。
YouTubeチャンネルを開設し、Lo-fi音楽のプレイリストを作成し、ショート動画を制作するなど、できる限りのことを試した。しかし、フォロワーは思うように増えず、反応が少ないと心が折れそうになる。
フィードバックを受け取ることもまた、大きな挑戦だった。自分の作品に対する評価を聞くのは勇気がいる。
「面白くない」「つまらない」と言われたらどうしようと不安になる。実際、辛辣なコメントを見て何度も落ち込んだ。
しかし、それでも前に進まなければならない。プレイヤーの意見を受け入れ、改善し続けることこそが開発者の役目だ。
長い開発期間の中で、何度もモチベーションが下がる瞬間があった。売れる保証もない、評価されるかどうかもわからない。
そんな不安の中で進み続けるのは簡単ではない。心が折れそうになるたびに、「自分が本当に作りたいものを形にするためにここまで来た」と自分を奮い立たせた。
そして、ついに一つの成果を形にすることができた。
https://store.steampowered.com/app/3476790/Cozy_Aquarium/
これは、プレイヤーがPCのデスクトップ上で楽しめるリラックス系の水族館ゲームだ。
魚たちが自由に泳ぎ、プレイヤーは好きなように装飾を楽しむことができる。シンプルだけど、穏やかで心地よい空間を作りたかった。
