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

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

維持・効率化チームの振り返り

f:id:tatsuhiro-oishi:20211022182238p:plain

こんにちは。 クラウドワークスのサービスはまもなく10周年を迎えます。

ユーザーの皆さまに喜んでいただけるよう、これまで様々な施策を打ってきましたが、その間、維持を後回し(借金)にしたことによる問題が蓄積し、必要となる維持コストが当時の想定より増大してしまっている問題があります。

その結果、多くのエンジニアリングリソースを割かないと解決できない問題や、新たな施策を開発する際の負債となって立ちはだかってしまいます(しまいました)。 この借金を少しでも返済すべく、 2020 年 9 月にシステム・サービスの維持とエンジニア業務の効率化をミッションとするチームが作られました。

ミッション

  • 維持しているメンバーを明確に見える化し、定常的に取り組みが行えるようにする
  • 不足を補い、正常な維持が行えるように人のアサインを行う
  • 放置されていたプロダクトの整理を行う
  • 思い思いに構築されているシステムの整理を行う
  • エンジニアが動かないと情報が得られない・対応できない事象を減らす
  • 特定のメンバーのスキルに依存していたり、精神的負担の高いマニュアルオペレーションを削減する

今回のブログでは、維持・効率化チームの 1 年間の活動の振り返りをお伝えしようと思います。

目次

タイムカードアプリのWeb化

背景

クラウドワークスには色々な仕事の契約形態があります。 その中の一つに時間単価制の契約があり、その名の通り作業した時間に応じた報酬が発生します。 クラウドワークスでは時間単価制の作業時間を計測するためにCWタイムカードというものがありました。

問題点

CWタイムカードは弊社の特許 (プレスリリース:オンラインで稼働時間をカウントできるアプリ「CWタイムカード」の特許を取得 時間単価制契約の急成長を支える) を利用し、作業時間・休憩時間、作業中のランダムなスクリーンショット・キーボードタイプ数・マウスクリック数を記録していました。 (※ 保存が好ましくないものに関しては作業者が個別に削除ができます)

このアプリは独立したプログラムで Windows, Mac, Linux 用をそれぞれ開発・提供しており、メンテナンスコストが大きなものになっていました。

検討

まず、上記のような機能は今も求められているのか、というところから調べました。

上記のデータの利用に関するユーザーの皆さまへのヒアリングを行うことで、削除することによる大きな影響はないという調査結果を得ました。

それにより、単純な Web アプリへの移行方針を立てることができました。

実施

幸いにも、同時期にデザイナーチームによるデザイン基盤更新プロジェクト(生まれ変わったログインページとデザインシステムのスタート)があり、デザイナーチームに良い機会と捉えていただき全面的な協力を得ることができました。

先日リリースされたログイン画面更新に続き、Vue.js を利用した新しいデザインを全面的に採用しました。その中で、

  • Storybook を用いることで、よりUI・デザインに時間をかけることができました。
  • フロントエンドの知識が浅かったため、フロントエンドに強い他チームのレビューを受けました。

チーム内外の協力のもと、より良いユーザー体験を提供できるように実装できました。

テクニカルサポート改善

問題点

ユーザーサポートのみでは解決できない問い合わせや問題が発生した場合、エンジニアに調査依頼をするテクニカルサポート案件(通称テクサポ)というものがあります。 ユーザーサポートが Redmine で依頼事項を起票し、その日の当番チームが対応する運用となっているのですが、

  • ユーザーサポートは起票に時間が取られる
  • エンジニアは現在の作業の手を止めて対応する必要がある
  • 案件によっては数時間かかる
  • 日をまたいで対応しなければいけないこともある

という、とてもコンテキストスイッチコストが高い作業となります。 お問い合わせ等をいただいたユーザーの皆さまにも問い合わせコストと待ち時間が発生するので、関わる人全員のコストがかかってしまいます。

検討

問い合わせを減らし、ユーザーサポートのみで解決できることを増やすべく、以下の取り組みを始めました。

  • Redmineチケットの解析
    • これまでのチケットを内容ごとに集計
    • 管理画面化やユーザー自身で解決可能な機能実装を検討
    • 改善の費用対効果の見積もり
  • ユーザーサポートとブレスト会
    • Jamboard に各人がつらみ・疑問を貼っていく
    • 問題のグループ分け
    • 改善の費用対効果の見積もり
  • ユーザーサポートとの定例会を検討
    • ユーザーサポート・エンジニア間の悩みの共有
    • お互いに相談しやすい環境づくり
    • 実は簡単に改善できるものがあるかもしれない

実施

ユーザーサポートとの定例会 定例会を開催するようにし、以下の内容を話すことにしました。

  • 困っていることについて共有
  • サービス上で起きた問題について説明

これまでユーザーサポートとエンジニアとの間でコミュニケーションをとる場がほとんど有りませんでした。 こういった場を設けることでエンジニアに相談しやすい環境になったと思います。

管理画面作成の推進

これまでテクサポで対応しているもので、効果の高いもの・低コストで対応できるものをピックアップし、管理画面作成を進めて、ユーザーサポートだけで対応できるようにしました。

f:id:tatsuhiro-oishi:20211022184202p:plain

また、発生頻度は少ないが発生すると調査コストが大きいものをRedash化し、ユーザーサポートに共有しました。

これらの対応を進めたことで、テクサポ件数を半分以下に抑えることができました。まだ改善できるところはあるので今後も進めていきたいです。

f:id:tatsuhiro-oishi:20211022184237p:plain

経理改善業務

背景

クラウドワークスのサービスは、クライアント(発注者)・ワーカー(受注者)間で契約が成立した段階でクライアントがクラウドワークスへ支払い(仮払い)を行い、お仕事が終了した段階でクラウドワークスからワーカーへ報酬が支払われる、という仕組みになっています。 この仕組みによって、クライアントが自身で「検収」をするまでワーカーへの支払いは行われず、ワーカーも作業に対する報酬が支払われることを保証しています。

クライアントがクラウドワークスに仮払いしたお金は「預り金」と呼ばれており、毎月初に預り金集計作業を実施してシステムが管理している預り金関連のデータを経理報告し、経理で管理している会計データとの突き合わせを行って間違いや不正等が無いことを確認しています。

この突き合わせにおいて、もし両者の間に差異があった場合にはその原因を調査・特定し、会計上問題がない旨の確認を実施して管理しています。

問題点

このように厳密な管理を実施している預り金ですが、システムが管理している預り金関連のデータと経理で管理している会計データとの間に差異が発生してしまう場合があります。 例えば、決済サービスとの間で障害が発生して入金・出金処理が失敗したため、手動で代替操作を行ったなど、システムで想定していないイレギュラーな処理がシステム外で行われ、その結果をシステムに取り込むことが難しいようなケースです。

当然、この発生してしまった差異は月次の集計作業・経理報告・突き合わせの中で原因の調査・特定と会計上問題がない旨の確認を実施して管理していますが、先述のようにクラウドワークスのサービスは 2012 年から約 10 年間弱という長期に渡って連続稼働しているので、このような差異が積み重なっていました。

検討

各差異の発生経緯・原因を再確認し、どのように差異解消を実施するか、経理有識者を交えて検討しました。

実施

2021 年 9 月に差異解消(システムに取り込めていなかったイレギュラー処理を、システムに取り込む対応)を実施しました。 現在、データを経理報告し、経理で管理している会計データとの突き合わせを行って差異解消が妥当に実施されているかの確認を実施している状況です。

あわせて、経理メンバーとの勉強会を継続実施し、共通合意・共通認識を形成して、今回のようなマイナスを回復するような作業だけではなく、プラスを生み出すような抜本的な経理改善につなげていきたいと考えています。

システムの維持活動

後回しになっている課題同様に現状稼働しているサービスの老朽化への対応についても今期チームで維持活動として行いました。 具体的に上げると、使用しているツール、周辺システムの各種バージョンアップの対応がスコープになります。 今期対応した中から一例として仕事検索などで使われている Elasticsearch バージョンアップの話を書きたいと思います。

クラウドワークスでは、仕事情報やワーカー情報、レコメンド情報を Elasticsearch に投入しており、障害が起こると会員、非会員問わずサービス運用上多大な影響がでます。 しかし、現状 Elasticsearch を専門に管理しているエンジニアはおらず EOL の時期が来ると持ち回りで対応を行うことになっています。

以前もバージョンアップについてエンジニアブログの方で取り上げたので気になる方は以下をご参照下さい。

今回は 7.5 系から対応開始時点(2021 年 4 月)での最新となる 7.12 系まで上げましたが、マイナーバージョンのアップデートということもあって過去のアップデートと比較して修正する点がほとんどなかったのが幸いでした。

対応として一番大きかったのが、Elasticsearch を操作するために必要な gem である elasticsearch-ruby が他の API 系 gem でも使っている Faraday に依存しており、 elasticsearch-ruby 7.12 に上げるためには Faraday のメジャーバージョンを 1 系に上げる必要があったことです。 他の gem との依存関係や影響範囲を調べて整合性を担保するのはコストが高く、モノリシックな規模の大きなサービスは管理が楽である反面意図しないところでバグが発生する危険性があることを再認識しました。

次回の対応は 8 系が出てからになると思いますが、メジャーアップデートは破壊的変更が怖い反面新機能やパフォーマンス向上などが見込めるので楽しみです。

その他にやったこと

先述のもの以外にも、細かいことを対応してきました。 小さなことですが、今振り返ってみるとエンジニアのコンテキストスイッチの減少など大きな効果を実感しています。

  • Ruby on Rails で使用している gem を日々更新
  • エラー通知の管理
    • 一部エラー通知内容の棚卸し
    • 本当に必要なエラーのみを通知するように改修
  • 機能の剪定
    • 機能の存続価値を見直し
    • 関連コードの削除
    • 関連データの削除
    • プロダクトをシンプルに保つ
  • 銀行とその支店情報の最新化の効率化
    • 統廃合情報などをエンジニアが手動で登録していた
    • 誰でも簡単に最新の情報に更新できるようにデータ登録機能を開発
  • 持続的な不正利用に対する取り組み
  • ルーズボールの対応
    • これまで手をつけらていなかった小さな改善

振り返ってみて

改めて多くの改善を行ってきたのだと感慨深いです。 今後、15年20年とサービスを続けていくための取り組みを続けていきたいと思います。

We're hiring!

クワウドワークスでは、目の前の問題・課題を改善していくことが大好きなエンジニアの方を募集しております!

www.wantedly.com

© 2016 CrowdWorks, Inc., All rights reserved.