「デザインからコードを生成するツール」は実運用に耐えうるのか
A. 結論、現状存在するツールでは初期の開発フェーズに限られそう
先日 Figma から React のコードを生成する Amplify Studio というサービスのリリースが発表され一部の世間を騒がせたようなそうでもないような。
このような「デザインからコードを生成する」ツールというのは昨今続々とリリースされています。誇張抜きで100個くらいあると思います。なんなら私も一個作ってます。
デザインからコードを生成する
そんなツールが出る度に人々は心を躍らせるものですが、それが実際にプロダクションで使われている、という事例はあまり聞いたことがありません。
それは、いざ使ってみると生成されたものに幻滅したり、ちゃんと生成するにはデザインやコードに一定の縛りが必要になってしまったり、既存のコードのアップデートにはあまり意味をなさなかったり…、様々な理由から実運用に耐えないものであるからでしょう。
私も自身でツールを作ってみてドッグフーディングしたりもしたので、その中で現状存在するデザインからコードを生成するツールはどういうシチュエーションで価値が出るのか、またどういったことができるツールが現れれば価値が出そうかなどを考えてみたいと思います。
プロダクションで利用可能なコードを生み出すためにやらなければいけないこと
まず、前提としてどんなツールを選ぶにせよ、ある程度デザインの作り方には注意を払う必要がある、ということをお伝えしておきたいです。デザインの作りがよろしくなかったり、コード生成のロジック自体がいけてないと生成されたコードが微妙になることがあり得ます。
ツールはちゃんとレイアウトの情報を生成するものを選ぶようにしましょう☝️で終わる話なのですが、自分が作るデザインに関してもちゃんと構造化して作らないと価値が発揮されない、というのは認識されておいた方が良いと思います。
Auto Layout をしっかり使う
Figma 前提の話にはなりますが、Auto Layout のようなコンテンツによって伸縮したりレスポンシブな挙動に耐えうるものでデザインを作らなければいけません。
Auto Layout がないと、レイアウトの情報がないため、コード生成ツール側の方では判断できず、absolute な配置 + width と height は固定にせざるを得ないからです。
ツール側で中身の要素の配置からレイアウトを推測する、なんてツールも出現するかもしれないですが、それでもちゃんとデザインを作るよりは精度が落ちてしまうでしょう。
構造をコードで表現するのと同じにする
上記の Auto Layout を使うことと ≒ なのですが、HTML などで組み立てるのと同じレベルでデザインのレイヤーを作る必要があります。
これも、同じレイヤーでないと生成ツール側であるレイヤーがない/あるのが意図的かどうかを勝手に判断できないためです。
レイアウトの要求が満たせなかったり、保守性の低い HTML が生成されてしまう可能性があるため、なるべくデザインでの構造はコードで表現するものと近しくなっている必要があります。
現状での「デザインからコードを生成するツール」の使い所
基本的には「初期の開発段階だがデザインはちゃんと構造化されて作ってある」という状況の時のみ有効だと考えています。
前述したようにちゃんと価値のあるコードを生み出すためにはデザインを構造化して作ってある必要があります。なので、それができる人材がいることが大前提になります。
また、詳細は後述しますが、基本的にデザインからコード生成する系ツールは「既存のコードがない」状態でないと価値が逓減していきます。ざっくり言うとデザインから生成できるのは View、つまり見た目の部分だけのコードであり、機能するソフトウェアにするためにロジックやアクションのコードが足されていくため、生成されるコードと競合していくためです。
これらの制約を鑑みると、あなたが以下のような状況にいる時はコード生成ツールを積極的に試してみると成果が得られやすいのではないかと思います。
完全新規のアプリ・サイトを開発している
とまでは行かなくても新規で作るページ・コンポーネントが多い
デザインを構造化して作れる
運用にも耐えうるツールの機能妄想
さて現状の課題を見たところで、ここからは「こんな機能があったらいけるんじゃないかなぁ」という私の妄想を書いていこうと思います。
運用時の課題
先ほどざっくりと運用時には View 以外のコードが増えていってツールで生成されるコードと競合していくため価値がなくなっていく、ということを書きました。
これをもう少し深ぼって何が変わるのかを考えてみると、次のようなことが思いあたります。
コンポーネントが作られていく
状態とのマッピングが行われる
状態で中身の文字列などを生成
状態でスタイルを変更
状態からリストを生成
アクションと View のマッピングが行われる
これらのアップデートが行われても View の部分が変わった時に競合せずにアップデートできれば運用に耐えられるものになるはずです！多分。
私の妄想図
という訳で私が思い描くこんなワークフローで作れるツールができたら運用もいけるかもしれないという妄想をお伝えします。
はい、あまり図にした意味を感じませんがいくつか必要なことを挙げていきます。
フロントのコードでは Container Component と Presentational Component をしっかり分けて作る
Container コンポーネントと Presentational コンポーネントという概念をご存知でしょうか？
Redux の connect するためのアレでしょ？と思っている方も少なからずいるのですが、もっと広義にとらえると
Presentational コンポーネント = 見た目に関する責務だけを持ち、ロジックや状態を持たない
Container コンポーネント = ロジックや状態を持ち Presentational コンポーネントに注入する
という感じで見た目の部分を見た目の部分だけに完全に分離する作り方です。
これの何が重要なのかと言いますと、思い出してください、デザインから生成できるのは見た目に関する部分のみです。運用していく上で競合するのは足されるロジックや状態の部分です。
なので、ちゃんと切り離して View の部分は完全にツールに任せるという運用にすれば可能性はあるのではないかと思いました。
ツール側で Props を View にマッピングできる
という訳で View の部分が切り離しても、実際のコードでは Props をマッピングできる必要があります。
例えば string の状態が Props として渡ってきたらそれを特定の箇所でテキストとして表示したり、ある関数が渡ってきたら button の onClick として紐づけて実行できるようにしたり。
こういうマッピングがツール上でできないと利用可能なコードは生成できないため、そんな感じの機能が求められます。
また、逆にコードの方を変えてもツール側で設定が反映されると嬉しいですね☝️
Variants をいい感じに一つのコンポーネントにできる何か
いい感じの UI は思いつきませんが何かがあって然るべきでしょう。だってコンポーネントってそういうものだもの。
GitHub との連携
ソフトウェア開発のソースコードバージョン管理には GitHub を使っておられることが多いでしょう、私もそうです。
なのでツールで返した結果をコミット & Push できるとシームレスな開発になるでしょう。ブランチング機能もあるとありがたいです。
おわりに
この辺りができるようになると実運用に乗せることも現実的となるのではないでしょうか。なんか自分で書いてて思いましたが、そこまで非現実的ではない気がしてきました。
個人的には View の部分の実装はあまりクリエイティブでない不毛なタスクであり、自分でも「もうやりたくない…」という想いから自分で自動生成ツールの実装をしたりもしました。
この辺りのツールは今が乱世というか(多分 Figma が Auto Layout 実装したおかげ)、ツールがたくさん出てきている状況ですが、この中からデファクトスタンダードとなるようなツールが出てくることを切に祈ります。というかワンチャン私が作るかもしれません。
皆さんもこの分野の発展に向けてぜひツールを使ってみてフィードバックしてあげてください。それでは！
この記事が気に入ったらサポートをしてみませんか？