なぜ我々はタスクを小さくしなければいけないのか、そしてタスクはどのようにして小さくしていったか

この間、キャンペーンに当たったのでUSJの貸切ナイトというものに行って来ました。
日中120分くらい並んでいたアトラクションが20分以下！
なんならほぼ並ばずアトラクション直通で貸切の凄さを感じました。
冗談抜きで貸切の時間だけでアトラクション制覇できちゃいます。
来年もまた当たるといいな・・・

タスク管理がうまくいきません

そんな悩みはありませんか？
なんとなくうまく行ってないからいつもKPTのProblemにそんなことを書いている。
そんなことはありませんか？

そんな悩みを少しでも解決できる記事になれば幸いです。

はじめに

タスク管理の話の前に・・・私たちはスクラム開発を取り入れています。
これまでも「スクラムやってるよ！」と言ってはいたものの、正直なところなんちゃってスクラムでした。
それが今年の6月から他社で経験がある方がきたことで本格的なスクラムが始まりました。
（この話はいずれどこかで誰かがすると信じて割愛します笑）

ということでスクラムが始まってからチームの中に課題感が出て来ました。
「なかなか動かないチケットがある」
こういったチケットを減らすために、どうしていったかの話をしようと思います。

チケットの大きさが生産性に影響があるのか？

あります。
これはアメリカの有名大学の論文でも明らかになっています。

いや、アメリカの有名大学の論文は嘘なんですが（もしかしたら本当はあるかもしれません）・・・
スキル的にあまり差のないメンバーを何人かピックアップしてみて、それぞれがどういったチケットを切っているか？というところを分析したことがあります。
生産性（ここではデプロイ回数を指します）が高いメンバーとそうではないメンバーではチケットの粒度が大きな差ということがわかりました。
1つ1つのチケット流度が大きい場合、シニアでは生産性に違いがなく、ジュニアメンバーほど生産性低いという結果が出ました。
当時はさらに分析していないのですがチケット完了までのリードタイムを測ればより見えるものがあったかもしれません。

書籍などでは1日くらいの大きさでチケットを切ろう！みたいなことが書いています。

「デカ過ぎんだろ・・・」

正直1日だとまだデカいと思っています。
実際先ほどの生産性の高いメンバーはそれよりもっと細かく切っています。

チケットはなぜ細かくしなければいけないのか、どうしたら細かくなるのか。
理由を探りつつ解決策を考えてみましょう。

チケットが大きいと起こること

1日の業務時間内で1つのことにだけ取り組むのは稀である

そもそも皆さんは業務時間内に完全に一つのことに集中しているでしょうか？

人間ですから当然お昼を食べます。
たまに息抜きにTwitterもといXを開くことだってあるでしょう。
エンジニアですから突発的な対応が入ることもあります。
元から予定されていた1on1や定例MTGなどもあるでしょう。

業務中にコードに集中し続けられる状態というのは非常に貴重です。
私はマネージャーという役割を担っていますのでよくMTGが入ります。
1つ2つではないのでMTG終わりにはMTG前に何をやってたかなんてもう忘れています。

業務でコードを書くということはコンテキストのスイッチが要求されるのです。

コンテキストのスイッチというのは脳に対してかなり負荷がかかります。
その負荷は「やる気を削ぐ」「大量を奪う」という形で表れていきます。
何より「さっきまで何をしていたっけ？」の状態になることが一番の問題です。
何をしていたか思い出す時間が発生しまえばかなりのロスタイムです。
それが業務中頻繁に起こっていれば生産性という観点ではかなりのハンデを負いますよね。

これもまた弊社の制度なのですがチャプター活動（来年度よりテックサロン）という制度があります。
これは毎週金曜日の午後に職能単位やチーム単位で集まり、業務とは別で負債解消を行ったりする時間です。
この活動は「週に1回」の活動です。
先ほどの例では1日の中で考えましたが、1週間に1度であればより「思い出す」という時間が必要になります。

タスクの分担ができない

これは実際にあった話です。
「組織に含まれる社員の一覧を見れるようにしてほしい」
という要件に対してチケットを切った結果下記のようになりました。

• フロントエンドの実装
• バックエンドの実装
• フロントエンドのレビュー
• バックエンドのレビュー
• テスト

またこの時実際私たちの中で起きたやりとりも見てみましょう。

A「自分は手が空いているんですが手伝えることありますか？」
B「フロントエンドの実装は私が担当しているのですが、キリが悪いのでそのまま進めます、大丈夫です」
C「バックエンドの実装は僕が担当しています。もう少しで終わりそうです、大丈夫です」
A「わかりました！では何かあったら声かけてください、レビューとかでお手伝いできるはずです、今は他のタスクを取ります」

翌日
A「明日スプリントレビューがあるけどみなさんチケット終われそうですか？」
B「フロントエンドの実装、動かないところがあって時間がかかっています、APIもまだできていないようなので終わりません」
C「バックエンドの実装は昨日他の対応が入ってしまったので進んでいません、今日やります」
A「他の方も手が空いて来たので分担できませんか？」
B & C 「大丈夫です、タスクを分けられないので今日中に終わらせるのでこのままやります」

翌々日
B & C「ごめんなさい、終わりませんでした」

どうでしょうか？なんとなく心当たりある人もいるのではないでしょうか？
動かないチケット、終わらない開発、伸びるリリース日・・・
もしこのチケットが終わってもレビューは終わってないし、テストも終わってない、どっちにしろ終わりません。

例えばこの状況で翌日にBさんが体調不良で休んだらどうなるでしょうか？
この時点でレビューも出ていなければ作業進捗もよく分からない状況です。
仮にリモートに資材がpushされていてもどこまで終わっているかからキャッチアップが必要です。

チケット自体で何をやるかが分からなくなる

これはコンテキストスイッチと近いのですが、チケット単位で何をやるかが分からなくなる時があります。
そんなことある？と思うでしょう。あるんですよ。

実装というチケットが意味していることが分からなくなることがあります。
あれ？実装ってどんなことやれば良かったんだっけ？といった具合です。
スクラムではリファインメントやプラニングを行いますが、それでも時間が経てば忘れてしまいます。
実装という大きなものとに対して何をしたらいいのか、どう向き合えばいいのか忘れてしまっては進まなくなります。
タスクが進められないということは生産性は落ちます。

チケットを小さくするためのアクション

それでは解決するためにはどうすればいいのでしょうか？

誰かが作ったチケットを評価し合う

まずはチケットをみんなで切るのもいいですが、それぞれ自分の思い通りに作ってみましょう。
そしてそのチケットを評価してみましょう。

タスクボードに並んだチケットを見てください。

「何をするか明確になっているか」

これが分かればOKです。
分からないのであれば小さくチケットを作らなければいけませんね。

作成者が分かればいいのではなく、その場にいる全員が何をしたらいいか分かる状態がチケットを小さくするための鍵になります。

私たちのチームではタスク管理でJIRAを使っていますが、タスクを作成する際はいきなりJIRAに作るのではなくまずFigjamに落とし込みます。
Figjamに作ったチケットを共有して「こんなことをやります」を宣言するようにしています。
そうすると自然と「他の人がみて理解できるチケット」が出来上がります。
なぜならその場で共有して説明しなければいけませんからね、誰が見ても分かるようになっていた方が都合がいいわけです。

またこうすることで「あれ？その作業の前にこれやらなきゃいけないんじゃない？」といったタスクの抜け漏れチェックにも役立っています。
もちろんですが「これなんか思ったよりやること多いからスコープ調整した方いいね」といったやりとりもここでできます。
大きいチケットだとチケット数が少ないのでここまで議論できません。

作ったチケットを評価し合う環境というのが一番効果があったと思います。

〇〇を××するといったやることベースでチケットの名前をつける

チケットの名前はやることにしてみましょう。
最初に記載した弊社の生産性の高いメンバーとそうではないメンバーの差はここにありました。

例えばユーザーの登録画面を作ってほしいという要件があります。

• APIの実装
• 画面の実装

こんなチケットではAPIの実装中に割り込みが入れば忘れてしまいます。
APIの実装というチケットだとAPIができあがるまできっとレビュー依頼はやってきません。
テストもできません。

• 各フォーム要素をマークアップする
• 各フォームの値に対してバリデーションを追加する
• フォームの値をAPIにPOSTする
• POSTの結果を元にユーザーへフィードバックを送信する
• POSTのリクエストを受け取るコントローラーを追加する
• フロントエンドのリクエストに対して一時的に成功のモックをレスポンスさせる
• リクエストされたデータをユーザーテーブルへ登録する
• ユーザーテーブルの登録結果をレスポンスとして返却する
• エラーがあった際にエラーを返す
• モックを削除する

チケットの名前にはやることを明確にして記載しましょう。
APIの実装だとどこまでやったか分からなくなりますが、これならどこまで終わっていてどこが終わっていないか明確になりますよね。
さらにこの粒度でタスクがあるなら作業も分担しやすいでしょう。

A「自分は手が空いているんですが手伝えることありますか？」
B「本日の午後MTGで埋まっていてなかなか手をつけられないのでAPIリクエストの部分をお願いできるでしょうか？」
A「了解！APIの実装でも困ったことがあったら言ってね！」
C「ありがとう！今の所大丈夫だから何かあれば声かけるね」
B「Aさんありがとう、助かったよ」

こんな感じでデイリーの中でタスクのアサインを簡単に見直せるでしょう。

他にも副産物はあります。

タスクレベルでクリティカルパスも明確になります。
フロントエンド的にはどこに向けてリクエストするか、どんなレスポンスが返ってくるかのインターフェイスが動けばより快適に実装が進みます。

さらにプルリクエストはこのタスクレベルで投げるとレビューがすぐに終わります。
1度のプルリクエストは1つの観点に絞るべきです。
また小さくあればあるほど読み手は楽にコードをレビューすることができます。
1000行の修正をボンと出しても根本的に間違えているというコメントがあれば全て作り直しです。
小さく作ることで手戻りの影響を減らし小さな影響範囲の修正で済みます。

チケットを見ればやることが明確です。
それにより色々なメリットを享受できるようになるのです。

チケットの粒度の時間を決めてしまう

これはチケットのサイズを絶対的な時間で縛ってしまうやり方です。

スクラムではプロダクトバックログアイテムはストーリーポイント相対見積もりを行うのが一般的だと思います。
それに対してスプリントバックログアイテムは想定見積もりである必要がありません。
なぜならそのスプリントで行う作業レベルのチケットであるからです。

プロダクトバックログアイテムはその複雑度を相対的に見積もる手法です。
その複雑なものに対して実作業レベルのチケットを作っていくわけですから作業者の絶対時間で何も問題ないわけです。

弊社では1チケット1ポモドーロ（25分）を目安に作りましょうとしていました。

残念ながらこの1ポモドーロ基準は全然受け入れられなかったのですが・・・笑

とはいえ実際に1ポモドーロ単位で作っていた時はかなり細かくチケットが切れていました。
1ポモドーロとする弱点は、作業者が自身がどのくらい作業できるか理解していないとできないこと
人によっては手を動かした方が早いと考えてしまうこと、またかなり細かいチケットなので終わらなってないことが明確に分かってしまいストレスになるといったことが挙げられます。
あまりに小さすぎて受け入れが難しかったというのもあるのでもう少し緩和して1時間くらいを目安にすると良いかもしれません。
1日、半日レベルだとうまくいかない時に手遅れになるので、せめて2時間程度を目安にするといいでしょう。

何度でも失敗してみて経験し振り返りをする

極論ではありますが経験してみるのが一番早いです笑

大きなタスクはどんどん作っていきましょう。
だって考えるのは手を動かしながらだっていいからね。
別にプランニングに時間をかける必要だってないよね。

それで正解したらそれがそのチームの正解です！
ここまで読んでもらって恐縮ですが是非このままいいチームでいてください！

でもうまくいかないチームはなんでうまくいかなかったか、現実を見つめ直してみましょう。
「このタスク、2日動かなかったけどなんでだっけ？」
「誰かが休んじゃうと開発が止まっちゃうね・・・」
現実を見るということはできていないことを突きつけられるのですがそこにこそ答えがあります。

もっとよくしたいと思ったそこのあなたは是非この記事を参考にしてみてください。