TALK SESSION

会社が成長するにつれ、人数も一気に増えてきた10ANTZ。メンバー同士の意思統一も重要な仕事です。そこで取り入れられているのが「スクラム開発」という手法。新規タイトルに関わる、プランナー、エンジニア、デザイナー。それぞれの立場から、プロジェクトの進め方などについて語ってもらいます。

01

それぞれ職種は違っても、 見ているゴールは同じ。

金丸

新規プロジェクトを進めるにあたって、まず意識したのが職種の壁をなくしたいなということでした。エンジニアだろうが、デザイナーだろうが、プランナーだろうが関係なく。お互いがお互いのことを、補完し合えるような体制にしたいなという思いがありました。同じ目的でつくっているはずなんですけど、職種をまたぐと各々が考えていることが変わってきて、忙しくなればなるほどケンカになったりすることも。なるべくそういうことをなくしたくて、誰かが忙しい時には、他の人が手伝える部分は手伝ってあげる。忙しくなる時はいずれ来るので。そこに向けての考え方というか働くスタンスをみんなで共有できればいいなと。

原田

やっぱり自分以外の職種に関わるって難しいです。エンジニアがデザインのことが分かるかって言うとやっぱり分からないので。そのうえでチームとしての働き方には、ふたつの大切なことがあると思います。自分の任された領域のクオリティを担保することと、最終的な目的を意識すること。エンジニアはコードをかいて終わり、デザイナーはデザインをあげたら終わりではなく。それぞれの役割はあくまでもひとつの手段であり、目的はいいプロダクトをつくること。忙しくなるとついつい自分の仕事に追われがちになりますが、最終的なゴールを、みんなで同じものを見られているかどうかが大事。それがスクラム開発の考え方なのかなと。

高浦

私はスクラム開発っていうのに関わるのは初めての経験です。もちろん、それまでのプロジェクトでも目的がひとつに絞れているっていうのはあったんですけど。どちらかというと、目的を共有したあとの仕事はデザイナー個人に任されていた部分もあって。今はプランナーさんやエンジニアさんとも頻繁にコミュニケーションをとりますし、チームとして進めている実感がありますね。話していくなかで、あ!こんなやり方や考え方もあるんだっていう勉強にもなりますし。

金丸

スクラム開発を導入することになったきっかけも、元々少人数で開発をしていた時にエンジニアからやってみたいという提案があったからなんですよね。コアメンバーにそういう意識の人が何人かいてくれたので、取り入れやすかったというか。

02

やることも、やらないことも、 みんなでハッキリと決める。

原田

いま思えば、立ち上げメンバーは最初からスクラム開発っぽい意識を持っていましたね。個人プレーじゃなく、チームワークを大切にする雰囲気だったんで、意見のいいやすい場でした。おかげで初期の段階から無駄なくやれてきたっていうのもあります。システムを実装する前から、しっかり話し合って仕様を明確にできたので、やっぱりいらないとか、これどうなってるの?といったやり取りは極力、少なくできるように意識していました。

金丸

プランナーの立場から言うと、ゲームの開発は仕様の部分と ストーリーなどのコンテンツがあってはじめてひとつの機能になるのですが。やるか、やらないかわからないままシステムを実装まで組み込んで、結局使わないとかっていうのがあったりするんですよ。なるべくそういうのを無くすようにはしました。企画が煮詰まっているものに関しては、いつまでにこれをやりましょう、と。逆に、その段階でふわっとしているものは一旦捨てて後回しにして、決まってから進められるように。プランナーチーム内でも密に話し合ったうえで、デザイナーさんやエンジニアさんに伝えています。

高浦

デザインに関しても進める前や途中でも、お互いに意見を出せる場があるのは、いいなと思います。デザイナーの視点からここはもっとこうしたらいいのにとか、気になることも言いやすいですし。みなさん、こちらの意見を、ちゃんとくみ取ろうとしてくれる人たちばかりなので。そういったところも楽しくいられるポイントなのかなと。あと、デザインの部分は、どうしてもスケジュールがおしてしまいがちなのですが、そういう時は、全体の調整もしていただけて。自分のことだけじゃなく、一緒に仕事をする仲間を思いやってくれる、やさしい人が多いですね。

03

話しかけられる距離感と、 話さなくてもわかる連帯感。

金丸

僕たちの仕事は、どうしても最初にデザインが必要になります。なので、デザイナーさんには、プレッシャーが、かかりがちなんですよね。デザインをしはじめてみたら、意外に時間がかかったり、こんなのが欲しいっていう希望だけを出してみても、実際にできるかできないかわからないということもあって。そんな時は、みんなの手が止まらないよう、空いている作業を入れ替えたりできるようエンジニアさんにも相談して、調整してもらいます。そういう意味でも、エンジニアとデザイナーの席は、なるべく近くに置いて。毎日喋りながら、わかんなかったら何でも聞いてくださいね、みたいな感じにしていますね。

原田

デザイナーさんがつくったものを、エンジニアがシステムとしてつくりこんでいくので、コミュニケーションの機会は多いですね。共有できることがあれば早い段階から共有しますし、もしも工程が遅れそうな場合でも、そこは急かすんじゃなくて。自分たちの部署でどうフォローすれば全体のスピードを上げられるのかを考えます。反対に、使用している画像素材のことなどは、自分たちにはわからないので、これってどこで使われていましたっけ?と聞くこともよくありますし。異なる専門分野だからこそ、普段からの連携が必要だと思うので、気軽に話せるのって大事ですよね。

高浦

客観的な意見を聞けるのも、このチームの良さですね。たとえばプランナーさんであれば世界観をまとめてくれている方々なので、こういう風にしたいんですけど、どう思いますか?と、あらかじめデザインを確認してもらいます。エンジニアさんであれば、コードをかくときのことも考えて素材の分け方を考えたり。そこでもらった意見を反映しながら、デザイナーとしてこうしたいという思いもあるので、じゃあ今回、この案を採用しよう、と。チーム間の認識や進め方で、ちょっとずれてきたことがあった場合は、気づいた時にちゃんと話し合い調整しているので、大きなズレもなく進められているんだと思います。

原田

物理的な距離も影響あると思います。単純に、離れていたら話しかけに歩いて行くのが、面倒くさいっていうのもありますけど。近いと話しかけやすいですし。だからこそ距離の近さが大事なのかもしれないですね。ただ、集中してる時は話しかけないでみたいな(笑)

高浦

私も集中しちゃうとイヤホンしてシャットアウトします(笑)

金丸

僕はあんまりイヤホンしないんで。イヤホンしてるなぁって思いながらも、話しかけたりしちゃいますけど。聞こえるかな?と思いながら、あ!聞こえたって感じで(笑)

04

ここまで来たら、あとはやるだけ。 チームの為に、それぞれの役割を。

原田

ある程度、機能の実装が終わった後は、ソースコード自体のクオリティ担保とか、バグをつぶしたりといった、パフォーマンスの向上に比重を置いていきます。機能開発は楽しいですけど、これからはリリースに向けて気を抜かないでしっかりやっていかないとなっていう段階です。その辺の工数ってなかなか確保しづらくて、ついつい機能開発優先になっちゃいがちなんですけど、そこの判断は僕がしないといけない部分。今までに、みんなで作りあげてきたもののクオリティを上げにいく時期ですね。

高浦

デザインは、ちゃんとのめり込んでもらえる世界観を、どこまで突き詰められるかですね。あとは、楽しんでもらえるように、お客様の邪魔をしないと言いますか。ある意味空気のような存在になって入り込んでもらえる場をデザインするのが、デザイナーの仕事 なのかなと。どんなにキレイなデザインでも、それが目立ちすぎて、お客様の邪魔をしてしまうのは違うなと思うんです。リリース直前までは、そういった細部にこだわる時間にしたいです。

金丸

プランナーとしては、その後のマネタイズや運用面のことを考える段階です。直近のことだけでなく中長期的に考えて、どういう企画を実装するかという指揮をとることを意識して進めたいなと思っています。管理する側としては、リリース直前ってどうしても殺伐としがちなんですけど、そうならないように、みんなで同じ目的に向けて仕事しているんだっていう雰囲気をつくっていきたいです。