エンジニアだけが優遇されるのではない組織をつくりたい

※ 2つの意味で解釈できるようなタイトルだった*1ため、より伝えたいことが明確になるタイトルに訂正しました。ご指摘いただいた皆様ありがとうございました。お詫び申し上げます

この記事はEngineering Manager Advent Calendar 2019の17日目の記事です。

手前味噌だが、所属している会社のエンジニア組織はだいぶ良い感じになってきているという自負がある。最近書いた自社のブログのエントリも多くの方に共感いただいた。 hackerslab.aktsk.jp 一つ一つの組織活動に対してこれって本当にあるべき姿なんだっけというのを問い続けながら地道な改善を続け、組織としての練度が大分高まってきた。 結果として、自社のあらゆる組織の中で、エンジニア組織は一番改善が進んでいる。*2

一方で、そこはかとなく、「このままで良いんだろうか」というモヤモヤがある。

会社はエンジニアのためにあるのか？

「エンジニアが働きやすくするのが会社にとって一番大事だ」という話を良く聞く。 私がこれを聞く度に、エンジニアが特別扱いされ、優遇される世界にどうしても違和感を持ってしまう。 なぜなら、会社にはエンジニア以外の職種が必ず在籍して、各々が各々の職務を全うした結果、プロダクトやサービスが提供出来ているからだ。 この事実を忘れて、「エンジニアは特別だ」なんてことはとても言えたものではない。

しかも、CTOやVP of Engineering(VPoE)、Engineering Manager(EM)のみならず、人事だったり社長がこの発言をしている場合もある。 自分が、あるいは、自分の所属している組織全体が働きやすくなるのも同列一番にして良いはずなのに、なぜエンジニアだけ優遇しようと発言しているのか理解出来ない。

私のモヤモヤの源泉は、自社でエンジニア組織だけが改善が進んだ状態に対してだ。 もちろん、これはこれで私自身が私の職務を全うした結果なのだが、エンジニアだけ働きやすくなるのは目指したい理想の組織の状態ではない。 組織に所属している全員が働きやすくなるのが、私にとって理想の組織の状態だ。

同じようなことがNETFLIXの本にも書いてあった。

NETFLIXの最強人事戦略 自由と責任の文化を築く

自社のエンジニア組織の改善は様々な議論の結果である

もちろん私も足りていないマネージメントの知識はたくさんある。 広木さんやEM.FMのゲストに来てくださった方々と話すと、自分の知識の浅さ・狭さを恥ずかしく思うことが正直ある。 それでも、なんとか食いつこうとここ数年マネージメント領域にコミットメントしてきたし、色々な社内外の方々とも議論させていただいた。 その学んだやり方をどう組織に適合させるかを考えぬき、実験しながら少しずつ組み込んでいったので、結果として良い感じにエンジニア組織が構築されていったのだと思う。・・・というと、自分だけの成果のようだが、CTOの組織に対する考え方が何よりも素晴らしかった。Team GeekのHRTを組織が若いうちに取り入れたり、CTOではなくチームに裁量をもたせられるように、適切にチームに権限委譲していた。私はこの考えに乗っかり、add-onしていっただけだ。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

なんとかしたいと思って出来ることをやった

一方でちょっと別の組織を見渡してみると、そんなにうまくいっていないという事実を目の当たりにした。 マイクロマネージメントを常にしていてメンバーが意思を持てないようになっていたり、 シニアマネージャーが適切に権限委譲出来ずにミドルマネージャーが苦しんでいたり、プロフェッショナルな組織と謳って感情を業務に持ち込めないようになっていたり、 マネージャーとメンバーの間でコミュニケーションミスが発生してマネージャーの信頼が意図せず失われたり、という状態が続いていた。

そこで私自身が何か出来ないか、ということで、いろいろやってみた。

組織の問題を議論出来るSlackルームを作った

まずそもそも皆が今の状態って良いんだっけ？と思えるように、組織で起こっている問題を議論するSlackチャンネルを作った。 最初はManagement3.0の本(Managing for Happiness)を輪読して感想を投稿していただけだったが、後にアジャイルコーチが話題を投下したり、 私自身もニュース記事をシェアしたり感想を述べたりしていったら、いつしかそれに反応してレスを返してくれるメンバーが増えていった。 そのチャンネルには12/16時点で、165人がjoinしていて、口コミで今も人が増え続けている。 多分、全体チャンネル系を除けば最もメンバーが多いチャンネルになっていると思う。 今でも1週間に2~3記事ぐらいはシェアされていて、そこから生まれる議論は楽しくて仕方がない。

Managing for Happiness: Games, Tools, and Practices to Motivate Any Team

組織の問題を議論出来るコミュニティを作った

プロダクトを良くするためのマネージメントのやり方をシェアしあわない？というところから7人のEMが集まって、議論をし始めた。 最初の方はアジャイル開発について話したり、EMの採用基準について話していた。 あるとき、もう少しコミュニティとして活動していきたいねということになり、それぞれの持っている価値観をすり合わせ、そこから自分たちは何のために今ここにいるか宣言文を書き、コミュニティの4つの価値観を定義していった。 その後、このコミュニティの価値観に共感したメンバーが5人増え、今ではエンジニアという枠を超えて、どうすれば自分たちのプロダクトが良くなるんだろうか、と話し合っている。

マネージメント勉強会を開催した

今ではもうやっていないのだが、一部のミドルマネージャー・リーダー向けに、マネージメント勉強会を実施した。 お菓子や飲み物を買ってきて、リラックスして話しやすい雰囲気づくりを作り、最近のタイムラインを作って議論してみるとか、ロッシェル・カップさんの本を使ってX理論/Y理論の解説とか、Delegation Boardを作ってみたり、Happiness Doorでフィードバックをもらったりとかやった。 ここでDelegation Boardを10人ぐらいで作ったからなのか、私がDelegation Boardについて社外で何度も発表したからなのかわからないが、 いつしかプロダクトのリーダーの交代時にDelegation Boardをやることが普通になった。 さらにはCEOと事業部長の間のDelegation Boardを作ることになったりと、着実に影響の輪が広がっていく感覚があった。

日本企業の社員は、なぜこんなにもモチベーションが低いのか？

みんなが働きやすくなるように新たな挑戦を決意した

これまでやってきたのは草の根活動だったけれど、今度はもっと直接的に組織の課題に立ち向かえるようにしようと、来年1月から人事部にチームを立ち上げて、VPoEと兼務することになった。 作ったチームの名前は、Organization Development Labというド直球な名前。*3

ラボでやろうと思っていることの第一は、会社全体がより働きやすい場となるように、ODに関する過去の研究結果や他社事例を調査し、それを実現出来るやり方を考え、全社に実験しながら導入していくということだ。 基本は、それが成果として現れたかを定量的に測れるように何らかのメトリクスも導入していく予定だが、そこまで従業員が多いわけではないので、定性的な結果判断も十分ありうる。 理想の状態としてはGoogleのように、何でもデータを取りまくって判断するような世界観だ。

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

ラボでやろうと思っていることの第二は、今会社でやっていることのバックグラウンドのデータなり知識を集結させて言語化していくことだ。 Management3.0の勉強会やポジティブ心理学の勉強会などに出席すると、今の会社でやっていることは先進的であるということはわかるが、残念ながらそのバックグラウンドの知識背景を自分たちの言葉で十分に説明しきれているわけではない。 そこで、他の人事チームと協力して、ここの言語化を推進していく。

ラボでやろうと思っていることの第三は、評価制度の見直しだ。 今の制度はメンバーもマネージャーも多大な工数をかけて評価をしているが、本当にそれが見合った工数なのかを改めて考え直したい。 これも他の人事チームと連携して進めていく予定だ。

その他、ラボの活動というわけではないが、バックオフィスの組織改革の相談役みたいな立ち位置にもなる予定だ。 既に人事部外から相談が来ていて、一緒に変革プロジェクトを進めている。

いずれにしても、このODの知識を広く深くつけていくために、新たな学び直しから始まる。 実は既に少し動き出しているのだが、ストレングス・ファインダーの2つ目の資質である学習欲が刺激されるので、モチベーションにもつながっている。

何をする人なのか

EMとかVPoEの枠を超え、組織全体を変えようとするのはChange Managerなのかもしれない。 学習する組織の

人は変化に抵抗するのではない。変化させられることに抵抗するのだ

という言葉があるように、 変化させられたと思わせるようなやり方ではなく、変化したくなる組織とは何かを追求して、エンジニアだけが優遇されない組織をつくりたい。

学習する組織――システム思考で未来を創造する

*1:元々「エンジニアだけが優遇されない組織をつくりたい」としていたが、これだとエンジニア以外は優遇してエンジニアだけが優遇されない(冷遇する)、とも読めた

*2:ありがたいことに、会社の様々な方もこの事実を認めてくれている

*3:Organization Developmentは良く組織開発と訳されがちだけれど、開発は新しくものを作るという意味合いが強くなってしまう感覚があり、それよりは発展とか発達の方が合っているのではと思ったりしている