「見た目の因果 v.s. オッカムの剃刀」的な何か

グラフを共有されて「AとBが相関しているのでうーたら」ということで何か判断がくだされていて、まぁ相関なのでCが疑われるんだけど、浅く考えるとAがBの原因みたいに見える、なーんていう事例を見ていて頭を抱えている

「AがBの原因」……うーん表面的にはそういう説明もできるんだよね、とは思っていて、ただ、私が観測している文章化が難しい他のコンテクスト由来の情報に併せて考えるなら、その因果関係を予測するのはちょっと馬鹿らしい、という感じなんだ。

例で言うなら、準備もなしにダンジョンに飛び込んだパーティが全滅して、その原因は最後に回復呪文の詠唱が遅れた僧侶のせいだ、と言っている感じ。ええとね、僧侶を叩きたいのは分かった。でも準備がないのが真の原因です。

ただ、人の世の中ってのは上ほどはっきり確実に真の理由を断定できるなーんてことはない。とくに言語化難しい、明白でないコンテクストを議論の土台に持ってくのは大変っちゃァ大変。

概ねこういうときは「予測して、おおよそよく当たる方が正しい」みたいに時間軸をつけて解釈をすることで、いたずらに論理を弄することなく予測する力を鍛えられること「も」ある。『超予測力』の論旨は大体そういうやつだったし、私の短い小さい経験の中でも、「言葉に説明できないが勘案しとくべきパラメータ」の評価ってのは時間を置いてきちんと見直すほうが、言葉尻の論理とやらに倣うより有効っぽい（あくまで「っぽい」にとどまる）印象ではある。

ただねぇ、ある種の会議で議事録に残る瞬間ってのを考えると、上の理路っつーのはなかなか通しづらいなとも思うわけだ。「その仮定の論理的正しさ」みたいな方が、ある種の裁判官は好きなわけよ。たとえ予測可能性が低そうな感じであっても。

んでもって、「オッカムの剃刀」の「ある事柄を説明するために必要以上に多くの仮定を用いるべきではない」「ある現象を説明する理論・法則が複数ある場合、より単純な方がよい」的な話ってのは、どちらかというとその「ある種の裁判官」の言い分寄りで、現実の生存率に関わる話とはちょっとずれているな、と思った次第。

まぁ原理定理の世界というよりは、文学的な比喩だからねぇ……

「知っている」と「わからなくなる」という現象がある

網羅的な分析をする気力もないのでメモだけしておく

「何か」を使っていると、その「何か」のうち、どこかを軽視するようになる

「何か」を作っていると、その「何か」のうち、どこかについてそれがどのくらい難しいことなのかが分からなくなる（→その作るプロセスの何処かを簡単と誤認するようになる）

普段ソフトウェアを使っていると、それを作るプロセスを何か具体的に経験したことがないのに「作れそう」という感じが生まれることがある。問題は実際にはどのように作るかについては、本当に、一切、全く、経験が増えていないにもかかわらずそうなることだ。

強いて言うなら、「使い勝手の評価」というごく一部の「テスト」に「関わる」知見はその人は蓄積する。ゲームを考えよう。「面白いゲーム」を私は知っている、だから、私は面白いゲームを作れる、と誤認するようになる。

「役に立つソフトウェアを知っている、だから、私はそのソフトウェアを作ることもできる」という誤認は多い。おそらくだが「身近」になると、その親近感によって、プロセスを全く知らないのにもかかわらずそちらも「近しい（つまり触れたことがあり、何某か通じている）」と連想する脳の働きがあるんだろう。親しい知り合いからの頼まれ事は、同じものでも知らない人からのよりも受け入れやすいことがある。事象としては遠いところにはあるが、脳のショートカットの中では類似した回路を援用しているような印象がある。

作っている側は作っている側で、身近なことを距離を置いて捉えることができなくなる。私はソフトウェア開発の文脈でよくこういうことが「あった」。今その症状が幾分緩和しているのは、ソフトウェア開発の講座を何度も主催側で見てきたからであり、現在進行系でも人を育てることがあるからだ。自分が当たり前だと思っていることが他者ができるようになるかは不明で、それに達する速度も人によってまちまちだ。基本情報技術者を半年程度で取る金融出身のnon-tech系中年もいれば、ITパスポートを何度も取りこぼすバリバリのITエンジニア若手もいる。

ちなみに上の発想が想起されたのは「共通フレーム2013」を読み直しているときであった。ウォーターフォールなりには良い示唆が書かれていると思うが、あいにく多い。正しいが示唆が多い。極論すれば、多数の正しいが多すぎる（故に現場で動的に想起できない）指摘それらが、全体として何かに収斂していく感覚があった。ユーザ企業とベンダー企業の間で起きるすべての問題がここにあるもう少し雑な（大局的な）話題に収斂するとまでは言わない。ただ、結構なチェック項目は、同フレームほど細かくするまえに対話の中で危ない兆候を拾えるように思えた。「土台の警戒心」は、チェックリストの物量よりも「コスパが良い」感覚が私にはあるのだ。

もう「エンジニアをエンパワーとか言わんでええんちゃうかな」と思い始めた件

まだ公開の場ではそのストーリーを使うと思うんだけど、気分的にはちょっと違うステータスになっているなと思ったのでメモ。

2つの方向で「違う」と思った。一つは「ソフトウェアエンジニアに傲慢な無能が増えてきた」という状況。もう一つは「ソフトウェアエンジニアという人種、みたいのに興味はなくて、別の属性の人に対してソフトウェアエンジニアリングという力を得てもらうことも含めて支援をしたい」という話。

1つ目は、まぁ人気が出てきちゃったからね、みたいのがある。正直、国内について言えば私が新卒採用された頃から状況は良くなかったわけだけど、今となってはもっとひどくなっているし、国内のその界隈の人々は一周回ってもっと態度が悪くなっている。これについては長く書かない。馬鹿らしいから。

2つ目の方が本質でポジティブかなと。結局、「口を開けて仕事待っている」感じの人にはそもそもそんなに魅力を感じないわけだ。どちらかといえば、率先して荒れ地に踏み込んで問題を解決しようとするメンタリティの人が好きであって、そういう人を支援したい、そういうときに、棍棒で戦うだけじゃないんだよ、という支援がしたいのではないかと。

G.M.ワインバーグをすごく好んでいた（今も好きだよ）時期の自分の思想に戻ってきている感じはある。「問題解決者」が好きなので、その「問題解決者」をエンパワーしたいのだ。

当時……つまり、「ソフトウェアエンジニアをエンパワーしたい」という気持ちを持って国内に戻ったとき、この「問題解決」の前線として自分が注力できる領域として筆頭にあったのが「ソフトウェアエンジニアリング」という領域とそれを専門にすることだった。

ただ、今となっては自分の中で「対象をそう絞る理由もないな」というのが実感としてある。（自慢かな、自慢になっちゃうかな！？）別にエンジニア風情でなくても、普通の人を育てられるような感じになってきた、ということなのだと解釈する。

まぁもちろん、育児の現場とか製造の現場とか医療の現場は、私が今持っている仕事の文脈においてはかなり遠いので、そこに飛び込んで大丈夫という感じはない。一方「ソフトウェアエンジニアリングを弄する問題解決者」が必要とされる領域ならば、別にそこに開発者がいる必要自体は感じなくなっている。むしろ、中途半端に現代の日本の慣行に慣れた怠惰な人種がまじりやすい感じがあって、「いっそ、いないほうが良い」と思うことすらある。

「正しい動機と意志を持っていて、でも棍棒で叩く方法しか与えられていない」善良な人というのは世の中にはきっと相当いて、ヘボい人によって苦労している。「ヘボい人」が「経営」を弄するのなら、多分私が手伝う（しょっぴく）べき領域は「経営」になるんじゃなかろか。なんか自然にそっちの話増えているし

※ところで、棍棒持ちにソフトウェアエンジニアリングの力を与えるっつーのを私は「全員ソフトウェアエンジニアになれば良いんですよ」と表現することもある。一方で「全員ソフトウェアエンジニアになる必要なんてないんですよ」という言葉も同時に口をついて出てくることがある。前者は、多分だが「現代風味の『DX人材』とやらを考える際にソフトウェア開発とその基礎部分が全く抜けていることはありえないし、そのあたりを多少やれば、現状のしょぼいエンジニアリング慣行に対しては十分ソフトウェアエンジニアと名乗ってしまえるのでは」という攻撃的な文脈が含まれる。後者（全員なる必要はない）は、例えばLinux上の操作やパーミッション設計というのはある意味議論で重要視するべき細部ではなくて、クラウドかIoTかでも話全然違うので、そこは上手く専門職の文脈に近い正系統の「ソフトウェアエンジニア」に任せればよいのだし、ソフトウェアエンジニアと名乗るならそっちになりなさいよ、ということを含んでいるんだと思う。「ITエンジニア」はこの文脈では前者風情であって、その名を名乗るべきじゃないんだ。

めんどくさいことをやれっつー話

世の中いろんな手法はあるのだけど「無駄」は省けても「本質的な困難」を消せる手法っつーのはないように思う。

手元に『GE式ワークアウト』という本がある。数年来本棚に放置されていた本で、役にたつかは分からないがそこにあった。

ここでいう「ワークアウト」というのは会社の課題（できれば根源的なもの）を草の根的に議論を始めたあと、ある種のプレゼンを通じて上位陣営（できれば取締役級）の決済を得た後に議論の成果を体系だって組織に浸透させる活動の手法……であるように見えた。最初の数ページでそう見えたんだ。

……合格だ（葬送のフリーレンのゼーリエ風）

問題はこの場合、手法の細部はともかく「ワークアウトを実施し切る覚悟ありますか」という一点に尽きるのだと思う。ここで読者の99%は脱落するはずだ。そして残った1%のうちの90%くらいは上位陣営を説得できない。残りの90%はその後の取り組みで持続力を維持できない。さて何人残っただろう（こたえはこたえは……0人。読者が一人もいない〜）

ゼーリエ風味に「合格」なのは本の視座だ。おそらくこの視座を持って2000年代初頭に書かれていた本がそのあとの書き筋で凡庸ということはおそらくない。だから本は「合格」

ただし読者が実施できるかどうかは「極めて怪しい」。読んで「分かる」は間違いない。ただし大抵、読んだ後には字義通りに実施しないし、ましてやはじめから自組織にカスタマイズもできようはずがない。「守破離」でかっこつけて「破」あたりからやって失敗するのはよくあることだ。問題はこの手の改革は本の内容を「守」ってもどこかで荒波に出会うことだ。大事なミーティングにみんな参加してくれなくなったりする。忙しくて自分がかいてあることをすっぽかす。

最も根底にある難しい条件がある。この手のことはどんな手法を使っても「めんどくさい」のである。これを越す魔法の薬というのはなかなかない。

もう少し構造化するならこうだ。時間がかかり、優先されるべき事態が差し込まれ、意識が常に別のトピックに引きづられる中で（経営者が変わることかもしれないし、子どもの不登校かもしれない）、意識を自然と引き付けてくれるわけでもない自分提案のやや「長期」的視野に基づく匍匐前進みたいな地道でスローな活動を維持するのは本当に難しい。難しいは数式が解けないとかじゃない。ダイエットできない、みたいな難しさだ。眼の前のお菓子すら我慢できない人類には不可能にすら見える。

ここ最近は（うーん自慢かな、自慢に見えるかな、まぁいいか）本系統の（場合によっては数年ものの）めんどうくさい話を数個捌いてきた履歴が自分の中にできてきていて満足している。

そういっためんどくさいうちの一つは、ようやくこちらの仕事が着地して案件からバイバイできた……と思った後、そのさらに数年後にめんどくさい原因だった人が逮捕された。「本当にヤバいやつだったんだ」と感嘆してしまった。その一連の（時間だけで言えば5年以上の単位でストーリーが散発的に続いていた）話題で振り返って思うのは、そういうことを踏み越えていくのは確かに真の自信につながるのだなということではある。あと些末ながら、なんなら案件中に捕まってほしかった……

こういった賢しい中年にならないとわからないことの一つ。めんどくさいものはだるい。そして言葉尻賢くても、こういった「めんどくささ」「だるさ」が越えられないというパターンがとても多いのだということが身にしみて分かってきた。

とはいえ、具体的に語るに難しいが（ぜひ語って自慢したいが）単に我慢するという話ではなくて、ある程度基礎的な思考方法と自分の怠惰を是正する仕組みの組み合わせで成功率は上がるのだという感じもある。

ただ、最初に言えるのは、キラキラした手法はいいからめんどくさいことをやる覚悟は持てよということだと思う。

中年になると、若手の我慢のなさというのは確かに我慢ならないというケースが有る。最近着地しつつある取り組みがあるのだが、言ってから着地の道が数年後くらいに見えてきた今の段階ですでに3年経っているのはなかなかハードなやつだ。トータルで5年もののプランだったわけだ。いやプランとすら言えない。誰かがいれば、……つまり、上のような粘り強いことをやってくれちゃう偉い人がいればすぐに開始して着地が収まる話が、自分が着地まで持っていく場合にはその数倍エネルギーと時間がかかるという話なのだ。「都合の良いスーパーマンがいればすぐ終わるので、終わらせてくれ」みたいな希望にすがるのは、冷静に考えるときっつい。若手というより正真正銘のガキでしょ。どーにも私も「最近の若いもんは」とか言いかねないじじいに近づいている。でもこれ、「最近」要らないね。「若いもんは」こういうもんなんだと思う。いいから、めんどくさいことをやれよ

私のケースでは、「結果的に」考えれば（当初はスルーされたりしていてほんとしんどかった）、終始めんどくさいことをやり続けた私の方に勝機が湧いてきたような感じだが、この経過を観察すると「めんどくさいことをやれ」という凡庸な言葉はかなり震える程度に人に失望させるアドバイスで、とても重要だ。

冒頭の本の評価はそれと比べれば一瞬でできる。そういうことをやってきました。ご紹介します、という本なら、それの著者は正真正銘でやりきった連中であることは自明だ。合格だ。ただし、読者を合格に導けるとは思わない。それは読者の宿題だ。

純粋な「良い」を接種できると期待するのはおこがましいことだ

www3.nhk.or.jp

まずは食品ではなく医薬品の文脈でいつも頭の片隅でひっかかるやつから。「ジェネリック医薬品だと効かないから元の方よこせ」という人がいて、なるほどなと思った。「主成分が同じ」が「効果が同じ」とは限らないのよなと。「値段安くて効果同じ」みたいな子どもの川柳を、大々的に店の壁に張り出していた薬局が以前あったんだけど、発想がナイーブなぁ、と今でも思う。

医薬品になりえない健康食品について全部否定するつもりもないのだけど「利益が薄いものでも気休めに接種する」って発想は結構危ないように感じる。

極論を言えば製造している工場を自分で視察しているわけではないから、工程に取り違えがあってとんでもない物質が混入してしまったときに末端で気づく術はすごくすくない。「医薬品」でもトラブルは起きるが、チェックのゆるい健康食品（例えばビタミン剤）が海外の怪しい工場で作られていて、どこかで妙なカビが混入するだの水銀が入るだのして、それがきれいなパッケージに入って輸入された際に気づく有効な術はない。

「支払いに対して、ついてくるベネフィットが純粋単独になるべきである」期待、あるいは「支払いに大してベネフィットの組み合わせが開陳されている」期待、というのは消費者としては素朴に持ちがちではある。袋の空いていないこんそめ味ポテトチップスの中身がきのこの山だというのは「あり得ない」ことを素朴に私達は直感しているし、事実髪の毛入っていても謝罪してくれる。

でも、ほとんどのベネフィットとその組み合わせは「保証」されていない。消費者保護の観点は現代では非常に強いから「消費者庁が許していないはず」ということにあぐらをかいている。全員大小様々な立ち位置で（適切に）油断している。油断を多くできる社会はより多くのエネルギーを他のことに割ける。

ただそれは「限界まで油断してしまって良い」ということも意味せず、油断の度合いにおいては綱引きが発生する。

健康食品について言うならこの綱引きの面倒なところに問題がありがちだ。「医薬品」のような箔と縛りのセットを引き受けるか、さも「ちゃんとやりました」風に見せかけるダミーのような認証で押し通すか、各社多様であるし、しかも別にすべてを社長が一人でやっているわけではなく、トップランクの社員が工場で作っているわけでもなく、委託先の管理が本当にきっちりできているか怪しいことがある。

加えて「ちゃんとやっています」という気持ちで未知のトラブルがあるというケースはなくならない。普通の検品をしていました、健康食品の枠では大丈夫と考えてます。3相試験？もちろんコストばかりかかるのでやりません。実は大規模調査するとまずい副作用がありました。ごめんなさい。

あるニュースでの街角コメントで「出すからにはちゃんとやって欲しい」という消費者のコメントがあった。生産者を擁護する気持ちはまるでないのだが、同じ消費者という目線からしても「どこまで？」がないこの手のコメントに、私は警戒感を保つ。この手のコメントがまかり通る界隈は「どう達成するか」に対する感覚がなく、感覚がないなりの敬意も実はおそらくない。

「ぼんやり生きています」という人をそこそこ守るための座組を世の中は整えようとしてきた感覚がある。ただ、そういう人を常に厚く守りきれる社会ではない。まず生産者を激詰めする部分については生暖かく見守りつつも、それを受け入れる消費者という観点での自己防御の健全な多重化、凡庸な「良い」に付随する想定されない副作用に対する予備防御は息をするようにしたいし、その防御は衰退するような社会ならそれぞれ強くしていかなければならない。

non-premptiveを前提にするならマイコンにいくよもぅ、みたいな雑なやつ

asyncioをPython周りで調べていたときに「select on steroidっつーことだよねこれ……」みたいな妙な幻滅があった。

でもC10K考えると仕方ない（場合もある）発想だなと。要は汎用OSというのは言うほどサーバサイドの哲学に合わないというか。実際、マルチユーザでOSが見えるもの使う機会ってあんまり今では一般的じゃない。

仮想メモリの文脈で今「強い」のは「メモリが無限に見える」ことじゃなくて「守られている」ことだし、時分割が本当に役に立つのは人間が複数人ログインしているのを気づかないことじゃなくてデバイスドライバがたまに処理を必要とするので専有ダメよ、ということなんかもね、なんて思ったりした。

例えば競プロをやるとか、あるいは「300msのジッターが30ms未満であってほしい」みたいなときにOSって過剰なのかもな、なんて思ったりする。asyncioでプログラムを書かせてメンタルモデル的にシングルスレッド（ただし大量のパケット処理はやられている）みたいな状況はOS研究の初期の時分割の話と事情が違う、という気はする。自分のPCについてエンドユーザは自分一人だけなので、優先して欲しい事柄は複数人が希少リソースを共有しているときと、根っこの意味では全く異なる。

ふとマイコンを触れていると、例えばWi-Fiモジュールがよろしく通信部分をやってくれるっつーときに「まぁ、これがむしろ自然か」などと妥協する部分がある。ソフトウェアライブラリをよくインストールするけど、正直ハードウェアもそのノリで良い瞬間あるよね、と。

マイコンとOS乗るCPUの根源的な差異についてLLMに聞いてみたら、まぁわからんでもない回答が来た（例えば電力効率）のもあって、そのあたり地味に理解を再構築しても良いんだろうかね、なんて思ったりしている。

殊「計算機」ということを考えるのであれば、OSはこの手の議論の本質からちょっとずれる議論や実務が多いからなぁ。例えばタイマー割り込みあればキャッシュはその分汚れるのだけど、マイコンにある割り込みで起こる汚れはやりたい単一のことに対して本質的で、OSを介した時分割マルチタスクにとっては（隣の他人事なので）、幾分ワークロード本体から見ると本質じゃない、みたいな。

よくわからんけど書いといた。

（追記）とはいえくっそ面倒なのはUnicodeで、Unicodeの豊かな思想はOSありきでまるっと全部を食い散らかす発想じゃないとちょっと重たすぎて無理だよなぁ、なんてことも思ったりする。

クラウドに盛り上がらなくなった

あ、FF7じゃないです。

10年弱ほど前に恐れていたのは「飯を食うために這い回った結果として自分が時代に遅れてしまう」的な話で、具体的にはAWSとかのノウハウが獲得できないまま過ごすとかそういうことだった。

関連して、その数年後には加えて、いわゆる「AIブーム」みたいなのの初期の話も心配材料になった。数学に対する無限の苦手意識が先行していた時期。クラウドの話はなんだかんだで自分でなんとか調べる……という話はあったもののデータに関しては難しいところがある。何より私にはあんまりセンスというか、そういうのを先んじて取得しに行くセンスがない。仕事でやるのが一番なのだ。

ちなみに当時の心配はもう一つあって（こっちのほうが大きかった気がするんだけど）、人が多数いる環境でのマネジメントの経験がつかないんでは、という話だった。少人数であれば当時ちょっといろいろトラブルを処理していたのもあって分かってきたんだけど、せいぜいが「個人事業主プラス」みたいなレベルではあって、もともと描いていた「組織を見る」という観点での経験は十分積めそうな感じじゃなかった。

というわけで割と恐る恐る転職活動をするなどして今に至るん。幸い、概ね上の話は全部心配ごとじゃなくなっている。あくまで後ろ向きに見るなら、納得感のある試行錯誤とミスと成果が溜まってきている。

うん、ただ、そういう流れの中で、例えば「ローコード」だのと風潮してはずっこける変な連中は一旦脇に置いとくとしても、Webを中心とした「アプリ開発」の低俗化……みたいのは何か看過できないなぁ、みたいな気持ちが出てきた。

専門的な分野で難しい話があるのを知らない、わけではない。ただLinuxはLinuxとして安定しているので、普通のB2Bで特別な工夫というのは要らない。AuroraすごいしCloud Run Jobsは便利なのよ。

そのあたりのソフトウェア開発において今何が問題になるかというと、概ね理解の浅い関係者と油断が激しいデベロッパが空転しており、納期に対するバランスを欠いているだけに見える。この事象自体は大変興味深いし、そういうのを眺めてあーだこーだするのはぶっちゃけ好きだ。

ただ、道具として使うソフトウェアツール群について言えば、同じようなことを本当に何度も繰り返してはロースキルの人に使わせるというチャレンジをし続けた結果として、技術の可能性を削ぎ落として凡庸なサイクルを組むための「ソリューション」の蓄積になってきた感じがある。先日アーキテクチャ図を見せてもらって「これ、どうでしょうか」と聞かれたんだけど、「そのアーキテクチャ図で盛り上がるソフト開発ってもう流石になくない？人生でまたこんなんやりたい？」なんて思っちゃった。「十分枯れた設計で構成されていますし、特段のリスクは感じませんよ」という感じで大人の返答をしたんだけど。

（じゃぁそういう「枯れた」世界でどうして問題が起きるかというと、例えばIaC, Cloud Formationとか一切考慮する脳みそはなくて、基礎的な設計はともかくライブラリがオワコンでツギハギで変更管理もない中で要件が途中で変わって記録が残ってないから1年後になんでそうしたのかも、どうやれば最新の構成を検証環境に作り込めるのか誰もわからんでどっかーん、みたいな事象なんじゃないかなと思うわけである。なんも新しいところないね）

「ノーコード」「ローコード」はそれ自体は、「技術の可能性を殺す」「やがて管理不能になる負債を背負う」といった副作用を受け入れれば一瞬は動作するし、その一瞬で自分が担当からはずれれば「成功」に見えるはずなのであった。つまりあるとても皮肉な言い方をすれば「成功している」とも言える。ただ、それは単純に馬鹿らしいことでもある。「単細胞な要件定義に終止する」「しかもしばらくして壊れる」ソフトウェアで成功なんである。アホかいな。まるで飛行機のドアに強度未検証な3Dプリンタの部品を使うようなもんである。ドア吹っ飛んで死者出るよ？……あいにくITにおいては止める人もいないのであった。

そういう進展は進展しているようでしていない。問題が矮小化している。それに対する「ソリューション」もある意味では矮小化している。使いやすい。ええと、なんとなく触れる限りではいいんじゃないかな……（なんかつまらんな）。

健全・適切な抽象化レベルに落ち着いたソフトウェアスタックというのもあってすべてがすべて上のようなバチクソ皮肉めいた進展を続けてきたわけではないんだけど（XMLの方がJSONより良いなんて言うつもりはないんだ）、少なくとも

• 10年弱ほど前に恐れていた事態は経験を積む機会に恵まれ回避された
• むしろ恐れていた対象が地盤沈下もして、恐れすぎると逆に自分を矮小化させてしまうリスクに見えてきた

という両方向からのアプローチで「別の大きな課題設定を人生で持っておく方が良いよね」なんて思う時期となってきた。

前者はどっかで前にも書いたか話したんだけど（とってもポジティブな話なのよ）、後者は油断すると「やーい老人！」と言われるタイプの考え方でもあって、良い表現の仕方も評価の仕方も自信のほども分かっておらず、なんとなく表現するのもブレーキかけぎみだった。今回なんとなく勢いで書いておくことにした。

ぶっちゃけると、私からすると「道具として以外のソフトウェアはもう勝手にやって欲しいかも」「別の道具と深く組み合わせたいかも」という感じに意識がシフトしている気がする。

Reactの最新バージョンに頭を悩ませるのも新しいMLパイプライン用の製品のバグに頭抱えるのもHogeSQL互換だけど挙動がピーキーな「スケール」するDBの値段にウンウン唸るのも何か本筋に見えないわけよ。B2Cで世界規模の課題（私はもう興味がない領域）でなければ、もう他のコンパクトな製品で出来てるでしょ、みたいな白けがある。世界一の計算機、というのも、うーんnv◯diaの暴走を止めてよ、と思っちゃう。

目下、数学と統計と会計と経営とで頭の領域を占めたい部分があって、そこにはソフトウェア「で」良くする領域が山程あるし、先日チラ見した「業種別審査辞典」に出てくるような各種の業界をソフトウェア「で」良くする方が何か面白そうなんよ。数百万でちっこい会社買収してニョキニョキするほうがなんか面白そうなんよ（無限に面倒くさそうなのでMBTIのI傾向がものすごい私は多分やらないけど）

思っていることが実は老人の喚きなのでは……なんていう恐ろしさはやっぱりあって、なんとか電子のお店にゾンビのように通ってると「これってある種のフレイルじゃねぇかな」とか思わないでもないんだけど、とりあえずはまぁ盛り上がる領域が変わった、ということで書くだけ書いておく。

そしてArduino（って抽象）を成立させたのすごいよなぁ、とかどうでも良いことを思う。すごいことは見えづらい。