Flex勉強会＠東京イキマシタ
東京のFlex勉強会に初参加。テーマは「デザイナとデベロッパの協業を考える」。
で、いろいろ思ったこととか考えたことを。(勉強会の途中で帰ったので、既に議論済みだったらごめんなさい)
■なんでこのテーマなのか？
今までもデザイナとデベロッパの協業は当然のようにありました。で、なんでこのタイトルでのイベントなのか？
答えは明確で、両者が扱う言語が同じだから。てことですよね。
勉強会に参加するまでは、僕としては単純にデザイナとプログラマの作業切り分けポイントを決めれば済む話だと思っていたのですが、参加してみて、それだけでもないように思えてきました。
■広告代理店/プロダクション/制作会社
大手企業さんのスペシャルコンテンツなどの広告系サイト制作における会社間の構図は今後も特に変わらないと思います。
変わる理由がないし、企画や(Flash)デザインはシステム屋にはできない芸当ですし。
ただ、内容としては、
サーバーサイドと連動した仕組みは必須(当たり前)になってきているようなので、
アニメーションや画面制御としてのFlash制作のみというよりも、よりソフトウェアのアーキテクチャを意識した制作が求められているっぽい。
そういう意味で、システム屋がサーバーサイドを担当するなど、この分野においてシステム屋の登場する機会はもう少し増えるかもしれません。
一方、システム屋が専門とする業務システム開発も、(RIAの要素が加わったとしても)基本路線は変わらないと思います。
ただ、RIAの要素が加わったことやお客さんの目が肥えてきたことから、
従来の機能要求を満たしているだけではなく、ユーザビリティを考慮したインターフェイスや、その他リッチなインターフェイスを
新たな要求として受け止めなければならなくなってきています。
この点はシステム屋が真摯に受け止め、ユーザビリティの向上に励む必要があります。
要素技術としてはFlexのコンポーネントを使用するのが最適だと思っています。
他にも外向け(コンシューマー向け)のインターフェイスも併せ持った業務システム開発が考えられますが、
こちらは今までもたくさんありましたので、
今までと同じように、デザイン屋さんとシステム屋さんの連携で作ることになると思います。
但し、両者の作業の切り分けポイントは、「"HTML"と"(JSP/PHP化も含めた)それ以外"」というものから、状況に応じた作業切り分けポイントを選択するものへ変化しそうです。
■デザイン屋さんって？
一言でデザイナーといっても、いろんな方がいると。
例えばプログラムを書かないデザイナーがいるとします。
この場合は、デザイナー(デザイン屋の人たち)はPhotoshop/Illustrator等で全体のイメージやパーツを作ると思いますので、デベロッパ(システム屋のシステム開発者)は、そのデータをもとに画面を作成します。
デベロッパチームとしては、Flexサイドとサーバーサイドの2チームに分かれて作業することになります。
勉強会でのひがさんのお話の中では、「デザイナが作成したデザインをプログラムに落とし込む人」という人物が登場することになります。
これは、ある程度デザインのことがわかるプログラマが画面作成を担当しますという意味ですので、やはり画面作成はデベロッパ側が担当します。
このパターンは、JSP/Struts全盛の時によく僕も経験しましたし、今もよくある分業パターンだと思います。
但し、FlexやFlashの場合はHTMLのように画面1枚＝1ページではないので、デザイナーさんにその辺りの特性を勉強してもらわないとうまくいかないように思います。
もう一方で、プログラムを書くデザイナがいるとします。
単純な作業切り分けのほうが、デザイナ、デベロッパ双方にとって効率が上がるでしょうから、選択肢としてはこれ位しかないと思います。
1.(デザイナーが)Flashで作る。⇒ デベロッパはサーバーサイドのみ作ればよい。
2.(デザイナーが)Flexで作る。⇒ デベロッパはサーバーサイドのみ作ればよい。
3.(デザイナーが)mxmlで画面のみを作る。⇒ デベロッパはActionScriptの記述＋サーバーサイドを作る。
1,2の場合は、
元々FlashでActionScriptをがんがん書いてきた方々がデザインを担当された場合。(または「プロダクション＆制作会社＝デザイナー」とする場合)
この場合そもそもFlexの提供するコンポーネントとかはあまり使わないっぽいですよね。
僕の会社でもそうですが、画面内のほんとうに細か〜い部分の制御などは、ほとんどのデベロッパには作れない領域ですから、
僕の意見としては、サーバーとの通信のインターフェイスだけを取り決めて、クライアントサイドはデザイン側の皆さんに全部お任せするのが良いと思います。
3の場合は、yui-frameworksがポイントですね。
■ActionScriptでフルスクラッチで画面を書く。
僕が個人的に最もやりやすいと思っているのは、MXMLベースで画面を作成して必要なコンポーネントだけを別途作成する方法。これならFlexFrameworkの利点も使えつつ、自分だけのカスタムコンポーネントも作れるし。
またはデフォルトのクラス(Buttonクラスなど)を拡張して作るとか。
これがFlexの王道ですよね(違うかな？)
でも、プログラムが書けるデザイナーさん達なら、Flexを使わないでAS3だけでフルスクラッチで作り上げるんでしょうね。(僕はパーツを上手く作れないので、あまりやりませんけど。)
なのでyui-frameworksとかは、(Flexに依存しないように)RPC実装だけ切り離して使えるようにすればいいのだと思う。
Flexのコンポーネントを使うか/使わないかは、お客さんの要求するレベルや制作する側の意思/スタンスなどにも左右されると思うので、どちらも生き残りそうです。
■mxmlデザイナーっているのか？
mxml(Flexのコンポーネントを使った)デザイナーさんっていないと思っていたのですが、あちこちから聞く情報だと結構いらっしゃるようです。(相対的な話です)
僕個人的には、デザイナさんにmxmlを覚えてもらう気は全くありませんが、クラスメソッドさんの勉強会発表であったように「スキニング」でかなり制御できそうです。
さて、yui-frameworksで提案されたスタイルは、mxmlとそれ以外の切り離し。
HTMLとMXMLはそもそも違うのでテンプレートエンジンっぽくはなりませんが、かなりの分離に成功してるようです。今後の課題は、あまりに切り離しすぎて画面制御に関する部分もロジック側に行ってしまったのをなんとかすることだと思います。
■で？
で、表面上はこんな感じだと思うのですが、結論として、やっぱAS3っておもしろいなと(笑)
というのも、
最初は単純にFlex/AS3を通じて、デザイナ/クリエータとデベロッパの相互間でActionScriptの技術交流が起こってる！って感じだったのが、
いつの間にか、お互いの開発手法/スタイルなどの、要素技術よりももうちょっと背景にあるものまでが交流してるっぽくて、その辺りを実感して再び感動してしまいました。
まだまだ交流は深まっていきそうでかなり楽しみっす
勉強会主催者の皆様、すてきな会をありがとうございました。
