クラウドワークスでのエンジニアリングマネージャーとしての歩み - クラウドワークス エンジニアブログ

クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

クラウドワークスでのエンジニアリングマネージャーとしての歩み

クラウドワークスのテクノロジーエクセレンスグループSREチームでマネージャーをしているbayashi_okです。

今回はエンジニアリングマネージャーになってからやってきた取り組みを一部紹介しようと思います。

まず少し自己紹介をすると、前職では同じく事業会社でSREをしており、チームの立ち上げから行い、マネージャーとして各サービスのインフラ整備や自動化などを行ってきました。

現職への入社は約4年前で入社時は再びSREチームメンバーとして業務を行ってきました。
そして1年半前に再びマネージャーに戻ることとなりました。

現在はテクノロジーエクセレンスグループというグループで

  • crowdworks.jpのSREチーム
  • 組織横断を視野に入れたチーム

のマネージャーをするとともに、crowdworks.jpのプロダクトマネジメントチームのサポートも行っています。

なぜ再びエンジニアリングマネージャーとなったのか

入社当時SREチームに入って感じたこととしては以下のようなものがありました。

  • ちゃんとSREしている
  • 優秀なエンジニアが多く、最小限の会話での意思疎通が図れる
  • Terraformでの構成管理の仕組みが整っている

個人的にはまさに理想の環境でしばらくは悠々自適に暮らしていました。
しかしチームに馴染め、組織を見渡していると違和感を感じるとともに、状況変化していく中での課題なども見えてきました。

当時私の感じていた課題としては以下のようなものがありました。

  • エンジニアリングマネージャーの人数が少なくなり、負担が増えていた
  • 施策を行う際のステークホルダーとの連携がうまく仕組み化できていなかった
  • データ分析周りにおける分析環境が一部形骸化していた

個人的にはSREはサイト全体の信頼性を上げていかないといけないという思いがあり、
SREチーム自体がうまく回っていてもプロダクト全体できちんと機能できていないと意味ないのではという前提の元、転職時はしばらくはなるまいと思っていたエンジニアリングマネージャーに再チャレンジすることとなりました。

エンジニアリングマネージャーになって感じた課題

実際にエンジニアリングマネージャーになってみると様々な課題がありました。

  1. マネージャーの事務作業の多さ
  2. エンジニア不在チームとの密な連携不足
  3. データ分析周りの専任担当者の不在

これらを改善するために周りの人たちと協力もあり様々な取り組みをしていきました。

1. マネージャーの事務作業の多さ

マネージャーの事務作業が膨大にあるとともに、手順やドキュメントが散乱しておりその都度判断や脳内の記憶を頼りに実務がこなされているという状況でした。

またエンジニアメンバーに対してマネージャーの数もたりていなかったため、新たにマネージャーの採用を行うとともに、 マネージャーの事務作業のインデックス・ドキュメント化を進めました。

具体的な作業としては

  • 提携作業をテンプレートに落とし込み手順化
  • Notionを使用してインデックスを作るとともに不足部分もドキュメント化するように実施
  • 新任マネージャーが来たときにどの程度理解したかを見れるように見える化

と言ったようなことをし定型タスク一覧を作りました。

また、エンジニアリングマネージャーも採用で1名、社内からも1名増え体制も以前より強固になっていきました。

2. エンジニア不在チームとの密な連携不足

各チームの取り組みを見ていくと、エンジニアやプロダクトオーナーを中心に施策が進んでいますが、 ビジネス・マーケーティング周りや、ユーザサポートなど当時エンジニア不在のチームとの連携を行う施策が希薄になっているように見えました。

この課題を深ぼっていくと、現場というよりはもう少し上のレイヤーでの課題が大きいことがわかりました。 そのため提案と課題をまとめた資料を経営会議に持っていきでプレゼンを行いました。

その結果、プロダクト顧問を雇用し改めてプロダクトの課題を見える化するとともに、顧問の方と協力し、驚き最小会議を開催していきました。

驚き最小会議とは、結城浩さんの「驚き、最小の法則」を元にしています。

https://www.hyuki.com/kokoro/#surprise

「驚き、最小の法則」というのは、 仕事を円滑に(人間関係を円滑に)進めるには「相手の驚き」を最小にすることが大切だ、 という法則です。

これらを元になぜこの会議を開催するのかという所からを各代表者にも開示していきました。

驚き最小会議の中身としては、単純に見える化すればよいというわけではなく、
何をどの段階で共有すれば驚かずに済み、かつ共有のコストをかけすぎずに済むか、施策ごとに以下の「状態」に分けて共有を行うようにしていきました。

  • (a) 「生煮え」:発生ベースで、各事業機能を担うリーダーが挙げる。「まだどうなるか分からないけど、多分他に影響出てくる」と思しきレベルのもの
  • (b) 「やっていき」:各事業機能チームで実現したい感が高まったときの状態。チーム内で合意形成されつつある事案
  • (c) 「のっていき」:驚き最小会議で「やりましょう。」と合意できたときの状態
  • (d)「取り組み中」:「のっていき」が着手されたときの状態
  • (e)「終わり」:取り組み終えた状態

結果、エンジニアがいない組織との距離やサービスへの理解も深まるとともに、チーム間での自己開示や他者理解を深めていくために重要な会議となっていきました。

ユーザサポートやマーケティングチームなどとの連携強化を行い、新しくエンジニアリングチームも発足することができました。

また、経営層としてもこの驚き最小会議を元に、驚き最小経営バックログという形で、 経営層の考えていることをマネージャーにデンタツする会も新たに生まれるようになりました。

3. データ分析周りの専任担当者の不在

こちらはビジネス観点の施策の実施が行われているのですが、データ分析が進んでおらず施策の結果、正確な成果が出ているのかが不明な状態になっていました。

以前書いたブログでも少し触れていますがCWのデータ基盤においては

  • 長年の運用も相まって古くからのクエリがいくつも動き続けており、取得データの有用性などの価値判断が行いにくくなっている
  • 分析用のDBであるRedshiftから派生するデータマートもいくつか存在し、これらも管理体制の整備が必要になってきている

といった課題がありました。

engineer.crowdworks.jp

こちらについてもその後、データアナリストの採用が進み、 記事での紹介もされているデータアナリストの力もありデータの力による意思決定に力を入れるような動きになってきました。

note.com

また正式にデータエンジニアの採用も開始し、新たなデータ分析基盤の構想も生まれてきました。

このあたりの話を詳しく聞きたい方は是非カジュアル面談や応募をしてみてください。

herp.careers

今後について

まず、これらの取り組みは自分だけでやってきたものではなく周りの働きや協力によるものが多く、いつもお世話になっている皆さんには本当に感謝をしております。

しかし、今現在においても圧倒的にリソースが足りないという状況は変わりません。

今後必要になってくる取り組みとしても上で話したような要素を踏まえて以下のような動きを行っていく予定です。

  • 採用計画も含めた経営層に向けての再接合
  • 会社全体を見据えたデータ分析基盤構築のフォロー
  • プロダクトマネジメントの強化

そのためにも先ほど紹介したようなデータエンジニア及びプロダクトオーナーの力が必要になってきます。

もし興味ある人は是非こちらまで応募をお願いします。

herp.careers herp.careers

最後に

私が当初クラウドワークスに転職した時の目標としては「ちゃんとSREをやる」ということで、現状もそれができている状況です。 しかし私の今の目標としては「ちゃんとプロダクトをやる」というところに置き換わってきたような気がしています。

こういった変化の機会を与えてくれる環境に身を置くことができたのは、自分の視野や視座を広げるうえでとても良かったことだと思っています。

しかしまだまだエンジニアリングマネージャーとしての力不足は否めないためこれからも精一杯努力し、メンバーやサービスや会社、共にいい方向に向かっていけるよう頑張っていきたいと思います。

© 2016 CrowdWorks, Inc., All rights reserved.