はじめまして！ タノシムスタジオ所属のゲーム大好きエンジニアの永井です。
今回はタイトル通りの、そんな装備(技術)で大丈夫か状態から
リードエンジニアとしてプロジェクトに関わり、リリースまでの
チームビルディング施策や気をつけてきたことをご紹介します。
担当プロジェクトでのエンジニアマネジメント課題
【メンバーは大体知らない人】
今まで運用メインの部署にいたのですが、今回の新規立ち上げのため異動して
誰も知る人のいないチームに参戦しました !
チームビルディングはチーム開発をうまく回すための１番大きな要素です。
起こりうる課題や、突発課題などには、開発期間中にどれだけ信用/信頼関係を作り、
本音で語れるようになれるかがとても重要と考えています。
しっかりした信頼関係が築ければ、細い指示がなくても簡単なコミュニケーションや連絡だけで
目的/課題の達成が可能になるので、開発速度も高速になり、
機敏な方針転換/役割の譲渡も可能になります。
また、全てがうまく行く開発は、宝くじの1等が当たるレベルでないと思っています。
そのうまくいかない時の「妥協」や「我慢」などのストレス下でも
課題を解決して行くには信頼の構築が本当に必要と思っています。
この関係性の構築を、ほぼ接したことのないメンバーで１から始める
というのがとてつもなく胃が痛くなる課題でした。
【Unityプロジェクト】
参加メンバーは、すでにUnityを使用し開発されておりプロフェッショナルな方が多く
対して私はcocos2dがメインからUnity初挑戦となり
こちらも、上述のメンバーの信頼にもつながる大きな課題の１つでした。
大きくは下記3つになります。
・ 周りよりも技術的に劣る者が上に立つメンバーの不安
・ 自身の能力/判断が開発遅れの原因になってしまう恐れ
・ 技術習得の時間が確保できるかどうか
ただ、自分の学習モチベーションはめちゃくちゃ高い状態で
周りにプロフェッショナルがいるという安心感もあり
プライド捨てて学びきるという根拠もない自身が当時あった気がします(笑)
【開発期間】
1年 + 数ヶ月
この業界の速度で言うとこの期間は多いかと思います。
やりたいことを全てやるには圧倒的に期間が短く
足りないもの、チームでの課題、技術能力的な課題が多い中
この期間で本当にやり切れるのか・・・？とかなり不安要素でした。
【課題まとめ】
なかなか課題の多いチャレンジングな環境になります。
エンジニアチームリーダー/開発メンバーとして、
この短期間で全てを学び自分で実装するのは難しいので
・ 忌憚なく意見を出せる環境づくり
・ 技術習得 / チーム内での役割分担や共通認識の作成
・ 工数のために抑える、見切りをつけるため区切りでの判断力を備える
のそれぞれの成長達成を目指し、チーム開発を円滑に進めるため
エンジニアメンバーが課題を抱え込むことなく共有でき、開発に集中できる環境を作る
というのをミッションとしてして定めていました。
開発のすゝめ
チームビルディング で気をつけたこと
必要な役割と分散をするためのチームビルディングの始めとして、
- メンバーの技術力の把握
- どの程度技術を収めればチームで対等に話せるか
を知るところから始めました。
具体的には、
自己紹介シートを作り、メンバー1人1人と1on1を行い
・ 自分を知ってもらうこと
・ メンバーと自分の共通点を探すこと
に注目を置き
・ エンジニアメンバーが気軽に本音で話せる環境を作る
と言うのを終始意識してコミュニケーションをとりました。
信頼関係作りの初手になります。
また、進行上、常に考えて状況に応じてやり方を更新していくのはもちろんのこと
・決定した内容
・決定した課程/前提の課題
の考えを、デイリースクラムで重複した内容でも必ず伝えるようにしていました。
チーム開発基盤 で気をつけたこと
開発初期は能力がバラバラだったため
ある程度のフレームワークに沿って、メンバーの認識を
揃えながらワンランク上を目指す形を取りました。
レギュレーションの整備/確認(クリーンアーキテクチャの採用)
・ コーディングルール / 設計のルールを決める
・ 全体/画面のルールを決める
開発物の認識のすり合わせ
・ レビューを行う ( 有識者メンバー→チームメンバー全員がレビュワーになれるように )
上記の認識をすり合わせながら少しづつ改善を加えました。
ちらしの裏
- クリーンアーキテクチャの採用
https://developers.wonderpla.net/entry/2021/02/18/121932
こちらの記事でも紹介されていますが、Clean Architectureを採用し、
画面単位の設計やclassの分け方の認識をメンバーで揃えました。
この前提が大きく、半年でレビューの精度も大きく上がりました。
お互いにレビューができるようになり、かなりの機能において共通認識を持て
属人化も大幅に避けることが可能になりました。(私の技術習得も高速化しました)
また、誰でも同じ形で実装できるようになったため、
タスクの分散がものすごく楽になりました。
変わる環境 / 大きな問題
大枠はうまく回せていましたが、それでも世の中も大きく変わっています。
ここではそんな中出た、大きめな問題と対応を紹介したいと思います。
コロナ からの オフィスの移転縮小、リモート勤務
この1年でやはり1番大きく外せない出来事！
それはもう、これしかないかと思います。
- コロナ からの リモート勤務
ここでの問題は、他者が見えないため不安感が募ったり、
今までの気軽なコミュニケーションの仕方がガラッと変わってしまったことにあります。
そして見えていないことから、サボってしまいがち になること。
この対策は本当に難しく、即席での解決は難しいものでした。
働き方に関しては、フレックスでコアタイムなどもあり今までもかなり柔軟に
働ける環境だったかと思います。
しかし、オフィスではなく自宅と言うのは集中環境も変わってくるため
それでも足りなくなってきているかと思っています。
その中で今回は
◆課題
その期間でのタスク消化と各メンバーが+αの実力を発揮すること
◆やり方
メンバーに集中タイムや働き方の時間の撮り方を大きく任せる
の大きな方針で進めました。
ただ、下記の4項目は必ず把握するようにしていました。
・ MTGなどの時間を守るための事前準備
・ アジェンダ、議事録をしっかりとり認識の共有
・ 仕様を必ず全部読み全体を把握する
・ メンバーのその日の進捗をgit /タスクチケットの状態から全て把握する
さらに、コミュニケーションが会話からslackなどのチャットツールメインになったため
・ チャットのレスポンスの速度も大事にし、スタンプなどでも反応をできるだけ送るようにする。
・ 遅れた場合はメンションを必ずつけ反応を必ずする。
と言うのを徹底してもらいました。
このタイミングから、自分で開発するところから、把握と開発を優先に
チームを回すことをメインで仕事をするようになりました。
開発初期時と同じレベルで、泥臭くコミュニケーションをしっかりとるようにして
環境の変化に対応して行きました。
外部要因の開発事情
こちらは技術的なところですが
・ 使用するフレームワーク(Unity)のversion更新問題
・ SDKのversion更新問題
・ iOS/Android のOSアップデートから起きる問題
が今回のプロジェクトでも発生しました。
自分たちでの設計している部分に関しては修正工数は出しやすいものです。
逆に、こういった外部要因が強く調査に時間がかかるものに関しては
・ 調査する期間を決める、
・ タスクを調整し専任できる人を立てる
ように解決に動くのがベターかなと思います。
調査系のタスクは思いのほか長引いたり、マルチタスクで行うと思わぬ漏れが出てしまいます。
どんなプロジェクトでも起こり得る問題なので、そういった使用している技術の最新を
常にチェックするなどが突然の対応にならないための必要な考慮かと思います。
使用する技術が初ということもあり、こういった問題が起こるだろうという想定も
開発初期にある程度まとめていたため、当面した際に大きく慌てずに対応ができました。
(工数の関係上タイミングが危なく、ひやひやはしました)
まとめ
いかがだったでしょうか？
かなり大枠の流れの説明のため、
もっと使用した細かい開発手法や話したい技術的な内容などもありますが
どんな環境でもチームビルディングにリードとして必要なことは
・達成するために考え、その考えをしっかりメンバーに伝える
ということかなと思っています。
ただ、想定していくつか準備も行って進めてきましたが
その物量を把握し地道にこなすと言うのは思っていた以上に大変でした（笑）
今回の私のチームビルディングも考え方や判断の選択肢の一つとして、
どなたかの役に立てれば幸いです。
チャレンジしたくても不安で立ち止まってしまう・・・
そんな方への勇気のかけらになればいいなと思います！
足りないものが多いスタートで、チャレンジは多いものは、それに伴う成長も大きいです！
今後もレベルアップしながら次の世のコンテンツを開発/提供していければと思っています。