2018年12月に開発リーダーを務めていたプロダクトがリリースし、今年から異動により別チームとなりリーダー業務から卒業しました。2017年から今のチームのリーダーをやってきたので、かれこれ2年ほどになります。
ありがたいことに**「運用フェーズチームのリーダー」と「開発フェーズチームのリーダー」**両方を経験することができたので、それぞれのフェーズでどのようなことを考えて取り組んできたか、通常業務以外でどのような課題に取り組んできたかを書き残しておきたいと思います。
あまり詳しいことはNDAの関係で書けないため、ある程度応用の利くように抽象化して書いていきたいです。
リーダーに必要な姿勢
結局のところ、チームの問題や課題というのは千差万別なので、これさえやっとけばOKというものは存在しないです。
ただ、どのようなチームにも問題や課題というものは持っており、そんなものが存在しないと抜かすのは見えていないだけの戯言です。
そういうものについていかに気づいていけるか、どのように対処するか、というのがリーダーの仕事であると思っています。
チームに長くいればいるほど抱えている問題に気づきにくいという側面ももちろん存在するので、常に目を皿のようにして課題に気づいていく姿勢が大事だと思います。また、新しくジョインしてきたメンバーに感想を求めるのも良いと思います。ぜひ耳を傾けましょう。
今回は受託開発での運用業務・新規開発業務のことであるというのが前提なので、自社開発やBtoC案件のもの、スタートアップ、非ゲーム案件といった状況が異なる場合は、また違った対応になってくるでしょう。
自社開発やスタートアップの場合の組織論とかチーム運用については、すでに優秀な人が本を執筆しているし、Web上にもまた私より優秀な人たちが資料をあげています。またチームに対して予算がつく場合もあるでしょうし、そうなればしめたもの。
アジャイルに則ってーとか、スクラムを使ってーなどとマネジメント技術を駆使できれば格好良かったのですが、それらを学んでみて実践しようとしても、結局のところは現実に起きている問題に対処していくしかないです。
マネジメント技術は起きている問題に対処していく手段、武器の一つに過ぎないので、結局のところマネジメント技術ありきではなくどう使うかの選択をどうしていくかというほうが重要なんじゃないかと思っています。
誤解しないでほしいのは、これらの技術を学ばなくても良いということでは**ないです。**技術を一通り学んだ上で、その時その時の状況を見て現場に対して何が使えるかの選択をしていきましょう。
何度でも書きますが、プロジェクトの状況を見て武器（やり方）を使い分けていくべきです。
どんな状況のチーム？
ここで私の担当したチームの状況を書きます。状況に応じてチームやリーダーの動き方は大きく変わってきますが、ざっくり書くとこんな感じです。
- お客さんの案件を請け負う受託開発である
- 勤務している会社の性格上、受託開発案件が多いのですが、多分に漏れず私の担当したチームも、お客さんから工数（人月）をいただいて開発を行っていくものでした
- 案件はブラウザゲーム
- 2012年からスタートしているが、3年程度周期で新規タイトル(続編)開発が行われる
- 2018年3月頃、3番目の続編開発が始まった
- そのため新規開発といっても常に運用中のものが存在するという結構特殊な環境であった
それぞれのフェーズで考えてきたこと、取り組んできたことを書いていきたいと思います。
今回書かないこと
なお、各フェーズにおける機能開発や具体的な実装技法については今回は割愛します。
また、主にこのようなフローで「通常開発」が行われましたが、これについても割愛します。
- 既存バグ修正
- 運用中、追加機能を実装する上での見積もり
- 仕様内容すりあわせ
- 工数の見積もりと実装内容の交渉
- 実装
- テスト
- 監視
- トラブル対応
- お客さんからの要望・質問に答え続ける
あまりにもエンジニアの日常すぎるので、今回は書いても仕方ないかなと思うためです。