見出し画像

Figmaに仕様書はアリ？ナシ？デザインツールの限界と対策

Shumpei Osawa

開発現場でFigma を使用している方は多いのでないでしょうか。
私もFigmaは仕事でもプライベートでもよく使います。絵にして何かを伝えることに非常に長けていますよね。かつてはイラレやフォトショを持ち出して、というようなこともありましたがFigmaは「オンライン上でさくっとできる」というのが最大の価値だと思います。

さて、先日Xでこんな話が界隈で話題になっておりました。

これに関しては私も思うところがあり、今回記事にしました。この記事では、Figmaの現状やメリットも交えて書きますが、個人的な結論としては、Figmaは設計ツールであり、仕様書としては必ずしも適していないという結論に至ります。

Figma仕様書：開発現場での導入状況と課題

Figmaは、WebデザインやUIデザインの分野で広く利用されているツールです。冒頭にも書きましたが、私もよくお世話になっております。直感的な操作性と強力なコラボレーション機能を備えているため、デザイナーだけでなく、エンジニアやプロジェクトマネージャーなど、開発チーム全体で活用できる点が大きな魅力です。

Figma導入の背景と開発現場における利用シーン

Figmaが開発現場で注目を集められるようになったのはざっと以下のポイントがあるかなと思います。総じて言うと、「ソフトをインストールせずに、URLを渡して、権限を付けるだけでOK」が肝だと思っています。

  • クラウドベースで利用できる：インターネット環境があれば、場所を選ばずに共同で作業できるため、リモートワークが普及した現代において非常に便利です。これは正直めちゃくくちゃ大きいです。

  • リアルタイムコラボレーション機能：複数人で同時に編集できるため、デザインレビューやフィードバックのサイクルを短縮できます。

  • プロトタイプ作成機能：インタラクティブなプロトタイプを作成することで、ユーザー体験を事前に確認できます。アプリ開発が当たり前になった現在では「紙芝居ができる」のはもはや必須ですね。

  • 無料プランがある：個人や小規模チームであれば、無料で利用できるため、導入コストを抑えられます。

現場では、Figmaを以下のようなシーンで活用されています。ワイヤーフレームからデザインまで一貫して使われている印象があります。

  • ワイヤーフレーム作成：画面構成やレイアウトを設計する際に利用されます。

  • UIデザイン：ボタンやアイコンなどのデザインを作成する際に利用されます。

  • プロトタイプ作成：ユーザーインターフェースの動作をシミュレートする際に利用されます。

  • デザインレビュー：デザインの確認やフィードバックを行う際に利用されます。

  • 設計図の共有：デザインをエンジニアと共有し、実装をスムーズに進めるために利用されます。

Figma仕様書で起こりがちな問題点

ここまで聞くと、「Figma 最高じゃん」となるかもしれないのですが、本記事の主題でもある「Figma仕様書には問題がある」という部分が入ります。
Figmaで仕様書を作成する際に、どのような問題が発生する可能性があるのかを具体的に見ていきましょう。

非機能要件の表現

Figmaは、デザインツールとして設計されたため、開発に必要なすべての情報を網羅的に記述する設計にはなっていません。そのため、Figma仕様書だけでは、エンジニアが実装に必要な情報が不足してしまうケースも少なくありません。

例えば、以下のような情報が不足しがちです。

  • API仕様

  • データベース構造

  • エラー処理

  • セキュリティに関する要件

これらの情報をFigma仕様書に追記しようとすると、デザインの邪魔になる可能性があり、可読性が低下してしまいます。つまり、非機能要件が図示しづらいということですね。既存サイトやアプリの軽微な改修程度なら、Figma 仕様書でもぎりぎりでどうにかなるかもしれないですが、一定規模のシステムがからむ要件だと途端に瓦解すると思います。

バージョン管理

Figmaでは、デザインファイルのバージョン管理機能は備わっていますが、仕様書としてのバージョン管理には不向きな場合があります。特に、複数人で同時に編集する際に、誰がどの部分を変更したのか、変更履歴を管理することが難しくなります。

バージョン管理が不十分だと、以下のような問題が発生する可能性があります。

  • 過去の仕様が分からなくなる：過去の仕様を確認する際に、どのバージョンが正しいのか分からなくなってしまい、開発に支障をきたす可能性があります。

  • 変更履歴が追跡できない：誰がいつどの部分を変更したのかが分からず、責任の所在が不明確になる可能性があります。

  • 衝突が発生する：複数の人が同時に同じ部分を編集した場合、変更内容が衝突し、意図しない結果になる可能性があります。

メンテナンス性とエンジニアにとっての可読性

エンジニアは、Figmaで作成されたデザインを元に、実装を行う必要があります。しかし、Figmaは、デザイナーがデザインを表現するためのツールであり、エンジニアがコードを書くためのツールではありません。そのため、エンジニアにとって、Figmaの仕様書を読み解くことは、必ずしも容易ではありません。

特に、以下のような点が課題となります。

  • コードとの関連付けが分かりにくい：Figmaのデザイン要素と、実装されているコードとの関連付けが分かりにくい場合があります。

  • 技術的な詳細情報が不足しやすい：実装に必要な技術的な詳細情報が不足している場合があります。

  • 検索や参照が不便：Figmaでは、仕様書全体を検索したり、特定の要素を参照したりすることが不便です。

まとめ｜Figma を上手に活用する方法

Figma仕様書と他のドキュメントツールとの使い分け

至極単純ですが、「ツールを使い分ける」です。やはり、ツールにはそれぞれの意図した使い方と得意分野があります。この記事でも再三、念押ししましたが、Figmaはデザインツールであり、仕様書を記述するためのツールではありません。そのため、実装に関する詳細な情報や、バージョン管理が必要な情報については、他のドキュメントツールを活用するのが良いでしょう。ConfluenceやNotionなどの「文章を書くこと」「バージョン管理の概念がある」「検索できる」を満たすツールとセットで使うがやはりいいと思います。私は資料の骨格はこれらで作りつつ、おおよそ2カラムのテーブルを用意して、左カラムはFigma で作った図表、右カラムにはテキストびっしりというかたちによくしております。

そうすると、ざっと説明する時には左カラムの図表を使用し、じっくりと読ませたいときに右カラムのテキストというように読み手のモードに合わせられるので良いと思ってます。

Figmaは、デザインを可視化し、チーム全体で共有するためのツールとして活用し、実装に関する詳細な情報や、バージョン管理が必要な情報については、他のドキュメントツールを活用することをおすすめします。

この記事が、Figmaと仕様書の関係性について理解を深め、開発プロセスに最適なドキュメント戦略を策定する一助となれば幸いです。

いいなと思ったら応援しよう！