デザイン→開発における現在の問題点

Flash Catalystの目的は、デザイナと開発者の間の連携作業をスムーズに進めることだ。ワークフローを改善する、と言っても良い。

高度にインタラクティブで、リッチなUIを備えたRIAを作成するには、デザイナと開発者の作業分担、そして連携が不可欠である。まずは以下のような作業分担が理想的だ。

デザイナの仕事は、自己の創造力を最大限発揮し、より良いデザインとユーザビリティを実現することだ。ユーザが使っていて心地良いと思えるような、インタラクティブな仕掛けやエフェクトも必要とされるだろう。こうした仕事をこなすために必要なのは、デザイナの創造力をすぐに形にすることができる、IllustratorやPhotoshopなどのようなデザインツールだ。

対して開発者の仕事は、ソフトウェアが正しく振る舞うようにコードを記述することだ。例えば「このボタンを押したらこう動く」という仕様を実現するのが開発者の役目であり、そのボタンのデザインが美しいかどうか、というのは開発者にとって本質的な問題ではない。こうした開発者の作業を助けるのは、高度なコード補完機能を持ち、ビルド・デバッグ・プロファイルなどの作業を可能な限り効率化してくれる、Flex Builderのような統合開発環境だ。

このようにデザイナと開発者の間には、作業の目的や利用するツール、そしてそれらのツールが利用するファイル形式に至るまで、非常に大きな隔たりが存在する。これまではその隔たりを、「デザイナが開発者寄りの作業をする」「開発者がデザイナ寄りの作業をする」、もしくは「Illustratorなどで作成されたデザインを開発者が苦心の末に『移植』する」といった形で埋めているのが実情だろう。図にしてみると以下のようなものになる。

デザイナ/開発者間のこれまでのワークフロー

この図で問題となるのは、「開発者とデザイナの作業領域が明確に分かれていない」ことだけではない。矢印(作業)の方向が一方向にしか流れていないことも大きな問題だ。つまり、一度デザインが決まって開発作業に入ると、その後のデザイン変更は非常に高くつくことになる。以下のような状況が容易に想像できる。

  • 「元のデザインを先に変更してから、開発者がそれを開発中のアプリに反映する」 -- デザイン原本とアプリの整合性は保てるかもしれないが、コストが高い

  • 「開発中のアプリに対して、直接デザイン変更を行う」 -- コストは低いが、元になったデザインとの一貫性は望むべくもない