@boscoworks です。
この記事は Livesense - 自 Advent Calender 2017 の第13日目です。
2015年、2016年に続き、早いもので3年目の参加です。引き続きお手柔らかにどうぞ。
最近はサーバサイドエンジニアからエンジニアリングマネージャー兼プロダクトマネージャー（どちらも見習い）みたいなポジションにジョブチェンジしました。
今回のテーマは「自」ということで、最近はやりの自己組織化についての話でもしようと思います。
自己組織化ってなに
Developers Summit 2017 Summer(通称:夏サミ2017) にて株式会社エウレカ金子さん(@kaneshin)1、梶原さん(@kajinari)2によるご講演が記憶にあたらしいですが、曰く、自己組織化された状態とは
- チームにスキルがある。もしくはチーム自身でスキルを獲得する方法を知っている
- リーダーは生産性に関与しない
- 自分たちで意思決定できる
- 衝突を内部で解決できる能力を持つ
を指しています。チーム全体が課題感について深く理解し、それぞれが「自分がなすべきこと」を把握し、課題解決に挑む組織。と私は解釈しています。
今となっては恥ずかしい話ですが、夏サミ2017、私もこっそり登壇していた3んですよね。それも組織改善について。ぎゃー。もはや黒歴史
いやはや自らの不勉強を痛感しましたが、同時に良い経験もさせていただきました。
本稿は登壇から半年経っての学びを語ります。
指揮統制型組織は本当に悪だったのか
かの名著「Elastic Leadership」曰く、チームのフェーズは、
- サバイバルモード
- 自己組織化モード
- 学習モード
の3つに区分でき、事業やチームの在り方によってフェーズが違うわけです。
今でこそリブセンスは「自己組織化」への歩みを進めているわけですが、部署によっては最近まで「サバイバル」な組織でした。私が所属している「転職ナビ」の部署がまさにそれにあたりました。4
自己組織化モードが進んだ組織から見ると、「サバイバルモード」にある組織はネガティブに見えがちで、たしかに見方次第ではそうかもしれません（詳細はElastic Leadershipに譲りここでは明言を避けます）。
ただ個人的には、これはこれで良かったところもあったんじゃないかと思っていて、あえて良かった部分をお話します。
職種越境の強化
リブセンスは職種越境型組織5を謳っています。エンジニアはプログラムだけ書いているわけではなくて施策を考えたり効果測定をしたり、営業さんの困っていることを自ら聞きに行ったりします。営業さんもクライアント様の状況を知るためにSQLを書いたりメルマガを考えたりします。「事業のために出来ることをなんでもやろう」の精神はしっかりとリブセンスに根付いています。
指揮統制型組織のなかでは、一つのプロジェクトのなかにいろんな職種が混ざって参加しており、更に全員がリーダーの方を向いているので、課題を通じて相互理解がとても深まりました。業務以外でもめちゃくちゃ仲がよくなったと思っています。
職種をまたいで気心の知れた仲の人がいくらかいると、協力を求めたり求められたりの際に余計なことを考えず条件反射で協力し合える体質になります。
今は自己組織化のフェーズに移行してきていますが、この下地があったからこそ自己組織化への取り組みがうまく行っているようにすら思います。
自己組織化に向けての取り組み
事業責任者と各施策の意思決定を分離
事業責任者が現場まで来ると、何も言わずともどうしても判断を委ねてしまうものです。
現場で自ら考え、自ら判断するには、責任あるポジションが細かな意思決定をせずとも済むよう、権限委譲をする必要がありました。
かく言う私も夏サミ2017登壇の頃は施策の意思決定に参加していましたが、最近では現場のメンバーたちにほとんど丸投げです。代わりに採用だったり、リーダー同士の会議だったり、内部統制だったり、まるっきり別の仕事に打ち込むようになりました。
自己組織化された組織のなかでは、「プロダクトマネージャーとメンバーが上下関係にある」わけではなくて、「プロダクトマネージャーも役割のひとつ」だと思っていて、それぞれが出来ることを精一杯やっているのが、今の転職ナビの開発チームです。
目標設定と評価のフィードバック
チームによってそれぞれだと思っていますが、基本的にクリエイター組織と言うのは売上や利益のような金銭的な目標設定を置かないほうが、より発想が自由になると思っていて、私のチームの皆さんにはほとんど金銭の絡む目標設定をしないでもらっています。例えばこんな感じです：
- エンジニア: 「期日までに◯◯機能を実装しリリースする」「◯◯の要件を満たす機能や仕組みを導入する」
- デザイナー: 「◯◯のデザインを改善する」「◯◯のページのUIを改善する」
- ディレクター: 「◯◯機能のKPIを◯◯%改善する施策を考える」
などなど。ディレクターはさておき、クリエイター職はかなり定性的な評価判断を強いられるわけですが、中長期的な価値創出を加味した品質担保や運用オペレーションはそもそもが定性的です。
これについては模索段階としか言いようがないのですが、誰が評価するにしたって異職種やクリエイター職の評価は難易度が高く、結局は「評価者・被評価者の間で双方納得感のある目標設定であるか」に尽きると思っています。
また、「勉強会やカンファレンスでの登壇」「ブログやQiitaへの投稿」「OSSやコミュニティーへの貢献」といった、チームの外にいる第三者の存在からの評価も、目標設定時に導入できるようにしています。その第三者のほうが、評価者よりもよっぽど特化した知識を持っている可能性が高いのもありますし、なにより社外での取り組みは刺激的で成長につながると経験的に知っているので、このような挑戦をしています。
振り返り会
転職ナビの開発チームは2週間1スプリントの開発体制を導入しています。ガッチガチのスクラム開発ではありません。調べたわけではないけれど、たぶんリブセンス全体を見渡しても、ガッチガチなところは無いように思います。
スプリントの終わりには、メンバー全員を集めて振り返り会を行います。有志でお菓子を買って、できるだけ楽しい雰囲気で振り返ります。6
振り返り会では、以下でご紹介する案件ニュースをもとに「このスプリントで何が起きたか」「次のスプリントで何が起きそうか」を認識合わせしていきます。
案件ニュース
スプリントの終了前に、全員で社内wiki(confluence)の「案件ニュース」というページを更新します。これは私が前職から持ち込んだ文化なのですが、「更新がめんどくさい・時間が持っていかれる」というデメリットに目をつぶれば、そのスプリントに何が起きていたのかが一発でわかるスグレモノです。
- メンバーの今の気持ち
- 本当にみんなそれぞれ下らないことを書くのですが(笑)、明文化されないモチベーションが見え隠れするので良いです
- 完了・未完了タスクの振り返り
- 完了したものはみんなで拍手しあう
- 未完了は未達な事自体を決して責めない。遅れた分を認識合わせする
- リリース物件の確認
- 高速に開発するといつ何をリリースしたかいちいち覚えていられない
- のちのち見返すとこれがとても便利
- CHANGELOG.md とかでも良かったなと最近思います
- インシデント確認
- 中には「もらい事故」等も含まれます
- のちのち見返すとこれがとても便利
- 次のスプリント外のタスク・おやすみ確認
- 2週間あるように見えて実際は10営業日も稼働できないことがほとんど。その具体的な見積もり
- 各メンバーのKPT (Keep/Problem/Try)
- 中に「それ業務と関係ないだろ」が紛れていても気にしない。むしろ上等
- 仕事とプライベート、全部合わせてメンバーそれぞれの生き方が構築されている。みんなでそれを認め合い支え合う自然な空気感を無理強いしない程度に生み出す
終わりに
Qiitaを見ている多くの方がエンジニアだと思いますが、多くのエンジニアは技術が好きでプロダクトが好きな人だと思っています。一方で、多くのエンジニアは技術のみで給料をもらっているわけではなくて、技術力の行使によって事業貢献を果たし給料をもらっているはずです。
そこには多少の摩擦やジレンマがあります。マネージャー職になった今でもそれを感じます。
だからエンジニア主導によるピープル・マネジメントが必要とされるのだと思います。7
私自身決してピープル・マネジメントが得意ではなく、どちらかと言えば失敗経験を色濃く思い出すタイプなのですが、エンジニアのマネジメントという領域にはまだまだ可能性を感じるし、自分自身の成長も感じています。
エンジニアリングマネージャーという仕事がクリエイティブな仕事と認知され、「いつでも誰でも出来るわけではないけど、いつかトライしたい」と思われるような時代が来ることを期待しています。
-
Elastic Leadership 曰く「サバイバルモードでは常に残業している」状態みたいにネガティブに書かれていますが、当時のリーダーが家族煩悩だったこともあり、残業はそんなにしてませんでした。一応名誉のため。 ↩
-
私は甘党なので、私が買うとだいたいチョコレートかクッキーです。夏はアイスクリームが美味しいです ↩
-
能登さん(@noto)のエンジニアリングマネージャーについての記事がまさにドンピシャです ↩