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