はじめに
こんにちは！READYFORでフロントエンドエンジニアをしております、江面（ @neripark ）と申します。 最近は主に Next.js （TypeScript）を用いたSPA開発に従事しております。CSS設計、コンポーネント設計、Netlify などが好きです！
本日はタイトルにもある通り、既存のRailsアプリケーションにCSSコーディング規約を導入したお話をしようと思います！ 既存のプロダクトのCSSで苦労している方の参考になれば幸いです。
続きを読む「リモートワーク成功・失敗事例〜コロナに勝つエンジニア組織〜」 にVPoE伊藤が登壇しました！#六本木スタートアップ
皆さま、こんにちは。READYFORでエンジニア採用担当をしております、西和田です。
東京では新型コロナウィルスの感染者がまた増えてきており、第二波も懸念されているる状況です。そんな「ウィズコロナ」の今、どの企業も向き合うことを避けられないのがリモートワークです。
今回は、そんなリモートワークにまつわるオンラインイベント、for Startups主催の「リモートワーク成功・失敗事例〜コロナに勝つエンジニア組織〜」に弊社VPoE伊藤が登壇し、セッションに参加させて頂きました。
今回、弊社の他にfor StartupsのCTO戸村さん、アンドパットのVPoE下司さんがセッションに参加されていました。 まず初めにそれぞれの会社紹介のお時間を頂き、READYFORからは、会社概要の他に「乳化」や「Tech value」のお話もさせて頂きました。
READYFORが目指す乳化とは
「組織の中に自然にエンジニアリングが溶け込んでいる状態」のことです。
またTech valueでは、プロダクトチームが目指すTech vision valueを紹介させて頂きました。 これはもともとREADYFOR全社のvalueとしてある７つの要素を、プロダクトチーム用にアレンジされたものです。
さて、続いてはセッションです！
一つ目のテーマ 「リモートでもスムーズに開発できましたか？」
for Startups戸村さんから「slackで毎日日報を報告するようになりました！」アンドパットの下司さんからは、「弊社では、通勤時間がなくなった分、毎日10分ほど(歯磨きをするかのような)勉強会を、任意で開催するようになりました！」などお話して下さる中・・ READYFORのリモート状況について、下記のお話をさせて頂きました。
コロナの前は、全社的に週１リモートOKという勤務ルールでした。READYFORでは、コロナウィルス感染拡大を受け2月の後半から、原則在宅勤務開始（必要に応じて出社）となりました。緊急事態宣言中は「原則出社禁止」となり、緊急事態宣言が解除されてからは禁止ではないが「基本はリモートワーク」というルールです。
エンジニアチームでいうと、通勤時間がなくなって、みんな水を得た魚みたいになっていました（笑) もともと毎日開催している朝会もオンラインになっただけですし、エンジニアは通信環境が整っている人も多いので、大きなデメリットはなさそうな印象で、生産性高く業務をこなしています。 ただ、これからこの状態が1年以上続いた際に、何か課題は出てくるかもしれませんね。（伊藤)
※READYFORでは、全社リモートワーク中に入社したエンジニアもいます。 リモート入社について、詳しくはこちらの記事をご覧ください。
※全社リモートワーク期間の詳しい様子はこちらの記事をご覧ください。
二つ目のテーマ 「第二波に備えていますか？」
特別第二波に備えるというより、より今の環境に合ったスタイルを突き詰めているという状況です。 例えば、READYFORの開発チームでは、オンラインもくもく会（勉強会）を実施したり、それぞれがslackのtimesでコミュニケーションをはかったり、最近だとお昼にオンラインラジオを開催するメンバーもいます。こうやって、それぞれのアイデアでリモート環境をより充実させていっています。（伊藤)
三つ目のテーマ 「リモートワークでも活躍できる人材とは？」
アンドパットの下司さんからは、「対面でのコミュニケーションが減る分、slack等で今少し話せますか？とちゃんと言えることも大事ですよね。」とお話される中、以下のようなお話をさせて頂きました。
今、選考もほとんどがオンラインで実施されていますよね。私は、以前から選考時にホワイトボードを利用していたのですが、オンラインになってからは、 Googleのdocsやジャムボードを活用しています。「オンラインのツールを使って、物事を言語化できるかどうか」はとても重要だと思っています。選考フローの中に、弊社のエンジニア複数名が参加してオンラインで雑談するような場面もあるのですが、やはり実際の対面と比較するとオンラインの雑談をどう滑らかにするかは課題ですね（伊藤)
いかがでしたでしょうか？ 誰もが向き合わなければいけない「リモートワーク」について、エンジニアもそうでない方もこの状況を少しでも前向きに捉えられるよう工夫し、更に強い組織にしていきたいですね。今回のイベントでは、Twitterでも多くの方が#六本木スタートアップをつけて感想を投稿してくださり、盛況の中イベントを終えました。
主催頂いたfor Startupsさん、ご視聴頂きました皆様、ありがとうございました！
READYFORは、引き続き絶賛エンジニア募集中です。これまで「現職が忙しくてなかなか話を聞くことができなかった・・」という方も、移動時間のないオンライン面談が可能な今こそ、ご興味のある方は是非カジュアルにお話させてください。ご連絡お待ちしております！
＜募集職種＞
フロントエンドエンジニア www.wantedly.com
バックエンドエンジニア www.wantedly.com
プロダクトマネージャー www.wantedly.com
500行超のスパゲッティコードなメソッドを10行に整理したお話
こんにちは。toyocです。READYFORでエンジニアをやっています。
最近までバックエンドフロントエンド問わず不具合を直したり、古くなって手がつけられないコードやモジュールを掃除したり、
もくもく会で料理したり、用務員のおじさん的な働きをしておりました。
この記事ではお掃除の一環で、500行超のスパゲッティコードなメソッドを理解・分解・再構築して10行に整理してまとめた話をします。
- 対象となるメソッドについて
- メソッドを理解する
- メソッドを分解する
- メソッドを再構築する
1.対象となるメソッドについて
READYFORには実行者が開設するプロジェクトページがあるのですが、今回対象となるのはその更新を担うメソッドになります。
プロジェクトページは大きく分けると下記の4つの情報に大別されます。
①タイトルなどの基本情報
②プロジェクトの説明
③支援者が選択するリターン
④検索などに使われるタグ
実際に実行者がプロジェクトページを編集する際は、それぞれについて1画面ずつ計4画面を遷移しながら編集していくことになります。（執筆時点）
それぞれの画面からフォームを送信していくわけですが、送信先は1つのエンドポイントに集約されています。
さらに、①や③には画像情報も含まれるのですが、それをAjaxで非同期に更新できるようにもなっています。これの受け口も同じエンドポイントです。
ここからさらに話が複雑になるのですが、READYFORでは現在実行者に「シンプルプラン」「フルサポートプラン」の2つのプランでサービスを提供しています。（執筆時点）
（ご興味ある方はこちらをご覧ください）
それぞれのプランで提供機能に差異があり、更新の挙動が異なります。特に「シンプルプラン」は提供サービスの仕様上、プロジェクトの公開前と公開後でも挙動が変わってきます。
つまり、まとめると1つのエンドポイントで下記のパターンを全部引き受けています。
（①〜④のフォーム送信 + ①③の画像Ajax非同期通信）×（フルサポート + シンプルプラン公開前&公開後）
そしてその処理内容はほぼ一つのメソッドの中にたくさんのif文と共に記述されています。
これが今回対象となるメソッドです。
とても複雑なコードになっているのは想像に難くないと思います。
（ちなみに、循環的複雑度を測ってみたら64でした。一般的には50以上は複雑すぎてテスト不可能、バグの温床になるとか。やばいですね。）
2.メソッドを理解する
このメソッドを整理するにあたり、中でどんな機能を担っているのか理解する必要がありました。
ということで、まずは各パターンの条件と入力でどんな結果が期待できるか、テストコードに書くことから始めました。いわゆるブラックボックステストですね。
しかし、前述したとおり、とても複雑なので、正常系のテストだけに絞ることにします。
それでも、パターン数が多いこともあり、書き上げてみたらテストコードだけで900行ぐらいの量になりました。
書き上げることで、おおよそ機能は理解できました。次に中の処理を詳しくみながら分解していくことにします。
3.メソッドを分解する
テストを書くことはできたので、えいやで色々いじってもテストさえ通れば少なくとも正常系については問題ないはずです。
というわけで、前述した下記のパターン毎にメソッドを分割し、可読性をあげようと思います。
（①〜④のフォーム送信 + ①③の画像Ajax非同期通信）× （フルサポート + シンプルプラン公開前&公開後）
ここではif文だけを見ながらなるべく機械的に分解してくことにします。
1.まずはフルサポートorシンプルプラン公開前orシンプルプラン公開後、の3つのパターンごとにメソッドを分割します。
# before def update # 500行の複雑なコード end # after def update if シンプルプラン && 公開後 simple_plan_after elsif シンプルプラン simple_plan_before else full_support end end
2.分割メソッドにはそれぞれ元々の分割前のメソッドの内容をコピペします。
def simple_plan_after # 500行の複雑なコード end def simple_plan_before # 500行の複雑なコード end def full_support # 500行の複雑なコード end
3.それぞれの分割メソッドのなかで、プランの条件にそぐわないコードを削除します。
def simple_plan_after # フルサポートプランや公開前の場合分けを削除したコード end def simple_plan_before # フルサポートプランや公開後の場合分けを削除したコード end def full_support # シンプルプランの場合分けを削除したコード end
4.同じやり方で、フォームの種類や、Ajaxリクエストかどうか、といったパターン毎にさらにメソッドを分割していきます。
def simple_plan_before_json_basic # 読む気になれるシンプルなコード end def simple_plan_before_json_reward # 読む気になれる短めなコード end def simple_plan_before_html_basic # 読む気になれる（以下略 end def simple_plan_before_html_story; end ... def simple_plan_after_json_basic; end ... def full_support_html_basic; end ...
分割することで500行1メソッドだったコードが、平均24行程度のメソッドになり、だいぶ可読性が上がりました。
4.メソッドを再構築する
分割したコードを一つ一つ見ていくと、このパターンとこのパターンはまったく同じ処理だった、このパターンは今では想定されてないパターンだった、
など色々整理できるところが見えてきました。
あとは適宜テストが通るか確認しながら、同じ処理内容を切り出したり、不要な処理を削除したりしていくだけです。
ただし、先ほど書いたテストは正常系だけなので、異常系については別途テストを行う必要があります。
まとめ
最終的に比較してみると下記のようになりました。
| before | after | |
|---|---|---|
| メソッド数 | 1 | 26 |
| 1メソッドあたりの 行数 |
500 | 23.6 |
| 1メソッドあたりの 循環的複雑度 |
64 | 3.6 |
| 可読性 |  |
 |
なんとなく成果があるように数字を並べて比較してみましたが、実際、肌感覚として読みやすく触りやすいコードになったんじゃないかなと思います。
ということで、複雑で手が付けられないように見えるコードも、挙動を理解し、理解に基づいて分解し、可読性を上げた上で再構築することで、手を入れやすい簡潔なコードにできるお話（という一例）をご紹介しました。
スパゲッティコードでお悩みの方の参考になれば幸いです。
Storybookをホスティングしてレビューが爆速になった話
こんにちは、エンジニアリングマネージャーの岡村です。
社員全員テレワークの環境にも慣れてきて、ワークフロー改善と共にREADYFORの開発環境も日々改善しております。
概要
StorybookをNetlifyへホスティングすることで、PR単位でデプロイされるためデザインの確認・レビューがとても楽になったので紹介です。
導入の背景
READYFORのアーキテクチャ上もっとも有効だった
ざっくりREADYFORのフロントエンドアーキテクチャはReact On RailsとElements(UI Library)で構成されており、デザイン手法にAtomicDesignが採用されています。 Elements(UI Library)はDesignSystemの一部として構成され、ドメインに依存しないコンポーネントはElementsへ開発しています。 そのため、確認をする際にはElementsのコンポーネント・READYFORのコンポーネントをそれぞれに確認する必要があります。
レビューコストがかかっていた
コンポーネントデザインを同じ粒度で確認できるようにStorybookを導入しています、しかし、デザイナー・PMへのレビューを行うための環境作成コストは負荷がありました。
PRをレビューブランチに反映or画面共有で確認してもらう必要があった。
弊社ではスクラム開発を採用しているため、スプリントレビュー時に都度この工数が発生していた。 また、開発中に確認をしてもらうのにその場で画面を見せたり（今だとハングアウト・Zoomなど）していました。
Storybookをホスティングし解決
この問題を解決するためにNetlifyのPR Previewを利用しました。
これによりPR毎にStorybookをbuildすることでPR単位のレビューが安易になりました。
デザイナーはURLを共有することでいつでも確認が可能です。
URLはGitHubのPRにリンクが貼られるためデザイナーからのレビューもPR上で行いやすくなります。
現場デザイナー・PMインタビュー
実際に現場のデザイナー・PMへStorybookについて聞いてみました
PM（江藤さん）
個人的には「レビューが手軽にできるようになった」がメリットだと感じています！ もしStorybookがないとすると... テスト環境に上げる工数がかかる テスト環境の数自体が限られているので、同時に複数Issueを進める場合に利用環境の調整コストもかかる ので、この2つのコストが抑えられているのがデカイと思います。
上記2つのコストが抑えられた結果として... 「とりあえず動くものを作ってPMに見せちゃおう」となり、 PM-ENG間のコミュニケーション量が増えて、 認識の齟齬が早期に解消できるようになったと思います！デザイナー（今野さん）
Figmaのコンポーネントと名称を統一しているため、コミュニケーションがしやすいです。 またボタンのHover, Activeなどトランジションを確認しやすく、 検索機能や、リストの階層化などあってFigmaより探しやすいです。 拡大機能や、背景色を変更できるので、実装後の気づきを発見しやすくなります！
エンジニア同様、デザイナー・PMさんもエンジニア同様確認するコストが減った印象があるようです。
確認・ブラッシュアップの工数はすごく重要だと思います。
このイテレーションが早くなるのは効果的だと思えます。
まとめ
「Storybookの導入が運用コストに見合わない」という課題は一定あるかと思います。
しかし、テレワークが推奨される今、Storybookをホスティングすることで得られる恩恵は非常に大きいと感じました。
参考になれば嬉しいです。
募集
READYFORでは現在「React・TypeScriptの開発ができるフロントエンドエンジニア・リードエンジニア募集しています！！」
- DesignSystemの整備・構築
- モノリスなアーキテクチャからの分離
- 新規SPA構築
- 大規模リファクタ
など、ぐいぐい進められるエンジニア募集しています！！ https://www.wantedly.com/companies/readyfor2/projects
READYFOR Tech Blogのヘッダーをリデザインしました
こんにちは、READYFORに2020年2月から1人目のプロダクトデザイナーとして入社した今野（@kyota）といいます。 今日はこのテックブログのヘッダーのデザインを変更したお話をさせていただきます。
なぜ変更したか
僕が入社した2020年2月3日にちょうどこのテックブログは立ち上がり、「みんなでテックブログ書くぞー！！」と社内で盛り上がっておりました。
ただ、ブログの見た目が社内にあった写真素材をそのまま使っており、正直なところちょっと残念な見た目になっていました。
そこで、READYFORらしさもありつつ、READYFORのエンジニアの色がでるような形でデザインを検討をすることにしました。
どのようなプロセスでデザインしたか
READYFORに入社したばかりだったこともあり、会社の社風を感じとりつつ「READYFORとは、、、」「READYFORとは、、、」と頭の中で連呼しながら、特徴や性格をインプットするところから始めました。
今回に限った話ではありませんが、今後 READYFORのプロダクトを作っていくにあたっても必要な考えなので、目にしたこと、聞いたこと、感じたことなど、日々 メモをしております。
インプット後、以下4つの方向性でデザイン案を作成し、社内関係者にプレゼンをしました。
A案
READYFORロゴに使われている有機体を使った案。 一番READYFORらしさが伝わる案です。 ただ、デメリットとして、READYFORのサービストップページや、コーポレートサイトでもすでにこちらの有機体を使っているため、全体的に似てしまうという懸念があります。
B案
READYFORでは、「エンジニアの乳化」という考えがあります。 こちらの意味は、以下CTOの記事を引用させていただきます。
卵を入れると水と油が混ざり合ってマヨネーズが作れるようになる、あの「乳化（にゅうか）」です。 私たちが「テックカンパニー化」というとき、それは「エンジニア／非エンジニア」と職種で線引きして単純にエンジニアの数を増やすことでは決してなく、エンジニアリングが組織全体に広がっている状態になることです。
クラウドファンディングのプラットフォームとして様々な種類のお金の流れを扱う READYFOR では、プロジェクト審査や支援金の会計処理など、多くの業務オペレーションがシステムと密接に繋がっています。それを支えるためにはエンジニアが各組織部門に乳化していくことがとても重要で、それによってオペレーションの卓越性が高まっています。
引用元：READYFOR の「テックブログ開設」までの軌跡 - READYFOR Tech Blog
この「乳化」というキーワードを元に、混ざり合い溶け込むイメージで作成したのがこちらのB案です。
C案
B案ベースに力強くロック調のフォントで作成したものがこちらのC案です。 READYFORでは、音楽好きが多く、きちんと主張してアウトプットできるロックなエンジニアが多いなーと個人的に感じたため、こちらのアイディアが生まれました。
D案
READYFORらしさから、かけ離れた案です。
「READYFOR Tech Blog」の頭文字をブロックっぽい形にし、可愛らしさと、モノづくりしているイメージを出しました。
（正直、こちらは他と比較しやすくするための捨て案かなーと思って作ったのですが、なかなか好評でした）
案を絞る
A案は、READYFORサービスと似てしまい、テックブログの独自性が無くなるため削ることに。
B案とC案は方向性が同じだったため、エンジニアの特徴が出ているC案を残しました。
D案は好評だっため、最終的にC案とD案で、エンジニアの社内投票で決めることにしました。
投票の結果...！！
11人のエンジニアの方に投票していただき、C案（下図では①）で決まりました！
ブラッシュアップ
案を作成した段階では、細かな調整は省いていたため、案が決定した後にブラッシュアップしていきます。 色味や、背景画像の微調整を重ねたり、ロゴタイプのカーニングの調整などしました。
リリース🎉
その後、ブログにデザインを実装し、4月にリリースをしました。
最後に
本当はヘッダー以外にブログ全体のデザインを調整したかったのですが、結構な工数がかかり断念したため、また別な機会にできればなーと思っています。
今回のデザイン変更を機に、よりREADYFORのことを知って興味を持っていただけれたら幸いです！
READYFORテックブログはまだまだ始まったばかりで、これからもどんどん発信と成長していきますのでお楽しみに！
オンラインもくもく会レポート
こんにちは、エンジニアリングマネージャーの岡村です。
4月24日、オンラインもくもく会を開催しました。
コロナウィルスの影響で弊社もテレワークへ移行し、コミュニケーションもオンライン勉強会やオンライン飲み会といった形に移行していく中でもくもく会もオンラインで行いました。そのレポートをお届けします。
当日の流れ
18:00 集合、各自取り組むテーマの発表
18:10 もくもく
19:40 進捗報告
20:00 解散
進捗報告
初めてのオンラインもくもく会ということで、 特にテーマを絞らず社内メンバーで開催となりました。 当日のハイライトとコメントを紹介します。
Toggleコンポーネントを作る
考える時間よりも作業に没頭したい気分だったので、もともと業務で作る予定だったToggleスイッチを作成しました。 デザインを見ながらマークアップ＋スタイリングしていくのは、デザイナーのこだわりを改めて垣間見れたりするので楽しいですね！
TwitterShareコメントをいい感じにする
支援したことをTwitterでシェアしたユーザーが、「自分が何番目に支援したか」を追記して投稿しているのを結構見かけた。わざわざ追記しなくても済むよう、defaultで記載してあげたらシェアして応援する気持ちも増えるかなと思って取り組んでみた。
- Elmチュートリアルに触れる
Elmの持つ実行時エラーの存在しない世界観や高品質な設計パターンを肌で感じてみたいと思い、まずはElmチュートリアルでElmを完全に理解してみました。 早くElmなんも分からん領域に達してみたいです。
その他以下のような進捗報告がありました
- SPAページ向けCI/CDを構築する
- 自然言語100本ノック
- SystemSpecを書く
- Sorbetを試してみる
- Webアクセシビリティ対応についてまとめる
- 料理してみた
よかったこと / 気になったこと
よかったこと
- シェアが画面共有でささっとできる
- 自宅なのでリラックスできる
- オンライン x テーマフリーだとかなり自由にもくもくできる（料理・筋トレ）
気になったこと
- 周りの空気を感じづらい
- 家族のご飯時間と重なりバタバタした
- 雑談もしたいが生活音がマイクに大きく入ると気になる
最後に
テーマを絞っていないため、それぞれ興味があることや、やろうと思っていたことなどに取り組み、発表時には「おー！」や「すごい！」などの声が多い会となり知らない技術に触れられる良い機会となりました。社内メンバーで開催された会ということもありネタを仕込んで来る人も。
オフラインの良さは同じ空間を共有できることに大きなメリットがあると思いますが、それぞれの自宅環境を活かし選択と集中がしやすいオンライン環境ならではの良さもあるなと感じました。
今後もオンライン・オフラインに関わらず定期的にもくもく会開催をしていきたいと思います。
READYFORエンジニアとしてJoinしました！~アクセシビリティを添えて~
はじめまして。4月からフロントエンドエンジニアとしてJoinした大房 稜と申します。 twitterではrandy_39という名義でやっています。
入社して約1ヶ月が立ちましてREADYFORで働いている皆さまは本当に素晴らしい方たちばかりでとても刺激のある毎日を過ごしております！ 私がこの1ヶ月で感じたREADYFORの良さと、ブログタイトルにもあるアクセシビリティという個人的な好きな話題を書ければと思います。
READYFORに参画した理由
私の前職はWeb制作会社で働いていました。元々未経験で採用されフロントエンドエンジニアとして勉強していた日々でした。
特に不満も無く働かせてもらっていたので転職したいという強い意志はなく、スカウトメールなどもスルーをしていたのですが、READYFORからのスカウトメールでの概要で誰もがやりたいことを実現できる世の中をつくるというビジョンにとても共感しました。
また現CTO町野さんのnoteの記事 を見て組織作りから同じ想いをもった人々と働けたら絶対に楽しいだろうな、とカジュアル面談でまず話を聞きました。
いきなりフルリモート
私が入社する前の2月頃からREADYFORではコロナの影響を考えリモート推奨ということでしたので、入社日はPC端末を受け取りに行きその翌日から現在までフルリモート環境の中で働いています。 コロナ感染拡大の真っ最中に通勤電車には乗りたくありませんでしたのでほぼ初日からリモートの対応はありがたかったのですが、いきなりリモートで働くのは流石に初めてでしたので不安の中業務をスタートしました。
業務スタートしてみればドキュメントには情報が整備されてあり、MTGの際にはビデオ通話やコードに関してはVSCodeのLive Share機能での共有、エンジニア同士では毎週のオンラインランチや月1のもくもく会、またまたNintendo Switchを持っている有志の人達でのゲーム大会、部署を跨いだオンラインシャッフルランチなど業務以外のところでもすぐ馴染めるような取り組みがなされていたのでとても助かりました。雑談用のenjoyチャンネルが多数あるのが素晴らしいですね！
READYFOR社員の行動指針の中に#隙手間かけるというものがあるのですが、わからないものは誰でも即レスポンスをくれてコミュニケーションが難しいということはありませんでした。感謝。
アクセシビリティとは
話題を変えて個人的な話としてアクセシビリティについて書きたいと思います。 アクセシビリティという言葉を聞いたことがない人に説明を書きますと、
Access（アクセス）＋ -bility（可能性）
アクセスのしやすさ
利用のしやすさ
というシンプルに言えば誰でもサービスなどにアクセス出来て使えることというものです。
アクセシビリティという言葉を少し知っている方で言えば障害者の方向けの対応を実装なりする、と考えている方が多いと思います。
よくある地方自治体サイトでの文字サイズ縮小・拡大の機能・音声読み上げ機能・色を何パターンか切り替えるような機能など見たことがあるかもしれません。
これらの機能の実装などは実はアクセシビリティ的にいらない三種の神器という観点があります。参考
Webというものは誰でもアクセス出来ることが本質なので、特別障害者の方に向けた機能の実装をするということではなく使っているユーザー全てを対象とすることがWebアクセシビリティと思っています。
怪我をしてしまって一時的に右手が動かしずらい方、日本人男性20人に1人いると言われる「色覚多様性者」の方、などのユーザーの方でもサービスを使えることがアクセシビリティということなんですね。視覚障害者の方でなくても音声読み上げを使ってサイトを閲覧しているユーザーもいるかも知れません。(自分の話です)
知らず知らずにアクセシビリティの恩恵を受けているパターンもよく見かけます。
iPhoneのアクセシビリティ設定の視差効果を減らすをONにしたらバッテリー持ちが良くなる情報
ゲームでのアクセシビリティ設定のある項目をONにしたらやりやすくなるからオススメ的な情報
健常なユーザーであってもこのようにサービスの体験を広く底上げ出来ることが良いですね！
READYFORとアクセシビリティ
このようにアクセシビリティというのは誰でもアクセスできて使えるものというところでREADYFORのビジョンの話に戻るわけですが、誰もがやりたいことを実現できる世の中をつくるということはまず誰でも使えるサービスを作ることも必要で、自分が何か貢献出来てREADYFORで働き誰かの夢を応援できる未来を想像してとてもわくわくしました。
直近で言えばコロナ基金のプロジェクトが多数のメディアに紹介され、たくさんの支援者が集まり、READYFOR史上最大の支援額ということでもの凄くサービスが改善・成長をしているのを間近で体感しています。
これから
とはいえREADYFORのサービスはアクセシビリティ、ユーザビリティ的、それ以外にもまだまだ課題がたくさんあります。 自分の役割としてはこういった改善をして使いやすくなったよ！というのをまた記事としてアウトプットしていきたいと思います。
最後に、READYFORでは共に戦ってくれる仲間を求めています。
共に想いが乗ったお金の流れを支えるサービスを作りませんか？