READYFOR Tech Blog

READYFOR のエンジニアブログ

READYFORが目指す「乳化」 への取り組み

READYFORが目指す「乳化」 への取り組み

こんにちは、READYFORでVP of Engineeringをしております、いとひろ( id:itohiro73 )です。

本記事はREADYFOR Advent Calendar 2020の記念すべき第一日目です。今年はREADYFORがアドベントカレンダーに初参戦!メンバー一同完走目指して頑張ってまいりますのでどうぞよろしくお願いします。

さて、READYFORでは「誰もがやりたいことを実現できる世の中をつくる」というビジョンのもと「想いの乗ったお金の流れを増やす」というミッションに取り組んでいます。そのために大切にしている価値観が「乳化」という概念です。本記事ではこの乳化という概念と、その状態を目指すためのいくつかの取り組みについて説明します。本記事は今年の夏に開かれた デブサミ2020夏 の講演内容に加筆修正したものになります。

READYFOR Tech Vision

READYFORでは、 「組織の中にエンジニアリングが自然に溶け込んでいる状態」 を「乳化」と呼んでおり、全社的にこの「乳化」の状態を目指しています。

乳化

ビジネスとエンジニアリングという2つの概念を対立概念として考えるのではないく、必要に応じて混ざり合い、組織全体として最大限のイノベーションとパフォーマンスを発揮したい、そんな思いをこの「乳化」という言葉に込めています。

この「乳化」というワード、実は広木大地さんのnote記事『「2つのDX」というコンセプト』で言及のあった「エマルション現象」を参考にしており、昨年の10月頃プロダクト開発ミーティング中にCTO町野が発した、READYFORはこのエマルション・乳化というイメージに向かっていきたいという話から端を発しております。

今ではプロダクト開発チーム内はもちろん、全社的に「乳化」というワードが日常的に会話の端々に出てくるようになってきています。しかしながら、「乳化したい」、と字面で言うのは簡単ですが、実際にその状態になれるかどうかはまた別の話です。本記事ではREADYFORが乳化を目指すために実際に行ってきたさまざまな取り組みを紹介していきたいと思います。

「乳化」という概念を全社的に共有する

まずやったことは、READYFORは「乳化」していくんだという想いを全社的に共有することでした。まだコロナに入る前にオフィスで全社的に行っていた朝会において、持ち回りで司会と3分スピーチをする場があったのですが、そこで「乳化」についての想いを語りました。

また、その数週間後にあった全社ミーティングでは2020年のエンジニアリングの戦略を共有するとともに、この「乳化」という概念を繰り返し強調しました。

全社MTG時のSlackの様子
全社MTG時のSlackの様子

エンジニア外の社内メンバーに対しても「乳化」という概念を波及させること、そしてその状態が良いなと思ってもらえることがとても大事だと思っています。

ビジネスプロセスを理解するために可視化する

READYFORは、「想いの乗ったお金の流れを増やす」ためのしくみとして、実はかなり複雑なドメインを扱っています。

READYFORのクラウドファンディングサイトを覗いてみると、一見普通のWebサービスのように見えます。どこにドメインの複雑さが隠れているのでしょうか。 READYFORのクラウドファンディング

実は、クラウドファンディングの実行者さんがREADYFORに申し込みを提出してからプロジェクト公開をするまでや、支援者さんからの支援が実行者さんにわたるまで、READYFORの社内ではさまざまなビジネスプロセスが走っています。

READYFORのビジネスプロセス

こういった複雑なビジネスワークフローをエンジニアがしっかり理解して改善や新規開発に取り組んでいくことも「乳化」をする上ではとても大切になってきます。では、どのように理解していけば良いでしょうか。

実際、ビジネスワークフローというものは、それを実際に行っている現場のメンバーが一番理解しているものです。それを現場のメンバーが自ら可視化できるのが一番理想的です。そのために、READYFORではBPMNというモデリング記法を活用していこうと考えました。

BPMN

BPMNを活用するためには啓蒙していく必要があります。studyチャンネルを作って地道に啓蒙活動していきました。

BPMNの啓蒙 #1
BPMNの啓蒙 #1

一度使ってみればその便利さが身に染みるので、地道に啓蒙です。

BPMNの啓蒙 #2
BPMNの啓蒙 #2

地道に啓蒙活動を続けていると、自ら試行錯誤してくれるメンバーが徐々に現れます。

BPMN試行錯誤
BPMN試行錯誤

そして、気がつけば様々なメンバーたちがBPMNでワークフローを可視化し始めてくれました。

BPMN ワークフロー可視化
BPMN ワークフロー可視化

啓蒙活動をしたとはいえ、正直READYFORメンバーの「まずやってみる」力、そして「乳化」への柔軟性には非常に驚いてます。

これでBPMNを活用して様々なビジネスワークフローを理解し、改善していくための素地が出来上がりました。

BPMNによるワークフローの可視化
BPMNによるワークフローの可視化

同じミッションを共有し、ともにつくる

エンジニアリングが組織に溶け込んでいくためにもう一つ重要なこととして、「同じミッションを共有し、ともにつくる」ということです。

READYFORではこのためにOKRという目標設定のフレームワークと、Squad体制という組織体系を活用しています。

OKRやスクワッド体制に関しての詳細は割愛しますが、Wantedlyの森脇さんのブログが参考になるので興味のある方はぜひ参照してみてください。Squad体制は、端的にいうと、ひとつのミッションの達成を目指す職能横断チームを組成することです。

READYFORのSquad体制の中でも、「乳化」の特徴をよく表しているSquadとして「決済・会計基盤Squad」を紹介します。

「決済・会計基盤Squad」では、「健全かつ堅牢なお金の流れを実現し、かつ把握できるSystem of Recordをつくる」というミッションを持ち、CFOの元田をはじめとする経理メンバーとエンジニアメンバーで組成されているSquadです。

決済・会計基盤Squad
決済・会計基盤Squad

System of Record
System of Record

「想いの乗ったお金の流れを増やす」というミッションを持ったREADYFORにとっては、決済・会計基盤Squadが取り組むシステム開発は事業の根幹を担うとても大切な領域となります。

事業部が実現したいこと、それを経理チームが実務として行う入金処理・出金処理・仕訳処理を要求分析・要件定義をすることを通して、どういったシステム構成であれば今後の事業展開に対してスケーラブルな仕組みになるのか、膝付き合わせながらまさに「乳化」して議論し、お金の流れを実現していく部分の自動化・システム化に取り組んでいます。

実際に現場の業務を行っている経理メンバーと、それを自動化・システム化していくエンジニアメンバーが、お互いの専門性を尊重し合いながらものをつくっていくプロセスは、まさに「乳化」の良い面が現れているなと思います。

日常をハックする取り組みを背中で見せる

日常の何気ない自動化は、「乳化」の醍醐味でもあります。最近は日常的に使うツール自体が拡張性を持っていたり、アドインを足すことでワークフローを自動化できたりと、非常に自動化がやりやすくなっていることが多いです。非エンジニアにとっては、ぱっと見た感じ敷居が高くみえるようなことでも、実はすごく簡単に実現できたりする。そういったことも、実際にやっているところを見ると人間やってみたくなるものです。

そんな中でも実際にやって見せて組織に広がっていった事例をいくつかご紹介します。

まずは、Slackで特定の絵文字スタンプを押すだけで別のチャンネルに投稿を飛ばすことができる、Reacji Channelerの導入。

Reacji Channelerの説明
Reacji Channelerの説明

こちら実はコマンドですごく簡単に設定できるのですが、まずは導入して使ってみることで、気になる人が現れます。

気になる人が現れたらその場でReacji Channelerコマンドの利用方法をSlackで共有し、さらにその共有した内容をReacji Channelerでproductivityチャンネルに送ると言う自給自足。

Reacji Channeler啓蒙活動
Reacji Channeler啓蒙活動

他にも「乳化研修」と称するトレーニングの場を設け、その場でZapierによる自動化をデモして見せ、実際に自分でも同じZapierを作ってみるということをやってみました。業務で使いそうな、「Gmailで受け取ったメールをSlackのチャンネルに送る」みたいな内容がさっと実現できるのを見て、その場で実際に試してもらう。さらに、内容が非常に簡単なので、このトレーニングを受けた人は口コミ方式で他の人に乳化研修を実施してもらう、という形で「ツールを使うと何が実現できるのか」の理解を広めてもらうこともできました。

Zapierを使ってその場で自動化をデモしてみる乳化研修
Zapierを使ってその場で自動化をデモしてみる乳化研修

広がる乳化の輪
広がる乳化の輪

ビジネスサイドの「わからない」に寄り添う

今年はコロナ禍による、資金需要の増加、寄付需要の増加があり、実はこれまでにないレベルで支援額・支援数が増えた年でもありました。

そんな中、これまでにREADYFORが経験してこなかったレベルでの同時支援数増加や、メディアで取り上げられたりSNSでの拡散等による同時アクセス数の増加による負荷が生じ、技術的な問題によるさまざまな処理限界が少しずつ明らかになり、クラウドファンディングの現場で実際にユーザーと対峙している現場メンバーには「何ができて何ができないのかわからない」不安感が生じ始めていました。

ただでさえイレギュラーな対応に追われていたコロナ禍において、限られたリソースでそれらの技術課題をすべてタイムリーに解決するのは非常に難しく、エンジニアチームでの調査の元、その時点で把握できている問題のカテゴリー分けととそこで生じうるリスクについて整理して全社的に共有しました。

支援数増加による処理限界の共有
支援数増加による処理限界の共有

すると、社内の仲間たちからものすごい勢いで感謝の言葉をいただけました。

負荷増加時の情報共有に対する社内の反応
負荷増加時の情報共有に対する社内の反応

これはエンジニア的にはなかなか驚きのリアクションです。なぜなら、この時点ではまだ技術的な問題が解決できたわけではないのですから。ではなぜここまでの感謝を得ることができたのでしょうか?

「わからない」ことが「わかる」状態になる。「不確実」なものを「確実」なものにする。それも一つの問題解決といえます。どこにリスクが存在していて何が起きうるのかが把握できる、それだけで実はいろんな問題に(解決ではないにしろ)対処できる可能性は増えると言えます。

エンジニアは問題が起きるとついつい技術的な解決法にすぐ目が向かってしまいがちですが、実はそれだけが問題解決の唯一の道筋というわけではないということは事あるごとに思い出したいです。

ピープルウェアという30年以上前に出版された本で「ソフトウェア開発上の問題の多くは技術的というよりも社会学的なものである」と書かれており、実際そうだなと思う場面はそこかしこに存在しています。

ピープルウェア引用
ピープルウェア引用

READYFORでは「乳化」を通してこういった社会学的な問題に対してもアプローチしていけるような組織であり続けたいと思います。

終わりに

まとめ
まとめ

いかがだったでしょうか。READYFORが「乳化」という状態を目指すために取り組んできているいくつかの事例に関してご紹介しました。冒頭にも書きましたが今回の記事は デブサミ2020夏  の講演内容に加筆修正したものになります。こちらから元セッションのスライドも見れますので合わせてご覧ください。

実は、本アドベントカレンダーでは、エンジニアやプロダクト開発メンバーのみならず、コーポレートチームやビジネスサイドのメンバーも参加しています。まさに「乳化」を体現するようなアドベントカレンダーになっていけると良いなと考えています。

明日はREADYFORに乳化を促す業務ハックエンジニア、s_urano が持続可能な効率化について書いてくれるようです。お楽しみに!

RailsアプリケーションのカオスなCSSに規約をゆるく導入する 〜要素セレクタ警察〜

はじめに

こんにちは!READYFORでフロントエンドエンジニアをしております、江面( @neripark )と申します。 最近は主に Next.js (TypeScript)を用いたSPA開発に従事しております。CSS設計、コンポーネント設計、Netlify などが好きです!

本日はタイトルにもある通り、既存のRailsアプリケーションにCSSコーディング規約を導入したお話をしようと思います! 既存のプロダクトのCSSで苦労している方の参考になれば幸いです。

続きを読む

「リモートワーク成功・失敗事例〜コロナに勝つエンジニア組織〜」 にVPoE伊藤が登壇しました!#六本木スタートアップ

皆さま、こんにちは。READYFORでエンジニア採用担当をしております、西和田です。

東京では新型コロナウィルスの感染者がまた増えてきており、第二波も懸念されているる状況です。そんな「ウィズコロナ」の今、どの企業も向き合うことを避けられないのがリモートワークです。

今回は、そんなリモートワークにまつわるオンラインイベント、for Startups主催の「リモートワーク成功・失敗事例〜コロナに勝つエンジニア組織〜」に弊社VPoE伊藤が登壇し、セッションに参加させて頂きました。

f:id:readyfor:20200720111719p:plain

今回、弊社の他にfor StartupsのCTO戸村さんアンドパットのVPoE下司さんがセッションに参加されていました。 まず初めにそれぞれの会社紹介のお時間を頂き、READYFORからは、会社概要の他に「乳化」や「Tech value」のお話もさせて頂きました。


READYFORが目指す乳化とは 「組織の中に自然にエンジニアリングが溶け込んでいる状態」のことです。 f:id:readyfor:20200717191552p:plain

またTech valueでは、プロダクトチームが目指すTech vision valueを紹介させて頂きました。 これはもともとREADYFOR全社のvalueとしてある7つの要素を、プロダクトチーム用にアレンジされたものです。

f:id:readyfor:20200717191531p:plain


さて、続いてはセッションです!

一つ目のテーマ 「リモートでもスムーズに開発できましたか?」

for Startups戸村さんから「slackで毎日日報を報告するようになりました!」アンドパットの下司さんからは、「弊社では、通勤時間がなくなった分、毎日10分ほど(歯磨きをするかのような)勉強会を、任意で開催するようになりました!」などお話して下さる中・・ READYFORのリモート状況について、下記のお話をさせて頂きました。

コロナの前は、全社的に週1リモート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. 対象となるメソッドについて
  2. メソッドを理解する
  3. メソッドを分解する
  4. メソッドを再構築する

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
可読性 f:id:toyoc:20200707170424j:plain:w200 f:id:toyoc:20200707170442j:plain:w200

なんとなく成果があるように数字を並べて比較してみましたが、実際、肌感覚として読みやすく触りやすいコードになったんじゃないかなと思います。

ということで、複雑で手が付けられないように見えるコードも、挙動を理解し、理解に基づいて分解し、可読性を上げた上で再構築することで、手を入れやすい簡潔なコードにできるお話(という一例)をご紹介しました。
スパゲッティコードでお悩みの方の参考になれば幸いです。

Storybookをホスティングしてレビューが爆速になった話

こんにちは、エンジニアリングマネージャーの岡村です。
社員全員テレワークの環境にも慣れてきて、ワークフロー改善と共にREADYFORの開発環境も日々改善しております。

概要

StorybookをNetlifyへホスティングすることで、PR単位でデプロイされるためデザインの確認・レビューがとても楽になったので紹介です。

導入の背景

READYFORのアーキテクチャ上もっとも有効だった

f:id:resqnet:20200612113037p:plain

ざっくりREADYFORのフロントエンドアーキテクチャはReact On RailsとElements(UI Library)で構成されており、デザイン手法にAtomicDesignが採用されています。 Elements(UI Library)はDesignSystemの一部として構成され、ドメインに依存しないコンポーネントはElementsへ開発しています。 そのため、確認をする際にはElementsのコンポーネント・READYFORのコンポーネントをそれぞれに確認する必要があります。

レビューコストがかかっていた

コンポーネントデザインを同じ粒度で確認できるようにStorybookを導入しています、しかし、デザイナー・PMへのレビューを行うための環境作成コストは負荷がありました。

f:id:resqnet:20200612112853p:plain PRをレビューブランチに反映or画面共有で確認してもらう必要があった。

弊社ではスクラム開発を採用しているため、スプリントレビュー時に都度この工数が発生していた。 また、開発中に確認をしてもらうのにその場で画面を見せたり(今だとハングアウト・Zoomなど)していました。

Storybookをホスティングし解決

この問題を解決するためにNetlifyのPR Previewを利用しました。
これによりPR毎にStorybookをbuildすることでPR単位のレビューが安易になりました。

f:id:resqnet:20200612112905p:plain デザイナーは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日にちょうどこのテックブログは立ち上がり、「みんなでテックブログ書くぞー!!」と社内で盛り上がっておりました。

ただ、ブログの見た目が社内にあった写真素材をそのまま使っており、正直なところちょっと残念な見た目になっていました。

f:id:rfkonno:20200604175612p:plain:w480
↑変更前のブログのデザイン

そこで、READYFORらしさもありつつ、READYFORのエンジニアの色がでるような形でデザインを検討をすることにしました。

どのようなプロセスでデザインしたか

READYFORに入社したばかりだったこともあり、会社の社風を感じとりつつ「READYFORとは、、、」「READYFORとは、、、」と頭の中で連呼しながら、特徴や性格をインプットするところから始めました。

今回に限った話ではありませんが、今後 READYFORのプロダクトを作っていくにあたっても必要な考えなので、目にしたこと、聞いたこと、感じたことなど、日々 メモをしております。

インプット後、以下4つの方向性でデザイン案を作成し、社内関係者にプレゼンをしました。

f:id:rfkonno:20200604181803p:plain

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案(下図では①)で決まりました!

f:id:rfkonno:20200611180246p:plain
自分のスタンプが含まれているため11人の投票となっています

ブラッシュアップ

案を作成した段階では、細かな調整は省いていたため、案が決定した後にブラッシュアップしていきます。 色味や、背景画像の微調整を重ねたり、ロゴタイプのカーニングの調整などしました。

f:id:rfkonno:20200612090612p:plain:w320
気になった箇所を微調整していく

リリース🎉

その後、ブログにデザインを実装し、4月にリリースをしました。

f:id:rfkonno:20200612092228p:plain

f:id:rfkonno:20200612112416p:plain

最後に

本当はヘッダー以外にブログ全体のデザインを調整したかったのですが、結構な工数がかかり断念したため、また別な機会にできればなーと思っています。

今回のデザイン変更を機に、よりREADYFORのことを知って興味を持っていただけれたら幸いです!

READYFORテックブログはまだまだ始まったばかりで、これからもどんどん発信と成長していきますのでお楽しみに!

オンラインもくもく会レポート

こんにちは、エンジニアリングマネージャーの岡村です。

4月24日、オンラインもくもく会を開催しました。

コロナウィルスの影響で弊社もテレワークへ移行し、コミュニケーションもオンライン勉強会やオンライン飲み会といった形に移行していく中でもくもく会もオンラインで行いました。そのレポートをお届けします。

f:id:resqnet:20200529103702p:plain

当日の流れ

18:00 集合、各自取り組むテーマの発表
18:10 もくもく
19:40 進捗報告
20:00 解散

進捗報告

初めてのオンラインもくもく会ということで、 特にテーマを絞らず社内メンバーで開催となりました。 当日のハイライトとコメントを紹介します。

  • Toggleコンポーネントを作る f:id:resqnet:20200521101414p:plain

    考える時間よりも作業に没頭したい気分だったので、もともと業務で作る予定だったToggleスイッチを作成しました。 デザインを見ながらマークアップ+スタイリングしていくのは、デザイナーのこだわりを改めて垣間見れたりするので楽しいですね!

  • TwitterShareコメントをいい感じにする f:id:resqnet:20200521101041p:plain

支援したことをTwitterでシェアしたユーザーが、「自分が何番目に支援したか」を追記して投稿しているのを結構見かけた。わざわざ追記しなくても済むよう、defaultで記載してあげたらシェアして応援する気持ちも増えるかなと思って取り組んでみた。

  • Elmチュートリアルに触れる
    f:id:resqnet:20200521101119p:plain

Elmの持つ実行時エラーの存在しない世界観や高品質な設計パターンを肌で感じてみたいと思い、まずはElmチュートリアルでElmを完全に理解してみました。 早くElmなんも分からん領域に達してみたいです。

その他以下のような進捗報告がありました

  • SPAページ向けCI/CDを構築する
  • 自然言語100本ノック
  • SystemSpecを書く
  • Sorbetを試してみる
  • Webアクセシビリティ対応についてまとめる
  • 料理してみた

よかったこと / 気になったこと

よかったこと

  • シェアが画面共有でささっとできる
  • 自宅なのでリラックスできる
  • オンライン x テーマフリーだとかなり自由にもくもくできる(料理・筋トレ)

気になったこと

  • 周りの空気を感じづらい
  • 家族のご飯時間と重なりバタバタした
  • 雑談もしたいが生活音がマイクに大きく入ると気になる

最後に

テーマを絞っていないため、それぞれ興味があることや、やろうと思っていたことなどに取り組み、発表時には「おー!」や「すごい!」などの声が多い会となり知らない技術に触れられる良い機会となりました。社内メンバーで開催された会ということもありネタを仕込んで来る人も。

オフラインの良さは同じ空間を共有できることに大きなメリットがあると思いますが、それぞれの自宅環境を活かし選択と集中がしやすいオンライン環境ならではの良さもあるなと感じました。

今後もオンライン・オフラインに関わらず定期的にもくもく会開催をしていきたいと思います。