エキスパートインタビュー第四弾は、轟啓介さん。アドビシステムズでデベロッパーマーケティングを担当されている轟さんは、デザイナーやデベロッパーの生産性を向上させる事に誰よりも真剣な、熱いナイスガイでした！
Javaのエンジニアから、Flexエンジニアになるべく活動
──轟さんは、アドビでどのような役割を担っているのでしょうか？
エキスパートNO.4 轟 啓介さん
マーケティング本部というところに籍を置いていまして、デベロッパーマーケティングという役目を担っています。 入社した当時は、Adobe FlexやAdobe AIRの開発者向けのマーケティングを担当していました。今はWeb系の製品全般をみていますね。
──アドビに入社する前のご経歴を聞かせてください。
前職はJavaのエンジニアでした。サーバサイドの担当で、例えばECシステムのバックエンドを開発していました。 ただ、やはりバックエンドって地味なので、少し飽きてしまったんですよね。どんなにきれいなコードを書いても、満足するのは自分だけ……という感覚もありましたし。
そんなとき、Adobe Flex（※）に出会ったんです。Flexはバージョン2からAdobe ActionScript3ベースになり、オブジェクト指向で開発を行えるようになりました。 また、Flex BuilderもEclipseをベースとしたIDEに生まれ変わり、もともとJavaエンジニアだった私にはとてもとっつきやすかった。
そこで、Flexエンジニアになろうと決心して、いろいろと活動しました。それが2005～06年くらいですね。 当時の会社の上司に、Flexチームを作らせてくれと直談判しました。直談判なんて、初めてでしたよ。それまではどちらかと言うと「受動的」に仕事をしていた人間でしたから(笑)。それから、2年くらいFlexにはお仕事として関わりました。
※Adobe Flex：アドビが開発した、リッチインターネットアプリケーション開発のためのフレームワーク。Flash Player上で動作するため、複数のブラウザ上で同様に動作する。Flex Builder（現在はFlash Builder）はその開発環境である。現在はApache Software Foundationのもと、オープンソースによる開発が進められている（[参考]。
──その後アドビに転職されたわけですね。
はい。2008年の4月に入社しました。そうなったきっかけは、開発者コミュニティです。
Flexに惚れ込んでから、[Flex User Group (FxUG)]にも入って、コミュニティ活動にも力を入れ始めました。コミュニティ活動はすごく楽しかったですね。 そして、いろんなイベントでプレゼンテーションをしたりしていたのがアドビの目に止まって、転職に繋がったというわけです。
ベンダー主導からコミュニティ主導に切り替えていきたい
──轟さんの目から見ると、コミュニティというのはどのように見えているのですか？
白石編集長
私自身、FxUGにすごく肩入れしていましたので、コミュニティ活動にはすごく共感しています。 だから、コミュニティの皆さんが気持ちよく活動できているか、そういう場を企業側が用意できているのかなどについては、いつも気になっています。 コミュニティ活動に勤しんでいる皆さんは、忙しい中時間を作って活動している。だから、こちらも少しでもコミュニティ活動のお手伝いをしたいと考えています。
またベンダーの目から見ると、コミュニティが強い技術というのは、すごく安心できるんです。 私たちが提供する技術を、ベンダー主導からコミュニティ主導に切り替えていくためにはどうしたらいいのか、コミュニティのみなさんにとって魅力的に映るようにするためにはどうしたらいいのか、そういうことを考えるのが自分の仕事なんだろうな、と思います。
──なるほど。僕（白石）はコミュニティ活動をこじらせちゃった人間なので、コミュニティに理解がある方とお話できるのはすごく嬉しいです。ちなみに、轟さんはアドビの製品全般を使えるんですか？僕も開発者上がりですが、全然なんです……
実は、開発者をやっていた頃からデザインとかはすごく好きだったんです。 レベルは知れていますけど、FireworksやIllustratorで絵を描いたり、デザインしたり。私はアイスホッケーをやっていたりするんですが、チームのジャージをデザインしたりもしましたね。 映像とかも好きだったので、アドビの製品は昔から大体全部使ってました。
──それはすごい！
いやいやほんと、レベルはたいしたことないんですよ(笑) デザインが好きなデベロッパーなんです。
デザイナーとデベロッパーの協業に関心あり
ただそういう背景もあるので、「デベロッパー」に対するマーケティングを行う立場であっても、デザインはすごく大事だと考えていて、デザイナーとデベロッパーの協業というテーマにもとても関心があります。
例えば、昔は「画面駆動」でシステムを構築することへの反省から、UMLなどを使ったオブジェクト指向設計が主流だった時代があります。 ただ、ユースケースなどを中心に設計をしていると、システムの振る舞いを設計するのが中心になり、画面のことを考えるのは一番最後になる。そうなると、UIがシステム中心の使いづらいものになりがちなんです。 今、UI/UXを重視する風潮が高まっているのは、いい意味で時代が「画面駆動」「ユーザー駆動」に戻ってきたってことじゃないかと捉えています。
──なるほど。僕も以前はUMLを使用して業務システムを開発していたのですが、業務アプリのUIも改善されてきているのでしょうか？
正直、まだまだといったところではないでしょうか。 以前、豆蔵の羽生田栄一さんと、バウンダリ（※）駆動でシステムを設計できないか、なんて話をしたことがあります。 そうすれば、システムエンジニアにとって馴染み深い手法をそのままに、ユーザー中心のシステムを設計できるのではないかと考えたんですね。
※バウンダリ：システムの分析手法の一つ「ロバストネス分析」において、ユーザーとシステムの境界を表す要素。バウンダリは「論理画面」とみなされ、実際のUIと1:1で対応するわけではない。ほかに、システムの振る舞いを表すコントロール（ビジネスロジックにあたる）、システムの永続的なデータを表すエンティティ（データベースにあたる）といった要素があり、ロバストネス分析では、システムをこの三要素に分解して整理していく。
翔泳社の岩切晃子さんとも、システム管理者を対象にしたイベントを企画してはどうか、なんて話をしたことがありますね。 業務アプリのUIが良くないのは、開発者の責任じゃなくて、そもそもそのシステムの要求を出す側の、例えばシステム管理者が「本物」（のUXデザイン）を知らないのではないか、そこを啓蒙していく必要があるんじゃないか、という話になって。 そのイベントは実現できていないんですけどね。
──そのイベント、ぜひやりたいですね！しかし、僕も業務アプリのSE出身ですので、身につまされることがたくさんあります。最近では少しはマシになりましたが、それでもやはり自分自身UXに対する意識が希薄というか…どうしてなんでしょうね？
いろんな会社とお付き合いしてきた中で思うのですが、デベロッパー（的思考）が中心の会社と、デザイナー（的思考）が中心の会社では、開発に対するアプローチが全然違うんです。
デベロッパーが中心の会社だと、デザイナーの数はすごく少なくて、単なるグラフィック制作の人員として使われていることがほとんどです。 そういう会社にとっては、顧客の要件は絶対的なもので、でき上がったシステムが顧客の要件を完璧に満たしているかどうかを重視します。 顧客から来た指令をこなすという思考に陥りがちで、「なぜそれが必要なのか」にまで立ち戻らない。 また、システムの設計にデザイナーが深く携わることはあまりありません。アプリのデザインまでできるような人材を、単なるグラフィッカーとして使うという、すごくもったいないことをしている。
デザイナーが中心の会社だと、そうではありません。 お客さんの要件を聞きつつも、「このお客さんが本当に求めているものは何だろう？」ってところまで考えることが多い。 システム開発の目的って、間違いを減らしたいとか、仕事にかかる時間を短縮したいとか、そういう目的があるわけじゃないですか。そこを探った結果、システム開発以外の解決策を提案することすらあります。 システムの設計においても、デベロッパーの意見も尊重しつつ、「そのシステムは何のために存在するのか」を見据えていることが多い。
そういう、アプリ開発に関するそもそものアプローチの違いが、UIの気配りとかに大きな違いをもたらすのではないでしょうか。
まあ、デザイナーやデベロッパーといっても、実際にはいろんな方がいらっしゃるので十把一絡げ（じっぱひとからげ）にするのは危険ですけどね。
──なるほど、デザイナーはUIを担当することが多いので、自然とユーザー中心のアプローチを行うようになり、バックエンドを担当するデベロッパーは、自然とシステム中心のアプローチになっていくのかもしれませんね。そして先ほど、「デザイナーとデベロッパーのよりよい協業」というテーマにすごく関心がある、とおっしゃっていましたね。秋葉さん（エキスパートNo16）もすごく関心がありそうなテーマですし、僕も関心あります！秋葉さんと二人で、それだけをテーマにした「デザイニアン」というイベントをやったこともあるくらいです。
はい、そのテーマにはとても関心があります。秋葉さんともそんなテーマでお話してみたいですね。
──で、せっかくアドビの方にお話を伺うのですから、ツールという観点から、そうしたテーマについて聞いてみたいと思います。2013年6月にリリースされたAdobe Creative Cloudですが、これはデザイナーとデベロッパーの協業をより促進することも目指した製品なのでしょうか。
そうですね、クラウドを活用したコラボレーションは、今後のCreative Cloudの重要なテーマです。 Dropboxなどを通じてクラウド越しにコラボレーションする…といったことは今でも行われていますし、非常に利便性が高いことは実証されている。Creative Cloudもそうした共有ストレージ機能を有しています（※）ので、Photoshopで作成したデザインカンプをクラウド上で共有することは、容易に行えます。 さらにアドビならではの付加価値を付けていきたい。例えば、PhotoshopやIllustratorのファイルはそのままプレビューすることができるほか、ファイルのバージョン管理も自動的に行われます。ツールの設定もクラウドを通じて共有できるので、いつでもどこでも自分好みの環境で作業を行えます。
※Creative Cloudのメンバーは、無償ユーザーは2GB、有償ユーザーは20GBのオンラインストレージを利用することができる。
また、5月にロサンゼルスで開催されたAdobe MAXのSneak Peeks（今後、アドビ製品に搭載される実験的な機能をお披露目する場）では、クリエイター向けのクリエイティブツールと、開発者向けのEdge Toolsが連携するデモもいくつか披露されていましたね。 Photoshopで作成したデザインカンプをEdge Reflowに取り込んで、そのままレスポンシブなサイトを構築できたり、PhotoshopのファイルをEdge Codeに読み込ませると、そのファイル内で使用されている色情報がCSSのコードヒントに出現したり。
まだリリースされたばかりなので、まだまだやるべきことはたくさんあるんですが、Creative Cloudでは製品のバージョンアップが加速しますので、片っぱしから実現していけたらいいな、と考えています。
生産性の高い開発の先に、開発者の幸せがある
──期待しています！最後に、HTML5 Experts.jpの読者に対して、伝えたいメッセージがあったら教えて下さい。
私は昔、プロジェクトマネージャーとしてガントチャートを引いたりしていた経験から、「開発の生産性」というところにすごく関心があります。 生産性の高い開発の先に、開発者の幸せがあるんじゃないか、と。
現在のWeb開発を、生産性という観点から見ると、JavaScriptというゆるい言語で大きなアプリケーションを作っていくのは、大変なんじゃないかな…と感じています。 効率のよいチーム開発はできているのか、とか、altJSを覚えるというのにも別の苦労があるんじゃないだろうか、とか、いろいろと疑問があります。
また、Web技術が進化するにつれて、学習すべきことがどんどん増えているのでは、という危惧があります。 Web自体はどんどん進化するべきだし、それでユーザーが恩恵を受けるのには大賛成です。でも、作り手がそれでキツイおもいをしてはいけない、と考えています。
アドビは残念ながら有償のツールが多いけど、私たちを含めた様々なベンダが頑張って、制作者に少しでも余裕が生まれるといいな、と思っています。 そしてその余裕が、より良いアウトプットにつながるようないい循環を目指したいですね。
