StructurePlay
朝ごはんについて、考えていた。 朝ごはんについてを考えていたはずだった。 しかし 「アサゴ・ハーン」 と言った瞬間、何かがおかしくなった。 いや、おかしいのは名前である。 アサゴ・ハーン。 なんだその、朝食のメニューを統一しそうな名前は。 チンギス・ハーンと同じ語尾なのに、通貨が納豆かもしれない。 なんだこれは。 ...いや待てよ。 アサゴ・ハーンがいるなら、 ヒルゴ・ハーン もいるのではないか？ いる。それは昼食を文明の頂点と考える帝国である。 定食文化が異常に発達している。 ...コホン、ということはだ。 ヨルゴ・ハーン。 これもいるよな。 夜食こそ人類の本音だと主張し、シメラーメンを外交カードとして使う危険な国家だ。 まずい。三食がモンゴル帝国になってしまった。 いや、まだ戻れる。これはただのダジャレだ。 ここで止めればいい。 ……。 オヤツ・ハーン。 いた。 なんでいるんだ。 しかも一番平和そうである。 三大帝国が国境で睨み合っている横で、オヤツ汗国だけが紅茶を飲んでいる。 お
ThinkingEssay
The Professional Consciousness of Japanese IT Engineers — From Reverence for Mechanical Design to the Age of the Abstraction-Layer Stroll 著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info) この文章は、技術そのものの歴史ではない。日本のIT技術者が、自分たちの仕事を何だと思い、何を「設計」と呼び、どこに権威や引け目を感じてきたのか。その職業意識の変化を追う試みである。 ひとつ断っておく。以下には、資料で確かめられる歴史的事実、既存研究から借りる理論的な補助線、筆者の経験から立てた仮説の三つが混じる。とりわけ中心の見立て――機械設計への劣等感、それが安全装置として働いたという話、そして「抽象層さんぽ」
StructurePlay
因幡の白兎という話がある。 白兎が海を渡りたい。 しかし船がない。 そこでワニに声をかける。 「君たちと兎、どちらが多いか数えてあげるよ。向こう岸まで一列に並んで」 ワニは並んだ。 親切である。 白兎はその背中を踏んで海を渡った。 そして最後の一匹のところで言った。 「本当は数えるためじゃない。お前たちを踏み台にして渡りたかっただけでーす！」 なぜ言った。 黙って岸へ上がればよかった。 詐欺を働いたうえ、被害者の目の前で成果報告まで行っている。 ワニは怒った。 そりゃ怒る。 ワニ側は、 一列に並んだ。 背中を貸した。 最後まで黙って協力した。 悪いところが一つもない。 全面的にピョン太郎が悪い。 ワニはピョン太郎の毛を剥いだ。 ここだけ聞くと残酷だが、事件名を正確に付ければ、 因幡海峡ワニ集団欺罔事件(いなばかいきょう・わにしゅうだん・ぎもうじけん) である。 加害者は白兎。 ピョン太郎である。 ピョン太郎はワニの怒りによって全身ずるむけになり、泣いていた。 そこへ大国主が通りかかった。 大国主もたぶん、 「お前何やっとん
StructurePlay
Pokémon Idulle: Reading the K-POP Industry as a Competitive Battle Environment 著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info) K-POPアイドルの評価は、なぜあれほど急に上がったり下がったりするのか。本人は何も変えていないのに、ある日突然パートが減る。その理由を「人気の移り変わり」で片づけると、いちばん大事な構造を見落とす。 K-POPについて考えているうちに、ひとつの対応関係に気づいてしまった。 才能＝種族値、生来の資質＝個体値、レッスン＝努力値振り、オーディション＝厳選、事務所＝トレーナー、コンセプト＝型、カムバック＝シーズン更新、衣装・
StructureEssay
Why "Pokémon Ieru Kana?" Makes Your Mouth Move on Its Own 著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info) 「ポケモン言えるかな？」は、初代151匹を題材とし、そのうち150匹の名前を歌うCMソングとして知られている。作詞は戸田昭吾、作曲・編曲は田中宏和（たなかひろかず名義）[1]。だが、この曲を「懐かしい暗記歌」として片づけると、その設計の大半を見落とすことになる。 大人になって聴き直すと、イントロからすでにおかしい。明るいファンファーレではなく、ハウス寄りのダンスミュージックで始まる。そして途中、名前の羅列は唐突にクラブラップへと変わる。 ここで、ひとつの見立てを立てておきたい。これは名前にメロディを付けた曲ではない。名前の音の中に、最初からメロディとリズムが眠っていて、それを掘り当てた曲なのではないか。
1000engineering
私は、ある時期から技術コミュニティに少し引っ掛かりを感じるようになった。 最初から否定的だったわけではない。 会社の外で知識を交換できることにも、技術者同士がつながれることにも、大きな価値があると思っている。 今でも、その考えは変わらない。 ただ、長く眺めているうちに、一つ気付いたことがある。 技術コミュニティで語られることは、思っている以上に「ある範囲だけ」を見ている。 もちろん、そこで語られる内容は重要だ。 新しいフレームワーク。 クラウド。 生成AI。 アーキテクチャ。 設計手法。 どれも技術者にとって必要な知識であることは間違いない。 しかし、それらの多くは「どう実装するか」という話だ。 つまり、技術の実装レイヤーである。 私は以前、「技術者とは、技術を知っている人ではなく、技術の概念を理解している人ではないか」と考えるようになった。 その頃から、少しずつ違和感が生まれた。 技術そのものを考える話が、意外なほど少ないのである。 技術は、なぜ生まれるのか。 なぜ企業はその技術を選ぶのか。 その技術によって、組織はどう変わるのか。 責任はど
StructureEssay
Contracts and the Translation of Emotion — Reading Korea's Judicial View of Contract Through the NewJeans Litigation 著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info) 2024年春から2026年の現在まで、NewJeans、ADOR、HYBE、そしてミン・ヒジンを巡る一連の紛争は、監査、仮処分、刑事告発、行政申告、本案訴訟という異なる制度の上を移動し続けてきた。報道の見出しはそのたびに「勝訴」「敗訴」「完敗」と書いた。読者もまた、そのたびに誰かの側に立ち、誰かを責めた。 本稿は、その勝敗表を書き直すためのものではない。
1000engineering
「どうすればできるの？」 一見すると、とても建設的な言葉に聞こえる。 実際、現場でもよく使われる。 しかし、この言葉は建設的な発言とは限らない。 むしろ、責任を他者へ移すための言葉として機能してしまうことがある。 問題は「問い」ではなく、「誰が考えるか」 例えば実装担当がこう言う。 「この通信経路では成立しません。」 「この権限では動きません。」 「この運用では回りません。」 ここで、PMなりリーダーなりが、 「どうすればできるの？」 と返す。 これは、一見すると前向きだ。 しかし、その一言だけで終わるなら、実装担当は * 制約を分析し * 代替案を考え * リスクを整理し * 工数を見積もり 最後に判断材料まで用意することになる。 つまり、 制約を理解する責任そのものが実装側へ移っている。 本当に建設的な人は何を聞くのか 本当に現実を見ようとしている人は、こう聞く。 * なぜ成立しないのか。 * 制約はどこにあるのか。 * 要件を変えれば成立するのか。 * 納期を変えるべきなのか。 * リスクを受け入れるべきなのか。
ThinkingEssay
How the separation between abstraction and implementation changed the culture of engineering. Written by Reichi Kirihoshi (min.k) · mncc.info Listen to how software gets discussed now. Cloud-native. Serverless. Zero-trust. Agentic. Self-healing. They are good words; each points at something real. But increasingly the talk floats free
1000notes
記号を追いかけるより、記号になる人になりたい。 別に、インフルエンサーになりたいわけではない。多くの人に知られたいわけでも、自分の生活を見せ続けたいわけでもない。 ただ、自分という生き方が、いつか誰かの生き方に引用されるような生き方はしたいと思う。 あの人と同じ服を着たい、あの人と同じ場所へ行きたい、ということではない。 何かを諦めるとき。 何かを選び直すとき。 みんなが進んでいる方向から、一人だけ降りるとき。 そんな場面で、誰かがふと、 「あの人も、こういう選び方をしていたな」 と思い出せるような生き方。 それは、注目されたいという欲望とは少し違う。 自分の人生を、自分だけの中で完結するものとして雑に消費したくないのだと思う。 生きて、迷って、選んだことのどこか一部分が、他人にも使える形で残ってほしい。 自分そのものを真似してほしいわけではない。 自分の考え方の一節を、必要なときに持っていってほしい。 誰かの人生の主役になりたいわけではない。 ただ、脚注くらいにはなりたい。 「こういう生き方もある」と示す、小さな参照点になりたい。 自分の生き方が誰かに引
1000engineering
技術企業だからといって、技術ばかりを見ていてはいけない。 一見すると矛盾しているようだが、私はむしろそう思っている。 技術は重要だ。だからこそ、真剣に見なければならない。しかし、技術とべったりになった瞬間に、企業の視点は驚くほど短絡的になる。 「次は何を導入するか。」 「どのモデルが勝つのか。」 「どのフレームワークへ移行するべきか。」 もちろん、それらは重要な問いである。 しかし、それだけを追いかけ始めると、本来考えるべきことが見えなくなる。 顧客にどんな価値を届けたいのか。 組織として、どんな能力を蓄積したいのか。 五年後、十年後も変化に適応できる状態とは何か。 技術は、その問いに答えるための手段であって、問いそのものではない。 これは企業だけの話ではない。 個人の技術者も、特定の技術そのものに関心が止まっていると、やがて成長が停滞する。 新しい製品を覚える。 新しい構文を学ぶ。 新しいフレームワークを使えるようになる。 それ自体は必要なことだ。しかし、そこで学びが止まれば、技術が入れ替わるたびに、また最初から追いかけ直すことになる。 本来、技術
StructureEssay
Amazon Doesn't Bet on Technology. It Invests in Continuity. 著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info) なぜGoogleほどの技術企業が、AmazonのようなEC企業にはなれなかったのか。 検索という最強の入口を持ち、機械学習の水準でも先行し、資金も人材も潤沢にあったはずのGoogleが、それでもAmazonのようなEC事業者にはならなかった。 GoogleはそもそもAmazonと同等にはECへ投資していないのだから、この問いには意味が薄い、という見方もあるだろう。それでも、あえてこの問いを立てることで見えてくるものがある。両社の差は、単純な技術力では説明できない。どちらも世界最高水準の技術企業だからだ。 Amazonの本当の強さは、ECでもAWSでもAIでもない。変化を前提に、自らを更新し続けるための基盤と文化を、長期にわたって構築してきたことにある。その根底には、継続可能性への投資、技術との適切な距離感、リアルオプション的な経営とい