2012/06/08に開催された『【shibuya meets tech 5】ディレクターとデベロッパーの“こそあど”』のノートです。ノートというかほぼ全部メモした感じですが …やはり生の会話には言葉の機微みたいものがあって、それが非常に面白いし、そういうものこそ残しておきたいと思うので、可能な限りノートに取ってしまうという …削った方がよいかな？と思う箇所は削りました。
20120608 shibuya meets tech vol. 5
講演者
株式会社ミクシィ 鈴木理恵子氏
株式会社バスキュール号 西村真里子氏
司会者
渋谷lab 鈴木氏
主催
渋谷lab
会場
Lightningspot
◆渋谷labって？
pasona techがスマホ開発とweb制作を行うための拠点
デベロッパやクリエータとコミュニケーションの機会を設けたい
技術セミナーをどんどんやっていきたい
◆自己紹介
◇鈴木理恵子氏
・背景
音楽の専門学校の出身
木工（ギターの製作）をしていたが、女性にはそちら関係の就職先が無く…
同じものづくりということで、ITならいろいろ実現できるのでは？と考えた
・mixiへの経緯
受託→SaaSと会社を移っていくなかで、（自分の関わるサービスを）もっと広く多くの人に使ってもらいたい、楽しんでいただく提案をしていきたい、という思うようになり、mixiに転職した。
・やっていること
mixi Platfromを提供し、mixiに関するアプリを作ってもらうという仕事をしている。
mixi上のたくさんの情報（つぶやき・日記）を、開発会社に提供するためのAPI。
◇西村真里子氏
・背景
- エンジニア5年。マーケティング2年。
- ちょうど90年代後半に学生をやっていて、や舞台照明をやっていた。
- 留学中に日本の友達と話すときにe-Mailを使っていた
- 大きなステージで照明を作る仕事をしていたが、Flashならもう少し身近に自分の作りたい大きなステージが作れることを知った。
- ITって何かすごいと思った。
・バスキュール号への経緯
いろいろ学ばさせてくれそうな会社ということで、最初にIBMに入った。
次に自分のクリエイティブを活かせるところに行きたいと思い、Flashを作っているMacromedia（現adobe）に転職。
それからグルーポンを経てバスキュールへ。
・こんな会社
- 12年選手の会社
- Flashメインで、インタラクティブ / マルチユーザ向けのコンテンツを作っている
- mixiさんと、いかにユーザが楽しくなるかというサービスを作っている
◇バスキュール号がリリースしたサービス / アプリ
・Fantastic Answer
- 友達とラジオを聴いて楽しむというコンテンツ。
- 大喜利みたいな感じでユーザがネタを投稿すると、ラジオで拾ってもらえる。
- ソーシャル・メディア・ラジオ・友達がmixiのプラットフォーム上で繋がる
・cotto
- mixiの友達とも楽しめるandroid用アプリ。
- デコアプリはいろいろあるが、これは複雑なコミュニケーション無しで使える。
・pelo
- チェックインツール。
- mixiにコネクトできる。
- 位置情報をベースに友達と繋がることができる。
- 海外のものは複雑だったり、mixiとコネクトできるものがなかったりした。
・Social Studium System
・mixi Xmas
◆topic / 現状・仕事の環境・組織体がどういう風になっているのか
鈴木
- 開発は小さな単位に細かく分割し、 それを速いスピードでいる
- チームは専門（機能や技術、サービスなど）毎に細かく分かれている
西村
- iPhone・androidのアプリや受託など、様々なものをやっている
- 何個も帽子をかぶっているような感じ
- 「いろいろな人と仕事ができるので、コミュニケーションとしては風通しがよいかな」
- 手が足りないときはいろんなリソースを使っている
◆topic / 現場の実態ってどうなのよ？
西村
「ディレクションとエンジニアのうまい連携を模索中という質問を頂いています」
鈴木
「永遠の課題ですね」
西村
「あとは、『自分に合ったスキルを身につけるべく現場の内情を知りたい』ということで …ディレクションとエンジニアの連携、うまくいってますか？」
鈴木
「弊社はわりとうまくいっていると思います」
西村
「私はディレクションとしてお金を儲けなければいけないので、クライアントの意見を『やりますね！』とか言って。それを社内に持っていくと（エンジニアから）『ふざけんなよ』ということがたまにあったり。『かっこいいことやろうよ！』といっても…」
鈴木
「『ちょっと待ってよ』とか」
西村
「そうそう。私とか気合とかノリで行こうとするんだけど、それがすごい嫌われるんですよね」
鈴木
「開発者からすると『ちょっと考えさせてよ』とか？」
西村
「そういうときはどうしたらいいんですかね？
『yes』って言って抱え込んじゃうと、体力勝負で潰れちゃったりとか …仕事が嫌になってしまう人もいると思うから、『ちょっと待ってよ』とか言ってくれた方がいいと思うんですけど。
mixiさんの方は、企画の方とエンジニアの方で『ちょっとそれ無理だよ』ときちんと言えるようになっているかとか、その辺はどうですか？」
鈴木
「弊社では、プロジェクトをどう廻していくかはチーム（チームリーダやマネージャ）毎で取り組み方が違うんですけど …大きく見ると、コミュニケーションを蜜にとろうとはみんな言ってますね。開発・企画の方を混ぜてミーティングを毎日やって、『今日何をするか』『もうやったもの』『まだやってないもの』を付箋でホワイトボードに張って。みんなの進捗が分かるようにしながら喋っていたり。で、けっこう大丈夫。それで解消されていることが多いですね」
西村
「企画の人も含めてそういう話をするんですか？」
鈴木
「そういうチームが多いですね」
西村
「毎朝とか？」
鈴木
「朝やっているところも、（一日の）締めでやっているところもあります」
西村
「ちょっと参考にしようと思います。というのは、企画の方で『いっちゃおうよ！』っていうごり押しとかしちゃったりとかして …（それよりは）なるべく、みんなが協調してできるといいなっていう。本当に模索中ですね」
◆topic / ディレクターと開発者の関係
西村
「今の会社に入って一年くらいなのですが、『おっ』と思うようなことがあって …企画を客先に持っていく前に、ブレインストーミング等で皆で考えて、『皆の提案を持っていくよ』という風にするようにしていて。そうするとうまく進められるのかな？というのを学びつつあります。
そうやると時間がかかるんですけど、ものづくりの人は自分の意見を反映したいというところがすごい深いと思うので …私みたいな（ディレクションの）人間はなるべくそういうことをやらないといけないのかな、と。
（参加者に向かって）
どうですか？ 私みたいな『やろうぜ！』というような人が来ると、いっしょに考えてくれたりとかしますか？」
参加者
「個人的には全然ありかな、と思っています」
西村
「どんな感じで進めているんですか？」
参加者
「いまはウェブではなくて、業務系のシステムを作っているんですけど、マネージャとプロジェクトリーダーがいる状態で、後は数人のチームで一丸となってやっている感じで。他部署との連携も多いので、話を聞くだけではなくて、きちんとコミュニケーションをとらないといけないと思っています」
西村
「ディレクター側と開発者側で悩んでいるというか『どうしてもうまくいかないんだよな？』『どうしたらいい？』といった悩みを抱えている人はいますか？」
鈴木
「別にディレクション職の方を悪く言うわけでないんですけど、開発の仲間がランチとかでぽろっと言うのは …ウェブの画面があって、『ここをちょっと変えてよ』というのがあると思うんですけど、ディレクターの方からしたら『見た目がちょっと変わるだけだから、大したことないんでしょう？』という感じだと思うんですけど、稀に裏の仕組みをいろいろと変えないとできないこともあって。『簡単に言うなよ』みたいな愚痴があったりしますね」
西村
「それがすごい怖いなと思うのは、本当にテキストを変えればいい場合と、後ろでバックエンドを呼んでいる場合とを把握しないで言ってしまうことがあって …テキストを変えるだけなら（開発側は）『オッケー』って感じなんですけど、バックエンドのところに繋がっていて『ふざけんなよ』って顔をされたときには、『しまったー』って思うんですよね。
…どのパターンか分からないっていう時はどう言えばいいんですかね？『変えておいて』じゃない方が？」
鈴木
「『どのくらいかかりますか？』と聞いてくれれば、何日くらいかは言えるので …そこでディレクションして優先順位を付けてくれたりするとうれしいなーって思います」
西村
「『変えてっ！』じゃなくて、ってことですよね …自分が本当、ひどい人のような気がしてきた」
◆topic / 組織の規模とコミュニケーション
鈴木
「mixiに入るまでは100人以下の会社にいたので、1つのプロジェクトを動かすにもだいたい4～5人、それにお客様くらいで済んでいたので、あまりコミュニケーションを蜜にとろうという意識はなかったんですけど …mixiは500人くらいいて、何か1つ変えるにしてもいろんな部署に伺いを立てないと後で大変なことになるので、その辺は気をつけるようになりました」
西村
「私は逆に、何万人規模から何千人 …いまは40人規模の会社に行って。いろいろと面白くて、いろいろ全部自分で見れるって言ったら変なんですけど、私はステップに沿った承認というのが合っていないタイプで。『時代がもう突っ走ってるんだから行こうぜ！』というタイプの、そういうことをやりたい人間なので、今の40人がすごい風通しがいいというか。
でも今は大きい会社だから守られていたというのもひしひしと感じていて。エンジニアとの会話でもそうかもしれないし、社内の会話でも、『いかに今まで守られていたところで仕事をしていて見ていなかったのだろうか？』とか『あー見えてなかったなー』とか …どんどん学んでいる感じがしますね」
司会
「会社規模って影響するところが大きいですよね」
西村
「大きい会社だから大きいことができるっていうのもありますよね」
（中略）
鈴木
「1000人 …もっと大きい規模の会社の人はいますか？」
（数人が挙手）
鈴木
「むしろ伺いたいくらいですね」
西村
「そういう大きなところでどうコミュニケーションをとれば …エンジニアとディレクターとか、もしくはエンジニア同士で、どういう形のコミュニケーションで問題解決をしているかというのを」
参加者
「どういう形で …私は開発でも研究側の方にいて、実際に事業をしている部門とはテレビ会議などを行なっています」
西村
「どちらかというと研究所の方が強い？ …って、変な言い方ですけど」
参加者
「弱いです。お金を稼いでいるのは事業をやっている方なので」
西村
「でも、コアはそこにあるじゃないですか」
参加者
「そうですが、お金を稼いでいる方が強いんです。そこからお金をもらって研究しているので …とにかく弱い立場で仕事をしています」
西村
「どうやって『なにくそ！』という感じにしていますか？」
参加者
「いや …メンタル的にきてしまうような人が出るような職場なので」
西村
「…私もちょうど前職でIBMにいたんですけど。そのときも大きな組織だからもどかしくてとか、意見が何重のレイヤで伝わらなかったりとか。メンタルとか壊す方もいて、せっかくスキルがある人達なのにどうしたらいいんだろう？とか …もともとの同僚がそうなっているのを見ると、どうしたら自分のやりたいことを企業の中でやっていけるのかな？という …難しい（問題）ですよね？ …そういうときは『飲みに行こう』って言えばいいのかな？」
◆topic / コミュニケーションで心がけることは？
鈴木
「『ディレクターとデベロッパーの立場でコミュニケーションについて普段心がけていることを聞きたいです。気をつけていることをお聞きしたいと思います』。ありますか？」
西村
「我々としては、いいものをつくってお客様に喜んでもらいたいというところがあるので、少なくとも、社内でどんな戦いがあっても、『いいものを作りたい』というビジョンは守っていきたいというのがあります。
それから、『みんなで作っているんだよ』と感じるにはみんなで会話する必要があると思うし、聞かないとみんなが喜んでくれるアイデアはできないと思うので、開発チームでなくとも参加できるように、ブレインストーミングとかで意見を聞くようにしています。
また、やはりビジュアルがあると具体的に話を進めていけるので、（ブレストに）参加するときには、できれば絵を持ってきてもらうようにしています。それを『いま解決しなければいけないのはこういうことですよね？』という点の参考にして話をするようにしています。
そういうのを頻繁にやっています」
鈴木
「私もディレクターに話すときはなるべく絵に落とすように心がけています。
私の周りのディレクターはオープンな人が多いのですが、デベロッパーには『今は触れてくれるな』という雰囲気を出している人がいて。私は喋るタイプですけど、そうでない人もいるので、（そういう人には）システムを使ってお願いや相談をしたり …人によって（コミュニケーションの手段を）使い分けたりしています」
西村
「それはわたしも気をつけています」
◆ topic / 盛り上がることの大事さ
西村
「（顧客への提案について。『こうした方がよくない？』というのが盛り上がって） …なんかみんな調子にのってやって。2週間以上これで盛り上がって、しばらく開発の時間が遅くなったりして。その提案は通らなかったんだけど、みんなで頭の中でシミュレーションしてキャンペーンやろうっていうのがあると、それは他のときにも使えたりするし …1回とか2回失敗しても、みんなで同じことを考えてみるのはいいことかな、と思います」
鈴木
「普段の業務とは離れるんですけど、社内のイベントで『WC2.5』というのがあるんですね。年に四回、月末の最後の2.5日を使って何かを作ろうという社内ハッカソンをやっているんです。それはエンジニアだけではなくて、企画の人とかデザイナーとか誰でも参加可能で、チームの募って合宿とかやっているんですね。最初は開発の人だけだったんですけど、徐々に企画の人とかも参加するようになって。
徹夜も覚悟でみんなで意見を出し合って。コンテストなので順位がつくんですけど …商品が出るのでみんなテンションがあがるんですね。かなり根をつめてコミュニケーションしてものをつくります。業務とは全く違うものなのですが、なかなかよい経験だな、と」
西村
「（その中から）サービスになったものもあるんですか？」
鈴木
「あります」
西村
「そういうのっていいですよね。やる気がでますよね」
鈴木
「コミュニケーションっていう意味でも、本音をぶつけあって。時間がないから遠慮しないんですよね …遠慮しないで言い合うっていうのがなかなかいい体験になっているな、というのがあります」
◆topic / コラボレーション
鈴木
「『異なる職種で見ているものを共有する工夫は？』ということなのですが」
西村
「モックアップとか、実際のシナリオを仮定してみるとか。元々Flashに強い会社なので、AndroidのアプリだとFlashからAIRで書き出して実機で動かしてみるというのはよくやってまして …これだと職種を超えてクライアントやメディアにも伝わりやすいので、非常に便利だと思っています。コラボレーションやりたいという人達には、『こういう感じになるから、一緒にやってみよう』という感じで使えます」
鈴木
「私はAPIを作る仕事なので、あまり画面というのがないんです。こういうAPIを作りましたというのを企画の人と共有しようにも、文字が出るだけなので全然共有できず、困ったことがあったんです。そういうときは、時間かかるけど『このAPIを使えばこんなアプリができます』という紙芝居みたいなものを自分で作って、意見をもらうように気をつけています」
西村
「絵とかモックとか言ったんですけど、いかに使っている人のリテラシーに合わせるかというところで、その立場の人が普段使っているものに当てはめるのはすごい大切。インサイトをどう使うのかというところはあるし大変だけど、それが見つかるといいなというのがありますよね」
鈴木
「相手の立場になって伝えようとしないとなかなか …というのはありますよね」
◆topic / ユーザビリティとデータとエンドユーザの関係
鈴木
「これは個人的に聞きたいことなんですけど …ユーザビリティテストはどうやっていますか？」
西村
「本当に常にやっているというか …企画段階でもそれが楽しいかどうかはまず社内でやるし、
クライアントにも何回もこういう形ですよね？というのを見せたり、ターゲットに近い人に実際に使ってもらったりとかしています。情報を集めて何回も絵にしたり、モックを作ったりしています。
いまやっているサービスでも、不都合があったところなど結果の分析をしていて …どういう機能だったらみんなが使ってくれているかというのを見たりしていて、使ってもらえる機能はどんどん良く、使われていない機能は削除してパフォーマンスを上げたり。
1回で終わりじゃなくて、何回もテストして良くしていく、という形でやっています」
鈴木
「そのテスト結果は開発の方などにも共有されているんですか？」
西村
「みんなで共有ですね。逆に調査部隊がいるわけではないので …エンジニアも『どういうデータが取れるか？』ということを考えながら開発するし、こっちも『どういうレポートがあればいいのか？』というのを考えながら作っていくというのをやっていて。結果を数値で見れるようにしています」
鈴木
「弊社でも全員に公開されているものがあって、それを見て声を上げる開発者もいます。みんなでやることで一体感がでるというところはあると思います」
西村
「データって大切ですよね。結果をちゃんと分析しないといけないというのは最近本当に思っていて …『作っちゃえばいいじゃん』ではなくて、結果を見てみんなで『どこを変えていこうか？』というのは必要だと思いますね」
鈴木
「私たちの仕事は一般の方がエンドユーザなので結果が見えやすいのですが、業務システムはユーザビリティの量り方が違うかもしれないですね」
西村
「確かに…
（参加者に対して）
業務系でユーザビリティというものはどういう風に扱われるのでしょうか？」
参加者
「正直に言うと、しっかりとは取れていないですね。大まかにやるくらいで …あとは人的にセミナー的なものを開催してお客様を集めてやる以外にの方法がなくて。サーバ自体をお客様のところにいれてしまうのでデータを取れないと。なので、提出して頂く何かしらの仕組みをとらないといけないのかな？と考えています」
西村
「それよりは、機能とかどれだけ正確に測れるかというのが重要視されるというのもありますよね」
◆topic / コラボレーションでやってはいけないことって？
鈴木
「『やり方や手法、やってはいけないことを教えていただければ幸いです』 …これは難しい」
西村
「やってはいけないこと …でも、失敗しなければ何も（はじまらないというか） …ねえ？」
鈴木
「コラボレーションでやってはいけないこと …なんでしょう？これ質問された方っていらっしゃいますか？」
参加者
「例えば考え方が違ったりいろいろあると思うのですが …何かやるにあたってタブー的な、開発者にこれ言ったらだめだよね？とかそういったことを聞ければ」
西村
「私も聞きたいです」
鈴木
「開発者の人って、割と非難されるのって苦手かな、と。
認めて欲しいというか、自分のやっていることに誇りを持っている方が多いので、どちらかと言うと『お世話になっています』『いつもすごいですよね』『信頼しています』『いつも期日どおりありがとうございます』とかそういうのがあると、すごく心の距離が縮まるというか …そういう一言で、『頼まれていたのはここまでだけど、先までやっちゃいました』とか、そういう方がいるような気がします。逆に、最初から『お前だめ』ってやると心を閉ざすのかな？と個人的には思います」
西村
「『お前だめだよ』って言う人がいるんですか？」
鈴木
「それは（ストレートには）言わないのですが …別に非難しようと思っているわけではないんだけど、個人攻撃のように感じられるような言い方というか …コミュニケーションってそういうことがよくあるじゃないですか？（特にエンジニアに対しては）そういうことは気をつけたほうがいいと思います」
西村
「例えばfacebookはある意味スタートアップ的なところから始まっているけど、エンジニアからああいう形にまで築いていたりとか …いまはエンジニアのほうがかっこいいと思いますよね」
鈴木
「エンジニアにもいろいろな人がいます …みんな得意不得意があると思います。
私は外に出てお話するのが得意なのでそういうスタンスでやっていますが、そうでない人もいるし、サービスによった開発をしたい人もいれば、言われたものや伝えられたものだけを確実に作るのが得意とか、いろんな人がいます。ただ、そういうものははっきりと分かれているように思いますね」
西村
「話をするのがすごく大切だと思っていて …エンジニアにもいろいろなタイプがいるというときに、
そのエンジニアは最終的にはディレクタになりたいと言っていて、『だったら一緒にやっていこうよ』という形でやっていき、それはうまくいきました、と。そういうパターンのエンジニアが多いのかな？と思っていたんですが、みんながそれを求めている訳ではなくて。
『俺はこれを完璧に仕上げたいだけだから。別に偉くなりたくない。ただこれは俺に任せてほしい』という人がいて。（最初はうまくいっていなかったのだけど）それを分かってからは、彼のスタンスとコミュニケーションできるようになった …ということもあって。一瞬でもうまくいかないなー、と思ったら話してみることが大切なんだと思いました。
一緒に仕事をしているのに改めて聞くのも照れくさいんですけどね。ただ、『この人はここを追及したいんだから、こちらの勘違いで変なプレッシャーをかけたらいけないなー』とか、そう思います」
参加者
「逆に開発に言われたくないことは？」
西村
「もう言われ慣れてしまったんですけど、もともとはIBMでエンジニアもやっていて、プロジェクトの中も知っているということで『こいつ現場知らないな』とは言われたくないけど、よく言われますね。
『お前は現場知らないんだから黙ってろ』みたいな。言われたくはないけど、今は実際にそうだし …過去のプライドはどうでもよくて、今のポジションだけ考えようというのがあります」
鈴木
「開発者がそう言うことはよくあるけど …よくないことだと思います」
西村
「そこで喧嘩してもどうしようもないし …『私はこのポジションだから』って切り替えて、『そうだよねゴメン』ってやろうかなとは思いますよね。
…ミーティングルームとかでも喧嘩になると、周りがとても寒いですよね。たまにありません？真剣に喧嘩になったりとか」
鈴木
「あります」
西村
「自分もたまにやってしまうことはあるけど …後から反省するし、そういうミーティングに行ったときって切ない気持ちになるので、思うことは合っても引こうかな、と」
◆topic / 質疑応答
参加者
「日ごろ、チームでデザイナやテクニカルの方と仕事をしているのですが、チームの中にテクニカルディレクターやアートディレクターという方がいます。そういう人がデザイナやテクニカルを管理しているという中で、下手したらディレクターっていらないんじゃね？と思うことがあります。
テクニカルだけで作っているアプリもたくさんありますし、そういう中でディレクターにしかできないことについて考え方を教えて頂きたいです」
西村
「一番強いのはアートディレクターやテクニカルディレクターです。私は会社に勤めている人間なので、いかに良いサービスをお金にできるか？とか、受託の仕事であれば、次に生かしていけるか？とか …ちょっとでもお金の換算というか、アートディレクターやテクニカルディレクターが引いた視点を持てればパーフェクトだと思います。でも、アートディレクターやテクニカルディレクターは現場でのアートやテクニカルなことに集中したい（と考えていると思う）し、そうしてほしいし、というところで …どちらかというと自分はプロデューサとして全体を見ることが多いのですが、クライアントとの関係とか、重要なパイプラインを作ることを自分の価値にしようとしています」
参加者
「それぞれの専門分野に集中してもらえればという…」
西村
「そうですね」
鈴木
「私もそういう目でディレクターさんを見ています。
お金の部分とか、本当に分析や効果測定しやすいデータというのはどういうものなのだろう？ということを考えたりとか、定期的に分析し続けたりとか、（そういうものは）開発者からはなかなか出てこないなと思っていて、そういうところをディレクターにお願いして調整してもらったり、他の人に考えてもらったりして …開発は開発に専念したほうがいいのかなと思います」
鈴木理恵子様、西村真里子様、渋谷Lab様、Lightningspot様、ありがとうございました。
0 件のコメント:
コメントを投稿