はぜにっき

日記です。(毎日更新ではない)

Re: 成果、売上、数値至上主義が苦手な理由が言語化できたっぽいのでメモる

前提:

hazediary.hateblo.jp

この2年で、考え方が変わってきたので書いておく。


もくじ


標数字と状態目標(ミッション)の関係

2年の変化を一行で言うと、
「このミッションを達成するには会社がこの状態にならないといけないので、そのために今年必要な数字はこれです!」が理解できれば、自分は目標数字に向かって進めることがわかった。
状態目標があって、そこに行くために必要なチェックポイントとして数字がある という構造が大切で、状態目標そのものが数字だったり、状態目標と目標数字が繋がっていない場合は、そこにモチベーションは生まれない。

資本主義経済の上で、事業会社の目的は「売上・利益を上げること」になる(と思う)んだけど、そこに突っ走る企業で働く気がなくて、何かしらの崇高なミッションのもとで、納得して働きたい。

大元の目標数字や成果の定義が大元のプロダクトを作る目的と合致していれば(=OKRのObjectiveがKey Resulと合致している)良さそう

前のエントリでOKRについて言及をしていた、これがちゃんとできてたら良さそうだと思う。

標数字の必要性についての納得

上の内容を2年前の自分に伝えても(理屈はわかるが)納得はできない、みたいな状態になっていたと思う。
ミッションが存在してチーム全員が同じように前に進めていれば、数字は無くても目標に着実に進めるだろう、と考えていた。

今は目標数字というものが結構大事だと思うようになった。

2年のプロジェクトのマネジメントの経験や、(副業で片手間でやっていたことだが)経営の経験を得た結果に理解した、と解釈している。
プロジェクトのマネジメントでは、 "このプロダクトをXX月にリリースする" というプロジェクトの目標があった時、じゃあこの機能はXX日までに、これはXX月までに出来ている必要がある、という大まかなスケジュールを立てて、それとの差分がどれぐらいあるかで「ゴールできるか」を途中で推測できる。
スクラムにおけるベロシティの概念を使ったもので、バーンダウンチャートがわかるならイメージしやすいと思う。 スクラムのプロジェクトゴールやベロシティはこういう使い方じゃないと思うけど、そこは一旦気にしないで欲しい)

それと同じようなことが経営でも存在していて、「この目標にXX年までにたどり着くには、XX円の売上がこの年で無ければいけない」が目標数字になる。
その理屈に納得が行かない・説明が無い時にモチベーションが下がる。て感じ。

品質基準とビルドトラップの話

目標そのものと少し話は逸れるが、前の記事に書いているので記載。

標数字に進むためには(プロダクト開発をして顧客に使ってもらうビジネスの場合)顧客に満足してお金を喜んで払ってもらう必要があり、そのためにはプロダクトの品質が一定以上でなければならない。
それが満たされていない時に、「品質が足りてないけど顧客に提供して意見を貰ったほうが良い」か「顧客に不満をもたらさないためにリリースを遅らせて品質を上げる」かは事業・経営判断になる。

その判断が適切だったかどうかはわかるときもあるしわからないときもあるけど、「品質足りてないと思ったけど顧客はそこの品質は気にしなかった」パターンもある。必ずしも明らかに品質が悪いと感じる状態でリリースすることが必ず駄目になるわけではない。
また、極端な例だと「リリースが来月に遅れたら会社の金が無くなって倒産する」とかもある。

...て観点が前は無かった気がするなーという振り返り。
開発者としては「作っているものを早く使って満足してもらいたい」と「使ってもらうなら良いものを使ってもらいたい」が両方あり、そこの比率は人によって違うしモノによっても違うので、なんとも言えない。

会社が存続しなければ製品は提供し続けられない / 金が無ければ開発はできない

更に話は逸れるけど書いておきたいので。
前のトピックでも倒産に触れたが、会社がなければ(もちろん例外はあるが)プロダクトは作り続けることができない。
会社の活動は慈善事業ではなく、経済活動のために行われているので、顧客が喜ぶ製品を作れていても、お金が無ければインフラ費用も払えないし、開発するエンジニアの人件費(というか給与)も払うことが出来ない。

かなり前に上長に「我々は慈善事業をやっているわけではない」と言われた意味を理解した。


自分は大元の目的とか課題に向き合って仕事をしたいので、そういう割り切りをしたくない。

プロダクトを作る理由はたいていの場合数字ではなく、社会・人々の課題なので、数字に囚われずちゃんとそこに向き合っていたいですね。

と以前書いたが、2年かけて「割り切りはしなくても良いが、会社として課題に向き合うには数字を使う必要がある」と理解を得た、ということが書きたかったエントリでした。

おわり。