優先順位付けとバックログについて考える

こんにちは、楽天ラクマでプロデューサー（PdM）をしている鈴木です。
ラクマで仕事をしていく上で、学んだことを今日は書いてみました。

はじめに

あなたの目標はなんですか、そのために今日何をしますか？

組織戦略レベルからチームの日々のタスク、ひいては個人のToDoまで時間、リソース、資金などに限りがある以上、すべてにおいて優先順位付けが必要です。なにをしてなにをやらないか、この判断を素早く妥当に行うことが命運を分けます。

“Coming up with an idea is the least important part of creating something great. It has to be the right idea and have good taste, but the execution and delivery are what's key. Any conversation I have about innovation starts with the ultimate goal.” - ― Larry Page

あんなこといいな　こんなこといいな　夢を叶えてくれる猫型ロボットはまだいない
I am NOT User　私たちはユーザーではないのだから
「なにをしたい」より先の世界を目指しましょう

そのために、優先順位付けとバックログについて考えをまとめてみたいと思います。

バックログとは

広義には「積み残しの作業」という意味ですが、プロダクト開発においては主に以下に分類できるかと思います。

主に管理につかわれているツールは

• JIRA
• Excel
• Torello
• Asana
• Office 365

などなどありますが、いずれも自由度が高く拡張性のあるものです。

細かい使い方やプロセスはそれぞれの管理者・利用者によって様々になりますが、概ね個別の項目にたいして、「期限」「優先度」というようなパラメータが付けられ優先順位が管理されているのだと思います。

バックログの数だけ、管理者がいてバックログの数だけ優先順位付けの基準が存在しうるものです。

ラクマのバックログ

組織が大きくなるにつれて、バックログといわれるものも増えています。私が入社した3年ほど前、組織の代表者がフリースペースに集い「次なにをするのか？」をいちどに話せていた頃が懐かしい・・

開発、事業それぞれのチーム毎に「やりたいことリスト」と「優先順位」が存在しており、それらを相互に把握して、整然と優先順位が並ぶということが難しくなっています。

さらに楽天市場と連携するようなプロジェクトとなると、楽天市場側の熾烈な優先順位付けにも勝利する必要がある状態です。社内調整に忙殺されず、ユーザーに向き合う時間を確保するためにも、バックログの管理や優先順位付けについては全体で改善をすすめていきたいと考えています。

理想的なバックログの管理

組織における理想的なバックログの状況を考えてみます。バックログに限らずなにか情報を管理するという点において「良い管理状態」とは次のような特徴があります

1. 常に最新化されている
2. 合理的で一貫した基準で分類、順位付けされている
3. 同じ内容が重複して存在していない
4. 管理者以外がみても理解しやすい
5. 必要なものだけが記録されている
6. 状況にあわせてメンテナンスが容易にできる
7. 管理状況の不備に気付きやすい

理想的なバックログは　必要最小限の情報が、一貫性のある基準によって、透明性をもってメンテナンスされています。

優先順位をきめること

「優先順位」という項目はいろいろなところで目にします。みなさんも「高」「中」「低」などを記載することは多いと思いますが、リストアップされたものの大半に同じ優先順位がついていたりしていることを目にしませんか。これでは優先順位がつけられている、いるとということにはなりません。

優先順位をきめるという行為は、相対的に明確な序列をつけること。優先しないことをきめるということ です。あれも、これも捨てがたい。けれど、そのためにはなにを諦めるかというジレンマと戦う行為です。
これは消極的態度の表れではありません。

最悪なのは優先順位をつけずにあれもこれもと手をだしてどれも中途半端になり終わらないことです。なぜ、「優先順位を付けなければならないのか？」と立ち戻って考えてみれば、「時間」や「費用」など資源の制約があるため です。そして、「今期にやるべきことはなにか」というような「ものさし」となる 価値判断基準 があるからこそ、取捨選択が行えるようになります。

システムのバックログ管理ツールを使うと、際限なく登録ができてしまいますので忘れがちですが、誰しも一度に処理できる情報には限界があります。優先順位を決める上でも候補はいずれも比較、考察、評価、分析する必要があります。制約や価値基準、さらに処理能力の限界を定めずにバックログにリストアップをしてしましまうと、自らの首を占めることになります。

有事の優先順位判断

「部隊の中で最初に死ぬのはだれか、最後まで生かすのはだれか」これは、自衛隊で学んだ軍隊を指揮する立場のものが決めておかなければならないことです。その時の状況判断を素早くおこなって冷厳な判断をしなければいけません。

「家屋の瓦礫撤去が１０件、行方不明者捜索が３件、炊き出しが２件、泥かきが３件。使えるのは2tトラック１台、人員は男5名、女5名。だれを何処におくる？」これは、東日本大震災の後、災害ボランティアセンター運営で日々行われていた意思決定です。

ビジネスにおいてはこれほど差し迫った状態ではないかと思いますが、いつも「想定外のこと」ということは起きるものです。考えうる最悪の状態が起きた時に何をまもるのか？を考えておくことは、平時に優先順位を決める上でも役にたつと思います。

情報のサイズを揃える

優先順位をつけるための前提条件として「情報が比較可能な状態である」ということも要点です。
比較可能とは「情報のサイズ」が同じであるということです。

ここでは階層的に情報を分類する感覚が必要になります。どのような切り口で情報を階層化するか？というのも唯一の解はありません。これもバックログの用途や共有する相手によって判断する必要があります。

エンジニアメンバーがスプリント中に実施すべきタスクの優先順位と、PdMやProductOwnerが 管理する自身のチームのプロジェクトや次期施策の優先順位と、経営層の戦略的方針の優先順位とでは、情報のサイズが異なります。これらを混同しないように、かつ全体的な整合をとることが大規模な組織には必要になります。

「やらない」という選択肢

ひとたび、バックログに改善のアイディアなり課題が追加されてしまうと、誰しも思考のバイアスとして 「これをいつやるべきか？」 という考えに陥ってしまいがちです。

特にそのアイディアを生み出したのが自分自身であったり、それを公言してしまっていたりするとバイアスはさらに強力になります。「結果的に優先順位で下位になってしまったけれど、いつかのために残しておこう」 というのも、バックログをいたずらに積み上げてしまう要因でもあります。

アイディアも課題もナマ物です。時間が経過するほどその価値も意義も前提も薄れていくものです。「今やるべきものではない」と判断した後には、「これを本当に残しておくべきか」「いつまでこの情報の価値は残るのか？」ということを意識することをおすすめします。

そうするといま自ら優先順位をあげようとしているアイディアに対してより、批判的な視点で見ることができるようになります。

みんなで決めても管理者はひとり

バックログを整然と管理するためには、先に述べたように一定の秩序と一貫性が求められるようになります。そのためには、それを担える「管理者」が必要になってきます。

組織が大きくなってくると、ある一つのバックログに対しても、
- 新規課題を追加しようとする人
- 優先順位の意思決定に関わる人
- そのリストから生み出されるタスクを遂行するひとなどなど影響を受ける人
- 影響を及ぼそうとする人
が増えてくるものです。

多様性を生かし、集合知によって優先順位を公正な議論によって決めていくいうことは望ましいですが、一貫性をもった状態を維持しつづける上では、管理者は明確に一人であるほうが良いです。そうでないと、先にのべた「情報のサイズ」も「ものさし」も「許容できるバックログの数」も瞬く間に崩れてしまいます。

管理者は管理対象のバックログに対して説明可能な状態である必要があります。それが困難な状態であれば管理ルールや方針を変更し、それに影響をうける関係者へ周知をする必要もでてきます。

意思決定が恣意的、または独裁的にならないためにも管理者はバックログの状態を維持して、いつでも後任の管理者に引き継げるようにしておきたいです

おわりに

優先順位付けというのは誰もが日常的におこなっていることではありますが、組織運営においてもその明暗をわける重要な要素です。

公式、非公式を問わず、みながそれぞれに優先順位とやりたいことを持っています。しかし、多くの関係者を巻き込み、その賛同を得て時間とお金を確保できない限りはどんなに秀逸なアイディアも日の目をみることはありません。

組織でバックログを取り扱う全ての人が、その上位、並列、下位に存在するその他のバックログにも意識をむけて、メンテナンスを継続しておくことがより大切になるのだと思います。