ソフトウェア分野では早くからDesign as Code(コードによる設計)のアプローチが浸透してきましたが、近年ではSpaceXのような先進的なハードウェア開発においても、
コードとしての設計
「コードとしての設計」→ CAD → 製造 というプロセスが一般化しつつあります。
SpaceXでは、Pythonや設計作業に特化した専用の記述言語(DSL:Domain Specific Language)を用いて、パーツの形状や構造をパラメトリックに定義しています。
これにより:
設計変更を高速に反映できる(CADを手作業で修正する必要がない)
材料・熱・応力などのシミュレーション条件と直結できる
バージョン管理や再利用が容易になる
といったメリットがあります。
とはいえ、最終的な出力先であるCADによる視覚的確認や干渉チェック、3Dプリントや加工などの物理的プロセスは不可欠です。
コード化が進んだとしても、設計がプロダクトとして成立するかを評価するための「出力との接点」は必ず必要なのです。
ソフトウェア開発においても同様です。
従来のような 「UI・UXツール → Code」 という一方向の流れから、
現在では 「Code ←→ UI・UXツール」 という相互補完的な関係へと進化しています。
たとえば:
Figma to Code(デザインからコード自動生成)
Code to Figma(コードの変更がFigmaに反映される双方向連携)
StorybookやFramer、Vercel Preview を用いたリアルタイムなUX確認
など、設計と実装の境界が溶け始めています。
また、コードだけでUXを十分に検証することはできません。
ユーザー体験は「見て」「触って」感じるものであり、
コードを変更しながらUXの変化をリアルタイムに可視化・体験できる開発スタイルが主流になりつつあります。
この点において、UI/UXツールはサンドボックスとしての役割も担うようになっており、
テスト環境に近い形で「プロダクトに近い体験」を通じた設計フィードバックが可能になっています。
出力=ビジュアル/CADでの確認と評価は不可欠
ClaudeやCursorなどのAIを活用して設計や仕様をテキストで扱える時代になったとしても、
出力=ビジュアル/CADでの確認と評価は不可欠です。
Design as Codeが進む現代において求められるのは、テキストとビジュアルの両方を自在に行き来できる設計リテラシーと、それを支えるツール環境(DSL、モック、シミュレーションなど)です。
今後は、「テキスト化か、ビジュアル化か」という二択ではなく、変換可能性を前提とした往復的な設計フローそのものに適応していく力が重要になります。