仕事とかで優先度について考えること多いけど、優先度の決め方って人によって結構異なる気がした。
自分は優先度の決め方にそれなりに理屈を持ってやってるつもりで、それは個人開発やってた経験が大きく影響していて、そのあたりについて書いてみる。
（個人開発の経験が大きく影響しているので、企業開発の場合に求められる物と少しズレはあるかもしれない。これについて自己認識出来ている部分は記載しておく。）
完璧主義をやめて優先度を考える
優先度決めるとき「これも大事、これも大事」ってなって「全部優先度(高)」みたいなのってありがち。
人って基本完璧主義で、理想が高すぎるんだと思う。
個人開発でもよく「これも盛り込みたい、あれも入れたい」ってやってて結局完成できずお蔵入り、、ってのも多い。
企業開発でも個人開発でもやりたい事に対して基本的に工数は不足する。
なので「やりたい事はできない」を基本マインドにする。
その「できない」の中から「できそう」な事をチョイスしていくイメージ。
優先度決めの作業で無数の要望の中から優先度（超高）を数えるくらい選んだら、残りが優先度（高）なのか（中）なのか（低）なのかは考えるだけ工数の無駄なので考えない。（超高）の実装が済んで初めて考える。予め検討しても状況も変わってるのでどうせ考え直すことになる。
個人開発なら上記した事でOKだが、企業開発だとこれに追加の事情が加わる。
別部門からの要望で「とにかく絶対にこの機能は必要！優先度超高でお願いします！」みたいなやつ。
結果、優先度超高で溢れることになる。
これはステークホルダーそれぞれの譲れない事情があって（よくよく議論してみるとそうでない場合も多いが）、それらが全部開発に降ってくるから発生するのだと思っている。
例えば営業にとっては今季の利益を上げることが何よりも優先なので、開発からみたら「一時的に利益あげても払う工数に対しての見返り少なくない？」っていう理論はあまり理解されない。
もちろん会社がなくなっちゃったら元も子もない。利益は大事。
ただ、この一時的な利益を優先するために失われるものも確かにあって、それは継続的は利益を得るための機能実装や、現在赤字になっている状況の解消の先送りであったり。
こういう状況でどれを優先させるかの判断は開発だけでも営業だけでもできないので、少し上のレイヤーの職位の人の判断になるパターンだと思ってる。
相手の言っている優先度の高い要求を受けるかどうか考える時、その要求が会社としての要求なのか、その人個人の要求でしかないのかを知る必要がある。
この時、相手が「要求を開発にいかにねじ込むかが腕の見せ所である」みたいに認識しているパターンだと優先度の議論が成立しないので、ちょっと難易度が高くなる。
マシなパターンに倒すことで、最悪のパターンを避ける
優先度とは少し異なるが「マシなパターンに倒すことで、最悪のパターンを避ける」というのを意識している。
個人開発をやるにあたって最悪のパターンとは「モチベーションを失って、結局アウトプットが何もない」である。
個人開発は無償で苦しさに立ち向かわなければならず、それを支えるのはモチベーションのみである。
なにか作ろうと思い立ったとき一番モチベーションが高いが、徐々にそれは失われていく。
他に興味が移っても失われる。基本いつ失われるかわからないと思っておく。
開発半ばでモチベーションが失われるとそれ以降開発はほったらかされ、そこまでどれだけ完成度が高くてもリリースされなければアウトプットはゼロである（経験は残るが）。
この「モチベーションを失って、結局アウトプットが何もない」を避けるために以下の戦略を取っていた。
- 機能を極限まで絞ってリリースしてしまう。その後、モチベーションが続く限りほそぼそと追加機能開発を行う。
- 開発で得られた知見をブログなどでアウトプットする。
完璧主義を捨て、機能を極限まで絞ったしょぼい状態でリリースまで持っていく。
結果これがモチベーション維持にも繋がる。やっぱ本番で動いているというのは気持ちが盛り上がる。
あとはいつモチベーションが失われてもリリースした事実とモノが残るという算段。
また、ブログで知見をアウトプットすることで、リリースまでいかなくても「アウトプットゼロ」を回避する。
上記は個人開発での話だが、企業開発でもやたら仕様が大きくなってまとまらなくなり、このままだと期限にリリースできない（最悪パターン）が見えたときに「一旦、最小仕様（マシなパターン）で作ってみて、その後追加仕様で改めて検討しませんか？」みたいに提案したりする感じ。
曳光弾
開発中は「急だけど来週リリースな」って言われる可能性が常にあると思って開発する。
リリース日が動かなくても、差し込み業務で丸一ヶ月の工数が吹っ飛ぶ可能性を意識している。
個人開発で言うと、突如モチベーションが失われてしまって、来週中にリリースできなければお蔵入りになってしまう、みたいな状態。
だから開発は、まずリリースできる状態まで持っていき、それ以降常にリリース出来る状態をキープする。
※ここで言う「まずリリースできる状態まで持っていき」とは最小機能で、要求仕様は全く満たせていないがとりあえず動作する、程度の状況
達人プログラマーという本で曳光弾という名前で紹介されていた（うろ覚え。こういう事を言ってたような気がする。もしかしたら違うかも）
例えばECシステムで必要な機能って、
- 商品一覧
- カート機能
- 決済機能
- 商品登録・編集
- 在庫管理
- 会員管理
- その他もろもろ
みたいに色々あるけど、とりあえず商品一覧が閲覧できる状態で本番で動くところまで持っていく。
極端だけど、ここまで作って「来週リリースな」ってなった場合、
- 商品登録や編集はDBを直接触って登録
- カートとか決済機能はないので、商品見て電話問い合わせで購入オペレーション。支払いは代引きとか使ってもらう
- 会員管理もエクセルとかでやってもらう
みたいな、条件は色々あるけどリリースはしようと思えばできる、という状態にできる。
（もちろん企業開発だと「最低ラインの品質」というものはあるが）
これが例えば、全部の機能を並行して作っていると「来週リリースな」の時点で出来ている機能が何もない（カート機能はできてるけど、商品一覧がまだないとか。）、本番環境自体まだない、というような状態になる。
こうなると、この一週間で本番環境構築しながら最低限の機能開発を突貫でやらねばなくなり、あわあわすることになる。。
優先度の決め方イメージ
優先度の決め方は「その機能って無いとどうにもならないのかどうか」で考えている。
残工数にもよるけど、例えば
カート機能：「電話でショップに問い合わせてもらうようにすれば購入できる」ので「どうにかなる」
商品一覧表示：「電話で問い合わせても一覧から選ぶという行為は難しい」ので「どうにもならない」
というわけで商品一覧が優先。
会員登録、決済機能もエクセルや代引きとかで「どうにかなる」ので優先度は低め
商品登録・編集機能は「毎回DB直接いじればどうにかなるが、運用をショップに任せるのであればどうにもならない」ので優先度高め
在庫管理は「在庫切れしていれば断りの連絡を入れたり、商品を取り下げておいたり出来る」ので「どうにかなる」ので優先度低め
みたいな感じ。
「どうにもならない」のやつが一通り実装できたら「どうにかなるって言うけど、実質これがないと運用が回らない」といったものに着手していく。
さっきの、カート機能：「電話で問い合わせて貰えれば購入できる」あたりは（規模によっては）実質運用難しいと思うのでこのあたりが候補になりそう。
売上管理とか、トレンド予想とか、おすすめ商品機能とか高優先度で希望されたりするけど、軒並み優先度低め。
こういうのは基本機能が揃ってから手を出すべき。
あと、以外に盲点としてシステム開発・運用側で優先度高い機能があったりする。
アラート通知まわりとか、CICD整備とか、バッチ処理の失敗時の復旧オペレーションの建付けとか機能化とか。
こういうのは初期にやっておくと、以降の工数が福利っぽく浮いてくるので優先度高でやっておきたい。
、、みたいな感じ。
