1時に寝て7時に起きた。

煩雑な検証

昨日の続き。午前中に pr を作成してレビューしてもらってマージしてデプロイして検証した。いくつか既存の設計には課題があると思いつつ、工数かけて直してくれという依頼は来ないのもわかっていて、煩雑なコードに煩雑な検証をやるだけにとどめた。テスト環境での検証自体は成功したので問題はなさそう。一部、本番環境でないと検証できないらしい。

会社のテックブログ談義

最高のテックブログを書くために気をつけている3つのこと というブログ記事をみかけた。内容はとても素晴らしいと思う。一方で会社のテックブログでこんな品質を求められたら、品質を満たせない執筆者のモチベーションを阻害しないかということがやや気になった。そんなもやもやを、こみやさんとまさひとさんに共有したらテックブログ談義が始まっておもしろかったのでまとめておく。会社のテックブログと言えばクラスメソッドさんが有名なので引用する。

もちろん弊社では、ブログを書くことを業務上の成果としても評価していますので、このブログを書くこと自体が評価につながるモチベーションになっています。

どのように評価をしているかと言うと、1つは本数という指標です。弊社では月4本エンジニアがブログを書くことを推奨しています。これは罰則はないので、書けていないからといって減点をすることはありません。逆に書いてるからといって加点をすることもありませんが、月4本を推奨していますし、10本書く人は高評価ということで「ブログのプロ」と呼ばれることがあります(笑)。その月は「10本書いたからプロになったね」というようなことを社内で言われたりします。

業務上の評価ということで、先ほど「減点・加点しないよ」というお話をしたんですが、3ヶ月に1回、ブログの本数とSNSのシェア数とビュー数が多い人に対して表彰をしています。やはり継続的にアウトプットをしているとこういった場面で表彰される機会も増えるので、社内でも「この人はたくさんブログを書いてるんだ」「この人はすごく高いスキルを持ってるんだ」と認められ、評価にもつながります。もちろん上司からも、技術ブログを書いてアウトプットが多いことが高い信頼につながります。

なぜ技術ブログを書きまくるのか? 『Developers.IO』のクラスメソッドが伝える、エンジニアの成長サイクル

みよ!この評価しているのか、していないのか、はっきりしない曖昧な制度設計を!

「テックブログは開発者がやるべき業務とみなしていますか?」と尋ねると、多くの会社では業務時間に書いてもよいけど必須でもノルマでもないみたいな答えが返ってくるのではないだろうか。業務に含めたくないのは、本質的に優先度の低い業務だという事実と、一定以上のコストをかけてまでテックブログに価値があると会社も考えていないのではないかと思う。業務とは言い難いので区別のためにここではテックブログを書くという 活動 と呼ぼう。

そして、個人のモチベーションに期待した活動を安易に評価の対象にするのは想像以上に厄介な制度設計になる。メタ認知で〈学ぶ力〉を高める:認知心理学が解き明かす効果的学習法 を読んで私は理解できたことなんだけど、おそらくクラスメソッドさんの (曖昧にみえる) 制度設計の裏には認知心理学の知見がある。

  • 外発的動機づけ: 金銭や物品などの物的報酬、よい評価を得るといった社会的報酬など
  • 内発的動機づけ: 自分がそれをしたいからする、知的好奇心など

外発的動機づけは内発的動機づけと比べてずっと弱い動機づけであることがわかっている。ここで外発的動機づけの業務から始めて内発的動機づけの活動に変わっていくこと自体は問題ない。スクラムで言及している自己組織化や自律的な行動というのは内発動機づけによる活動に変わっていくことを期待している。会社の制度設計として難しいのはこの逆はよくないという話しがある。内発動機づけで行動していた活動を外発的動機づけに置き換えてしまうことだ。テックブログのような、本人が自己学習やアウトプットを目的に自律的にやっていた活動に、安易に金銭的な報酬を与えてしまうと、お金のためにやっている業務に置き換わってしまってやる気をなくしてしまうという懸念がある。余談だが、褒めることそのものは副作用のない安全な報酬と認知心理学の研究からわかっているらしい。クラスメソッドさんが表彰という制度設計にしているのは、本人のやる気をなくしてしまわない報酬を考慮しているからかもしれない。

またコンテンツの所有権という側面からテックブログは会社のものだから、自身のブランディング戦略とは相性がよくない。これは 限定合理性 の話しとも関係してくる。開発者に限らないが、転職を当たり前にする時代で個人ブログに記事を書く方が開発者にとってのメリットがある。「会社ブログに書く動機はなにか?」は、人それぞれの理由があるだろうけれど、その理由が明確でないと消極的に会社ブログは書かないという帰結になるのではないか。私の経験則においても、会社のテックブログを書く開発者は圧倒的に少数である。私は過去に会社のテックブログを書いてきたモチベーションは単純にアウトプットすることで自身の勉強になるなら書く場所はどこでもよいという考えがあった。補足としては、会社の利益 (採用) に貢献しようとか、会社のテックブログを書く開発者が少ないという希少性に着目して自身をアピールするとか、そういった考えもあったと思う。

若い開発者にアウトプットする習慣を付けてもらう取っ掛かりとしてテックブログはよいのではないかという話題も出た。開発者のスキルアップのために会社がどこまでコストをかけてサポートするかという話題でもある。その延長上に評価制度もあるなぁと voyage さんの技術力評価会の資料もみてたりした。会社のイベントや業務を通じて、自然とアウトプットに関するスキルが身に付いて行動できるようになるなら本人のキャリアにとってもよいことではある。私は 書く という行為は開発文化から影響を受ける側面が強いと考えていたけど、voyage さんの制度はその下地を組織として支えていく仕組みになっているのかもしれない。