クラウドワークスの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:お母さんが言うんだから間違いありません！

Amazon LinuxのEOLに伴いバッチをサーバレス化しFargateに移行した話

はじめまして、2020年3月に中途入社したSREチームの @bayashiok です。

今回は入社後、Fargateでサーバレスバッチ基盤を構築した話を書いていきます。

目次

経緯

日々のSREチームのタスクの中で、EOLとなるソフトウェアの状況を定期的にチェックしているのですが、今回 Amazon Linuxが2020 年 12 月 31 日にEOLを迎えるということで、Amazon Linux上に設置されているシステムを移行する必要がありました。

Amazon Linux2に移行するという案もあるのですが、このままでは負債(後述記載)が残ってしまうためAmazon Linux上に置いてあるバッチの整理と移行バッチのFargate化を行いました。

Fargateを選んだ理由

Fargate化することのメリットは次のようなものがあげられます。

クラウドワークスを退職します。

お世話になったオフィス

こんにちは、@ysk_118 です。
実は2020/06/30をもって退職することになりました。
2015/05/18に入社していますので5年とちょっと在籍していたことになります。

時系列とKPTでこの5年を振り返ります。

whoami

この5年で非常に多くのことに携わりましたので、まず軽くやってきたことを振り返りながら何者なのか知っていただけたらと思います。

• 2015/05〜2016/03: 開発Div. エンジニア
• 2016/04〜2017/02: プロダクトDiv. 新規事業開発グループ チームリーダー
• 2017/02〜2018/03: プロダクトDiv. エンジニア -> スクラムマスター -> プロダクトオーナー
• 2018/04〜2019/04: プロダクトDiv. エンジニアリング部 部長
• 2019/05〜2020/06: 執行役員, エンジニアリングDiv. GM, 人事兼務¹

クラウドワークスに入社した当時は新卒3年目でまだ経験的にも浅く、エンジニアとしてしっかりキャリアを積んでいきたいという一心でいろいろな会社を受けていたところ、運良く拾ってもらえたので非常にうれしかったです。

そこから2年ほどエンジニアとして様々なプロジェクトに関わり、その後スクラムマスターやプロダクトオーナーとしてプロダクトや組織そのものへアプローチを1年ほど。さらにその後組織全体をみていくポジションに手をあげ、マネージャーや執行役員として会社全体の中でのエンジニアリングを考える役割を2年ほどやってきました。

こうしてみると自分で手を動かすよりもマネジメント寄りのことをしている時間のほうが若干上回っていそうです。当初の目的であったエンジニアとしてのキャリアを突き詰めるよりかはなんだかんだジェネラリストを極めた結果になってしまいましたw

---

1. Div.=Division(部署) GM=General Manager(部門責任者)↩