仕事で特に意識していなくても、作業優先順位という物が割り振られていると思う。しかし、この作業優先順位が機能していた例は、一番初めに従事したプロジェクトのバグ管理だけだったと思う。
ここでは、筆者が経験した「優先度」という物に対しての意見や、こういう表現されたら気を付けろ!的な経験則の内容を記載していく。
〇前提:言葉の定義や現場の話
前提として、個人に与えられる作業という物は複数存在するが、好きな順番で行うわけではない。スケジュールに則って、責任ある方(ディレクターだったり、プロジェクトマネージャだったり)が、作業の順番を決める。
また、製品(=ゲームアプリ)を製造(=プログラミング)する仕事だと、当然予期せない問題が発生する。
プログラムが正常に動いていない状態を「バグがある」だとか「不具合」という。
バグ・不具合は直さなければならないが、当然のようにその作業にも順番が決められる。
この作業順序の事を「優先度」というパラメータで表す事によって、個人作業者が作業順序を把握できるように運用する事がある。大抵、優先度が高い物を「S」とし、A~Eの優先度が割り振られる。これは、数字で表されることもある。
〇問題提起
ここまでなら、ゲーム開発をしている人なら見慣れた光景の方もいるのではないかと思う。筆者も業界4年目くらいまでは、特に何も考えず「優先度って大事だよねー」くらいにしか思っていなかった。
しかし、ある時、優先度Sの物が複数割り振られたという状況になった時に「優先度って、ただ付けるだけだと意味わからなくね?」と思った。
まず、アルファベットで優先度を付けるのはいいのだが、その優先度の緊急具合が良くわからない。Sとか付けられても、緊急そうだけど、今やってる作業止めてでもやるの?と思ってしまうし、BとかCくらいになると、これいつやればいいんだろうとなる。中には、もうやる必要のない作業にBやらCやらが割り振られている事もあった。
Sが複数割り振られた時なんか、Sの中でもABCとかいうわけのわからない事になっていた。
これはもう、優先度フローを考えた人も、何をどうしたらいいのかわからなくなっていたとしか思えない。
〇提案(教訓)
結局のところ、作業の割り振りをする前にやるべき事として、
・やる
・やらない
の2択をするところから始める必要がある。
この2択をきっちり決めずに、「やらない」に該当する物をCとかに割り振るからややこしくなる。
やらないと判断した物に優先順位は必要なく、逆にどれだけ重要じゃなくても、やると判断した物には優先順位は必要になる。
さらに、優先順位とずっと言っているが、プロジェクト運用という観点からすれば、大事なことは「いつまでに終わるか」という「期限」であり、優先順位は実はさほど重要な物では無かったりする。
なので、優先順位という物は、アルファベットで漠然と、何となくの感覚で決めるような物ではなく、やるかやらないかを決めた後に、やるならいつまでにやるのか、という期限を定める事である。
その期限の早い順が優先順序という事になるだろう。
更に、アプリ開発特有の条件を加えるとするなら、本当に緊急でやらなくてはいけない物が発生した際の「今行っている作業をすぐに止めてでも対応する」というのは、あってもいいかもしれない。まぁ、これも結局期日指定はするので、特別何か起こるというわけでもないと思うが。
〇書いてて思った事
よく考えてみると、正常に運用されているプロジェクトに関して、「優先度」なんていうアルファベットでの運用が入り込む余地なんてないのではないかと思い始めてきた。
なぜなら、通常は、優先度を付ける以前に、見積もりを出してスケジュールを引いて、期日指定が必ず来るはずだ。
とすると、この優先度、とりわけ、アルファベットでの優先度割振りという物は一体どこから生まれてくるのだろうという疑問が出てきた。
まず思いついたのが、まだ開発をしている最中でのバグ報告だ。
これは、スケジュールに組み込まれる事は少なく、優先度だけ割り振るから、時間がある時に直しといてとかいう、意味不明な管理がされる傾向にあった気がする。
次に、当初予定になかった作業、いわゆる「追加機能実装」があった場合、しかも「大して大きくない細かい機能」に対して割り振られる事が多い傾向にあるように感じる。
大きくない機能なので、優先度だけ割り振るから、どこか時間を作ってやってという、作業者の裁量が有りすぎる管理(笑)がされる傾向にあった気がする。
そう考えてみると、そもそもスケジュール管理の方法がおかしいと、このような優先度とかいうアルファベットが入り込む余地を与えてしまうのかなという仮定に行きついた。
開発途中だろうが、バグだろうが、追加実装だろうが、全て行う必要がある作業であれば、それを全てスケジュールに組み込んで期日を指定するのが、正しいスケジュール管理であろう。
逆に言えば、このような意味不明なアルファベットの優先順位が出てきているプロジェクトは、スケジュールに落とし込まれていない=スケジュール管理が正常にされていない可能性が極めて高い。
〇余談
ちなみに、聞いたら気を付けなければならない表現方法として
「~までに、必須ではない」
という物がある。
「~までに、必須である」なら、期日までに何かを行わなければならないというのが、はっきりとわかるが、
「~までに、必須ではない」だと、いかようにも解釈可能である。
・次の締切までには要らないけど、最終的には作業が必須
・別になくてもいい
などだ。
なので、このような表現をされたら、やはり、やるのかやらないのか方針をきちんと決める事だ。決められないのであれば、やる物としてスケジュールに記載しておくのが、正しリスクヘッジという物であろう。
そして、この表現を何の躊躇もなく使う人間には気を付けた方がいい。
「(やるやらない)どっちでもいい」とか言ってくる人も同様だ。
他業種の方からしてみると、なんてレベルの低い話をしているのだろうと思われるかもしれないが、10年間大小そこそこの数のプロジェクトに従事してきても、このような所から意識しなければならない事が多かった。ゲーム業界が全てこんなのだというつもりもないが、これも数多有るしょうもない話の一つとして楽しんでいただければ幸いである。