どの組織に行っても「今年の目標数字はXX円です」とかそういう話に興味が持てなかったり、数値目標ベースで仕事を進めていくとモチベが下がりまくる現象の理由を考えていて、うまいこと言葉に落とせた気がするので残しておく
なるほど / 他3件のコメント https://t.co/qwj9AFgr1x “トラブル対応は全く無駄 - 最速配信研究会(@yamaz)” (6 users) https://t.co/bz5Uh96u3D
— はぜ(Sho Tokuda) (@haze_it_ac) 2021年2月20日
最近"早く使ってもらった方が良い"っていう話に対して違和感を持つようになっていて、早く使ってもらうようにするために犠牲にしているもののほうが大きいのでは?というのを感じているからな気がする
— はぜ(Sho Tokuda) (@haze_it_ac) 2021年2月20日
不確定のものを予測して動いたり、対応しないといけないものを後回しにしたりすることが多くて、結局完成度の低いものを使ってもらう状態になったり、トラブルで結局後ろ倒しになったりするので良いものを正確に作ってデリバリする方向もありなのでは
— はぜ(Sho Tokuda) (@haze_it_ac) 2021年2月20日
品質基準が定まってないことが問題な気がしてきたな
— はぜ(Sho Tokuda) (@haze_it_ac) 2021年2月20日
シンプルに "はよリリースしろ" っていう雰囲気と圧力があって、満足して開発し切っていない状態でリリースしているっていう話だ
— はぜ(Sho Tokuda) (@haze_it_ac) 2021年2月20日
スケジュールを立ててそれが遅れている状態に、正常な判断ができなくなって後から文句出るパターン
成果物の出来よりも目先の消化ポイントを優先している問題 ビルドトラップじゃん
— はぜ(Sho Tokuda) (@haze_it_ac) 2021年2月20日
結局 "(成果|数値)をあげよう"という命題と雰囲気に組織が飲まれると良くないという話な気がしていて、全社レベルの組織課題っぽい
— はぜ(Sho Tokuda) (@haze_it_ac) 2021年2月20日
「成果物に微妙に不満があるけど(早くすればするほど成果に繋がるから|目標の達成のために|組んだスケジュールから遅れないために)リリースする」という状態がよろしくない。
違う軸で "成果や数字のためにはなるけどユーザ|ブランド目線ではないもの" を作ったりするときもまあしんどい。大元は同じ話。
大元の目標数字や成果の定義が大元のプロダクトを作る目的と合致していれば(=OKRのObjectiveがKey Resulと合致している)良さそうだけど、それがちゃんと定義・運用できていて、全体で合意が取れていて納得している状態って現実的に作れるんだろうか。
割り切って "プログラマは目の前の仕様を淡々にいかに早く良く作れるかだけを考えれば良い" とも思うんだけど、自社でプロダクト作っている会社だと大体目標とか目的とかそういうのに向き合う必要がある。そして前述のもやっとする話になる。
というか自分は大元の目的とか課題に向き合って仕事をしたいので、そういう割り切りをしたくない。
ある程度の規模以上の出来上がった組織だと、どう頑張ってもこの問題に当たると思うのでこれから組織を少しずつ大きくしていく未完成の組織に移る選択をしたんだと思う。
10人未満の事業部でどうなるか、どうすればこの課題を何とかできるかは4月から考えていきたい。
プロダクトを作る理由はたいていの場合数字ではなく、社会・人々の課題なので、数字に囚われずちゃんとそこに向き合っていたいですね。