任天堂で活躍されたクリエイターの横井軍平氏の「枯れた技術の水平思考」という言葉があります。以前、宮本茂氏の「ゲームは2度作ると良くなる」という言葉について記事を書きましたが、任天堂のものづくりの言葉には学びが多いと感じています。
そもそも「枯れた技術の水平思考」とは
初見の方向けに、まずこの言葉自体を説明します。「枯れた技術」とは、登場から時間が経ち、広く使い込まれて問題点が出尽くし、安く安定して手に入るようになった技術のことです。「水平思考」とは、その技術を本来の用途の延長線上(垂直方向)で高度化するのではなく、まったく別の用途(水平方向)に転用する考え方です。つまり、最先端を追わず、こなれた技術を誰も考えなかった使い方で製品にする、というのが横井氏の思想です。
水平思考の代表例が2つあります。
1つ目は1969年の「ラブテスター」です。皮膚の電気抵抗を測るという技術は、当時すでに嘘発見器などで使い古された、新しさはないものでした。横井氏はこれを「男女が手を握り合って愛情度を測る」という玩具に転用します。技術としては枯れきっていますが、「手をつなぐ口実になる」という用途の発明で大ヒットしました。技術の新しさではなく、使い道の新しさで勝った例です。
2つ目が1989年の「ゲームボーイ」です。当時すでにカラー液晶は存在していましたが、横井氏はあえて白黒の反射型液晶と、当時としても新しくはない8ビットCPUを選びます。その結果、本体は安価で、乾電池で数十時間遊べる携帯ゲーム機になりました。直後に登場した競合のゲームギアなどはカラー画面という先進性で対抗しましたが、電池が数時間しか持たず価格も高く、市場から消えていきました。スペック競争を降りて、枯れた部品で「携帯機に本当に必要なのは電池持ちと価格だ」という別の土俵を作った例です。
このように「枯れた技術の水平思考」は、技術で勝つのではなく、枯れた技術の安さと信頼性を土台に、用途の発明で勝つという考え方です。
ソフトウェアではそのまま成り立つのか
新規事業やプロダクト開発に携わる中で、この格言をソフトウェアの世界に当てはめて考える機会がありました。考えていくと、応用には少し考え直さないといけないことに気づきます。この記事では「枯れた技術の水平思考」のソフトウェア時代での応用方法と、ソフトウェアでは優位性の源泉が「枯れかけ」にあるのではないか、という話を書いてみます。
技術の「枯れ方」は3段階に分けられる
まず、技術を一括りにせず、枯れているかの成熟度で3段階に分けて考えてみます。
第1段階は、完全に枯れた技術です。 圧縮、暗号プリミティブ、JSONパース、RDB、HTTPスタックなどがここに入ります。これらは選定さえ間違えなければよく、自作はむしろ事故のもとです。ほとんどの場合、議論の余地なく標準品を使うのが正解です。
第2段階は、枯れかけの技術です。 音声認識、OCR、機械翻訳、TTS、BLE、位置情報、アプリ内課金などです。一発の精度、つまりコアの性能は枯れているのですが、連続運用時の状態管理や他システムとの統合がまだ枯れていません。「仕様書は短いのに、実装は大変」という領域です。
第3段階は、新鮮な技術です。 自律操作AI、リアルタイム音声対話などです。そもそも枯れた答えが存在しません。先に設計を固めても外れるので、動くところまで作ってから設計を決めるべき領域です。
なお、この分類は時点に依存します。技術は段階の間を移動し続けるからです。たとえばLLMの中でも、単純なプロンプト呼び出しやRAG、ワークフローに基づくAIエージェントなどの定番パターンはすでに枯れかけへ移りつつあり、自律操作AIのような領域が新鮮の側に残っています。どの段階にあるかは、その都度判定するものだと考えてください。
実務的には、第1段階は議論せず標準品を使う、第2段階は精度チューニングよりも失敗時のUXに投資する、第3段階は設計より先に手を動かす、という指針になります。
横井氏の理論をWebとソフトウェアに適用するには注意が必要
もともとの「枯れた技術」の効能は2つありました。①部品が安いこと、②リスクが洗い出されていること、です。
ハードウェア中心時代には、枯れた部品を使ってもなお、量産能力や流通網が参入障壁として機能しました。枯れた技術を使いこなせること自体に、まだ希少性があったわけです。
一方WEBとソフトウェアでは、枯れた技術は限界費用ゼロに近く全員に同時に配られます。OSSとして、マネージドサービスとして、標準APIとして。つまり①の希少性が消えやすい。「枯れた技術を使えること」は優位性ではなく、前提条件になったと考えています。第1段階の技術では、差がつきにくいと考えたほうが良いでしょう。
「枯れかけ」には一時的な障壁がある
ではどこが使いやすいか。第2段階、枯れかけの状態だと考えています。
枯れかけの技術の統合の痛み、つまりドキュメントに書かれておらず踏まないと分からない知識は、少なくともそれが枯れるまでの間は、限界費用ゼロでは複製されません。実装した者だけが持つ資産になります。しかも②の効能、失敗モードが列挙できるという性質は、枯れかけの時点ですでに手に入ります。失敗モードが分かっていれば、失敗時のUXを設計できるからです。
新鮮な技術にはこれがありません。失敗モードすら未知で、さらにプラットフォームの進化に工夫ごと吸収されてしまう「ラッパー問題」もあります。登場したばかりのAPIに薄いラッパーを被せたプロダクトが、次のアップデートで本体に飲み込まれるのはよく見る光景です。
ただし、枯れかけの障壁は償却資産のようなものです。プラットフォームは数年で統合の痛みを吸収していきます。新しいOS標準APIが出た瞬間に、旧APIで積み上げた苦労が丸ごと消える経験をした方も多いのではないでしょうか。
そのため、枯れかけ戦略の本質は「時間差を買う」戦略です。窓が開いているうちに、データ、ユーザーの習慣、ブランド、ドメイン知識といった、枯れない障壁への転換を済ませる必要があります。
Dropboxを「枯れかけの水平思考」として分解する
この枠組みで見ると、ファイル同期サービスのDropboxは、「枯れかけ」の性質がはっきりした事例に見えてきます。
ファイル同期サービスで使われる、変更された部分だけを効率よく転送する技術には、1996年に発表されたrsyncのアルゴリズムなど先行技術がありました。圧縮、ハッシュ、差分検出、ファイルシステムといった構成要素も、いずれも枯れた技術です。
さらに2006年にはAmazon S3が登場し、耐久性のあるストレージをAPI経由で利用できるようになりました。Dropboxがベータ公開された2008年には、AWS自身がDropboxを「S3-powered」と紹介しています。つまり、小さなチームでも、世界中からアクセスできるファイル保管サービスを、巨大なストレージ設備を所有せずに構築できる条件が整い始めていました。Amazon S3の2006年の発表、AWSによる2008年のDropbox紹介
しかし、「ファイルをサーバーへ送ること」と「どの端末でも、いつ見ても、同じフォルダになっていること」の間には大きな隔たりがあります。
ユーザーはオフラインの間にもファイルを編集します。別の端末では同じファイルが更新され、フォルダが移動され、一部の通信だけが失敗します。アップロードとダウンロードが並行して走っている最中にも、ユーザーはファイルを削除したり名前を変えたりします。さらにWindows、macOS、Linuxでは、ファイル名、権限、通知APIなどの挙動も異なります。ほとんどの時間に正しく動くだけでは不十分で、一度の誤判定がユーザーの大切なファイルの消失につながります。
これはまさに、一発の処理は枯れているが、状態を持って連続運用すると急に難しくなる、第2段階の技術です。
Dropbox自身も後年、同期エンジンについて、「双方向同期には多くの例外的なケース」があり、それはDropboxでは通常のユースケースであると説明しています。長期間オフラインだった端末が復帰し、複数の変更を矛盾なく統合する必要があるからです。「同期処理は非常に並行性の高い問題であり、並行コードのテストとデバッグは極めて困難である」とふりかえっています。Dropboxの同期エンジン解説
Dropboxの初期の障壁は、「何も考えずDropboxフォルダに入れれば、いつの間にか全端末で同じ状態になる」という単純な体験の裏側で、ユーザーに見せずに例外を処理できることでした。ドキュメントには書かれておらず、実際に大量の端末とファイルを同期しなければ分からない統合知識が、複製されにくい障壁になっていたと考えられます。
しかし、この障壁も永続的ではありません。やがてApple、Microsoft、GoogleがOSや自社サービスにクラウド同期を組み込み、「ファイルが複数端末へ自動的に同期されること」自体は標準機能になっていきました。同期の統合技術が枯れ、知見が蓄積されるに従って、Dropboxと同じような基本機能を持つサービスを作るハードルは下がりました。
その間にDropboxが獲得したのが、Dropboxフォルダへ入れるというユーザーの習慣、共有リンクを送るという行動、チームフォルダに蓄積されたファイル、そして大切なデータを預けてもよいという信頼です。Dropboxによれば、現在の同期システムは数千億のファイル、数兆のリビジョン、数億台の端末を扱う規模に成長しています。技術の窓が閉じる頃には、障壁の中心が同期アルゴリズムから、データ、運用実績、ネットワーク効果、習慣、信頼へ移っていたわけです。
Dropboxは、製品の核となる能力が、「一度ファイルを送れること」ではなく「状態を持って同期し続けられること」として定義されていました。コアの処理には答えがあり、失敗の種類も想像できる。しかし、すべてを連続して正しく動かす統合方法はまだ枯れていなかった。統合自体も技術的なチャレンジングを行い、すでに存在していた差分転送、ハッシュ、バージョン管理、分散システムの知識を、「一般ユーザーがフォルダへ入れるだけ」というわかりやすい用途へ水平に移動させました。
数年早ければ、安価なクラウドストレージや常時接続環境が足りず、一般ユーザー向けの体験として成立させるのは難しかったでしょう。逆に、OS標準のクラウド同期が普及してから参入していれば、同期できること自体では差がつきません。Dropboxは、ファイル同期が「できるかどうか」から「何も考えず任せられるか」へ移る、枯れかけの時間軸に張りました。
そして障壁がまだ有効なうち間に、技術的な障壁をユーザーの習慣と信頼へ転換した。この意味でDropboxは、「枯れかけの技術で時間を買い、枯れない場所に障壁を移す」という戦略の事例だと考えています。
まとめ：着想は枯れかけから、障壁は枯れない場所に
整理すると、次のようになります。
- 枯れた技術(第1段階)は前提条件であり、差はつかない
- 新鮮な技術(第3段階)は失敗モードが未知で、ラッパー問題に飲まれやすい
- 枯れかけ(第2段階)にだけ、複製されない統合知識という一時的な障壁がある
- ただしその障壁は減価するので、障壁があるうちにデータ・習慣・ブランドといった枯れない障壁に転換する
横井氏のものづくり論については今も学ぶことが多いと感じます。横井氏はハードウェアから入り、ゲームボーイなどソフトウェアの動くプラットフォームを作る人としても達人でした。今回はソフトウェア中心にいる私の立場でも彼の思想を実践できないかと考え、言語化した内容になります。 着想は枯れかけの技術から得て、ユーザーにとっては分かりやすく入り口で整理する。それが「枯れかけの技術の水平思考」と表現してみました。
