エントリー
採用情報
社員の声
プロジェクトの流れ
開発フェーズ
- プランナーM
- 2016年入社。多くのタイトル運営と若手教育をこなす。プランナー職最初のメンバー。2児の父。
- デザイナーK
- 2020年入社。デザイナー長。デザイナー全体の管理も担当しており業界歴は当社メンバーで最も長い。
- プログラマーA
- 2011年入社。創業初期メンバー。片手くらいの社員数の頃から現在までを知る。エンタメなんでも好き。
- プログラマーY
- 2019年新卒入社。最近リードっぽい事も任されるようになった3年目社員。自称コミュ障。慣れてきた。
どんな業務内容でも
目的は全員同じ
- 新規タイトル開発の流れを教えてください
- デザイナーKデザイン部署では、まず仕様書を確認して制作物の洗い出しとその制作概算工数出しから始まります。その後、ワイヤーフレームを作成し、画面遷移図を作ります。併せてプロジェクトごとのコンセプトアートを作成し、グラフィックのクオリティラインの策定やデザイン仕様を作成し、プロジェクトに沿ったツールや手法をプログラマーと相談しながら設計に落とし込みます。次に、主要となるゲームサイクルができたら必要に応じて修正対応を行います。で、最後にアニメーションやエフェクトを制作・実装し大体の流れが完了となります。リリース前から更新内容が決まってるので並行して次の事に取り掛かってる事が多いですね。
- プランナーMプロトタイプ作成→仕様書作成、承認→デザイナー部署の工数を確認→プログラム設計と工数の確認→デバッグとレビュー&修正を繰り返し完成。具体的な工程はもっと多いのですが大雑把に言うとこんな感じです。細かく説明しようとするとかなりあります。
- プログラマーAプログラマー部署では、まず仕様書の確認を行い大まかな設計と概算の想定工数を出します。複数人いるのであれば、各人の担当範囲の振り分けを行い実際それぞれが担当する箇所ごとに詳細な想定工数を出します。次は、コーディング作業に入ります。先に内部のシステム部分のコーディングを行い、デザイナーのレイアウトが上がったら細かい演出等のUI部分の制作に取り掛かります。そして、コーディングが終わると単体テスト→結合テスト→システムテストという流れになります。デバッグと修正をしっかりと！
- それぞれの部署での業務内容を教えてください
- デザイナーKデザイナーの業務内容としては、デザイン仕様作成／UIデザイン／グラフィック素材制作／3Dモデル制作／アニメーション制作／エフェクト制作／Unityへの実装／広告用に使う素材製作／外注ディレクション／他部署との連携と進行管理、おおまかですがこれくらいです。それぞれの中にもっと工程があります。あと、プログラマーチームとの進捗の共有などで頻繁に連絡取る時もありますね。
- プランナーM企画と進行管理、品質管理です。言葉で表すと少ない印象ですがかなりやる事は多いですね。仕様書通りに実装ができているか、認識に違いがないか、問題は発生していないかなど開発中のコミュニケーションはもちろん、進行状況を見てスケジュールの管理も行っています。各部署のプロジェクトリーダーと情報共有をしつつ、全体を見て都度判断を下していきます。開発の後半からは品質チェックも行います。リリースがゴールじゃないんで運用フェーズもリリース前から取り組みます。
- プログラマーY大体の流れは、「基本設計」→「詳細設計」→「実装（コーディング、Unity実装）」→「テスト」ですね。プログラマーはやはりゲームの実装が主な作業です。バックエンドからフロントエンドまで一通り実装を行います。ポジションにもよりますが、プログラマー全体のプロジェクト進行管理、広告実装なども行います。人数が多めのプロジェクトの場合は進行管理や各部署との情報共有、連携にしっかり時間を割かないといけないですね。
- 進行中に良く起きる問題点はありますか
- デザイナーKスケジュール調整ですね。新規開発のタスクとリリース後の運用フェーズタスク、既に運用中のタイトルが同時に動いている事が多いので、正直なところリスケやタスクが前後する事は多いです。私の場合は他デザイナーのスケジュール管理なども行ってますのでいつ誰に何をさせるか、どこにヘルプさせるかなども含めかなり広めに把握してなければならないです。
- プランナーM不具合や想定外の対応が入るとかなりバタつきますね。開発中は予定通りにいく事の方が少ない気がしますが常に臨機応変に対処していかなければいけません。
- プログラマーAプログラマーもスケジュール調整がよく起こります。デザイナーと同じなんですが新規開発タイトルと運用タイトルを同時担当しているメンバーがほとんどなのでリスケが必然的に多くなります。リスケするにしても他部署との作業絡みなどもあるので各所にスケジュールの相談をするのがちょっと大変です。
- プログラマーYあと、あるあるだと思うんですが、すぐできそうだと思ってたら案外詰まって時間がとてもかかってしまった、などはよく起こります。知識が少ないころに作成したぐちゃぐちゃなコードのアプリの更新とかを重ねていって、どこでどの処理をしているのかわからなくなることもよくありますね・・・
- 職種間でコミュニケーションを取るときに気を付けていることはありますか
- デザイナーKどの部署もそうかもしれないですが齟齬が無いよう、なるべく分かりやすい言葉を選んだり、ログを残すなど後から確認したり複数人へ同じ情報が共有できるようにしています。とにかく同じ認識を持てているかの確認が大事です。イメージする人と手を動かす人が違うものを見てるような状態は避けたいですね。
- プランナーMあとは情報を残さず伝える事、プランナーは特に意図を伝える事も重要ですね。なんでやるのか、どう考えてこの発言に至ったか、などですね。プランナーって普段から考えを巡らせているので、つい伝わっていると勘違いしたりするんで意識して何度も確認、共有するようにしてます。
- プログラマーAプログラマーの場合、仕様通りにできるできないの判断を行うのではなく、代わりにどういった内容であれば実現できるかなども併せて伝えないといけないですね。こういった際にプランナーの意図が組み取れていないと作業を戻らなきゃいけなくなるので結構確認を重ねてます。
- プログラマーYそうですね、僕も実装し終えてからプランナーさん、デザイナーさんの意図していた動作と違っていたことに気づいた、などが無いようにすり合わせをしっかりと行うように心がけてます。何度も同じ事を聞くことになると申し訳ない気持ちになりそうですが違うもの作ってロスするよりはマシですしね。
- 新規タイトルの開発を進めるうえでのやりがいを教えてください
- デザイナーK仕様書をベースに進めますが、演出や補足などデザイン主導で動ける部分も多く、その意見が商品となるので、とてもやりがいがあるかと思います。作っているとこういう表現の方がいいのでは、と思う事もあるのでそういった意見をいつでも出せるのが良いところでもありますね。
- プランナーM私は自分の立てた仮説がデータで結果として突きつけられるところですね。個人的な性格もあるかもしれませんが、うまくいった、うまく行かなかったけど新たな結果を見れた、という発見があるのがやりがいです。データっていうのはユーザー様が遊んでくれた結果なので、ユーザー様の声というか意見のようなものが知れたという事が嬉しいのかもしれません。
- プログラマーA何もない状態から製品を作り上げていくため、自分が書いたコードによって各動作が出来上がった際にはゲームを作っている感があって楽しさがありますね。チーム一丸となって製作したゲームが市場に出たときには、プロジェクトメンバーと達成感を味わえるので、苦労した時間があってもおおきなやりがいに感じます！
- プログラマーYそうですよね、一から作り始めるのでどのように進めていくか等を考えていくのは大変ですが、その分完成してリリースした時はとにかく達成感があります！リリース後ユーザー様の反応が良かったら尚更楽しくなりますね！
- 開発中のミーティングの頻度はどれくらいで、どんなことを話しますか
- デザイナーK参加人数も規模も様々ですが、平均すると2日に1回くらいです。リーダー同士もありますしメンバー同士もあります。内容は、仕様・設計についての確認や相談、進捗状況の共有やタスク調整、デザインの確認などが多いです。
- プランナーMプロジェクトの規模や複雑さによってまちまちです。定例ミーティングみたいに毎週固定でやったりは基本しません。不要なミーティングは皆の時間がもったいないので柔軟に行っています。良くないかもしれませんが急にミーティングが発生することも場合によってはあります。話す内容は全体の進捗、スケジュールの確認、問題点などですね。外注をしている場合はミーティングが増える傾向にあります。
- プログラマーA中規模でのタイトルだとリーダー同士のミーティングが多くなりますよね。プロジェクトミーティングも当然やりますがリーダー間の情報共有は2日に1回くらいでしょうか。結構頻繁にやってます。内容はやはり、仕様・設計についての確認や相談、スケジュールやタスク調整がほとんどです。
- プログラマーY現場ベースだと共有したい事が発生したら都度行う感じなので頻度はまちまちです。定例ではやってないですね。プロジェクト内だけでなくプログラマー間で技術的な面で情報共有したりもするのでそういうミーティングもあります。
エントリー
