私は今ビジュアル作成からコーディングまで一人でやっていて、これは良いんじゃないか？と思ったことをまとめます。

見出し
1. ビジュアルとコードの整合性
2. デザインシステムへの落とし込みやすさ
3. 目下の課題

ビジュアルとコードの整合性

普通はカンプを作り終わってからコーディングに入ると思います。しかしここ最近いくらかの事情があって、「全部は出来てないけど可能な場所からコーディングに入る」という進め方をしていました。

カンプ作成時からコードのことは考えていましたが、それでも実際に書くと迷う場面も出てきます。例えば、あるコンポーネントの配置をこうやって統一できればコードが結構簡単になるなあ……など。

丁度、まだまだカンプが完成していないので（問題が起こらないか検証した上で）コードに合わせて修正をしました。

あっちを作ってこっちを修正してと作っているうちに、ビジュアルもコードもかなり一定のルールに沿ったものになってきました。私の会社は事業会社なので保守運用の面で「誰が触っても崩れにくい」ことは非常に重要です。

デザインシステムへの落とし込みやすさ

流行っている……という言葉で表現すると語弊がありそうですが、とにかくデザインシステムは色々なところで見るようになりました。先程の話と似ていますが、デザインシステムもどれだけキレイにまとまっていても使いづらいものだったら一瞬で破綻するかと思います。

ビジュアルを優先して作られたガイドラインは再現するためのコードが大変だったりしますし、コードから起こされたガイドラインはビジュアルの幅が狭くなったりします。

そういう意味ではビジュアルとコードの整合性を保ちつつ同時並行でガイドライン化していくのが良いのかなあと思っていて3領域を行ったり来たりしながら作れていることに結構手応えを感じています。

目下の課題

今は作業をしているのが自分一人なので、修正したい点も順番も全て自分が持っています。これが複数人で同じプロジェクトをやっていたら同様の進め方はできなかったろうなと感じています。

この課題については、まず自分一人で再現性があるレベルで力を身に着けて、もう一人増えたときにどんな問題が起きるかを見て解決する、といった泥臭いやり方しか浮かんでいません。いずれにせよ、自分だけでしっかりやれるようになることが先決かと思っています。

まとめ

開発の中でデザインは1つのステップに過ぎませんが、その中でもウォーターフォールではなくアジャイル的なアプローチが可能なのかもしれないと気づけました。複数人で作業をするときでも同様に上手く出来るのであればもっと広めていっても良さそうだと感じています。

見出し
1. ビジュアルとコードの整合性
2. デザインシステムへの落とし込みやすさ
3. 目下の課題