開発フローからチームビルディングまで　LIG×エアークローゼット×DMMが語る、フロントエンド開発事情 - Part1

事業会社・制作会社の違い

司会者：パネルディスカッションを始めさせていただこうと思います。事前にみなさまからいただいた質問から、いくつかディスカッションのネタを用意しました。それらをもとにして、4名の方にお話しをうかがえたらと思います。

では、1個目は「事業会社・制作会社のそれぞれの違い」についてです。本日は制作会社・事業会社と、業態の違う会社さんが集まったので、この機会にいろいろな業務の悩みや、その業務の悩みをどう解決したか、あとは事業会社・制作会社「ならでは」のおもしろさがあると思うので、そちらについていろいろお聞きできればと思います。

では、LIGさんからお願いします。

岡澤伸也氏（以下、岡澤）：Webの受託製作の特徴だと思うんですが、一つひとつの案件のペースがだいぶ速いです。

LPだったら1週間、2週間というスパンでリリースまで持っていったり、いろんな質や種類の制作物に携われるのが、制作会社の1つの特徴だと思います。

司会者：土屋さんはどうですか？

土屋大輔氏（以下、大輔）：さっきの発表でもお見せしたんですが、システムを作るだけじゃなく、見た目を派手に動かしたりすることも必要になってくるので、Canvasを使っていろいろ表現したり、SVGを使って表現したりします。

見た目に関わるところで、いろいろ触る機会があるので、そういう楽しさがあるのも制作会社の特徴だと思います。

司会者：ありがとうございます。では、千葉さん。

事業会社のつらみ

千葉：DMMはたくさん事業がありますが、ユーザーにインパクトのあるものを事業だと作れますし、ユーザーの声が直で聞けたりします。

「これ使いづらいよ」とか、こっちがよしなに思って、いい感じにデザインを変えたんだけど、「昔のほうが使いやすかった」みたいなクレームがけっこう来ます。

松本雄太氏（以下、松本）：（笑）。

千葉：弊社には、Slackに顧客からのクレームだけを垂れ流すチャネルがありまして、そこを見てるともう……。なので、「心の強い人だけしかチャンネルに入らないでください」というふうになっています。

でも、こちらがよしなに思っていることと、顧客が求めることって違うと思うので、そこらへんを直に感じ取れるのは大きいです。エアークローゼットさんはどうですか？

松本：そこはすごく同意です（笑）。お客様の声をダイレクトに受け取って、ちょっと凹むときも一切ないわけじゃない。

千葉：（笑）。

松本：お喜びの声をいただく時はすごくうれしいです。僕は入社して間もない頃に、新規事業としてAndroidのアプリを出したんです。今までエアクロにはなかったので、新しい「pickss」のサービスをAndroidで出したことについて、お客さんからすごく喜んでいただいたメールが来た時は、目頭が熱くなるようなこともありました。

（事業会社の）つらみとしては、運用・保守の面でつらいと思うところがけっこうあります。「今これをやってるけど」という中で、他の施策を持ったグループから「これをやってほしい」と言われた時とかは、「ええ〜？」ってなる時もけっこうあります。

あとは、僕が個人的に「RDD」と言っている、「リリース駆動開発」というのがあって、リリース日がドーンと決められて、そこに向けて全力でがんばる。そこらへんは、ちょっとつらいと思うことがあります。

その反面、1個のプロダクトを長く持っていくので、そのプロダクトを愛でることができるのはいいことだと思っています。「これを新しく入れてみました」「このコンポーネントを作ったんですけど、これどうですか？　すごくないですか？」みたいに、1人が作ったものを、みんなが長期的に使いまわしていくので、けっこう愛を持ってプロダクトを育てることができると思っています。

司会者：ありがとうございます。各社の話が聞けていいですね。

製作・開発のすすめ方

司会者：では、もう少し具体的な話題として、「実際、製作・開発をどうやって進めていますか？」ということで、「どんなフローで？」とか、「どこから案件が降りてきて、どんな流れで最終的にリリースするの？」みたいなところを、掘り下げてお聞きしたいと思います。同じ順番でいきましょうか。

土屋：弊社の製作で言うと、ディレクター・デザイナーによるヒアリングから始まって、デザインの提案があって、そこを通ってから開発が始まります。

フロントエンドがデザインの再現をしたり、一緒に開発していくというような工程を経て、それがない場合もあるんですが、バックエンドはその案件に必要な工程を広く担当します。そういうことを経て、デプロイです。

なので、製作に関して、フロントエンドとデザイナーに限っては一緒に進めることがあるんですが、各職種の作業時期は分かれて存在している印象です。

岡澤：同意です。

（一同笑）

職種に関係なくフラットに

司会者：じゃあ、DMMの千葉さんお願いします。

千葉：先ほど組織変更のお話もしましたけど、スクラムをやっているチームというか、事業部が多くて、そのチームが持っているプロダクト主体で、改善や新規リリースは行っています。

もちろんサービスを運用している側に許可をとったりもしますが、けっこう自分たちの良きタイミングで（動いています）。そうは言っても、次のリリースまでに2ヶ月空くとかはないです。「小さいレベルで」ですね。

例えば、「4行変えて小さくマイナーバージョンをリリースしよう」とか。そういう粒度でやっているところが増えてきて、（他人から）言われてリリースするのではなく、自分たち主体で「ここをこうしたほうがいいよ」「こうやっていきたい」みたいな感じで開発をすることが多いです。

チーム編成はさまざまで、僕がいるチームはデザイナーもいますし、僕みたいによくわからない人間もいますし、サーバサイドの人間もいるので、正直そのチームだけでWebアプリが作れちゃうみたいなチームも多いです。

「APIしか提供していないよ」というサービスも、チームの中であったり、「秒間何千回叩かれても大丈夫」みたいなインフラを作れるチームもあって、おもしろい感じです。

松本：そこに関しては、うちはかなりフラットで、提案の嵐みたいな感じです。

例えば、他のグループがコラボレーションの企画を持ってくることもありますし、社内のグループが「こういうことをやったらお客さんが喜ぶんじゃないか」「じゃあ、こういうのを作ってください」みたいなこともあるんですが、そういうのに対して、企画の段階からエンジニアもガッツリ入って物申していくパターンも多かったりします。

「登録する時のフローをこういうふうにしたいです」という話が出た時に、「それをやるとお客さんとしては手間増えるから、それはやめよう」となって、流れることもあるし、逆にエンジニアから「こういうことやろうぜ」と言って、他の人を巻き込んでやっていくこともあります。なので、完全にフラットな状態でやっていて、（職種関係なく）物申していくスタイルです。

チームにおけるコミュニケーション

司会者：ありがとうございます。次の質問にいきます。「コミュニケーション」というところで、LIGさんの登壇の内容にもあったんですが、エンジニア同士だったり、異なる職種で、デザイナーとのコミュニケーションとか、いろんな職種の人たちが入り乱れてチーム開発をしているところもあると思います。

そういった中で、職種が違うメンバー同士でのモチベーションの高め合い方やノウハウ、あとは「社内で飲み会などのコミュニケーションはどうやってますか？」みたいなところを、ざっくばらんにお聞きしたいと思います。じゃあ、エアークローゼットさんからお願いします。

松本：エンジニア同士は、仕事をしながらよくしゃべったり、いじったりみたいなことを繰り返していたりして、かなり仲良くやっています。

うちのチームに関しては、昼ごはんはだいたい一緒に食べに行って、戻ったら一緒にスマートフォンのゲームで遊ぶのが流行っていたりするぐらい、とても仲がいいです。

うちの会社はコミュニケーションを大事にしていて、「いつでもいろんな人に話しかけていいよ」という環境を作っているので、他の職種の方と話す時も、普通にその人の席に行って「これどうよ？」みたいな感じで話しています。

デザイナーとのコミュニケーションについて

司会者：先ほどの登壇の中で、デザイナーの方は違うチーム体制でしたよね。そのデザイナーの方とのコミュニケーションはどうしてますか？

松本：もう普通にしゃべりかけにいきます。

司会者：かなり距離は近い感じで。

松本：はい。カンプを貰った時とかも、「ここはこうしたほうが良くない？」「アプリの概念的にこれは難しいからやめたい」という感じで、直接物申しにいきます。

司会者：なるほど。それに対して、デザイナーも「OK。わかった」みたいな？

松本：そうです。そういう壁がない感じです。

司会者：ありがとうございます。いいですね。千葉さんどうですか？

千葉：弊社は「どこからしゃべっていいのやら」という感じですが、まず人がたくさんいるので、いろんな人がいます。もともとデザインとサーバサイドとか、けっこう分かれていたので、エアクロさんみたいにフラットかと言われると、若干しこりがあるところが多いです。

司会者：ちなみに、「しこりをどう解消していくか」みたいなことはありますか？

千葉：難しいんですが、私はそもそもデザイナーあがりで、「管理画面を作って」みたいなことを言われたら、カンプを作るんじゃなくて、そのまま実装して、モックを「こういうデザインでどうですか？」みたいに見せるタイプの人間だったので、私はデザイナーとよく話しにいきます。

そこを上手くほぐせる人というか、デザイナーのこともわかるし裏の実装のこともわかるという人が、まだ弊社には少ないので、今後の課題だと思います。

今は職種間というのがあんまりないんですが、そこはけっこう横断的にやっていたりします。

フロントエンドで言うと、毎週金曜日にいろんな部署の人が集まって、「今週なにやった？」「今やってる案件が炎上して苦しい」みたいに、雑多に吐き出せる場があるのはいいところだと思っています。それが本当に職種関係なく広がっていくと、もっと弊社は楽しくなるんじゃないかと思いますが、まだ先は長い感じです。

「同じ釜の飯を食う」ような関係性

司会者：ありがとうございます。LIGさんはどうですか？　たぶんデザイナーと一緒のチームなので、コツや秘訣をお聞きできたらと思います。

岡澤：だいぶ原始的だと思います。「同じ釜の飯を食う」じゃないですけど、ランチはうちもチームで一緒に行ったりします。あと、LIGは長野にオフィスやゲストハウスがあるので、チームで合宿に行ったり、セブにもオフィスがあるので、そっちに行ったりします。そういうところで交流を深めたりというのはあります。

フロントエンドは、チームというかユニットの単位で言っても、週に2回ほど共有会の時間をとって、フロントエンドの人が集まって言いたいことを言っています。「困ってることがあったら言って」というかたちで進めています。

土屋：あと、「同じ釜の飯を」というところで、社内にキッチンがあったりして、料理が得意な人で振る舞うのが好きな人がいるので、業務時間後にカオマンガイ（タイ料理）がいきなり出てきたりして、カオマンガイパーティが始まったりします（笑）。

みんなでご飯を食べて仲良くなるみたいなのはちょこちょこあって、そんな感じでコミュニケーションをとっています。

司会者：ありがとうございます。やっぱり各社で文化の違いというか。

千葉：弊社も同じ釜の飯を食べるような機会を増やしたほうがいいですね。

司会者：チームでちゃんとご飯食べに行くとか、しっかりやらないとダメだなって、自分も思いました（笑）。