エンジニアが画面設計（Figma）を担当してみた振り返り

Thinkings株式会社 では sonarATS の開発にあたり、基本的にはデザイナーがFigmaを作成し、それに基づいてエンジニアが開発するというフローを取っています。

そんな中、先日エンジニアサイドで画面設計を行ってみるという実験的な取り組みをしました。

本記事では画面設計を行うことになった経緯と具体的な取り組み内容を振り返り、エンジニアが画面設計をすることのメリットと課題感について考えたことをまとめたいと思います。

エンジニアサイドで画面設計をするきっかけとなった要因

エンジニアサイドで画面設計をすることとなった理由として、大きく分けて以下３つの要因がありました。

• デザイナータスク削減の目標
• あるマスタ画面を開発したときの課題感
  • 上述の通り、『簡単なマスタ画面の開発』のような共通的な画面設計になる機能については、できるだけデザイナーが介入せずエンジニア主導で開発している
  • → 実際にコーディングまでしてみて、仕様（画面設計含め）が定まっていない部分に気がつき修正が必要となり、手戻りが生じた
  • → また、テキストベースでの相談で、参考になる画像を貼り付けたり、開発中の画面キャプチャを取って貼ったり……とコミュニケーションでも手間を感じた
• 組織としての開発生産性向上の目標
  • エンジニアが画面設計を担当できるようになることで生産性を向上させる事ができないだろうか、という仮説
  • デザイナー目線のきれいなUI、ユーザビリティ中心の考え → 開発効率が落ちる方向性となっている場合もある
    • UIが見やすい、ユーザビリティを考えている、というのも大切ではあるが、一概にそればかりを優先して開発効率を下げるのは良くない
    • エンジニアが画面設計をすると、ユーザビリティの観点、および特にきれいなUIというのは作るのが難しいが、一方で開発効率を視野に入れた上での画面設計が出来る
    • 今までデザイナーから下されたデザインをエンジニアが作るという体制で取り組んできたが、最近はスピード感が落ちてきているようにも感じるので、一度エンジニアが画面設計を担う体制に切り替えていくことでスピードアップできないか挑戦したい……という状況
  • またエンジニアサイドで画面設計を巻き取ることが出来れば、将来的にはデザイナー不足の解消にも繋がる

取り組み内容

上述のような課題感、要因があり、先日トライアルとして画面設計を担当させて頂けることとなりました。

取り組み内容の一連の流れを、以下箇条書きで記します。

• 画面設計作業にあたり、デザイナーから画面設計リソースの説明を受ける
  • Figmaで過去の画面設計ファイルを保管している場所、およびコンポーネントやローカルスタイルが定義されている場所とそれらの使い方をお教え頂いた
    
    
    
• 画面設計リソースを活用して画面設計作成
  • まず過去の画面設計をコピーして流用
  • パーツの付替えが必要な場合は、適宜コンポーネントを参照して活用
  • 相談点があればFigma上に説明イメージを作成し、PdMに相談
    
• 完成した画面設計を PdM、デザイナーにレビューして頂き、画面設計完成
  

振り返り

良かったこと

• 開発の視点を持って画面設計することで、考慮漏れを減らすことが出来た
  • 多少は開発してみて気づく漏れというものはあったが、画面設計もエンジニアが担っているため、漏れに気付き次第すぐに画面設計に戻って修正し、それから開発再開……とスピーディに対処できた
• 開発目線で実装効率を優先した画面設計を提案できた
  • トップダウンでデザインを提示されるフローだと、ユーザビリティが優先されて開発生産性が後手に回る印象があった
  • しかしエンジニアがボトムアップでデザイン提案できると、開発生産性を考慮して実装が複雑になりそうなデザインは積極的に避けることが出来る
  • → 最終的にはこれをPdM、UIチームにレビューしてもらうことで、ユーザビリティとのバランスを取ることが大切だが、生産性ファーストに出来るのは一つの強みとなるかも知れないと感じた
• 相談を行うにあたってFigmaのイメージがあることで議論しやすかった
  • 従来は別の参考画面キャプチャを貼ったり、テキストベースで情報を伝えていて、手間だった

課題に感じたこと

• 使うべきコンポーネントの選定が難しい
  • 既にデザイナーが用意してくださっていた画面設計リソースから、適宜コンポーネントを選定して画面設計していた
  • エンジニアサイドでは「こういうときはこのコンポーネントを使う」というパターンが理解出来ておらず、誤ったコンポーネントを選択してしまうことがあった（デザイナーレビューでご指摘頂いた）
  • → 判断基準をドキュメント化するなどして事前にインプットできる環境を整えることができれば、レビューの手間も軽減できて良いと感じた
• Figmaに機能仕様のようなテキスト情報まで載せるかどうか悩ましい
  • 画面設計として、Figma上に画面レイアウトを作るだけでなく、画面要素についての補足説明や機能仕様もまとめて記載した
    • → Figmaに全情報がまとまって確認しやすかった一方、テキスト情報の入力しにくさや検索性に課題を感じた
    • テキスト情報の入力しにくさ: Markdown記法が使えない
      • テキストはMarkdownで書けたほうが効率的という要望がエンジニアメンバーから上がったが、Figmaの基本機能では出来なかった
      • → Simple Markdown Notes のようなMarkdown記法をサポートするFigmaウィジェットを使えば改善するかもしれない
    • 検索性の課題: Figmaではファイル横断的な検索ができない
      • 補足説明として機能仕様的な内容も記述しており、全ファイル横断で情報検索したい場面がありそうだが、Figmaでは出来ない
      • → 検索性については、社内ドキュメントツールのほうが高いと感じた

まとめ

今回の経験を通じ、ある程度パターン化した画面であれば、エンジニアにも十分画面設計ができそうだと実感しました。

またエンジニアサイドで画面設計を行うことに一定の意義を感じることが出来ました。

個人的には、実装を始めてしまってからの手戻りをほぼ無くせたことや、エンジニアサイドから実装が簡単になるデザイン方針を提案できたことは、特に大きなメリットだったと思います。

ただ画面設計そのものおよびFigmaに対しての学習コストが掛かるので、全体として生産性を向上させるには、画面設計のテンプレート化を行うなど、さらなる効率化の方法を模索すべきだと感じました。

今後も引き続きエンジニアからの画面設計提案に挑戦し、生産性を向上させられないか検証と改善を重ねていきたいです。