今日はこのへんで

Webエンジニア。プログラミング、スタートアップについて。もしくはただの雑記。

Rebuild #171 Muscle Memory を聴いた

一周遅れで Rebuild: 171: Psychologically Safe Podcast (naoya) を聴いた。

Rebuild.fm はなんだかんだNaoya Itoさんが出ているときが一番好きかもしれない。マネジメントの話は勉強になるし、流行りの技術も好きなのでNaoyaさんの触ってみた系の話は面白い。僕も去年ちょうどPythonによるデータ分析入門を読んでPandasを使っていたので、今年はエセData Scientistが湧くという予言に、これは僕のことだな、なんて思ったりもした。

話のなかで少し気になったのが、後半のNaoyaさんの話だった(話は01:09:00あたりから)。業績を上げることが目的である会社という組織で、職場の環境を良くすることを優先しすぎること、そしてそれによってプロジェクトが進まず業績が上がらないという状況はどうなのか、という話だったと思う。(正しいニュアンスか自信がないが、僕はそう理解した。)

※ここから先、マネジメントをしたことがない人間が雰囲気で書いています。ご注意ください。

自由を与えることの意味

社員に自由を与えて心理的安全性が担保されると生産性が上がる、という話はGoogleの人事トップが書いた ワーク・ルールズ!―君の生き方とリーダーシップを変える という本に書いてあって、おそらくNaoyaさんの言っていた日経の記事なんかもこれが元になっている。

ここで言う「自由を与える」や「心理的安全性を担保する」というのは社員やマネージャに好き勝手なことをやらせるという意味ではなく、役職や権限に関わらずチームのメンバーを信頼し、会話の仕方や会社のルールを工夫することで会社の透明性や個人の自主性を尊重するように努力することを意味する。

また、チームの心理的安全性については、ソニックガーデンの倉貫さんもブログに書いている。

心理的安全性の高いチームを作るための取り組み | Social Change!

なぜ生産性を高めるのか

そもそもなぜ生産性を高めるのかを言われれば、同じ時間でよりたくさんのタスクを終わらせるためであって、エンジニアに限ればより多くの時間を実装に使えるようにするためだと思う。

よりたくさんのタスクがこなせるようになると、より早く顧客に価値を届けることができて、これが結果的により良い業績につながる。逆に言うと、顧客の価値とならないタスク(これにはリファクタリングなどを含む)をどれだけやっても業績は伸びない。

だから、生産性を高めるためにエンジニアのリソースを使ってリファクタリングや作業フローの改善をすることは、それ自体は業績に寄与しないし、自身の心理的安全性を盾にそれを勝手に行うことも間違っている。

では技術的負債の返済は悪なのか、と言われれば、悪ではない。やらなければならないときも必ずでてくる。ただし、顧客に価値を届けることを無視して自分たちのために時間を使いすぎてはだめだということ。技術的負債を返済するという判断は、事業や経営に関わる機能実装のコストやタイミングとのトレードオフでやるべきであって、エンジニアや下位のマネージャが勝手な判断でやって良いものではない。

自由を与えつつ社員の暴走を止めるには

社員のなかには、どうしてもリファクタリングをやりたい、やるべきだという人もいるかもしれない。そのときがマネージャの腕の見せ所で、きちんとそういった意見を 1 on 1 で引き出しつつ、今やらなければいけないことを伝えて理解してもらうことが大切だと思う。(やったことないけど)

1 on 1 の方法論については、最近、東京大学産学協創推進本部の馬田さんがとても良いエントリを書いていたので見ると良い。

効果的な 1 on 1 ミーティングのためにマネージャができること – Medium

そして、それでも暴走しがちな社員を止めるには、きちんとやるべきことを社員と約束することが必要になる。これにはGoogleが採用していることで有名な目標管理手法であるOKRを使う。

OKRでは、Objective(目標)とKey Results(主な結果)を四半期の始めに握り、四半期の終わりにKey Resultsの達成度合いで社員を評価する。

大切なことの一つは、決めたObjectiveをきちんとやりきる(またはやりきらせる)ために、Objectiveを決めるときにはマネージャと社員の両者に納得感があること。もう一つは、Key Resultsは評価しやすいように定量的に設定したうえで、それにとらわれずプロセスも評価することだ。

より詳細はVCの前田ヒロさんが非常にわかりやすくまとめている。

OKR (目標と主な結果) – 前田ヒロ

このOKRをきちんと期初に決めておけば、社員が暴走し始めても「君の今やるべきことはこれでしょ」と伝えて納得してもらえるはずだと思う。そして、もしその暴走の内容が社員が本当にやりたいことで、会社のためになると感じていることであれば、次の期のObjectiveに設定して、やってもらうこともできる。もちろんそのときには、Key Resultsとなる生産性(例えばエンジニアのVelocity)を計測したり、施策の対象となる社員に対してアンケートをとったりして、期末に結果をレポートしてもらったうえでマネージャーがそれを定量的に評価する。そうすることで、会社と社員の良い関係が構築できると思う。


Rebuild.fm ではOKRには触れられていなかったので、補足になればと思いブログに書いてみた。

自分もエンジニアなので、古いものを新しいものに置き換えたり、色々試すことはやってしまいがちだけれど、改めてこういうことを意識して、自分の関わる事業を成長させていければと思う。

キン肉マン 1 (ジャンプコミックス)

キン肉マン 1 (ジャンプコミックス)

ワーク・ルールズ!―君の生き方とリーダーシップを変える

ワーク・ルールズ!―君の生き方とリーダーシップを変える