はじめに
DIGGLEエンジニアのaki0344です。
DIGGLEでは数年間、スクラムマスターを開発業務と兼任、輪番制で行っていました。
兼任、輪番制によるメリットは大きかったのですが、開発者の増加、開発速度の加速などによりデメリットも目立つようになってきました。
そこで今回、専任スクラムマスターを一定期間固定で配置し、デメリットに対する改善を試みることになりました。
今回は専任スクラムマスターとして業務を開始した筆者がタスク整理をしてみて見えてきた、今までのタスク管理の問題点と、それを解決するために行った施策について書いてみたいと思います。
結論
忙しい方のために、最初に結論を書いておきます。
チームのタスク管理を行う上でもっとも重要なのはこちらです。
「なぜやるのか(Why)」を書く
これに尽きます。
ではなぜこの考えに至ったのかを書いていきたいと思います。
タスクはいつ生まれるのか？
みなさんのプロダクトではどんな時にタスクが作成されますか？
DIGGLEでは以下のような時にタスクが作成されます。
- ユーザーストーリーを消化するとき
- 障害を検知したとき
- 時間のかかる処理を検知したとき
- 開発中に改善できる実装箇所を発見したとき
- 問い合わせなどにより問題が発見されたとき
改めて並べてみると、色々なパターンがあることがわかります。
タスクは誰が作るのか？
DIGGLEでは、タスクはDEVチームのメンバー(エンジニア)が作成します。
前述した契機で、各メンバーが必要だと思ったタスクを作成しています。
タスクは誰が整理するのか？
これはチームによって結構差がありそうです。
プロダクトオーナーを立てたり、プロジェクトマネージャーがやっているところもあるかと思います。
DIGGLEでは主にDEVチームのメンバーが行っており、整理の仕方は大きく分けて以下の3つが存在します。
タスクを作成したメンバーが決める
緊急性の高いものや、サクッと片づけられそうなものは作成者が次の作業として積むことがあります。
DEVチームで合議のうえ決める
2週間に1回、チーム全員で集まって新規タスクを整理する時間を設けています。
担当者、いつやるかが決まっていない新規タスクを今やるのか、後回しにするかを決めています。
作成から一定期間経過したタスクを棚卸する
四半期に1回、チーム全員で集まって後回しにしたタスクを整理します。
時間が経過してやる意義の薄れたタスクはクローズしたり、逆に需要が増してきたタスクは次にやる作業として積んでいきます。
見えてきた課題
今までは前述のような仕組みで管理されてきたタスクですが、エンジニアが増えたことで以下のような課題が出てきました。
積みあがっていくタスクたち
人が増えると視点も増えます。
プロダクトは1つでも、それに関わる人それぞれが異なる視点で課題を見出し、改善系のタスクが作成される頻度が増えました。
また、開発速度が上がりDIGGLEの機能は以前よりも速いスピードで増えています。
既存機能の規模拡大に伴い、改善すべき項目も増えていきます。
その結果、タスクの作成頻度が消化頻度を上回り、未消化のタスクが増え続ける状態になってきました。
何のためのタスクか覚えていない
優先度が低く後回しにされたタスクは四半期に1回整理されますが、時間が経過しているため記憶から薄れていることも珍しくありません。
タスクには「何をやるか」は記載されていますが、なぜそれをやるのか、やることでどんな効果があるのかは記載されていないことが大半です。
「タスク作ったときに話した記憶はあるんだけど、何でしたっけ……？」という会話が増えました。
何を優先すればいいか共有ができない
ここで本記事の本題です。
「なぜそれをやるのか」が書かれていないと、「このタスクからやらないといけないよね」という合意がチームで取れなくなります。
やることは山のようにずらずらと並んでおり、各メンバーは「これは先にやっておきたいなあ」ぐらいの意識を持っていますが、他のメンバーにはそれが見えず、各々が会話しながら頭の中で整理を行うことになるため、「チームとしてこれを優先してやっていきましょう」という状態まで持ってくのが非常に難しくなります。
さらに、以前はそれほど重要ではなかったタスクが時間の経過とともに優先してやるべきものに変わることがありますが、後回しにされた膨大なタスクの中に埋もれて忘れ去られてしまうことがあります。
「なぜやるのか」が書かれていればこのようなタスクも今やるべきかの判断が可能ですが、「何をやるか」だけでは今やるべきと気付かれずに見落とされる可能性が高くなります。
実施した対策と効果
これらの見えてきた課題に対してどのような対策を行うのか。
視覚的にわかりやすいもの、さらに継続的に行えるよう、シンプルな方法を選びました。
それがこちらです。
ユーザーストーリーを作る
とにかくユーザーストーリーを作りまくりました。
今まで個別に並んでいただけのタスクに対してユーザーストーリーを作成し、「なぜやるのか」を明確にします。
そして、すべてのタスクが必ずユーザーストーリーに紐づくようにしました。
DIGGLEではタスク管理にJiraを利用していますが、一覧にユーザーストーリーとそれに紐づくタスクが順番に並ぶように整理しました。
ちなみに、タスクに「なぜやるのか」を書かずにユーザーストーリーを作った理由は、タスクは「なぜやるのか」を書かなくても成立してしまう性質のものだからです。
「なぜやるのか」を書き忘れてしまっても、「なにをやるか」が書かれていればタスクは消化できてしまいます。
そのため、タスクに「なぜやるのか」を書くようにルールを決めた場合、それがちゃんと書かれているのか監視する役が必要になります。
いっぽうで、ユーザーストーリーは「なぜやるのか」を書くためのものであるので、「なぜやるのか」が書かれていないユーザーストーリーというのは成立しません。
そのため、監視の目は必要なく、管理コストを抑えることが出来ます。
また、Jiraではユーザーストーリーとタスクが一目で区別できるようになっているため、ユーザーストーリー(=なぜやるのか)のみを比較することが容易になります。
そのため、タスクに「なぜやるのか」の記載を追加するのではなく、ユーザーストーリーを作るという方法を選択しています。
生まれた変化
対策の結果、以下のような効果が生まれました。
やらなければいけないタスクを共有できるようになった
「なぜやるのか」が明文化されることで、チーム内で「これは最優先で対処しないといけないよね」という合意を取ることが簡単になりました。
チームで何からやるかを明確にできた
今まではチーム内で合意を取るのが難しく、その工程を省略することも多々あったため各自が優先すべきと考えているタスクを順に処理することになりがちでした。
今は前述の通り優先的に対処すべきことがチーム内で合意を取れるようになったことで、チームとして最優先のタスクから消化するという体制ができました。
やりたいユーザーストーリーを話し合う場が生まれた
DIGGLEでは開発にスクラムを採用しています。
2週間を1スプリントとし、最初にその中で消化するタスクを決めてから作業を始めます。
対処必須のユーザーストーリーをスプリント内で消化すると決めた後に、まだ余裕があればタスクを追加します。
この追加するタスクについて、今までは最初にそれっぽいことを言った人の案が採用されるようなケースがありましたが、残っているタスクにも「なぜやるのか」が書かれており比較できるようになったため、どれを先にやるべきかチームで議論する場が生まれました。
今後の課題
直近の作業については優先度をチーム内で確認して消化することができるようになりました。
一方で、過去に作成され優先度が低いと判断されたタスクはまだ整理ができておらず、眠ったままの状態になっています。
これらのタスクについてはもう一度対応の要否を判断したうえで、ユーザーストーリーを作成して優先順位を決めた状態に整理したいと考えています。
新たに追加されたタスクと併せて常に最新の優先度を保ち、プロダクトにとってもっとも影響の大きなタスクを消化していけるような状態にするのが当面の目標です。
おまけ
ユーザーストーリーはそのままタスクとして消化していいの？
ダメです。
DIGGLEが利用しているJiraはユーザーストーリーもタスクも見た目は違いますが、情報を持たせる「箱」であることは変わりません。
そのため、ユーザーストーリーにステータス(未着手/対応中/レビュー中/完了)を持たせて、タスクとして消化することは可能です。
でもダメです。
なぜなら、ユーザーストーリーに対する作業量は変化するからです。
一度実装を行っても、「やっぱりこっちのほうがいいよね」ということが往々にして起こります。場合によっては1つのユーザーストーリーで2度、3度と起こります。
そのため、もしタスクとして利用してしまうと、「対応中」の状態から動かずに居座り続けるタスクが存在する状態になります。
そしてそのタスクは、作業量が膨らんでいることが見えず、どんな作業が残っているのか見えなくなります。
ユーザーストーリーはどんなに小さなものでもタスクを作りましょう。 作業が増えたときは新しいタスクを作りましょう。
終わりに
DIGGLEではともにプロダクトを開発してくれるエンジニアを大募集中です。
少しでも興味があれば、ぜひ下記採用サイトからエントリーください。
カジュアル面談も実施しているので、気軽なお気持ちでご応募いただければと思います！
