溢れるチケットを上手いこと整理整頓してプランニングをスッキリさせた話
こんにちは、サファイアです。ナビタイムジャパンで地点検索システムの研究開発を担当しています。
みなさん、アプリなどを開いた時に検索窓に出発地や目的地などの情報を入れますよね。検索窓に入ってきた文字列からユーザーが期待する結果を返す処理を、ナビタイムジャパンでは「全文検索エンジン」を用いて実現しています。
私はその全文検索エンジンを用途に合わせて活用するチームに所属しています（また、社内のアジャイル推進チームにも所属しています）。本日は私がその全文検索エンジンを活用するチームで行ったカイゼン活動についてお話しします。
今回のお話
今日お話しするのは、そのチームでのタスク管理についてです。タスクが溢れかえって困っている人は読むと参考になるかもしれません。
背景：管理するプロダクトが多いチーム
前提となる状況：全文検索エンジンが、たくさんある！
現状、チームでは全文検索エンジン「Solr」を、検索される対象ごとに持っています。検索される対象の例には、「駅やバス停など」「POI（地点）」「カテゴリ」などがあります。
各Solr別にはそれぞれ異なる目的で使用されがちなため、改修案件が各Solrごとにバラバラに降ってきがちだという傾向性がありました。
結果：捌くべき案件が慢性的に多い
それぞれのSolrに関してバラバラに案件が降ってくるわけですが、どのSolrに対しても案件が尽きることがないため、チーム全体で捌くことになる案件の数が慢性的に多くなっており、ビジネスサイドからの要望に応えるだけで精一杯になりがちになることもしばしばでした。
今回の問題意識：大量のタスクからチームの作業計画を能率的に作成したい！
こうした状況下では「大量に発生する案件を捌きつつ、内部改善と研究開発をいかにして進めていくか？」という問題が生まれます。
今回の記事ではその問題の解消に資するべく「案件・内部改善・研究開発としてあらわれる大量のタスクをどのような基準で能率的にチームの作業計画へと組み込んでいくか？」という課題を解決した方法について、お話しします。
課題：無限に縦に伸びるカンバン
はじまり：miro上でのタスク管理
私がチームにジョインした時、チームは開発全体のフレームワークとしてスクラムを採用していました。スクラムについてのわかりやすい解説は「いちばんやさしいアジャイル開発の教本」をご参照ください。
そして、スクラムでのタスク管理に使うチケットの管理は、miro上に置いたカンバンを用いて行っていました。miroとは何かについては「チームのためのビジュアルコラボレーションボード - Miro」をご参照ください。
カンバンでは、列を以下のような粒度で分けていました。
・スプリントにまだ載せないタスク
・スプリント内
・実施前タスク
・実施中タスク
・待機中タスク
・完了済タスク
起こったこと：縦に伸びまくるカンバン
すると、何が起こったでしょうか。カンバンの中で「スプリントにまだ載せないタスク」を置く列が際限なく縦に長く伸びていったのです。
そこでチームは「スプリントにまだ載せないタスク」を下記の2つに分割しましたが、すぐにどちらの列も縦に伸びまくることになってしまいました。
・着手可能になっていないタスク
・可能な順にスプリントに載せるタスク
ちなみに、縦に並べるタスクは、優先度が高いものから順に上におくようにしていたのですが、「優先度」の定義が言語化できていなかったため、タスクの優先度を判定する議論は毎回長引いてしまっていました。
結果：しんどいプランニング
その結果、その頃のチームではプランニングが「縦に伸びまくったカンバンを前に延々と優先度について議論をし続けるしんどい場」になってしまっていました。あまりにしんどいので「うちのチームにスクラムは合わないのでは」という声も度々上がっていました。
なお、この頃、プランニングには合計3時間くらいかかっていました。
改善施策１：重要度-緊急度マトリクスを配置
状況に対する分析：優先度を分解する
この自体を解決すべく、私はまず「優先度」は下記の3つの要素に分解できるはずだと考えました。
1つ目が「（チームが持つプロダクトの中でタスクが発揮する）重要度」です。これは、チームが提供「できる」価値の最大化に資するか否かによって測られます。いわば、「可能な価値」の観点から見たタスクだとも言えるでしょう。
もう1つが「（チームが置かれたビジネス状況が要求する）緊急度」です。こちらは、チームが価値を提供「する」タイミングを逃さないか否かによって測られます。これは「現実の価値」の観点から見たタスクだとも言えるでしょう。
つまり、この2つの軸のマトリクスに並べるべきものを無理に一列の「優先度」順に並べようとしていたことが、「優先度」の定義が言語化困難なままの長くてしんどい議論を生んでいたのではないか、と考えたわけです。
施策：重要度-緊急度マトリクス
そこで、私は「可能な順にスプリントに載せるタスク」と「実施前タスク」の間に「重要度-緊急度マトリクス」を挿入し、「可能な順にスプリントに載せるタスク」にあるタスクを順次「重要度-緊急度マトリクス」に移して、「可能な順にスプリントに載せるタスク」を廃止する方向でタスクの整理を進めました。
結果：不透明な「優先度」からの解放
これにより、チームから優先度をめぐって延々と議論することが減り、タスクも一望しやすくなりました。
それだけでなく、優先度だけでは見えないタスクの扱い方の違いも可視化できるようになりました。例えば、「緊急度が高いタスク」は可能な限り早く取り組む一方で、「緊急度が低〜中くらいだが重要度の高いタスク」は後進の教育用に使うといったように、です。
その後：再び溢れるタスク
しかし、その後しばらくすると今度は「重要度-緊急度マトリクス」が溢れだしました。溢れたタスクは重要度や緊急度が低い順に「ネタ帳」という新設した場所に押し出される形で落ちていきました。
こうした満員電車状態の「重要度-緊急度マトリクス」を見ながらタスクの着手順位を検討するのでは、最終的に「ネタ帳」送りになるタスクまで（視界に入ってしまう以上）繰り返し検討の対象とすることになってしまい、後から考えれば無駄にみえる議論も発生することで、プランニングの能率向上は壁にぶつかるようになりました。
この頃、プランニングには合計２時間くらいかかっていました。
改善施策２：複雑度-必要性マトリクスを配置
状況に対する分析：やる／やらないの判断をしよう
そこで、再びどこをカイゼンすればより能率的なプランニングができるのかを考えることとしました。
そもそもタスクが積まれるスピードと着手可能になるスピードが、チームのタスク消化速度に比べて大きい限り、全てのタスクを完了させることはできません。
そのような状況下で発生したタスクをそのまま「着手可能になっていないタスク」や「重要度-緊急度マトリクス」に入れるのは、全てのタスクに対して暗黙的に「やる」という判断を下していることと同じだと気付きました（「ネタ帳」送りは、後になってから受動的に「できないので置いておきます」という判断に追い込まれているだけ）。
確かにほとんどのタスクは「できた方が嬉しい」ものではありますが、全てのタスクを消化することができない以上、本来ならば（受動的に完了を諦めるのに先んじて）「やる／やらない」の能動的な仕分け判断が必要なはずです。もちろん、チームのタスク消化速度を上げるという解決策も積極的に実施されるべきですが、「やる／やらない」の判断はそれとは独立に実施可能であり、かつそれを実施する意義があると言えるでしょう。
そうした「やる／やらない」の判断を挟むことができれば、チームが抱えるタスクの全体像がシンプルになってメンバーに対する知的負荷の軽減になるとも予想できます。
施策：複雑度-必要性マトリクス
このような分析を踏まえ、私は「複雑度-必要性マトリクス」というものを考案し、それを「着手可能になっていないタスク」や「重要度-緊急度マトリクス」の前に配置することにしました。
「複雑度-必要性マトリクス」は下記の
から構成されます。タスクの必要性をOKRを用いて検討するのは、OKRはチームとプロダクトがどうあるべきかという「チームのwhy」に対する答えを簡潔に定義したものだからです。OKRとスクラムの双方向的な組み合わせについては「OKR-based scrum」をご参照ください。
・（タスクそれ自体の）複雑度
・（OKRの観点から見た）必要性
このうち、まず「複雑度」は、以下の３段階に分かれます。
低：1スプリントの個人作業で完了可能
中：1スプリントの個人作業で、1スプリントで完了可能な複数個のタスクに分割可能
高：複雑すぎて1スプリントの個人作業では見通しも立たない
続いて「必要性」は、以下の３段階に分かれます。
高：今年度のOKR達成のために必要
中：次年度以降のOKR達成に必要な可能性が高い
低：次年度以降もOKR達成には関わらない可能性が高い
この二軸から構成される複雑度-必要性マトリクスは以下のようになります。
各領域ごとにタスクの扱いは以下の通りです。
複雑度低x必要性高（※１）：やる。「着手可能になっていないタスク」か「重要度-緊急度マトリクス」に送る。
複雑度中x必要性高（※２）：元のタスクを複数個の複雑度低のタスクに分解する作業を「複雑度低x必要性高」のタスクとして切り出す。
複雑度高x必要性高（※３）：タスクの分解に必要そうな人員を集めてタスクの分解に取り組む時間を確保し、そこでタスクを分割する。できない場合は時間を定期的に確保しながら根気強くモブプロ的に取り組んでいく。
複雑度低x必要性中（※４）：やることを明確にして、忘れないようにマトリクス外の専用スペースにストックしておく。
複雑度中x必要性中（※５）：年に一回くらいの「自由研究」スプリントで取り組むかもしれないアイデアとしてマトリクス外の専用スペースにストックしておく。
複雑度高x必要性中（※６）：「簡単に実現できるようになる条件が整う」か「やらないといけない抜き差しならない状況」になるまでアイデアとしてマトリクス外の専用スペースにストックしておく。
必要性低（※７）：思い切ってマトリクス外の「ネタ帳」に送る。
なお、必要性の検討の際には、タスクを発行する際のテンプレートの先頭に下記のような「問題意識」欄を追加して、そこであえて「放っておくとどうなるのか」を言語化させることで、「やらない」と判断した場合のリスクを他のタスクと比較できるようにしておきました。
## 問題意識
・誰が？
・どう困ってる？
・放っておくとどうなる？
## 課題設定
・何を？
・いつまでに？
・どうする？
## DoD
・どういう入力をして
・どういう出力が出るようになったら終わり?
## 作業の段取り
・まず何をやる？
・次に何をやる？
・最後に何をやる？
この「複雑度-必要性マトリクス」の基準に沿って、「着手可能になっていないタスク」と「重要度-緊急度マトリクス」に載っているタスクも扱いを再検討し、整理＆断捨離を実行しました。
OKRについての補足
ところで、結果の紹介に入る前に複雑度-必要性マトリクスで参照するOKRについての補足なのですが、OKRではチームがやるべき仕事を幅広く網羅できるように定義しておくようにします。明示的にOやKRに掲げていなくても、OやKRを達成する際に実施が必要になるタスクとして、チームが実施すべきタスクがOKRに包含されるようにしておく、ということです。なお、OKRとチームがやるべき仕事とを無理なく組み合わせる方法については「OKRはツリーではない」をご参照ください。
そのようにOKRを組むと、連携して動く他チームからの依頼に対応していくことや、内部改善を進めていくことも（暗黙的にであれ）OKRに組み込まれることになるので、それらに該当するタスクも原則的に「必要性：高」として扱うことになります。内部改善がチームが提供できる価値に及ぼす影響については「質とスピード」をご参照ください。
結果：ようこそ、スッキリしたプランニングへ
この複雑度-必要性マトリクスの導入により、無事「着手可能になっていないタスク」と「重要度-緊急度マトリクス」をスッキリさせることができました。導入から二ヶ月ほど経ちますが、そのままタスクをスッキリさせた状態を維持できています（乱雑になる気配もありません）。
これで、プランニングが１時間３０分程度で終わるようになりました。
しかも、無駄な議論を省くことができたので、慎重に方針を考えるべきタスクについてはむしろゆっくりと時間を取ることができるようになり、加えてプランニングの疲労感が軽減できたことで、スクラムイベント後にタスクに着手する余力が残せるようにもなりました。
まとめ
改善施策１：重要度-緊急度マトリクス
タスクの優先度を重要度と緊急度に分割したことで、タスクを誰がどうやるべきかについての判断が下しやすくなりました。
改善施策２：複雑度-必要性マトリクス
「チームとプロダクトがどうあるべきか」という「チームのwhy」に対する答えとしてのOKRに基づいてタスクの「やる／やらない」を判断してプランニングを進めることで、能動的にタスクを取捨選択できるようになり、やると決めたタスクについて考える時間と労力を増やすこともできました。
さいごに
こうして、私のチームでは軽快なプランニングで軽快にバリューを最大化していくことができるようになりました。溢れるタスクに困っておられる方は、ぜひ参考にしてみてください。