タグ: 海外

原文：”Fintech, a Failure?” by Jake Fuentes

「ソフトウェアは世界を飲み込む」という宣言がされた2010年にはモバイルとクラウドの波がすべて変えてしまうのではないかと思えた。交通やホテルやその他多くの産業をテクノロジーが混乱に落とし込み、シリコンバレーは次の獲物を探していた。ノロマな60兆円の王冠をかぶった怪物。それが銀行業界だった。

　この獲物は十分に熟れて食べごろに見えた。サービスが普及しているにもかかわらずユーザーから非難されている徹底的に老朽化した固定費の高い産業。 更にリーマンショックから回復したばかり。銀行の過ちが大きく経済を後退させたのをみんなが目撃したばかり。時は来た。シリコンバレーは動きはじめ、VCはテクノロジーを使ってファイナンスを変革するスタートアップを追い求めた。そしてフィンテックが生まれた。

　その7年後の現在。SquareとStripeがペイメントでブームを巻き起こし、WealthfrontとBettermentが投資管理に挑戦し、テクノロジー業界はBitcoinに夢中になっている。しかし、アメリカのリテールバンクの領域はそのまま手付かず。むしろ、もともと強力だった伝統的な金融機関はより強力になった。一時期もてはやされたLending ClubとProsperは苦戦している。勝者は確かに存在するが、テクノロジーは本当の意味において銀行に革命を起こさせていない。フィンテックは既存の銀行をぶち壊すのではなくパートナーとなることを選び、VCの投資もより有望な分野に移りつつある。

　ひょっとしたら成功すべきスタートアップは現れてないだけなのかもしれない。それにしても、当時に描かれた夢の2017年と現実の2017年はかなり違う。当時の神託は実現されていない。モバイルペイメント、オール・デジタル・バンキング、新しいクレジット・モデル、真に包括的な金融システムが実現されるだろうと。そのビジョンが完全に荒れ果てているわけではないものの、なぜ期待されたディスラプションを(まだ)起こせないのか考察する価値はある。

預金口座とパーソナルファイナンス：サプリ問題

評価: F (もちろん主観的なもの)

　まず自分の会社からはじめよう：Level Moneyは予算管理アプリとしてはじまった。ユーザーが自分のお金を「大人のおこづかい」として簡単に管理できる。Level Moneyは銀行の新しいフロントエンドとして使用できると考えた。シンプルなUIを維持しながら、金融商品をアプリケーションに組み込んでいった。そして次世代の銀行を作る上で「これはサプリなのか？クスリなのか？」という根幹的な問題にぶち当たった。自分たちは病気を治すクスリを作ってるんだと納得させようとしたが、実際に作っていたのはサプリだった。サプリは毎日のめば長期的なメリットがあるけど、クスリみたいに病気のときにすぐに必要なものじゃない。

　銀行はたしかに好かれてなかった。それでもSimple、Moven、Digit、Check、Level Moneyといったのアプリはサプリ問題に繰り返し繰り返しぶち当たった。ユーザーは銀行を変えたいという潜在的な願望を持っているかもしれない。でも、それを明日に延ばしても死ぬわけじゃない。ファイナンスの透明性を望んでいるかもしれないけど、現状を維持することが最大の抵抗だったりもする。解決策を売り込むために問題があるんだと説得しなければいけないなら、それはすでに負け戦と言える。

　いまのところ、この分野で成功したスタートアップはまだない。数多くのスタートアップだけでなくPayPalですら挑戦したにもかかわらず。

ローン：ファストワールドのスローマネー

評価：C

　銀行はどっちにしても口座でお金を稼ぐわけではない。ローンのために口座であえて損をしている。ローンは銀行の儲けの源泉であり、新しいデータソースを使った貸出には大きな改善が期待できそうだった。そこでLending Club、Prosper、SoFi、Affirmなど多くのスタートアップが参入した。

　私たちが後に学んだように、この分野のスタートアップが直面する基本的な課題は時間。新しいプレイヤーにとって競争上の優位性は悪い貸付と良い貸付を見分けられること。それは貸したお金が数年後にちゃんと返済されないと証明できない。そして、モデルが証明されるまでは、急速に成長しないように注意しなければならない。これは爆発的成長とそれに伴う利益に慣れたVCやスタートアップ業界にとってイライラすることだ。

　さらに、信用はマクロ経済の信用サイクルに大きく依存する。私たちは何年もの間、信用の高い環境にいて、この分野にとってそれはいいことだった。でも、市場が変われば、それはまったく別の話。

ペイメント：ぶっちゃけカードで困ってない

評価：B-

　ペイメント領域には特筆すべきいくつかの明るいスポットがある：Square、Stripe、Venmoは大きな波を作った。業界はSquareのモバイルでのカード支払いを、VenmoのP2Pを慌てて滑稽な形で真似をした。

　しかし、祝福をする前にペイメント領域がそもそも抱いていた野心を思い出そう。金融サービスのすべての分野のうち、モバイルデバイスがペイメントを支配はずだった。モバイルペイメントは（それが涙で終わるまでは）明るい未来だった。数え切れないほどのスタートアップがハイプに乗っかって激しくクラッシュした（Clinkleを覚えている？）。 Googleウォレットが何回も再起動して、そのたびに失敗した。アップル – あの全能のアップル！ – ですらモバイルペイメントの広がりを加速させていない。ペイメントには多くの進歩があったけど、フィンテック時代の神託を実現するには至っていない。

　大小にかかわらず多くの企業がモバイルペイメントに挑戦したが、イライラするほど変化がなかった。理由はシンプルで、やっぱりサプリ問題。電子決済は現金よりも優れている。ただモバイルデバイスでの決済はカードをスワイプするよりも大きく優れているわけではない。SquareとStripeはお店がカードを受け入れやすくした。Venmoは人から人への支払いでも同じことをした。でも、Googleウォレット使ってTargetで5％安く買い物ができる程度では染み付いた習慣を変えることはできない。人は技術が新しいとか、洒落ているとか、哲学的に優れているから新しい技術を使わない。あとから考えてみれば当たり前なんだけど、いつもそれを忘れてしまう。

投資管理：ロボアドバイザーの時代

評価：B+

　フィンテックの中でも目立つ動きがあるのが投資管理。Wealthfrontが2008年に設立され、投資領域は根本的に違って見えるようになった。ロボ・アドバイザーは高い報酬の割にパフォーマンスの低いファンドマネジャーに宣戦布告をして、上場投資信託が支配していたパッシブ・マネジメントに波を起こした。同時に、Robinhoodは取引手数料に攻撃を仕掛けた。Robinfoodは300万人のユーザーを獲得している（E*Tradeは360万人）。

　それでも、ロボ・アドバイザーは米国で182億ドルの資産を管理しているに過ぎない。大きな額であるものの、20兆ドルの個人投資家の総資産からするとまだ少ない。 変化には常に時間がかかる。ファイナンスの世界はさらに足が遅い。たとえロボ・アドバイザーが市場を拡大しても、底辺への競争の価格体系は長期的な収益性の問題となるかもしれない。しかし、少なくとも部分的には強力なテクノロジーからの挑戦で伝統的な業界に本当の変化が起きていることは確か。

　テクノロジーは金融サービスを諦めたわけではない。ただFintechに対するVCの投資は冷え込んでいる。確立されたCredit Karmaのような企業は新しい分野に進出しており、Aspiration、Upstart、Erninのような新しい企業にも期待は持てそうだ。ただ、これからの足が重くなるであろうこともこれからの経験から学ばないといけない。本当にローンのような分野に一撃を与えたいならVCドルは苦手なことをしなければいけない：待つこと。市場はモデルを証明するのに十分に長い時間をかけて重い足取りを進む起業家を支援する必要がある（ローンに関してはMax Levchinがその人だろう）。

　世界がクリプトカレンシーやその他の技術に注目するにつれ、初期のフィンテックから学ばなければいけない。いいカナヅチを持っていると全てがクギに見えてくる。わずか数年前、そのカナヅチはクラウドコンピューティングとモバイルデバイスだった。そしてそれは一巡した。みんな次の獲物を探している。次の波を見逃したくないから、シリコンバレーは「こいつは全てを変えちまう」という物語に乗っかってしまいがち。でも、時自分たちは間違っていることが多いということを忘れてはいけない。現状を変えるために必要があるのか製品の良さを割り引いて考えないといけない。素晴らしい成功を祝うだけでなく、なんで間違ってしまったのか。次のハイプに乗る前に。

関連記事

 

原文：”Blockchain Infrastructure Landscape: A First Principles Framing” by Trent McConaghy, July 15, 2017

分散アプリにおけるストレージ、コンピューティングおよびコミュニケーションを明らかにする

　Ethereum、IPFS/Filecoin、BigchainDBはどのように補完しあっているのでしょうか？Golem、Polkadot、Interledgerは？このような質問をよく受けます。だから、私はこれらの質問に答えてみることにしました。

簡単な答え：魔法のようにすべてを行う「ブロックチェーン」という魔法のシステムはありません。分散化アプリケーションを効率的に開発するために組み合わせて利用できる優れたビルディングブロックならあります。Ethereumはその役割があり、BigchainDBも役割があり、それ以外にも多くの技術がビルディングブロックを形作っています。それを今から見ていきましょう。

背景

　コンピューター処理の要素は、ストレージ、コンピューティングとコミュニケーションの三つです。メインフレーム、PC、モバイル、クラウドは共通してこれらの要素を独自の方法で実現しています。特殊なビルディングブロックがこれらの要素のトレードオフを補完する形で生まれることもあります。

　たとえば、ストレージ要素にはファイルシステムとデータベースがあります。ファイルシステムはディレクトリーとファイルの階層にmp3のようなブロブを格納するためのものです。データベースは構造化メタデータを格納するためのものでSQL*1のようなクエリインタフェースを備えています。集中型のクラウドに置き換えて考えると、ブロブストレージにAmazon S3、データベースはMongoDB Atlas、プロセッシングはAmazon EC2に相当します。

　この記事ではコンピューター処理の各要素のブロックとシステムの例を中心にブロックチェーンの視点で説明します。

ブロックチェーンのビルディングブロック

以下がそれぞれの要素と関連する分散化のビルディングブロックです：

• ストレージ：トークンストレージ、データベース、ファイルシステム/ブロブ
• ブロセッシング：ステートフル／ステートレスなビジネスロジック、ハイパフォーマンスコンピューティング
• コミュニケーション：データ、バリュー、ステートのネットワークを繋げる

ブロックチェーンのインフラにおけるランドスケープ

　ブロックチェーン技術は以下のようにコンピューター処理の要素にマッピングすることができます。

ストレージ

　基本的なコンピューター処理におけるストレージ要素は次のビルディングブロックがあります。

トークンストレージ

　トークンは価値（資産や証券など）を格納します。例えばBitcoins、飛行機のマイレージ、デジタルアートの著作権などです。トークンストレージシステムは二重支出を防ぎながらバリアントとともにトークンを発行／トランスファーします。

　BitcoinとZcashはトークンにフォーカスした代表的な「ピュアプレイ」システムです。 Ethereumは世界のコンピュータとなるミッションの実現のためトークンをサービスで利用しています。これらはすべてネットワークインフラストラクチャを運用するための内部インセンティブとして使われるトークンの例です。

　その他のトークンはネットワーク自体に力を供給するための内部性を持ちません。より低いレベルのインフラストラクチャが実際にトークンを格納する上位ネットワークのインセンティブに使用します。Ethereumメインネットの上のGolem（GNT）のようなERC20トークンは一つの例です。IPDBネットワーク上で動作するEnvokeのIPライセンストークンももう一つの例です。

　最後にほとんどのブロックチェーンシステムにトークンストレージの仕組みがあることを示すために”.*“をリストしました。

データベース：データベースは構造化されたメタデータの格納に特化しています。例えばテーブル（リレーショナルデータベース）、ドキュメントストア（JSONなど）、KVS、時系列、グラフなどです。クエリ（SQLなど）を介してデータを迅速に取得することができます。

　MongoDBやCassandraのような伝統的な分散型（ただし集中化された）データベースは数百テラバイト、さらにはペタバイトのデータを毎秒100万回書き込むことができます（Netflixの事例）。

　SQLのようなクエリ言語は実装と仕様を分離しているため特定のアプリケーションに縛られません。SQLは何十年にもわたる標準です。同じデータベースシステムをさまざまな業界で使用することができるのはこのためです。

　別の言い方をすれば、アプリケーション固有のコードを使わずBitcoinを超えてブロックチェーンのアプリケーションを一般的なものにするためにチューリング完全性を徹底する必要はありません。データベースが必要なだけです。これには単純さと規模のメリットがあります。ただし、いくつかの場面でチューリング完全性を持つ大きな意味がまだあります。これについては「分散処理」のセクションでさらに解説します。

　BigchainDBは分散データベースソフトウェアです。具体的にはドキュメントストアです。MongoDB（またはRethinkDB）上に構築されているため、Mongoのクエリとスケールを継承しています。さらに分散制御、耐タンパー性、トークンサポートなどのブロックチェーン特性も備えています。IPDBはBigchainDBのガバナンス機能を持った公開ネットインスタンスです。

　また、IOTAはブロックチェーン分野における時系列データベースと考えることもできます。

ファイルシステム／データブロブストレージ

　これらは大きなファイル（ムービー、mp3、大規模なデータセット）を格納するためのシステムで、ディレクトリとファイルの階層構造をとります。

　IPFSとTahoe-LAFSは分散型のファイルシステムで、分散型／集中型のブロブストレージをラッピングします。FileCoin、Storj、SiaやTieronは分散型ブロブストレージです。古き良きBitTorrentもそうですトークンではなくtit-for-tatスキームを使用します。 Ethereum Swarm、Dat、Swarm-JSは基本的に両方を行います。

データマーケットプレイス

　これらのシステムはデータ所有者（企業など）とデータ消費者（AIスタートアップなど）を仲介します。本来ならデータベースやファイルシステムよりも高いレイヤーのものですが、データを必要とする無数のアプリケーション（AIなど）がそのようなサービスに依存するため、コアインフラストラクチャにもなります。Oceanはデータマーケットプレイスを構築することができるプロトコルとネットワークの例です。アプリケーション固有のマーケットプレイスもあります：暗号市場のEnigma Catalyst、個人データ用のDatum、 IoTストリーム用のDataBroker DAO [2]などです。

プロセッシング

　次に基本的なコンピューター処理のプロセッシング要素について説明しましょう。

「スマートコントラクト」は分散型の処理を行うシステムにとって人気のある呼び方です*2。 実際にはステートレス（コンビネーショナル）ビジネスロジックとステートフル（シーケンシャル）ビジネスロジックの2つのサブセットがあります。ステートレスとステートフルは複雑さや検証可能性などにおいて根本的に違うものです。さらにHPC（ハイパフォーマンスコンピューティング）という3つ目の分散処理ブロックがあります。

ステートレス（コンビネーショナル）ビジネスロジック

　内部的にステートを保持しない任意のロジックです。電気工学用語では組合せ論理回路と位置づけられます。ロジックは真理値表、回路図、または条件文を保持するコード（if / then、and、orを組み合わせたもの）として表現されます。ステートを持たないため、大きなステートレスなスマートコントラクトを検証するのは容易です。このため大規模な検証/安全なシステムを構築することができます。N個の入力と1個の出力を検証するためにO（2 ^ N）回の計算が必要です。

　インターレジャープロトコル（ILP）には組み合わせ回路を明確に指定する暗号条件（クリプトコンディション：CC）プロトコルを含みます。CCはIETFを通じてインターネット標準となっているため、知っておいたほうがいい技術です。またILPは集中管理と分散管理の両方のペイメントネットワーク（例：75以上の銀行がRippleを介した取引）で普及しています。CCはJavaScript、Python、Javaなどのスタンドアロン実装があります。 BigchainDBやRippleなどのシステムはCCを使用し、組み合わせビジネスロジック／スマートコントラクトをサポートします。

　BitsharesとEosはステートレスなビジネスロジックもサポートしています。

　ステートフルロジックはステートレスロジックのスーパーセットであるため、ステートフルロジックをサポートするシステムは（複雑さと検証の難しさを犠牲にして）ステートレスロジックもサポートします。

　BigchainDB、BitsharesとEosはイベントもサポートしています（例）。このためステートフルなビジネスロジックに近いレベルの永続性を与えます。

ステートフル（シーケンシャル）ビジネスロジック

　内部的にステートを保持する任意のロジックです。つまりメモリーを保持します。または少なくとも1つのフィードバックループ（およびクロック）を備えた組み合わせ論理回路です。たとえばマイクロプロセッサには内部レジスタがあり、それに送られるマシンコード命令に従って更新されます。より一般的にはステートフルなビジネスロジックは、一連の入力を受け取り、一連の出力を返すチューリングマシンです。このようなシステムはチューリング完全システムと呼ばれています*3。

　Ethereumはステートフルなビジネスロジック／スマートコントラクトを直接チェーン上で実行する最も有名なブロックチェーンシステムです。 Lisk、RChain、DFINITY、Aeternity、Tezos、Fabric、Sawtoothなど多くががこれを実装しています。実行コードが「ちょうどそこに、どこかに」というのは多くのユースケースを適用することのできる強力なコンセプトです。これこそがEthereumが立ち上がった理由です。そして、そのエコシステムが成長して、それ自身がプラットフォームである理由です。このビルディングブロックに多くの強豪が参入してくる理由でもあります。

　シーケンシャルロジックは組み合わせロジックのスーパーセットであるため、これらのシステムは組み合わせロジックもサポートします。

　The DAOのハッキング事件でも示されたとおり、コードの小さな間違いは重大な結果を招く可能性があります。正式な検証はチップ業界を助けたように役立ちます。 Ethereum Foundationはこれに取り組んでいます。しかしスケールには限界があります。内部変数がすべてブール値であると仮定して、組み合わせ回路の場合可能なマッピングの数は2 ^（入力数）です。シーケンシャルの場合、内部状態の数は2 ^（内部ステート変数の数）です。たとえば、3入力の組み合わせ回路を使用している場合、²³ =8のsステートの可能性を検証する必要があります。これが32ビットレジスタを持つ順序回路であれば、²²= 42億のステートを検証する必要があることになります。このように順序回路の複雑さが制限されます（仮に信頼したい場合）。 Rchainがrho calculusで行ったように、ステートフルなスマートコントラクトを信頼するもう1つのアプローチは「Correct-by-construction」です。

　分散処理が必要な場合はより簡単なアプローチがあります。プロセッシングをJavaScriptやSwiftでブラウザやモバイルデバイスなどクライアントで行うのです。この方法ではクライアントでの処理を信頼する必要がありますが、手元のデバイスにおいてそれは許容されることが多いです。これを「ファットプロトコル」の代替としての「ファットクライアント」だと考えています。 このアーキテクチャはメインストリームのWeb開発者にとっては簡単です。多くのWebアプリケーションに必要なのはアプリケーションステートです。これを構築するにはJavaScriptとIPDB（js-bigchaindb-driverを使用）を使うだけです。また、アプリにブロブストレージとペイメントが必要な場合はJSクライアントバージョンのIPFS（ipfs.js）とEthereum（web3.js）を追加します。以下の図がその例となります。

ハイパフォーマンスコンピューティング（HPC）

　レンダリング、機械学習、回路シミュレーション、天気予報、タンパク質フォールディングなど「重い」計算を行う処理です。ここでの計算ジョブはマシンのクラスタ（CPU、GPU、場合によってはTPU）で数時間から数週間かかることがあります。

　HPCの分散処理にはいくつかのアプローチがあります：

• GolemとiEx.ecは分散型スーパーコンピュータとそれに関連するアプリの組み合わせとしてとらえています。
• Nyriadはストレージ処理としてとらえています。基本的に処理は分散ストレージ（Nyriadにも解決策があります）と隣接しています。
• TrueBitはサードパーティが計算。その計算後のチェックを行います（可能な場合は暗黙的にチェックし、質問が発生した場合は明示的にチェックします）。
• 一部の人々は単にVMまたはDockerコンテナで重い計算を実行し、その結果（最終的なVMステートまたは計算結果のみ）をアクセスが制限されたブロブストレージに格納します。次にトークン化された読み取り権限などを利用してコンテナへのアクセスを販売します。このアプローチはクライアントに結果検証をより多く要求しますが、今日使える技術で全てできることが利点です。これはTrueBitが成熟するにつれてTrueBitと自然に統合されます。

コミュニケーション

　ここでは第3の基本的なコンピューティング要素のコミュニケーションについて説明します。コミュニケーションをとらえるには多くの方法があります。ここではネットワークへの接続に焦点を当てます。データ、価値、ステートの3つのレベルがあります。

データ

　私たちは60年代にARPAnetを手に入れました。この成功はNPLやCYCLADESのようないくつかの同様のネットワークを生み出しました。そして新しい問題も生まれました。異なるネットワークはお互い会話ができませんでした。CerfとKahnは70年代にTCP/IPを開発して現在インターネットと呼ばれるネットワークのネットワークを作りました。 TCP/IPは現在ネットワークを接続する事実上の標準になっています。OSIは競合するプロトコルでしたが衰退していきました。しかし、皮肉なことに、そのモデルは有用であることが証明されています。したがって、長い年月が経っているにもかかわらず、TCP/IPはデータのネットワークをつなぐための分散ビルディングブロックです。

　Torプロジェクトはユーザーのプライバシーを保護するためのTCP/IPオーバーレイと見なすことができます。しかし、アメリカ国防総省からの資金提供はいうまでもないことですが、集中化の側面があります。トークン化されたTorのようなプロジェクトが出現しはじめています。今しばらくお待ちください[2]。

価値

　TCP/IPはネットワークをデータレベルでのみ接続します。TCP/IPではパケットを二重に使うことがあります（一度に複数の宛先に同じパケットを送ります）がそれは気にしません。しかし、ネットワークに接続して価値を送る場合はどうでしょうか？たとえばBitcoinやEthereum、あるいはSWIFT決済ネットワークからRippleのXRPネットワーク。トークンを一度に一つの宛先だけに送りたいはずです。交換機は二重支出を防ぎながらネットワークに接続する方法の一つです。しかし交換機の利用はかなり重いです。ただし暗号エスクローを使用することで、交換機の本質部分だけ抽出してスリム化し、仲介人の必要性を取り除くことができます。アリスはMalloryを介してボブに送金することができます。Malloryはファンドを送りますが、使うことはできません（そしてMalloryは永遠にファンドを留めることができないので、その場合はタイムアウトとなります）。これがインターレジャープロトコル（ILP）の本質です。双方向ペグ（サイドチェーン）とステートチャンネル（LightningとRaiden）とコンセプト的には同じです。しかし、価値のネットワーク接続に100％フォーカスしています。 ILPに加えてCosmosもあります。Cosmosはより利便性を高めるために複雑さを少し増しています。

ステート

　価値をネットワークにつなぐ先は何でしょうか？ あるネットワークから別のネットワークにジャンプすることができる独自のBitcoinウォレットを備えたコンピュータウイルスを想像してみてください。またEthereumメインネット内のスマートコントラクトがその状態を別のEthereumネットうあ別の互換性のあるネットに移すことができたら？またはAI DAOを1つのネットに制限するのはなぜですか？

　Polkadotはこのためにあります。ステートをネットワークでつなぐ。Aeternityは価値のネットワークとステートのネットワークの間のどこかにあてはまります。

ビルディングブロックを組み合わせた事例

　ここまでコンピューティングの3つの要素（ストレージ、プロセッシング、コミュニケーション）と、それぞれのビルディングブロックおよびサンプルプロジェクトを紹介してきました。

　人々は組み合わせながらシステムを構築しはじめています。二つのブロックの多くの組み合わせるプロジェクトはたくさんあります。通常はIPFSとEthereumまたはIPFSとIPDBの組み合わせです。そして三つ以上のブロックを組み合わせる事例もあります。ここでいくつかの最先端の事例を紹介します。

Ujoの事例

UjoではIPFS|Swarm + IPDB + Ethereumの組み合わせで分散型音楽サービスを実現しています。IPFSまたはSwarmはファイルシステムとブロブストレージとして、IPDBとBigchainDBはメタデータの格納とクエリに、Ethereumはトークンの格納とステートフルなビジネスロジックに使用されます。

Innogyの事例

Innogyではサプライチェーン／IoTアプリケーションにIPFS + IPDB + IOTAを使用しています。IPFSはファイルシステムとブロブストレージとして、IPDBとBigchainDBはメタデータの格納とクエリに、IOTAは時系列データに使用されます。

そのほかのフレーミング

　ブロックチェーンコミュニティにおける他の人たちによる他のフレーミングも紹介します。それぞれの人たちとの会話を私は大いに楽しみました。

　Joel Monegroの”Fat Protocols“は各ビルディングブロックをプロトコルとして位置づけています。なかなかクールなフレーミングの方法だと思っていますが、それはビルディングブロックがネットワークプロトコルを介してのみ会話をすることとなります。別の方法もあります。ブロックは単に1つの「インポート」ステートメントまたはライブラリ呼び出しとする。

　インポートを使用する理由は（a）レイテンシを短くすること：ネットワークコールに時間がかかりユーザビリティを損なう可能性がある（b）シンプルさ：ライブラリ（または埋め込みコード）の利用はネットワークでの接続、トークンの支払いなどより簡単（c）より成熟している：プロトコルスタックが誕生してきています。私たちは数十年にわたる素晴らしいUnixライブラリを持っています。PythonとJavaScriptのブロックも15年以上経過しています。

　Fred Ehrsamの “Dapp Developer Stack“はWebビジネスモデルに重点を置いています。 このフレーミングも非常に有益ですが、特定のコンピューティング要素（ファイルシステムとデータベースの違いなど）のブロックをさらに区別することを目的としていません。

　BigchainDBのホワイトペーパー[PDF]（2016年2月に公開）図1は、このポストのスタックの初期バージョンです。以下のチャートがそれです：

　この図ではプロセッシング、ファイルシステムおよびデータベースのビルディングブロックにフォーカスしています。「コンピューティングの要素」という観点からは枠組みを構成しておらず、分散処理の種類も区別していませんでした。私がこの記事はこのホワイトペーパーを書いた一年半からの私の考えの進化とも言えます。私の考えは段階的に進化していき5月22日のConcensus 2017でのトークはこの記事と非常によく似ています。そしてこの記事を書いた理由はこのトークをきちんと形にするリクエストをたくさん受けたからです 🙂

　この図は完全集中化（左）から完全分散化（右）までのスペクトラムがあることを示しています。このような表現は既存のシステムを徐々に分権化する上で、どこが最も分散化の恩恵を受けるのか理解するのに役立ちます。

　Stephan Tualの “Web 3.0 Revisited“はこの記事と精神的な部分で近いですが、よりEthereumに重点を置いています。多くのプロジェクトを類似のビルディングブロックにグループ化することでコミュニティに役立つ貢献をしています。自分の考え方ととても似ていることに喜んで驚いていました。しかしアプリケーション（メッセージング、ストレージ、コンセンサス、ガバナンスなどのブロック）を構成するブロックに「アプリ」「What」「How」の3つの要素が混ざり合っています。私にとってはブロックは「What」でなければなりません。したがって、メッセージングは​​アプリです（アプリケーションレベル）。ストレージはより細分化する必要があります。コンセンサスは「How」の一部です。ガバナンスも「How」です。また下位のブロックとして（ネットワーク）プロトコルがあります。私はライブラリの呼び出しと同様にブロックが互いに話すことができる方法の一つだと考えています。それにもかかわらず、私はこれが優れた記事とスタックだと思います 🙂

　Alexander Ruppertの“Mapping the decentralized world”には約20のグループに整理され、x軸はインフラストラクチャ層からアプリケーション層まで4つの上位レベルのグループを表していて、ミドルウェアと流動性を中間レベルに位置づけています。これも素晴らしいやり方です。私はAlexのマップを手伝うことができてうれしいです。コアインフラストラクチャーに重点を置いておらず、より幅広いトレンドに焦点を当てています。これもコアインフラストラクチャに関する第一原則フレーミングです。

将来

　UjoのプロジェクトではIPFSとSwarm（ブロブ）+ Ethereum（トークンとビジネスロジック）+ IPDBとBigchainDB（データベースと高速クエリ）を組み合わせて全てのメリットを享受しています。

　この傾向はビルディングブロックの関係性の理解が進むにつれて増えていくと考えます。「ブロックチェーン」という大きなモノリスにすべてを詰め込むより生産的です。

　このスタック自体も分散型エコシステムとともに絶えず進化するでしょう。AWSはブロブストレージ用のS3というたった一つのサービスからはじまりました。 それからプロセッシングのためのEC2が追加され、AWSのサービスは増え続けています。ここにAWSのリリースタイムラインがあります。現在AWSには50以上のブロックがあります。以下はすべてのAWSサービスの現在のスナップショットです。

　AWSで起きたことが分散化の分野でも起きると予想しています。おそらく現在ある全てのAWSブロックは分散化されるでしょう。もちろんクラウド、モバイル、分散システムにはそれぞれ独自のブロックがあります。分散システムであればトークンストレージなどです。これからの将来はとても楽しみです。

 

　ここ数年、このスタックについて私にフィードバックをくれた無数の人々に感謝します。Carly Sheridan、Troy McConaghy、Dimi de Jongheの編集協力に感謝します。最後にビルディングブロックを改善し続け、さらに興味深いアプリケーションを開発し続けている宇宙の皆様に感謝します:)

翻訳：カタパルト式スープレックスなかむらかずや

関連記事

 

原文：“The E-krona project – First interim report”k by Riksban

　スウェーデン国立銀行（Riksbank）は法定通貨をeクローナとしてデジタルで補完することが可能かどうか調査しています。さらに、このデジタル化がスウェーデン国立銀行にとって安全かつ効率的な決済システムをもたらすことができるのかを調べています。このようなことはすでに数回経験しており、今回だけが特異ではありません。決済マーケットの変化に応じて、政府自身の役割を変える必要があります。eクローナは物理的な貨幣の使用が急速に減少している将来の決済マーケットで起きるであろういくつかの問題に対応できる可能性があります。

　eクローナにより現金の代替手段として国から保証されたデジタルな通貨が使えるようになります。そして、サプライヤーはeクローナのシステムにアクセスすることができます。現在はRIXデジタルペイメント（Riksbank’s payment system for financial transactions―中銀決済システム）の加入者のみが参加することができます。eクローナは商用銀行のシステム基盤から独立して機能することにより決済システムを非常時により堅固にすることができます。例えばカード決済システムなど。

現金利用の低下

　スウェーデンは21世紀に入りカード支払いと同時に現金の使用が減少しました。それに取って代わりSwishでの支払いがますます一般的になっています。小売業における現金支払いの割合は2010年では40％近くでしたが、2016年には約15％にまで低下しています。消費者の3分の2は100クローナ（約1300円）以下の決済であれば現金無しで支払いができると考えています。それほど遠くない将来にスウェーデンは現金が一般に受け入れられない社会になるかもしれません。このようなスウェーデンの決済市場の発展は国際的にもユニークと言えます。

デジタル化は好ましくない効果もある

　この発展はいくつかの要因が組み合わさっています。ひとつは社会におけるデジタル化への大きな傾向です。そして、スウェーデンにおける決済仲介は完全に民間が主体となり少数のビジネス、サービス、インフラに統合する可能性も要因の一つと言えます。長期的には、この集中は市場における競争力を抑制し、社会を脆弱にするリスクがあります。キャッシュレスに向かう社会への発展により中央銀行によるリスクの少ない貯蓄に振り分ける機会が少なくなる可能性もあります。その結果として決済システムの弾力性が低下する可能性があります。

　更に現時点においてデジタルペイメントを利用できない人たちや、現金での支払いを好む人たちがいることも認識しています。これらのデジタルペイメントを使わない、使えないグループに代替手段を提供できることも重要です。郵政局（The Swedish Post and Telecom Authority）および郡管理委員会（County Administrative Boards）は基本的な決済サービスが一般の人々のニーズにマッチすることを確実にする必要があります。

　金融危機など何かが起こると現金の需要が増加が想定されいます。そのような場合、中央銀行が最終的に準備ができるとしても、必要な機関に現金を配分するのに時間がかかります。またシステム的な問題が発生した場合、現在の現金のように自律して存在できる代替案がないリスクもあります。

レジスターベースのeクローナをバリューベースのeクローナで補完

　仮想法定通貨「eクローナ」のモデルとしてレジスターベースとバリューベースの2つのモデルが考えられます。レジスタベースのeクローナの場合、残高は中央のデータベースの口座に保存されます。バリューベースのeクローナは現在の現金のようにアプリまたはカードにローカルに保存されます。

　現在の評価では、単純なバリューベースのモデルはレジスターベースと比べ発展性が限られていますが、より早く導入される可能性があります。レジスターベースはより複雑ですが、段階的に拡張できるため将来の需要に対応できる大きな可能性があります。このプロジェクトでは2つのモデルの組み合わせが提案されています。レジスターベースのモデルを小額決済をメインとし、なおかつオフラインでも使えるバリューベースのeクローナが補完する形です。バリューベースのソリューションにより、eクローナ口座を持つことができない、または望まないグループにもeクローナが使えるようになります。これにより特別なグループのニーズを満たす決済サービスソリューションをさらに開発することができます。

利用する技術はさらなる検討が必要

　eクローナで使われる技術はさらにプロジェクトで検討する必要があります。新しい技術も枯れた技術も可能性がありますし、公共機関と企業などの協力体制も考えられます。

金融政策や財務の安定性への影響は限定的

　eクローナの導入における金融政策、決済市場と財務の安定性に関して大きな障害は確認できていません。金融政策の枠組みはデジタル化の新しい現実に適応すると考えています。スウェーデン国立銀行は一般市民と市場が要求する紙幣と硬貨を供給しています。紙幣と硬貨の供給と同じ方法でeクローナの供給を決定すると想定しています。

法令の見直しは必要

　私たちが提起する質問は非常に大きく重要なため、議会での徹底的な審議が必要であると考えています。eクローナの導入によるスウェーデン国立銀行の金融政策における責任分野は現在の立法では対応できません。しかし、調査結果ではeクローナは安全で効率的な決済システムを促進するという法定の役割を果たすことができます。スウェーデン国立銀行がデジタル決済手段を発行する場合、Sveriges Riksbank Act（中央銀行は金融政策について完全独立していることを定めた規定）を適用する必要があるとプロジェクトは考えます。eクローナ発行をスウェーデン国立銀行に委任するか、法的に入札されるべきかは立法の判断となります。

eクローナのコンセプト

　このプロジェクトはスウェーデン国立銀行の理事会が中央銀行のデジタル通貨を一般に公開する必要があると判断した場合、次のようなeクローナのデザインを提案しています。

• eクローナは主に消費者、企業、および当局間における小額決済を目的としています
• eクローナはスウェーデン国立銀行が発行しスウェーデンクローナに対応します。一般市民、金融機関および企業が保有することができます。1日24時間、週7日、365日、リアルタイムでアクセスできます。
• eクローナは利息は発生しませんが、将来的に利息が発生するようにするための機能を組み込むことが可能である必要があります
• レジスターベースのeクローナはバリューベースのソリューションと組み合わせることにより小額のオフライン支払いを可能にし、eクローナ口座を必要としないグループへのアクセスを広げます
• スウェーデン国立銀行はeクローナの基本機能を提供しますが、既存のデジタル基盤を使用する可能性を調査し、外部のプレーヤーからもにエンドユーザとのやりとりのデザイン提案を受け入れます

　この報告書はプロジェクトの初期の暫定的な結論です。分析と調査を継続します。プロジェクトが社会の利害関係者と対話した後に修正される可能性があります。

関係者との議論

　決済市場の発展は社会全体に影響を及ぼします。スウェーデン国立銀行はこの報告書様々な疑問や問題についてグループとの幅広い対話の道を開くことを望んでいます。eクローナに関する調査するこのプロジェクトの次のステップは関係者からの意見と質問を集めることです。スウェーデン国立銀行はまだeクローナの発行について決断をいません。

関連記事

 

原文：”How reusable is open source software?” by Laura Gerhardt, Innovation Specialist at 18F, October 23, 2017

　ここTechnology Transformation Services（TTS）に所属する私たちはオープンソースソフトウェアの大ファンです。オープンソースは納税者に透明性とコスト効率を提供する重要な方法の1つです。ホワイトハウスのオープンソースポリシーはオープンソースソフトウェアを「誰でもアクセス、使用、変更、共有できるソフトウェア」と定義しています。TTSは開発したすべてのコードをパブリックドメインとして誰でも複製または再利用できるオンラインリポジトリにリリースしています。このソフトウェアを構築する際には既存のオープンソースコードライブラリを組み込んでコードライセンス管理の必要性を最小限に抑えます。

　オープンソースソフトウェアにより政府、ベンダーや外部の貢献者が協力して作業することも可能になります。これにより柔軟な使用とカスタマイズが可能になり、政府はソフトウェアライセンスを節約することができます。セキュリティー上の恩恵もあります。監査能力を向上させ、開発者にセキュリティーに対する強い姿勢を最初から持たせることができます。コードはパブリックドメインであるため、誰でもコードを再利用または再配布することができます。18Fのオープンソースポリシーでは「オープンソースライセンスではない限定的なライセンスのプロジェクトにも統合することができる”としています。

　この記事は政府のカスタムソフトウェア開発プロジェクトにおけるオープンソースコードの使用に関するいくつかの誤解を明らかにし、特定の問題を明確にすることを目指しています。

再利用の限界

　オープンソースのコードが再利用可能であるというだけで、すぐに利用できるというわけではありません。

　すべての政府サービスのなり立ちには長い歴史があります。当時利用可能だった技術、複雑に絡み合った法的要件や関わった人たちなどです。

　その影響は多岐に渡ります。特定の免責事項を含む必要性、特定の形式の電子署名でサインすること、特定のフォームフィールドを更新すること、または独自の承認プロセスを持つなどです。

　このようなユニークな状況では政府サービスが望む厳密な形ですぐに使えるソフトウェアソリューションがない可能性が高いです。オープンソースかどうかに関わらず。ITチームが既存のコードベースをそのままインポートしようとすれば、ユーザーが絶対的に必要とする機能が不足している可能性があり、エンドユーザはそのサービスに満足できないでしょう。追加のメンテナンス費用を必要とする使用しない様々なものが含まれている可能性もあります。プロプライエタリなソフトウェアの場合、ワークフローとユーザーの構成によってシステムの制限がある可能性があります。

　ユーザーのニーズを満たすためには、ほとんどの場合カスタム開発が必要になります。オープンソースの柔軟性は必要なモジュールを組み込み、それらのユーザーニーズを満たす助けとなります。さらにプロプライエタリなソフトウェアに対する高価なライセンス料を払う必要もありません。Ruby on RailsやDjango（Python用）のようないくつかの既存のフレームワークによりユーザーと関係機関のニーズを満たすツールの開発に開発者がすぐに取りかかることができます。

　例えば、私たち18FはC2という米連邦政府一般調達局の公共建築物サービス（PBS）の購入カード承認アプリケーション構築の支援をしました。私たちの開発者はRuby on Railsを活用して承認ワークフローを構築しました。これにより承認者が必要とする情報を組み込むことができ、PBSの既存の独自のビジネスプロセスと同じ個別の購入ごとのレビューレベルを実装することができました。

　今後、他のチームがこの購入カード承認アプリケーションを使用する可能性があります。しかし、アプリケーションを大幅に変更することなく使用するのは困難でしょう。内部の承認プロセスが異なるからです。しかし、C2はオープンソースソフトウェアであるため外部の開発者はC2のコードをその目的に合わせて変えたり、少なくとも開発者がどのように問題対してアプローチを取ったか確認することができます。

オープンソースは自分で作るときに最高

　デジタルサービスの場合、オープンソースコードを再利用しやすいケースは二つあります。パッケージが同じビジネスプロセスをサポートしている場合とビジネスプロセスに関係なく同じソフトウェア問題を解決する場合です。オープンソースコードでは、開発者やデザイナーが既存のコードを自由に必要に応じて採用し、ユーザーのニーズを満たす開発作業に集中することができるからです。

　たとえばDigital Analytics Programのためにに開発されたソフトウェアは都市、州、国によって15回以上再利用されています。再利用されたオープンソースプロジェクトとしての成功の要因の一つは多くの政府機関がGoogle Analyticsを使ってトラフィックを監視していたからです。それによりソフトウェアのデータソースは常に同じ場所から同じ形式で提供されます。使用法とデータパイプラインが同じであれば、開発者は政府のブランドを組み入れるか、既存の機能の上に開発することができます。Digital Analytics Programソフトウェアは共通かつ限定的なビジネスケースをサポートすることによりオープンソースの再利用性を高めています。

　同様にU.S. Web Design Standardsは開発者にとって使いやすいユーザーインタラクションライブラリを提供しています。これによりパブリックかプライベートの開発者は自らが関わるプロジェクトのビジネス課題に集中してソフトウェアを開発することができます。アプリケーション設計者達によると、すべてのプロジェクトでボタンサイズのような設計上の意思決定を行う必要がないため開発期間が短縮できたそうです。U.S. Web Design Standardはオープンソースなので開発者は政府機関のスタイルガイドを満たし、元のコードに含まれていない追加のデザイン資産も自由に追加できます。

　展開プロセスはオープンソースソフトウェアを組織に組み込むもう1つの良い方法です。開発プロセスはビジネスプロセスとは異なることが多くあります。継続的デプロイメント（CI）などは他の組織が開発したオープンソースのソフトウェアを追加する方が容易な場合があります。これらのツールはプロジェクトへの頻繁で小さなコード更新がコードの他の部分を壊さないようにするのに役立ちます。展開のパイプラインの標準化をサポートし、インフラストラクチャと環境の構築とプロビジョニングに費やす時間を削減することができます。これにより開発者は何がユーザーと顧客にとって本当に必要なのかを探ることに時間を使うことができます。

　政府がオープンソースソフトウェアへのIT投資の効果を最大限に高めることを考えている場合、ビジネスプロセス特有のコードを分けておくとわかりやすいです。例えば、データやワークフロー、インタラクションコンポーネントやデータベース、ホスティングリソースなどです。これらビジネスプロセス特有の要件はほぼ確実にカスタマイズする必要があります。しかし、コンポーネントと開発者のリソースを相互に活用することは共同投資と再利用の恩恵をもたらします。

　再利用可能な18Fプロジェクトは以前のブログ記事を参照してください。詳細を知りたい場合は、公開Slackチャンネル#opensource-publicに参加して、GitHubプロフィールをチェックしてください。

関連記事

1235 Mission Streetにあるサンフランシスコのフードスタンプオフィス（通称：1235）

原文：”“People, Not Data – On disdain and empathy in Civic Tech” by Jake Solomon, Jan 6, 2014

　ここはサンフランシスコの大きなフードスタンプオフィスです（フードスタンプは低所得者に配給される金券。スーパーマーケットなどで食料品を買うことができる）。通称1235。1235 Mission Streetにあるから。私がはじめてここを訪れたのは2013年2月7日木曜日でした。コンクリート柱を通り抜け、二人の警備員が立っている金属探知機を通過。書類が散らかったテーブルの横を通り、ようやく待合室にたどり着きました。とても騒がしかった。天井のスピーカーの声がリノリウムの床に反響して響き渡る。サービスカウンターBと呼ばれる大きなカウンタートップに大勢が並んでいました。

　背の高い黒人男性が列の先頭にいます。彼は前かがみになって手をカウンターにおきました。厚くて曇った防弾ガラスシートが彼とワーカー（福祉サービスのソーシャルワーカーのこと）を分け隔てていました。彼らはガラスに取り付けられたひょろ長い会議用のマイクを通じて会話をしていました。彼はワーカーとのマイク越しの会話が聞き取りづらくて困っているようでした。マイクをつかんで上に向けようとしましたが、それより近づくことができません。さらに腰を曲げて頭の位置を下げ、耳をガラスにつけました。さらに膝を地に下ろし、マイクを顔に近づけ、腕をカウンターにもたれかけました。そしてひざまずいたまま会話は終わりました。

　私がいる場所。サンフランシスコ。私たちの国で最も繁栄している都市のひとつ。そこで私が見た風景。防弾ガラス越しに会話を聞き取るためにひざまずき、連邦政府からのフードスタンプを受けようとしている男性。

何かがとてつもなく間違っている

　これが私のCode for Americaのフェローシップのはじまりでした。2013年2月の後半にサンフランシスコの4つのシェルター予約サイトの1つであるミッション・ネイバーフッド・リソースセンターを訪問しました。シェルターで一晩のベッドを予約するのに12時間以上かかることがあり、シェルターよりストリートで寝ることを選ぶ人もいます。また次の日のベッドのために朝4時にシェルターをでて列を作る人たちもいます。ベットが欲しければ早く起きなければいけません。

　私のチームメイトもフードスタンプに登録しました。メールが送られてくるようになりました。しかもたくさん。それらはこのように威圧的だったり：

文字だらけで混乱していたり：

あるいは全く意味をなさなかったり：

　7ヶ月の加入期間中、20のメールを受け取り、3回ほど打ち切られそうになりました。下のタイムラインをみてください。

サービスはユーザーを見下している

　これが私たちと政府とのやり取りです。私たちはひざまずき、シェルターでベットを確保すために並び、郵便で攻撃的なレターを受け取ります。本来なら困っている人に手を差しのべるサービスが助けるべき人たちを見下しています（disdain）。

dis·dain（見下す／軽視する）

動詞：その人を考慮する価値がないとすること

　このユーザー軽視は人生を変えるほど巨大で物議をかもす形で現れます。退役軍人が障害手当を受け取るのに260日かかります。私たちは家族が暮らす部屋を用意するためにひと月3,000ドルを費やしますが、その家族が必要なのは一人当たり900ドルの現金です。

　そして、このユーザー軽視は小さく静かに誰も気づかない形で現れます。サンフランシスコで無料の学校給食をオンラインで申請をするとウェルカム画面でこの警告が強調表示されます：

オンラインでできるのは一つの申請だけです。何らかのエラーが発生した場合は紙で申請する必要があります。

　またはCalWinのiPhoneアプリをダウンロードしてみてください。カリフォルニアの7億5000万ドルのクライアント福祉データシステムのアプリです。そこで目にするのは：

　このようなユーザー軽視は上から下まで徹底しています。例えばhealthcare.govで起きた問題は政府のITがいかに壊れているかという長い議論（と周辺に巻き起こる批評）をもたらしました。しかしエズラ・クラインが何が壊れているのかの本質を言い表しています。

…一部の被保険者と裕福な人が持つ特権は貧しい人たちが日々晒されている低品質な公共サービスに対して言い訳をすることです。報道機関は大抵は見て見ぬフリをするか、全く本当に何も知らないかです。貧しい人たちが政府の官僚主義に日々どれほど打ちのめされているのか。そうして放置することで官僚主義はさらに悪くなっていきます。エズラ・クライン

　問題はWebサイトではありません。問題は1235でひざまずいている男性であり、ユーザーを軽視するマシンのような官僚主義がひざまずく彼を助けないことです。

共感からサービスを作ろう

　だから私たちはここにいます。ユーザー軽視のマシンと格闘しています。誰もそんなことは望んでいない。ソーシャルワーカーもユーザーがひざまずくことを望んでいたりはしない。CalWinの開発者も自ら開発したアプリがiPhoneのホームスクリーンで恥をさらすことを望んでいない。誰もホームレスの人々が徹夜で並ばなければいけないことを望んでいない。それはすでに政治の域を超えています。

　できるならば、これを勇ましい言葉で終わらせられたらと思います。「私と一緒に行動を起こしませんか？私たちの壊れた政府を直しませんか？ここをクリックしていますぐ寄付を！」しかし、私にはそれはできません。私はCode for Americaのフェローシップ期間中に解決策よりも多くの問題をみてしまいました。そこで私は一つの疑問を提起したいと思います。どうしたら共感力のある公共サービスを作れるのでしょうか？

　兎にも角にもまずはユーザーのニーズ。共感力のあるサービスはリアルな人々のリアルなニーズに根ざしています。必要なのはイノベーションではありません。ビッグデータ、government-as-a-platform、透明性、クラウドファンディング、オープンデータ、Civic Techなどではないのです。大事なのは人です。人々とそのニーズを優先することを学ぶこと時間をかけて学ぶべきです。このような変化はすぐには起こりません。一人づつ、ゆっくりと。でも私たちははじめなければいけません。

　私たちは非常に多くの創造性、ツール、そして非常に多くの素晴らしい事例があります。ユーザーのニーズを特定し、文書化し、説明し、ニーズに答えるのに役に立つ様々なリソースが。それを活用していないだけです。私はSF映画に出てくる宇宙船400台全ての相対的なサイズを知っています。しかし恥ずかしい話ですが、ホームレスのシェルターや刑務所がどのように機能するかはほとんど知りません。

　healthcare.govの侮辱と怒りを感じている最中、ティム・オライリーが大きな機会を気づかせてくれました。

healthcare.govの問題に嘆いたり、誤りや政治的な優位性をくまなく探すよりいいことがある。すべての人たちにとってシンプルで効果的で使いやすい公共サービスを創造する絶好のチャンスがいまなんだ。ティム・オライリー

　だから、穏やかにしかし根気強く意識をユーザーニーズに戻し、ひざまずく人を探して手を差し伸べられる共感力のある仕組みを作りましょう。

追記 (2014年1月22日)

　私が2013年2月にどっぷりと浸った日々は人生で最も有意義な職業経験でした。だからこそ私はそれについて書きました。世界の人々と共有するために。これにより問題の解決に関する議論をより広範なコミュニティに広がることを期待していました。そして、それは成功しましたし、それを誇りに思います。しかし、私のいくつかの疑問やいくつかの批判もありました。ですから、私は一歩立ち返って、地方自治体、公共サービス、特にサンフランシスコのヒューマンサービスエージェンシー（HSA）で働くことになった背景をもう少し詳しく説明したいと思います。

　地方自治体は非常に制約されていると知ったのは今年の大きな学びでした。自治体は地方の政治、州法、および連邦法の複雑な絡み合いに制約されています。制約は責任を伴い下まで行き渡っています。メールの内容を変更したり、SMSを送ったりするにも州と連邦の関係者との協力が必要です。このすべてがフラストレーションとなりえます。しかし、それこそ私がCode for Americaに最初に参加した理由です。本当のの問題を解決するために必要なことを学ぶこと。

　HSAは制約を理解し、それを解決をするのに何が必要なのか学ぶのに最適な場所でした。以下は私が在籍した時に解決を間近にみたことです：

• HSAはユーザーの対面体験を改善するためにMedi-Calのロビーをデザインし直しました。さらに1235のフードスタンプオフィスもデザインし直しました（今は防弾ガラスとマイクは撤去されています）。
• HSAはAffordable Care Act（通称：オバマケア）をはじめとする数百の新しい規制改善を実施しました。Medi-Calを数千の新しいサンフランシスコ住民にまで拡張しました。夜間と週末にもコールセンターにアクセスできるようになりました。何百ものスタッフに新しいプログラム要件のトレーニングを提供しました。これによりサービスが「間違ったドアなし “No Wrong Door”*1」に一歩近づきました。
• HSAはフードスタンプのための報告義務を四半期から半期に削減しました。
• HSAはフードスタンプの再認定のための対面式インタビューを廃止し、ユーザーが電話でインタビューできるようにしました。
• HSAはフードスタンプのユーザーを支援するために特別に作られた最初の栄養ウェブサイトであるEatFresh.orgを提案、資金提供、構築、ローンチしました。
• 最後にTrent Rhorerのユーザーのためにリスクを取る無限の意欲に感謝します。HSAはユーザーのためのSMSシステムを構築して実装した最初のヒューマンサービス機関となりました。

　HSAは2013年にこれをすべて実施しました。これこそがユーザーを第一とするサービスに必要なことです。HSAと2,000人以上のスタッフがそのために日々働いています。サンフランシスコの暮らしと生活を豊かにする助けをしてくれている彼らに感謝します。

　AlanとCrisのメスカルを飲みながらのフィードバックに感謝します。ドラフトを読んでくれたMarcとZavainに感謝します。そして、私たちをパートナーとして共に歩み、大事なことを実行し、実行し続けてくれているサンフランシスコのHSAに感謝します。

関連記事

 

原文：”How Do e-Residents Pay Taxes” by Evelyn Liivamägi, Head of the Tax Department at the Estonian Tax and Customs Board (ETCB), October, 2017

• 仮想住民は課税対象ではありません

• 私たちが税金の仕組みで改善しようとしていること
• 納税義務を理解する
  • 個人税
  • 法人税
• 例
• 関連記事

　現在、エストニアは国際租税競争力指数（International Tax Competitiveness Index）のトップに立っていて、起業家たちに完全オンラインで簡単な税金支払い方法を提供しています。

　しかし、これは現状に満足する理由にはなりません。

　エストニアの税金と関税についての委員会（Estonian Tax and Customs Board）は、国民、住民、その他の税金納付者のために変革を続けなければいけません。そして外国にいるエストニアの仮想住民（e-residents）の起業家コミュニティーに奉仕しなければいけません。

　e-Residency（外国人が簡単にオンラインでエストニアの仮想住民になる仕組み）のメリットは起業家に幅広いオンラインサービスの選択肢を提供していることです。このプログラムの成功は最高品質の公共電子サービスとオンラインビジネス環境を提供できるかどうかにかかっています。

　今後、さらに多くの国がe-Residencyのような仮想住民の仕組みを提供し、世界的に行政の仕組みが改善されることでしょう。しかし私たちはそれを待たずに先に進んでいきます。

　私はエストニア税務局長としてエストニアの仮想住民である皆様方（そしてエストニアで税金を払っているすべての人たち）のために、どのようにサービス改善のため投資をし続けているのか説明します。また、仮想住民の税金に関する仕組みについてより明確に説明したいと思います。これは仮想住民の中で最も頻繁に議論されている問題の1つです。

仮想住民は課税対象ではありません

　エストニア仮想住民はこのプログラムから得られる機会を活用してエストニアに貢献しています。

　一部は財務的な貢献で税金として直接納められています。実際に仮想住民の所得税納税額はe-Residencyに対する税金投資金額を超えています。

　しかし、e-Residencyで登録した仮想住民は課税住民ではないことを強調したいと思います（市民権、エストニアやEUに物理的に居住する権利もありません）

　すべての仮想住民がエストニアに納税しているわけではありません。納税義務はe-Residencyが仮想住民を可能にしたこと（国際的なルールのもとに企業を設立できること）に基づいています。仮想住民だから課税義務が発生するわけではありません。

　また、e-Residencyは税金逃れをする仕組みでもありません。e-Residencyは世界中の起業家が信頼できる企業として成功する機会を提供します。幸いなこと実際そのように認識され運用されています。

私たちが税金の仕組みで改善しようとしていること

　最近まで国際税務の複雑さに対処しなければならなかったのは世界各国に事務所や工場を持つ大企業だけでした。

　しかし、e-Residencyやその他のデジタル技術の進歩により、だれでも国をまたがるグローバル企業を作ることができます。たとえその従業員があなた一人だとしても。

　これは明らかに良いことですが国際課税の複雑さがだれにでも身近な問題となることでもあります。

　e-Residencyの恩恵を受けている設立された新しい企業はこのような複雑な納税義務を理解するための大企業のように大きな会計部門もリソースもありません。しかし、その必要もありません。

　私たちはすべての人にとってシンプルで公正であるべきだと信じています。そうすることにより起業家は書類作成ではなく情熱を傾けるべきことに集中することができます。

　幸いにもエストニアはすでに起業家の成長を支えるようにデザインされた納税の仕組みをもっています。例えば、エストニアで納税義務のある法人は利益分配後に定率で課税されます。そのため再投資をした金額を除いた利益にのみ課税義務が発生します。

　起業家にとって魅力的なのは税制だけではありません。税金を支払うこと自体も容易です。私たちはEstonian Tax and Customs Boardが提供するソリューションに大変な誇りを持っています。すべてオンラインで行うことができ、国民、住民や仮想住民に提供されている安全なデジタルIDによって完全に統合されているからです。オフィスがウレミステにある私たちの事務所の隣であろうと、地球の反対側にあるビーチカフェにあろうと、どこからでも利用することができます。

　しかし、現在のシステムは数年前にオフラインサービスのオンライン版としてデザインされました。政府の多くのレガシーシステムと同様に（当時としては当然ながら）役人のニーズを重視して設計されたものです。

　新技術は会計士、中小企業や大企業のようなユーザーを中心にデザインし、もっと革新的なシステムの構築を可能にします。たとえば私たちはより多くの言語を追加し、レスポンシブでモバイルフレンドリーなデザインを使用し、すべてのプロセスが可能な限り論理的でわかりやすくなるように心がけています。

　私たちの目的は快適なセルフサービスの納税環境をすべての納税者のために構築することです。またデータの収集と分析を改善し、起業家に貴重な経済情報をリアルタイムで提供できるようにします。

　新しいe-TaxおよびCustoms Boardポータルの開発は2020年末までに完了する予定です。そして、今年から私たちはすでに新しいサービスの段階的な導入を開始し、フィードバックを求めています。

　私たちは自国の税金の仕組みを改善するだけではありません。私たちの国は欧州連合理事会の議長を務めています。その中でデジタル経済の発展を考慮し、誰にとってもより中立的、公正かつ透明になるようにヨーロッパ全体の税制を洗練させる一助となるように努めています。

　私たちはまた国をまたがる税金を自動的に分けるような国際税制を模索する初期段階にあり、課税対象の住民でなくとも私たちの税務サービスを利用できるようになるのではないかと期待しています。これにより世界の起業家への手間がさらに軽減されると同時に各国が公正な税収入を得られることができます。私たちはこのアプローチのパイロットに関心のある他の国の税務当局と常に話したいと思っています。

　最後に、仮想住民の方々が実際に住む国によって異なる納税義務を簡単に理解できるような支援を含むe-Residencyプログラムも同時に開発しています。

　このように私たちはエストニアの税務サービスをできるだけ多くの仮想住民の方々に活用していただけるよう支援していきたいと考えていますが、皆さんの税金義務は国際税規則に基づいています。次にその概要を説明します。

納税義務を理解する

　あなたとあなたの会社が一つの国に籍を置き、その国で価値を明確に生み出していれば、あなたの税務上の居住地は簡単です。

　しかし、特定の場所に依存しないデジタル遊牧民のような起業家である場合、国際納税義務を決定することは大変です。

　この問題は居住地に関わらず国境を越えてビジネスを行うすべての人に影響を及ぼします。e-Residencyは企業がどのように運営されているかをより透明にし、負担している税金を簡単に支払うことで、このようなグローバルな課題への解決策となる可能性があります。

個人税

　最初に個人に対する税金について説明します。国際課税に関するオンラインでの議論されていますが、個人の税金と法人に対する税金について混同されていることが大き見受けられます。

　あなたの個人の税務居住地とあなたの会社の税務居住地は違うことがあります。税務居住地を決める基準が個人と法人では異なります。あなたの個人の状況とあなたの会社の状況も異なるでしょう。

　個人として納めている税金は個人が在籍する税務居住地での幅広いサービス（医療福祉や年金など）のために納められています。このようなサービスは私たちのようなデジタルな国家から提供される可能性もありますが、それはまだ遠い将来の話です。

　それぞれ国によって個人の税務居住地を決める方法がありますが、通常は1年のうち6ヶ月以上住んでいることが条件です。 エストニアでは12ヶ月以上連続して183日以上住んでいると税務居住者となります。税務居住者となる場合は居住者としてデジタルIDを持つことになるので、e-Residencyで仮想住民として登録する必要はないでしょう。

　デジタル遊牧民のような起業家はこの基準を満たすに十分の期間をどこか一つの国で過ごすことがないケースがあります。その場合は税務居住地は、通常その人の「母国」とみなされます。

　デジタル遊牧民は自らを特定の地域に縛られないと考えていますが、多くの人たちは実際には「母国」に籍を持つので、考慮しなければいけないことは多いにもかかわらず個人所得の税務居住地を決定することはそれほど難しいことではありません。

　税務上は「国にいない」のと「国に住んでいない」のは一般的に同じこととみなされます。たとえば休暇で海外に出かけても個人の税務居住地に影響を与えません。それがどれだけ長期間旅行に行く場合でも、特に帰国できる住所がある場合は、同じです。

　移動し続けることで特定の場所で税務居住者とならないことは技術的に可能ですが、それは思っているよりも達成するのが難しく、その労力に見合うものではありません。また、社会保障、信用格付、現在と将来の公共サービスを受ける権利など多くの利益をあきらめなければいけません。更に訪れた国すべてのルールを確認しなければいけません。

　まれにではありますが、二か国で税務居住者とみなされることもあります。しかし、個人も法人と同様に二重課税を回避する条約によって保護されています。

　企業が個人に賃金を支払うとき、個人に対する税金は税務上居住地の規則に沿って、その収入に対して納められます。会計士はこのプロセスがスムースに進むことをお手伝いします。e-Residencyのウェブサイトはビジネスサービスプロバイダのリストを掲載しており、仮想住民に特化した会計サービスを探すことができます。

法人税

　法人税はその会社の税務居住地で納められます。

　国際税法は国際ルールに基づいていて、国際的に運営されている企業に一般的なアドバイスを提供することを難しくしています。その会社がどこで登記されていようと、創業者である起業家が個人的にどこに住んでいようと、税金がどの国に納められるべきかは一国で決められるものではありません。

　法人の納税居住地はその企業固有の状況に依存しているため、納税義務（税務居住地のみか恒常的な拠点を持つ他の地域を含むのかなど） 将来どの税務当局にも問題が発生しないように納税する必要があります。

　納税義務について疑問がある場合は、資格を持つ税務アドバイザーに相談すべきです。また、いつでも私たちにコンタクトしてください。

　まず第一にエストニアのe-Residencyを通じて設立された企業は、自動的にエストニアが税務居住地となります。 また課税所得の源泉があれば、法律に従って他の国でも納税義務が発生します。

　幸いにもエストニアはすでにすべてのEU加盟国とほとんどのOECD加盟国、仮想住民が急速に増えているウクライナやトルコを含む57カ国と二重課税の回避のための条約に署名しています。全リストはこちらから入手できます。

　個人の税務居住地と同様に法人の場合も居住地を決定するための基準が国によって異なりますしかし、一般的なルールとして、ほとんどの税制は価値が生まれた国で税金を支払うという原則に基づいています。 例えば恒久的施設（PE）という用語は国との経済的なつながりを決定し、税務上のしきい値として使われます。

　あなたの会社がある国で強い存在感がある場合、法人としての税務居住地は簡単に決めることができます。しかし、あなたの会社が複数の国にまたがって運営されている場合、あなたの会社が置かれている独特な状況を見ることができる資格のある税務アドバイザーから助けが必要になるでしょう。これは小さな会社や創業者一人の会社も影響を受けます。旅行と出張を同時にしたり、国境を越えて協力している可能性もあるためです。

　あなたの会社の状況（そして納税義務）は時間とともに変化する可能性があることも忘れないでください。

　e-Residencyのウェブサイトではビジネス・サービス・プロバイダーのリストを掲載しています。このリストは他の仮想住民から推薦されており、 起業家の約90％はこのようなサービスを利用しています。

　あなたのエストニアの会計士はあなたの税務居留地として異議申し立てをしそうな国の税務専門家とも話すようにアドバイスをするでしょう。長期的に2カ国で2人の会計士が必要になるわけではありません。しかし、一度訪問は賢明な投資である可能性があります。また、あなたはいつでも私たちのチームに話すことができますし、それは無料です。

　次に、実際に国際課税がどのように機能するかいくつかの例をあげて見てみましょう。

例

• Jaakoはフィンランドのヘルシンキに住み、Venlaはエストニアのタリンに住んでいます。彼らは一緒にeコマースを設立。世界のどこからでも顧客に製品を販売したいと考えています。会社とVenlaの税務居住地はエストニアです。そしてJaakoはフィンランドが税務居住地で、エストニア企業の外国従業員として個人所得税をフィンランドで納めています。Jaakoは税務アドバイザーとフィンランドの税務署と相談して、エストニアにある彼が共同創始者の会社に法人として課税義務があるかどうかを確認しました。フィンランドのエストニアとの租税条約により二重課税のリスクはありませんでした。

• Katerynaはウクライナのキエフに住んでいて、キエフで起業しました。彼女はPayPalビジネスアカウントを開設するためにe-Residencyで彼女のスタートアップを運営しています。それによりEU市場にアクセスし、ユーロで取引し、世界中の顧客とより簡単にビジネスを行うことができます。同社はウクライナですべての価値を生み出しているため、税金はウクライナに納められていました。しかし、Katerynaはビジネス機会がEU内にあること発見し、彼女はエストニアのスタートアップビザプログラムに応募。審査に通り彼女のスタートアップをタリンに移転し、自らもエストニアに移り住みました。そうすることによりKaterynaは現在の居住地であるエストニアで法人税と個人の所得税を納めることになります。1年後にKaterynaは彼女の最初の物理的なオフィスを開設し、最初の従業員を雇うことができるほどに会社を成長させることができました。人材プール、コスト、地元の知識など鑑みて将来の成長を考えるとキエフがよさそうです。そして、ウクライナに恒久的施設（PE）を持ち、再びウクライナで税金を納めることになりました。エストニアとウクライナの両方が彼女のスタートアップの成功に重要な貢献を果たしていますが、両国間の租税条約により二つの国から同時に課税されることはありません。

• Steveは英国のマーケティングコンサルタントです。彼は色々な国を旅をしながら、彼自身が唯一の従業員である彼の会社で「デジタル遊牧民」として働いています。彼はe-Residencyを通じて彼の会社を設立しました。それにより、どこにでもオンラインで会社を運営することができる真の意味でのロケーションフリーな企業となります。また、英国で登記するより運営コストがやすくなりました。彼は有名なエストニアのスタートアップシーンである#estonianmafiaを含む世界中の他のフリーランサーとともに働いています。 スティーブの個人としての税務居住地はまだ英国にあり、彼はそこで彼の医療と年金に貢献し続けることができます。一方で彼の会社はエストニアで設立され、エストニアが税務居住地となります。他の国には税金の納め先に関する異議申し立てもありません。Steveは外国人従業員としての給料に対してイギリスで所得税を納め、彼の会社は配当金からエストニアの法人税を納めています。

免責事項：ボク自身は税金の専門家じゃないので、詳しくは専門家にちゃんと聞いてね！

関連記事