プロジェクトを円滑に進めるために取り組んだこと
はじめに
株式会社 RetailAI X Advent Calendar 2022 の19日目の記事です。
昨日は@yoshitake_tatsuhiroさんのPrefectを試用したでした。
自己紹介
株式会社RetailAI Xでエンジニアをしています。
直近ではトライアルで利用されている店舗運営システムのリニューアルプロジェクトにおいて、エンジニア兼開発チームリーダーとして携わりました。
今回はチームのアウトプットの品質を高めプロジェクトを円滑に進めるために、どのような取り組みを行ったか、また現在進行系でどのような取り組みを行っているかに焦点を当ててご紹介したいと思います。
どんな人へ
これから新しくプロジェクトを始める人
開発手法に興味のある人
チームリーダーを担っている人
チーム体制
PM:1人
バックエンドエンジニア:3人
アプリエンジニア:2人
デザイナー:1人
SREエンジニア:1人
最初からこの人数でやっていた訳ではなく、途中でメンバーがアサインされたりもしましたが、最終的には上記のような体制になりました。
また、私含めてメンバーの半分以上が20代という比較的フレッシュなチームだと思います。
やったこと
合宿
プロジェクトの立ち上げに伴い、箱根にある弊社所有の施設で合宿を行い、主に以下2点についてメンバーで話し合いました。
-
役割のすり合わせ
まずプロジェクトを始めるに当たり、各メンバーの役割のすり合わせを行いました。
方法としては各メンバーが自分以外のメンバーに対して期待していることを付箋で書いていくというやり方です。
その後、メンバーが思っている認識と自分が思っている認識にズレがないかということをすり合わせていきます。
自身の役割に対する認識の齟齬により、誰が担うべきなのかが不明瞭なタスクが生まれてしまわないようにすることを目的として進めました。 -
エレベーターピッチ作成
一人ひとりにエレベーターピッチを作成してもらったあと、全員で内容を突き合わせてプロジェクトに関わる全員が目指すべきゴールを明確にするという目的で行いました。
メンバーそれぞれが持っている役割によって観点が異なるゴールを書いていたのは興味深かったです。
また、一方的にプロジェクト責任者からプロジェクトのビジョンを語ってもらうのではなく(もちろん責任者の方に明確なビジョンは持っていただきたいですが。)、改めて一人ひとりが考えることで、プロジェクトに対して自分ごととして臨むことができたのではないかと思います。
基本的に弊社はリモート勤務で、私自身もリモート勤務派ですが、やはり大事な話をするときやプロジェクトを立ち上げるときは今回行った合宿のように、対面で行うほうが良いなと感じました。
リモートだと伝えたいことがうまく伝わらなかったり、相手の温度感も分かりづらかったりします。
かつ出社してMTGを行うのではなく合宿を行ったメリットとしては、他の業務に邪魔されることなく集中してプロジェクトについて考えることができたこと(箱根といういつもとは違う環境の中で行えたのも良かったと思います)、一日中一緒にいるので、初めて関わるメンバーの人となりも知ることができました。
また、業後はみんなで桃鉄で遊んだりとメンバー同士の距離を縮めることができたと思います。
合宿が終わった後メンバーに感想を聞くことができましたが、
「自分の理解度を確認することができた」、「プロジェクトを自分ごと化して捉えることができた」
などポジティブな意見が多く上がっていました。
また、冒頭でも少し書きましたが途中でメンバーがアサインされたり役割が変わることもあるので、その際は改めて認識のすり合わせを行っても良かったなと思いました。
スクラムの導入
プロダクトを素早く改善するために、組織としてスクラム開発を導入する取り組みが進んでおり、その一環として外部のアジャイルコーチの方に入っていただきながら開発を進めました。
-
振り返り会
2週間を1スプリントとして、スプリントで起きた出来事に対してKPT方式で振り返りを行いました。
今まで定期的な振り返りを行う文化が無かったのですが、うまくいっていること・いないことを自分一人の問題ではなく、チーム全員の共通認識として解決に取り組むという文化を作れたことは良かったと思います。 -
計画会
前述の振り返り会とセットで行いました。
次のスプリントまでに何を達成している必要があるかを念頭に進めました。 -
レビュー会
週に1度、成果物を実際に店舗で検証することによって、レビューを行いました。 -
終礼
毎日30分間終礼を行いました。
内容としては、その日行ったことの報告をメインとし、その他共有したいことや困っていることなどを相談する場としていました。 -
1on1
月に1度、チームメンバー全員同士で1on1を行いました。
コミュニケーションツールとしてgatherを使っており、gather上で二人一組に分かれ10分ずつ1on1を行いました。
gatherの良いところとしては、同じスペースにいれば誰と誰が喋っているのかが分かり、かつ近づかないと話の内容が他の人に聞こえないという点です。
意外とチームメンバー全員と1対1で話す機会がなかったので、どんなことに興味を持ったり考えたりしているのかを知ることができ、良かったと思います。
また、時間も10分ずつと短めに設定していたので、負担の無い範囲で行えたのではと思います。
今までスクラムという文化がなかった(あったかもしれませんが何となくだった)ので、いきなり全てのイベントを完璧に行うのではなく、少しずつできるところから取り組むよう進めていきました。
例えばストーリーポイントも最初の頃は集計せず、途中から集計するようにしました。
最初から完璧にスクラム開発を行おうとするとメンバーからの抵抗感や負担も大きいと思うので、少しずつできるところから取り入れる方が受け入れられやすいと思いました。
また、外部のコーチの方に入っていただくことにより、スクラム開発に対する専門的な知識を持ったメンバーがいない中、スクラム開発を行う枠組みを作っていただいたこと、今回私が初めて開発のチームリーダーを経験し、プロジェクトを回していく上で考慮していくべきポイントもご指導頂くことができたのは大変助かりました。
最後に
最後までお読み頂きありがとうございました。
今回ご紹介させていただいた内容が何かの参考になれば嬉しいです!
次回は@kobayashi-shotaさんの記事です。
Discussion