この記事は、みらい翻訳 Advent Calendar 2020 ８日目の記事です。
みらい翻訳 Advent Calendar 2020には二回目の登場となります @nile_mt です
エンジニアリングマネージャーとして、機械翻訳サービスのMiraiTranslatorの開発に携わってます。
私自身は、機械学習系のエンジニアではなく、どちらかというとWeb系かつマネジメント系の人です。
はじめに
バックログを作ったけれど、どこから手を付ければよいか迷ったことはないでしょうか？
あるいは、プロジェクトが続くうちに、バックログが溜まってしまって、優先度がわからなくなったことはないでしょうか？
あるいは、業務がたくさんあって、どう消化していいのか途方くれたことはないでしょうか？
私はあります。
そういう時は、一度手を止めて優先度の見直し（棚卸し）をするのがオススメです。
今回は、そういう時の、頭の整理をするのに役立つ優先度についてのフレームワークのいくつかをご紹介します。
MoSCoW法
1994年にDai Cleggが開発。元々はRAD（Rapid Application Development）で使う用だったようです。
（RADって何十年ぶりかに聞いた）
| M | Must have | 必須 | 入らないとリリースできない. |
| S | Should have | 重要 | 重要だがリリースに必須ではない |
| C | Could have | あれば尚良し | 望ましいが、必須ではない。時間があればやるやつ |
| W | Won't have | 多分、無駄 | 重要でなく見返りが小さいとステークホルダーと合意されたもの |
MustなのかShouldなのかの見極め大事
冷静に判断しましょう。
Kano Model
狩野モデル-Kano Modelを上げておく
狩野モデル（かのうモデル）は、顧客満足度に影響を与える製品やサービスの品質要素を分類し、それぞれの特徴を記述したモデルである。1980年代に東京理科大学教授であった狩野紀昭によって提唱された[。マーケティングや品質管理の分野に対して多大な影響を与えたモデルであり、世界的にはKano Modelとして知られる。
出典: フリー百科事典『ウィキペディア（Wikipedia）』
UXに関心のある方なら、ご存知の方も多いのじゃないかと思います。
次にどんな機能を作ろうかという議論のときに、ちゃんと必要とされるものを作りましょうというお話。
| 項目 | 内容 | 例（スマートフォン） |
|---|---|---|
| 当たり前品質 (Must-Be) | 最低限必要なもので、ないと不満を引き起こす | 通話音声（音が良くて当たり前、聞き取りづらいと不満） |
| 一元的品質 (One-Dimensional) | 充足されると満足、ないと不満になるもの | バッテリーの持ち（稼働時間が長ければ満足、短いと不満）、重量など |
| 魅力品質 (Attractive) | 不充足でも仕方がない（不満には思わない）が、充足されれば満足 | ハイレゾ音源（あれば良いが、なくても不満ではない）、曲面液晶など |
| 無関心品質 (Indifferent) | 充足、不充足で満足度に影響ないもの | |
| 逆品質 (Reverse) | 充足すると不満になり、不充足なら満足になるもの | あまりに高度で細かな設定画面等 |
例えば、スマートフォンにおける、高精細カメラは、以前は魅力品質だったが、一元的品質あるいは当たり前品質に変化。
日科技連 狩野モデルと商品企画 から引用
緊急度・重要度のマトリクス
日々のタスクの優先順位づけなら、こちらが基本かもしれません
どのタスクが今すぐ手をつけるべきタスクかを見極めるための考え方
理屈は単純で、緊急度（時間）x重要度（影響範囲・インパクト）の２軸で考える
Jooto 緊急度☓重要度のマトリクスによるタスクの優先順位の付け方から引用
| 重要度 | 緊急度 | 優先度 | |
|---|---|---|---|
| A | 高 | 高 | 最優先。今すぐ片付けるタスク |
| B | 高 | 低 | 将来への価値になるタスク。後回しになりがちだが、時間がたつとA領域に移動する可能性あり |
| C | 低 | 高 | できるだけ効率よく片付けるべきタスク |
| D | 低 | 低 | 基本的には後回し。ただし時間が経つと緊急度があがってC領域に移動する可能性あり |
このうち、緊急度は時間と共に変化しますで、BからA、DからCへの移動というのは起こります
とくに最優先のAへ移動する前、Bの段階でタスクを片付けられるかが肝。
「手遅れ」になってAからDへの移動なんてことにならないように気をつけましょう
意思決定マトリクス
より精緻に優先付けをしたいときに使うのがこちら
事前に緊急度・重要度のマトリクスなどでカテゴライズして評価対象を絞っておくのがオススメです。
引用：マーキャリ MEDIA
評価対象を決める
優先順位を付けたい評価対象を縦軸に列挙する。
アイデアやソリューションを評価するのか、課題を評価するのかは、はっきりさせること。
どの課題から解決するかの話してたのに、どのソリューションなら実現可能か？みたいな議論になりだしたら要注意
評価軸を決める
実現性、収益性、緊急性、独自性、効果性、将来性、インパクト、優位性、展開性、リスクなどなど。
「重要性」みたいな言葉を使うと、何を評価する軸なのかが曖昧になるので、
「収益性」とか、「想定顧客数」、「セキュリティリスク」とか、
できるだけ、何を評価するのかがはっきりわかる軸を設定しましょう。
個人的な経験的には、あまりに多くの評価軸を設定すると順位が付けづらくなるので、４〜５ぐらいがオススメ。
評価軸の比重を決める
評価において、なにを重視するかを議論して、比重設定する。
倍率で考えるのが難しい場合は合計を100％にした割合で考えるとわかりやすい。
けど、無理して比重かけなくてもいいと思う。
評価を行う
例：各項目を５点満点で採点。合計点を計算
話ながら決めていってもいいし、それぞれで採点して付き合わせてもいい。
やり方はチームそれぞれ。
どこまでデータ集めてやるかというのも、チームや状況に応じて変わると思いますが
データ集めにあまりにも時間がかかるようなら、仮説（≠勘と経験）を信じても、そんなに変な事にはならないと思います。
注意
・なるべく複数人で行う。評価項目の選定や倍率の設定までチーム行うのが望ましい
・スコアリングした結果に、違和感がある場合は、違和感の原因を考える。
・点数をつけて終わらない。課題を評価する場合は、その後の打ち手も話し合う。
まとめ
勘と経験とか、起票者の声が大きいからとかであれやこれやと手を付けていくと、
貴重なリソース（時間とお金）を消費しても効果がでなくて、ストレスたまる一方なので
こういうフレームワーク使って、冷静に判断していきたいですね。
（こういうので理論武装しとくと、飛び込みタスクにも冷静に対応できます。）
明日は、SREチームの @kobarasukimaro がAWSについてなんか書くみたいです。