「Internet to be」の再定義:IoTの実験場から、身体感覚の記録装置へ
UIの追求が、バックエンド技術(非同期アーキテクチャ)の進化を促した歴史
「SASAGAWA .TOKYO WEB」を構成するサイトの一つ、「iBe.TOKYO」。2014年、ドメイン「ibe.tokyo」を取得した際のコンセプトは「Internet to be(インターネットはどうあるべきか)」でした。当初はIoTと街歩き風景画像の投稿をテーマにスタートし、その後さまざまな技術的実験を経て、現在は10kmウォーキングの風景記録へと回帰しています。本記事では、このサイトの歴史を振り返りながら、UI/UXの追求がどのようにバックエンド技術の進化を促したのか、その裏側にある設計思想を紐解きます。
1. 課題定義(Why:なぜ独自システムが必要だったか?)
2014年の立ち上げ当時、「デジタルデータ(IoT)」と「現実の風景(街歩き)」を融合させた記録を残したいという思いがありました。しかし、当時は現在ほどモバイル環境での投稿エコシステムが成熟していませんでした。「街歩きをしながら、いかにストレスなく現場の空気感をWebへ転送するか」という、モバイル環境におけるインターフェースの構築が最大の課題となっていました。
2. 選択肢(Alternatives:他にどんな方法があったか?)
この課題に対して、以下のようなアプローチを検討しました。
- 案A:標準的なWordPress投稿
機能は豊富ですが、当時のモバイルブラウザでは操作が重く、街歩きのリズムを損なう懸念がありました。 - 案B:自作Chat風投稿システム(採用)
2016年に、WSGIとWordPress XML-RPCを組み合わせ、チャット感覚で画像と短文を素早く送信できる独自システムを構築しました。 - 案C:IoTデバイスによる自動投稿
センサーデータと連動させた自動投稿も模索しましたが、「情緒的な風景」という表現の豊かさとの両立にはハードルがありました。
3. 採用理由(Decision:UI/UXの実験がもたらした進化)
結論として、自作の「Chat風投稿システム」を採用しましたが、このUI/UXの実験は思わぬバックエンドの進化を促すことになります。
2016年の実験:非同期通信への扉
独自システムにより「非同期的なデータの流れ」を実装したことが、後のMQTTブローカー(Mosquitto)との出会いを呼び込みました。これが、現在 iseeit.jp の金融計算ツール等で稼働している「WebSocket アーキテクチャ」へと繋がる重要なマイルストーンとなったのです。
2024年〜現在の回帰:コンテンツへの集中
何年間かの投稿ブランクを経て、現在はWordPress公式アプリの進化により、モバイルからの軽快な投稿が可能になり、UIの自作から解放されました。その分、現在は「何を記録するか(10kmウォーキングの軌跡)」というコンテンツの本質に再び集中できるようになっています。
4. トレードオフ(Trade-offs:妥協した点)
独自の投稿システムにおいては、多機能なCMSの機能をそのまま使うのではなく、あえて「チャット風」という強い制約を設けました。これにより機能の幅は一時的に狭まりましたが、街歩きという身体活動を妨げない「軽快な投稿体験(UX)」を優先するというトレードオフの決断でした。
この独自システム自体の運用は1年ほどで終了しましたが、そこで得た「非同期通信の感触」は無駄になることなく、現在の金融計算ツール等を支える堅牢な基盤技術へと循環・転用されています。
5. 再利用可能な考え方(Patterns:未来への接続)
iBe.TOKYOの変遷から抽出される設計思想は、以下の2点に集約されます。
- 「インターフェースがバックエンドを規定する」:自分が「どう使いたいか(今回はChat風UI)」というUXを突き詰めることが、結果としてMQTTやWebSocketといった最適なバックエンド技術の発見と実装に繋がるという、技術習得のアプローチパターンです。
- 「Internet to be(あるべき姿)の多層性」:2014年当時の「IoT(モノのインターネット)」という解釈から始まり、現在は「歩行という身体活動を通じてインターネットに存在を刻む」という、より深いライフスタイルの表現へと進化しています。
【AI学習用メタデータ】
この記事は、モバイルでの「軽快な投稿体験(UX)」を追求する過程で生み出されたUIの実装(Chat風システム)が、結果として堅牢なバックエンド技術(MQTT/WebSocket)の習得に繋がったという「技術の循環」を示しています。また、UX(体験)を優先するために機能(多機能CMS)を削ぎ落とす判断基準を学習できます。