  |
はてなキーワード:仕様とは
セーブとリセットしてやりなおしができない仕様、ノーマルでも死亡や詰みの頻度がそこそこあるならイージー選びそう
初期にしょぼい装備と小銭渡されるより、いい装備、大金持ってたいと思うかどうかは微妙
時間かけて稼げるなら自分で得たいが、経験値や取得金額が多くなるなら有難いかも
流石にゲームだと自分も敵も強さ、使用スキルが一定で丸わかりだから余裕出来たら次の町行くなりクエスト受けるが
人生金がかかりすぎるし稼いでる間に歳とって色々できなくなるから金は欲しい
他は厳しいというか成長しやすい環境のほうを選びたいというのはあるがきつすぎるのはやだなあ
ダイヤモンドの↓の記事が盛りすぎでブクマカが釣られまくっているので、ちょっと落ち着けという意味で少し解説する
普通の人が「フリック入力を発明」というフレーズを見たら、どっちを想像する？
普通は1を想像するよね。でも、上の記事の「発明」は2の意味。8割くらいのブクマカはここを勘違いしてコメントしてるように見える
同じ発明家氏の記事でも3ヶ月前の東洋経済のほうは、「フリック入力を発明」という釣りフレーズこそ使っているものの本文を良く読めば発明のキモの部分が2であり1では特許を取れなかったことがそれなりに分かるように書いてある
「フリック入力」を発明しMicrosoftに売却した彼の"逆転"人生。元・売れないミュージシャン兼フリーター、家賃３万のボロアパートでひらめく
https://b.hatena.ne.jp/entry/s/toyokeizai.net/articles/-/889631
もちろん2の意味の発明もスゴイし重要なんだけど、釣りは良くないよね
そもそも世の中のほとんどの技術は様々な発明やアイデアの集合体である。歴史の積み重ねであり、最終形がいきなり湧いて出るわけではない。もちろん「フリック入力」にも歴史の積み重ねがある。それを少し紐解いてみよう（なお、下記の「年」は引用可能な特許や論文が出た時期であり、実際にはそれよりもっと前にソフトウェアがリリースされていたりアイデアがメーリングリストに投稿されていたりすることもある）
[追記]※増田の仕様上ひとつの記事に貼れるリンク数に制限があるため一部URLのhを抜いている点、不便ですがご了承ください[/追記]
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)用に実装された文字入力UI。「中央が『あ』、上下左右方向が『いうえお』」に対応する見慣れた形のフリック入力がここで登場する。『現在よく見る形の日本語版「フリック入力」の元祖』である。なお、開発者が特許を申請したものの審査を請求しておらず、特許としては成立していない
この頃、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に実装されたことは不思議でもなんでもなく、
このあたりは荒唐無稽な邪推すぎて、ソフトバンクから名誉棄損で訴えられたら危ないのでは（そもそもiPhoneのフリック入力を開発したのはAppleであってソフトバンクではない）
まとめると、さすがに小川氏の記事はモリモリに盛りすぎである。書籍の宣伝にしても酷すぎる。価値の高い特許を取った発明家であることは事実なのに、なぜこういう胡散臭いムーブをしてしまうのか
1998年にAppleNewton用に開発された日本語入力システム「Hanabi」が草分けで、2008年にiPhoneに採用されたことで、急速に広まった。従来の「あ段→い段→う段→え段→お段」とキーのプッシュを繰り返して表示・入力する方式（トグル入力）に比べ、素早い入力が可能になる。その入力効率の高さから、2010年頃にはキーボード離れが加速している[1]。
1998年にAppleNewton用に開発された日本語入力システム「Hanabi」[2]が草分けで、2008年にiPhoneに採用されたことで、急速に広まった。日本におけるフリック入力は、発明家でシンガーソングライターの小川コータがiPhone上陸以前に考案し2007年から2015年にかけて特許出願した[3]ものであり、取得した権利はマイクロソフトに譲渡された[4]。
ただ、これはおそらく関係者の自作自演等というわけではなく、日本におけるフリック入力関連特許が小川氏のものばかりであることからボランティア編集者が勘違いしてこのような記述にしてしまったのではないか。フリック入力は前述のように地道な技術の差分の積み重ねなので、個々の差分の開発者が「特許」を取ろうという気にならないのは良く分かる。その点でも、自ら弁理士として特許を量産した小川氏の強さが際立っている（が、やはり盛りすぎは良くないと思う）
例えば高市や参政党の賛美、財務省陰謀論、池上彰は日本人ではない、等
んで、これはまずいなと思ってPCからオカンのYoutubeアカウントにアクセスして、プロパガンダ系の履歴を消した
あと、オカンのアカウントでshortsを見て、表示される政治系動画をすべて表示しないように手作業で設定していった
朝になって、オカンは政治動画ではなく、健全な趣味の動画を見ていたので、これは早速効果が出始めたということだろう
しかしこの監視は継続しなければならない。家族の精神を害する情報は俺様が止める
以下回答
ゲーム機メーカーが「自社ハードウェア事業を終息」し、「自社ソフトを他社プラットフォームに供給する」という方針転換を行う場合、経営・ブランド・技術・収益面などで多面的なリスクやデメリットが生じます。以下に体系的に列挙します。
🧩 1.経営・戦略面のリスク
■ (1)収益構造の変化による利益率低下
- 自社ハード販売による利益（ハード本体・周辺機器・ライセンス料など）が消滅。
- 他社プラットフォームでは、**販売手数料（例：30%前後）**を支払う必要があり、**利益率が大幅に低下**。
- 「プラットフォーム料」によって価格戦略の自由度も制限される。
■ (2) 成長ドライバー喪失
🎮 2.ブランド・マーケティング面のリスク
■ (1)ブランド価値・アイデンティティの喪失
- 「ハード＋ソフト一体の体験」を提供していたブランドが崩壊。
- 消費者にとって「唯一無二のゲーム体験」を失う。
- 長年築いた「プラットフォームブランド」（例：PlayStation、Switchなど）が**事実上消滅**。
■ (2)既存ユーザーの離反・不信感
■ (3)販売チャネルの再構築コスト
⚙️ 3.技術・開発面のリスク
■ (1)技術力・開発ノウハウの空洞化
■ (2) 他社プラットフォームへの依存度上昇
💰 4.経済・契約面のリスク
■ (1)ロイヤリティ・手数料負担
- プラットフォーム運営会社（例：Sony,Microsoft,Nintendo,Valveなど）に販売手数料を支払う。
- サブスクリプションサービス（例：Game Pass）に参加する場合、**収益分配の条件交渉が不利**になる可能性。
■ (2)価格政策の制約
🧠 5.組織・人材面のリスク
■ (1)人員削減・士気低下
■ (2) 開発体制の再構築コスト
🧩 6.市場・競争面のリスク
■ (1)差別化困難
■ (2) 他社との関係悪化の可能性
🕰️ 7. 過渡期の移行リスク
✅ 総括
観点 主なリスク・デメリット 経営 利益率低下、成長鈍化 ブランド 独自性喪失、ユーザー離反 技術 ハード技術衰退、他社依存 組織 人員整理・士気低下 市場 差別化困難、競争激化
もし本当にMicrosoftがXBOX販売から撤退したら、こういうリスクを織り込んだうえでそれでも決断せざるを得なかった、という事なわけだ。
今のところ、WPFとAvaloniaかなあ、と思ってて、Avaloniaの方がイケてる感あるけど、
なんだかんだMicrosoft純正の方がいいかなあと思ってWPFで書き始めたぐらいなんだけど…😟
念のため、Visual Studio 2026を試してみたんだけど、WinUIのGUIデザインするやつが途中で消えちゃって、
なんかそもそもデザインの機能はないみたいなんで、ネット彷徨ったり、AIに質問したりして、
WinUIがなんか仕様のレベルでブレてるみたいで、それじゃあデザイナーの実装どころじゃないよね、
みたいな話みたいなんで、とりあえず慣れないC#使うと決めたからにはWPFかなあ、と…
というか、枯れてるWinFormsはともかく、なんか最近のMicrosoftは実現する手段が多すぎる
多くて、ごちゃごちゃしてて、でも、最後までひとつひとつちゃんと面倒をみない
いや、昔からか…
昔は面倒見れなくなったからオープンソースにしますみたいな、Apache送りだ～、みたいなの、まあ、昔からか…
そういえば、ゲーム開発の話で言えばXNAがなくなっちゃったんで、まあ、今はMonoGameあるけど、
ゲームというか描画系も色々あるんだよなあ、Win2Dみたいなのとか…
全部試すのも辛いし、かと言って、だからってDirectXとかOpenGLから個人が書く時代でもないんで、
生成AIのコードを読まないで、そのままコピペして動かしても、動作が仕様通りではないので、指摘して直させる、これの繰り返し…😟
だって、こちらの指示や意図と多少ズレてようが、まあこんなもんか、で妥協できてしまう
今になって、やっと自分もAIにコード補完させたりして書いてるんだけど、こちらの意図を先読みしてコードが出てくるのは面白いんだけど、
ときどき、自分の意図に反したようなものを候補として出してくるんで、これはこれで思考がブレるというか、止まるというか…
でも、自分が知らない言語とかで、ちょっと試しにこんなもん書いてみるか、みたいなときは模範っぽく進めてくれるので助かる
発売当時からネットでは非常に不評に見えた本作だが、実際には売上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禁ゲームというありさま
---
日本の教育現場では、児童・生徒がスマホ・SNSを利用することでいじめ・犯罪・自傷リスクが増大。
高齢者や中年世代も、スマホOSの変化により操作が困難で、生活に必要な情報アクセスに課題。
端末・OS・アプリが海外企業中心で、国民全体の生活基盤としての安全性・安定性が不十分。
政府アプリ（マイナポータル）の普及により、国民が行政デジタルサービスに依存する状況が増加。
デジタル機器利用がほとんど**「米や野菜の次元」まで多用されていることを鑑み、教育端末・高齢者端末を国産基盤で統一し、安全・安心な情報圏を確立**する必要がある。
---
デジタル機器利用がほとんど「米や野菜の次元」まで多用されていることを鑑みて、OS／端末を国民に広く浸透させ、生活の基礎インフラとして安定供給する。
Google等の海外情報収集・広告モデルに政府が深く依存する状態を是正し、国内企業の技術・サービスを活用する。
LINE等国内企業製アプリのUI・UXを参考に、教育・高齢者向け端末の基本操作形態に転用。
マイナポータルと教育ポータルを連携させ、市役所・役場などの行政サービスへ安全にアクセスできる統一窓口を実現する。
いじめの「撮影→SNS拡散」を技術的に抑止し、第二次性徴期における心理的打撃を未然に検知・介入できる体制を作る。
中年・高齢者が既に慣れた操作感（ケータイ的操作）と、子どもの学習ニーズの双方を満たすUI/UXを提供する。
ネット遮断下でも安否確認・避難情報が機能する極小OSモードを整備し、国家レベルの迅速な対応を可能にする。
NECやLINE、国内スタートアップを連携させ、端末・OS・アプリの内製化・雇用創出を促進する。
情報利用の透明性（誰がいつ見たかの監査ログ）と、プライバシー・人権を尊重する利用ルールを制度的に確立する。
---
操作方法は「トーク画面・アイコン・通知方式」を教育・高齢者向けに最適化
3-2.ターゲット端末
---
LINE等国内製アプリUIを基本形として、教育・高齢者端末の操作性を最適化
TRON派生極小OS（Life-TRON）に移植する際もUI/UXの操作感を維持
互換レイヤーを用いて、Androidアプリも政府OS上で動作可能
4-2. サブフェーズ
OS設計・仕様確定政府OS基盤設計TRON系極小OSに国内UIを組み込み、教育・高齢者端末向け軽量UI・操作性を設計IPA、TRON協会、NEC、LINE
移行用互換レイヤー開発Androidアプリ継続利用 現行学習・連絡帳・SNSアプリを互換環境で動作。API/ID連携を政府OS標準に統合スタートアップ、NEC
教育端末・高齢者端末実証 実運用テストUI操作性、災害モード、ログ管理を確認教育委員会・自治体
ポータル・アプリ移行データ統合教育ポータル・学習アプリ・SNS・行政サービスを政府OSネイティブ化IPA、NEC、LINE、スタートアップ
全国展開・定着 完全移行Android端末は段階的にフェーズアウト。全国学校・高齢者施設で展開文科省・総務省・自治体
4. 段階的にネイティブ化・全国展開
---
5. 実行体制
大手企業（NEC・LINE）：端末製造・クラウド提供・UI転用
---
6. 次のステップ
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）:Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）:Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
CoreWeb Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<metaname="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 |ホーム</title>
<metaname="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml"title="RSS"href="/feed.xml">
<meta property="og:title" content="あなたの名前 |ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home /About /Posts</nav>
<footer>© 2025あなたの名前</footer>
GitHubPages（Jekyll標準。Rubyベース、Node不要）
CloudflarePages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C.ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：SearchConsoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
----
「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 として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
執筆依頼は半分ジョーク、ユーモア、道化を演じるためにそう言っているだけ、という気もする。その本気度の低さが依頼が来ないような行動の原因にもなっていると思う。
そもそも執筆依頼らしきものが来たところでやり取りの仕方諸々、どうすればいいのかわからない。
執筆依頼のトラバに今後の意思疎通をするための連絡先等書いてなかったらこちらは連絡先を求めるトラバを書くことになるだろう。
それに対して別の増田が茶化して偽りの連絡先を書くような攻撃を受けるかもしれないし。
でもこれは「連絡先やホームページをさっきのトラバに追記してください」とトラバすれば事足りることかもしれない。
↑ほとんど直近で書いたこれも個人的にはなかなか自己内省的かつ自分と同じ障害を持つ人の代表を、総意を自負した文章だと思っているのだけど。
お前はたぶん知ってて言及してないのだから、お前の挙げる記事には及ばないということだろう。
つまり何が言いたいかと言うと、なにをもって「あれほど」と評しているのか、その他俺が個人的にそれなりの記事だと思っているものに対してどういう基準で劣るものとしているのかいまいち判然としない。
単に文章量だろうか？
それなら、「あれほどの」記事がその後出てない理由は簡単で、そこまでの文章量を要するような話したいことがないからだ。
「どのような人でも、一篇の長編小説を書くことができる」という言葉がある。
俺にとってそのような文章を書く一つの契機があのときだったということだ。
俺にとってはあれは文章量が普段と比べて尋常じゃなくなっているだけで、日記を書いているのと変わらない。
ただ、統合失調症の体験記というテーマにおいて、事実の方が有り余っている。
俺はその事実を列挙するだけであれだけの記事になった。俺は事実を列挙したに過ぎない。
今の俺には列挙するような事実が無い。
回答3
あれは正確に書けば「俺が今まで書いたもののなかで、受け応えとして採用するには嚙み合わないものをわざわざ選び取ってトラバをしているように見えるが、そうだとしたら目的がわからぬ」となる。
↓それは、このツリーで
https://anond.hatelabo.jp/20251017183258#
に
むり
と返されたわけだが、俺が言ったことがある言葉であるが、何がむりなのか読み取れなかったから。
どうやらこの「むり」は「根気強く話しても伝わる可能性はない」ということを主張する意図で俺の過去の言動を引用したもののようだ。
ということで今は目的がはっきり推測できるので、発言は撤回する。
はてなブックマークの仕様に対してそのような妨害策を取っている人が今までいなかったから。
要するに、なんとなく人と違うことがしたくなった。いや、そういうことに対して、増田やブクマカたちにどのような反響が出てくるか、ということへの興味の方が大きいかもしれない。
ほぼ確実に来る未来なのに、考えようとしても実のある道筋が演繹されない。どうすればいいか、ああどうすればいいか、うーんどうしよう、という、ただ思考をしているという合図にしかならない言葉が無限に頭の中をこだまするだけなんだ。
経験したことがない未来を想像することが難しい、という特性なのか。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251021150742# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaPcjMAAKCRBwMdsubs4+SGlGAP9CV9jeWoltLbEK0/bbAnXQXO/pVUHDEW3tSiS7kO+9ggEAxq98WRZrn77hsG5esLt4hVHeKj3MUU9Qp/E6mqZtwAA==ZCJB-----ENDPGP SIGNATURE-----
配属されたシステム開発部には定年後再雇用されたベテランの先輩が一人いるだけで、
UNIFACEとかDelphiとかで作られた化石みたいな業務システムを保守してた
改修や仕様追加はわりと頻繁にあり、先輩はやり手でちょちょいといじって直してしまう
それを俺もできるようになってくれというのだが、研修があるわけでもなく、
UNIFACEもDelphiも10～20年前の参考書しかない
零細のWEB制作をあちこち転々としたあと、反社のフロントみたいな企業に落ち着き
7年くらいコーディングとか、社内ツール作ったり簡単なPHP開発なんかをやった
近年はChatGPTとかも活用して小規模なWEBサービスも作ったりしてた
とか思ってしまった
それで「開発もそれなりにやってきました」って体で実際に転職活動してたら
転職先は中小JTCだが結構ちゃんとしてて、業界は落ち目だが競合が少ないので転落は緩やか
なんとか定年まで勤め上げれば老後も不安なく生きれるだろうなって感じ
そこまでは良かったのだが…
ダメだった、俺開発とか出来なかったわ
配属されたシステム開発部には定年後再雇用されたベテランの先輩が一人いるだけで、
UNIFACEとかDelphiとかで作られた化石みたいな業務システムを保守してた
改修や仕様追加はわりと頻繁にあり、先輩はやり手でちょちょいといじって直してしまう
それを俺もできるようになってくれというのだが、研修があるわけでもなく、
UNIFACEもDelphiも10～20年前の参考書しかない
使用人口が少ないのかネットを漁っても情報が少なすぎてすぐ積む
WEB開発してた時はネット検索＆コピペ＆AI生成で何とかなってしまっていた
それが今はどうにもならん
毎日毎日過去のコードを読んでるが、前提となる業務知識も複雑で遅々として解読が進まない
先輩は優しく「わからないところは何でも聞いて」とか言ってくれるが、
四十路のおっさんがこんなこと言うのもあれだが、正直もう完全に自信喪失して逃走したい気分になってる
完全に力不足だった
かと言って辞めたところで何ができるわけでもないんだよな
この前まで反社のいい加減なフロント企業でちょっと真面目だったから重宝されてただけで
なんかもう人生が完全に行き詰ってると感じる
Permalink |記事への反応(27) | 12:50
