中央銀行デジタル通貨（CBDC）はそんな単純な話しではない
一つ前のエントリで、
海外では、「電子マネー＝デジタル通貨」であって、今は、今後ビットコインを代表とする暗号通貨をどう取り込んでいくか、CBDC（中央銀行発行デジタル通貨）をどうするか、といった話題がホットトピックなのです。
と書いたように、英語圏では、特にWall Street Journal や Bloombergと言った経済紙だけではなく、一般紙のニュースにも上記の話題が頻繁に登場します。日本のように「PayPay、楽天ペイ、LINE Pay」といった企業の目くらましの広告宣伝に汚染されたりしていない、という事です。
もちろん、英語圏でも、伝統的な金融・経済界や金融当局側からすると、暗号通貨と言ったデジタル通貨は脅威であって、ビットコインなど潰したい、という意向が働きネガティブに報道するという力学が作用している事は確かです。
本来、米国は、国際準備通貨としてのドルという地位を維持したいが為に、ビットコインなどの暗号通貨は邪魔な存在でしかありません。金融界としても、元来の金融とはまったく異なる次元で動く暗号通貨というものは歓迎すべからぬものだったのです。なので、伝統的な金融・経済界や金融当局側からネガティブな反応が出るのです。Facebookの計画したLibraという暗号通貨を米国政府が潰したのもそれが原因です。最近でもトランプ大統領が「（ビットコインなどの暗号通貨は）ドルと競合する。好きじゃないね」などと発言してます。
しかし、現実は、暗号通貨を無視する事も潰す事も出来ない事は明らかで、米国としても、無視したままでやられるよりは、逆に活用するか、積極的に何か対抗していくべきなのでは、という方向の議論がこの1年で増えてきて、趨勢が変化してきた感じがします。
一番の理由は何か、というと、やはり中国です。中国はビットコインのような国家によるコントロールが効かない非中央集権的な分散型の暗号通貨を禁止して排除し、「デジタル人民元」という国家が発行して管理統制するデジタル通貨を普及させようとしています。これが、現在のドル体制にとって、明確な脅威と受け取られているのです。
「デジタル人民元」は、CBDC、つまり中央銀行発行デジタル通貨の一つで、暗号通貨とは明確に異なり、国家（の中央銀行）が中央集権的に管理・発行するものです。もし、このデジタル人民元が、ビットコインのように国境をまたいで簡単に取引できるようになって普及してしまうと、ドルの地位が根本から揺らいでしまいます。米国の影響下にある国際決済システムのSWIFTも同様です。米国が行ってきた金融制裁という方法も、効果が激減するでしょう。
では、ドルも対抗して、今まで見下していたビットコインや中国のデジタル人民元のように、デジタル化すべきなのか・・・それともこのまま指をくわえてデジタル人民元が浸食してくるのを許すのか・・・これが現在の米国にとっての難しい悩みであるわけです。米国では、デジタル通貨はれっきとした国家の安全保障問題なのです。
本来、米国は伝統的に国家の管理は最小限にし、民間資本に任せる、というのが主義です。なので、CBDCなどで既存の体制を変更したり、デジタル化で管理統制を強化するような事は本来であれば、米国らしくない事です。しかし、ドルの地位を脅かすという事は、米国の主権に関わってくる話しで、前述した安全保障問題でもあります。こうなると米国はどう出るか分かりません。
米国にとってさらに悩ましいのは、エルサルバドルのような国がビットコインを法定通貨として扱い始めた、ということもあります。元々南米の国々は、米国に「裏庭」扱いで、様々な形で干渉を受けて来たという歴史的な経緯から、米国の影響下から脱却するのがウケるという傾向があります。で、反米的でナショナリスティックなベネズエラのような社会主義の左派政権がいくつも出現して結果、通貨が暴落するなんて状況。なので、南米は「脱ドル、入デジタル通貨」する下地があると言えます。ますます米国にCBDCを検討する圧力がかかります。（またはエルサルバドルのような国に圧力を加えて止めさせようとする）
そんなニュースがありながら、はてブのコメントでは、
日本政府、ビットコインを外国通貨と認めず エルサルバドルの法定通貨化受けビットコインはネットワークビジネスの商材に過ぎない。いかなる意味でも通貨では無いのだから、認めないのは当然。
2021/07/02 08:22
などといった、自分の視野２メートル範囲の観察でしか物事を判断しない人がいるのが残念です。そもそも「通貨とは何か」、「通貨の価値とは」という点を勉強して欲しいなぁ、と思います。この点、以前書きました。
さて、本題の、「デジタル日本円」についてなのですが、日銀の対応はというと、以前より「念のため、研究と実証実験を行うものとする」という、前向きなのかなんなのか分からない姿勢のまま変化がありません。結局、日本が良くやる、様子見、右に倣え、ってやつでしょう。
でも、日本もさっさとCBDC、つまり中央銀行発行デジタル通貨を発行すればよい、というつもりもありません。
CBDCはその定義上、その名前の通り、国家の中央銀行が直接発行して管理するデジタルなものです。という事はつまり、すべてのお金の動きを国家が簡単に把握できる、という事でもあるのです。まぁ、具体的にCBDCがどのように実装されるか不明な段階ではっきりした事は言いようがないのですが、デジタルでやる以上、明示的に何らかの足かせを掛けない限り、出来てしまう事に変わりがありません。
例えは嫌いなのですが、使用者から見たCBDCは、国が自らデビットカードの運用と管理をやって、強制力をもって通用させる、みたいな話しでしょうか。
利点としては、脱税や違法取引を取り締まり易くなる、という事でしょう。現金は匿名ですが、CBDCのデジタル通貨だと簡単に足が付きます。
欠点としては、国民の監視やコントロールに使いやすい、という事です。CBDCだと、何をいつどこで買ったか、という履歴が全て簡単に個人と紐づく事になります。個人のお金を政府がボタン一つで凍結したり0円にする事も、技術的には出来ます。中国のような独裁的な権威主義国家が、CBDCをどういう目的で使おうとしているか、考えるだけでウンザリします。
また、中央集権的に管理するとなると、セキュリティ的にリスクが高くなります。
なので、個人的にもろ手を挙げて推進するべき、とは言い難いと思っています。よく、「中国が先行しているCBDC・・・」などというセリフを見かけますが、上記の点にまったく触れておらず、片手落ち、というか、無責任な表現だと思います。中国がCBDCを推し進める理由は、国内向けの監視統制強化、海外向けのドル体制への挑戦という2重の意味というか目的があると思っています。これについて、「先行」しているので追い付くべき、という文脈だけで語るものではないと思うのです。
さて、日本でこういう事を公に議論していたりメディアで取り上げている所はあるのでしょうか。そこが物凄く不安であります。日本のメディアを初め、日本社会では、米国の後追いして真似すればよい、程度で思考停止している感じがします。そもそも、日本のメディアを含め一般が「決済手段と通貨を混同している」レベルでしっかりと整理もせずにいて、10年先の国家戦略なんて議論出来ないと思うんですよね。
因みに、個人的には、もし現状を維持したいなら米国をはじめとして各国がまとまってルールを定め、なんだかんだ理由を付けてデジタル人民元を排除する仕組みを作るしか方法は無いと思います。しかし、今の欧米に対中共同歩調を取れる余裕と覚悟があるかどうかは疑問です。
極論すれば、ドルに代わってデジタル人民元が覇権を取るくらいなら、ビットコインが世界の基軸通貨になるべき、とぐらいに考えてます。
いずれにせよ、中国がCBDCを推し進めている以上、各国も何らかの対応を迫られるという事です。その時に、民間で何にも議論をしていない日本は大丈夫なのか、という事です。
追記：
ロイターで日銀の動向が記事になってました。（因みに日本の共同通信や時事通信でもなくロイター通信発という点に注目。日本のメディアさぁ・・・orz。）
中国がデジタル人民元の大規模な実証実験を行うなど開発を進めている。村井氏は「価値観を同じくする国同士で共通の基盤をもち、相互運用性が高い標準技術を確立しなければならない」と発言。「隣の大国に標準技術を握られないというようにする、そういう大きな視野も必要」と述べた。
まぁ、そうなるでしょうねぇ。結局、欧米と共同歩調という・・・。中国にデファクトスタンダードとられるのもマズイのも確か。
日本円はスイスフランとともに安全通貨の地位を保っているものの、人民元の存在が大きくなってくればその地位が脅かされ、日本経済が混乱することもあり得ると懸念を表明。
「デジタル人民元がものすごく使い勝手のいいものになり、海外の人たちが旅行で使ったり、商取引や貿易でメーンの決済通貨になってきたりすると、円と人民元の関係が変わってきてしまう。資本政策など通貨の国際化にはデジタル以外の要素も当然影響してくるが、デジタル人民元に利用が大きく流れていってしまうと危ない」とも述べた。
これも、その通りでしょう。
村井氏は、民間デジタル通貨やステーブルコイン（法定通貨を裏付け資産とする仮想通貨）に関し、現在の国際社会が主権国家を中心とした経済・社会システムになっている以上、国家の通貨主権を脅かすような存在については「一定の規制が必要だろう」と見解を示した。
「日本であれば、日本人の命と生活を守る責任を国が負い、それに伴い通貨主権を行使している。このため通貨主権はその国の経済のありように直結してくる。それを脅かす存在には注意が必要」と述べた。
これはどうなのか。EUなんて単一通貨で「通貨主権」は国単位では持って無いし（だからドイツとギリシャとかの間でゴタゴタが起きる）、エルサルバドルなんて、法定通貨はドルだけだった訳で、そもそも「通貨主権」なんて持っていない国もある。日本や米国などの自国通貨が既に一定の立場を確立している国から見た視点でしか無いのでは、と思ったり。もちろん、一定の規制は必要でしょうし、日本円の立場は絶対に守っていかなければなりません。
ただ、ドルや円といった国際通貨を持っている「先行者利益」のようなものを維持したい既得権益者が保身を図って旧態にしがみつきイノベーションを阻害して、結果として、新しい技術を使う新参者に全てをひっくり返される、なんて歴史上何度も起きて来たことにならないようにはして欲しいものです。
追記２：近いうちに、Facebookが新たにドルを裏打ちにした、いわゆるステーブルコインのディエムという暗号通貨を発行する話しがあります。Facebookが以前計画していた旧リブラは、複数通貨をバスケットで裏打ちするという暗号通貨でしたが、ドルに対する脅威という事で当局の反対にあって潰されました。自分は当時、ザッカーバーグの議会証言とかもYoutubeで観てました。しかし、この新しいディエムはドルに裏打ち・連動されたステーブルコインという事で、米当局からもヨシヨシと受け入れられている感じです。
つまり、米国は、CBDCを自ら手掛けるよりか、米国らしく民間にCBDCの代わりとなるものをやらせようとしているのかもしれません。Facebookのような世界的に影響力のある企業を持っているのですから、それを利用するのは手です。ザッカーバーグ自身もそう議会で証言していたのが印象に残っています。
日本だと・・・GMOあたりが日本円ステーブルコイン発行していたかな・・・。
日本の「電子マネー」というデジタル後進性
前のエントリでチラっと触れた、日本における「電子マネー」という言葉について、改めて書いておきたいと思います。
そもそも、日本では、単なる「電子的に支払い（決済）」するという手段の話しを「電子マネー」と呼んでしまったりするのでさらに混乱します。手段を通貨と混同してしまっているのです。電子マネーと言ってもあくまでも法定通貨である普通の円を使っている事に変わりありません。
英語で「電子マネー：electronic money」なんて表現は普段使いませんし、electronic money と言ったら、ビットコインという暗号通貨が登場する以前の、「Ecash」とか「DigiCash」とかの、（ドルでも円でもない）デジタル通貨の事を連想します。
実際、英語版の本家ウィキペディアで、デジタル通貨の項を見ると、「Digital currency (digital money, electronic money or electronic currency)」とあって、「デジタル通貨」も「デジタルマネー」も「電子マネー」も「電子通貨」もすべて同義語扱いです。つまり全部同じ事を意味します。対して日本では、そして日本版のウィキペディアでは、デジタル通貨、と電子マネーは、別の項に分けられていてそれぞれ別の意味があります（しかも「電子マネーは...支払手段の一種...ただし、定義は必ずしも一様ではない」とか書いてある）。（＜ウィキペディアを少し修正しておきました。）
そう、日本では決済手段と通貨を混同してしまっているのです。英語圏で「デジタル通貨・電子マネー」と言えば、現代ではビットコインを代表とする暗号通貨やCBDCの事を意味します。
昨今、「日本では電子マネーやキャッシュレスの普及が遅れている」なんていう言説が盛んに言われていますが、何を言っているのやら、と。まず第一にそもそも言葉の定義が違うのに比較も何も出来ないだろうに、と思う訳です。
英語圏などでは、クレジットカードやデビットカード決済で広く電子決済が行われてきました（普通に小切手も同じぐらい使われている）。そのせいで、消費を煽るばかりの、借金漬けで、クレジットヒストリーを常に気にするような社会ってのも大きな問題です。寧ろ、そういうのを警戒してきた日本人は賢かったとも言えます。偽札や強盗を心配するような治安問題なんて海外では日常茶飯事ですが、日本ではごくごく少ないですし。
一方日本では、交通系のSuicaやPasmo、コンビニ系のnanacoなど、むしろ乱立気味に普及しています。QRコードで支払いしている中国すごい？なんてニュース、オカシイです。
「日本では電子マネーやキャッシュレスの普及が遅れている」という言説は、大抵、「日本ではクレジットカード払いの需要が少なかった」、というだけの事に過ぎません。（あと、大規模チェーン店が支配的な米国と異なり、個人商店が生き残っていけた日本）
対して、最近の日本におけるIT系企業による大規模なキャンペーンによって、「PayPay、楽天ペイ、LINE Payを使ってキャッシュレスの電子マネー（キャピ）」というのは、あくまでもユーザーを囲みこみたいだけの企業の広告の宣伝文句に過ぎず、ポイント還元などを組み合わせただけの囲い込み商法で、何一つ新しい事はありません。寧ろ、ベンダーロックインのように、特定企業に囲い込まれるという弊害だけがあります。
日本が遅れているのは、そういう企業の宣伝文句に騙されて、「PayPay、楽天ペイ、LINE Pay」みたいなのを使って「きゃしゅれすの電子マネー」と勘違いして「進んでいる」と誤解してしまう事です。世界から見れば、そんなのクレジットカードやデビットカードで何十年も前から同じ事が出来てたんですけど・・・という話しなのです。
日本で言う「電子マネー」というのは、単に再チャージの出来るプリペイドカードにすぎず、乗車券や自販機で主に使うもの、という認識。スマホで使うなら単に、スマホ決済というだけであります。
海外では、「電子マネー＝デジタル通貨」であって、今は、今後ビットコインを代表とする暗号通貨をどう取り込んでいくか、CBDC（中央銀行発行デジタル通貨）をどうするか、といった話題がホットトピックなのです。
自分は普段、英語のポッドキャストやニュースに浸っているのですが、たまに日本の動向を調べると、非常に悲しくなります。英語では日常的な経済ニュースでは「電子マネー＝デジタル通貨＝ビットコイン等」として、そういう話題が頻繁に登場します。関連するのは米国や中国の動向ばかりで、日本は一切登場しません。
悲しいことです。
追記：たまたまこんな記事が目に入ったのですが、デタラメぶりに目を覆いたくなります。
「仮想通貨」「ドル」「金」「株」、じつは“一番安心できる”のは…？ プロの「意外な答え」（大原 浩） | マネー現代 | 講談社（1/6）
仮想通貨（暗号通貨）、電子マネーなど新しいタイプの「お金」の議論が花盛りだ。この新しいタイプの「お金」は概ね2つに分けられる。
１． 既存の通貨システムとは基本的に切り離されているお金。ビットコインなどの仮想通貨が典型。
２． 既存の通貨システムの上に乗り、そこから派生する形で生まれるお金。ペイペイなどの電子マネーは基本的にこのタイプ。フェイスブックが企画して頓挫したリブラもここに含まれる。
ペイペイとFacebookのリブラが同じタイプ？この大原 浩氏という「プロ」は一体何を言っているのでしょうか。
バスケット方式で裏付ける「暗号通貨」だったリブラと、単なる日本円の電子決済手段に過ぎない日本円そのままの単なる決済サービスであるペイペイを、「同じタイプ」と解説するのは、基本的な勘違いとかいうレベルではなく、日本人を騙す、詐欺的なレベルかと・・・ペイペイからお金でも貰っているのでしょうか。
こういう言説が堂々と「専門家」から垂れ流されている現状は、まさに私が指摘しているように、日本のデジタル後進性を表していますね。
続き：
「仮想通貨」は止めて、「暗号通貨」と表記しよう
日本では、メディア報道も含めて以前はビットコインなどを指して「仮想通貨」と表現するのが一般的でした。
「仮想通貨」という表現をいつだれがどのような文脈で使い始めたのかはとりあえず置いておいて、インターネットで使う「バーチャル」なもの（大抵ネガティブで見下したカノテーションがあります）、という意味合いでしょう。
しかし、資金決済法の改正（令和２年５月１日施行）によって、去年（2020年）から法令上、「仮想通貨」は「暗号資産」へ呼称変更されました。よって、現在、日本の大手メディアでは、「暗号資産（仮想通貨）」というカッコ付きの表記が使われています。
金融の規制や法的な観点からすると、確かに「新たな資産クラス」という意味で、「暗号資産」、という呼び方は正しいと言えます。まぁ、金融当局からすると、「法定通貨との誤解を生みやすい」から「通貨」とは呼びたくない、というのが本音なのかもしれませんが。
ただ、「暗号資産」という呼称は本来のビットコインの特性を正しく表しているとは思えません。また、日常的に呼ぶ呼称としても違和感があります。例えば「円」は「現金・キャッシュ・法定通貨」などと色々な呼び名がありますが、普段使いで「法定通貨」などとは言いません。
じゃ、海外ではどうしているのか、というと、英語圏でも別に「暗号資産: Crypto Assets」という呼び名が一般で使われているという訳ではありません。もちろん「仮想通貨」でもありません。普通に「暗号通貨: Cryptocurrency」です。会話では略して「Crypto」なんて言ったりします。
ビットコインの特性は、「暗号」と「ブロックチェーン」と「コンセンサスアルゴリズム」の３つを組み合わせて使った、非中央集権の分散型マネーシステム、という点です。
そういう特性から、「暗号通貨: Cryptocurrency」が最もビットコインなどの特性を正確に言い表している、と言えます。
「仮想通貨」という呼び名の何が悪い、という事でもないのですが、元々日本では「バーチャル」なものというのは大抵「現実社会では通用しない」、といったニュアンスのネガティブで見下した文脈で使われてきました。
そもそも、日本では、単なる「電子的に支払う」という決済手段の話しを「電子マネー」と呼んでしまったりするのでさらに混乱します。手段を通貨と混同してしまっているのです。電子マネーと言ってもあくまでも法定通貨である円である事に変わりありません。頭が痛くなります。・・・が話しが逸れるので、それはまたの機会に補足（書きました）。
ビットコインは、大きな枠組みでは、デジタル通貨・電子マネーの一種でありますが、その他のデジタル通貨などと区別して、ビットコインを「仮想通貨」と呼ぶのは、それが持つ革新的な特性に限定した分かり易い呼び名とは言えません。「仮想通貨」というのは、いわゆる「ゲーム内通貨」などを含めた、カテゴリーを表す総称なのです。
英語版のWikipediaでCryptocurrencyの項を見てみると、
Not to be confused with Virtual currency.
と、暗号通貨を「仮想通貨と混同しないこと」という但し書きが初めに表示されます。つまり、「暗号通貨」と「仮想通貨」という言葉を明確に区別して定義している事が分かります。
「仮想通貨」と「暗号通貨」の違い、また相互の関係性をもっともよく表した一文があります。
A cryptocurrency is a digital currency using cryptography to secure transactions and to control the creation of new currency units. Since not all virtual currencies use cryptography, not all virtual currencies are cryptocurrencies.
つまり、
暗号通貨は、暗号（Cryptography）を用いて、セキュアな取引と新規の通貨単位生成をコントロールするデジタル通貨の事である。仮想通貨がすべからく暗号を用いているという訳ではないので、仮想通貨がすべて暗号通貨であるとは意味しない。
という事です。
参考までに、英語版のWikipediaの関連する呼称の定義部分をそれぞれ以下に、簡単に訳しておきます。
Digital currency (digital money, electronic money or electronic currency) is any currency, money, or money-like asset that is primarily managed, stored or exchanged on digital computer systems, especially over the internet. Types of digital currencies include cryptocurrency, virtual currency and central bank digital currency.
デジタル通貨（デジタルマネー、電子マネー、電子通貨）とは、通貨、お金、またはお金のような資産全般を指し、主にデジタルコンピュータシステムで特にインターネット越しに管理・保存・交換されるもの。デジタル通貨のタイプとしては、暗号通貨、仮想通貨、中央銀行発行デジタル通貨などが含まれる。
Virtual currency, or virtual money, is a type of unregulated digital currency, which is issued and usually controlled by its developers and used and accepted among the members of a specific virtual community. In 2014, the European Banking Authority defined virtual currency as "a digital representation of value that is neither issued by a central bank or a public authority, nor necessarily attached to a fiat currency, but is accepted by natural or legal persons as a means of payment and can be transferred, stored or traded electronically". By contrast, a digital currency that is issued by a central bank is defined as "central bank digital currency".
仮想通貨（または仮想マネー）とは、規制を受けていないデジタル通貨の一形態であり、開発者により発行され、通常コントロールもされており、特定の仮想コミュニティ内で受け入れられ、使用されているものである。2014年に欧州銀行監督局が「中央銀行や公的機関の発行によるものではない、法定通貨に裏付けのあるとも限らない、がしかし自然人（個人）や法的人格（企業など）に支払い方法として受け入れられ、電子的に移動、保存、取引される電子化されたもの」と定義した。対照的に、中央銀行によって発行された電子通貨は中央銀行発行デジタル通貨（central bank digital currency, CBDC）という。
A cryptocurrency, crypto-currency, or crypto is a digital asset designed to work as a medium of exchange wherein individual coin ownership records are stored in a ledger existing in a form of a computerized database using strong cryptography to secure transaction records, to control the creation of additional coins, and to verify the transfer of coin ownership.[1][2] Cryptocurrency does not exist in physical form (like paper money) and is typically not issued by a central authority. Cryptocurrencies typically use decentralized control as opposed to a central bank digital currency (CBDC).[3] When a cryptocurrency is minted or created prior to issuance or issued by a single issuer, it is generally considered centralized. When implemented with decentralized control, each cryptocurrency works through distributed ledger technology, typically a blockchain, that serves as a public financial transaction database.[4]
Bitcoin, first released as open-source software in 2009, is the first decentralized cryptocurrency.[5] Since the release of bitcoin, many other cryptocurrencies have been created.
暗号通貨とは、交換媒体として機能するよう設計されたデジタル資産の事であり、個々のコインの所有権の記録はコンピューター化されたデータベースという形の台帳に保存され、強力な暗号によって、取引履歴の安全性が保障され、新たなコイン生成がコントロールされ、所有権の移転が確認されるものである。暗号通貨は物理的な形態（紙幣など）を持つものではなく、一般的に中央権者によって発行されるものではない。 典型的な暗号通貨は分散的（非中央集権的）にコントロールされており、中央銀行発行デジタル通貨とは対照的なものである。暗号通貨が生成される時、または発行前の生成時、または特定ユーザーから発行される時、それは一般的に中央集権的とされる。非中央集権的なコントロールが実装された時、個々の暗号通貨は、分散化した台帳技術（通常はブロックチェーン）を通して、パブリックな金融取引データベースとして機能する。
ビットコインは、2009年にオープンソースとしてリリースされたものであるが、これが史上初の非中央集権的な暗号通貨である。ビットコインの公開以来、様々な暗号通貨が生まれている。
日本語版のウィキペディアの関連する項は、情報が古いだけでなく、ごちゃごちゃで整理されていなく、色々な面で破綻してますね・・・。あ～、自分でウィキペディア編集というか英語版から翻訳してみるかなぁ・・・面倒だ。（＜少しウィキペディアを修正しておきました）
続き：
はてなのサービスはBrave対応をしてみたらどうか
自分は、はてなのサービス、特にブックマークを以前より長く使っています。一時離れていてましたが、最近また戻ってきてたクチです。
そんな中、気が付くと、はてな界隈の衰退を嘆くエントリが度々上がってきます（１、２）。たしかに自分もそういう状況に気が付いています。昔はてなにいたIT系の尖がった人達は極端に減り（居ても話題が内向き）、以前よりも特殊な政治的志向を持った人達がはてなにぐっと増えました。そういう新しい人達がはてブでなにか世論誘導を図ろうとしているような感じさえ受けました。
自分は、そういう状況にちょっと違和感を感じて離れていったようなところもあるかもしれません。
また、昔のようにワクワクするような新しいサービスが出てくる時代とは異なるので仕方がないのかもしれませんが、ここ10年ぐらいぱっと見何も変わっていない、というのもユーザーとして寂しい限りです。
そこで、はてな衰退論を唱えるエントリと、その反応を観察してみると、はてなが一皮剥けないのは、はてながユーザー＝書き手＝クリエーターがマネタイズできるようなサポートを出来なかったからだ、という点を指摘する意見が散見されます。noteといった有料化をサポートするサービスやYouTubeなどのプラットフォームと比較すると、確かにはてなで収益化を図ろうとしてもアフィリエイトしか方法はありません。
ただ、お金が第一の目当てになると、コンテンツが歪み、内容が汚染されかねない、という事で嫌厭されることは理解できます。アフィリエイト目的で広告記事だらけ、みたいなのもありますしね。
しかし、何も報酬がなくても続けられるのは一部の奇特な人達だけです。これは、アプリケーションの開発においても言えることです。
とは言え、やはり、モチベーションや継続性を考えると、やはり対価を払うというか、評価をしてもらう、という意味では何かもらえると嬉しい事には変わりはありません。そこで、投げ銭というかTipを払えるようなシステムを公開してくれないかなぁと。
有料アプリを買ったり、サブスクリプションで支払い続ける、というよりか、ちょっとした応援、という気持ちで気に入ったアプリに対して、気持ちの表現としてチップって良いじゃないですか。
上記のエントリでも書きましたが、Braveというブラウザと、新しい広告のありかた、クリエーターの収益方法が登場しました。これは、Webネイティブな「ポイント制」であるBATという暗号通貨をチップとしてクリエーターに対してチップ支払いが出来るというものです。
現在の広告モデルやビジネスモデルと整合性をとりつつ、はてなのサービスで、Braveのモデルも採用できないものでしょうか。Braveブラウザを利用しなくても同じような事が出来るようにするという事です。BATだけでなくMONAにも対応しても良いでしょう。はてなのアカウントが自動的にウォレットになる・・・というのはハードルが高いかもしれませんが（取引所のサービスと連携するだけでも良い）、ここははてなに期待したい所です。
暗号通貨というと怪しい、と言って頭ごなしに否定するような人達もいるでしょうが、そういう人達は何も分かっていない人達なので、無視して構わないと思います。
新しいものを言下に否定する人達は昔から常に居るものです。PCが普及し始めた頃にもそういう人達は居ました。インターネットが登場した際もそういう人達がいました。iPhoneが登場する頃にもいました（日本のIT系メディアでは静電式ではなく感圧式を推し、日本製のガラケーに対して「iPhoneはウケない、なぜなら爪の長い女性は操作できないからだ」といった無理やりなネガキャンが多勢だった）」
早くからインターネットやモバイルに参入して足場を築いてきた人達や企業は、本質的な技術の可能性に気付いて、そういう雑音に惑わされずに突き進んできた訳です。
はてなが次の時代に生き残れるか、ここが正念場ではないでしょうかね。
追記１：
以下のようなサービスが出てきましたね。はてなのブログで出来なかったのがイタい。
追記２：
ふと思い立って、「はてな ブロックチェーン」で検索してみると、はてなのブロックチェーン技術に対する取り組みとかは一切引っかからず、はてなのエンジニアの退職エントリが出て来て、
「仮想通貨」という漠然とした正体不明のものが、エンジニアとして「暗号通貨」という技術的背景を持ったものに見えるようになったのでした。
ここまでで、2009年のマウントゴックス事件のときには 得体の知れないポイント的なものを物好きが取引している というイメージだったビットコインの印象が塗り替えられ、 なるほどビットコイン、面白そうじゃん、と思うようになりました。
という話し。はてな、新しいことにチャレンジしないから、暗号通貨に感度のある若いエンジニアまで流出してしまってますねぇ。もったいない。
因みに、自分も同じころに似たような事に気が付き、ビットコインの革新性に驚いたものです。ただ、自分は文系の非エンジニアで、自分が使いたいから作る、だけのもう若くは無い人なので、暗号通貨の取引ツールなどを作っている＝「WebサーバーのAPI叩いている」だけで満足していますｗ
要件定義という時代遅れの慣習
前エントリで、
これから新しいモノを作ろうという時に、特定のサービスや業務の構成要素と機能（つまりビジネスドメインのビジネスロジック）を隅々まで初めから予見したり、全て理解している開発者なんていません。（業務システムの場合、SEが業務担当者に聞き取りをして要件定義だ、なんて言っていますが、しょせんITに疎い素人で全体像も見えていない担当者が業務内容に疎いSEつまりはその業務分野のド素人に教えるとかいう悪夢）
という文を書いていて改めて思った事ですが、この点、補足しておきたいと思います。
よくある間違い。
要件定義＝システム設計である。
要件定義とは、システム開発を請け負う委託契約上、後々お互いに齟齬が起きないように、予め「どこまで何をどうやるか」を決めておく「契約上の取り決めの一部」に過ぎない、という事です。あくまでも契約上の「予防線」から生まれたものです。
直近では、要件定義をしたのにも関わらず、契約違反で訴訟沙汰になった、などという野村HDの事件もありました。野村HDのケースは担当者側のサボタージュだったとかいう話しもあるので、それはそれでまた別問題でもありますが・・。
恐らくは発注側がそもそも要件を把握できていなかった、と思われる理由で、京都市での基幹システム刷新が2度も失敗するとかいう事態も起きています。こういうも「要件定義＝システム設計」という勘違いから生まれていると思われます。
要件定義とは、請負契約上「どこまで何をどうやるか」を事前に決める話しであって、そんなものを元にシステムを開発設計しても当然のように碌なものが出来ません業務上使いやすいものが出来るとは限りません。なので「契約の仕様通りに作ったので使いにくくても知った事ありません」と言われて終わり、なんていう事になります・・・
システム設計とは、現実のドメインロジックに合わせて設計するもので、開発者自身に、対象となるドメインの業務知識や業務フローに関する幅広い全体的・俯瞰的な知識が必要です。そうでないと、使いやすいものは出来ませんし、そもそも野村HDのように担当者の一存で出来あがる前から滅茶苦茶になったりします。
ではどうするかというと、究極的には、開発者自身がその業務に実際に関わる、または、その分野でシステムを一度作ってみる、という二つの方法しかありません。
にも関わらず、これを、日本のITゼネコンとかが請け負って、プログラミングも出来ないSEとかいう職種を独自に作って「上流工程」だとか「要件定義」とか言って、実際に開発するのは下請け、孫請けの開発者達に丸投げしている構造があります。これじゃまともなものは作れません。すべてのやり取りが素人同士の伝言ゲームとなるので、悪夢以外の何ものでもありません。
NTT系列や国内大手ITベンダー（日立、NEC、富士通）の三社、外資系ITベンダー（IBM、HP、Oracleなど）系列のSIerが大手の顧客を囲い込み、インフラ構築からコンピュータ機器の設置、納入後の運用メンテナンスに至るまでを一括受注して利益を得ており、実際のプログラミングやテスト作業を中小のSIerに丸投げしている状態となっている。
日本とアメリカでは、エンジニアの勤め先から大きく異なっている。日本のエンジニアの多くはIT企業に勤めており、ユーザー企業から依頼を受けて開発を行う。そのため大手企業の運営するサービスであっても、実は全く名前が知られていないような会社が開発したということが起こるのだ。
一方アメリカでは、エンジニアの多くが勤めているのはユーザー企業だ。自社サービスの開発に力を入れており、成功失敗に左右されるというのも先ほど述べた通りである。
この違いは発注者・受注者の関係に大きな影響を及ぼす。アメリカでは発注者・受注者は共に同じ会社の人間だ。コミュニケーションはスムーズに取ることができ、遠慮なく意見交換を行えるだろう。[中略]
柔軟性に欠ける開発手法
日本のソフトウェア産業では開発手法としてウォーターフォール型が一般的だ。1970年に提唱され今なお活用されている手法である。しかし、これもまたやや時代遅れの手法となっている。
この手法は、まず始めに要件定義、それから設計、プログラミング、テストという手順を踏んで納品に至る。なぜ、日本のソフトウェア品質は悪いと言われるのか？https://blogs.techvan.co.jp/quality/quality-bad
しかしながら、大抵の顧客は、最初から自分の欲しいソフトウェアをはっきりと説明できないことが多く、出来上がったソフトウェアを見てから、自分の欲しいものではなかったと気づく。また、近年のビジネスは変化が非常に早く、要求が刻々と変化していく場面でそそれを固定するのは困難である。その影響から、結果的に無駄な作業が発生し、追加の作業によって納期が遅れることが多い。
前述の野村HDのケースでは、ITゼネコンに開発を丸投げし、ITゼネコンは自社で開発するでもないどころか、そもそも出来合いの海外製システムを流用しようとしたとか（よくある話し）。ITゼネコンのパッケージ「ソリューション」なんて、大抵中身は名前を変えただけの海外製。そもそもそんなITゼネコンなんて存在意義はありません。
既製品を使うなら、野村HDが直接海外の開発元から購入するなり、カスタマイズを依頼すればよかった話しです。もし業務フローを既成システム側に合わせられないというのなら、外注するのではなく、自社開発するべきです。デジタルトランスフォーメーション（DX）とはそういうものです。
そもそも、建設業や製造業といったハードウェアの産業構造である日本特有の旧態たるゼネコン体質をそのままITの世界に持ち込んだのが間違いだったのです。
例え出来上がっても、「完成形」の要件イメージ自体が間違っており、実際には使い物にならず、結局また一から作り直し、なんて事になるのがオチです。この手の失敗例は日本の大規模開発でも有名な失敗例は幾つもあります。そもそもハードウェアの製造業とは違い、ソフトウェアに「完成形」など存在しない、という考え方もあるのです。
ITの世界では、ソフトウェアやサービスはベータの段階などで早めにリリースして、フィードバックを得て改良、アップデートしていくのが正攻法であって、一度リリースしたら変更できないいわゆる製造業の製品サイクルとは大きな違いがあるのです。ハードウェアと比較すると、ソフトウェアは「生き物」だ、という言い方も出来ます。
これを根本的に理解できていない為に、自社のシステムをITゼネコンに丸投げしてしまう日本企業の経営陣の問題もあるのでしょう。
「サービスをリリースしたら終わりではなく、リリースしてからが勝負だ」と話した。そのためにも、デジタル化のプロセスについて「アジャイルで小さくつくるように変えていく必要がある。小さくつくってから発展させること、失敗をある程度許容していくこと、時にはやめることも大事だと考えている」（津脇企画官）
https://xtech.nikkei.com/atcl/nxt/column/18/01651/062500011/
コロナ禍と共に、デジタルトランスフォーメーション（DX）だ、なんて話しが出てくると、すわっとばかりにITゼネコンが飛びついてきて、バズワードを散りばめた中身空っぽの売り文句で広告や営業を掛けてきます。本来のDXは、そういうITゼネコン依存から脱却することから始まるのですけれどもね。
日本企業のIT化が進まない理由として挙げられるのが、諸外国とは異なる「日本特有のSI業界の産業構造」だ。国内のIT人材をSIerが一手に抱え、ユーザー企業はそのSIerにITシステムの企画・構築・運用を発注する――。日本ではすっかり常態化したこの産業構造だが、実は海外ではこのようなやり方は必ずしも多くはない。そしてこの産業構造は、過去には有効に働いていた時期もあったが、現在では非効率な面が目立つようになってきている。
日本企業のIT化はなぜ進まないのか――日本特有のSI構造とエンタープライズITの在り方から探ってみると – データのじかん
つまり、本来、発注側が主体的に開発するか、開発経験のある開発者達がその経験を生かしてパッケージ製品的なものを開発し、販売導入サポートをする、といった形が当たり前のやりかたなのだと思います。請負契約時の要件定義というのは、どうしてもの際に、必要悪として存在しているようなものです。
追記：日経が面白い記事を出した。
日本企業におけるIT（情報技術）人材の不足は、平成バブル崩壊後の1990年代に情報システム部門が本体から切り離された影響が大きい。当時「ノウハウ集約」「専門性の向上」といった大義名分で設立された情報子会社の多くは、コスト削減目的のアウトソーシング（外部委託）が実態だった。システムを受託開発する大手の「システムインテグレーター」の下請けからエンジニアを出向で派遣してもらい、依存が強まった。
60～70年代に大型汎用機（メインフレーム）を導入した当時の「電算部」から蓄積してきた「情シス」のノウハウと人材が途絶え、IT投資はシステム業界への丸投げが常態になった。自社業務に都合よく独自仕様で導入したERPは継ぎはぎ改修を繰り返し、設計にかかわったシステム会社しか触れない「ベンダーロックイン」にはまっていく。
この間、欧米では汎用パッケージソフトが広がったが、日本企業は身動きがとれずにいた。経営トップにDXが競争力を左右するという意識が薄く、システム会社もベンダーロックインで稼いでいたからだ。ある大手ソフトウエア会社の経営者は「情報システム担当者は業者との蜜月関係を守ってきただけ。ある種の怠慢があった」と日本企業の不作為を嘆く。
米ガートナーによると、日本企業の売上高に対するIT予算の割合は20年に推定1.0%。北米の3.3%、欧州・中東の2.6%に水をあけられている。しかもIT予算のうち外部委託費の比率が34%と高く、ユーザー企業のシステム内製化が進む北米の20%と比べると丸投げ体質が透ける。
DXの出遅れを取り戻す解のひとつが内製化だ。ホームセンター大手のカインズは19年にデジタル戦略本部を設け、自社エンジニアやデジタルマーケティング担当者を約150人に増やした。店員向けの在庫確認アプリなどを矢継ぎ早に実用化した。米マイクロソフト出身の池照直樹本部長は「80点の出来でもいいからまずスタートさせ、現場の意見を聞いて走りながら改善する」という。
しかし、米国の同業、ホーム・デポは1000人規模でエンジニアを採用するなどケタが違う。同国では情報システムのプロがCIO、CDO（最高デジタル責任者）、CTO（最高技術責任者）といった肩書で業界の垣根を越えて移籍するのが一般的。
バブル崩壊をきっかけに、外部丸投げが始まり。以降、慣れ合いで、ITゼネコンつまり「システムインテグレーター（SIer）」にベンダーロックインされたままきてしまった。
というお寒い状況。
アプリは２度作り直して初めて使い物になる
まともなアプリケーションは１度作っただけでは不十分で、大抵もう２回はフルスクラッチで作り直し（再設計）が必要だ、という話しです。３度目の正直とも言います。
対象
対象となるのは、GUIのあるアプリケーションを一般向けに人様に使ってもらう為に開発する際の話しです。GUI（イベントドリブンの処理があるUI）が絡むと途端に複雑さが増すため、非GUIのライブラリとか単一機能のツールとは事情が異なります。単にリクエスト<->リスポンスしかないWebアプリも対象外です。
自分の場合、アプリはショボアプリ含めるとそこそこの数を作ってきましたが、振り返って考えてみると、今でも使っていて、満足できる仕上がりになったと思えるアプリは、大抵２回はフルスクラッチで作り直し（再設計）をしていました。個人的な経験ですが、ありがちなのではと思います。
前提
なぜなのか、というと、まず前提として、開発者が新しいアプリを作成しようとする際、システムの全ての必須要件と機能なんて初めから全部分かりっこないという事です。（出来合いのアプリやサービスを真似して作るなら大体想定できるけれど、しょせんモノマネは単なるモノマネで終わる）
これから新しいモノを作ろうという時に、特定のサービスや業務の構成要素と機能（つまりビジネスドメインのビジネスロジック）を隅々まで初めから予見したり、全て理解している開発者なんていません。（業務システムの場合、SEが業務担当者に聞き取りをして要件定義だ、なんて言っていますが、しょせんITに疎い素人で全体像も見えていない担当者が業務内容に疎いSEつまりはその業務分野のド素人に教えるとかいう悪夢＞補足エントリ「要件定義という時代遅れの慣習」）（私のように一時別の某業界で実際に働いていた経験のあるような人間は特殊）
アプリ開発では、まず間違いなく、作ってみなければ分からない、という事があるのです。この実際に作ってみて初めて見えてくるもの、というのは貴重な知見となります。
次に、アプリというかソフトウェアの開発では、小さく作って（スモールスタート）、大きく育てる、という原則があります。というのも、初めから全ての機能を全て揃えた「完成形」のソフトウェアを開発してリリースしようとすると、とてもじゃありませんが、形になるまで最低でも何年もかかってしまい、モチベーションもリソースも足りなくなるでしょう。途中で挫折するのが見えています。
例え出来上がっても、「完成形」の要件イメージ自体が間違っており、実際には使い物にならず、結局また一から作り直し、なんて事になるのがオチです。この手の失敗例は日本の大規模開発でも有名な失敗例は幾つもあります。そもそもハードウェアの製造業とは違い、ソフトウェアに「完成形」など存在しない、という考え方もあるのです。
ITの世界では、ソフトウェアやサービスはベータの段階などで早めにリリースして、フィードバックを得て改良、アップデートしていく（いわゆるアジャイル開発）のが正攻法であって、一度リリースしたら変更できないいわゆる製造業の製品サイクルとは大きな違いがあるのです。比較すると、ソフトウェアは「生き物」だ、という言い方も出来ます。
初回のリリース
このような前提があるため、ソフトウェアというものは、一度とりあえず作ってみて、出来たものを実際に動かしながらどんな機能が必要なのか（または不要なのか）を見極めていく、という走りながら行く先を決めるような所があります。実際に使ってもらってユーザーの方々からの反応も大いに参考になります。
なので、とりあえず最小の機能でとりあえず形になったものを公開する、というのは良くあることです。これは、別に不具合だらけの未完成のものをリリースする、という話しではなく、UI設計も含めて一通りカチっと完結したものでなくてはなりません。
これが、初回のリリースとなります。この段階で実際に使ってみて、公開してみて、ユーザーの反応も見るのです。もし、使ってみて、ピンとこなくて実用性も感じられなければ、そのアプリはそれまでです。一言でいうと必要とされていなかった、という事。単発屋で消えていく運命です。
ですから、この初回リリースまでの時点でアプリの内部設計や将来的な計画に力をいれすぎるのもリスクがあり、コストに見合いません。この段階ではとくかくアイデアとスピード重視です。
もし作ったものがそれなりに使われて、必要とされた場合、当然ながらもっと改善したい、という欲求が生まれます。自分が使う上でアレやコレや使いやすく改良したり機能を追加し、ユーザーからの要望を（取捨選択した上で）取り入れていきます。その結果、当初の想定とはまったく異なった用途のアプリに進化していった、なんてこともあるあるです。
第１回目
そうこうしているうちに、アプリのアップデートを重ねる度にとりあえず追加、追加、でソースコードの内容も複雑化していき、付け焼き刃的な対応も増えてきてメンテナンスが難しくなってきます。当初想定していなかった機能が増え、リファクタリングとかではすまない、設計上の問題でソースコードの見通しが悪くなってくるのです。
この頃になって初めて、開発者もアプリのあるべき構成と機能（コアのドメインとドメインロジック）の全体像が見えてくる、と言えるでしょう。
ソフトウェアの内部的な設計というかアーキテクチャーは、付け焼き刃的な対応では変更できません。フルスクラッチで作り直さないとなりません。初めから分かっていればちゃんと設計しますが、前述したように、分からないのが当然なので、仕方がありません。
これで、第１回目の作り直しが発生します。と言っても、内部的な設計をやり直してコアドメインに合わせてスッキリさせるのが目的なので、重要部分のソースコードはコピペでそのまま再利用できます。問題なく動いている処理をわざわざ書き直す必要なんてありませんしバグを産む原因になってしまいます。
全体像が見えてからアーキテクチャーの再設計をする事により、将来的な機能追加やアップデートがしやすくなるのです。また、将来に備えて内部の技術をきちんと体系化して再利用可能にもしていく、という感じです。つまり、作っているアプリに将来性がある、とその価値が認められたことにもなります。
なぜフルスクラッチで書き直すことにしたのか
例えばアーキテクチャの文脈で言えば、素朴なMVCで作られていました。とにかくリリースを早めて検証するタイミングでは最悪の選択肢ではないと思いますし後悔はしていないのですが、年を経て同じ画面内での機能追加・仕様変更が重なるようになってくると、開発スピードの維持が難しくなってきました。データバインディングなどの仕組みもなく、処理を素直?な手続き的に書いていたのもあり、画面の状態数とそれに応じた条件分岐が増えていくほどメンテナンスの難易度も上がってしまっていました。
先述したリニューアルは、デザインの一新や仕様の見直しなどを行う、ある種0からプロダクトを見直す機会でした。既存のコードベースをリファクタしながら少しずつ変更を入れていくアプローチは、こういった状況で難易度の高いテーマです。APIも含めシステムとしての変更が生じることは分かっていたので、結局それなりの割合のコードを書き直す未来は見えていました。
分かるわ～。このケースではMVCからMVVMへのアーキテクチャー変更の話しをしていますが、初めからMVVMパターンで作っていた場合でも、異なるレイヤーの話しですがイベントドリブン寄りからドメインドリブン（ドメインに合わせたモデル）に寄せて再設計したくなるのです。外部のライブラリやAPIやDBとの連携が増えたので、全面的に非同期のマルチスレッドで設計し直し、なんてこともありました。
体力というか大人数で開発出来るリソースがある所は、既存のアプリをメンテナンスしつつ、並行して内部的な再設計とUIのリニューアルを同時にやっちゃうケースもあるかもしれませんが、個人レベルでチマチマ作っている開発体制だと３つを同時並行的に一気にやるのはまず無理です。それに、大きな機能追加などを行う前に、まず先にアーキテクチャーの再設計をして基盤整備をしておきたい所です。
第２回目
という事で最後に、第２回目の作り直しになります。これは大抵、GUIの操作性を含めた全面リニューアルです。第１回目で作り直したのは内部的なソースコードの刷新でしたが、GUIは初回リリースの頃からの継ぎ接ぎを引きずっています。必要となる機能が大体分かって内部の再設計と整理がされ、一通り大きな機能の実装も済んできた頃、改めてGUIも統一感のあるドメインに合わせた使いやすいUIにしたくなるのです。
この際、不要だと思った機能もバッサリ切り捨てる良い機会になります。「完璧とは、付け加えるべきものがなくなった時ではなく、取り去るべきものがなくなった時のこと」、なんて誰かが言っていましたね。KISS（Keep It Simple Stupid!）原則なんて言ったりします。
もともと、UIというのは機能が一通り揃って仕様が固まってからでないと画面設計が難しいのです。機能が１つか２の頃の画面設計と、１０の機能とオプションが沢山ついた時の画面設計・デザインは根本的に異なります。UIデザインはどうしても面倒で一つの正解は無いなので、UIの作りこみはどうしても後回しになりがちです。
しかし、ユーザーがイタンタラクトするのがUIですから、ユーザビリティにも直結する、もっとも重要な部分とも言えます。UIの改善を怠った、またはユーザーを意識していないUI設計だと、せっかくのアプリも使いモノにならない、と判断されても仕方がないのです。理系の開発者が多い中、日本ではそういうUI/UXの面を手抜きしているアプリも多いのが残念な所ですが、そこまでやって初めて形になったと言えるのではないでしょうか。
感想
という事で、２度の作り直しを経て、やっと満足のゆく、一人前のソフトウェアになった、と言える段階に達すると思うのです。これは、どうせ後で作り直すのだから、と、始めは後先考えずにとりあえず形になるようガシガシと汚いコードを書きなぐる、という事の言い訳にもなっています。
あくまで、個人的な経験に基づく感想ですが、実際の所、他ではどうなんでしょうかね。まぁ、超がつく定番アプリは大抵、1度や2度では済まない作り直しをしているとは思います。（Web系でも、例えばTwitterやFacebookは使用言語すら変えて、何度も根本から作り直していますね）
BlazorのWebAssemblyをレンタルサーバーやGitHubのPagesにデプロイしてみた
BlazorのWebAssembly、つまり.NETのC#で作ったアプリがブラウザ内で動いてしまうという変態・・・もとい、驚きの技術がある訳ですが、今まで特にBlazorで作りたいものも無かったので、2019年に正式版がリリースされていたにも関わらず、まだ触っていませんでした。
そこで、今日、ちょっと息抜きにチャレンジしてみました。先ほど、WinUI 3 - Project Reunion 0.8 Previewを試したのですが、強烈に脱力するほどダメだったので、お口直しです。正直、期待しないようにしてましたが、結果としては、色々あったけど、.NETのC#のソースコードがそのままブラウザで動くとか変態すぎて、ニヤニヤが止まりませんでした。特に、自分はここ10年ぐらいWeb系の開発から離れている事もあり、良い気分転換になりました。
Blazorには、サーバーサイドでの実行に依存するBlazor Serverと、クライアントサイドだけで単体動作するBlazor WebAssemblyの二種類があり、クライアント（ブラウザ）だけで動くstandaloneのWebAssemblyも作れるという話し。サーバー版を使うと、MicrosoftのAzureとか、クラウドのサービスにロックインされるのが嫌なので、使いません。（データを保存して操作するような場合は何らかのクラウドのサービスを使ってAPIサーバー側も作らないとなりませんが、既存の公開されてるサードパーティーAPI- 天気予報APIとかブログ投稿APIとか - を使うだけなら問題ない）
クライアントサイドだけで動くstandaloneのWebAssemblyが可能という事は、普通のレンタルサーバーにファイルを置くだけで動作するはずです。
では、試してみようではないか、と。しかし、マイクロソフトの公式にも、様々なサイトにも、静的ファイルを普通のレンタルサーバーにFTPでアップロードしてデプロイする、なんて情報は一切どこにもありません。Visual Studioを使ってAzureにデプロイとかFirebaseにデプロイ、IISサーバーにデプロイ、そんな話しばかりです。みんな、クラウドとかで、サーバーサイドを使う前提なのですね。
まぁBlazorの大きな利点は、クライアント側のフロントエンドとサーバー側のバックエンド実装を、JavaScriptとかを使わずに、同じC#のソースコードで共通化できる、という事ですからまぁ当然ですね。クラス定義とかそのまま使いまわせるとかムネアツ。なので、わざわざstandaloneに切り分けてブラウザで全てを処理させる必要性はオフラインでも動作するようにする以外、あんまりありません。
しかし、私は古い人間なので、昔のように、FTPソフトを使ってCGI/Perlのスクリプトをアップロードしたりするようなのを試したいのです（化石人間）。いや、どうせやるなら、誰もやってない事をやりたいではないですか。
続きを読む