はじめに
はじめまして。クラウドワークスに今年10月に入社しました小橋と申します。
この記事では、私がクラウドワークスに入って1ヶ月たった感想について書いていきます。
今までの経歴と入社した経緯
まず本題に入る前に、今までの経歴とクラウドワークスに入った経緯について簡単に触れます。
新卒で大企業向け業務パッケージソフトメーカーのエンジニアとして入社し、給与・会計分野の社内向けWebアプリケーションの開発を行ってきました。
上記12年程在籍したあと、クラウドワークス子会社のgravieeに入り、2年ほど社内業務システム開発(契約・請求管理)+ひとり情シスみたいなことをやっていました。
今年の8月くらいからクラウドワークス-graviee間の連携を今まで以上に強化するという流れになり、その一環でシステム周りも徐々に統合するため、graviee内で自分の仕事がなくなってしまいました。
これを機に転職なども考えたのですが、会社とも相談したところクラウドワークスのエンジニアとして受け入れていただけるということで、頑張ってみることにしました。
このような経緯なので、クラウドワークスという会社についても、「クラウドワークス」のサービスを運営している会社だというくらいの認識で入社に至りました。
ずっと業務系&Javaをやってきたので、Webサービス運営会社&Railsでの開発業務も初めてです。
予備知識もなくキャリアも異なる状態で入社した自分がクラウドワークスについて書くことで、クラウドワークスに興味を持っている方や、業務系エンジニアからWebサービス運営会社へキャリアチェンジを検討している方などの参考になれば良いと思っています。
目次
クラウドワークスに入っての感想
文化について
入社してすぐに、会社の文化(カルチャーブック)についての説明を受けました。 その中でも印象に残っているのが、コミュニケーションに関する内容でした。
「よ！」 ：誰かの発言に対して、肯定でも否定でもなく、いったん受け止めたことを合図する言葉。個別の解釈に対して評価や否定される不安を感じることなく、率直に意見を伝えられる環境をつくるために使う。
「ばぶばぶ」 ：結論のない発言、まとまっていない発言、事実のない解釈のみの発言などを行うこと
「デンタツ」 ：結果を出しただけでなく、結果を相手に伝えて初めて評価を受ける。小さなことでもいいので、結果が出たらデンタツをしていき、その積み重ねが社会の評価につながる。
このようにコミュニケーションに対してのスタンスが会社として明文化されているのがとても良いと感じました。
それぞれは特別なことではないかも知れませんが、会社のカルチャーとして明文化されているのが価値があるように思います。
まとまっていない意見やどんな種類の意見・アピールなども、遠慮・萎縮することなく発言を促すことによって、各メンバーが主体的に自分らしく働けるようになると良いと思いました。
ちなみに、社内Slackでは「よ」のリアクションや、「babubabu」チャンネルなどもあります。
チームやスクラム開発について
クラウドワークスのプロダクト施策を行う「デリバード」というチームに所属しました。
現在、プロダクトオーナー・エンジニア(フロントエンド・バックエンド)・デザイナーの混在チームになっています。
チーム運営は、スクラム開発になっており、チーム内は基本的にフラットな組織になっています。 (開発リーダーは存在しますが、役職ではなく、あくまで等級的な位置付け)
はじめに書いたように自分はずっと業務系のエンジニアをやっておりスクラム開発は初めてでした。 受託開発ではなかったのでアジャイル的な要素は入っていますが、基本的にウォーターフォール寄りです。
さらに今までは、個人主義で自分の守備範囲は自分で責任を持って仕事をしているような環境でずっとやってきたので、正直スクラム開発にあまり良い印象もなく、やっていけるか不安なところがありました。
また、エンジニア主体でロードマップ作成・要件定義から設計・開発まで一貫してやっている組織の経験しかなかったので、エンジニアと別にプロダクトオーナーがいるというスクラムの形式にも懐疑的でした。
しかし、不安・違和感はあったものの、せっかくの機会なので、しのごの言わずやってみようと思っていました。
やってみて最初に思ったことは、とにかくコミュニケーションコストが高いのでは？ということでした。 今までは責任者・マネージャーが判断していたようなことも、全員に相談・ディスカッションして決めていくのでスピード感がないように感じていました。
しかし、さらにやっていく中でスクラム開発の良さ・特徴について少しづつ理解が進んできました。
案件・要件的なことだけでなく、プロセス自体もチームみんなで相談・ディスカッション・改善していくのだと言うことに気付きスクラム開発に対しての印象が変わりました。 プロセス等に問題があったり非効率すぎることがあれば、みんなで提案・改善していけば良いのです。
また、業務系は目的・ゴール・納期などが割と明確なのでエンジニア責任者が意思決定をしていくスタイルでも良いですが、サービス運営だとKPI・KGIも複雑になり、関わるメンバー・ユーザー種類も多くなり、エンジニア責任者の判断で進めていく難易度が上がるため、立場の違うチームメンバー同士が話あって物事を決めて進めていくと言うのはあながち効率が悪くないと思うようになりました。
それ以外にも、みんなで話しあって決めることによって、メンバーの多様性・全員の納得感・主体性の観点でもメリットが大きいと感じています。 スクラム開発と、クラウドワークスのコミュニケーション文化との相性も良いと感じています。
スクラム開発以外のことでは、チームみんなで行った スキルマップ共有&お互いへの期待のワークショップが印象に残っています。
まずは、スキルマップ共有ということで、各メンバーの保有スキルを言語/フレームワークからツール・デザイン・設計・管理スキルまで多様に渡って共有を行いました。
その上で、各メンバー間で相互に期待する内容を共有しあいました。(XXXの知見を発揮して欲しい。〇〇の分野でチームを引っ張って欲しい 等)
異なるバックボーン(スキル・キャリア)を持ったメンバーの集まりなので、相互理解・期待の認識合わせを最初にするのはとても良かったです。
プロダクトや技術について
まず、10年弱の歴史があるクラウドワークスのRailsコードの量に圧倒されました。
正直、クラウドワークスのプロダクトに関して、ワーカー・クライアントのマッチングをするだけだからそんなに大変ではないのでは？と思っているところがあったのですが、エンドユーザー向け機能は一部に過ぎず、サポート・管理などの社内機能が多くあり、コード量にも納得しました。
今までずっとJavaメインでやってきて、初のRailsでしたが、この規模のコード量にもかかわらずスクリプト言語であるRails(Ruby)を触るのはちょっと怖いなと感じてしまいました。
中には数千行のコードもあり、コンパイルエラーも出ないRailsでこのコードを触らないといけないのは大変そうだなと思いました。(自動テストやCIサイクルなどはありますが…)
また、言語・コード量的な側面以外にも、内部で連携している様々なサービス・アプリの量にも驚きました。
ログ・キャッシュなどはもちろんですが、マーケティング向け・ユーザーサポート向け・各種KPI測定など、今まで全く触れたことも無いような種類のサービスとも多く連携しており、個人で全てを把握しきるのは無理そうだな…と感じます。
そういう意味でも、スクラムでチーム全体に課題・タスクを共有しながら進めるのは、対応漏れ・デグレード対策の面でも良いと思いました。
あと、実際に開発を行っていてびっくりしたのは、これだけの規模のあるサービスなのにプルリクのレビューだけ通ったら、自分で動作確認をして本番含めたデプロイなども各開発者が行っていることです。 障害時のアラート・対応なども整備されているとは言え、リリース作業は緊張しますね。
大変だったこと
質問をするコストが高い
完全フルリモートの組織なので、ちょっとした質問などはSlackのチームチャンネルで行っていました。
まだ会社のことも、プロダクトのことも分からないことだらけで、「何がわかっていないか分からない」という状態になることがあり、そうなるとSlackで質問するにも言語化するのが大変で大したことない質問でもなかなか質問できなかったりということがありました。
そこで、途中から朝会(チームのデイリースクラム)の時に質問時間を取ってもらうことにしました。 急ぎでない質問はスプレッドシートにストックしておき、朝会のタイミングでみんなの前でまとめて質問させてもらいました。
みんなが揃っているので誰かしらが答えられるので、その場で疑問解決できてとても効率的でした。 Slackと違い質問が流れてしまったり、スレッドのやりとりが発生して時間がかかったりということもありませんし、わざわざSlackでは質問しないような些細なことでも質問しやすくなったので、だいぶ気持ち的に楽になりました。 ただ、質問がふんわりしすぎていると、みんなの前で質問するのもちょっと躊躇ってしまうこともありますが。
今でもまだうまく質問できず少しモヤモヤする時もありますが、チームからも質問自体は積極的にして欲しいと言ってもらえており、実際に些細なことでも時間を使って答えてもらえるので、自分が会社に慣れてくれば解消するとは思っています。
MTGが多い
スクラム開発でチーム内の事柄はみんなで共有・議論することになるので、必然的にMTGが多くなります。
自分の場合、MTGの内容に関して、考えが追いつかなかったり、わからない事柄・言葉が沢山出てくるので、事前予習や終了後の思考整理・キャッチアップなどにも時間を使ってしまうので、負荷が結構あります。
ただし、今は大変ではありますが慣れてくればMTG前後の負荷も減ってきて、全体のことが把握できるようになるので長い目で見るとメリットだとは思っています。
情報に飲まれやすい
MTG以外での情報収集は、主にSlackや社内Qiitaなどで行います。
Slackでは各チーム・業務チャンネルだけでなく、timeチャンネル(分報)も登録をして、気になる事柄があれば可能な限りリアクションやコメントをつけるようにしています。
社内Qiitaでは、チームのポータルページ・mini spec(開発要件まとめ)・技術ノウハウ・その他ポエムなど様々な記事がアップされています。
現段階では分からないことだらけなので、Slack・社内Qiitaを読み出すとあっという間に時間が経ってしまい、上記のMTGの件と相まって、集中してタスクをこなす時間があまり取れなかったりします。
分からないことがあるのは仕方がないので、これは、自分で作業時間・情報収集の時間を区切ったりして、うまくバランスをとって行くしかないだろうなと思っています。
また、ある程度慣れてきたら、自分の得意領域や力をいれるポイントなども分かってくるはずなので、そうなると情報の取捨選択もしやすくなってくると思います。
さらに、社内のドキュメント整理・改善などが進められると、情報収集の効率は上がるだろうなとは思っています。(実際、社内でも課題認識されている部分ではあります)
やっていきたいこと
最後に感想ではありませんが、自分がクラウドワークス内でやっていきたいことを書きます。
今までの業務システム開発の経験から、要件定義から業務・運用を設計(ソース・DB)に落とし込む作業は得意だと思っているので、そのあたりを踏まえてコミュニケーションや意見出しができるようになると、チームに対してメリットが多く出せるのではないかと思っています。
前職等で業務やプロセス改善なども取り組んでいたので、慣れてきたらその辺りも積極的に貢献できるようになりたいです。
また、スキル面だと、フロントエンド側に力を入れていきたいと考えています。
最近プライベートでAngular&Typescriptをやっているのですが、SPAのフロントエンド側のコードをバックエンド感覚で書けることに感動しました。
モダンJS+Typescript+SPAであれば、今まで自分がやってきた要件定義〜設計・開発やバックエンドのノウハウを生かせると思っており、フロントエンド・バックエンドの垣根なくスピード感のある開発ができるのではないか思っています。
クラウドワークスではフロントエンドで一部Vue.jsが利用されているので、Railsのキャッチアップと並行して、Vue.jsのキャッチアップも積極的に行っていきたいです。
We're hiring!
クラウドワークス では、働き方の変革に挑戦するエンジニアを募集しています！ 個性豊かで、愉快なエンジニアがお待ちしています。まずは気軽にお話してみませんか？