開発のプラクティスとして大きいタスクを小さく分割するというのがある。しかしよく考えると何が嬉しいかを的確に説明するのが難しいプラクティスだと思う。現在進行形でチームに広めようとしてうまく言葉が出なくて困っている。なぜ俺たちはタスクを分割するのか、思いつくポイントを整理して思考をクリアにしようと思う。
ポイント1: 見積もりのため
大きなタスクについて開発にかかる時間を見積もる必要があるのなら、タスク分割の必要性は明らかだと思う。大きいタスクを大きいまま見積もるのは難しい。外れやすくなるし、3倍とか4倍とか外れる度合いも大きくなりうる。そういう場合に、予測をつけやすい手頃なサイズに分割してそれぞれを見積もるというのは圧倒的に正しい。ぜひやるべきだ。見積もりされたタスク一覧があると、進捗を可視化することもできる。
ポイント2: 実装方針を間違いすぎないため
仕様が大きく実装方針が明らかでない時も、タスク分割は有効だと思う。複雑なものを複雑なまま考えるのは難しい。大量にコードを書いていって、最後の最後に破綻していると分かるということが起こりうる。これは大変ダメージが大きい。できることなら小さく失敗したい。まず全体を捉えて、そのあと小さく分割して、それぞれを簡単な問題にして解いていく方が賢明だと思う。もちろん、その分割に時間がかかりすぎても困るが、基本的にはそのタスクの複雑さにいつ対処するかというだけの違いで、かかる時間は大して変わらないと信じたい。その分割の過程でコードを書いてはならんという法もないので、3割くらいの力で適当なコードを書いてみても良い。
ポイント3: レビュワーの負担を減らすため
大きいpull requestをレビューするのは大変だ。大きいタスクを自分で実装するよりも大変に感じることすらあるかもしれない。タスク分割をしないと、大きいタスクに対応して大きいpull requestを作ってしまいがちだと思う。タスク分割という形でマージ可能なサブセットを事前に抽出しておくと、それをガイドラインにしてレビュワーの負担を軽減できる可能性がある。コミットを綺麗にするので大丈夫という声が聞こえてきそうだが、コミットを綺麗にする重要性が理解されているなら、それをpull requestやタスクという単位に応用するだけのことだ。タスク全体での整合性を見落としやすくなるので、その点は事前の設計レビューなどで補う必要がある。
ポイント4: 手分けをするため
ホールケーキをみんなでつつくようなやり方はソフトウェア開発では難しい。大きなタスクを手分けして進めるためには分割するしかない。タスク分割を上手に行うと、個人の負担を減らし、フィーチャーがリリースされるまでの時間を短縮できる可能性がある。ただ、文脈を共有したり分担できるほど設計を練るのはコストがかかるので、あくまでバランスという程度のポイントではある。
ポイント5: 自分のモチベーションのため
大きな仕事をモチベーションを維持してやり遂げるのは大変だ。僕なんかは、3日もpull requestを出せないでいると、何もできていない気がしてどんどんやる気が下がる。1日1個おわるくらいのタスクに分割しておいて、毎日確実に終わっていくというのは精神衛生上かなり良いと思う。一度書き始めたコードをずっと書いてしまうとこういう区切りをつけるのが難しくなるので、どこかでタスク分割フェーズと実装フェーズを明確に分けるのは良いプラクティスじゃないかと思う。最終的に生産性を高める可能性はある。
今のところ思いつくポイントはこのくらいだ。ひとくちにタスク分割といっても、そのメリットが多様であるということが一覧されて、思考が少しクリアになった。それぞれでメリットを享受する人が異なるというのもわかった。また、一覧してみるとMUSTでやるべきと思うのはポイント1と場合によってはポイント4くらいで、他は加点項目という印象がある。このあたりがスパッと説明できなかった要因かもしれない。
実際にやっていくことを考えると、タスク分割の丁寧さにも段階があって、誰が見ても着手できる説明をつけてチケットを切る松プランから、箇条書きでチェックリストを作る梅プランまである。どんなメリットを享受したいかに合わせてやり方を検討すると良い。
