付加価値度と優先度 | mutter
たくさんある業務上の改善点や新機能追加などの各タスクについて、非技術者である社長が優先度を設定した上で、会社に与える利益のインパクトを基準として付加価値度を設定すると言うやり方です。上司がいた頃は、その付加価値度を四半期ベースで集計して待遇の見直しに活用されていたようです。今の僕は決められた時給で働いて賞与もないので全く関係ありませんが。
経営的な視点で見ると、こうした付加価値度の付け方は6割ぐらいは「正しい」と言える方法だと思います。タスクの難易度や工数に応じて付加価値度を付けるのではなくて、あくまで会社に貢献出来たかどうかで評価を上積みするという考え方です。確かにどんなに技術的に素晴らしくても会社の利益にならなければそれは無価値だし、非技術者が技術者を統制する方法としては合理的であろうとは思うのですが、エンジニアの心情的にはその理を飲めない部分もありますよね。特に、その数字の集計が次の四半期の待遇に反映されると言われたら、色々考えることがあります。
例えば「手間がすごく掛かるけど付加価値度が低い案件」というのはやりたくありません。効率が悪いし、手間に見合わない。でも経営判断としてどうしてもそれが必要だと言うこともあるわけです。だから「優先度が最高で難易度も高いけれど付加価値度はとても低い」なんていうタスクも発生します。仮に1週間それにかかりきりになってしまったら、その週稼ぐはずだった付加価値度はゼロになり、苦労して実装したのに待遇としてはマイナスの評価になったみたいなことも起こりえます。だから当然、エンジニア的には反発します。当たり前ですよね。
でもそのエンジニアの反発に対して経営者は「いやこれは会社の利益を基準に設定した数字だから、手間が掛かっても増やすわけにはいかない」と言って突っぱねます。そりゃそうだ、エンジニアからの「これ手間掛かります」に対応していちいち付加価値度を上げていたらキリがないし、会社の利益にならないが手間が掛かる仕事でエンジニアの利益貢献が止まったとしても変わらず給与は支払うわけだから、払うものは既に払っているという感覚です。付加価値度0での給与は既に払っているじゃないかと。それに「手間が掛からないけど付加価値度が高い仕事」だってあるだろと。
まあそりゃ理屈ではそうなんですがね。でも心でも納得出来るか？と言われたら納得出来るわけがないですね。こんなシステムでやってたら、そりゃ永遠にわかりあえないよなあ。そう思って見てたんですけど、結局その部分に於いて最後まで解り合えないまま上司は辞めていったような気がします。経営者としての論理は理解出来るけれども、甘やかさない範囲で気持ち良く仕事をさせるのも必要なことなんじゃないのかな。必要だからやってくれ、ただし評価は出来ない、そしてその評価で次の待遇を考えるっていわれたら気持ち良く仕事出来るわけなんかないじゃん。
どうすりゃいいのか
非技術者が技術者をハンドリングする方法というのはとても悩ましくて、僕もどうやったら良いのかよくわかりません。わかりませんが、今回のように付加価値度と優先度でタスクを管理していく方法を採るのであれば、案件ごとに付加価値度に係数を掛けるべきかなあと思います。係数は優先度に紐付けられていてもいいかも知れませんね。SからDまで5段階あって、Sが最優先、Aが優先、B以下はSとAが無かったら着手出来る、Dはほぼペンディングみたいな状態だったら、Sの場合は係数1.2、Aは1.1、以下B1.0、C0.9、D0.8とかね。そうすることでエンジニア側からは「優先度を上げる=タスクを突っ込まれる」ことに対する対価が支払われるということになりますし、その分が心理的な保証になると思うんですよね。経営者側も優先度を上げる場合のコストが見積もりやすくなる。その程度の係数なら集計も大変ではないと思いますし。
なんつて思うんですけど、多分変わることはないだろうなあ。んで、次入ってきたエンジニアとも揉めるんだろうなあ。この程度のコストで内製出来てることが奇跡に近いですからね。仕方ない。