  |
はてなキーワード:マイクロとは
SDカードなのか、マイクロSDAIなのか、よく分からない。まあせいぜい使い倒してやろうと思う。ちょっとしか関係ないけど頑張れGHC-CLI。
「おっさんずラブ」ではなく「クロードコードラブ」。もしクロードコードを使い放題できるマンガ喫茶があれば、泊まり込みしてしまうかもしれない。
大学時代から、プログラミングとか、電子回路とか、金属加工とか、凄い人が周囲にいっぱいいたけど、
自分は何者にもなれなかったけど、最近の中国とか見てると、二足歩行ロボット楽しそうすぎるし、
そもそも、プラレス三四郎とか、メダロットがやりたかったはずなのに、今の俺は何やってんだろう、みたいに愚痴ったら、
複雑な制御系とか、レベル高いのは難しいけど、意外と市販の基板の組み合わせとかでなんとなかるもんです、
箇条書きズラズラ、やってみたら意外とできるかもしれませんよ、みたいに言われて、
まあ、でも、なんとかならんかったんよね…😟
3Dプリンタで出力して、サーボ組み込んでロボットっぽいものまで作ったら、それでもう疲れちゃって…😟
大分日数が経って、忘れたぐらいに改めて自分が作ってたものの残骸を見て、あー、意外と良くできてたな、みたいに思ったりもしたんだけど…😟
そういえば、大学時代に、今みたいな便利環境のない時代でのマイクロマウスの本、
トラ技のムック本？みたいなの読んで、こういうのできたらなあ、みたいに思ったんだけど、
比較的最近で例えるなら、まずCPUをトランジスタで作って、そのCPUを使ったコンピュータを作って、
そのCPUで動作するOSを作って、そのOSで動作するプログラミング言語とかも作って、
みたいなのは、まずレイヤーごとに作れば、なんとかなるのかもしれない、
でも、その当時のトラ技の本とか、最近でもそういうことができる人いるけど、
低レイヤーから坦々と組み上げていくわけですよ、まるで一人でピラミッド建造するみたいな、
昔から今の自分まで、一貫して自分に足りないのは、その体力というか、胆力だと最近も思ってる
そこが圧倒的に足りない…😟
自分は浮気性なので、集中して何かやっても、なんかこれは線形とか比例して成長していけそうだな、
と思ったところで、ダレてしまったりして、要は、これってもう努力と結果が比例するだけなんだ、と思っちゃうと駄目…😟
それより、あー、これは努力では突破できない、これを最初に思い付いた奴はスゲーな！みたいなのが好き、
そういえば、ワナビーじゃなくてウォナビーズの出来の酷さは、キャラデザの園田健一先生もずっと根に持っていたんですね、
今更、なんかで見たけど、たしかにあれは酷かった…😟
なんの話だったっけ…😟
レポートによると、この法律は米国のデジタル資産、特に「決済用ステーブルコイン」に関する連邦レベルの明確なルールを定めたものです。
最も重要な規定は、ステーブルコインの発行者に対する厳格な資産裏付け要件です。
要件：現金（Cash）または短期米国債（Short-term T-bills）による100%の準備金を保持しなければならない。
目的： ステーブルコインのリスク（取り付け騒ぎやデペグ）を排除し、米ドルと同等の安全性を持たせること。
結果： これにより、ステーブルコインは実質的に「デジタル・ドル」としての地位を確立し、銀行や機関投資家が安心して扱える資産となりました。
法律の遵守（コンプライアンス）に伴い、ブロックチェーン側にも新たな技術的仕様が求められるようになりました。機関投資家が利用するためには、以下の2点が必要です。
KYC/AMLへの対応：顧客確認（KYC）およびマネーロンダリング対策（AML）を効率的に満たす仕組み。
選択的プライバシー機能： すべての取引が公開されるパブリックチェーンではなく、機関の取引内容（金額や相手）を保護できるプライバシー機能。
金融取引の決済において、不確実な時間を排除することが求められます。
要件： 「サブ秒（1秒未満）」での取引完了（ファイナリティ）。
背景： 従来の銀行システムや高頻度取引に匹敵するスピードが必要とされています。
この法律の施行により、既存のブロックチェーンの勢力図に変化が生じると予測されています。
取引完了に12秒かかる点と、全ての取引が透明（プライバシーがない）である点が、機関投資家のニーズ（即時決済・秘匿性）と合致しないため、機関マネーの受け皿として不利になる。
規制準拠（GENIUS法対応）を前提に設計されており、「選択的プライバシー」と「サブ秒の完了性」を持つため、機関投資家のステーブルコイン業務のシェアを奪う。
小売（リテール）分野で拡大しつつ、2026年初頭の「Firedancer（アップグレード）」により処理能力と速度を向上させ、機関向け業務の獲得も狙う。
ごもっともな疑問です。GENIUS法やイーサリアムの技術的な話（DeFiやステーブルコイン）は、一見すると「アルトコインやブロックチェーン技術」の話であって、「なぜそれがビットコイン（BTC）の価格を押し上げるのか？」というつながりが見えにくいですよね。
レポートの論理を紐解くと、これらは「お金の入り口（パイプ）」と「最終的な行き先（貯蔵庫）」の関係で説明されています。
なぜ「アルトコインや規制の話」が「BTC爆上げ」につながるのか、3つのロジックで解説します。
1.GENIUS法は「機関投資家マネーの高速道路」を作るから
GENIUS法でステーブルコインが「100%現金/国債裏付け」になり、国の認可を受けるということは、銀行や大企業が堂々とブロックチェーンにお金を入れられるようになることを意味します。
これまで：規制が怖くて、機関投資家は巨額の資金をクリプト市場に入れにくかった。
これから（GENIUS法後）： 「デジタル・ドル（ステーブルコイン）」として安全に資金をブロックチェーン上に持ち込める。
BTCへの波及：クリスプト市場に入ってきた数兆円規模の「機関投資家の資金」は、最終的にどこに向かうか？
リスクの高いアルトコインではなく、最も流動性が高く、価値の保存手段として認められているビットコインに、ポートフォリオの核として資金が流れます。つまり、ステーブルコインは「入り口」であり、その資金が向かう「本命の投資先」がBTCという構造です。
レポートでは「金（ゴールド）が下がって、BTCが上がる」と予測しています。
イーサリアムなどの役割： 送金、契約、DeFiなどの「実用・技術」担当。技術競争（速度やプライバシー）で勝ったり負けたりする。
ビットコインの役割：デジタルな「国家レベルの資産（Sovereign Asset）」。
ロジック：GENIUS法などで市場全体が信頼できるものになればなるほど、「インターネット上の基軸通貨」としてのBTCの地位が盤石になります。ドルが強い環境下で、投資家が金（ゴールド）から資金を抜く際、その避難先として選ばれるのが「規制された市場の王様」であるBTCになる、という理屈です。
これはイーサリアムとは別の話ですが、レポートにある重要な要素です。
OB3（大型減税法案）：法人税が下がり、企業の手元に現金が増える。
トレジャリー（財務戦略）：企業はその余った現金をただ持っているだけでなく、インフレヘッジなどのために運用したい。
BTCへの波及： 既にマイクロストラテジーなどがやっているように、企業の準備資産（トレジャリー）としてBTCを購入する動きが加速する。「ETFと企業の保有で供給の11.7%がロックされる」というのは、この動きを指しています。
「GENIUS法で『道路』が整備され、OB3減税で『軍資金』を得た企業が、最終的に『土地（BTC）』を買い占めに来る」 というシナリオです。イーサリアムやソラナの話は「道路工事の競争」の話であり、BTCの話は「値上がりする土地」の話として区別されています。
ビットコインの価格を語る上で欠かせない「半減期（Halving）」について、基本的な仕組みと、今回のレポートがなぜそれを「あまり重要ではない」と見ているのかを解説します。
半減期とは、ビットコインの新規供給量が文字通り半分になるイベントです。
1. 仕組み
時期: 約4年に一度（正確には21万ブロックが生成されるごと）。
内容:ビットコインのマイニング（採掘）報酬が半分になります。
2.目的と効果デフレ資産: BTCの発行量を計画的に減らすことで、希少性を高めます。
これにより、ビットコインはインフレ耐性のあるデジタル・ゴールドとしての性質を持ちます。
供給ショック:市場に新しく出回るBTCの量が突然減るため、需要が変わらなければ、理論上は価格に上昇圧力がかかります。
【ポイント】 これまでの歴史上、半減期の約1年後には価格が大幅に上昇する傾向が見られてきました。これが従来の「4年サイクル」の根拠です。
今回のサイクル（2025年〜2026年）では、半減期のポジティブな影響をマクロ経済の力が上回ると主張しています。
レポートは、価格の牽引役が「供給側（半減期）」から「需要側（機関投資家）」に移ったと分析しています。
レポートが、半減期による価格の緩やかな上昇を超える力を持つと見ているのが、以下の3つの強烈な需要側の要因です。
具体的な数値:ETFや企業財務保有（DAT）が、既にBTCの**総供給量の約11.7%を保有している。
意味合い: これは、市場で売買される流動的なBTCが減り、価格変動に強い「硬い需要の層」が形成されたことを意味します。この構造的な買い圧力が、半減期で供給量が減る効果よりも強力だと見られています。
GENIUS法: ステーブルコインの規制整備により、数兆円規模の機関投資家マネーの参入障壁が取り払われる（前の回答で説明した「高速道路」の整備）。
OB3法案:企業減税により、企業の余剰資金（法人マネー）がBTCに流れるインセンティブが強化される。
結論:規制環境の改善と企業の資金力投入が、単なる半減期では達成できないほどの、持続的で巨大な需要を生み出すと予測されています。
レポートは、金利とドル高の環境が続く中で、利回りのない金（ゴールド）は調整局面に入ると予測しています。
対照的に、規制整備と機関参入を経たBTCは「主権格の価値の保管手段」としてゴールドのポジションを奪い取るとされています。
【まとめ】
このレポートのシナリオでは、半減期は依然として重要ですが、その効果は「マクロ経済の潮目」と「機関投資家の構造的な買い」という、より大きな波に飲み込まれ、2026年までの長期的な高値圏形成の要因となるということです。
つまり、「半減期が弱いかどうか」ではなく、**「機関投資家の採用が半減期を上回るほど強い」**というのが、レポートの主張です。
私が所属している某大手メーカーの新規事業部が、先日めでたく爆散しました。
いやー、すごかった。何がすごいって、数年かけて数百億円を溶かして、何も生み出さずに更地に戻ったあとの清々しさたるや。
あまりにも典型的すぎて教科書に載せたいレベルの「JTCの新規事業失敗事例」だったので、ここにお焚き上げとして供養させてほしい。
ことの発端は、偉い人たちの「これからはモノ売りじゃない、コト売りだ！」という号令でした。
今までハードウェアを作っていたおじさんたちが、急にシリコンバレーの風に吹かれてしまったのです。で、何をしたかというと、「既存のハードウェアに無理やりWi-Fiつけてクラウドに繋ぐ」。これだけ。
「これで顧客の課題を解決するソリューションになる！」って息巻いてたけど、顧客からしたら「いや、その機械、スタンドアロンで動くのが一番便利なんですけど」という至極真っ当なツッコミは、Teasm会議のミュートの闇に消えていく。
で、中身を作るのは誰かというと、ソフトウェア開発なんて触ったこともない生え抜きのハードウェア設計者たちと、大量の新卒・若手社員。あと少しの中途社員。
経験豊富なCTOもいない無法地帯で、意識高い系の末端エンジニアが「Qiitaで見たから」という理由だけで選定した技術スタックが乱舞。しまいには買収した子会社が自己成長に向けた謎技術の提案。
•ユーザー数人の時点で、Google規模に耐えうるKubernetes構成
• 単純なデータ表示だけなのに、無駄に複雑なマイクロサービス化
そして訪れた「事業撤退」の日。ここからが弊社、いやJTCの真骨頂です。同じチームにいた現地の海外関係会社のメンバーは、Zoom会議一本で即日レイオフ。「Sorry」の一言で画面が消えるドライさ。
一方、日本の我々はどうか。誰一人としてクビになりません。「君たちには明日から、全社DX推進本部に行ってもらう」出たー！「DX」という名の現代の姥捨山！
今までAIなんて触れてなかった人たちが、明日からAIを用いて全社のデジタルトランスフォーメーションを担うんです。専門性？適材適所？ そんな言葉は弊社の辞書にはありません。AIが全てをなんとかするんです！実態は、社内システムのExcelマクロを直すだけの仕事です。これぞ、年収1000万の窓際族の爆誕です。
一番面白いのは、この事業を立ち上げて大失敗したマネジメント層の挙動です。普通、責任取って辞めるとか、降格とかあるじゃないですか。彼らは「貴重な失敗経験を積んだ人材」**として、何食わぬ顔で隣の事業部の部長にスライドしていきました。異動先の事業部の部員たちの、「えっ、あの沈没船の船長がウチの舵取るの…？」という絶望的な顔。モチベーションの低下音が聞こえてきそうでした。
解散後、数名は「敗戦処理部隊」が残されました。任務は、**「ほぼ顧客ゼロのソリューションシステムの維持」**です。
なぜか？
「サービス終了」をアナウンスすると、失敗を対外的に認めることになるから。「あくまで事業再編であり、サービスは継続している」という建前を守るためだけに、誰も使っていないサーバーが唸りを上げています。A⚪︎ureだかの請求書を見ると、月額数千万円。これぞデジタル赤字。
これだけのリソースと金をドブに捨て、社員のキャリアを迷子にさせても、弊社の株価はピクリとも動きません。時価総額ウン兆円の巨体にとって、数十億の損失なんて「誤差」なんでしょう。
今日も社食のランチは美味いし、オフィスから見える東京タワーが恍惚としている。この「茹でガエル」の湯加減が最高に気持ちいいから、私はまだしばらくこの会社にいると思います。
ちょいちょい言ってるように、一般利用者のイメージからかけ離れて多い、という印象がある。
全国CMやってるようなところでも、激ヤバなところはある。
問題は、中のエンジニアのうち、上の方の連中は「俺たちのシステムはイケてる」って認識らしいってところだな。
k8s使ってる。
terraform使ってる。
×××使ってる。
でも、運用頑張ってる。
SRE頑張ってる。
QA頑張ってE2Eテストやってる。
で、障害多数。
なんでやねん w
一つ一つ、ごく局所的に観察すれば、さほど間違えちゃぁいない。
多分参考にした記事が、10年とかくらい前に日本に紹介された方法で、その当時の規模、複雑度を前提としていたりするので、現代に持ってくると、でかくて複雑な大量の設定ファイルを要求する。
そもそも整理するとか、書き直すという言葉が、彼らの辞書には存在しないのかもしれない。
ともかく、規模がデカくなると、そのままの延長で通用しない、という常識が通用しないのだよな。
加えて、その設定ファイルをきっちり書かないと動かないんだが、その書かれた設定ファイルをテストする仕組みはない。
ある場所の設定変更が、他のところに影響しないという保証がない。
ささやき
いのり
えいしょう
ねんじろ！
デプロイに失敗した
みたいなことが高確率で発生し、DevOpsだなんだ標榜していても、新機能のリリースは少ないし、古いリソースの解放はまずやらない。
楽しいわけないよな？
エンジニアが辞めていく。
取り残された連中は、次の生贄を確保するために嘘をつく。
「うちはフレンドリーですよ」
全部、嘘。
楽しいわけないよな？
で、うんこの山を積み上げるスピードを上げて、さらにプロダクトを脆弱にして、働きづらくする。
楽しいわけないよな？
それは解決策じゃない。
せません！
って思うわ。
20年ほど前に業界に入って、OJT受けたおっさんにOJT受けたエンジニアか？ w
ソフトウェアエンジニアリングは、しきたりを1ミリも変えたらいかん伝統芸能ちゃうねんぞ！
E2Eテストなんて、今時のWebサービスの規模、複雑度っていう圧倒的物理量に追いつけるわけがないんだよ。
屁の突っ張りにもならないどころか、
爆上げさせてる
いや、そもそもE2Eテストとセキュリティリスク、なんの関係があるんや？ って問題はあるんやけど w
本来そんな機能がないのにあると勘違いして使うことの危険っての、教えてもらわんとわからんか？
って、安全帯のフックを自分のベルトにかけて、送電線の点検ができるか？
安全帯自体の機能として落下防止が当然あるけど、「正しく使わないと正しく機能しない」し、そもそもそれ、体重を支えられるのか？ それ以前に安全帯か？ ただの100円ショップで売ってたキーホルダーちゃうか？ って問題なんよ。
安全帯でも負荷を支えられなきゃ意味ないし、物が違えば、キーホルダーはキーホルダーだし、安全帯は安全帯なんだよ？
Web記事とかの「単語」だけ相手にするから、こういう致命的な間違いをガンガン積み上げて、炎上現場、高粘性現場にレベルアップさせるんだよ。
DDD、TDD、クリーンアーキテクチャ、マイクロサービス、DevOps。
本人達は真面目に輸送機から「素晴らしいもの」を得るための手順を踏んでるという認識しかなく、おかしなことをしてる自覚が皆無っての、そのままだって気づけ。
理解してるなら、その目的がちゃんと達成できてるか、確認してるか？
ちゃんと適用されたまともな現場を知らんで、「こんなもんでしょ」で満足してるの、頭おかしいぞ。
猿か？
才能がないと思ったら、早いうちに河岸を変えた方がいい。
早ければ早い方がいい。
可哀想だから(教え子が？ それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。
10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？
まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w
それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。
球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。
でも草野球は楽しめる。
才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。
誰にも迷惑かけないなら。
医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。
落ち着きないし。
同じことを何日も続けたら、爆発する。
「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。
こんな感じに、才能がものをいう分野って、意外に多い。
ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。
その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。
どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。
たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。
いや、そういうの主催してる暇があったら、コード書けよ、って。
でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんのAI と変わらんクズだよ。
おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。
シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。
30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。
今だと玉拾いも任せられないくらいだったりする。
ちょい前も、PostgreSQLの中身いじれます！ って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。
そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w
才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。
そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。
マイカーガー。
マイホームガー。
子供ガー。
愛犬ガー。
んなもん知るかっ！
そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。
あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。
VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。
1年で10。
2年で30とか。
マジかよ w
思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？
とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。
真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。
さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。
これで3倍界王拳だ w
経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w
大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。
はっきりいう。
今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。
具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。
ワークライフバランス？ w
才能のない人は河岸変えろ。
業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。
じゃねーよ。
ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。
ってのが多い。
「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」
「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」
うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？ って聞いてんねんけど……。
って現場、多い。
でも、今通常営業してるサービスでも、こういうところ多いんだよな。
それはともかく、
「マイクロサービス化していて、いま120を超えたところで、当面160になります」
「……は？」
「……デプロイの時、どうすんの？」
「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」
「Cloneして立ち上げます」
「これ……、モノリポ？」
「120個？」
「120個」
「なんか立ち上がらないんだけど……」
「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」
「……動かないぞ」
「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」
5日で立ち上げ切れるんか？
って現場がね、案外たくさんあるんだ。
「ほう……？」
どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？
っていつも思う。
マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)
ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。
120のマイクロサービスとか、お前、認知科学の知識もないねんな……。
それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。
まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。
それでプロダクトがうまく回ってなかったら、それが答えなんよ。
まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。
その正しい答えに行きつかない、ってのを
「致命的な才能の欠如」
って呼ぶんよ。
眉カットに行け。そのあと写真撮って、数ヶ月はその形を自分で維持しろ。維持できなくなったらまた眉カット行け。
毎晩風呂に入ったら、ふつうのソープでの洗顔だけでなく、オイルクレンジングで顔の油脂ヨゴレを取れ。
風呂あがりには汗が引いてからなんでもいいから化粧水をバシャバシャつけて寝ろ。
ところでオレはニキビ出来やすい体質だったけど、これに加えてマイクロファインバブルのシャワーにしたらかなり肌きれいになった。だがこれは根拠不明なのであくまで参考情報だ。
髪の毛は相談にのってくれる美容院で似合う髪型にしろ。似合う髪型が見つかったら毎月美容院に通って維持しろ。
これでかなり変わる。
grokと新しい半導体冷却システムの話をしていたら面白いネタができたので書いておく。
水没型冷却(誘電性液体)のNoveck液体などを半導体の中に閉じ込め、その端にヒートパイプをwifiルーターのアンテナみたいに(ウニみたいに)生やすというものだ。
そのアンテナというかウニに、既存の水冷の装置をはめ込むことで、そこで熱交換して冷やす。
つまり、冷やす表面積をさらに増やすというものだ。半導体内部から冷やす。
もちろん、既存の冷却システムのように外部からも冷やしてもいい。
外部と内部の両方からキンキンに冷やせるので、めっちゃ電気食わせてOCしても動くはず。
MSFTがスイス大学のベンチャーと一緒に同様のコンセプトのものを作っているけど、あれは水冷の液体を半導体の中に流すのでとても複雑で摩耗も怖いし、専用のポンプもいる。
この方式の場合、半導体の内部にNoveck液体等が封じられているので、流れることがない。
したがって摩耗もしない。ポンプもいらない。さらに既存の水冷システムとも接続できる可能性が高い。
ヒートパイプの代わりに銅板とかの熱伝導率が高いものを使ってもいいだろう。ヒートパイプは寿命があるし、そこそこ太いのでね。
半導体の内部に閉じ込めたNoveck液体と熱交換できる素材なら何でもいい。
もちろん、内部に封じるのは、Noveck液体である必要はない。熱を交換できて、ウニに伝えられるなら気体でも液体でもなんでもいいよ。
geminiに教えてもらったけど、マイクロループヒートパイプ（μLHP）の半導体組み込み技術というのがあるらしい。
ただ、こちらは半導体の内部に液体か気体の熱交換をもっと促進するものを封じるのが違うところかな。
chatgptはNoveck液体以外も検討した方がいいけど、このアイディアは機能する可能性があると評価してもらえた。また、chatgptによるとウニではなく触手だと。エロゲかよ。
うーん、いけるんかねえ？
もし、10年後にCPUやGPUから冷却用のウニや触手が生えて、半導体の内部に熱交換の何かが封印された製品が出てきたら、面白いなあ。
そんな日々の中で最も厄介なのは、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の積み重ねだ。
手間が増えて、全然楽になってないのなら、それは正しく理解できていず、目的を見失い、手段を目的としているから。
速い話が、
間違えている
からだ。
DDDとかTDDとかDevOpsとかIaCとかクリーンアーキテクチャとかマイクロサービスとかアジャイルとか、とか、とか。
いろんな現場で、責任者は「うちは××を採用して云々」と胸を張って宣言してくれるんだが、「ならなんでそんな状態になってんの？」「なんでそんなにエンジニアがたくさん必要なん？」と聞きたくなる。
今時、SREがいるとか、QAが別にいてE2Eテストとかしてるとか。
まず間違いなく、
間違えている。
んだよね。
TDDをちゃんとしていれば専属QAは不要だし、DevOpsをちゃんとしていれば専属SREは不要。
いやでも「Googleならそうしている」っていうなら、大きな勘違いをしている点を指摘してあげよう。
「君たちはベアメタルサーバを管理していないし、Lanケーブルの取り回しもしていない。GoogleのSREエンジニアが頑張って運用してくれているシステムに乗っかって、アプリケーションに集中できる状態になっているはずだ」
ということ。
何らかの課題なりタスクなりを解決するのに、部下が方法Aと方法Bを出してきたとする。
しかし他にCやDという方法もあり、（自分の目からは）明らかにそっちの方がいい。
わりとよくあるシチュエーションだがこんな時はどうしたらいいのか。
よく言われているのが、答えを指示してマイクロマネジメントせず、部下が自分で考えて辿り着けるようにせよということだ。
ちょっと間違ったら「自分の頭にある考えはなんでしょう」クイズになり双方が不愉快になる。
だったらとりあえずCとDは出してしまい比較検討だけしてもらう方が楽だし成長に繋がるように思える。
それすら言わず最初の方法で失敗させるという考えもあるが、短期的には失敗と認識されず長期的な負債になることもあるので難しいこともある。
相手によってちょうどいい手段を見つけるのが管理職の仕事だと言われそうだが、自分にはできないしこんなことを日常的にやっている世の中の管理職は偉いと思う。
「品質管理が僕たちの責務です」
って、最近エンジニアリング界のライザップ的元テスト専門会社のQAエンジニアが、昔、言ってたなぁ……、と。
思い上がるなっ！
君たち如きに背負えるものでは、すでにない。
とあえて言おう。
いや、マジで、無理なんよ、もう。
例えば、キッチキチにエレベータを作り込んだとして、後から点検してくれ、と言われたら、まぁ、普通は困るよな。
モーター室がモーターが入るギリギリの広さだとしたら、箱の外に出る手段がなったら。
どうやって点検するんだよ。
実際には、設計時に点検方法を決定して、それができる余地を確保してから、施工するものだろう。
今時のEV車なんて、テスト用の仕組みがきっちりと、製品に組み込まれている。
検証不可能とまで言わなくても、検証困難な場合はちゃんと対策をとるもんです。
作りきってから、「E2Eテストお願いねー」とQAチームに投げるものじゃあないんですよ。
設計時に、テスト戦略から何から何まで検討済みになってるもんなんです。
別にユニットテスト書いて、カバレッジあげるのがTDDというわけではない。
検証可能なシステムを設計実装し、リリースのたびにシステムの健全性を検証できる仕組みを整える。
ってのが「テスト駆動開発」なんですわ。
テスト戦略をちゃんと練れば、マイクロサービスの分割の仕方、連携の仕方等々、多分、今、Web上でよく見る記事とはだいぶ様相が異なってくるはずだ。
で、プロダクトの中身である、設計や実装を理解できなければ、検証のしようがないのがここ10年ほどだ。
金槌を渡されて、「品質検査しろ」と言われたら、まだ何とかなるだろう。
けどボーイング787をポンと渡されて、「品質検査しろ」と言われたら？
マニュアルなしで。
モジュールがどう組み合わされてるか等、中身を理解できなければ、何をどうしていいかも分からんだろう？
扉の開け閉めができるとか、主電源入れたらなんか部屋の明かりがつくとか、そういう表面的な検査しかできないだろ？
これは、QAが、設計に飲み込まれることを意味する(10年以上前に、↑のQAエンジニアとした話)。
QAのテストに関する知見を、設計実装するエンジニアは当然持っておかなければならないということとともに、QAエンジニアは消えてなくなるということでもある。
お分かりだろうか？
同じ流れで、SREも不要になる。
Infrastructureas Code は設計実装エンジニアのためのものだと言っておこう。
決して、Terraformのファイルを編集して、SREの許可を、延々と待ち続けて、適応してもらうことをいうわけではない。
そこまで込みで、設計するのだ。
高負荷時にどうスケールさせるかなども、当然設計に入ってくるからな。
ってなわけで、ほとんどの現場では、そういう致命的な誤認識をしていると思う。
認識が古すぎている上に、大型化複雑化した現状を認識できていない。
開発初期はまだ規模が膨らんでいないから、何とかなりそうな勘違いを犯しているだけの話だ。
初回リリース前後で、「あ、やばい……」となっているところがあまりに多すぎる。
また、この誤認識によって、役に立たないエンジニアの頭数だけを並べて札束を燃やし、事業の拡大の足を引っ張っていると指摘しておこう。
ここら、どげんかせにゃならんのよな。
で、遠野。
盛岡や花巻あたりから沿岸南部(釜石、大船渡、陸前高田)に行くのに、ほぼ必ず通過するのが遠野である。東日本大震災の時にはボランティアのベースキャンプ的な場所としてもよく使われた。と言っても大抵の人が遠野と聞いて思いつくのは民話の郷という二つ名だと思う。
いちおう遠野はいくつかのアニメで舞台にはなっている。"魔法遣いに大切なこと"第一作ではちょっとだけ遠野が登場したが、聖地と言えるような場所は存在しなかった。唯一主人公の名字"菊池"が遠野に多いってくらいか。"カッパのクゥと夏休み"は有名どころばかりが並んでいる。"咲"については…これは後述する。まあ全般的に言えるのは、大抵の場合は遠野市が推している観光地を巡れば聖地巡礼もほぼ出来るということだ。
まずは遠野市街地近辺。民話と言えばカッパということで、遠野駅周辺にはカッパのオブジェが山ほどある。まあそもそも遠野市のマスコットキャラクターがカッパなので、カッパの図案はここに限らず遠野全体で見られるんだけどね。遠野駅の向かいにある観光協会にはマストのグッズがある。カッパ捕獲許可証。いや単なる許可証は主な観光関連施設で購入可能なんだけど、ここの観光協会だけは写真入りの許可証を作ってもらえるのね。できれば即日発行して欲しいところだけど、まあ料金は送料込みだし。
遠野市街地の主な観光地は、駅近辺から北東に行った土淵近辺にある。伝承園、オシラサマ、カッパ淵。ここから少し離れてるけどここを経由地にして北に行くと遠野ふるさと村という観光施設があり、古民家はここに多く保存されているし、時代劇等で何度もロケ地としても使われている。今回の案内の"春から秋"という期間からは外れてしまうが、ここでは11月から2月にかけて"どべっこ祭り"というイベントが開かれ、この時どぶろく試飲とにごり酒飲み放題の食事が振る舞われるので酒好きな人は日程を確認していただきたい。"どぶろく"、密造酒のことだが、遠野はいくつかの施設が特区としてどぶろく作りの許可をもらって作っている。祭り以外でも酒屋とか道の駅にはどぶろくが売られていることがあるので、上記期間外でも買って飲める可能性はある。
それ以外には地ビール。遠野はホップの生産地ではあるのだけど、地ビールの精算は特に遠野市街地では遅かった。とはいえ最近のクラフトビールブームに乗って、遠野醸造というマイクロブルワリーが市街地に存在する。どぶろくは飲みやすいがアルコール度数が意外と高いんで、飲めるけどたくさんは飲めないと言う人はこちらも選択肢になる。
話が酒から始まってしまったが、遠野のソウルフードと言えばジンギスカンである。以前は遠野近辺ではけっこう羊を多く飼っていたことも要因にあるらしい。現在は全て輸入肉で提供されているが、元祖店のあんべ、もしくは国道沿いの遠野食肉センターあたりで食べられる。なおこの地域では屋外で食べるときのために穴開きのジンギスカンバケツが普及しているが、たぶん観光で食べるときにはこれはお目にかかれないと思う。
遠野には遠野らしい和菓子もいくつかあるが、とりあえず「明けがらす」だけは紹介しておかないといけない。米粉を主体としたお菓子で、和菓子だがそれほど甘くなく、食感も中外で若干違ったりする。探せば盛岡でも売っているけれど、遠野が元祖ということで遠野で探したほうが見つかりやすい。
遠野市街地の西側にある道の駅を越えると旧宮守村になる。例によってここは平成の大合併で遠野と合併したところだが、こちらはこちらで観光名所が多い。中心市街地ではないが、メインとなるところは宮守の道の駅である。ここは背後にめがね橋の鉄道橋となり、遠野としてはここも含めて遠野のシンボルとしている。あまりに有名な場所なので前述の「咲」では2,3回くらい背景に登場しているらしい。ただマンガが古いため既にない聖地もある。宮守女子のモデルになった高校は15年くらい前に閉校しているし、宮守の中心市街地(というほどでもないけれど)にある宮守駅は完全に建て替えられて跡形もない。ただまあ、それ以外の橋とかはいくつかは残っている。
宮守の方には遠野市街地よりも前から地ビールの会社があって、特産のわさびを配合したわさびエール(発泡酒)とかも出していた。今もいちおう出しているがここの醸造樽では作っていないらしい。
この宮守の市街地から北に少し行ったところに稲荷穴、という湧き水があって、実はそこに併設されている蕎麦屋のそばが美味かったんだが、今は蕎麦屋は跡形もないそうだ。残念だね。
