デザイナーとエンジニアのワークフローについて書かれている下記の記事を深掘りしようと思う。

要件資料とデザインファイルの統合

企画の人とデザイナーの人が別だと要件ファイルがPowerPointなどで作られていたり、コンフルエンスを使って作られていたり、Excelで作られていたりと人によって様々で、そのファイルを置く場所も様々になってしまい、デザイナーと企画との間ですら要件をすり合わせるのに人と同じ数のパターンが発生しているケースがある。
ここではfigmaにツールを統一することによって、ファイルの更新にデザイナーが気づきやすくなるだけでなく、エンジニアの共有も楽になる。
個人的にはそれだけでなく、デザインをあまり詳しくない企画の方が担当になったとしても、既存のプロダクトのモジュールのデザインを引用することが同じツール上で行っているので容易になる。
企画書の中のモックの精度が上がることにつながる。
そうなると、企画の人が企画を考える際に、既存のモジュールを参照しやすくかつ、実際のものと相違がなくなる点が大きなメリットだと思う。
あの画面のあのモジュールを出すためには、どうすれば良いのかなど考えたりする時間の短縮にもつながる。

ルールの把握しやすさ

企画やデザイナーやエンジニアの共通言語としてカラーコンポーネントを定義することによって、使っていい色、悪い色、使っていい形、悪い形など細かいところにおいても認識を簡単に合わせることができる。
簡易的なモックの欠点としては、実際に使われているフォントサイズやカラーでモジュールを置いたときに幅が思ったより出たり、想像していたものとの差がどうしても出てきてしまう。
カラーコンポーネントやアセットを共有して認識しておいてもらうだけでなく、使いやすくしておくことによって、その相違がほぼ無くなる。
はじめに覚えておかなくても、実際に使うときにそのコンポーネントを参照すればいいだけなので、イニシャルコストも削減できてメリットだらけだと感じる。

長期で見てもメリット

短期で見ても上記のようなメリットが既にあるが、長期で見ても、モジュールやカラーアセットを変更することになっても、ツールが同じなので、すぐに変更を理解できるし、エンジニアの人も反映することができる。
最新を周知し損なったとしても、自ら最新をとりに行けるし、意識せずとも最新になっている。
企画する時は企画に、デザインする時はデザインに、実装する際は実装に集中できる。メリットだらけのようだ。