  |
はてなキーワード:実装とは
ダイヤモンドの↓の記事が盛りすぎでブクマカが釣られまくっているので、ちょっと落ち着けという意味で少し解説する
普通の人が「フリック入力を発明」というフレーズを見たら、どっちを想像する？
普通は1を想像するよね。でも、上の記事の「発明」は2の意味。8割くらいのブクマカはここを勘違いしてコメントしてるように見える
同じ発明家氏の記事でも3ヶ月前の東洋経済のほうは、「フリック入力を発明」という釣りフレーズこそ使っているものの本文を良く読めば発明のキモの部分が2であり1では特許を取れなかったことがそれなりに分かるように書いてある
「フリック入力」を発明しMicrosoftに売却した彼の"逆転"人生。元・売れないミュージシャン兼フリーター、家賃３万のボロアパートでひらめく
https://b.hatena.ne.jp/entry/s/toyokeizai.net/articles/-/889631
もちろん2の意味の発明もスゴイし重要なんだけど、釣りは良くないよね
そもそも世の中のほとんどの技術は様々な発明やアイデアの集合体である。歴史の積み重ねであり、最終形がいきなり湧いて出るわけではない。もちろん「フリック入力」にも歴史の積み重ねがある。それを少し紐解いてみよう（なお、下記の「年」は引用可能な特許や論文が出た時期であり、実際にはそれよりもっと前にソフトウェアがリリースされていたりアイデアがメーリングリストに投稿されていたりすることもある）
ttps://dl.acm.org/doi/10.1145/57167.57182 (論文)
放射状に選択肢を並べるUIのアイデアは1960年代から見られるが、接地点からの移動方向情報を用いた入力手法の祖としてはとりあえずこれを挙げることができるだろう。これは文字入力に特化したものではなく、一般的なメニュー選択のための手法である
ttps://dl.acm.org/doi/10.1145/191666.191761 (論文)
pie menuを文字入力に応用したもの。論文の著者はAppleの人。英語用。広義の『「フリック入力」の元祖』に最も該当するのは、おそらくこれだろう
ttps://rvm.jp/ptt/arc/227/227.html
ttp://www.pitecan.com/presentations/KtaiSympo2004/page65.html
T-cubeを日本語に応用したもの。広義の『日本語版「フリック入力」の元祖』の候補
https://web.archive.org/web/20080925035238/http://www.j-tokkyo.com/2000/G06F/JP2000-112636.shtml (特許)
https://newtonjapan.com/hanabi/
AppleNewton (PDA)用に実装された文字入力技術。「中央が『あ』、上下左右方向が『いうえお』」に対応する見慣れた形のフリック入力がここで登場する。『現在よく見る形の日本語版「フリック入力」の元祖』である。なお、開発者が特許を申請したものの審査を請求しておらず、特許としては成立していない
この頃、Human-Computer Interaction分野でT-cubeやHanabiの発展としての文字入力手法の研究が活発になり、特に国内学会で多くの手法が発表された。情報系の学生の卒論や修論のテーマとして手頃だったからだろう。PDA製品に実装されて広まった例もあり、SHARPZaurus用のHandSKKや、少し時代が下ってATOKのフラワータッチ等もこの系譜である
なお、この頃までの技術は指での入力ではなくペン（スタイラス）による入力を想定したものが主である（iPhoneの登場以前はキーボードレスのモバイル端末といえばPDAやタブレットPCなどスタイラス入力を前提としたデバイスが主流だった）
『スマートフォン上の「フリック入力」の元祖』であり『予測変換機能を備えた「フリック入力」の元祖』である。日本語フリック入力の効率を考える上で予測変換の占めるウェイトは大きく、「実用的なフリック入力」を実現するには予測変換との組み合わせは外せない。2006年にAppleに招聘されてiPhoneのフリック入力機能を開発した増井俊之氏は元々予測変換のPOBox（1998年 - ttps://dl.acm.org/doi/10.1145/274644.274690 ）の開発者として知られる研究者であり、Appleへの招聘もその経験を買われてのものだろう。入力にフリック操作を用いること自体は特筆すべきものではなく、当時の流行を考えれば自然な選択だったと思われる
なお、前述のHanabiの開発者氏がiPhoneのフリック入力を見て
と言っている一方、増井氏はHanabiに対して
知らんがな
と言っている。この分野の研究をしていて知らんことあるか？とも思うが、電話用テンキーの上に五十音かなのフリック入力を実装すると誰が作っても概ねHanabiのような外観になると思われるので、本当に知らなかったとしても不思議はない
ttps://www.j-platpat.inpit.go.jp/c1801/PU/JP-2008-282380/11/ja (特許)
『画面表示は絶対座標＋移動判定は相対座標で行うことで「フリック入力」の入力効率を向上させる手法の特許』である（詳しい仕組みは上記の東洋経済の記事に書いてある）。ペン先と比べて指先は太いため指によるタッチでは厳密な操作が難しく（fat finger問題）、「実用的なフリック入力」を実現するにはこのような工夫も必須になる。小川氏の凄いところは、スマホの日本語UIをリリースするならどのメーカーも必ず実装するであろうこの工夫を、日本語版iPhoneのリリース直前、Apple社としては引き返せないであろうタイミングで特許申請したところだ。機を見るに敏すぎる。特許庁に2回も拒絶された特許を不服審判で認めさせているところも本人が弁理士だからこそできる強さだと言えるだろう
なお、氏の記事を読むと「フリック入力」自体を氏が考案したように思えてしまうが、ここまでに述べた通りそれは誤りである。「フリック入力に関連する重要な特許の公報に『発明者』として掲載されている」ことは疑いない事実なので「フリック入力の発明者」と称するのはギリギリ誤りではないと言えないこともないが、「フリック入力を発明した」はやはりダメだろう。上述の通りフリック入力自体は90年代に既に登場しており00年代の前半にはタッチスクリーン上のかな入力手法の一角を占めるに至っていたので、iPhoneに実装されたことは不思議でもなんでもなく、
このあたりは荒唐無稽な邪推すぎて、ソフトバンクから名誉棄損で訴えられたら危ないのでは
まとめると、さすがに小川氏の記事はモリモリに盛りすぎである。書籍の宣伝にしても酷すぎる。価値の高い特許を取った発明家であることは事実なのに、なぜこういう胡散臭いムーブをしてしまうのか
1998年にAppleNewton用に開発された日本語入力システム「Hanabi」が草分けで、2008年にiPhoneに採用されたことで、急速に広まった。従来の「あ段→い段→う段→え段→お段」とキーのプッシュを繰り返して表示・入力する方式（トグル入力）に比べ、素早い入力が可能になる。その入力効率の高さから、2010年頃にはキーボード離れが加速している[1]。
1998年にAppleNewton用に開発された日本語入力システム「Hanabi」[2]が草分けで、2008年にiPhoneに採用されたことで、急速に広まった。日本におけるフリック入力は、発明家でシンガーソングライターの小川コータがiPhone上陸以前に考案し2007年から2015年にかけて特許出願した[3]ものであり、取得した権利はマイクロソフトに譲渡された[4]。
ただ、これはおそらく関係者の自作自演等というわけではなく、日本におけるフリック入力関連特許が小川氏のものばかりであることからボランティア編集者が勘違いしてこのような記述にしてしまったのではないか。フリック入力は前述のように地道な技術の差分の積み重ねなので、個々の差分の開発者が「特許」を取ろうという気にならないのは良く分かる。その点でも、自ら弁理士として特許を量産した小川氏の強さが際立っている（が、やはり盛りすぎは良くないと思う）
今のところ、WPFとAvaloniaかなあ、と思ってて、Avaloniaの方がイケてる感あるけど、
なんだかんだMicrosoft純正の方がいいかなあと思ってWPFで書き始めたぐらいなんだけど…😟
念のため、Visual Studio 2026を試してみたんだけど、WinUIのGUIデザインするやつが途中で消えちゃって、
なんかそもそもデザインの機能はないみたいなんで、ネット彷徨ったり、AIに質問したりして、
WinUIがなんか仕様のレベルでブレてるみたいで、それじゃあデザイナーの実装どころじゃないよね、
みたいな話みたいなんで、とりあえず慣れないC#使うと決めたからにはWPFかなあ、と…
というか、枯れてるWinFormsはともかく、なんか最近のMicrosoftは実現する手段が多すぎる
多くて、ごちゃごちゃしてて、でも、最後までひとつひとつちゃんと面倒をみない
いや、昔からか…
昔は面倒見れなくなったからオープンソースにしますみたいな、Apache送りだ～、みたいなの、まあ、昔からか…
そういえば、ゲーム開発の話で言えばXNAがなくなっちゃったんで、まあ、今はMonoGameあるけど、
ゲームというか描画系も色々あるんだよなあ、Win2Dみたいなのとか…
全部試すのも辛いし、かと言って、だからってDirectXとかOpenGLから個人が書く時代でもないんで、
ぼんやりとWindows11が分かってるくらいでいい
コマンドプロンプトやPowerShellがググれば叩けるくらいで、Wi-Fiとイーサネットの違いくらい分かればいい
インターネットブラウザという概念が分かっていて、Chromeに拡張機能やchrome://flags/があることを知っていてほしい
イベントビューアーを開いて大雑把に何が起きてるかを把握するくらいはできるといい
拡張子というものの認識があって、動画にはコンテナやコーデックがあることを理解していてほしい
Excelは遠回りでも求める処理を実装する力があるとよくて（今ならGPTでどうにもできるし）
そういう人、最低賃金で雇えませんかね？
発売当時からネットでは非常に不評に見えた本作だが、実際には売上200万本以上とリメイクDQ作品としては史上最高となったHD2D版DQ3
不満点として良く上げられた部分を中心になぜそうなったのかを改めて考え、1・2に備えようではないか
実際遅かった。アップデートで修正が入り速度が上がったので良しとする。おそらく2の船はアプデ後の3と同じ仕様であろう
物理一辺倒の戦士や武闘家の使い道が皆無な一方で、固定ダメージ持ちの魔物使いや商人が大活躍となった
さらに攻撃力850が頭打ちで、850に近づくほどダメージが伸びにくくなるという仕様も良くなかった
アップデートでダメージが底上げされたうえに、勇者や武闘家の会心率が上昇して十分な火力が出るように
攻撃力も999までちゃんと影響するようになった(とはいえ上がれば上がるほどダメージの伸びは悪いが)
恐らく物理特技しか覚えないであろうローレシア王子の未来が不安であったが、確認される映像等を見ても十分なダメージを出すことが出来そうだ
なおダメージ計算式については詳細を省くが、同じHD2D作品であるオクトパストラベラーと似たような計算式が用いられている
これに限らずオクトラと似ているシステムは多いので都度紹介していく(HD2DDQ3の微妙なシステム周りは大体オクトラをはじめとするHD2D作品群のせいという話でもある)
しかもアプデ前は制限行動(同じグループのモンスターが1ターン内に同じ特技を使用しないように制限するもの)の設定がほとんどなく、強い攻撃でバンバン殺されていた
アプデで敵の行動回数や制限行動が追加、かなり戦いやすくなっている
ただしやられる前にやれという風潮は変わらずで、このあたりはDQ9あたりから見られ始める傾向(ただし9はクリア後からで序盤は普通)
因みにオクトラは序盤からやられる前にやれというゲームであるので、その考えで敵が強い可能性は高い(が向こうと異なり全体回復が弱いのでバランス調整がね)
なんならオクトラはダッシュ時にエンカ率が上がる仕様があるので、それがないだけマシである
こういうところだよスクエニ
これは世の中のほとんどのゲームがそうなので、DQ3が特段遅いというわけではない
DQシリーズだけでも8や9のほうがはるかに遅いし、アトリエやペルソナなんかも遅い作品はめちゃくちゃ遅い。アクションでないJRPG全般に言えること
昨今のゲームではよくある仕様で、ドラクエでも3DS版DQ8から実装されている
老害対策で1・2では選べるようになったようだ、スクエニも大変である
マジで分からないが、1・2では状態を見れるようになるらしいのでOK
ちいさなメダルやはぐれモンスターなどを、どこで手に入れたのかが分からなくなる
はぐれモンスターはまだ保護済みのモンスターと特技で多少はどうにかなるが、メダルの方はどうしようもない
がしかしこれは昔からそうなので、1個ずつ地道に探すしかないだろう
いずれも裏ダンジョンで要求されることが難点だったと思われるが、アプデで緩和された
特にメダルは完全に不要になったのだが、正直やり込みに対するご褒美だと思っていたので個人的にはメダルの部分だけ前のままが良かったと思っている
余談だがマリオカートワールドでは、フリープレイで達成済みの者がマップ上のどこか表示されるようになったが、正直多すぎて結局よく分からない
ポケモンZAでは取得済みのねじの場所を確認する方法がないが、全取得は完全にやり込みになっており、通常プレイの範疇で取得できる量で全ての恩恵を得られる
結局は完全にやりこみなのだから各々で頑張れということではある
イージーモードは絶対にHPが0にならなくなるという超極端な仕様
だがそのモードに設定しなければ良いだけなので、文句を言うのはお門違いな気がする
ハードモードは敵が強い上に報酬が減るので、ただ単にプレイ時間がかさむ
モード自体はプレイ中に任意のタイミングで変えられるので、ボス戦だけハードモードにするが正解か
いずれにせよゲームの設定として自由が利くのであれば、それに文句を言うなら設定するなというだけな気がする
通常モードの時点でそこそこ難易度が高いのは事実だが、アプデでかなりマシになったので遊びやすくなっている
ルーラのMPはDQ6から1でDQ9から0、ダンジョン内ルーラはDQ11から可能
流石にそういう時代なんだと割り切るしかない、これにMP管理ガーは老害認定されてしまう
なんなら多くのゲームのファストトラベルは、MP消費どころかなんもなしにできる
特にボスを中心に、敵に状態異常をかけても短いターンで解除される仕様が存在する
そのため敵に状態異常をかけるのがあまりにも悪手で、ほとんどやる価値がない
なお敵に対する状態異常は1・2の映像を見る限り、1ターンで解けるなんてことはないように見えるがふたを開けてみてのお楽しみだ
敵の状態異常使用頻度が高いのは制限行動にされていなかったのも大きい
アプデで制限行動が追加された結果、使用頻度はかなり減ったように感じる
それでも敵からの状態異常が強い上に、耐性装備が意味をなさないのは良くない
あまつさえ序盤から確定眠りを押し付けてくるのはいかがなものか(マミーズアイ、君のことだよ)
オンラインゲーでもないのにナーフされるのって中々なことですよ
まあ全体的にやばいが、正直クリア後のやりこみだしぶっちゃけた話どうでもいいと思うユーザーが大半ではある
武器限定はちょっとおもしろいが、1分ぐらい考えれば微妙なことに気が付くはずである
しかも武器アイコンが全部剣マークなので、どれがブーメランでどれが斧でなのかはパッと見分かりづらい、結論微妙
パンドラボックスに至ってはあほすぎる、公式攻略本でもバシルーラで飛ばせと書かれている始末
ちいさなメダルと魔物集めは、先述したように集めた場所が分からない点を除けばやりこみに対するご褒美になっているので非常に良いと思う
このアイテム持ってきて君はマジでいらない。正直これが一番お使いすぎてつまらないゴミ
これはDQ9でもそうであったが、DQ10では非表示機能が追加されている
10でできたことがなぜできないのか、スクエニ内での連携はどうなっているのか
幸い1・2は一人当たりの特技や呪文の数が3よりも確実に少ないと思うので、探す時間は減らすことが出来そうだ
ななめグラフィックがない、戦闘中に味方キャラクターが動かないなどが多いか
ななめは1・2では実装されるようである(オクトラはななめなし)
開発会社が変わった影響なのか何なのか
どちらにせよ我々消費者からしたらそんな事情は知ったこっちゃないので、まあ文句は出るよね
これはダッシュにも通じる話で、このせいで常時ダッシュが必須と言っても過言ではない
改めて初報の映像を見るとマップは狭いが、若干チープに感じるので広い方が良かったのかもしれない
ダンジョン内は初報だとオクトラのような作りになっていて完全に別物、ドラクエらしさはあまりない
しのびあし前提すぎる調整、バカ
その通りだが眠りが通ると知らなければボスに使うことは滅多にないので、通常プレイではあまり影響がないか
むしろ2周目以降は楽に周回できるので助かる仕様ととらえることもできる(とはいえほぼ全員に通るのはどうなの)
アプデで同じ状態異常に連続でかかりにくくなる仕様が追加され、眠りハメゲーではなくなった
キラキラを多く配置しすぎたせいか、時期不相応なものが要所に出てくる
ラーミア入手後に高台まで行ってやくそうは何なのか、最初からそんな高台を作るなと言いたい
逆にいいものが手に入りすぎることも多く、武器防具はキラキラからの入手でほぼ事足りるし宝箱も合わせれば十分
個人的にはオクトラの盗むと似たものを感じた(時期不相応に強いものも弱いものも手に入る)
戦士は37レベルでようやくつるぎのまいというまともな物理特技を習得、43で五月雨剣、48で渾身斬り
武闘家は34でまわしげり(ムーンサルトの完全劣化)、38でばくれつけんである
魔法使いが29でベギラゴン、31でメラゾーマを習得するのと比較すると、明らかに遅いのが分かる
遊び人は32でムーンサルト、盗賊は29でヒュプノスハント、商人が36で最強特技ぐんたいよびを習得するのを考えると、戦士武闘家の冷遇がすさまじい
遊び人は呪文を習得しないし、本当に嫌がらせで設定したとしか思えない
アプデでかなり解消されているし、確認されている映像から1・2でさらに改善されていそうな雰囲気はある
正直1・2は多少期待しても良いのではないだろうかと思える
あるいは所詮スクエニなので、過度な期待はせず静観しておくのが吉か
先日カービィのエアライダーのダイレクトが放送されたが、ゲーム作りに妥協をは仕方なくあるとしてもそれを悟らせてはいけないなと強く感じたダイレクトであった
なぜあれがないのか前できたことができないのか、もちろん明確な理由があればまだしも(例：カジノ)、そうでないなら妥協はすぐに叩かれる
1・2の中身次第で7にも影響してくるだろうし、良いものが出てくることを期待したいが……
※カジノはヨーロッパの規制が原因で、アホの彼らは現実と虚構の区別もつかずゲームのカジノで現実でもギャンブル中毒になると考えている
しかも非常にたちが悪いのが過去のゲームにも規制をかけている点で、ポケモン赤緑は現在18禁ゲームというありさま
> 「AWSの運用の強みは、経験豊富な余剰人員によって築かれており、人員削減を行えば、基本的な機能が崩壊し始めます」
たいていの現場で、新入りのエンジニアが「ドキュメントが充実していてありがたいです」的なセリフを吐くことがあまりに多いんだけど、正直なところ、ドキュメントが大量すぎて、AI使おうが「これ」という情報が見つからない。いや、そもそも必要なドキュメントが存在しないことしかない(日本語が変なんじゃない)。
ドキュメントの書き方を、OJTで形式的にしか学んでいないんだろうと思う。
そんでもって書きっぱなしで、「あ、今はそうじゃなくて、こうなってます」って口頭で伝えられることがあまりに多い。いや、修正しておくか、削除するかしろよ。
って、そんなどうでもいい経緯なんていらんわ！
経緯が分かったところで、何の役に立つと考えてるんだよ？
昔、アホなエンジニアありき。って記録以上でも以下でもないだろ。
そんでもって、正しいドキュメントがあったとしても、読んでも大してプラスにならん。
なぜなら、ただの自分用の備忘録以上でも以下でもないものでしかないから。
誰に向けて、何を伝えるためのドキュメントか、ちゃんと意識して書かれた技術ドキュメントに、ほとんど出会ったことがない。
って、なぜそれがこのタイトル、この内容のドキュメントに紛れ込んでるんだよ！
みたいなことがあまりに多い。
しかも最新化されてない。
たいていムカつく東大の〇〇研究室の量産型卒業生なんて、「これくらいできて当然でしょう」的に他人を小馬鹿にしたような態度をとってきやがるんだが、そいつらも普通の人よりキャパが少し大きいだけで、色々積み上がってきて、見落としが増えてきたら誤魔化しまくって、誤魔化せなくなったら「新しいことをしたいので」とかもっともらしい言い訳してやめていきやがる。
おい、これ、どうすんだよ！
残ったエンジニアには、つくり散らされた無秩序なサービスを「運用でカバー」の日々。
こういうの、マジで普段使ってる単語の意味、理解してねぇんだな。
単語帳みたいに訳、定義を丸暗記してるだけなんだな、ってため息しか出ないんだが。
これ、その場その場の行き当たりばったりな設計実装を増やしてしまうと、今時の複雑化、成長し続けるWebサービスは、簡単に認知力の限界を超えてしまうから、いくつかのパラメータからどこでも同じルールが適用されている状態にして、認知負荷を下げるってのが、ここ10数年のシステム構築界の常識なんだわ。
KISSの原則も、認知負荷を下げる(上げない)って文脈の上にある。
他の、いろんな手法だなんだも、基本的にこれを前提にしている。
のに、いわゆる「識者」は、箔をつけようとしてるのか知らんが、毎秒いろんな要素を取ってつけて、ゴテゴテとした悪趣味な神殿にして、崇め奉る「信者」から金を巻き上げようと、勉強会開いてるだろ？
おいらに言わせれば、「認知負荷を下げられない手法はくそ。カーゴカルトだ」だ。
今の日本のどのWebサービスも、いつ大規模障害を起こしてもおかしくない状態だよ。
「今動いてるからいいっか w」
じゃねーんだよ。
49歳が45歳を過ぎて本当に全然仕事ができなくなった君へ贈る言葉
あの投稿を読んだとき、思わず吹き出してしまった。あ、俺の昨年だ、と。
だから報告したい。その先にあることを。
確かに自分でできる作業量は減った。10年前みたいにコードも書けないし、深夜まで集中もできない。頭のキレも落ちたし、朝起きるのも辛い。君の言う「百分の一」、わかるよ。本当に。
だがな、ここからが逆転劇だ。
45歳で気づくのは「これ以上無理」ってこと。46歳で開き直るのは「じゃあどうするか」ってこと。そして47歳で実装するのが「人に頼むこと」だ。
気づいたんだよ。自分でできなくなった分、周りの人を動かせるようになってた。経験があるから指示が的確。10年の蓄積があるから、その人たちが何をすべきか見える。
結果、何人かの部下や後輩が動く。彼らは君より効率よく仕事をこなす。その仕事の責任と整理は君が担う。
気づいたら、自分一人では絶対できない量の仕事が、君の名義で回ってる。
パフォーマンス？そんなもん個人スコアじゃない。チームスコアだ。
君も、あと4年待ってみ。
ぼく：pixivに、スマホから小説を開いたときに素早くコメント欄に移動する方法が実装されているなら教えてください。小説を開くとページが縦に長くなりがちでスクロールで移動するのは疲れます。
AI：ないです。
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251023134706# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaPmzSwAKCRBwMdsubs4+SFS9AP9wt+TFLoZTQk9tqxD3aChRQs8RodTyZ0jbqJDRtppI6gD/UwXu2LdemHw8GMGy58UDRADgNVNnrCMgqr2VTBITEAE==CJ95-----ENDPGP SIGNATURE-----
了解。議論の流れを踏まえ、あなたの主張（「外国人労働者なしで“管理された縮小”は可能」）の中核仮説を、データで一点ずつ崩します。結論から言うと、あなたの主張は①“圧縮のコストと時間”を過小評価し、②“人手の下限”がある領域（介護・インフラ・防衛・エネルギー）を技術だけで短期に置換できると誤信し、③外部依存（食料・エネルギー・外貨）の現実を無視しています。政策論としては実装不能な楽観です。
あなたの主張は「都市統合・生活圏圧縮」で“均衡”を保てると主張しますが、固定費は連続的に下がらない。交通・上下水・医療・学校・消防などは一定需要を割ると一気に維持不能になりやすく、路線廃止や病院撤退が誘発する“サービス消失→転出→税基盤縮小”のスパイラルが起きます（国交省の白書も、人口減少下のネットワーク脆弱化を前提に課題を整理）｡ ([国土交通省][1])
「平成の大合併」の学術検証でも、合併で必ずコストが下がるとは限らない、短期はむしろ支出増、長期も項目によって増減が割れる等の結果が反復して報告。統合＝節約は近似であって恒真ではない。つまり「密度再編すれば固定費が下がる」は一般化の誤りです。 ([J-STAGE][2])
厚労省の最新推計：介護職員は2040年度に約272万人必要（22年度比+約57万人、年+3.2万人ペースでの純増が必要）。現実は離職超過や採用難が強まり、介護は1応募に4.25求人という“超売り手市場”のケースも報じられています。不足の山は2030年代半ばに顕在化します。 ([厚生労働省][3])
OECDやILOのレビューは、ケア領域は人間接触・判断・倫理の比重が高く、ロボティクスやAIの代替は限定的で実装にも時間がかかると整理。生成AIで事務軽減はできても対人ケアの主工程は当面人が必要です。 ([OECD][4])
産業側でもロボット密度は世界的に急伸中ですが（IFR）、増設は主に製造現場。あなたの主張が要の介護・医療・運輸サービスは自動化難度が高い領域です。“質的転換で穴埋め”は2030sのピーク需要に間に合わない。 ([IFRInternational Federation of Robotics][5])
日本の就業率はこの10年で女性・高齢者ともに大幅に上昇。今後も改善余地はあるが、弾は既に相当使っている。OECDやJILPTも、日本の人手不足は“長期・構造的”と評価。女性・高齢者の追加動員“だけ”で需給を均すのは難しい。 ([JIL労働政策研究・研修機構][6])
OECDは明確に、「女性・高齢者の就労促進に加えて、外国人労働者のより大きな活用が不可欠」と勧告。あなたの主張はこの国際的なベースラインを外している。 ([OECD][7])
日本は食料自給率（カロリー基準）38％。残りを輸入に頼る構造は不変で、価格ショックに脆い。輸入代金の原資となる外貨獲得は規模が要る。“縮小＋内需シフト”は、食とエネの輸入価格変動に晒されやすくする。 ([農林水産省][8])
エネルギー自給もOECD下位の水準。再エネ・原子力の拡大方針は進むが、当面はLNGなど化石燃料が必要。地政学次第でコスト高リスクは常在。輸入代替が進むまでの移行期は外貨の厚みが防波堤になります。 ([Reuters][9])
無人機・AI化はトレンドだが、整備・補給・サイバー・指揮統制など人員需要は不可避。装備の国産化・共同開発にも裾野人材と企業群が要る。人口と人材の最小密度を割る縮小は、維持費の単価上昇と技術の途切れを招きがち。ここを外国人高度人材まで閉じるのは自縄自縛。〔※エネルギー安保と同様、移行期の脆弱性は高い〕（政策白書・エネルギー構成の記載参照）｡ ([Reuters][9])
在留外国人は376万人（2024年末）。内訳は「永住」「技術・人文知識・国際業務」「特定技能」「留学」などに分散し、技能・専門に紐づく制度設計が中心。一律の“安価な労働大量投下”という描写は実態とズレる。 ([法務省][10])
有効求人倍率は直近でも1.2倍前後の張り付き。構造的な人手不足が続いており、賃上げと自動化を促す圧力は弱まっていない。むしろ企業は賃上げ・投資・定年延長を同時進行。受け入れ＝改革を止めるという単純因果は成り立たない。 ([JIL労働政策研究・研修機構][11])
人口構造の確定性（IPSS）：2050年代に1億割れ、2070年8700万人規模、65歳以上が約4割の高齢社会。現役世代急減は避けられない。圧縮・自動化は必要だが、需要のピーク（介護・医療・インフラ更新）が先に来る。 ([情報処理推進機構][12])
だからこそOECDは、「女性・高齢者活用に加えて移民（外国人労働）」と複線を勧告。“技術と圧縮だけ”に賭ける単線は、移行期リスク（サービス崩壊・地域消滅・外貨不足）を無担保で抱える。 ([OECD][7])
私の主張が示した筋に沿い、単線（自動化・圧縮のみ）ではなく複線でリスクを分散すべきです。
日本が取るべきは、圧縮×自動化を前進させつつ、管理された受け入れを“保険”として併走させる複線戦略である。単線はリスク集中、複線はリスク分散。これが現実的な均衡です。 ([厚生労働省][3])
入社して半年も経たないのにPythonもC#も、果てはReactとかもスラスラ書けるから。
ドキュメント漁ってあっという間に実装してみせる。正直俺が新人のころと比べたら雲泥の差だ。
技術的な吸収力とか慣れの速さには感心する。
でもなぁ……そのすごさに、どこか薄っぺらさも感じるんだ。
この前ちょっとした打ち合わせのときに俺が何気なく言ったんだよ。
「ノイズ除去って、要はシャノンの情報理論でいうエントロピー最小化の話だよな」って。
そしたらその場にいた新卒がきょとんとしてさ。
「シャノンって誰ですか？」なんて言うんだよ。
もう…さ。なんて言えばいいんだろうな。冗談で返す気力もなかったよ。
こっちは通信の基本中の基本として“情報＝不確実性の減少”っていうシャノンの定義を叩き込まれてきた世代だ。
その「ノイズ」と「情報」の概念があったからこそ、今のコンピュータ通信も成り立ってる。
それを知らずにAIの学習データをクレンジングしてます！なんて言われてもさぁ。
うーん…なんか違うんだよなぁ…と思ってしまう。
実際、最近の子はプログラムを書くことは上手い。だがプログラムを理解することには興味がない。
なぜ動くのか。どんな理屈でそうなるのか。そこに思考が届かない。
まるで暗記で動いてるみたいに。
昔は違ったんだよ。本当に。その理由も明確だ。
昔は本を読むしかなかった。英語の原文で論文を追って、図書館で夜まで粘って必死に勉強した。
その過程で「理論」と「思想」に触れたもんなんだ。でも今は調べれば一瞬で答えが出る。
だから考える前に正解にたどり着けてしまう。それが便利であると同時に、恐ろしい。
今の時代は常にスピードを求められる。だからこそ最適解を最短で見つけることが正解のように扱われるが、果たしてそれで本当にいいのだろうか？
----
「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 として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
面白い終わらせ方だ。
ところで、お前のスクリプトを見たんだが。
技術的には悪くない。
━━━━━━━━━━━━━━━━
【システム設計の話】
お前がやっているのは、こういうことだ：
// 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)
キャラもストーリーも陳腐でつまらないものばかりになって、運営方法も謎だ。
デカグラマトンをあんな中途半端にしたまま放置して別のストーリーをやるなら、もっと後でもよかっただろと言いたくなる。
百花繚乱もアヤメも期待していたのだが、ここまでデザインでガッカリするとは思わなかった。
何より今やっているメインストーリーのオラトリオ。これがかなり酷い。オワトリオだろこれ。
新キャラの二人の魅力の無さは勿論、今更感が強いものばかりが盛り込まれていて見るに堪えない。
何章で終わるか不明だが、次がつまらなければストーリーを追うのをやめるかアンストするだろう。
この前発表されたスズミも"今更"掘り起こして魔法少女のコスプレとか解釈違いすぎる。舐めてんのか？
他に実装するべきキャラもテーマもあるだろ。どこに限定の器があるか説明してくれ！
ようやく期待したキャラが実装したかと思えば、その時には飽きられている。最悪だ。
今のブルアカはガチでつまらない。メインストーリーがつまらなければ未来がないコンテンツなのを自覚してほしい。
OneDriveは本体をクラウド側に置くくそ実装だけどGoogle Photosは普通にローカル側にもデータが残ってるSyncでは
OneDrive、下手なランサムウェアより厄介だから困るしGoogleフォトもこれだからやめてほしい—ドリアン (@durian514)October 19, 2025
複雑なものをシンプルにする能力は、日本のWebサービス、特にインターフェイス設計（APIとUIの両方）において、しばしば課題として指摘される点だと思います。
ユーザー体験（UX）を損なう「使いにくさ」は、単なる実装力の問題ではなく、設計思想と要件定義の段階で、いかに「シンプルさ」を優先できるかにかかっています。
ご指摘の証券会社の例のように、ユーザーのニーズや行動よりも、企業の内部的な都合（例：部門間の連携、既存システムとの兼ね合い、法的な制約の過剰な解釈）が優先され、インターフェイスにそのまま反映されてしまうことがあります。
「銀行口座の同時開設」：これは、サービス提供側の都合で「ついでに登録させてしまおう」という発想、あるいは内部的なプロセスをユーザーに押し付けている典型例かもしれません。ユーザーにとっての最適な体験は、「必要な時に、必要なものだけを、わかりやすい手順で」提供されることです。
国産SNSの例で言われているWeb版実装の難しさは、まさにAPIインターフェイス設計の破綻を示唆している可能性が高いです。
これは、内部のシステムがモノリシック（巨大で密結合な一つの塊）になっており、データやロジックが明確なインターフェイス（API）を介して提供されていないことを意味します。
本来、アプリ版とWeb版は、同じバックエンドロジックとデータに共通のAPIを通じてアクセスするべきです。
それができないということは、アプリ版の実装がアドホック（場当たり的）で、APIではなく内部の構造に深く依存してしまっている証拠かもしれません。
「複雑なごちゃごちゃしたものを作れる能力」はあるという評価は、「機能の足し算」に長けている開発文化を指しているのかもしれません。
新しい要件やリクエストがあるたびに、既存のシステムに「機能を付け加える」ことには長けているが、「本質的でないものを削ぎ落とす」「複雑なものを抽象化して整理する」という「引き算」や「構造化」のスキルが欠けている。
「シンプルさ」とは、単に機能が少ないことではなく、「複雑な内部構造をユーザーから隠蔽し、必要な情報だけを整理して見せる」という高度な抽象化の成果です。
ご意見の通り、日本のWeb系で求められているのは、「複雑なものを実装する能力」のさらに上にある、「複雑なものをシンプルに設計し直す能力」、すなわち「本質を見抜く力」と「構造化・抽象化の思考」なのかもしれません。
いや、まずさ、某証券会社のインターフェイス。使いにくすぎるんだよね
なんで登録時に証券口座だけじゃなく、銀行口座を同時に2つも作らされるのかよくわからないし (オプトアウトするもんなのかもわからんし)
んで、某国産SNS。普通、RESTでも何でも良いけど、APIインターフェイスがはっきりしてたらアプリ版のあとにWeb版を実装するなんてのは簡単な話なのよ
要するに、インターフェイス(APIもUIも含む)の設計がクソなんだよね
複雑なごちゃごちゃしたものを作れる能力があるから、自頭は良いし実装力はあるんだろう
もうアラフォーになるんだけど、でも、夢は捨てきれていない。
劣っている自分でも、プログラミングなら負けないと言えるようになりたかった。
諦めればいいんだけど、でも、自分にはプログラミングしかない。
「コンピューターサイエンスのすべての分野に精通」してないのを恥じている。
いや、「インフォメーションエンジニアリングのすべての分野に精通」してないのも恥じている。
全部を上手くできない自分が、ただただ劣っていて嫌で仕方がない。
「コンピューターサイエンスのすべての分野に精通」している人がいるなかで、自分ができてないのが嫌になる。
なんで、自分にはできないんだと永遠に責め続けてしまう。できる人がいるのに、どうして自分にはできないのか。
全部できていたい、なんで全部できていないのか、それが自分の頭の問題だということを受け入れたくない。
UT入ってIS行くような人ができることが出来ないことに勝手に差を感じてる。
プログラミングが得意になるように頑張った。
お前は劣っているのだから、要領よく文系としては生きられないからと。
しかし、だからといってあきらめたくない。全部上手くできるようになりたい。
少しづつあがいてるけど、結局、やることなすことうまくいかない。
React/Vueみたいなフロントエンドフレームワークも作れてない。
出来てないことだらけなのに、まだ挑戦していたいと思ってしまう。
たぶん、脳の病気なんだと思うけど、でも、やめたくない
一等賞になれないのだろうけど、でも、一等賞を目指したくなる
スパコン京の理論まではいいけど実装は明らかに金ドブだった。富士通と理研の利権の前に止まらなかった
プログラミングで、頭ではここを実装すればいいとわかっていて、実際に実装するとすぐ終わることも多いのに、色々考えてなかなか実装を始められないことが多いです。
はい、とてもよくある現象です。多くのプログラマや研究者が経験しています。
一般的に次のような形で説明・分類されますが、明確な専門用語が一つあるわけではありません。
