はじめに

「システムを作る」と言うと、多くの人は画面を思い浮かべる。

ログイン画面があって、ダッシュボードがあって、ボタンを押すと何かが動く。 それが「システム」だと、なんとなく思っている。

でも、本当にそうだろうか。

僕はかつて、Amazon輸出の無在庫販売で生計を立てていた時期がある。 価格改定、在庫更新、出品管理、データ取得——すべてを自動化して、毎月利益を出していた。

そのシステムに、UIは一切なかった。

管理画面もなければ、ダッシュボードもない。 ボタンもフォームも、1つも作らなかった。

それでも、システムは動いていたし、利益は出ていたし、運用は安定していた。 むしろ、UIがなかったからこそ、うまくいっていた部分がある。

この記事では、その経験をもとに、「UIを作らない」という選択肢について書いてみたい。

フロントエンドを否定したいわけではない。 ただ、UIは目的ではなく手段だということを、改めて考えてみたいのだ。

Amazon輸出で実際にやっていたこと

まず、当時の仕組みを簡単に説明しておく。

無在庫販売とは

無在庫販売とは、在庫を持たずに商品を出品し、注文が入ってから仕入れるビジネスモデルだ。

    1. 日本のECサイトの商品を、米国Amazonに出品
2. 米国で注文が入る
3. 日本で仕入れて、米国に発送
4. 差額が利益

シンプルに見えるが、実際にはいくつかの難しさがある。

  • 為替が変動する
  • 日本側の価格が変わる
  • 在庫がなくなる
  • 競合が価格を下げてくる
  • 出品数が多いと、手動管理は不可能

これらを人力でやっていたら、すぐに破綻する。

だから、自動化した。

自動化していた処理

僕が作っていたのは、こんな処理だった。

価格改定

    - 日本側の価格を定期的に取得
- 為替レートを取得
- 利益率を計算
- 米国Amazonの価格を自動更新

在庫更新

    - 日本側の在庫状況を監視
- 在庫切れなら米国側を出品停止
- 復活したら再出品

出品管理

    - 新商品の自動出品
- 売れない商品の自動削除
- カテゴリ・価格帯でフィルタリング

データ取得と分析

    - 売上データの収集
- 利益計算
- レポート生成（CSV出力）

これらは、すべてバッチ処理とAPIで動いていた。

cronで定期実行し、ログをファイルに吐き出し、問題があればメールで通知。 必要なときはCSVを開いて確認する。

管理画面は、なかった。

なぜUIが不要だったのか

「でも、操作する画面がないと不便じゃない？」

最初は僕もそう思っていた。 管理画面を作ろうと思ったこともある。

でも、作らなかった。 作る必要がなかった。

操作する「ユーザー」がいなかった

このシステムの「ユーザー」は、僕だけだった。 しかも、僕がやりたいことは「操作すること」ではなく、「利益を出すこと」だった。

考えてみてほしい。

価格改定のたびに画面を開いて、ボタンを押す。 在庫更新のたびに確認して、チェックを入れる。 そんなことをしていたら、1日が終わってしまう。

僕が本当に求めていたのは、**「何もしなくても、利益が出る状態」**だった。

であれば、UIは邪魔だ。 画面を開く時間すらもったいない。

判断はロジックで十分だった

「価格をいくらにするか」は、人間が決める必要がなかった。

    仕入れ価格 + 送料 + 手数料 + 利益率 = 販売価格

この計算に、人間の判断が入る余地はない。 為替が変われば自動で計算し直す。 仕入れ価格が上がれば、販売価格も上がる。

UIで「この価格でいいですか？」と聞く意味がなかった。

フィードバックは「数字」だった

システムの良し悪しを判断するのに、ダッシュボードは必要なかった。

  • 今月の売上はいくらか
  • 利益率はどうか
  • 在庫切れで機会損失していないか

これらは、CSVを開けば分かる。 Excelでピボットテーブルを組めば、十分に分析できる。

グラフがリアルタイムで動く必要はなかった。 日次のレポートで十分だった。

UIを作る理由が、1つもなかった

改めて振り返ると、UIを作る理由がなかった。

  • 操作するユーザーがいない
  • 判断は自動化できる
  • フィードバックはCSVで十分
  • 画面を見ている時間がもったいない

これが現実だった。

UIがなかったから得られたメリット

UIを作らなかったことで、いくつかの明確なメリットがあった。

実装スピードが圧倒的に速かった

フロントエンドを作らないということは、工数が半分以下になるということだ。

  • HTMLを書かなくていい
  • CSSを調整しなくていい
  • JavaScriptのフレームワークを選ばなくていい
  • レスポンシブ対応もいらない
  • ブラウザ互換性も考えなくていい

バックエンドのロジックだけに集中できた。

新しい機能を追加するとき、「画面どうしよう」という議論が発生しなかった。 ロジックを書いて、cronに登録して、終わり。

改修が楽だった

UIがあると、改修のたびに画面の調整が必要になる。

  • 項目が増えたらフォームを変える
  • 表示が変わったらCSSを直す
  • 操作フローが変わったらUIも変わる

UIがなければ、ロジックを変えるだけで済む。 依存関係がシンプルだから、変更の影響範囲が小さい。

バグが少なかった

フロントエンドは、バグの温床になりやすい。

  • 状態管理のミス
  • 非同期処理の競合
  • ブラウザごとの挙動の違い
  • ユーザー入力のバリデーション漏れ

これらを考えなくていいというのは、大きな安心感だった。

バグが出るとしたら、ロジックのミスだけ。 原因特定も修正も、シンプルだった。

運用が安定していた

UIがないシステムは、壊れにくい。

  • ユーザーが「想定外の操作」をしない
  • 状態が予測可能
  • 入力が固定されている（APIレスポンス、CSVなど）

人間が介在しないから、人間起因のトラブルがなかった。

フロントエンドを学ばなくてよかった

これは副次的なメリットだが、時間の節約になった。

React、Vue、Angular、Next.js、Nuxt.js、Svelte… フロントエンドの世界は変化が速い。

それを追いかける時間を、ビジネスロジックの改善に使えた。 新しいフレームワークを学ぶ代わりに、新しい商品カテゴリを開拓できた。

技術を学ぶことが目的ではなかった。利益を出すことが目的だった。

ユーザー体験はどうだったか

「UIがないと、UXが悪いのでは？」

これは当然の疑問だ。 でも、実際は逆だった。

「何もしなくていい」が最高のUX

このシステムの「ユーザー」は僕自身だ。 僕がシステムに求めていたのは、**「自分の時間を奪わないこと」**だった。

画面を開いてボタンを押す時間。 データを確認して判断する時間。 エラーを見つけて対処する時間。

これらがゼロに近いほど、僕は幸せだった。

朝起きたら、昨夜の売上がメールで届いている。 問題があれば、アラートが飛んでくる。 問題がなければ、何もしなくていい。

何もしなくていい時間が長いこと。

これが、このシステムにおける最高のユーザー体験だった。

画面を見る必要がない安心感

UIがあると、つい見てしまう。

「ちゃんと動いてるかな」 「今日の売上どうかな」 「エラー出てないかな」

これが、意外とストレスになる。

UIがなければ、見ようがない。 見なくても大丈夫な設計になっているから、見なくていい。

この「見なくていい安心感」は、想像以上に快適だった。

それでもUIが必要になるケース

ここまで「UIは不要だった」と書いてきたが、極端な主張をするつもりはない。

UIが必要なケースは、確実に存在する。

人が判断する必要があるとき

自動化できない判断がある場合、UIは必要だ。

  • 「この商品は出品していいか？」という審査
  • 「このクレームにどう対応するか？」という判断
  • 「この価格で本当にいいか？」という確認

ロジックだけでは決められないことがあるなら、人間が介在する必要がある。 その場合、UIは有効な手段になる。

可視化が価値になるとき

データを「見ること」自体が価値になるケースがある。

  • 経営ダッシュボード
  • リアルタイム監視
  • チームへの情報共有

「何が起きているか」を人が把握する必要があるなら、UIは意味を持つ。

例外処理・デバッグ

イレギュラーな事態への対処には、UIがあると便利だ。

  • 手動で再実行する
  • 特定のデータを修正する
  • ログを確認する

僕の場合は、SSHで入ってログを見たり、SQLを直接叩いたりしていた。 これで十分だったが、エンジニア以外が運用する場合は、簡易的な管理画面があった方がいいかもしれない。

UIを作らない判断基準

では、どういうときにUIを作らないという判断ができるのか。

問いかけてみてほしいこと

  1. そのUIを、誰が、いつ使うのか？

    • 使う人がいないなら、作る必要はない
    • 使う頻度が低いなら、CLIやCSVで十分かもしれない

  2. その操作は、自動化できないか？

    • 人間が判断する必要があるか
    • ルールベースで処理できないか

  3. フィードバックは、どう受け取るか？

    • リアルタイムで見る必要があるか
    • 日次のレポートで十分ではないか

  4. UIを作るコストは、ペイするか？

    • 開発コスト
    • 保守コスト
    • 学習コスト

UIが不要になりやすい領域

経験上、以下の領域はUIなしで成立しやすい。

  • バッチ処理: 価格改定、在庫同期、データ集計
  • ETL: データの抽出・変換・ロード
  • 通知系: アラート、レポート送信
  • 連携系: API同士のつなぎ込み
  • 定型業務: 毎日同じことをするもの

逆に、UIが必要になりやすい領域もある。

  • ワークフロー: 承認、レビュー、ステータス管理
  • 例外処理: イレギュラーへの対応
  • コミュニケーション: チャット、コメント
  • クリエイティブ: デザイン、執筆、編集

結論：UIは目的ではない

僕がAmazon輸出で学んだことを、一言でまとめるなら、こうなる。

UIは目的ではない。成果を出すための手段の1つに過ぎない。

そして、成果から逆算すると、UIを作らないという選択は、しばしば合理的だ。

UIを作らなければ、

  • 開発は速くなる
  • 保守は楽になる
  • バグは減る
  • 運用は安定する

UIがなければ、

  • ユーザーは「何もしなくていい」
  • それが最高のUXになることがある

もちろん、UIが必要なケースはある。 人が判断する必要があるとき、可視化が価値になるとき、UIは有効だ。

でも、「システム＝UI」という思い込みは、一度疑ってみてもいい。

良いシステムは、人が触らない時間が一番長い。

画面を開かなくても、利益は出る。 ボタンを押さなくても、業務は回る。

そういうシステムを作れたとき、僕は初めて「これでいいんだ」と思えた。

最後に

この記事は、フロントエンドを否定するものではない。

UIが必要な場面は、たくさんある。 フロントエンド技術は、日々進化している。 それを学び、使いこなすエンジニアを、僕は尊敬している。

ただ、目的と手段を混同しないでほしいという話だ。

UIは、システムの価値そのものではない。 成果から逆算したとき、UIが最適な手段でないこともある。

「まず画面を作ろう」ではなく、 「そもそも画面は必要か？」から始めてみる。

その問いかけが、システム設計を少しだけ楽にしてくれるかもしれない。

余談：無在庫販売のその後

ちなみに、この無在庫販売ビジネスは、数年続けた後にやめた。

Amazonの規約変更、競合の増加、為替の変動。 いろいろな要因が重なって、利益が出にくくなったからだ。

でも、この経験で得た「UIを作らない」という発想は、今の仕事にも活きている。

業務システムを設計するとき、 「本当にこの画面は必要か？」と問いかける。

答えが「No」なら、作らない。 それでいい。

システムは、動いていればいい。 利益が出ていればいい。 業務が回っていればいい。

画面の美しさは、その後の話だ。

関連記事