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

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

月間100時間超の工数削減を実現したユーザーサポート支援チームの軌跡

前置き

メインサービスcrowdworks.jpのユーザーサポート支援チーム、名称UDXに所属していました、薄井と申します。

UDXチームはユーザーサポートチームの課題解決を技術的に支援することを主な目的として活動していましたが、この度、期が変わったタイミングでその活動に一区切りをつけることになりました。

本記事では、チーム発足から解散するまで、期間にして2023年5月から2025年9月までの2年余りで取り組んだ主な施策の振り返りを記していきます。なお、一連の施策の成果として月間100時間を超える業務工数削減を実現しております。

チームメンバーは、エンジニア3~4名(途中で初期メンバーは全員卒業)、プロダクトオーナー1名(+2024年9月までプロダクトオーナーアシスタント1名)で構成されていました。

筆者がUDXチームに加わったのはチーム発足から約1年後の2024年6月になります。初めの1年については直接の記憶はなく、記録を見て文をしたためております。そのため、2024年6月以前以後で期間を分けて紹介したいと思います。

なお記事中にて技術面の言及はそれほどなされません。あらかじめご了承ください。

取り組んだ施策の振り返り

続きを読む

ユーザー満足度に注力するプロダクト開発におけるエンジニアの役割

ユーザー満足度に注力するプロダクト開発におけるエンジニアの役割

はじめに

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

プロダクト開発において、ユーザー満足度は最も重要な指標の一つです。私たちのチームではこの満足度をプロダクトゴールとして設定し、開発を進めてきました。本記事では、そのような環境下でエンジニアとしてどのように価値を提供してきたか、具体的な取り組みと成果を共有させていただきます。

※なぜユーザー満足度をプロダクトゴールに設定したのかについては、チームの PO が書いた下記の記事をあわせてご覧ください。

note.com

続きを読む

クラウドログ開発チームにおけるAI活用

はじめに

こんにちは、工数管理SaaS クラウドログ でエンジニアをしている越阪部です。

普段の業務では、Webフロントエンド関連の開発を担っています。

突然ですが、みなさんAIツールの活用進んでいますでしょうか?

直近では、コーディングエージェントを使っての開発や、MCPサーバーを使っての業務自動化など、AIツールの活用方法の発見と共有が賑わっており、もうAIのなかった頃には戻れないなと日々痛感しています。

クラウドログ開発チームでは、AIツールを業務に組み込むことで開発生産性の最大化を図り、顧客により大きな価値を提供できる体制を確立することを目指しています。この記事では、私たちがどういった取り組みをしているのかを、まだまだ試行錯誤を続けている段階のトピックが多いですが、簡単にご紹介したいと思います。

コーディングツールの導入と活用KPT実施

現在CrowdWorksでは、全社的な取り組みとして、コーディングのためのAIツールを配布し始めています。CursorClaude CodeGitHub Copilotといった選択肢が用意される中、クラウドログ開発チームでは主にCursorClaude Codeが選択されています。

これらのツールを個人のスキルとしてだけでなく、チーム全体の力として最大限に活用するため、週に一度「AIツール活用のKPT(Keep, Problem, Try)」というミーティングを実施しています。この会では、各々が見つけた「活用のためのTips(Keep)」や、直面している「改善が必要なこと(Problem)」をFigjam上に書き出して共有し、それらのProblemに対する「具体的な改善策(Try)」をチームで議論します。

KPTの様子

この取り組みの目的は、AI活用のナレッジをチーム内で平準化し、継続的に知見を蓄積していくことにあります。例えば、直近のKPTでは、Keepとして「Claude Codeのhooksを使えば、時間のかかる処理の終了をアラート通知できて便利」「ユニットテストの実装を任せると、高い品質で生成してくれている」といった具体的な成功事例が共有されました。

一方で、Problemとしては「顧客情報などのセンシティブな情報をAIに渡さないためのルール整備が必要」「AIツールを横断して、共通の設定やルールファイルを同期する方法を検討したい」といった課題が挙がっています。

このように、具体的な成功体験と課題をセットで共有することで、チーム全体でAI活用のベストプラクティスを模索しています。昨今のAIツール界隈は、技術の進化やトレンドの移り変わりが速いため、こうした定期的なナレッジ共有の場を持つことは、チームとしてAIを最大限活用していく上で重要だと考えています。

調査で大活躍Devin

クラウドログ開発チームでは、自律型AIツールであるDevinも導入しています。Devinは幅広い使い方が可能ですが、特に「不具合報告に対する一次調査」という領域で大きな成果を上げています。

Devinによる調査

クラウドログのコードベースには、歴史の長い箇所や、特定のメンバーしか普段触らない箇所も存在します。そのため、調査の内容によっては、調査を担当するメンバーの知識や経験に依存してしまい、誰もがすぐに調査できるわけではないという課題がありました。しかし、内外から報告されている不具合の対応は、他の開発タスクを進めながらも、迅速かつ確実に行わなければなりません。

Devinは、この課題を解決するのに非常にハマるツールとなっています。開発メンバーは、自身が取り組んでいる作業を中断し、ローカル環境のブランチを切り替えるといった手間をかけることなく、管理画面上から手軽に調査を依頼できます。さらに、今のところDevinはコンスタントに高い精度の調査結果を報告してくれており、非常に頼りになります。

一方で、機能の実装といったタスクにおいては、まだ期待する品質のアウトプットには至っていません。しかし、前述したような調査タスクにおいては、なくてはならない存在になりつつあります。

よりAI駆動な開発方法の模索

AIを一層活用するための開発方法の模索も始めています。現在、特に注力しているのが「仕様書からの実装生成」です。仕様書やコーディング規約を整備しつつ、AIに資料として提供することで、人間の介入を最小限に抑えつつ、品質が揃った実装を効率的に生み出す開発フローを目指しています。

資料構成のイメージ

このアプローチを現在開発中の新機能の開発で試しています。まだまだ手法を試している段階ですが、具体的に適用してみたケースとしては、ページの機能を整理した仕様書をAIに読み込ませて、Reactによるフロントエンド実装を試みました。結果としては、私たちが定義した設計方針に沿ったファイル配置を行ってくれたり、既存のAPI仕様書から生成された通信用の実装を適切に使用してくれたりと、活躍の可能性を感じる部分はありました。しかし同時に、実用化のために乗り越えるべき壁も発見されています。

例えば、AIは、内製のUIコンポーネントライブラリを知らないため、使って欲しい局面で使ってくれないことがあります。たとえばテーブルUIを実装する時に、独自コンポーネントの代わりに、標準的なHTMLの <table> タグで実装をしてしまうといったケースがあります。これはAIが「このUIには、このコンポーネントを使うべき」という文脈情報を持っていないのが原因と考えられます。今後は、ライブラリの情報を提供するMCPサーバーを実装することでAIに適切に情報を渡していくといった対策を試していきたいと思います。

また、別の観点では「AIの作業完了を待つ時間を人間がどう使うか」という課題も浮かび上がっています。たとえば、ページ全体の実装といった大きなタスクであれば、AIの作業完了を待つ間に別の作業ができます。しかし、より細かいタスクをAIに任せつつ他のタスクを行おうとした場合、頻繁なコンテキストスイッチが発生し、かえって生産性が落ちる可能性もあると考えています。タスクの粒度をどう設計していくかは今後の検討事項となりそうです。

また他にもチームでは、「AIを前提とした業務適用が進んだ時、エンジニアの役割はどう変わるのか?」がトピックとして上がっています。実装作業の多くをAIに任せるようになった時、エンジニアはこれまで以上に関連領域へと専門性を広げていく必要があるのではないかと思います。例えば、プロダクトオーナーのように上流のビジネス要件から開発を推進したり、セキュリティやアーキテクチャ設計といった、より高度な専門スキルを身につけたりすることです。

ビジネスサイド業務の自動化もやっていく

プロダクトの成長に貢献するため、AIツールの活用は開発業務だけに限定せず、ビジネスサイド業務の自動化も進めています。現在着手しているところとしては、商談後の議事録生成と顧客データ入力の自動化があります。

具体的には以下のようなフローを実現すべく検討しています:

  • プロダクトセールスが商談を顧客と実施
  • 商談中の動画を元に内容を文字起こし
  • 文字起こし内容から議事録を生成
  • 議事録の情報を元に、CRMスプレッドシートなどの情報を更新

こういった議事録の作成や各種ツールへの顧客データの入力は、商談の重要な情報を記録し、戦略検討や振り返りなどのために必要なものとなりますが、どちらかというと定型的な業務で、自動化できると嬉しい領域です。ビジネスサイド業務の自動化も進めていくことで、より本質的な業務に集中できる環境を作っていきます。

番外編: Vibe Coding実演会やってみた

AIの活用をより身近に感じることができるように、Vibe Codingの実演会を実施しました。個人的には、雰囲気でさくっとツールやスクリプトをAIに実装させる、という手法の利便性に可能性を感じており、それを普段の業務でも手段として思い出してもらえるようにとこの会を企画しました。

会の内容としては、FigmaのPluginの実装を要件定義から実装と動作確認までサクッと行うものとしました。作成したPluginは、指定した箇所にランダムに生成したテキストを挿入するという仕様としましたが、Geminiとの要件定義の壁打ちからGithub copilotでの実装生成までスムーズに進み、動作確認まで大きな問題なく完了することができました。

作成したプラグイン

この会を実施して、「短い時間で実装を完了させられたことに驚いた」「自分もAIで何かつくりたくなった」などの感想を参加者から得ることができました。今回は、AIを使ってサクッと実装をする便利さを知ってもらうことを目的としたため、実演形式をとりましたが、次回はハッカソンのように実際に手を動かすような形式でもやってみたいと思います。

おわりに

クラウドログ開発チームにおける、AI活用の取り組みをご紹介しました。目まぐるしく変化を続けるAIの世界では、積極的にキャッチアップしてとにかく試していくことが必要と感じています。AIツールはただ導入しただけでは最大限の活用は難しいため、チームとしてノウハウを収集、発見、共有を徹底することに加えて、AI自身が学習・参照しやすいナレッジの整理と蓄積も積極的に行い、最適な活用方法を確立していきたいと思います。

マネジメント経験が一切無いRailsエンジニアがEMになってから1ヶ月経ったので振り返ってみた

はじめに

クラウドソーシングサービス「クラウドワークス」( crowdworks.jp )でEM(Engineering Manager)をしている讃岐です。2022年11月に株式会社クラウドワークスに入社し、主にRailsでのサーバーサイドの開発を担当していました。

今回は、2025年の6月からEMという新たなロールに挑戦することになりましたので、その経緯と、最初の1ヶ月を走り抜けて今感じていることをお話しします。

経緯

自分がEMになった直接のきっかけは、上長である部長兼サービスCTOとの1on1でした。そこで「EMをやってみませんか」と打診を頂いたことです。

自分の目から見て、クラウドワークスのEMの方々は、組織や技術の課題に深く向き合い、プロダクトへの理解も非常に深い、エンジニアから多大な信頼を寄せられている頼もしい存在です。

そんなイメージがあったので、お話を頂いた当初は、正直なところ戸惑いしかありませんでした。というのも、自分は入社してまだ3年弱、しかも直近1年はAI関連の別プロダクトに携わっていたため、プロダクトへの理解にあまり自信がなかったからです。

あまりに自分の中のEM像とギャップがあったので、最初は冗談だと思っていました。が、上長から「半分冗談、半分本気です」と言われたとき、かえってその言葉に不思議な説得力を感じ、「これは本気かもなぁ」と思いました。

その言葉を受けて、「こんな自分でもこのプロダクトの成長のために役立てることがあるのかもしれない」と前向きに考えるようになりました。そして、その思いからEMの役割をお引き受けすることを決意しました。

今回は、そんな経緯でEMになった自分が、最初の1ヶ月を過ごしてみて何を感じたのか、振り返りながらお話しできればと思います。

感じたこと

役割が違う

AI関連のプロダクトでは開発リーダーとして動いていたのですが、チームで起きた問題はとりあえず自分が解決できるかどうか試す、無理なら他の人に回す、といった思考をしていました。

自分で対応できることは自分で巻き取り、他のメンバーにはそれぞれのタスクに集中してもらう。その方がチーム全体のスループットが上がり、開発がスムーズに進むと考えていたからです。

ただ、今振り返ってみると、このやり方が通用していたのは、もっと大きな問題が顕在化する前に、POや事業責任者の方々がうまく交通整理をしてくださっていたからなのだと感じました。

その感覚のままEMになった当初、自分は以前と同じように「まずは自分で何とかしよう」というスタンスでいました。しかし、EMとして向き合う問題は、開発リーダー時代に比べてはるかに規模が大きく、自分一人の手には負えないものがほとんどでした。

解決には時間もかかりますし、そもそもEMになったばかりの自分には解法自体もわからないものが大半なため、自己効力感がかなり下がっていました。

そんな風に少し思い悩んでいたとき、ふと、AIのプロダクトでお世話になった創業メンバーである取締役の記事に書かれていた言葉を思い出しました。

エンジニアという職業は、本質的には「課題解決」する役割であると考えています。それと対比すると、マネジメントという役割は「課題設定」、すなわちメンバーが解くべき課題(=この課題を解けば、目的・目標が達成できるという課題)を設定する役割です。

プレイヤーからマネージャーになって最初に越えなければいけない壁は、「課題解決」というエンタメを手放すことです。

(引用元:https://qiita.com/shinichinomura/items/457ba01b0fc67b37b775

僕が感じていた問題はまさに自分が課題解決というエンタメを手放せていないからであり、役割が変わったことを認識できていなかったから感じていたものでした。

それまでは少し気後れしていた大きな問題にも、この気づき以降は「自分の役割は課題を解くことではなく、まず設定することなのだ」と、スタンスの違いと自分の実力不足を素直に認めることで、不思議とフラットな気持ちで向き合えるようになりました。

視座が高くなった

EMに就任して最も大きなメリットだと感じているのは、自身の視座が格段に高まったことです。

今振り返ると、以前は自分が担当するプロダクト開発のことだけを考えがちで、事業としての側面や、グループ全体の戦略に対する理解を深めようという意識があまりなかったなと思います。

しかしEMの職務は、より事業に近いものが多く、日々向き合う中で、市場や事業戦略、そして組織について自ずと考える機会が増えました。現在は、まだまだ知識不足を痛感しつつも、勉強し始めています。

また、EMという立場になったことで、グループのマネージャー陣と交流する機会も生まれました。特に、グループのEMが定期的に集まる会議は、各社の事業や組織文化の違いを知れたり、客観的なご意見を伺える貴重な場となっており、良い文化だなと感じています。

自分はいちエンジニアのままではおそらくこういった視座にはならなかっただろうと思っているのでEMになって良かったと思いました。

時間がたりない

自分が担当するグループは、メンバーがそれぞれ異なる4つのチームに所属しています。そのため、一人ひとりに的確なフィードバックを行うには、各チームのプロジェクト状況や課題をなるべく把握しておく必要があります。

結果として、把握すべきコンテキストが広がり、参加する会議の数はエンジニア時代と比較して約3倍に増えました。以前好きだった集中して作業できる会議のない日を設けることも今では難しい状況です。

自分は何事もある程度準備を整えてから臨みたいタイプなのですが関わる業務領域が広がったことでその準備時間を確保するのが難しく、これまで以上にシビアなタイムマネジメント能力が求められていることを痛感しています。

そのため始業直後と終業直前にタスクの整理や分解を行い、タスク完了までのステップを明確にして空いた時間にすぐに作業に取り組めるようにするなど、効率よく少ない時間でタスクを実施できるようにしています。

知識不足

EMになる直前の一年ほどは、新規事業でのAI開発や社内向けのAIエージェント構築に注力していました。そのため、現在のプロダクト領域から少し離れてしまっており、ドメイン知識のキャッチアップに苦労しています。

各チームの状況を把握したり、EMとしての新しいタスクに慣れたりすることに時間を使っていると、なかなか腰を据えて学ぶ時間が取れないのが正直なところです。

それに加えて、これまでのエンジニアとしての視点だけでなく、マネージャーとして経営的な視点も持つ必要があり、求められる知識が本当に増えたなと実感しています。

この前、営業でマネージャーをしている友人と話してみたのですが、営業の場合はピープルマネジメントの大変さはあっても、ここまで新しい知識分野が増える感覚は少ないようでした。

エンジニアリングマネージャーという役割は、技術とビジネス、そして組織と、本当に幅広い知識が求められるのだなと改めて感じている次第です。

終わり

自身の力不足を痛感し続けた、というのがこの1ヶ月の率直な感想です。

ただ、開発組織をより良くしていくことに直接的に関与できる立場になりました。この役割を通じて、エンジニアの皆さんがより働きやすく、成果を出しやすい環境を作れるよう、貢献していきたいと思います。

We're hiring!

クラウドワークスではエンジニアを募集しています。興味のある方は以下のリンクからご応募ください!

https://herp.careers/v1/crowdworks/AaOS_he9juwD

© 2016 CrowdWorks, Inc., All rights reserved.