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

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

自社の開発組織の強みを定義する

ようやく涼しくなってきましたね。もう少し漸進的に気温が下がってほしい。プロダクト開発部部長の塚本@hihats です。

自社の開発組織の強みを定義する

前置き

この二、三年くらいは個人的にシステム思考への傾倒があり、以前ここに書いた変化に適応するソフトウェアアーキテクチャと組織構造への道程も、Qiitaに書いたソシオテクニカルアーキテクチャ概要もその系譜の記事だった。今回は、エレガントパズルという書籍を読んでいて、そこかしこにドネラ・メドウズ公の話が出てくるので改めて私もシステム思考について記事を書こうと考えていた。

そんな折、他社のCTOと話す機会があってそこで「自社の開発組織や開発力にそこまで特別さを感じていないんですよね」という話を聞いた。実は過去にもそれはあって、自社のWebプロダクトで会社の利益を上げているにも関わらず、開発の責任者がそう思っているケースは少なくないのかもしれない。

一定の市場シェアを獲得していて、今生き残っている時点で何らかの競合優位性があるはずではあるが、それは先行者利益なのか、次々と生まれる革新的なアイデアなのか、顧客体験の良さなのか、外部環境の変化なのか、要因は様々である。

いずれにしても、「開発組織として可視化しやすいスループット(一般的に技術力と呼ばれやすいもの)を強みとするのが本当に正しいのか、それが本当に事業貢献をしているのか」あたりの疑問は常について回っているといった様相がある。

開発生産性がやたら取り上げられる昨今、なおのこと向き合うことから逃れることはできない命題であるし、それについて書くことにした。

突きつけられている課題

  • ソフトウェア開発者をやっていると、ソフトウェアで問題解決をしたり価値提供をするのが当たり前であり、それを疑いもせずエンジニアをやってきていることは特段珍しいことではない
  • 一方で、ソフトウェア開発をせずに問題解決をしたり価値提供できるのであれば、リードタイムは短く、技術的負債も発生せずで、そのほうが嬉しかったりする

この矛盾はありつつ、手札としてソフトウェア開発力を備えていない企業が生き残るとは思えないし、いざ地上戦になったときに製品開発力がないことによる「戦う前からの敗戦」を避けることはできる。そもそも新規開発に限らず、長期的に製品を保守運用するだけでも相当の技術力は必要である。

事業会社における技術戦略とはそういうものであるという解釈のもと、では自社の開発組織の強みとはなんなのかを抽出してみる。

自社の開発組織の強みの抽出

How to

定量的には例えばFour Keysの指標が他社と比較して高いなどが上げられるかもしれない。それらで言えば部分的には平均よりは高いらしく(Findyさん調べ)、一定強みといっても過言ではないとは言えそうだった。がしかし、それと事業収益性との相関がまだ見えていない状況で強みとするのは時期尚早という判断で除外した。

ではそれ以外だとなんだろうというところで、結果としては複数人から一定共通して上がる我々ならではの定性的な強みがいくつか上げられた。

複数プロダクトによる技術の多様性

クラウドワークスでは複数プロダクトを運用しているが、技術選定に関してはハッキリ言ってバラバラである。

各プロダクトの利用技術(一部)
各プロダクトの利用技術(ごく一部)
統一しようと思えばできなくもないが、今後もM&Aによる子会社が増えることを考えると、統一することはどのみち現実的な選択肢ではない。

であれば、それぞれが好きな(つまり状況に適した)技術を採用するほうに舵を切りつつ、横断的関心事や、専門性&学習コストが高い技術領域に関してはプラットフォームチーム化するのが妥当という方向性になる。

結果として

  • 技術に限らず、SaaSやプラットフォーム、Embed AIプロダクトといったプロダクトの型も多様
  • マッチング領域から工数管理領域までドメインも広い
  • 開発プロセスも基本現場任せであり、チームの特性や成熟度にあったやり方を選択している(英語を使う部もある)
  • 異動によって必然的に新しい技術を学ぶ環境にはなっている

これらは強みと言えるが、特異性と言ったほうが近く、見方を変えると一方で

  • 人材の流動性という面では異動してすぐ活躍できるかという点での不安などがある
  • 局所的に技術を突き詰めたスペシャリストは生まれにくい土壌になりつつある

これらのデメリットは、それでいいのかという課題はつきまとう

テクノロジーカンパニーである

ここでいうテクノロジーカンパニーとは

「技術を正しく使える」

という意味で、開発者一人ひとりにその意識があることを指す。

言い換えると、新しい技術への関心はもちつつ、決してそれを使うことが目的にはならない集団とも言える。

※もちろんテクノロジーカンパニーには「経営が技術を理解して適切な技術投資をできる」という文脈もあり、それはそれで必要ではあるもののここでは一旦脇に置く

自社の開発組織の強みとしては基本的にはこれに尽きるが、シンプル過ぎるのでこれに従属した強みも列挙していく

健全性、持続性、信頼性への責任

数年後まで持続的に運用する前提で品質を考慮して設計するのが当然の考えとなっている

  • ポストモーテム文化
  • 内部品質と外部品質両面からSLIを定めて運用(整備中)
  • 不正利用への厳正さ

    ※ここで言う不正利用とは、利用規約に違反した利用のこと

    ※※日々多種多様に発生しているので、不正に対応しきれているとは言えない

  • 技術的負債を解消していく文化

    • 技術的負債に対する向き合い方がチームを超えて共通してある

その他の特性

  • 課題内在性認知負荷に対する耐性が強い
  • 越境を厭わない
  • アジャイル

    ここではアジャイルの定義の正誤については議論の対象にしない

  • 適切なリーダーシップ

    • 分からない人がいれば手を差し伸べるのが当然で、優しさというよりあくまでコミットメントのためにそうしている
    • 育成も同様
  • 刺激と成長
    • 技術と知識に優れた人が積極的に継承の姿勢を見せることで、それに続くことが自明の態度である
  • わからないことは聞く
    • 真面目な仕事人は自分でなんとかする方向に寄りがちなので、あえて即白旗を上げる方向に寄せて助けを求める心理的ハードルを下げる(白旗文化)
  • OSSや社外への貢献

エンジニアに限定しなければ

  • POなど開発職以外のメンバーも上記特性への理解があり、部分的にエンジニアリングをしている

これらはマネジメントからのフィードバックによって奨励されてきた行動もあるが、会社全体のカルチャーとも相まって、意図せずして生態系としてそうなっている側面もある。 ここまで書いて、結局システム思考の話に戻ってくるんじゃない?と気付いた。はい、長くなるので今回はここまで。

まとめ

自社の開発組織の強み

  • 技術の多様性
  • テクノロジー(を正しく使える)カンパニー
    • 健全性、持続性、信頼性への責任
    • 変化に対応する特性

といったところになった

何をもって「強み」とするかは、どうしても相対的な見方が入ってきてしまうので、私含め数人が他社と比較して自社が優れていると思う点になった。 上記に挙げたいずれも、そう容易に組織に身につくものではないと考えていて、先人も含めた全員の積み上げにより作り上げられてきたという自負がある。 (逆に積み上げられた負債もあるが、それに立ち向かっているという点では強さと表裏一体である)

そして、こうやって言語化することで改めて見えてくることがあり、内外に発信することによってより強固になっていくのだろうという仮説があるので、これから検証していく。

We are hiring!

上記のような強みをもつ開発組織で働いていきたい方、こちらからお待ちしてます! herp.careers

HerokuとAWSのリージョン移行した話

初めに

こんにちは。クラウドワークスのエンジニアをしているu2_cwです。

普段はクラウドワークス テッククラウドワークス エージェントの開発を行なっています。

今回は、そのサービスのアプリケーションで利用しているインフラである HerokuとAWS のリージョンを東京リージョンへ移行した際に起こった問題について共有しようと思います。

続きを読む

Aurora MySQLとRedshiftのゼロETL統合が本番導入出来るか検証しました

Aurora MySQL Zero ETL Integrations

クラウドワークスのSREチームに所属しています@ciloholicです。

2023年11月にAurora MySQLとRedshiftのゼロETL統合がGAされました。この度、ゼロETL統合が本番導入可能かを検証する機会があったので、その検証結果を記載します。

aws.amazon.com

2024年7月時点での検証結果ですので、時間経過によって内容が変わっている可能性があります。その点は十分ご注意ください。

背景

まず、ゼロETL統合の検証しようと考えた背景について軽く説明したいと思います。クラウドワークスでは、MySQLのテーブルをDMS経由でRedshiftにニアリアルタイムで同期し、データ分析を行なっています。3年前は約30億レコードでしたが、現在では古いレコードの削減を行なったため、約25億レコードになりました。

engineer.crowdworks.jp

時折ですが、Redshiftのレコードに不整合が発生すると、テーブル全体やテーブル単体を再同期してレコードを洗い替えたいときが存在します。レコード件数やデータサイズが大きいテーブルを再同期すると、テーブル単体で最大約8時間、テーブル全体で半日以上かかっていました。データ分析基盤を平日に半日以上止めることはできないため、土日に再同期するという作業が発生していました。再同期を頻繁にするわけではないのですが、気軽に再同期ができないことは運用上の課題になっていました。

DMS以外の同期方法として、RDS MySQLのスナップショットからS3へエクスポートし、Redshiftに取り込む方法も存在しました。この方法では、1回のエクスポートごとに復元スナップショットサイズ1GB単位での課金が発生します。1日に何度も同期する場合には料金が高額になるため、この同期方法は断念しました。DMS以外の同期方法を探しているときに見かけたのが、冒頭に記載したAurora MySQLとRedshiftのゼロETL統合がGAされた記事でした。

続きを読む

フロントエンド開発チュートリアルを作成し開発ハードルを下げた話

こんにちは、crowdworks.jpの開発エンジニアをしている得能です。

クラウドワークスへの入社以来バックエンド開発のみ行ってきましたが、今年に入りフロントエンド開発の機会をいただけることになり、Vue.jsを使い新規画面実装などを行いました。 その際に、今後新しくcrowdworks.jpのフロントエンド開発を行う方々がスムーズに開発業務に入れるようにフロントエンド開発チュートリアルを作成しました。今回はその取組みについてお話したいと思います。

背景

crowdworks.jpはバックエンドはRuby on Rails、フロントエンドはERB、Vue.jsで開発されており、少しずつVue.jsで開発した画面への置き換えを進めています。

Ruby on Rails × Vue.jsの実装といえば、Vue.jsで画面実装、Ruby on RailsAPIサーバーにする、がよくある構成かと思いますが、crowdworks.jpでは過去の実装を残しつつVue.jsに移行を進めているなどの理由もあり弊社特有の実装方法を確立しています。そのため、crowdworks.jpのフロントエンド開発を初めて行う方はまずそのような実装ルールを知る必要がありました。

実装方法は現在の実装コードを眺めればある程度理解できます。また、フロントエンド開発に必要な知識は社内のQiita Teamにまとめていただいており、誰もが閲覧できる状況にはなっていました。 しかし、私がいざ開発を始めてみるとコードを読み込むだけでは

  • コード上では必須ファイルの名称などが明記されておらず見逃してしまう
  • 実は共通コンポーネント、関数が定義されているが、読んだ実装コードではたまたま定義されていなかった

ということがありました。

また、Qiita Teamの資料については実装したあとから「資料あったのか〜」と感じることがいくつかありました。その資料に到達するまでの検索ワード、問いが実装の過程では思いつかなかったためと分析しています。

私の情報探索力が足りないというのも理由ではあると思いますが、一方で、これだけ見ておけば全体像を理解できると感じられるガイドブックのようなものがあれば、誰でも迷わずcrowdworks.jpのフロントエンド開発に必要な知見をスムーズに習得することができるのでは?とも感じました。

どんな形式のガイドブックが良いだろう…と考えた結果、チュートリアルの形式が良いのではないかと思い作成してみました。

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.