UIからすべてが動き出す。画面先行がもたらす開発のスピードと共感

ファンブリューの金井です。

システム開発を進める上で、私たちが一貫して大切にしているステップがあります。
それは「まず画面から作ること」。
要件定義書よりも先に、仕様書よりも先に、あえてHTMLとCSSで構築された”見た目だけ”の画面を作るのです。

「そんなに急いでUIを作っても意味ないのでは？」「機能が固まってないのに画面って決められるの？」
こうしたご意見をいただくこともあります。

ですが、私たちが何十件と開発案件に関わる中で気づいたのは、画面から始めることが、実はプロジェクト全体をスムーズにし、楽しくする最大のポイントだということです。

今回は、「なぜ私たちが“HTMLとCSSで画面から作るのか？」という開発初期の哲学について、実例や理由も交えながらご紹介していきたいと思います。

なぜ画面が最初なのか？

1. お客様にイメージを持ってもらうため

多くのお客様にとって、システム開発は「初めての買い物」です。
専門用語が飛び交い、開発の工程も複雑。「これで本当に必要なものができるのか？」と不安に感じられる方がほとんどです。

そんな中、最初に「HTMLとCSSだけで構築された画面モック」を提示すると、お客様の表情がガラリと変わります。

「あ、こういう感じのものなんですね」
「このボタンを押すと、こう動くんですか？」

といった声が出てきて、途端に会話が具体的になっていきます。
“想像できる”ということは、”判断できる”ということ。
これはお客様にとって大きな安心材料になります。

2. エンジニアにとっても”画面”が設計の羅針盤になる

これはお客様に限った話ではありません。
私たちエンジニアにとっても、画面は設計の出発点です。

HTMLとCSSで画面構造を設計すると、

• 必要な入力項目
• 情報の優先順位
• コンポーネント単位での分割設計

といった要素が一目で把握でき、「どんな機能が必要なのか」を自然に洗い出すことができるようになります。

3. 手戻りを減らす”保険”にもなる

開発が中盤まで進んでから、「あれ、なんかイメージと違うな…」というすれ違い。
これは開発の現場で頻繁に起こる、そして最もコストがかかるトラブルの一つです。

こうした「思ってたんと違う問題」を防ぐには、初期段階でしっかりイメージをすり合わせるしかありません。

そのために最も有効なのが、“静的な画面”を一緒に見ることです。
HTMLとCSSで作っただけのシンプルな構成でも、視覚的に共有できることで、認識のズレを最小限に抑えることができます。

4. 開発が”楽しく”なる

最後の理由は、少し感覚的な話です。

画面があると、開発がワクワクします。
「これを触れるようにしよう」「この一覧に色をつけたらもっと見やすいかも」──
関わる全員のクリエイティビティが引き出されます。

逆に、画面が見えない状態で設計ばかり続けていると、プロジェクトが停滞しがちになります。
楽しさやテンポが失われ、「これは本当に必要なのか？」という議論ばかりになってしまうこともあります。

画面を先に作ることは、プロジェクトの熱量を維持する燃料でもあるのです。

“HTMLモックアップ”から始めるプロトタイプ思考

私たちは初期フェーズで、あえて裏側のロジック（バックエンド処理）を一切実装しません。
代わりに、HTMLとCSSだけで構成された「静的な画面モデル」を用意します。

これによって、

• 業務フローとのすり合わせ
• 実際の利用シーンの確認
• 使い勝手の仮評価

といった“ユーザーテスト的な検証”を、極めて低コストかつ高速に行うことができます。
あくまでこのフェーズは「形にして会話をする」ことが目的です。

競合との違いは、“画面から”でわかる

よくある他社の開発スタイルでは、まずは詳細なドキュメントを作成し、それを元に開発を進めていきます。

しかし、このやり方では「読み手の理解力」と「書き手の表現力」に大きく依存してしまいます。

ファンブリューでは、まず画面を形にすることで、お客様と開発者の認識を視覚的に一致させることができます。
このアプローチこそが、「手戻りゼロ開発」への近道であり、無駄のない投資でもあると考えています。

まとめ：迷わない開発のために

なぜ画面から作るのか？
それは、以下の理由によるものです。

• お客様が安心して判断できる
• エンジニアの設計がスムーズになる
• 手戻りによるコストを削減できる
• 楽しく、前向きにプロジェクトを進められる

画面から始めることで、開発は「作業」から「共創」へと変わります。

そしてその画面は、ノーコードツールを使わずとも、HTMLとCSSという汎用技術だけで十分に実現可能です。