  |
はてなキーワード: 仕様書とは
日本がラストチャンスとばかりに開始した「日の丸半導体」ラピダスに多大な公費が追加されていることが話題を集めている今日この頃。
心無い専門家たちからは必ず失敗するだの金ドブだの批判殺到中だが、本当に日本（経済産業省）主導の国家プロジェクトは今まで成功しなかったのだろうか？
この記事では主に経済産業省、旧・通商産業省が中心となって始めた国家プロジェクトを振り返る。
大規模集積回路（LSI）の研究、特に基礎研究に力を入れた国家プロジェクト。
当時、半導体弱小国であった日本で700億円以上の金を基礎研究に投資するのは挑戦的であったが、電子ビーム露光技術などの研究レベルのアイディアを実用・量産レベルに持ってくることに成功。
よく「日本は半導体生産はダメだが、生産機械はまだシェアがある」というが、この40年前の国家プロジェクトの技術的成功がかなり大きく、現在でも半導体製造機械はこのプロジェクトに関わった企業が上位にいる。
この成功をバネにして1980年台の日本は半導体生産の8割を占めることとなった。しかし鮮やかすぎる成功体験と日本政府の政治的脆弱性により、90年台に入ると見る影もなく没落したのはあまりにも有名。
通産省は前述の大規模集積回路（LSI）の成功体験を強く意識し、コンピューター技術の「進歩段階」は大規模集積回路が「第4世代」、そしてAI技術が来たる「第5世代」であると想定した。
「仕様書を読んでプログラムを作ってくれるすごい機械」を目指し、500億円規模の国家プロジェクトに踏み切った。
しかし当時の通産省は何もかも見通しが甘かった。大規模集積回路の次がAIというのも謎の括りで、ハードウェアとソフトウェアを混同していた。そもそもなにを研究するのか？という具体的な内容すらあやふやで、やがてはスパコンをよせ集めてもそんなものは出来ないという技術的課題に直面。
現在でいう自然言語処理などのソフトウェア開発を散発的に行い、難航。
それぞれが独自のプログラム言語を作ったりOSを作ったりしたが、特に統合されることも活用されることもなく、「ソフトウェアはむずかしい」ということだけが判明し、放棄された。
なお、唯一の結論「ソフトウェアはむずかしい」ということですら後に生かされることはなかったが、通産省は成功したと主張している。
「10年後にはソフトウェア技術者が60万人不足して、日本は技術的に取り残される–––」
この現代でもよく聞くようなフレーズに慌てた日本産業界は、ソフトウェア技術者の育成に熱い視線を向け始めた。
そこに通産省が入り込むと、さまざまな思惑が一致し、ついには国家プロジェクトとして250億円を投入するΣ計画が発足。日本はソフトウェア技術者の天国となる予定であった。
ソフトウェアという実態の見えないものに予算をかけることへの抵抗感からか、対象は主にハードウェア系企業に集中。
ソフトウェア技術者を増やすという本来の目的は曲解され、最終的には「安価な計算機を普及させる」というハードウェア重視の目標にすり替わっていた。
その結果としてΣステーションと呼ばれる計算機が誕生したが、特に安いわけでもなく、規格が致命的にガラパゴスだったので、ほとんど普及せずに失敗した。
失敗した後も地方を名目としてダラダラと予算が積み重ねられたが、何の成果もなかった。
日本のソフトウェア技術の息の根を止めたとして有名なプロジェクトである。
日本がIT技術に致命的に遅れていることにようやく気づいた通産省は、起死回生の一手としてIT技術に約500億円をかけることを決定。これを「リアルワールドコンピューティングプロジェクト」と名づけた。
しかしそもそもこのプロジェクトには、何の見通しも何の戦略もなかった。
約50個の研究が「リアルワールドコンピューティングプロジェクト」の内容であったが、その実態は検索ソフトから光ファイバーまでバラバラであり、散発的かつ無計画に予算をばら撒くという意味不明な行為は、もはや単一の計画である必要性がなかった。
この計画は最終的に10年にもわたって継続されたが、特に何の成果もなかった。そして膨大な予算とともに記憶の彼方へと消えた。
2000年に入ると、経済産業省は「かつて世界一だった日本の半導体産業を復活させる」という妄想に取り憑かれるようになる。
その数はまさに膨大である。
「みらい」プロジェクト（2001年）に465億円を注ぎ込むも見事に失敗すると、「はるか」プロジェクト（2001年）、「あすか」プロジェクト（2002年）、「DIIN」プロジェクト（2002年）、「あすか2」プロジェクト（2006年）、「つくば半導体コンソーシアム」プロジェクト（2006年）などが代表で、そのほとんどが失敗はまだしも、なんの検証もなく消えさった。
「アスパラ」（2002年）はかなり象徴的で、日本の先端半導体企業が集合して日の丸半導体企業を作ろうと国費315億円を費やしたが、2006年には泡の如く消えた。
これらの膨大な失敗は特に顧みられることもなく、なぜ失敗したのかいう考察もなく、ただ予算ともに忘れ去られた。
いったい何故だろうか？
摩訶不思議なことに、ソフトウェア技術者が致命的に不足していた日本においては、国産の検索エンジンが誕生しなかった。
中国やロシアが自前の検索エンジンを開発し始めると、日本でも国産検索エンジンを作るべきという安全保障上の発想が経済産業省に芽生える。約300億円をかけて国産検索エンジンを開発することにしたが、当時普及し始めたネット界隈はこれを激しく批判。
失敗続きの国家プロジェクトと比較されるが、経済産業省は「かつての国家プロジェクトとは違う！」と強い自信を見せた。
しかしなにも成さず、なんの検証もなく、予算とともに忘れ去られた。
ラピダスにおいては、経済産業省主導の国家プロジェクトは失敗するという根拠のない批判が多い。
しかしこうしてまとめてみるとどうだろうか？
膨大な数の実績が経済産業省には積み重なっている。
少しは信じてあげよう（完）
リチウムイオンバッテリーは、充電と放電が同時に行われることは基本的にありません。これは、バッテリーの充電と放電は電流の向きが逆であるためです⁵。
リチウムイオンバッテリーの充電と放電のプロセスは、リチウムイオンがプラス極とマイナス極の間を行き来することで行われます⁴。充電時にはリチウムイオンがマイナス極からプラス極へ移動し、放電時にはその逆のプロセスが起こります⁴。
したがって、バッテリーが充電されている間に放電（つまり、バッテリーのエネルギーを使用）することは、基本的には不可能です。ただし、一部のデバイスでは「パススルー」機能があり、充電しながらデバイスを使用することが可能です³。しかし、このような操作はバッテリーに負荷をかけ、劣化を早める可能性があるため、長時間のパススルーは避けるべきです³。
以上の情報を考慮に入れると、リチウムイオンバッテリーを長持ちさせるためには、適切な充電と放電の管理が重要となります³⁵。具体的には、バッテリーの過充電や過放電を避け、高温や低温の環境を避け、定期的にバッテリーの状態を確認することが推奨されています³。また、バッテリーがフル充電状態になったらすぐに充電を止め、残量が20%程度になったら充電を開始すると良いでしょう³。これらの対策により、リチウムイオンバッテリーの寿命を延ばすことが可能です³⁵。
(1) リチウムイオン電池の充放電曲線とエネルギー効率について_No.5 .... ttps://www.daiwa-can-ens.com/info/technology/column_0005.
(2) リチウムイオン電池の仕組み【基本をわかりやすく】 - Techs blog. ttps://techs-blog.com/lib/basic/.
(3) リチウムイオン電池を長持ちさせる充電方法は？充電できない .... ttps://www.jackery.jp/blogs/power-station/lithium-ion-battery-charging.
(4) リチウムイオン電池の仕組み【基本をわかりやすく】 - Techs blog. ttps://bing.com/search?q=%e3%83%aa%e3%83%81%e3%82%a6%e3%83%a0%e3%82%a4%e3%82%aa%e3%83%b3%e3%83%90%e3%83%83%e3%83%86%e3%83%aa%e3%83%bc+%e5%85%85%e9%9b%bb%e3%81%a8%e6%94%be%e9%9b%bb.
(5) リチウムイオン電池が過放電した時の復活方法！携帯やPCに .... ttps://allfreeee.com/richiumuiondenchi-kahouden-hukkatsuhouhou/.
Q. スマホを充電しながら使用する場合は「パススルー」機能が使用されるのか、AC電源からのパワーをデバイスとバッテリー充電双方に割り当てるのか。判断方法も含めて調べろ。
スマートフォンを充電しながら使用する場合、その動作は「パススルー充電」と呼ばれる機能によって可能になります¹¹⁵。パススルー充電とは、ポータブル電源本体を充電しながら、本体から他のデバイスに給電できる機能のことを指します¹¹⁵。
具体的には、バッテリーとデバイスを並行して充電する役割を果たすため、コンセント一つで複数のデバイスを充電できます¹¹。この機能は、例えばソーラーパネルでポータブル電源本体へ充電を行いながら、USB接続したスマートフォンへ充電する、といった使い方が可能です¹⁴。
ただし、パススルー充電はバッテリーに負荷がかかるため、ポータブル電源の寿命が縮まる可能性があります¹¹。また、パススルー充電を利用すると、ポータブル電源本体の負荷がかかり温度上昇する場合があります[^10^]。そのため、スマートフォンが熱を持った場合は、利用を控え涼しい場所で休ませることが推奨されています[^10^]。
なお、スマートフォンがパススルー充電に対応しているかどうかを判断する方法は、具体的には製品の仕様書や公式ウェブサイトで確認することが一般的です。また、充電しながらスマートフォンが正常に動作するか試してみることでも確認できます。ただし、パススルー充電が可能でも、常時利用することは推奨されていません¹¹。
(1) 【最新】パススルー充電とは｜仕組み・デメリット・対応可能 .... ttps://www.jackery.jp/blogs/power-station/pass-through-charging.
(2) 充電しながら給電できるパススルー対応モバイルバッテリーと .... ttps://www.elecom.co.jp/pickup/mobile_battery/basic12.html.
(3) パススルー充電とUPS機能の違い - ポータブル電源まるわかり .... ttps://www.denchiya.net/lp/portablebt/basicguide/202112172.html.
(4) 【注意】やってない？スマホ寿命を縮める充電方法と使い方 .... ttps://apprev.smt.docomo.ne.jp/article/794859/.
(5) スマホの充電の正しいやり方【しながら使用してもいいの .... ttps://izuki.net/smartphone/how-to-charge/.
(6) 【スマホ】 AC(電源)アダプタの選び方・違いがわからない・注意 .... ttps://simfreepic.com/blog-entry-164.html.
(7) 過充電でバッテリー劣化は嘘。スマホは充電しながら使っても .... ttps://tonaburo.com/blog-entry-125.html.
(8) スマホの過充電は危険？専門家に聞くバッテリーへの影響や .... ttps://time-space.kddi.com/mobile/20210623/3108.html.
(9) 「ながら充電」や「100％のまま充電」はNG？ スマホの .... https://www.itmedia.co.jp/mobile/articles/2108/19/news070.html.
(10) スマホを充電しながら使うのはNG!?バッテリーの消耗を最小限に .... ttps://chargemap.jp/article/1199.
(11) スマホを充電しながら使うのはNG その理由や対処法を徹底解説 .... ttps://bing.com/search?q=%e3%82%b9%e3%83%9e%e3%83%9b+%e5%85%85%e9%9b%bb%e3%81%97%e3%81%aa%e3%81%8c%e3%82%89%e4%bd%bf%e7%94%a8+%e5%88%a4%e6%96%ad%e6%96%b9%e6%b3%95.
(12) スマホを充電しながら使うのはNG その理由や対処法を徹底解説 .... ttps://sumaho-arekore.com/post-19404.
(13) パススルー充電とUPS機能の違い - ポータブル電源まるわかり .... ttps://bing.com/search?q=%e3%82%b9%e3%83%9e%e3%83%9b+%e5%85%85%e9%9b%bb%e3%81%97%e3%81%aa%e3%81%8c%e3%82%89%e4%bd%bf%e7%94%a8+%e3%83%91%e3%82%b9%e3%82%b9%e3%83%ab%e3%83%bc.
(14) 「パススルー充電」とは? - いまさら聞けないスマートフォン .... ttps://news.mynavi.jp/article/20190411-smartphone_word/.
Q. リチウムイオンバッテリーは充電しながら放電できないのに、パススルー充電がバッテリーに負荷がかかるのはなぜか。科学的に検証したデータを示せ。
リチウムイオンバッテリーが充電しながら放電できないのに、パススルー充電がバッテリーに負荷をかける理由は、バッテリーの充電と放電が同時に行われることによるものです¹²。
パススルー充電では、バッテリーが充電されている間に、そのエネルギーが他のデバイスに供給されます¹²。このプロセスは、バッテリーが充電と放電を同時に行うことを意味します¹²。この同時の充電と放電は、バッテリーに負荷をかけ、その結果、バッテリーの劣化を早める可能性があります¹²。
具体的には、バッテリーが充電されている間にエネルギーが引き出されると、バッテリー内部の化学反応が不安定になり、バッテリーの寿命が短くなる可能性があります¹²。また、バッテリーが充電されている間にエネルギーが引き出されると、バッテリーの温度が上昇し、これがさらにバッテリーの劣化を早める可能性があります¹²。
したがって、パススルー充電は、必要な場合に限定して使用し、バッテリーの健康を維持するためには、バッテリーが完全に充電されてから使用することが推奨されます¹²。また、バッテリーの充電状態を定期的に確認し、適切な充電管理を行うことも重要です¹²。
(1) 【最新】パススルー充電とは｜仕組み・デメリット・対応可能 .... ttps://www.jackery.jp/blogs/power-station/pass-through-charging.
(2) 【徹底解説】ポータブル電源のパススルー充電とUPS機能の違い. ttps://mutinomiti.com/pass-through/.
(3) 落雷による突然の停電対策に使える！ “パススルー充電機能 .... ttps://www.itmedia.co.jp/pcuser/articles/2308/15/news005.html.
(4) よくある質問. ttps://www.dabbsson.com/ja/pages/faq.
Q. 矛盾の説明になっていない。充電と放電を同時にできないのになぜできるというのか。
申し訳ありませんが、誤解を招く表現があったかもしれません。リチウムイオンバッテリー自体は、同時に充電と放電を行うことはできません。しかし、「パススルー充電」は特定の回路設計を用いて、バッテリーの充電とデバイスへの給電を同時に行うことを可能にしています12。
具体的には、AC電源からの電力がポータブル電源に供給され、その一部がバッテリーへの充電に、残りの部分が接続されたデバイスへの給電に使われます12。このプロセスは、バッテリー自体が同時に充電と放電を行っているわけではなく、内部の回路が充電と給電を別々に管理しているため、可能となっています12。
しかし、このパススルー充電は、バッテリーと回路に負荷をかける可能性があります12。なぜなら、バッテリーは充電する際に熱が発生し、その熱がバッテリーの劣化を早める可能性があるからです3。また、パススルー充電中は、ポータブル電源本体の負荷がかかり、温度上昇する場合があります12。そのため、パススルー充電は必要な場合に限定して使用し、バッテリーの健康を維持するためには、バッテリーが完全に充電されてから使用することが推奨されます12。また、バッテリーの充電状態を定期的に確認し、適切な充電管理を行うことも重要です12。12。12。12。12。12。12。12。12。12。12。12。12。12。
Q. 諒解した。パススルー充電の問題点は熱問題だけであると。一般的な回路設計では過度の加熱はしないものと考えられるが、各情報源は熱のリスクを過剰に喧伝していないか。
パススルー充電に関する情報源の中には、熱問題について警告しているものもありますが、それはバッテリーの寿命や安全性を保つための注意喚起と考えられます12。
一部の情報源では、パススルー充電がバッテリーに負荷をかけ、その結果、バッテリーの寿命が短くなる可能性があると述べています12。また、パススルー充電中は、ポータブル電源本体の負荷がかかり、温度上昇する場合があるとも指摘しています12。
しかし、これらの情報源も、パススルー充電が必要な場合に限定して使用し、バッテリーの健康を維持するためには、バッテリーが完全に充電されてから使用することを推奨しています12。
したがって、これらの情報源が熱のリスクを過剰に喧伝しているとは言えません。むしろ、これらの情報源は、ユーザーがバッテリーを適切に管理し、長持ちさせるための有用な情報を提供していると考えられます12。12。12。12。12。12。12。
一部の情報源では、パススルー充電がバッテリーに負荷をかけ、その結果、バッテリーの寿命が短くなる可能性があると述べています12。また、パススルー充電中は、ポータブル電源本体の負荷がかかり、温度上昇する場合があるとも指摘しています12。
何事にも長所もあれば短所もありますが、パススルー充電にも同じことがいえます。パススルー充電の利用は、常時続けているとバッテリーに負荷がかかるため、ポータブル電源の寿命が縮められる可能性があります。ただし、Jackery（ジャクリ）ポータブル電源のProとPlusモデルは、パススルー充電でもバッテリーに負荷かからないように制作されているので、充電しながら利用してもポータブル電源の寿命に影響がございません。
https://b.hatena.ne.jp/entry/s/smart-flash.jp/sociopolitics/277057/1/1/
大阪府の入札結果
https://www.pref.osaka.lg.jp/keiyaku_2/e-nyuusatsu/e-kekka.html
府からの案件は万博公園ばかりで、学生招待業務で旅行会社を呼ばれてたぐらい。
（万博公園の資料デジタル化の入札が0.7千万と5千万の2社なの大丈夫かしら）
大阪市の入札結果
https://www2.keiyaku.city.osaka.lg.jp/OsakaCity-PPI/index.html
コンサルでは、交通需要3.5千万、鶴見との連携2千万、花飾り企画0.7千万とか。
物品では、ロゴ入りの色々が買われてるけど、推進局設置は一社入札でよかったんか。
工事では、上がってこない。委託では推進局の害獣駆除。花飾りや諸外国からのファムトリップツアー業務は入札中止になってる。
(花飾り委託がR5/8、コンサルがR5/11なので不調後の予算見直しのため?)
https://www.expo2025.or.jp/bidding/
は応答遅すぎで開かないのでまた今度(土日が無理?)。
あくまで使用権単体の話ならば行使できるようにするのも1つの戦略なのでアリだと思う。
問題は作品の完成に向けた仕様書・発注書の性質を持つ契約においてである。
ここな。著作権者が同一性保持権を行使する構えであるとき、じゃあ検収してくださいって契約になる場合がある。
これは元々法人向けのひな型にはあるもので、先方のブランドを守るための手続きのテンプレ。
これを個人の著作権者がスルーして契約するととんでもないことになる。
とか確認作業が一気に発生する。たまにアニメ化で忙しくなってる作家などいるが、このタイプの契約が多い
別に本人がやる気なら全然いいし、時間作れるならOKなんだけど、その準備のないまま契約するとえらいことになる。
いやブランド守るために監修しなきゃいけないでしょ、って人もいる
なんで契約する前にまず編集とどういうスタンスで向き合うかをよくすり合わせる必要がある。
じゃないと某増田みたいに「全部チェックしますよね？ 予定入ってるんで行ってきてください」みたいな事態になる。
某大手通信業者に勤めててソフトウェアエンジニアやってるんだけど
会社にも申請して副業フリーランスしていてそっちの収入の方が断然多くてどっちが副業なんだか分からない状態になってる
副業やってると分かるんだけど巷のソフトウェアエンジニアって大半が低スキルで年収もせいぜい500万とかで
高スキル者だと年収1000万越えは普通、2000万クラスもザラっていう感じ
で、自分は高スキル者側にいるので副業フリーランスの方はいろんな依頼も来るしそこそこのプロダクトを作ったりしてるんだが
そこそこ給料貰ってるんだから全然やりますよ、と伝えても、そもそも仕事が来ない
たまに来る依頼はほぼ秒殺できるような内容だったり
依頼内容が意味不明な上に会話しようとしてもコミュニケーションエラーになるような仕事ばっかりなんだよね
基本的にウォーターフォール開発なので仕様書・設計書を最初にゴリゴリ作るような文化で
ソフトウェアエンジニアに対する依頼は設計書渡して「お願いします」って感じ
大抵の場合は設計書の段階でクソコードになっていたりセキュリティ上の問題があったりするので
その辺の指摘をしてみるとコミュニケーションエラー起こして大問題になる
設計書に至までにいろんな会議を通していろんな偉い人が承認してることになってるから
それをひっくり返すのはいろんな人のメンツを潰したり会議に再付議とかなってクッソ時間がかかる
そもそもの組織構造がウォーターフォール前提に作られているのでこのあたりを効率化するのはほぼ不可能に近いし
組織に長く居る人ほどウォーターフォールじゃないと業務出来ない人が多い
高スキル者ってプログラミングに関する知識もそうだけどウォーターフォールでいうところの上から下まで全部やるので
組織構造としてウォーターフォールになってる会社とは全然合わないんだな、とは思っている
例えばうちのCTOにあたる人ってバズワードとか業界動向、社内事情とゴルフについてはめちゃくちゃ詳しいし、そういう人じゃ無いと務まらない
なのでその地位を目指す管理職はそっちの知識を付けようとするし評価もそっちに流れていく
そんな中に高スキル者を同じランクで配置できないし、仮に配置させても全然上手くいかない
CHR$(143)
プレイ時間 88時間（全ステージクリアしたばかりの現在の時間）
全クリして達成感に満ちあふれているが、この気持ちが収まる前に感想を書くぜー！
しかし、タイトル名の読み方がよくわからん。「キャラクターズ・ワン・フォー・スリー」でいいのか？ ちなみに、ゲームのタイトル画面では『Project CHR$(143)』表記となっている。
タイトル名の『CHR$(143)』だが、Amstradというイギリスのメーカーから1984年に販売されたCPC464というホームコンピューター（パソコン？）のキャラクターコード143に四角形が割り振られていることが元ネタのようだ。レトロなコンピューターを元ネタにしてるだけあって、ゲーム画面全体もレトロな雰囲気に仕上がっているのも好きだ。
ゲームのジャンルとしてはパズルゲームでいいはずだ。ちなみに、Steamでのジャンルは「インディー, シミュレーション」となっている。
Steamのストアページの類似品として、『Baba Is You』（説明不要の有名パズルゲーム）に、『Factorio』・『shapez』といった工場建設系シミュレーションに、カイロソフトのレトロ調シミュレーションゲームに、変態パズルゲームメーカー（誉め言葉）で知られるZachtronics社の『SHENZHEN I/O』などが並んでいる。
『CHR$(143)』の紹介文をSteamストアより引用する。
リッチでやりがいのある物理ベースのパズル/ロジック/建設/プログラミングゲーム！弾道学、流体力学、熱力学、化学反応、核反応をマスターし、オートメーションレンガを使い、構造物、機械、乗り物を作り、電力を生産し、パズルを解き、霧を突き破り、CHR$を倒そう！
https://store.steampowered.com/app/1695620/CHR143/
パズルゲームやレトロ調ゲームが好きな私としては『CHR$(143)』のトレイラー動画や上記の紹介文に心惹かれてプレイした次第だ。これがやっぱり面白かった。上記に挙げた他の類似品に匹敵する、あるいは凌駕するほどに面白かった。
ゲーム内容としては、箱庭系というよりもステージ攻略型のパズルである。ゲーム内では各ステージはレベルと表記されているので、この感想文でもレベルと表記する。
パズルの難易度としてはかなり高い。それでも、チュートリアルなどの導入はしっかりしてるし理不尽さもないので、私にとっては時間をかけて考えれば自力でクリアできる難易度だった。とはいえ、悩みに悩んで、日をまたいでようやくクリアしたレベルもある。
ちなみに最終レベルクリアのSteamグローバル実績は1.6%である。これで難易度の高さが伝わるだろうか。
各レベルの主な流れとしては、ブロックを作ったり掘ったり操作したりして目的を達成（レベルクリア）していくことにある。ブロックの一つ一つが物理演算する様は『Noita』らしさを感じた。レベルクリアについてだが、解法がガチガチに決まっているわけではない。時間制限があって急いで操作しなければいけないレベルもあり、レベルによってはアクション性が高かったり、シューティングゲーム要素があったりするのも楽しかった。
レトロゲームは昨今のゲームと比べてジャンルという枠組みにとらわれていない印象があるが、この『CHR$(143)』も同様だ。
ブロックを組み合わせたギミックはとても面白いが、その中でも特に好きなのは蒸気タービンによる発電だ。
ただ過熱蒸気をタービンに送るだけでは発電できず、冷却用の水も同時に必要となっている。タービンで熱交換されて、過熱蒸気はただの蒸気となり、水は温水になる。発電を継続させるためには、蒸気を常に加熱する仕組みと、温水を冷却塔で常に冷却する仕組みを構築する必要がある。蒸気よりも過熱蒸気の方が密度が小さいので上の方に行き、水よりも温水の方が密度が小さいので上の方に行く。こうしたブロック毎の密度の違いを利用してタービン発電を実装していく必要があるのだ。
このように、流体力学や熱力学を反映したシミュレーションになっているのが、『CHR$(143)』の面白いところだ。
非常に頭を悩ませながらも面白かったのがプログラミングだ。AND・OR・NOTなどのブロックで論理回路を実現できるだけではなく、CPUブロックも存在する。そしてCPUに対して、このゲーム専用（たぶん）のプログラミング言語で命令をプログラムできるのだ。この言語がとても低レベル（低水準・低レイヤの意味で、決して侮蔑表現ではない）なのが面白い。逆ポーランド記法で数式を記述したり、goto文で条件分岐したりといった具合だ。言語の仕様は大量にあり、pdfファイルでまとめられているほどの徹底ぶりだ。しかも、ゲーム中でも詳細はpdfファイルを参照するようにと求められるのだ。パズルゲームで、まさかプログラミング言語の仕様書を読まされるとは思わなかった！
とはいえ、言語仕様を全て理解する必要はないし、プログラミングもゼロからコーディングする必要もない。プログラムはサンプルとしてすでに作られた物をコピペで流用して必要な個所だけを書き加えたり修正したりすればいいし、仕様書も必要なところだけを読めばいいのだ。それはそれで、ある意味リアルなプログラミングともいえるのだが……。
説明するのを忘れていたが、ゲーム全般は日本語対応しているものの機械翻訳なので翻訳はガバガバだ。とはいえキー操作一つで英語表記に戻せるのでそんなに問題は無いし、翻訳のガバガバっぷりはそれはそれで味があっていいものだ。しかし、プログラミング言語仕様が描かれているpdfファイルは英語オンリーなので、読み解くのに苦労した。とはいえ、言語仕様を調べようとして英語の説明しかなくて苦労するというのにも、これはまたリアルなプログラミングだなぁと感じたものだ。
好きなレベルについても述べたいので、まずはレベルがどのように構成されているかから説明する。
チュートリアル的なレベルでギミックの説明から始まり、レベルを経る毎にギミックを応用させた解法が求められる。さらにレベルを経るとこれまでの集大成的なレベルが登場して、それをクリアしたらまたチュートリアル的なレベルで新たなギミックが登場する。この繰り返しが『CHR$(143)』の大きな流れだ。
その中で私が好きなのは、やはり集大成的なレベルだ。集大成的なレベルは視界が狭まっており、一体何があるのだろうかと周囲を探索しながら進んでいくのが楽しかった。こうしたレベルはクリアがSteam実績解除の対象となっており、それにふさわしい達成感も与えてくれる。
そして最終レベルをクリアしたのが、つい最近のことだ。この達成感を味わったことを書き残したくて、今この文章を書いているところだが、それももう終わりのようだ。
かっちりとした設計書を作ることは少なくなったが土台となる仕様書やソフトのマニュアルとかは未だに存在するが、まぁ読まない。酷いと帳票のデザインから仕様を読み取ってプログラム組んで後で間違いと気づいて質問してきたりする。
仕様書が正で帳票デザインが間違いなのでそれを直せば良いだけなのに見比べるとかしない。
技術書や公式ハンズオンを最後までやらない。ググって赤の他人のQiitaの内容で理解した気になる。だから想定外の時に何も検索条件を出せない
確かに技術書でHello, world!出すのは達成感は無いし仕事の何に役に立つんだって思うけど大半の技術書はその分野の土台を網羅しているのでその後の詳細な知識の吸収には圧倒的に有利になる。なのに3章までもやらすに分かった気になって開発に勤しむ。でコピペコードでソースレビューで説明できず勝手に機嫌悪くなる。誰も粗探しもしていないのに。
確かにベンダー系の資格は高いし更新にも金かかる。IPAの資格は時代遅れ感半端ない。でもシステムに勤しんでいて無勉で受けて合格する人は半分も居ないだろう。難易度が高くなればさらに減る。
あほくさい勉強だけど実力はつくし自信と箔もつく。転職でも評価はされる。資格取らなくても勉強してアウトプットしているのなら良いけどそれもしない。
そんな感じなので検索のワードの粒度が荒いので問題解決に時間がかかる。おまけに英語が嫌いなので海外の情報はシャットアウト。最近はChatGPTに聞きまくるがそれでも意味不明な物を作ったりする。
軽く指摘するとはてなブックマークで未経験なのにChatGPTでサービス作った人の記事を教えてきたが、たぶんこの人は技術書を最後までやり切れる人だからすぐ飽きて出来もしない上を目指す君にはChatGPTも匙投げるよと言いたかったけど「凄いねー」で済ませた。
仕事だから嫌々やっている事も出来ない人材が年々増えている。好きな物はChatGPTとキントーンとセールスフォースな感じの
ついでに未来の話を聞きたい。よろしければ。
クレヨンとかでコンセプト画を描く。
下っ端が実図面に起こす。
ザハ・ハディドなんかはトンカチ一つ持ったことがないから、下っ端に完全おんぶにだっこ。
日本人は、そういうセンセイの立場になるまでに下積みなしということはまずないので、
これはもちろん例えで、
コンセプト・構造・意匠を統合して立体構築する頭脳労働＝プログラ厶の設計
ということになろうかと思うが、
建築の場合やっぱり下から全部やった人がクレヨン握らないといいものができない。
ザハ・ハディドなんかはどっかの独裁国に馬鹿げた「作品」作っただけで先進国ではついに通用しなかった。
プログラミングはどうなのかな。
いずれAIにどんどん下働きは任せて、人間はコンセプトとか要望を出すだけで良くなるのか
仕様書を作ってないシステムの概要を資料にまとめて欲しいと言う依頼
その程度であればと思い受けて、数時間でできる程度の資料を作って送る
結局、
あれも教えて欲しい、これも追記して欲しいと工数以上の事を要求される
「何でこんなお粗末な資料を寄越すの？」って言われても、DB設計書も指示書もまとまってないんだから多めに見てくれよ、この程度の工数でやる気なんて出ねえよ
「何でそのままDBのカラム名をプログラムで使わないの？」って言われても、パスカルケースとキャメルケースとスネークケースが混ざっているし、日本語ローマ字だらけのカラム名をそのまま使えるわけねえだろ
と部屋で一人愚痴りながら書き上げて送る
叩き台作らされた上に、修正で手を動かす側にさせられるのは損だなと思いつつ
