見出し画像

優先順位付けとバックログ

はじめに

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

組織戦略レベルからチームの日々のタスク、ひいては個人の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

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


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

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

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

  1. 常に最新化されている

  2. 合理的で一貫した基準で分類、順位付けされている

  3. 同じ内容が重複して存在していない

  4. 管理者以外がみても理解しやすい

  5. 必要なものだけが記録されている

  6. 状況にあわせてメンテナンスが容易にできる

  7. 管理状況の不備に気付きやすい

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

優先順位をきめること

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

これでは優先順位がつけられている。ということにはなりません。

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

最悪なのは優先順位をつけずにあれもこれもと手をだしてどれも中途半端になり終わらないことです。

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

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

優先順位をきめるとは、優先しないことを決めること
優先順位をつけるためには、制約と「ものさし」となる価値判断基準をしることが必要
優先順位検討で取り扱える情報処理能力の上限に注意すること


Column 有事の優先順位判断

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

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


情報のサイズを揃える

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



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

エンジニアメンバーがスプリント中に実施すべきタスクの優先順位と
PdMやProductOwnerが 管理する自身のチームのプロジェクトや次期施策の優先順位と
経営層の戦略的方針の優先順位とでは情報のサイズが異なります

これらを混同しないように、かつ全体的な整合をとることが大規模な組織には必要になります。

バックログに並べる情報のサイズをそろえること。サイズや階層の異なるものを同列に扱わない
管理しやすい「情報のサイズ」はシーンにより様々である

バックログの詰みすぎ注意

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

ひとたび、バックログに改善のアイディアなり課題が追加されてしまうと
だれしも思考のバイアスとして
「これをいつやるべきか?」
という考えに陥ってしまいがちです。
特にそのアイディアを生み出したのが自分自身であったり、それを公言してしまっていたりするとバイアスはさらに強力になります。

  「結果的に優先順位で下位になってしまったけれど、いつかのために残しておこう」 というのも、
バックログをいたずらに積み上げてしまう要因でもあります。

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

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

優先したいものを終わらせる意味

また、優先すべきなにかが終わるということは、その結果によりなにか変化が生まれるはずです。その結果は次に実施すべき優先順位判断の新たな材料になるものです。

「優先順位がつけられない」要因の一つには、このように判断材料が乏しい中で同時にあれこれと想像を巡らせて仮定に仮定を積み重ねてしまっている。ということがあります。

不確実性が高いなかでの意思決定はその精度も落ちるものです。
順位付けをしようとして比較している対象が多すぎる場合、不確実性に不確実性を積み重ねているような状態になります。

優先順位をつけることを目的化してはいけません。
検討に値することだけを考えるようにする必要があります。

「やらない」という意思決定にも意味がある
「やらない」を選択肢とすることで、アイディアを批判的に検証できる
アイディアや情報はナマ物。経年によりその価値はかわる


Column さよならPepperくん

昔、Pepperくんが世にリリースされた頃、その活用検討がプロジェクトポートフォリオに載りました。
新し物好きの社長のオーダーということもあり、時間をかけてあらゆる検討が行われましたが結果的にその時には別のプロジェクトが承認されました。

その後のトレンドや街中でPepperくん見かけると「Pepperくん導入」というものをバックログとして残していなくてよかったと感じます。

バックログに残らないことで、私自身もその後任となる者も、Pepperくんの利用価値や機能拡張、事例収集、トレンドの趨勢などを意識し、継続して追い続ける必要から解放されたからです。

アイディアをボツにする。というのは誰しも心理的な抵抗をもちます。
ただボツになったことで得られた反省と、その分空いた脳のリソースによって、
次のよりよいアイディアを生み出すことができるのだと思います。



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

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

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

多様性を生かし、集合知によって優先順位を公正な議論によって決めていく
ということは望ましいですが、一貫性をもった状態を維持しつづける上では、管理者は明確に一人であるほうが良いです。

そうでないと、先にのべた「情報のサイズ」も「ものさし」も「許容できるバックログの数」も瞬く間に崩れてしまいます。

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

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

みんなで決めてもよいけれど、一貫性を保つために管理者は一人に定める
管理者には説明責任が伴う。管理者がいなければ情報は無秩序に蓄積される
管理者は管理者をいつでも引き継げるように、ルールを整備する

おわりに

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

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

この記事が気に入ったらサポートをしてみませんか?