QualiArts Advent Calendar 2019、17日目の記事です。
弊社には、開発ディレクター（以下、開発D）という役職が2015年に作られました。開発Dが発足した時からかれこれ5年間くらい、そのポジションで奮闘していますが、今回はその役割について個人的に感じている事などを交えながら、記載しようと思います。
一般的には、PMやPOと近しい役割を一部担ったりもしていますが、会社により定義は様々だと思いますので、あくまでも「QualiArtsとしての開発D」という観点で読み進めていただけたらと思います。
#QualiArtsの開発ディレクター
作られた経緯
ネイティブゲームへと事業の方向性がシフトし、ゲーム開発の規模拡大に伴って、「開発全体のリーダー」が必要となった為。
責任領域
- 開発管理
- 品質管理
要は、新規プロジェクトでも運用プロジェクトでも、しっかりとスケジュール通りに不具合なくリリースをしましょうという感じです。
他にも、「メンバーのマネジメント」や「評価」などの役割も担っています。
「スケジュール通り不具合なく」と聞くと、何を当たり前のこと！！という感じかもしれませんが、この当たり前の実現には、たくさんの壁があります。その壁にぶつかった時に判断し、それを正解に導く働きを全力でするのが開発Dの役割なのではないかと僕は感じています。
本当によくある壁
基本的にはどのプロジェクトでも必ずと言っていいほど挙がる内容ではないかなと思います。
- スケジュール
- 人員、コスト計画
- 技術選定、実現可能性
- チームビルディング
- メンバー同士の合う合わない問題
- コミュニケーション
細かいものを羅列したらキリがないくらいあるかと思います。
僕自身も、普段からできる限り事細かく注視して違和感を感じた場合は先延ばしにはせず、自分で解決、もしくはメンバーを頼って解決するように働きかけています。
開発を進める上で、問題になりそうな所、なった所に関しては役割を超えてでも行動を起こし、どうにかするための働きがけをするというのがQualiArtsの開発Dの特徴かもしれません。会社全体の判断が必要な場合には、経営層に混ざり議論をすることもあります。
色の異なり
責任領域は明確ではありますが、各プロジェクトの開発Dによって動き方は全然違います。
例)
- サーバーサイドに特化した開発D
- 必要に応じてAPI実装、管理画面の実装、インフラ構築をする
- クライアントサイドに特化した開発D
- 技術判断や、必要に応じて画面実装をする
- 事業に特化した開発D
- 事業課題を把握し、必要に応じて事業の課題解決に向き合う
上記の例は極端な部分もありますが、開発Dの中でもそれぞれの強みも違うので、明確な責任は持ちつつ必要に応じて、動きを変えたりします。
余裕がある時は自身のスキルアップに時間を使ったり、本を読んだり、興味がある分野に足を突っ込んだりと、開発Dというポジションをうまく利用できたりもします。
まとめ
開発Dについてまとめてきましたが、将来的には開発Dがいなくてもチームが成り立つような状態にしたい、そのような状態に近づけるために試行錯誤しながらプロジェクトの成功に貢献できたらと考えています。
この記事を書きながら、「なんでも」ってなにやったかな？と考えた時に、過去のプロジェクトでひたすらゲーム内のボタンのタップ領域を広げるという作業をしていたことを思い出しました。
最後まで読んでいただいてありがとうございました。