ネットワークコンピュータ時代には「ファイル」というメタファは一般からは失われ透過的なものになる。URLも適切というわけではないが、ファイルやURLも自然に使える人たちの中から徐々に変化していく。何より自分の親にWindowsの使い方を教える時に一番難しいのは「ファイル」というメタファだった。

フロッピーディスクからファイルを読むのは直感的だが、それはフロッピーディスク＝ファイルだと思ってるから直感的だったのであって、HDDやWebにファイルが存在するのは直感的ではない。

ファイルは、頭と終わりという区切りをもった「データ」でしかないのを、無理やりアイコンにマッピングしているのがGUIのOSだとすると、そのメタファ自体は古いものになるだろう。

スマートフォンで「ファイルを扱うこと」の気持ち悪さについて感じたことはないだろうか！？ドロップボックスアプリにあるファイルを、そのまま開くことに関してはメンタルモデルとして「そうしたい自分がいる」ので違和感はないが、そのファイルをローカルフォルダという中間状態に置いて別アプリから読み出すアプローチはイメージがわからないし、そういう実装になっていない。「写真」はファイルではなく「写真」として扱われていて、アルバムを読み書きするという表現になっている。

Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編） － Publickey

Immutable Infrastructureも言ってみればServletコンテナ（JVM）とjarファイルの関係だと思っているが、アレが古くて、コレが新しいという部分は、古い考え方としてはJarファイルは特定の時点のスナップショットでしかないという部分であり、新しい考え方は、GitHubなどのコラボレーションサービスがデータ流通のハブになっていることだろう。これにより流れるデータが「常に最新の」動的なものになっている。有機的と表現しているのかな。気がついてみたら、自動的かつ継続的にdeploymentしてくれるシステムとは、そこの上で人と人とがコミュニケーションし、ソースコードが管理され、テストを通じてjarファイルを自動的に整えてくれて、サーバに配備してくれるシステムのようになっている。しかしjarファイルのようなものは存在せず、GitHubのURLから落としてくるという行為で透過的に扱われている。バージョン管理システムは、もはやただのファイルの変更履歴管理システムではない。

jar(war）ファイルによるWebアプリのdeploymentがスタートアップやベンチャーにしっくり行かなかったのは、頻繁なリリースの中で「今回は更新しなくて良いファイル」もdeploymentのミスで危機に陥れる可能性があったところだと思うし、昔の安価なservletコンテナだと、コンテナ自体の再起動が必要だったりしてワークフローと馴染まなかったからだ。今となっては「思想は正しかったが、環境が実現できなかった」。Immutable Infrastructureの前提となるソリューションが、テストファーストやAWSも含めて見事に解決してくれそうだ。

ファイルをファイルとして意識させずにリソースとして使わせるのはMSもWindowsで同じことを目指してたし、Macは最初からこういう意識だったと思うが、オフラインを前提とし「コピー」と「移動」というアーキテクチャを昇華させるのはイマイチしっくりいかなかった。スマホにせよGitHubにせよネットワーク常時接続時代のアーキテクチャで自然に使われ始めているのが、「アーキテクチャ＝哲学」の難しさであり、面白いことだと思っている。MSが脱Windowsに流れ始めているのも、あくまでもファイルシステム＆ウインドウメタファの最強OSであったWindowsが、ネットワークOS時代にしっくり行かなかったという現れなのではないだろうか。あれほどの強大なブランドを持ってしても超えられない壁。これがアーキテクチャの変革なのか。一歩一歩ネットワークOSの時代へ進んでいる。