Macの登場以来、Appleはファイルシステムとの闘いを着実にエスカレートさせてきました。ファイルを階層的に整理する機能は、オペレーティングシステムが登場して以来、オペレーティングシステムの柱であり続けてきました。しかし、Appleの優秀な開発者たちは、Packagesの導入に始まり、iOSにファイルシステムを操作するためのユーザーインターフェースが全く存在しないという状況に至るまで、Apple製品の進化ごとにこのアプローチを常に否定してきました。
これは、ファイル システム自体が iPhone や iPad から消えたということではありません。iOS の洗練されたユーザー インターフェイスとクラウドベースのドキュメント ストレージの下では、ファイルとディレクトリが引き続き、データを整理するための基本構造を提供しています。
Appleがファイル中心のユーザーエクスペリエンスから、 ドキュメントという概念に厳密に基づくエクスペリエンスへと移行するという決定は、ファイル管理の責任をユーザーからアプリへと移行させるものです。そして、Appleのこの新しいアプローチの重要な副作用は、各アプリがファイルを完全に制御できる制限されたサンドボックス内でのみ動作することを制限することです。
ファイルに別れを告げ、ドキュメントにこんにちは
iOSにユーザーがアクセス可能なファイルシステムが存在しないという点に対する反応は様々です。iOSは高度に区分化された環境を実装しており、各アプリは独自のサンドボックス内で動作します。ドキュメント中心のアプローチは比較的うまく機能しています。これは、Appleがユーザーエクスペリエンスをこのモデルに合わせて細部までカスタマイズできたことに大きく貢献しています。iOSは全く新しいクラスのデバイス向けにゼロから構築されたため、開発者は従来のオペレーティングシステムのパラダイムのサポートについて心配する必要がなかったのです。
技術的な観点から見ると、このアプローチには多くの利点があります。まず、各アプリが自身のコンテンツを直接管理することになります。これにより、開発者は、例えばどのデータをキャッシュ、バックアップ、iCloudに同期するかなど、高度な制御が可能になり、アプリのストレージ使用量を最小限に抑えることができます。
同様に、アプリを専用のサンドボックスに閉じ込めることで、ファイルシステム全体への影響を抑えることができます。従来の環境では、ソフトウェアはハードドライブ上の様々なディレクトリに様々な「デジタルデータ」を残す傾向があり、設定や共有フレームワークなどのデータは、ユーザーがアプリをコンピューターから削除しようとした後も長く残ってしまうという悪癖があります。iOSではすべてが専用のコンテナにきちんと閉じ込められているため、アプリとその残骸を削除するのははるかに簡単です。
サンドボックスはコンピューター向けであり、人間向けではない
これらの技術的利点の裏返しとして、平均的なユーザーの実際のニーズが無視されてしまうことがあります。例えば、iOSではサンドボックス化によって重複が発生することがよくあります。アプリは割り当てられたディスク領域内にあるファイルにしかアクセスできないため、2つのソフトウェア間でデータを共有する唯一の現実的な方法は、悪名高い「送信」機能を使うことです。この機能は、ドキュメントのコピーを作成し、一方のアプリからもう一方のアプリに渡すことになります。
多くの人が指摘しているように、このアプローチでは複雑なワークフローの作成が非常に難しくなり、同じドキュメントが複数の場所に、しかも完了状態が異なる状態で表示される傾向があります。
これは必ずしも悪いことではありません。ドキュメントの所有権を特定のアプリに関連付けることの興味深い副作用は、後者がドキュメントの管理の全責任を負うことです。デスクトップオペレーティングシステムでは、私たちは無意識のうちにドキュメントをそこに含まれるデータの種類に基づいて考えるようになり、アプリが直接所有していないファイル形式とも相互運用できることを求めています。
例えば、Word文書をPagesで開こうとした時に、変換中に書式設定の半分が失われてしまった経験があるなら、私の言っていることがよく分かるでしょう。AppleがMicrosoftが完全に所有するファイル形式の細部まで全て把握することは不可能ですし、Microsoftが独自の方式で保存されたデータを第三者が読み取ろうとする際に起こりうるミスを心配する必要もありません。
iOSの送信機能は、欠点はあるものの、開発者にドキュメントを単に「保存」するのではなく、別のアプリに渡しているという事実を理解させるよう求めます。これにより、開発者は受信側アプリがデータの意味を推測する必要のない中立的なフォーマットを選択できるようになり、その過程で、開発者はユーザーに、もし失われる機能があれば、その機能について説明できるようになります。
それでも、ニーズが非常に単純な場合を除き、iOS のドキュメント保存に対する分散的なアプローチは、解決しようとしている問題と同じ問題を引き起こすことになります。
人間と同じように考える
この問題は、単純な問題に帰着します。サンドボックス モデルは技術的な観点からは理にかなっており、多くの利点をもたらしますが、人々の働き方を反映していません。
私の仕事のやり方を考えてみると、私の活動は「プロジェクト」という概念を中心に展開していることは明らかです。プロジェクトとは、この記事のようにテキストと数枚の画像で構成されたシンプルなものから、（少なくともOS Xでは）Xcodeプログラムのように6つのアプリから生成されるデータを含む複雑なものまで、多岐にわたります。
いずれにせよ、多くのアプリがますます特化している現状を考えると、単一のアプリを使うプロジェクトは珍しいと言えるでしょう。同時に、私が直接行う作業でファイルシステムを必要とするものはほとんどありません。大規模なプロジェクトでは、データを区分けするためにフォルダを使うこともあります。例えば、すべての画像を一箇所にまとめるなどです。しかし、これはあくまで便宜上の理由からであり、その作業はオペレーティングシステムに任せたいと考えています。
そのため、このようなプロジェクトベースのモデルは、iOS自体に組み込まれればうまく機能するだろうと私は考えています。このオペレーティングシステムでは、ユーザーが「ワークスペース」を作成し、複数のアプリがそれぞれのデータを保存できるようにすることができます。内部的には、ワークスペースはサンドボックス化され、各アプリがそれぞれのファイルに排他的にアクセスできるようになりますが、同時に「共通」領域も備え、アプリが互いの情報を自由に読み取ることができるようになります。
例えば、Photoshopのようなアプリは、ワークスペースのサンドボックス領域に、フィルターやレイヤーなどのAdobe固有の機能がそのまま保持され、外部からの干渉から保護された編集可能なバージョンの画像を含む独自のPSDファイルを保存できます。同時に、JPEGやPNGなどの一般的に理解されている形式で、読み取り専用バージョンの画像をワークスペースの共通領域に保存することで、他のアプリが元の画像の整合性を損なうことなく簡単に使用できるようになります。ユーザーが例えばPagesドキュメントをワークスペースに追加すると、その画像はすぐに利用可能になり、元のドキュメントが変更されるたびに自動的に更新されます。
時代を超えたファインダー
このアプローチはデータを一箇所にまとめ、コンピュータではなく人間にとって分かりやすい方法で分割することを容易にします。また、内部的には従来のファイルシステムに依存していますが、エンドユーザーにはその複雑さが一切感じられず、Appleのシンプルさと使いやすさという使命を満たしています。
さらに整理すると、ワークスペース自体を Apple 自身が提供する専用アプリで管理できるようになります。このアプリの役割は、ワークスペースを「所有」し、ユーザーがワークスペースを整理して iCloud に同期できるようにすることです。これは、今日のファイルやディレクトリだけでなく、より高度なデータを扱う、ポスト PC 時代の Finder です。
これにより、このアプローチを OS X に移植することが容易になります。OS X では、今日のサンドボックスの制限がさらに顕著になっており、ファイル システムへの自由なアクセスに基づく 30 年間の遺産を単純に無視することはできません。
もちろん、これがAppleの進む方向なのかどうかは私には分かりません（そう願っていますが）。しかし、現在のサンドボックス化は、ユーザーに重大な制限を強いるという理由だけでも、より良いものへの足がかりに過ぎないと確信しています。
それでも、従来のファイル システムに戻ることは、サンドボックス化によってもたらされた多くの革新を無駄にする後退のように思われます。結局のところ、ある賢者が別の賢者から引用した言葉にあるように、パックがある場所を見つけて、そこに滑るということになるでしょう。
