こんにちは、トクバイサービス開発部でバックエンドエンジニアをしている金子です。
サウナばかり行っていますが、合わせてプールも行き始めて体つくりにも興味が出てきましたｗ
弊社の近くですが、都内での屋外プールは貴重でおすすめのプールはこちらです。
業務の方では直近で開発した機能がプレスリリースしたので、こちらでも宣伝させてください🙏
トクバイとGooble Bussiness Profileが連携できるようになりました！
https://prtimes.jp/main/html/rd/p/000000208.000046400.html
さて、今回のテーマは チームの効率的なタスク管理 についてのトライについて書いていきたいと思います。
背景
そもそもなんで、エンジニアがチームのタスク管理なんじゃいという話もあるかと思いますが、ロコガイドではディレクター、デザイナ、エンジニアが小さなチームを組み、スプリントでプロジェクトを進めています。その中で、エンジニアも仕様検討から入ったりとプロジェクトの初期段階からチームで課題の解決に取り組んでいます。
エンジニアから見て、もっとこうなっていたら良いなということを試行錯誤した記録として見てもらえると幸いです。
また、同時期にエッセンシャルスクラムを読んでいたので、参考に取り入れさせてもらいました。
スプリントでのタスクがよりわかりやすくなるように(全体の見える化)
当時もissueを切る -> エンジニアをアサイン -> 開発 -> テスト -> リリースのような通常の開発フローで開発を進めていました。
しかし、以下のような問題点がありました。
① issueの大きさによっては、今何をするべきかはなんとなく分かるが何がどこまで終わっているかはissueからは読み取ることが難しい
② ルール化されてなかったので、開発にのってからissueができるとか、単発で調査のissueが出来るとか何の文脈からの調査か分からないなどissueを建てる人によって粒度がバラバラ
上記はリモート環境下になって、日常のコミュニケーションで解決出来ていたものがより難しくなったように感じます。
issueの構造化
そのため、issueの単位をスクラム手法に倣い、product backlog item(以下、PBI),sprint backlog item(以下、SBI)で管理し、それぞれの定義をチーム内でも共有しました。
product backlog item: ユーザーに与える価値(e.g. ユーザーが〇〇を出来るようになるなど)
sprint backlog item: 上記の価値を実現するために必要なタスク(エンジニアがPBIを実現するためのタスクを積む)
※ エッセンシャルスクラムでは不具合や技術的な改善を含めたプロダクトオーナーにとって価値がある作業なら何でもPBIとしていますが、チーム内で話し合い、プロダクトバックログの抽出についても不慣れな部分があるため、分かりやすいユーザーに与える価値として定義しました。
このように、issueを構造化することで
①に対しては、1つのPBIを達成するのにどのくらいの工数(SBIの個数や大きさ)で、今、どこまで完了していて、あとどのくらいかかるのかが分かる
②に対しては、PBIをユーザーに与える価値としているので、issueが切られるタイミングもある程度揃えられ、かつ、そのPBIを中心にタスクが積まれていくので文脈を見失うということもなくなります。
ただ、PBIを経由しないタスクも存在し、例えばバグ修正や、リファクタなどの改善などはSBIに積み、スプリントプランニングの際にチーム内で調整をしています。
zenhubをうまく使う
また、弊社はタスク管理のツールとしてzenhubを使っていたことも、上記のようにissueを構造化すれば効率化できるのではないかと思ったきっかけでもあります。
具体的には以下の画像のように管理しています。
さらに、zenhubにはissueをepic化する機能があるので、PBIをepic化してあげるとそれに紐づくタスク群(ABI)を関連付けることが出来ます。これによって、問題点①に対してもより見える化が出来ます。
また、まだうまく使えてはいないですがburndown chartは今後使っていきたい機能です。各issueにsprintが振られていれば自動で生成してくれるので、何か設定をする必要はなく、以下のように各sprintでのチャートを発行してくれます。スプリントの振り返りの際にはこういうグラフなどを元にベロシティや各issueのポイントの振り方などの反省の材料にしたいと思っています。
以上、issueの構造化, zenhubをうまく使う で全体の見える化はほぼ達成できたかと思っていますが、PBIの精度向上など、まだまだ出来ることはあります。今後も継続してチーム内でより良くしていきます。
まとめ
はじめはうまくスプリントを回すためにどうすればいいかというところからスタートして、上記の形で運用するところまでいくことが出来ました。
ただ、この運用にするまでにもissueの構造化などは従来通り、構造化せずにそれぞれのissueが独立してあった方が良いのではなど意見もありました。その時は協議して、利点の説明や意見を取り入れたり、チームに合った形を取ってきました。今後もユーザーに価値を継続して届けるためにも、各スプリントの振り返りなどを通じてチームに適応していきたいと思います。
