Tortoise Shell

デザイン、システム開発、ライフハックについてゆるく書きます

実装されたデザインの確認について

今の勤め先や、これまでの現場で「実装されたデザインの確認」を、どのように開発フローに組み込むかが議題になることがあった。

というのも、実装されたデザインの確認をしなかった場合、意図と異なるデザインのままリリースされる場合があるからだ。

この件は、デザイナーだからこそ意識の向くものであり、他のロールでは気付きにくいのかもしれない。あるいは、デザイナーも含めた開発チームとして、品質の基準をどのように持つかという問題でもある。

というのも、開発したものをリリースする場合、まともな開発チームであれば事前にテストを行う。コードベースでの単体テストや結合テスト、開発箇所以外にあらぬ影響を及ぼしていないかを確認するリグレッションテストがその一例だ。

この時、いわゆるビジュアルに関する部分は、システム開発の文脈では外部仕様と呼ばれるものだが、これは意図を理解している者にしか違和感に気づきにくい。

QAエンジニアの場合でも、明らかにレイアウトが崩れていたり、配色が不自然だったりすれば気付きやすいかもしれないが、ディティールともなれば、さすがにデザイナーしか気付けないだろう。

開発した機能が問題なく動作し、デグレもなければ、細かいビジュアルに関しては優先順位としても低くなりやすい。

しかしながら、それはエンジニアやPMがデザインやデザイナーを軽視しているわけではなく、単純にその視点を持っていないだけである。よって、デザイナーの方から手を挙げ、課題を共有し、デザインを確認するプロセスを提案するのが望ましい。

ところで、そもそもこのような問題が起きる原因は、デザインと開発のプロセスが分離しているからだ。Figma等の描画ツールで設計図を描き、それを説明し、エンジニアが把握して実装するというプロセスの時点で、そこには分断が生じる。細かなビジュアル面も含めると、そのコンテキストを完全に伝えることは不可能だ。これはデザインに限った話ではなく、何かを作る行為全般に言えることだろう。

ひとつの解決策として、ペアプロを実施するのは有効だと考えている。例えば、開発の文脈では、ペアプロやモブプロといった手法が既に普及している。メリットとしては、まさしくコンテキストを共有できる点にある。常にコミュニケーションを取りながら開発を進めるため、なぜその設計にしたのか、そのような書き方をするのか、といった思考のプロセスを常に共有できる。

もちろん、ペアプロは手段としての例に過ぎないので、あまり開発の知識がないデザイナーであれば、ペアワークという形で、実装する時にずっと隣で見させてもらうだけでいい。今はリモートワークが主流なので、画面共有をして、話しながら一緒にデザインを組み立てていくのだ。デザイナーにとっては、フロントエンドがどのように実装されているかの勉強になるし、エンジニアにとっては、疑問点をその場ですぐに解消できるので手取り早い。

要するに、コンテストを共有しながら、一緒に作り上げることが重要なのだ。そうしていれば、意図と違うものがリリースされるということは、そもそも起こりづらい。

この「実装されたデザインの確認」については、単純に「確認手順を設ける」といった線形のフローを設計するだけでなく、そもそもなぜ起きるのかから考えてみると、違った視点が見えてくるかもしれない。ぜひ試してみてほしい。