Dropboxの有形固定資産から、ファイル共有サービスビジネスを分析する
どうも。田舎野郎です。
田舎野郎のくせに、なんとな〜く分析とかしちゃいました。アドバイスや感想等ありましたら嬉しいです。お手柔らかに頼みます。
ファイル共有サービスのビジネスを分析してみました。記事の半分は分析で、もう半分はメモなのですぐ読み終わると思います。
全然関係ないけど、日本語でのBoxの発音はボッ↑クス↓ではなく、Boxボッ↓ク↑スらしいです。
ファイル共有サービスの有形固定資産
SaaS企業３社比較してみました。SaaSとはいえ、貸借対照表の資産構成が全然違うことに気づきました。
３社ともSaaSですが、ファイル共有サービスを提供するDropboxとBoxの資産構成が非常に似ています。
Zoomと大きく異なる点で目を引くのは固定資産、その中でも以下の図で赤枠で囲んでいる有形固定資産の比率だと感じました。
そこで、主にDropboxの有形固定資産に着目し、なぜ有形固定資産の比率が高いのか、それがどのように強みにつながっているのかを分析してみました。
有形固定資産の中身はデータセンター関連
有形固定資産の中身は一体何でしょう？
まずは、３つの企業の有形固定資産の内訳を並べました。
額の違いはあれど、中身はデータセンター、コンピューター関連の比率が高いことがわかります。
よって、有形固定資産比率が高いDropbox、Boxはデータセンター関連の固定資産を多く持っていることがわかります。
データセンター関連資産はコストとUX最適化のため
ではなぜデータセンター関連資産を多く自社保有しているのでしょうか。
Dropboxを例に説明します。理由は２つあると思います。
理由①コスト
Dropboxはサービス提供のランニングコストを下げるため、データセンター関連資産、具体的にはサーバーやストレージ機器を多く自社保有しています。
サービス提供基盤をパブリッククラウドの王者であるAWSから、自社基盤に切り替え、ランニングコスト削減につながった話があります。
脱クラウドを大規模に実行した企業として知られるのがDropboxだ。同社は2008年に同名ファイル同期サービスの正式提供を開始してから約7年が経過した2015年に、Amazon Web Services（AWS）の同名クラウドサービス群のクラウドストレージ「Amazon Simple Storage Service」（Amazon S3）で保管していた膨大なデータを、オンプレミスのストレージシステムに移行した。事業が成長を続ける中、AWSでインフラを拡充するという選択はしなかった。（引用：Dropboxはなぜ「AWS」からオンプレミスへの回帰を選んだのか）
コストだが、前述のDropboxの事例でも、それが移行の大きな理由となっている。実際に同社の場合、オンプレ回帰によって2年間で7500万ドル（約81億円）のコストを削減できたと報じられている。（引用：海外で進む「オンプレミス回帰」 その背景に何があるのか）
理由②UX
Dropboxは、ユーザーのファイルアクセス頻度やファイルサイズに最適なシステムを設計するために、自社サービス基盤を構築しました。
アクセスされる頻度が高いファイル、低いファイルに分けてシステムを最適化し、ユーザーが使いやすい設計にしていることがわかります。
Dropbox公式HPに以下の説明と図がありました。
Dropbox で行われるファイル アクセスは、全体の 40 % 以上が前日にアップロードされたデータ、全体の 70 % 以上が前月にアップロードされたデータ、90 % 以上が前年にアップロードされたデータです。（引用：Magic Pocket をコールド ストレージ向けに最適化）
Dropboxのサービス基盤を担当していた方の言葉です。
コーリング氏は「Amazon S3は複数の企業に対して1つのストレージシステムを提供するが、Dropboxは自社サービスのユーザーに最適な1つのストレージシステムを必要としていた」と説明する。（引用：Dropboxはなぜ「AWS」からオンプレミスへの回帰を選んだのか）
Boxも同様の理由で、自社でサーバ等を多く理由していることが有形固定資産比率の増加に寄与しているのだと思います。
Zoomの有形固定資産が小さい理由は、パブリッククラウド
Zoomはサービス基盤を自社で保有するのではなく、AWSやMicrosoft Azure、Oracle Cloud Infrastructureなどのパブリッククラウドを主に利用しています。
パブリッククラウドをサービス基盤として使う場合には、貸借対照表の資産として計上されません。代わりに、毎期の費用として損益計算書に計上されます。
これが、Zoomの有形固定資産の小ささを物語っているのだと思います。
この影響がZoomの損益計算書にどれほどあるのかは、また今度気が向いたら書きたいと思います。
分析まとめ
DropboxやBoxの有形固定資産が多い理由は、サービスの基盤であるサーバーやストレージを自社保有しているからです。
自社保有する必要がないパブリッククラウドの選択肢がありながら、なぜ資産として保有しているのか。それは、ランニングコストとUXの最適化のためでした。
Boxも似たような資産構成であることから、ファイル共有サービスの強みの源泉は、有形固定資産のデータセンター関連資産にあるのだと思います。
おまけ
本記事ではDropBoxとBoxをファイル共有サービスとひとまとめにしてしまっているますが、お互いにマーケットがもろかぶりの競合として認識しているわけではないっぽいです。
Dropboxの10-Kには、「Boxも限られてはいるけれど、競合っちゃ競合です」って書いある。
一方Boxの10-Kには、「ファイル同期・共有サービスにおいて、Dropboxも程度は小さいけれど競合してる」と書いてある。
２つの違いは、Dropboxはローカル保存、同期、クラウドを意識させない、Boxはクラウド保存、管理重視、絶対クラウドといった点が違うらしいです。こちらのnoteがわかりやすかった（クラウドストレージ DropboxとBox）。
分析は以上になります。ありがとうございました。
後述する内容はメモ。
AWSからオンプレミスへのデータ移行
エクサバイト級のデータ移行作業だから、ものすごいことっぽいな。
当初選択肢は２つあったらしい。
１つ目はハードを物理的に移動。これは、ダウンタイムを無くす、セキュリティの観点から採用せず。
２つ目はAWSのDCからオンプレミスがあるDC（コロケーション）にネットワーク経由でテータ転送。
毎日約5PBずつのデータを転送し、移行対象の全データを転送するのに約半年を要した。もちろんネットワークだけでなく、オンプレミスのデータセンター側で受ける膨大な数のストレージも必要だ。ストレージ搬入用のトラックが事故に遭遇するなど想定外のトラブルもあり、コーリング氏は「かなりの集中を要する期間だった」と振り返る。（引用：Dropboxはなぜ「AWS」からオンプレミスへの回帰を選んだのか）
Dropboxに特化したMagic Pocket
Western DigitalのHDDを採用している。ベンダーロックインを避けている。
Dropboxはオンプレミスのデータセンターに導入する製品については、可能な限りマルチベンダーにすることを重視しているという。この方針はHDDやSSDなどのストレージに限らず、マザーボードやネットワークカード、CPU、メモリといった「ハードウェア全てに適用するように努めている」とコーリング氏は強調する。ハイブリッドクラウドの採用と同様、これも特定の環境やベンダーにロックインしない考え方の表れだと言える。調達先を複数社にすることによるリスク分散の効果もある。（引用：Dropboxがオンプレミス回帰後も「AWS」を使い続ける理由）
Magic Pocketが採用したSMR方式のわかりやすい解説。
「SMRは集約化できるが、書いたり、消したり、変更が多いものに関しては向かないということもある。われわれがSMRを選択した背景としては、ファイルを変更する時間帯が限られており、新規ファイルをDropbox上にアップロードした直後が一番多くの変更があり、時間の経過とともに変更されなくなる。そのため、最初の段階をケアすれば、それ以降は変更されることは少ないことからSMRを採用した」（引用：なぜ、DropboxはAWSから自社システムに乗り換えたのか?）
詳しい内容は、Dropboxの公式HPで解説してくれている。すごい。（Magic Pocket をコールド ストレージ向けに最適化）
ローカリゼーションのためにパブリッククラウドを使う
AWSからオンプレミスへ大規模移行をしたものの、今もAWSを使っている。
以下は2019年度10-Kから抜粋。メインはアメリカにあるコロケーションDCを使い、日本を含めたいくつかの地域ではAWSを利用している。ローカリゼーションが理由。
AWSの日本リージョンを使用する理由は、ユーザー企業のデータ活用ポリシーに合わせてのこと。
Dropbox Businessを使う法人ユーザーから寄せられた「業務ファイルを国内のサーバー環境下に置きたい」という要望を受けたもの。Dropbox Japanの五十嵐光喜社長は、「（ストレージサービスの）インフラとなるネットワークにも投資することで、お客さまからもっとも多く寄せられた要望に応えられる」としている。（引用：Dropbox、法人向けに国内データ保管サービス 今夏から 個人向けにも新施策を準備中）
分析のためにパブリッククラウドを使う
Long-time AWS customer Dropbox recently migrated a 34 PB analytics data lake from on-premises Hadoop clusters to S3. （引用：Amazon S3 Update – Strong Read-After-Write Consistency）
AWS Snowball を使用して大量データをS3に移行に記載されている方法とかでデータ移行したのかな。こんな感じでストレージにデータを入れてから、AWSのDCにストレージを直接移動させるんだね。
おわり。
※ぼくはエンジニアではありません。
この記事が気に入ったらサポートをしてみませんか？