この記事はJohanna Rothmanによるゲスト投稿です。

チームが膨大なバグのリストやバックログ、さまざまなタスクのリストを抱えていることはよくあります。それは本当に意味があるのでしょうか？この記事では、どれくらいのデータを手元におくべきか、タスクをどうやって整理するかについて、いくつかのガイドラインを示します。

ポーラはアジャイルへの転換に取り組んでいる最中の会社で、新任のテストマネージャーとして働き始めて1か月がたったところです。テスター全員と顔合わせを済ませ、定期的に1対1のミーティングを行うことにしました。また、毎週、チームの全員が学習の機会を持てるよう、同僚と協力してプラクティスのコミュニティを立ち上げました。

それから頭を悩ませることになったのが、バグや膨大なバックログをどうするかという問題です。彼女には、チームやプロダクトオーナーたちが、必要になるかもしれないから念のためといって情報を溜め込んでいるように思えたのです。

会社がアジャイルアプローチを採用し始めたとき、いつかやるべきことのリストを管理する方法は変更されませんでした。依然として同じバグ管理システムを使い、同じロードマッピングツールを使い、同じプロジェクトポートフォリオツールを使っていました。

ツールが問題なのではありません。ツールの使い方が大きな問題を生んでいたのです。組織の方針として、彼らはかなり先のことまで詳細に計画を立てていました。何一つ絶対に削除せず、よいアイデアを見失うことがないようにと考えていました。

もっと多くのアイテムを追加するのではなく、アイテムを削除することで、計画の方法を変えるべき時が来ていました。

削除して明快にする

アジャイルへの転換の過程では、手順を削除することが必要になるケースが多々あります。たいていの場合、振り返りでチームのプロセスを明らかにし、変更します。

プロセスの手順を削除する必要については、多くのチームや組織が認識しています。しかし、データを削除することは忘れられがちです。

ポーラは、チーム（プロダクトオーナーも含む）がバグ管理システムに登録された多数のバグを確認し、優先順位をつけなおす必要があると判断しました。製品の1つは、10周年を迎えたところでした。その製品は、何千ものアクティブとされているバグがバグ管理システムに登録されていました。

ポーラは各チームにある試みを提案しました。バグデータを全部バックアップ版のデータベースにコピーし、現行のバグ管理システムにはまったくバグが存在しない状態で再出発してみたらどうか？問題が見つかったら、問題をバグ管理システムに追加する、そうできないだろうか？

当初、ほとんどのプロダクトオーナーの答えは「だめです！」でした。プロダクトオーナーたちは、発見された問題が修正されなくなることを懸念しました。

ポーラは以下の代替案を提案しました。

• 既知の問題が再発見されたとき、バグ管理システムに追加する。そうすれば、本当に問題があるのだということが皆に再度周知される。
• 過去2・3か月オープンしたままの問題を抽出し、新しいバグ管理システムに入れる。問題を修正する計画を立てる。
• 最長で1時間だけ使って、現行のバグ管理システムから最も影響度の高い問題を選択し、新しくクリーンアップされたツールに追加する。

ポーラは常に問題について考えていなければならないことからくる認知負荷について説明しました。また、何を修正し、何を後回しにするか、プロダクトオーナーに難しい判断が求められるという現状についても説明しました。

考慮すべきアイテムが少なければ、問題が発見されたとき、すぐに問題を修正する方法を検討できるでしょう。問題の修正が先延ばしされることはないでしょう。

先延ばしがないということは、最初はゆっくりかもしれませんが、時間をかけて製品が改善されるということを意味します。問題が発見されたら修正することで、製品は良くなっていきます。

各チームは、それならうまくいく可能性があると判断しました。すると、あるプロダクトオーナーが次のように質問しました。「わたしはまだバックログには入らないアイデアを追加するのにバグ管理システムを使っています。また、ロードマップも使っています。よいアイデアを見失わないようにするには、どうすればよいでしょうか？」

プロダクトオーナーのジレンマについては、ポーラも理解しました。ポーラは、よいアイデア用にはロードマップまたはマインドマップだけを使い、バグ管理システムは使わないよう提案しました。そうすれば、バグ管理システムは何でもほうりこむ所ではなくなります。バグ管理システムはバグだけを追跡します。

それに、すばらしいアイデアなら何回も繰り返し出てくるものです。

よいアイデアは何回も出てくる

問題が発生したらすぐに修正することで、バグ管理システムをきれいな状態にしておいたとしても、また別の問題は避けられません。顧客が製品を気に入ってよく利用してくれるなら、リクエストが出てくるでしょう。リクエストをどこに登録しますか？

何らかの形式で「検討対象」リストまたはデータベースに保存することをお勧めします。リクエストに関して統計データなどのデータを収集したい場合は、データベースが必要でしょう。スプレッドシートで事足りる場合もあるでしょう。わたしはリストを好んで使っていますが、リクエストの日付を記録しておくのもいいかもしれません。

製品に関するすべてを入れる場所としてバグ管理システムを使わないでください。

わたしがリストを使う理由は、後で列を足して、他のユーザーから同じフィーチャーをリクエストされた回数を書き込むことができるからです。同僚の中には、重ねてリクエストされた日付も追加するという人もいます。

わたしはこのリストを使って、リクエストがまだ妥当かどうか、わたしたちが目指す製品の方向に沿っているかを確認します。

製品のユーザーが増えるほど、よいアイデアは繰り返し出てきます。選択肢はいろいろあるでしょう。既存の製品に加えて別の製品または補助的な製品を提供することも考えられます。

リクエストをトラッキングするとき、製品に対して問題をトラッキングしているときとは異なる視点を持つことになります。製品が向かうべき場所がわかり、ロードマップを作成する助けになります。さらに、どの問題が目的地への妨げになるかがわかり、より緊急性の高いバックログアイテムを選択するのに役立ちます。

長期的な計画と短期的な計画を分けることができます。

認知負荷を減らす「パーキングロット」

ポーラはまだ準備ができていないアイデアのための「パーキングロット（駐車場）」を提案しました。この「パーキングロット」は、バグ管理システムのバックアップデータベースコピーのようなものです。プロダクトオーナーは何でもパーキングロットに追加できます。そのあとは、パーキングロットについて始終考える必要はありません。

新しい作業に取り組む時間ができたら、プロダクトオーナーはパーキングロットをレビューして、パーキングロットを出る準備が整ったものがないか確認できます。

パーキングロットは長期的な計画と短期的な計画を分けるのに役立ちます。常にすべてを見る必要がなければ、短期的な計画をより適切なものにできます。いっぽう、パーキングロットをレビューすれば、ロードマップ、つまり長期的な計画に入れたいものが見つかるでしょう。

データを削除し、溜め込まない

ポーラがデータの溜め込みの問題に対処するには、数か月にわたってプロダクトオーナーやチームと協力する必要がありました。一夜にして達成できたわけではありません。それでも、取り組みを始めてから3か月後には、いくつかのチームはフィーチャーをより早くリリースできるようになっていました。なぜでしょうか？それらのチームは、迅速な開発の妨げになる小さな問題をすべて修正しており、結果として、リクエストによりすばやく応答できたからです。

直近の目標に関してより適切に計画し、実行できたのです。それによって、もっと先の作業についてより多くの試行を重ねることができます。

チームは最も重要なデータだけを見ており、すべてのデータを管理しようとすることからくる認知負荷はありませんでした。

ずっとデータを持ち続けてきたからというだけでデータを溜め込まないようにしましょう。どのようなデータを利用し、保存するか、データに関して振り返りを行いましょう。

Pragmatic Managerとして知られるJohanna Rothmanは、顧客の難しい問題に対して率直なアドバイスを提供しています。リーダーやチームが問題を直視し、リスクを解決し、製品開発を管理できるよう支援します。Johannaはこれまでに14冊の書籍と多数の記事を執筆しています。jrothman.com および createadaptablelife.comで月一回発行の電子メールニュースレター「Pragmatic Manager」およびブログをご覧ください。

（この記事は、開発元Gurock社の Blog 「Hoarding Content: How Long to Keep Ideas in Any Form Around」2020年1月7日の翻訳記事です。）