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

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

カスタムコンポーネントを実装してみて思ったこと

カスタムコンポーネントを実装してみて思ったこと

この記事を書いているひと

CrowdWorks.jp デザイン基盤チームでデザイナーをやらせていただいている id:ksmxxxxxx です。

普段は CrowdWorks.jp のデザインシステム構築における、UI デザインと Vue コンポーネント作成をメインに活動しています。

今回は「デザインに軸足を置きながら、Vue コンポーネントを作っているデザイナーがデザインとフロントエンドの狭間で右脳と左脳を殴り合わせながらカスタムコンポーネントを実装した」ポエムをお送りします。
あくまで個人の感想であり他にも解釈はありますが、ひとりのデザイナーの中でデザインする自分とコーディングする自分が河原で殴り合ったポエムなので気軽に読んでいただけたら幸いです。

何もわかっていなかったカスタムコンポーネント

ここ 1 年くらいデザインシステムを構築するチームで、UI デザインの作成 →Vue コンポーネントへ実装という仕事をしていました。
私のコーディングスキルは初学者でもまだまだ尻にカラがついている程度のもの…...という自覚があります。実装もやっていても軸足はデザインなので、能力比率としては デザイン 8 : エンジニアリング 2 くらいの割合です。

そんな私がカスタムコンポーネントなるものを実装することになりました。
以前から「やってみたい」と息巻いていたこともあって「やっと手がつけられる〜」なんて呑気に構えていたころが、今では懐かしいです。
2 ヶ月前の自分に言いたい。「そんな呑気にしてられるの、今のうちだぞ」と。
それくらいはじめてのカスタムコンポーネント実装は私にとって学びの多い機会でした。

続きを読む

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

ようやく涼しくなってきましたね。もう少し漸進的に気温が下がってほしい。プロダクト開発部部長の塚本@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された記事でした。

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.