この記事はクラウドワークスアドベントカレンダー 18日目の記事です。 はじめまして。クラウドワークスでEMを担当をさせていただいている庄司です。
EMは、Engineering Managerの略で、そのままですがエンジニア組織のマネージャでして、具体的にはチーム単位での組織設計やメンバとの1on1等を通じた課題の抽出/取り組みを行い、組織を運営する役割を担っています。 今回はEMとして過ごしてきた中で、いいなと感じたことや、組織としての取り組みについて簡単にご紹介できればと思っています。
内容については、人によってご意見が色々と当然あるかなと思いますが、あくまでも私自身の今までの経験を元にした解釈ですのでそのあたりはご容赦くださいませ。
すごくざっくりと私の経歴を書かせていただきますと、大学時代、片道3時間の通学時間の読書のなかで認知心理学やアフォーダンス、ユーザビリティ等に影響を受けUI周りに興味を持ち、周りがメーカに就職してゆく中、webの開発会社に約20年前に就職しました。…が結局はそちら方向には向かわず、携帯電話のミドルウェア開発のベンチャーで上場含めての様々な開発経験であったり、上場企業の子会社でのゲームプラットフォームの立ち上げや運用、本社での事業立ち上げ等を経験させて頂きました。というようなバックグラウンドを持っております。
そんな経歴の私が、ご縁あってクラウドワークスにお世話になっている訳ですが、Webの世界にどっぷりではなかったエンジニアの視点としてクラウドワークスの雰囲気をお伝え出来ればと思っています。
開発組織で、良いなと思っていること
「発信」が組織に根付いている
まず、入社直後に驚いたのはドキュメントの量でした。プロダクト組織ほぼ全員がQiita Teamのアカウントを持っており、エンジニアに限らずプロダクトに関わるメンバが積極的に記事を書いています。その投稿内容は、サービスの機能説明・仕様・設計の経緯・障害対応の手順に限らず、サービス・システムの課題提起や、取組みへの提案なども含まれています。 私の見える範囲では記事の数は11,530本、Qiita以前に利用されていたConfluenceも含めるとかなりの量の記事が社内に公開されています。ルール化はされていませんが、投稿を皆さんチェックしていて、役割関係なくリアクションやコメントも積極的にされており、それがコミュニケーションの一部になっているように思います。
クラウドワークスには、クラウドワークスの重視する価値観や行動の基本が書かれた「カルチャーブック」という文章があり、その中の一つの項目に下記があります。 「成果＝結果＋伝達」 成果は結果だけでなく伝えることも大切という内容ですが、こういった考え、文化が定着している結果なのかもしれません。 常に新しい情報が投稿され続けることが当たり前になっていることは、すごいことだと思います。
あと、発信という意味では、アドベントカレンダーも自発的にメンバ内で準備を進めてくださいました。エンジニアに限らずPO、デザイナが協力してカレンダーを作り上げているのは、発信に加えて、クラウドワークスっぽい仲の良さが現れているんじゃないのかなと思います。
マルチエンジニアが多い
クラウドワークスはベンチャー企業です。開発自体もベンチャーの空気感があり、フロントエンド、バックエンド、インフラという垣根を超えて触れる機会があります。と言うよりは垣根を超えないと開発出来ない部分も多々あります。
crowdworks.jpは約9年、生き抜いてきたシステムですので、コード量は周辺システムも含めて、かなりの量になります。分業という形もあるかと思いますが、フロントエンドエンジニアだから、バックエンドエンジニアだから等、作業範囲に壁を作らず、積極的に取り組む人が多くいる印象を持っています。 たとえば、たかのさんが以前書かれた記事では、さりげなく書かれてはいますが、広い技術範囲の取り組みをされいることがお分かり頂けると思います。 積極的に学習に取り組む方が多く、合わせて開発の中で、幅広い技術分野や考えに触れることで、自然と幅広い知識を持ち、成長する方が多いのかもしれません。
ちなみに、話は少しずれてしまうのですが、クラウドワークスのPOのみなさんは普通にSQLを書いて日々分析等行っています。個人的にはこれもすごいなと思っています。
課題面で言うと、技術分野の広さは逆に、キャッチアップであったり、オンボーディングの負担や通常の開発/運用での負荷が大きいという課題もありますので、継続的に検討を必要する部分ではあるかとも思います。
リモートワークの知見が多い
今年は、コロナウイルスの影響で、リモートワークという働き方が世の中に浸透した年でした。 クラウドワークスといえば、新しい働き方を提案し続けてきた会社ですが、社内では4年以上前から部分的にリモートワークが導入され、その後、2019年7月からは全社にリモートワーク制度が適用されています。その背景もあり、今年、全社員リモートワークの体制への変更となった際も大きなトラブルなくスムーズに移行ができました。 また、クラウドワークスでは、毎週月曜日の朝に全社200人弱集まる朝会が開催されます。平常時はオフィス内開催で、オンライン参加も可という形でしたが、感染者数の増加を受けて、発表者だけオフィス、後に完全リモートと変わりましたが、こちらも大きなトラブルはなかったと記憶しています。
写真は発表者だけオフィスとなったときの様子ですが、当時はUミーティングというツールとバックアップ用にGoogle Meet両方で配信をしていました。
今はリモートワークがメインですが、昨年まではオフィス出社のメンバも多くいましたので、オフィスとリモートでのコミュニケーションの温度感の「ずれ」が課題として上がり、様々な取り組みがされていました。こういった経験も、Afterコロナも見据えてのクラウドワークスの強みなのではないかなと思っています。
今後の取り組み
今後も継続的な取り組みとなる中長期システム戦略
crowdworks.jpというサービスは2012年3月から開始したサービスで、まもなく9年を迎えます。 昨年のエンジニアリング戦略に書かれた記事にありますが、中長期を見据えたシステム維持の取り組みは形を変えながら、現在も継続して進んでいます。
少しだけ去年と変わった点として、エンジニア内では課題として認識されていたけれど、なかなか手がつけられず、改善できなかった開発項目への着手を進めてもらっています。中長期の取り組みは、継続性が重要になりますが、割り込み作業が多く発生すると、それが阻害要因になります。現在の取り組みで、より大切なことにエンジニアがフォーカスできる状態をつくり、中長期を見据えた新しいチャレンジの機会を作り出せればと考えています。仕事をする前にまず机の上を片付けるといった考えに近いですが、こういった取り組みは、できるだけ早くやればやるほど効果があると考えています。
また、技術的負債に対しての取り組みも継続しています。 2015年のブログ記事にすでに技術的負債という言葉が出ていますが、これまでの4年間でも、テストコードの充実や、リファクタリングや再設計の模索等多くの取り組みがなされてきました。現在は、コードの保守性を高めるにあたって、もっとも効果の高い箇所を洗い出し、その部分に対して集中して改善を行うため、crowdworks.jpのコアドメインについての深堀りが進められています。
中長期を見据えた組織の形の模索
現在の開発組織の規模はベンチャーとしては大きいですが、大企業と比べると、もちろん小さい。境目くらいの規模感です。メンバーの期待も、ベンチャーの自由さやチャレンジ機会を求める側面と、組織化を求める側面の両面がせめぎ合っている様にも思います。システムの規模にたいして、今の組織の規模や形では対応しづらい状況も発生しています。
crowdworks.jpは今も多くのお客様にご利用頂いており、また、日々成長しているサービスです。全社では新しい事業の立ち上げも進んでいます。エンジニア組織は事業の成長と、新規事業と既存事業との、サービス間連携も含めた最適化を常に模索し続ける必要があります。そんな中で、何を残して、何を変えるのか。今の良いところを残しつつ、組織を安定して成長させる引き続きの模索が重要ではないかと考えています。現在、事業を横断して、「プロダクト開発ポリシー」という、プロダクトメンバの考え方の基本をまとめる取り組みも進められており徐々に次のクラウドワークスのプロダクト組織の形も見えてくるのではないかと思っています。
最後に
以上、断片的ではありますが、今の組織と今後の取組について書かせていただきました。もし、ご興味持って頂けたら、ぜひお声がけ頂けたらと思っています。
We're hiring！ クラウドワークスは一緒に働き方の変革に挑戦するエンジニアを募集しています！
