優先度付けの技術

先日参加してきたSCRUM Product Owner Trainingで習ったことのひとつが「製品バックログの優先度付け」。製品バックログとはSCRUM用語で、開発対象の要件をフィーチャ単位で書き出したものだ。この製品バックログに優先度をつけて、高い優先度のものから順次開発していく。

優先度と「いうのはタダ」な説明責任

ところが、この優先度というのはなかなか簡単につけられるものではない。その組織が恐怖の独裁体制で、トップが「これでいけ」と言ったら配下がいっせいに「はは〜」と動くのなら別だけど[*1]実際には関係者間の利害関係が重なり、なかなか調整が難しい。

自分が日本で開発にかかわっていた頃に経験した話。ある情報分析系システムを古い基盤から新しい基盤に移す際に、不要な分析ロジックを廃棄しようということになった。明らかに使われていない分析ロジックがごろごろしていて、これらがCPU/Disk性能の大半を奪っていたのは確実だったから。

お客さんは総論賛成だったのだけど、実際にどの機能を削るかという段階になってからは揉めに揉めた。自分達の業務に関わる可能性のある部分は「残してくれ」というのみ。結局、全部に残してくれ、というフラグがついた。

いざ、という時に「なぜ、この機能を削ったのだ。削ると言い出したのは誰だ！」と後ろ指差し合戦が始まることを予想したのであろう。そうならないために「全部残して」と反応する。これは当然かもしれない。だって、「残して」というのはタダなんだから。

仮想通貨を与える

SPOTで習ってきたのは、この優先度付けに「仮想通貨」を与えること。まず、製品バックログ毎に開発量を見積もる。見積もり方法については気が向いたらあとで書くけど、仮想通貨で「１００カノッサ」「１０００カノッサ」みたいに規模を数値化していくわけだ。

そして、優先度をつける側に、仮想通貨を与える。合計１００００カノッサしかわがままをいえない状態にすれば、「あれもこれも」ということはなくなる。まずは優先度の高いものが見えてきて、それらが開発される。一通り開発のめどがついたら、次の「入札」を行えばよい。こうして、優先度の低いものに順番が回ってきた段階で「冷静に考えたら、こいつらいらないな」と判断されるかもしれないし、「やっぱり開発して」となるかもしれない。

大事なことは「いうのはタダ」という状態からの脱却。これが優先度付けの鍵であろう。

残業削減にも使えるかも

どうしたらいいんだろうね（３）でt-miyazawaさんからいただいたコメント。

できるヤツから潰されるに書いてある『「これが先！」「緊急！」「最優先！」のインタラプトが乱舞』、これに近い「トラブル対応だから」がある種伝家の宝刀になっている気がしています。というか、この間それがあったです。端的に言うと、トラブル対応の遅れを部分的に挽回させられました。しかもその遅れは人為的ミスです。作業しながら真実を知った時はむかつきましたよ。しかも指示が出たのが21時過ぎで、翌日午前中まで、という酷い時間指定付き。

普段の作業も、SCRUM的に「定量化」されていると良いのだろうね。そして、緊急時対応は（さらに深夜対応は）割り増し請求をかける。

「あなたが要求している緊急対応は、普段は５０カノッサですが、緊急＋深夜割り増しで１４０カノッサとなります。この分は、明日以降割り当てられているタスクから相殺することになりますが、どのタスクを後回しにするか決めてください。それからでないと緊急対応しません。」みたいにPMと折衝するわけよ。

まあ、このような「対決」の姿勢はSCRUM（あるいはAgile）としてはよろしくない。チーム一丸となって質の高いシステムを開発し、トラブル対応の頻度を減らすのが本来のAgileというもの。でも、一歩とびにその世界を実現できるとは思えないので、当面は作業量調整のために、上記仮想通貨の概念を導入するのは悪いことではなかろう。

緊急対応ばっかりで本来の作業がおざなりになることが、次のトラブルの種を撒いていることに他ならないのだから。

*1:まあ、そういうところはトップがこけたらぜんぶコケるのも怖いところ。NOVAとか。