この話、誰に言っても通じない話なのですが、
かつての名作にストリートファイター2ってゲームありますよね。
僕は、そんなに得意なゲームじゃないんですけど、ゲームセンターの対戦プレイでこれをやると喧嘩になるという戦い方があるそうです。
それが、
「最速の足払いをひたすら使って、相手の大技を封じる」
というものです。スト2が面白いのは、大技は相手に巨大なダメージを与えられますが、技を繰り広げる前に、ちょっとしたダメージしか与えられない小技である足払いを食らうと、大技が出せなくなってしまう作りになっています。
それ故に、ひたすら足払いで防御することで、相手に徐々にダメージを与えていくという技があります。
何せ、技を出そうとすると、足払いで潰されるわけですから、姑息な技とイライラされるので、対戦で足払いで勝つと喧嘩になることもあるそうです。
似たようなことが、僕らの日常のタスクマネジメントにおいても、起きていませんか?というのがこの記事の趣旨。
管理職や経営者が、大きなことを思考したり、開発者が大きな開発作業には集中する時間が必要です。ところが、トラブルや運用などで発生する日常タスクである「足払いタスク」のようなものがどんどんやってくると、ついついそっちに集中力が持って行かれます。
何せ、足払いタスクは、目の前で困っている誰かがいる可能性が高いので、そういう人たちの困り事を解決してあげたくなるのは人情というものです。
それ故に、小技タスクをついつい優先してしまうわけですが、ふと気がついてみると、時間だけ過ぎて、大切な大技が出せなくなっている自分がいます。
もし、あなたが大技を出すべき役職、役割であれば、これは赤信号かもしれないです。日常の問題に気を取られるあまり、本当にあなたがやらなくてはいけない、将来に繋がるようなことができなくなっているかもしれません。
こうなっているときは、小技を封じるように動くことであったり、小技を誰かに移譲することに精力を傾けないと、本当に将来がヤバイことになるかもしれません。
開発においても、小さな工数の改善チケットと、大きな工数がかかる開発タスクは、これまた相性が悪いです。ついつい小さな改善チケットを優先すると、あっという間に時間を費やしてしまったり、逆に、大きな工数のタスクを優先して、小さな改善が全然できなくなっていたり。うまくタイムマネジメントするという手もありますが、これは、すっぱりチームのラインを分けてしまうほうが合理的ですね。
タスクの優先順位設定は、サービス全体のKPIを伸ばすタスクなのか?システムを守るための改善タスクなのか?技術的負債の返済なのか?応用の効かない特定顧客向けのカスタマイズなのか?など、それぞれのタスクの向かっているベクトルと、その作業量の粒度が違うのに、無理やりシリアライズしようとしても、何せステークホルダーが違う可能性がある以上、適切な優先順位が設定できないことも多々あります。結局、目の前の営業の約束がー、とか、社長が言ったからー、などと目の前にある状況に振り回されてしまったり、逆に、自分たちの視界を優先しすぎてコンサバに進みすぎていて事業が全く進まない状況になってしまったりと、会社それぞれの文化に依存したタスクマネジメントになりがちです。
基本は「肉も食べたら野菜もね」なんですが、それも3つ4つも論点があると、溢れるものもでてきてしまいます。防御側の大技の代表例であるセキュリティ管理issueのように、一旦、やりすごそうと思えばやりすごせてしまうタスクがおざなりになるのが一番怖いです。一度、後回しになったタスクは、よほどの決断力を持たないと上位にすることはできません。上位にするのがセキュリティ問題が発覚した時ともなってしまったら目も当てられないです。
もし、これがどうしてもままならない、というのであれば、もう作業ラインをパラレルで走らせるしか手がないかなと思ったりします。
進むべきベクトル毎にチームを分けて、気持よく優先順位をシリアライズ可能な状況を作るしかない。
これらのような状況から、ついつい、足払いタスクと、大技タスクは相性が悪い、という表現をしてしまいます。
残念ながら、周りの人たちに共有可能なメンタルモデルがないようで、理解はしてもらえないのですが(笑)
なんか一人でも共感してくれる人がいたらいいなぁと思って、思い切って書いてみました。また、是非、いい解決方法があったら教えてほしいです。
【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください