業務効率化には強化された Slack のワークフローがオススメ

はじめに

こんにちは。家にいる時間が長くなってからジャンキーなベジタリアン料理が趣味になっている大浦です。(おからこんにゃくのカルビ丼おいしいですよ！) ここ最近 Slack のワークフローのステップにアプリが追加されたことにより非常に便利になったので、そのひとつの例を書いていきたいと思います。ワークフローについては去年末に「Slack ワークフローをさわってみた」という記事を投稿してますので参考にしてみてください。

本記事で扱うアプリのステップ

Google Sheets for Workflow Builder https://slack.com/app-pages/google-sheets

Google スプレッドシートの行の追加に Slack が使えるようになって業務効率化が捗ります。🎉

https://slack.com/apps/A01AWGA48G6-google-sheets-for-workflow-builder

何に使える？

下記のような 頻度は低いがそれでも一定発生する業務 に向いているでしょう。

• 相談窓口
• 稼働報告/管理
• 従業員の体調報告/管理
• 定期的なミーティングやイベントのフィードバックの収集

逆に、頻度が極端に低くかったり高かったりする業務だと、Slacck ワークフローは使わず、直接スプレッドシートに書き込んだり、専用のUIを設けたりしたほうがよいと考えます。当人のコンテキストスイッチの負荷が目安というところで、なかなか塩梅が難しいところですね。

クラウドテックのテーブル構造を改善していった話

はじめに

クラウドワークスの運営する クラウドテック というサービスで開発に携わっている @hamajyotan といいます。ここでは、最近クラウドテックのデータベース構造の課題を解消した話をします。

クラウドテックは、ハイクラスなフリーランス IT・WEB エンジニアやデザイナーに特化したマッチングサポートサービスとして 2015年4月から始まったサービスです。サイト自体は Rails 4.0 あたりからスタートし、現在 Rails 6.0.3.3 で動いています。

データはアプリケーションより長寿なので改善を要する

一般に、データ(ベース) の寿命はアプリケーションの寿命より長いと言われています。例えばシステムの統合、あるいはシステムのフルスクラッチなどがあったとしてもそれとは別観点でデータベースはそのまま残すか否かは検討の余地があり、そしてそのまま既存のデータを引き続き扱うことも多いです。

そして、データに長く付き合うためにはプログラムと同様、頻度の差はあれど定期的なリファクタリングはあるべきでしょう。 プログラムと違い、 Security Fix や Rails バージョンアップの変更に追従するなどの動機はあまりありませんが、少し前にバズっていた技術的負債の解消などはデータベース構造のリファクタリングの動機となりえます。

改修前のざっくりとした構造

今回の話題の登場人物を示しています。

※ ここでの名前は、ある程度抽象したものに置き換えており実際の名前とは異なります。

• 「ユーザ (User)」はクラウドテックに登録くださっているユーザそのものを表します。
• 「クライアント (Client)」はクラウドテックに案件を提供くださっている企業を表します。
• 「案件 (Project)」は、特定のクライアントの案件を特定のユーザが実施する業務を示し、通常 3ヶ月前後の期間で実施されます。
• 「月間作業報告 (MonthlyReport)」は、ユーザが案件の業務を実施する際の作業報告書のイメージです。
  • 月ごとに分かれており、例えば 1月から3月までの3ヶ月間の案件であれば、1レコードの案件から 3レコードの月間作業報告が発生することになります。
  • 「案件ID × 年月」 の組み合わせで、一意制約がかけられています。
• 「クライアント請求 (Bill)」および「ユーザ支払 (Payment)」は、月ごとの稼働の検収を経て、クライアント/ユーザそれぞれに対する請求/支払を意味するデータです。
  • 「月間作業報告」と同様に月ごとに分かれており、例えば3ヶ月間の案件に対しそれぞれ 3レコード発生することになります。
  • 「案件ID × 年月」 の組み合わせで、一意制約がかけられています。

クラウドワークスのWebアクセシビリティチェックを始めてみた

こんにちは。フロントエンドエンジニアの yamanoku と申します。

最近久々に出社しましたが、どうやら半年以上も出社していなかったことに驚愕しました。自分自身が違和感なくリモート作業やれているのかもなぁという気づきにもなりました。

前回の記事では東京都 新型コロナウイルス対策サイトの Web アクセシビリティチェックをしたという話をしました。

engineer.crowdworks.jp

今回の記事では、チーム内でクラウドワークスの Web アクセシビリティチェックを実施してみた話をします。

【Vue.js】負債を返却しながら機能追加しなければならない状況で実践したフロントエンドのコンポーネント設計

はじめに

こんにちは！ 社会人2年目を頑張っております、エンジニアの@b0ntenmaruです。

今年2月までリファクタリング専門チームにてcrowdworks.jpの技術的負債を返却するために奮闘しておりましたが、そこから現在まではユーザーの皆様に安心安全なサービスを提供するためにクラウドワークス 安心安全宣言のための施策を行っています。

リファクタリング専門チームについては以下をご覧ください。

engineer.crowdworks.jp

qiita.com

施策による機能開発を行う際に直面した課題

施策では主にフロントエンドの機能追加をすることになったのですが、技術的負債によりスピードを維持しながら開発を続けることは困難な状態でした。 crowdworks.jpを取り巻くフロントエンドの技術スタックはざっくり書くと下記3つに分類できます。それぞれで発生している問題を簡潔にまとめます。

ERB

• html.erbファイルにif分岐や業務ロジックが直接記述されており、かつ同様の記述が複数ファイルに散らばっている

※ ERBはcrowdworks.jpで採用されているRuby on Railsのテンプレートエンジン

CSS

• 秩序なく数年上書きされ続けたCSSが無数に存在していて、意図したように実装できなかったり意図しないページのデザインが破綻してしまうことが頻繁にある
• 変更による影響範囲の特定が困難、かつできたとしても調査に時間がかかる
• CSSの中には!importantで上書きされ続けたCSSも多数存在しており、新規のデザインを適用される場合やむをえず!importantを上書きするしかない場合がある

jQuery

• 古の時代に書かれたjQueryのイベントハンドラが大量に張り巡らされており、変更を加えると意図しないページで破綻していることがある
• そもそも読むのに膨大なエネルギーを消費する
• 変更による影響範囲の特定が困難、かつできたとしても調査に時間がかかる

このような課題があり、スピードを維持して開発が続けられるよう機能追加だけでなく負債の返却作業をする必要もありました そこで、関心事を集約して複雑なUIを確実かつ堅牢に組み上げる手段であるコンポーネントベースの思想を取り入れ、かつ今後の負債化を防ぎ、持続的に開発していくためのコンポーネント設計を考えました

※ crowdworks.jpではVue.jsを採用

この記事ではhtml.erbからVue.js置き換えなど負債を返却しながら機能追加していく時に実践したフロントエンドのコンポーネント設計について書いていこうと思います。

実録：「えっ、このシステム何ですか？」から始まる小さな引継ぎのおはなし。

はじめに

みなさまこんにちは。なんとか生き延びております、たかのです。

いきなり本題ですが、事業を長く続けていると、サービスの中核のシステムは肥大化します。 複雑さが増せば、理解も運用も大変になってきます。

そんな複雑さを回避するために、小さい単位で機能を分割し、別システムに切り出すことはよくあることです。 クラウドワークスにも、中核のシステムを支える小さなシステムがたくさんあります。

生きているからこそ、お世話がつづくのです

システムは生き物です。（そうは思えないかもしれませんが、そんなものと思ってみてください！*1）

稼働はしていても拡張や整理の判断ができず、「属人化」どころかその進化系で、作った人が退職して詳しい人が誰もいなくなってしまったもの。 そんな状態を、わたしたちの職場では「無人化」と呼んでいたりします。

こうした状況は望ましくないので、メンテナンスを仕組み化し、チームで分担して取り組むようにしています。

さて、わたしたちのチームも、この「無人化」対応のタスクを1つ担当することとなりました。 その際のあれこれや学びについて、わたしの「 余技 」をふまえてお伝えします。

見積もりするよ！

*1:お母さんが言うんだから間違いありません！