LCL Engineers' Blog

バス比較なび・格安移動・バスとりっぷを運営する LCLの開発者ブログです。

追加機能の実装前にタスクの分解をしてみた

こんにちは、バックエンドエンジニアの id:kasei_san です

最近、アメリカン・ゴッズを見始めて、ようやく最新話まで追いつきました!

シーズン2からの主人公の行動原理がイマイチつかめなくなったのですが、ここからどのように話を畳むか気になって仕方ないので、最後まで付き合おうと思っています!

www.amazon.co.jp

さて、本日はタスク分解の話です!

機能追加実装時のこれまでの課題

1人の担当者が実装し、すべての実装が完了した後にコードレビューが行われるという流れでした

しかし、この場合、以下のような課題がありました

  • 属人性が高い: 担当者以外がその機能の仕様を知る機会がない
  • レビュー負荷が高い: 大量のコードを一斉にレビューするため、レビュアーの負荷が大きい
  • 手戻りが大きい: レビューの際に大きい問題が発生すると、手戻りが大きい
  • マネジメントしづらい: 進捗状況が分かりづらい、また複数の作業がある場合、優先順を間違えるリスクがある

上記の問題を解決すべく、タスクの分解を提案してみました

タスクを分解するとなんで上記の問題が解決するの?

機能追加チームのメンバー全員を集めて機能を説明し、やるべきことをホワイトボードに皆で書き出しました

その後、各タスクのゴールを明確にし、それぞれをissueにして優先順をつけました

これにより、以下の効果が期待できます

  • 属人性が下がる: 全メンバーがその機能の仕様を知っている
  • レビュー負荷が下がる: 分解したタスク単位でレビューを行うため
  • 手戻りが少ない: 粒度が小さいので、レビューの際に問題が発生しても、手戻りが小さい
  • マネジメントしやすい: 進捗状況がissueの残りでひと目で分かる。優先順も明確なので、調整の必要が無い

f:id:kasei_san:20190331172626j:plain
バス便のデータをCSVにエクスポートするclassを作る作業のタスク分解の様子。赤字は優先順です。今回は初めてだったので、やや細かめにメソッド単位でタスクを分けました

やってみてどうだった?

参加メンバーにたずねてみました!

良かったこと

  • 全容を把握しやすい
    • 最初の段階でタスクの全容を把握できたので安心感を持って進められた
    • 複数人でタスクを分解したことによって自分では考慮できていなかったタスクの漏れなどに事前に気づくことができた
    • リリースまでの残タスクが明確にわかった
  • ヘルプの依頼/受けが容易
    • 自分が手一杯になったときに作業の分担を簡単にお願いすることができた
    • 案件開始時に仕様と大枠の実装方針を共有していたため、後半に実装ヘルプに入る際にスムーズに入ることができたのでよかった
  • レビューしやすい
    • 細かくレビューしていただくので大きな手戻りがない
    • コードレビューのコストが下がった
      • レビューの単位が細かくなったため、より細かいことをしっかりレビューできるようになった
      • 誰でも気軽にレビューできるようになった
  • その他
    • 1issue1課題にしたため、issue上でのやり取りがシンプル
      • 大きいissueだと、いろいろな話題が1つのissueで行われるため、話題がとっちらかりやすい

目論見通りの効果を感じていただけて何よりでした!

悪かったこと

  • レビューが滞った
    • レビューのフィードバックが返ってこないとなかなか次のタスクを進めることができないことがあった
    • レビュー待ちの状態で次々とタスクを進めていくとIssueを分割した意味がなく、かえってブランチを統合するときに面倒になった
    • コードレビューが遅れたため、依存関係があるissueが停滞した
  • 細かくしすぎた
    • 分割の粒度が細かすぎたかもしれない。良い点でもあるがやり過ぎるとレビューもしにくくなると感じた。スピーディーにレビュー & マージできれば問題ないが、レビュアーも業務があるため限界がある
  • ブランチのルールが決まっていなかった
    • ブランチの分割がうまくできずにブランチの統合に戸惑った
    • ブランチの切り方を最初に共有できていなかったため、ブランチの依存関係がとっちらかった
  • その他
    • 複数人でタスクを分割していくので場所と時間のスケジューリングが必要
    • 一番難しいところは、結局ベテランのメンバーが実装した
      • 本当はそこも誰でも実装できるようにしたかった

レビューを滞らせてしまったのと、issueを細かくしすぎて、さらにそれ毎にブランチを切ったためにブランチが混乱してしまったのが、今回の大きな課題でした...

今後の課題

  • ブランチの切り方を共有する
    • 今回失敗したブランチの切り方は改善の余地がありそうです
    • 👉 最初にworkingブランチを作って、基本的にはそこからの子ブランチとする。孫ブランチはなるべく作成しない
  • issueの粒度をもう少し大きくする
    • ブランチ(イシュー)分割の粒度を良い感じにすり合わせる
  • コードレビュー
    • コードのレビュー待ちの状態の時にできるタスクを用意しておいた方が待ちの時間を有効に使えると思いました
    • コードレビューの時間を作る
  • その他
    • 今回は基本的には1人の担当者が実装をしたので、もっと1つの機能をチームで実装するようにしていく

次回はよりよいやり方に変えて、メンバーがさらに気持ちよく仕事できるようにしていきたいですね!

最後に

タスクを分解することで業務の属人性とマネジメントコストをへらすことができました!

今後も、誰が抜けても安心なチームを目指してカイゼンを続けていこうと思います

誰が抜けても安心なチームを作ることに興味があるエンジニアの方、ぜひ力を貸してください!

www.lclco.com