開発ディレクターはじめてみた

この記事は GRIPHONE Advent Calendar 2022 17日目の記事です。

こんにちは。Unityエンジニアの米倉です。
現在は新規開発のUnityエンジニアチームのリーダーをしています。

この記事では、自身がプロジェクトの中で開発ディレクターとして任命され、何も分からない状態から手探りで行ってきたことについて紹介したいと思います。

はじまり

（大きく意訳しますが）

「もっと開発のスピードを上げたいから開発ディレクターになってほしい！」

とPMやその周辺のメンバーからお願いされました。
この時点では、自分自身も新たなミッションとして前向きに受け取りつつも、具体的にどうしていけばいいかわからない状態でした。

開発ディレクター is 何

まず手始めにGoogle検索してみると、以下のような内容でした。

基本的にはソフトウェアやWebサイトの開発において、チームの指揮をとる人を指します。開発は複数人で進められるケースが大半ですので、それらをディレクターとしてまとめていくわけです。(中略) 管理職的な役割を負います。実際に管理職に就いているかは別の話ですが、同程度のスキルが求められるのです。
https://www.anken-navi.jp/news/work-freelance/development-director/

また、弊社と同グループである株式会社QualiArtsでも、最近の記事で開発ディレクターの役割を言語化しており、こちらも参考にしました。

今までに比べ開発規模が大きくなり、各職種のリーダーが1人で開発管理、品質管理、技術判断、チームマネジメント、スケジュール策定などを行うのが難しくなってきました。
そこで「開発管理」と「品質管理」に責任をもつ役割として、開発Dを新設しました。
https://technote.qualiarts.jp/article/44

これらを自分なりの言葉に落とし込むと、「開発管理と品質管理に責任を持ち、チームでの開発をありとあらゆる観点から推進する人」かなという所感でした。

とにかく、プロジェクト内で開発ディレクターの需要があるということは、複雑な事情で進めづらい部分をうまくいい感じにやってほしい、と期待されていることはわかります。

プロジェクトで期待されていることに落とし込む

開発ディレクターという役職のおおよその働き方は理解したため、ここからは自身のプロジェクトにおいて期待されていることを把握するようにしました。

今回のプロジェクトでは複数のサービスの開発ラインを連動して走らせるため、2名が現在の業務と兼務する形で開発ディレクターを担当します。

そもそも前提として、普段の業務でUnityエンジニアチームのリーダーとしてエンジニアのマネジメントや企画との折衝、開発のスケジューリング等、ある程度開発を進行するための動きは実務として行っていました。

そのため、上記の領域やそれ以外の領域について、「さらにどのような動きを期待されているか」という観点でプロジェクトメンバーやステークホルダーにヒアリングし、自分に期待されていることを模索していきました。

見つかった期待&課題感

各所にヒアリングすることで見えてきた直近の課題感は以下でした。

開発イテレーションの推進者が欲しい
- それまではプランナーが開発者のタスク進行管理を行っており、工数配分的に少し負担がかかりすぎていた。
開発管理手法を見直したが、作業者に浸透しきれていない
- 一部コアメンバーによって整理された開発管理手法を各メンバーに改めて理解して貰う必要があった。
デザイナーを含めた開発管理と連携力強化
- ゲームシステム以外の、表現に関する要件などを適切なタスクに落とし込んで開発を効率よく進めたい。
イテレーション管理と実作業に必要なミーティングの切り分けをしたい
- 進捗確認のミーティングの中で具体的な議論に発展することが多く、必要な領域で切り分けて効率化したい。
プロジェクト全体のマイルストーンや現在の状況について透明性を上げたい
- PM、ディレクター、マーケティングの想定するプロジェクトの進め方を各メンバーが十分把握できている状態にしたい。

取り急ぎすぐ見えてきた課題感は役割分担の見直しとコミュニケーション不足の解消によって解決できるように見えたため、それぞれ必要そうな会議体を作り、実行することで解消を図っていくことにしました。

実行したこととその結果

イテレーション管理の引継ぎ

「このラインは○○さん」「このラインは○○さん」といった形の分担を再度関係者で話し合い、一部イテレーション管理を自分も担当することにしました。

結果：プランナーが開発管理する負担が軽減されました。

開発管理手法の統一、伝播

各ラインに分かれたイテレーションの確認時に、改めて開発管理の方針の共有を各メンバーに行いました。
どのような単位でタスクを切り、どのような単位でイテレーションを回すか、といった思想の部分を各イテレーション管理者同士で事前にしっかりすり合わせてから各メンバーへ伝えるようにしました。(自分自身もかなりヒアリングしました)

結果：作業者が自発的にタスクを切り、ステータスを更新するようになったことで開発管理の定例の時間が短縮されました。

開発管理の単位にそったミーティングの見直し

それまでなんとなく必要な単位、慣習的な単位で行っていた定例ミーティングを見直しました。
基本的にはタスク管理に用いるカンバンボードと定例ミーティングの単位が一致するようにしました。
バトル機能のような複雑な要件に対する作業者どうしの連携ミーティングを新設し定例化しました。

結果：開発管理のミーティングで実装の話に脱線するケースが減り、タスクの優先順位やステータスの話に全員が集中できるようになりました。

開発ディレクターミーティングの新設

ディレクター（プロジェクト全体を見ている人）と開発ディレクター、プランナーリーダーを集めた会議体を新設し、プロジェクト全体のスケジュールの話と開発の具体的なスケジュールの話を情報共有し、問題解決を図る場を新設しました。（ディレクター側から設定してもらいました）

結果：ディレクターと開発チームの情報共有がスムーズになり、課題のキャッチアップや問題解決に対する意思決定のスピードが上がりました。

現状の所感

ミーティングを少し増やすことになりましたが、見直したことで結果的にはそれぞれのミーティングが気持ちよく終わることが増え、開発効率も上がってきています。

まとめ

開発ディレクターとしての事始めは以上のような交通整理から始まりました。
まだまだ足元の課題解決の動きしかできておらず、今後もありとあらゆる問題に対処していくことになると思います。

この役割にたった一つの正解などはないため、プロジェクトの開発をより良く進めるために自ら考え、行動することを引き続き意識したいと思います。

同じような境遇に際している方の参考になれば幸いです。
ご覧いただきありがとうございました。

それでは、明日の記事もお楽しみに！