優先順位をつけるべきか?

本稿は、2023 年 6 月 23 日に AWS Cloud Enterprise Strategy Blog で公開された “Should You Prioritize?” を翻訳したものです。

ときどき、ある考えが常識として染み付いてしまっており、私たちの行動すべてに組み込まれている前提となっていることがあります。会議で誰かが「優先順位をつける必要がある」と言ったり、「これは優先事項ですか？」と言ったりなどです。何かがうまくいかないとき、それは優先順位をつけなかったせいにされるかもしれません。IT チームが、ビジネスが要求するすべての仕事に対応できないとき、ビジネスリーダーには優先順位をつけるよう求められます。優先順位という言葉は、ハイレベルなもの （会社の戦略的優先順位を決めなければならない） から、粗い粒度の戦術的なもの （投資に優先順位をつけなければならない） 、細かい粒度のもの （優先順位に基づいてバックログを整備しなければならない） まで、さまざまな議論の中で定着しています。

優先順位をつけることが誰にとっても難しいように思えるのは、何か不自然なところがあるからなのでしょう。

問題のひとつは、優先順位という言葉の意味が変わってしまったことです。14 世紀にラテン語の prior を元にした古フランス語の priorite から作られた最初の造語では、「（他の何かより） 早い状態」を意味していました。つまり、重要性ではなく時間を指していたのです。1900 年代に入ってから、直ちに注意を要するという意味を持つようになりました。[1]

priorities という複数形は、最近になって英語に加わったものです。これは 1900 年代に作られた造語で、1940 年代まではほとんど使われていませんでした。それまでは、最も重要なことは 1 つしかないのだから、優先順位は 1 つしかないことは明らかだったのです。prioritize という動詞が生まれたのは最近のことであり、1972 年の大統領選挙の頃に、政治的な演説の一部として初めて使われました。

私たちの多くは本能的に、優先順位とは企業にとって最も重要な事柄の集合であると定義していますが、実のところ、今日この言葉をそのように使うことはほとんどありません。その意味は、私たちが認めたがらない形で再び変化しています。

今日における優先順位付けの本当の意味

奇妙なことに、今日私たちは優先順位付けを、やる仕事とやらない仕事を分けるために使っています。新しい仕事が提案されると、誰かが 「それは本当に優先順位が高いのか？」と尋ねるでしょう。それは、優先順位が高くないなら、やるべきではないというのが前提があります。優先順位とは、もはや他のことに先立ってやらなければならないことでも、最も重要なことでもありません。だから複数形が必要になっているのです。複数の優先順位がなければ、やるべきことはひとつしかないのです！

今日の用法では、優先順位とは、組織のランク付けされたすべてのニーズのサブセットとなっています。優先順位を付ける、とは、潜在的な仕事や投資のリストを作り、それらを重要度の高い順に並べ、その中から上位 3 つ、 6 つ、あるいは 12 個を取り出し、優先順位のラベルを付けることです。それらが、その企業が投資する対象となるものです。

なぜ、このように意味が変わってきたのでしょうか？ それは、経営者やリーダーが絶え間なく経費削減を求められそれを証明する必要のある環境の中に住んでいることが関係しているでしょう。優先事項、つまり 「やらなければならないこと」だけに投資すること以上に、支出を少なくする方法はないのです。その起源はどうであれ、この変化は、優先事項が「すべてやるつもり」リストになるというダイナミズムを生み出したのです。奇妙な感じがしますよね？

私は最近、2 社の戦略計画を見直しました。そのうちの 1 社は、11 の優先事項を挙げていました。なぜそんなに多いのでしょうか？ それは、事業を運営するために必要なことをすべて盛り込もうとしているからです。2 社目の戦略計画には 4 つの優先事項しかありませんでしたが、どれも漠然としたもので、「卓越した運用を追求する」とか 「顧客のために成果を出す」といった内容でした。優先順位はすべてを含むように意図されており、彼らが選択したものはすべて、形式化された優先順位にマッピングできるようになっていました。

これらの「優先順位付け」は、優先順位について何も伝えていないというのが実際のところです。

優先順位付けの重要な（奇妙な）前提1：固定されたキャパシティ

優先順位付けの中心的な前提は、私たちは固定されたキャパシティで仕事をしているということです。私たちができることには限界があるため、優先順位をつけなければなりません。おそらく、優先順位付けの候補リストには、良いリターンが期待できる投資だけが含まれているはずです （そうでなければ候補にはなりません）。優先順位付けの考え方には、機会費用が発生する可能性を残しておこうという意図が組み込まれています （訳者注：機会費用とは、ある生産要素を特定の用途に利用する場合に、それを別の用途に利用したならば得られたであろう利益の最大金額をさし、実際の生産額の費用とする概念[2]）。リターン獲得のために利用可能な機会に基づいてキャパシティが設定されるのではなく、キャパシティが　（どうにかして）　設定され、そこから利用可能な機会が導き出されるのです。

IT 部門は長い間、この仮説に悩まされてきました。 IT 部門は、企業全体のサービスに対する需要を募ったり、受け入れたりすることで、優先順位をつけるために要求された仕事のリストを作成します。この需要は常に IT 部門のキャパシティを超えるため、 IT 部門は全部の中から一部を選択しなければなりません。断る仕事の中には、会社の利益になる仕事も含まれているため、組織 （訳者注： ITにリクエストを出すビジネス部門のこと） の一部を不愉快にさせ、 IT 部門が反応が遅くて鈍いという印象を与えることは間違いありません。

ビジネス部門の人々は、良いアイデアをたくさん持っている傾向があります。もし、キャパシティには限りがあり、優先順位をつけなければならないと言われれば、優先順位が高いものしか扱われないとわかっているため、すべて良いアイデアなのですべての優先順位が高いと宣言するのは自然なことです。もし優先事項だけで実行可否が決定されるのであれば、付加価値を生むアイデアはすべて 「優先事項」になってしまうでしょう。

実際、組織には、優先事項でなくてもやらなければならないことがたくさんあります。特に IT の世界では、会社を運営し続けるにはかなりの帯域幅 （訳者注：キャパシティと同義）　が必要です。仕事を「優先事項」に限定すると、デス・スパイラルが始まり、会社の運営にリスクが加わり始めます。優先順位をつける行為自体が無駄を増やしていくのです。技術者ならこの比喩の意味がわかるかもしれません。コンピュータのメモリが少なすぎると、結局 CPU はアプリケーションをメモリに出し入れするのに時間を費やしてしまい、無駄に消費されてしまいます。 IT 部門は、創造に費やせるはずの労力を需要管理とガバナンスに費やすことになります。

キャパシティに基づいて仕事を絞り込まなければならないという考えは、私たちが平衡状態にないことを意味しています。私達が価値を生み出すことができないのであれば、受け入れるキャパシティを増やす必要があります。あるいは、優先順位付けの候補を特定する方法に何か問題があるのかもしれません。企業は制限されたキャパシティで働くべきだという考え方は、キャッシュ・マネジメントとの類似から来るものかもしれません。企業は一定額のキャッシュしか持っていないので、利用可能なキャッシュでしか投資を行うことができません。しかし、それは短期的な話であり、企業の成長計画はキャッシュ・ニーズへの対応が不可欠です。経営がうまくいっている企業では、資金の制約がビジネス価値を損なうことはありません。 IT リソースに恒久的な制約を課すことは、どういうわけかそれとは違うように思われるのです。

いずれにせよ、 IT 部門は優先事項だけでなく、企業が必要とするすべてのことに責任を持たなければなりません。

優先順位付けの重要な（奇妙な）前提2：既知の機会

優先順位付けの２つ目の前提は、与えられた投資機会のリストについて意思決定を行うことです。私たちは、「優先順位付けの候補となる以下のリストの中で、どのように順位付けをすべきか、また、どのリストに取り組むべきかの境界線をどこに引くべきか？」と問います。しかし、目まぐるしく変化する今日の不確実な環境では、私たちは常に新たな機会や課題に遭遇し、潜在的な投資案件の重要度が上がったり下がったりしています。

スクラムのようなアジャイルフレームワークは、作業のバックログを作成し、それを頻繁に優先順位を変更し、または洗練することによって、こうした変化を管理しようとしています。しかし、おそらくこれは優先順位付けとプロジェクト管理を混同しています。（議論の余地はあるものの）スクラムは組織的な優先順位から逆算するのではなく、要求抽出のプロセスを通じて与えられた、粒度の細かい個々の作業項目を調整しています。スクラムは本質的に、優先順位付けとはランク付けとサブセット化を意味するという考えを形式化したものです。もちろん、バックログを整理し、優先順位を付け直すことはできますが、バーンダウンチャート （訳者注：プロジェクトの進捗状況を可視化したもので残りの作業量を把握することができる）　を有用なものにするためには、多かれ少なかれ、前もって事前に作業を把握しておく必要があります。追加することはできますが、それに必ず他の作業への影響があります。

ここで想定されるメンタルモデルは、それぞれ独自のニーズを持つしたサイロ化された事業単位であり、中央にある IT 組織によってランク付けされなければならない、というものです。各サイロは独自の優先順位があり、中央の IT 組織は 「中央」であるがゆえに異なる優先順位を持っています。この状況は、競合する優先順位の枠組みが生み出され、勝者と敗者を選別しなければなくなります。予想通り、 IT は「ビジネス」と「より整合性のある」ものになるべきだという声が絶えません。

優先順位付けの重要な（奇妙な）前提3：厳格な方法論

3つ目の前提は、多種多様な投資を合理的に順位付けする方法があるはず、それはおそらく投資収益率 (ROI) である、ということです。しかし、拙著『 The Art of Business Value 』で論じたように、 ROI はこの目的を効果的に果たすものではありません。 ROI に基づく IT 作業の優先順位付けは、ビジネススクールの教授だった方々には申し訳ないのですが、価値を破壊することになります。私は、ESGの重要性が増すにつれて、このことをさらに確信するようになりました。ステークホルダーは、必ずしも ROI を最大化しないものにも価値を見出すことが多いのです。

優先順位を分けて考える

この混乱を解きほぐす第一歩は、戦略、優先順位、仕事量管理の概念を分けることです。戦略とは、優先順位のリストではなく、リーダーが自社の市場に対する独自のアプローチを推進するために決定する、一連の原則です。どんな瞬間にも、優先順位は 1 つであるべきです。それは、戦略を実行するにあたり、リーダーが従業員に集中して取り組んでほしいと思える事がその時々の優先事項なのです。しかし、優先事項 （単数）は、会社が実行する必要のある仕事すべてではありません。実行は高帯域幅で多くのことを並行して行う必要があります。今日、私たちは従業員を自律的なチームに編成し、それぞれの領域に対して完全なオーナーシップを持つようにしています （「自分たちが構築したものを自分たちで実行する」）。これは、活動を並行して行うための優れた組織構造になります。

この3つのコンセプトはそれぞれ異なりますが、連続した全体の一部になります。仕事量管理に対する異なるアプローチは、経営陣が戦略を打ち出すことから始まり、その戦略を達成するための仕事に直接移行します。優先順位付けが必要な、組織全体から募ったイニシアティブのリストは存在しないのです。イニシアティブは、ハイレベルの戦略から有機的に導かれます。また、優先されるのは最初に実行されるイニシアティブです。戦略上の必須事項が成長である場合、望ましい成長をもたらす可能性が最も高いイニシアティブが追求されます。これは、他のイニシアティブが推進されないという意味ではなく、リソースの競合がある場合に戦略的なイニシアティブが優先されるというだけなのです。

これは、優先順位の設定について私が常に耳にしている雑談に基づいた考えにすぎません。参考になれば幸いです。

-Mark

[1] Online Etymology Dictionary https://www.etymonline.com/search?q=priority
[2]　機会費用 コトバンク

この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。