プロダクト開発の2024年総括とシステム思考

2024年総括とシステム思考

年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。プロダクト開発部部長の塚本 @hihatsです。 本記事はクラウドワークスグループAdvent Calendar 2024 シリーズ4の25日目の記事です。

昨年に引き続き、プロダクト開発部として今年取り組んできたことと、全社におけるプロダクト開発の動きから整理していきますが、 3ヶ月ほど前に書いた自社の開発組織の強みを定義するという記事の中でも軽く触れたシステム思考の話を中心軸に置きつつ進めていきます。 *1

engineer.crowdworks.jp

また今年はアドベントカレンダーの数も昨年より倍に増えました。 アドカレの記事もまとめつつふりかえっていきます。

*1: 「システム思考」については紹介するだけで連載記事になるのでここでは割愛します。機を見て書く意思はある

crowdworks.jp のデザインシステム構築活動を振り返る 2024 (実装編)

この記事はクラウドワークス Advent Calendar 2024 シリーズ 1 の 18日目の記事です。

こんにちは、crowdworks.jp のデザインシステム構築に携わっているエンジニアの @t0yohei です。

昨年は、crowdworks.jp のデザインシステム構築活動を振り返る 2023 (実装編)という記事で、デザインシステム実装の 0 -> 1 について書きました。

デザインシステム実装 2 年目である今年は、1 -> 10 として「やったこと」と逆に今の段階では「やらなかったこと」を書いてみたいと思います。

デザインシステムを実装中の方、これからデザインシステムを実装していこうという方の参考になれば幸いです。

目次

2024年 crowdworks.jp の SRE チームでやったこと

この記事は クラウドワークス Advent Calendar 2024 シリーズ2 17日目の記事です。

こんにちは。クラウドワークス SRE チームの田中（@kangaechu）です。 この記事では クラウドワークス の SRE チームが2024年にやったことを記載していきます。 2024年も様々な挑戦を通じて、クラウドワークスの信頼性を向上させるための多岐にわたる改善を行いました。本記事では、それらの活動をご紹介します。

2023年の振り返り

去年までにどのようなことをしてきたかはこの記事を参照ください。

engineer.crowdworks.jp

2024年にやったこと

日々成長を続けるプロダクト開発チームを解剖してみた〜メガ進化するデリバード〜

この記事は クラウドワークス グループ Advent Calendar 2024 シリーズ3の13日目の記事です。

こんにちは。株式会社クラウドワークスで「クラウドワークス」の開発を担当しているエンジニアの keigo0331 です。
最近はデータサイエンスに興味を持ち始め、趣味で数学や統計学を勉強しているのですが、難易度の高さに悪戦苦闘しています。一応大学では数学を専攻していましたが、約10年のブランクがあるとほとんど忘れてしまうものですね。

さて、今回の記事では、私が所属しているプロダクト開発チーム「デリバードチーム」についての内容です。

私は入社以来このチームで活動しており、気づけば3年が経過。今では最古参メンバーとなりました。デリバードチームは、私が加入する以前から常に高い成果を挙げ、MVPに選ばれるなど、社内でも評価の高いチームです。しかし、その道のりは決して平坦なものではなく、時にはチーム体制の大幅な変更を経験しながらも、さまざまな課題を乗り越え、成果を積み上げてきました。

特に昨年5月からの大きな体制変更を経て、1年に及ぶ大きなプロジェクトも終わり現在ようやく一区切りといった状態です。この記事では、この1年半にわたる改善の歴史と、現在の強み、そして今後の課題について振り返り、来年さらなる成長を目指すための糧にしたいと思います。少しでもチーム運営の参考になれば幸いです。

ちなみにチーム名の由来はポケモンのデリバードです。発足時の資料には「施策をしてユーザーにデリバリーを届けるチーム。ポケモンのデリバードが使う唯一の技が「プレゼント」なので、「ユーザーに良いものをプレゼントする」という気持ちを込めて。」という熱い想いがありました。*1*2

大きな改善点

メンバーの大幅な離脱をきっかけにスクラムの見直しを実施

デリバードチームは、スクラムを活用してプロダクト開発を行っています。昨年4月から5月にかけて、7人だったチームメンバーのうち3人が異動などで離脱し、スクラムに詳しいメンバーが不在となる不安定な状況に陥りました。それまでの運用は、経験豊富なメンバーに依存した高度な形で行われており教科書的なスクラムからはやや逸脱していましたが、この状況を受けて運用の抜本的な見直しが求められることとなりました。

この変化を機に、当時のマネージャーがスクラムマスターの役割を担い、スクラムの基礎から運用方法までの見直しを進めました。

主な改善内容

• スクラムマスターの設置（2023.5~2024.8）
• スプリントゴールの意識づけ（2023.5~）
• プロダクトバックログとスプリントバックログの整備（2023.6~）
• ユーザーストーリーの導入（2023.6~）
• スプリントレビューの開始（2023.7~）
• 1スプリントの期間を2週間に（2023.7~）
• スクラムガイド 輪読会の実施（2024.3~2024.8）
• プロダクトゴールの設定（2024.8~）

これらの改善プロセスは3段階で進められました。2023年5月から9月末まではスクラムのイベントや運用ツールの整備に注力し、2023年10月から2024年3月にかけては実践フェーズに移行。さらに2024年4月以降はスクラムガイドを活用した学び直しを進め、基盤を強化しました。

詳細な改善プロセスについては、当時のスクラムマスターが記録したこちらの記事をご覧ください。

engineer.crowdworks.jp

現在のデリバードチームのスクラム運用は、教科書的な形に近づいており、新しいメンバーが加わった際にも過去の知見をスムーズに活用できる環境が整っています。また、未経験者もスクラムガイドや SCRUM BOOT CAMP を参考にしながら順応しやすい状態になっています。
加えて、困りごとが発生した際にはチーム外のスクラムに詳しい方に相談しやすくなり、逆にスクラムの専門家も現状を把握しやすくなったことで、適切なアドバイスができる環境になりました。さらに、ネット上のナレッジを取り入れるハードルも下がり、チーム全体として継続的に改善を進めやすい体制が整いました。

また改善の議論を一つひとつ丁寧に行ったことで、各施策の意図や効果が明確になり、個々のスクラムに対する理解も向上したと感じています。このような環境整備により、属人化を防ぎ、自律的かつ持続可能なチーム運営が実現しました。その結果、「会社で最もスクラムをうまく活用している」と評価される機会も増え、他チームから参考にされるなど、会社全体のナレッジ向上にも貢献しています。

チームの担当領域を具体化し、明確なミッションを制定

2023年10月から、デリバードチームはクラウドワークスの主要ドメインである「マッチング」を担うチームとなりました。

それ以前、デリバードチームは「ユーザー向け施策を行うチーム」として漠然と広い領域を担当しており、ドメイン知識の蓄積が難しい状況にありました。また、エンジニアが2名と少人数だったため、リソース不足から広い領域を扱うことが厳しい状況でした。一方、マッチング領域は事業の主要ドメインであるにも関わらず、担当チームが存在せず数年間にわたり開発が滞っており、業績への寄与が期待されている領域でした。

チームの新たな役割を明確にするため、以下の取り組みを実施しました。

チームビルディング：改めて「このチームは何をすべきか」「良いチームとは何か」を議論。
ミッションの制定：「スムーズなマッチングでワクワク×ゴキゲンを増やす」というミッションを策定。

具体的なプロセスや背景についてはこちらの記事に詳しくまとめています。

engineer.crowdworks.jp

ミッションの明確化により、チームの方向性が揃いやすくなり、優先順位の決定や行動計画がスムーズに進むようになりました。

改善の成果

スクラムの改善とチーム再生成の結果、KPIの過去最高記録を更新することができました。

2023年10月から2024年3月末までに設定したKPIでは前年比123%の成長を達成し、単月では最高140%という過去のピークをも超える成果を上げることができました。

2024年4月からは別の新たなKPIを定め、2024年8月には「KPIを70%から80%に引き上げる」というプロダクトゴールを設定しました。この目標は非常に難易度が高いものの、現時点では数値がまだ確定していないですがほぼ達成可能な見込みとなっています。

これらの成果には、スクラムの改善とチーム再生成の取り組みが起因していると考えております。特にプロダクトゴールの導入以降は以下のプロセスが定着し、開発がより効率化されました。

1. ミッション・ビジョンに基づく明確なプロダクトゴール設定
2. プロダクトゴールをもとにユーザーストーリーを作成
3. ユーザーストーリーを起点にスプリントゴールを設定
4. スプリントゴールに向かい日々開発を行う

これにより、チーム内の認識の齟齬が減り、開発の無駄が排除され、大きな目標に向けて日々着実に進むプロセスが構築されました。また、2024年4月にはチームメンバーが9名に増加しましたが、整備されたスクラム運用のおかげで学習コストが低減し、新メンバーが力を発揮するまでの時間が短縮されました。

デリバードチームの強み

スクラムへの深い理解と運用

スクラムは現在では広く普及しているフレームワークですが、その運用には難しさも伴います。デリバードチームは、現実に直面する課題に対し、時間をかけて最適な解決策を模索してきました。ただ単にスクラムに「乗っかる」のではなく、スクラムの原点を学び直し、検証を繰り返しながら一歩ずつ進化を遂げてきました。その結果、スクラムを効果的に運用する能力が培われたと感じています。

デリバードチームの大きな特徴のひとつが、活発なレトロスペクティブ（振り返り）です。この場では常に建設的な議論が交わされており、チームが改善を重ね、スプリントを重ねるごとに強化されています。こうした文化により、チームは継続的な成長を遂げており、スクラムを扱う精度も高まっていると感じています。

もちろん、まだ完全にスクラムを理解し尽くしているとは言えません。しかし、地道な改善を続けることで、さらなる成熟に向かっていると確信しています。

レトロスペクティブの雰囲気

心理的安全性の高さ

先ほど紹介した「良いチームについて考える」の記事でも見られますが、デリバードチームのもう一つの強みは、その高い心理的安全性です。弊社全体の文化として「性善説」の考え方を基盤に心理的安全性を高めるための工夫が行われていますが、デリバードチームでもこの文化がしっかりと根付いています。この文化が、仕事をしやすい環境づくりにつながり、精神的な負担を軽減するとともに、活発な議論を促しています。その結果、改善が進み、生産性の高いチームが形成されています。

昨今の研究では、エンゲージメントと生産性に正の相関があることが示されていますが、デリバードチームが成果を出し続けている背景には、このエンゲージメントの高さが大きく寄与していると考えています。特にアジャイル開発のようにコミュニケーションの機会が多い開発手法では、心理的安全性が高い環境がエンゲージメントを高め、その結果、生産性が向上するという好循環が生まれております。

また、こうした文化により、新入社員の配属先としてデリバードチームが薦められるケースも増えています。今年4月には新卒メンバー2名が加入し、チームの規模は9名に拡大しました。この文化だけが薦められる要因ではないですが、心理的安全性を基盤としたチーム運営が、結果的に優秀な人材を引き寄せ、生産力向上に大きく寄与していると実感しています。

良いチームの状態になるために

現状の課題

マッチング領域が広すぎる

デリバードチームが担当するマッチングは、クラウドワークスの主要ドメインであるために非常に広範かつ複雑です。現在、検索システムの改善（並び順のスコアリングや検索エンジンを扱うGemの整備）を主に進めていますが、それだけでもリソースが不足している状況です。さらに、検索導線の整備やUI/UXの向上といった重要な課題も多数残されており、手が回らない状態が続いています。

加えて、マッチング領域はクラウドワークスのサービスの中心であるがゆえに、10年以上にわたる膨大なコードと、それに伴う技術的負債を抱えています。この負債を解消しない限り、新しい機能や改善を進めることが困難な場面が多くあります。例えば、フロントエンドの多くが古いERBベースのコードで記述されているため、クラウドワークスのデザインシステムを適用するにはまずVue.js化が必要になるなど、開発そのものが難しい状況です。

現在は一時的に他チームから支援を受けて負債解消やVue.js化を進めており、このサポートには非常に感謝しています。しかし、他チームに依存する形では、マッチング領域の知識がデリバードチームに蓄積されにくいという新たな課題も生まれます。長期的には、主要ドメインをより深く理解し、効率的に扱える体制を築くために、チーム規模の拡大や新たなチームを配置し領域を分割するなどといった構造的な変更が必要だと考えています。

スクラム改善の効果を十分に定量評価できていない

これまで取り組んできた様々な改善について、一定の効果を実感しています。しかし、その評価は定性的なものにとどまっており、定量評価の仕組みが十分に活用されていないと感じています。例えば、ストーリーポイントをもとにベロシティを測定する仕組みはありますが、ポイントの設定基準が煮詰まっておらず乱高下しており、ベロシティの信頼性が高いとは言えない状態です。

現状では、良いと思われるチーム体制によって成果が出ているものの、それがマンパワーによるものなのか、スクラムの効果によるものなのかを厳密に分析できていません。より多角的な軸で定量評価を行うことで、改善の真の効果を把握できる仕組みが必要だと考えています。

ただし、スクラムの改善効果を測る指標を設けるには、一定のリソースと専門性が必要です。現在はスクラムマスターが不在であり、スクラム運用に専念できるメンバーもいないため、定量的な評価の仕組みを構築する余裕がない状況です。最近、事業部全体でOKR（Objectives and Key Results）の取り組みを開始し、デリバードチームでも試験的に導入しています。この仕組みを活用することで、改善効果をより定量的に評価できる可能性を模索しています。

定量評価を導入できるようになれば、成果の再現性の向上や意思決定の精度向上、生存者バイアスの回避などが期待できます。デリバードチームを拡大したり、新しいチームを立ち上げる際に活用するためにも、定量評価の仕組みが構築できれば理想的です。

使用技術が多岐にわたり専門性を深めにくい

クラウドワークスの基盤は主にRuby on Railsで構築されていますが、最近ではフロントエンドのTypeScript×Vue.js化が進められています。それでもなお、RubyとRailsの知識が求められる場面が多く、マッチング領域も例外ではありません。また、ドメイン駆動設計を取り入れており、FatModelの解消など技術的負債の返却も進行中です。

さらに、デリバードチームでは検索エンジン（Elasticsearch）の運用や、Redshift上でのスコアリングロジックの実装（PL/pgSQLの利用）といった多様な技術を扱っています。このように使用技術が広範囲にわたるため、メンバーが特定の技術に専念することが難しくなっており、技術的な成長が見えにくいという課題があります。また、キャリア形成を考える際にも悩みが生じる可能性があります。

私自身はキャリアについて深く考えるタイプではなく、さまざまな技術を楽しみながら学びたい人間なので、この多様な技術環境を前向きに楽しんでいます。しかし、全員が同じように感じているわけではなく、特にフロントエンドに専念したいと考えるエンジニアが増えている昨今の状況では、現状の体制においてRailsの知識も必須になる点が課題です。その結果、専門性に特化したエンジニアを雇う機会を逃し、チームとして機会損失を招いてしまう可能性もあります。

また、チームとしても特定技術の知見が十分に蓄積されにくく、成果物の質を高めることが難しい場合があります。これを解消するためには、専任のチームを設けるなど、技術領域に知識を集約しやすい環境を整えることが重要だと考えています。例えば、スコアリングを担当するチームと検索体験のUI/UXを担当するチームに分けることで、特定の技術分野における専門性が深まり、効率的かつ質の高い成果が得られるのではないかと思います。

まとめ

振り返ると、この1年半でデリバードチームは多くの改善や挑戦を重ねてきました。この成果はチーム全員の熱意と尽力によるものだと強く感じています。デリバードチームに対する愛着と情熱を持った素晴らしいメンバーが集まり、共に前進してきたからこそ、今の成果に繋がっているのだと思います。私自身も入社以来、デリバードチームを成長させることを目標に働いており、改めてこのチームで働けることを誇りに感じています。

ちなみに今年の6月に「Elasticsearch RailsからSearchkickへの移行で気づいたSearchkickの注意点」という記事を公開しましたが、先月ついに移行が完了しました。チームのリソースにも余裕が生まれつつあるので来年からはより多くの挑戦が可能になると確信しています。

2025年も、デリバードチームとしてさらに成長し、新たな価値を生み出していけるよう努力を続けます。

ちなみに明日はデリバードチームのPOが書いた、プロダクトゴールの導入とそれによるKPIの上昇についての記事が上がります。ぜひお楽しみに！！

*1:執筆時点ではレベルアップでプレゼント以外の技を覚えます。

*2:執筆時点ではデリバードはメガシンカしません。

ビビリのためのRDS MySQL→Aurora移行

この記事は クラウドワークス Advent Calendar 2024 シリーズ3 11日目の記事です。

こんにちは。クラウドワークス SRE チームの田中（@kangaechu）です。 クラウドワークス では2024年12月に クラウドワークスのマスタデータベースをMySQL から Aurora に移行しました。今回はその移行について書きます。

クラウドワークスは、2012年にリリースされた日本最大級のクラウドソーシングサービスです。 クラウドソーシングを通じて、企業とフリーランスのマッチングを行い、業務の効率化を支援するため、仕事の公開、応募、受注、進捗管理、報酬の支払いなど、さまざまな機能を提供しています。 クライアント数は100万社、ワーカー数は670万人と、多くの方に利用していただいています。

そんなクラウドワークス のデータベースはAWSのRDS MySQLで運用されていました。 これをAuroraに移行するのですが、もし移行に失敗した場合、多くのユーザに影響を与えてしまいます。 移行に失敗したらどうしようという不安を抱えていました。

そこで、クラウドワークスで使用したビビリのためのAurora移行の方法を共有します。 これを行うことにより、Aurora化が失敗した場合でもRDSに戻すことができます。