2024-04-25

【エンジニアの日常】エンジニア達の自慢の作業環境を大公開 Part2

自慢の開発環境を大公開

こんにちは。

FindyのTeam+を開発している西村(sontixyou)です。

【エンジニアの日常】エンジニア達の自慢の作業環境を大公開 Part1と題して、公開したブログが好評でした。それに続いて、弊社エンジニア達の作業環境を見ていきましょう！

作業環境を大公開

西村

私は、現在週3日ほど出社と残りはリモートワークしています。そんな私の作業環境をご紹介します。

デスクの全体像はこのような感じです。

デスクは新卒時代の先輩からおさがりです。幅120cmのものを使用しています。

ディスプレイはDELLの27インチ 4Kモニタを2枚使っています。1枚だけ縦置きにしている理由は、省スペース化と首の振り向きが大変だからです。

横置きのディスプレイでは、エディタとSlack専用になっています。

縦置きのディスプレイでは、ブラウザ専用になっています。ウィンドウを垂直に2枚置いて活用しています。

ディスプレイはエルゴトロンのアームで支えています。ディスプレイの縦置きを実現するために欠かせないアイテムです。また、ディスプレイの台座があると場所を取るためです。

Webカメラは10年前に買ったlogicoolのものを使用しています。マイクが内蔵されているため、外付けマイクは用意していません。そろそろ買い替えしたいので、乗り換え先を探し中です。

USBハブには、サンワサプライのUSBハブを使用しています。このハブは、HDMI(4k/60Hz対応)1本とUSB3.0 2本とUSB Type-Cの充電ケーブルを指すことができます。

キーボードはkeychronのK6 Proを使用しています。

キースイッチはKeychron Silent K Pro Switchを使っています。打鍵感がとても良いため、自宅用とオフィス用で2台購入してしまいました。

マウスは、logicool ERGO M575Sを使用しています。

手首を動かさせずに、カーソル移動ができます。そのため、手首の疲れは全然ありません。また、ボールを取り外すことができるため、マウス内部の清掃やボール交換が楽々です。

自分が好きなものをデスクに置くことで、仕事終わりまでモチベーションをキープしつつ仕事ができます。

まずは、フィギュアです。私は海洋堂制作のフィギュアが好きなため、ガチャポンで当てた怪獣ネロンガと恐竜を置いています。縦に長いものはミイラ展で当てた猫のミイラを題材にしたフィギュアです。

デスク横には、PS5を置いています。仕事終わった瞬間に、ゲームプレイできるためとても快適です。

仕事を快適かつ集中できる場所になるように意識して、デスク環境を整えています。

浜田

次は浜田(ham)の作業環境を紹介します。

コロナ禍のときにリモートワークを始め、コツコツリモート環境を整えました。私のポリシーは「日々使うものは良いものを！」なので、予算の許す範囲で妥協せずに自分が良いと感じるものを選ぶようにしています。

ディスプレイは2枚ないと開発効率がガタ落ちするタイプのエンジニアなのでデュアルディスプレイです。

右側は4Kで31.5インチ、左側は27インチです。 4Kディスプレイは、ブラウザやZoomやGoogle Meetなどを表示しています。 27インチディスプレイは、Slackやメール、エディターなど文章を扱うツールを表示しています。

4Kディスプレイはメーカーなどにこだわりはないのですが、USB Type-Cで出力とPC本体への給電ができるものを選びました。ケーブルが少ないのは正義！！

また、こちらのディスプレイは足が大きかったのでモニターアームを使っています。デスクスペースを拡げるためにモニターアームを買ったのですが、モニターの角度を簡単に変えられるため、モニターの背面の配線を変えたり、モニター周りの掃除もしやすくなり地味にストレスだったことも解消されました。

27インチディスプレイは解像度などのスペックは劣りますが、文章を書く場合に4K解像度だと文字が小さくて使いづらいので、必要十分なスペックだと感じています。

リモートワークにおいてオンライン会議は生命線です。こちらの画質や音質が悪い場合は相手にストレスを与えてしまう可能性があります。

そのため、Webカメラ / マイクは良いものを選ぶように心がけました。また、自室では前からの光が当たらず、顔が暗く見えていたためライトも買いました。見た目の印象も大事です。

椅子はErgohuman PRO2 Ottomanを使用しています。足を伸ばせるようにオットマンがついているものにしましたが、全然使わないので不要でしたw

なお、足置きと一緒に使うことで椅子の高さ調整がやりやすくなるので、足置きとセットで使うことがお勧めです。

冒頭に書いた「日々使うものは良いものを！」のキーボードから始まりました。

REALFORCEから始まり、HHKB Professional(手元にないので写真なし)、HHKB Professional Hybrid Type-S、そして今はHHKB Studioを使っています。

また、分割キーボードを使っていたこともありました。

Corne Cherry V3はキーが少ない代わりにレイアーを活用するのですが、使いこなせず挫折しました・・・

HHKBライクな7sProは、気に入っていたのですがキーの反応が鈍いことが多々ありストレスを感じたのでHHKBに戻りました。

髙橋

週に2日程度リモートしている髙橋（@nokv）です。

オフィス勤務が主体のため自宅はシンプルな環境にしています。

デスクの全体像はこんな感じです。

200cm程度の大きいデスクを妻と半分ずつ使っています。

妻はリモートワークが多いため、MTGが被った際はどちらかが移動しないといけないなど不便なこともありますが、作業の合間に会話がしやすくリフレッシュできるので1つのデスクにして良かったと感じています。

自分の作業環境はMacBook Proと外部ディスプレイを縦並びに配置したシンプルなデュアルディスプレイ構成で作業しています。

以前はもう1枚ディスプレイがあり横に配置していましたが、首や目に負荷がかかると感じたため現在の構成にしました。

外部ディスプレイはDELLの27インチの4Kモニタを使っていて、PCへの給電もケーブル1つで可能な点がお気に入りです。

エディタやGitHubなど閲覧頻度の高いものは外部ディスプレイに表示し、首への負荷を軽減するため視点がなるべく下がらないようにしています。

キーボードはNuPhyのHalo75で、スイッチはNight Breezeを使っています。打鍵感と静音性のバランスが良く、長時間使用しても疲れにくいのが気に入っています。

MacBook Pro本来の配置に慣れているため、マウスやトラックパッドを別で用意することはなくいわゆる尊師スタイルにしています。

椅子はHerman Millerのセイルチェアを使っています。椅子の選択は体の負荷に直結するので機能性の高さを重視しました。それに加えて普段はhamさんと同じように足置きを使っています。

性格的にものが多いと落ち着かないので、必要最低限のものだけを配置して作業に集中できるような環境を作っています。

まとめ

いかがでしたでしょうか？

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers

2024-04-22

開発生産性を上げるために開発をする前に考えていること

こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。

この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。ここで「開発をする前」というのは次のようなタイミングを指します。

PdMなどから新規施策の仕様について相談を受けたとき
起票された開発Issueを最初に確認するとき
自分がIssueを作成するとき

なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。

なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。

いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことになります。そのような事態を避け、提供価値を少しでも上げるために考えていることを記します。

なぜ、いつ、だれがつかうか？
開発する必要があるか？しなくて済む方法はないか？
シンプルにできないか？
リリースを分割できないか？
実例の紹介
終わりに

なぜ、いつ、だれがつかうか？

大前提にはなるのですが、まずは以下を考えます。

なぜ：なぜその機能が必要なのか？ユーザーはなぜこの機能をつかうのか？
いつ：いつその機能を使うのか？そのときユーザーはどういう状況にいるのか？
だれ：どういう属性のユーザーか？ユーザーが社内にいる場合、どの部署/役割の人か？

これらの情報はありがたいことにPdMから普段提供してもらえています。しかしながら自分でも考えるようにしています。エンジニアの視点からも考えることで、それを実現するための別の形の機能やアプローチが良いのではないかと提案できることがあります。

たとえ提案が採用されなかったとしても現行案の妥当性を確認できるため、方向性を間違える可能性を減らすことができると考えています。

開発する必要があるか？しなくて済む方法はないか？

提供価値を極力変えないまま、投入リソースを減らせるアプローチがないか次のことを考えます。

既に同じ機能が存在するか、または全く同じではないものの実質的に同じ提供価値を持つ機能があるか？
既存の機能を利用、または組み合わせて実現できるか？
外部サービスやライブラリをつかうことで実現できるか？

例えば、画面Aで情報の表示追加を要望された際、その情報をすでに表示している画面Bがあるため、画面Aへの直接追加ではなく、画面Bへのリンクを設けるだけで十分というケースがあったりします。

このように要望機能そのままでなくても必要十分をみたせば問題ないというケースでは、開発リソースを減らせることがあります。

シンプルにできないか？

機能が複雑になるとその後のメンテナンスや改修の工数が増加したり、作り直しが発生したりしてトータルで見ると生産性が落ちるということが起きがちです。

そのため次のことを考えます。

複数の関連性のない異なる目的を担う機能になっていないか？
その場凌ぎでワークフローや処理の分岐を増やすことになっていないか、またはそれらを極力減らして開発できないか？
過度に自動化、抽象化することでなにをしているかわからなくなったり、イレギュラーケースに対応しづらくなっていないか？

私は過去にシンプルさよりもリードタイムを優先して機能追加をしたことがあります。その時は本来異なる目的をもつ既存機能に付け足す形で機能追加をしました。

最初のリリースまでのリードタイムは短縮できましたが、処理の分岐とデータのパターンが増えてメンテナンスとデータ集計がしづらくなり、結局は一から作り直すことになりました。トータルで考えると最初からシンプルに別の機能として設計/開発をしたほうがよかったと考えています。その反省も踏まえての内容になります。

ただし、特にベンチャー企業においてはどうしてもリリースまでのリードタイムを短くしなければならない状況もあると思います。そのため完全に否定できることでもないですが、単にそのほうが楽だからという理由ではやらない方がよいと考えています。

リリースを分割できないか？

ユーザーへの価値提供を考えて立案された施策や機能が、本当に有効かどうかは実際に提供してみないとわかりません。また、大きな施策の場合は必須なものと必須ではないがあれば嬉しいというものが混在しがちだと考えています。それらすべての内容をつくってからリリースする場合、期待通りの結果が得られなかったときに投入した開発リソースを無駄にしてしまう可能性があります。

これを避けるため、今回の開発で一番実現したいことはなにか？を考えて、もっとも重要なものから段階的にリリースすることを考えます。いわゆるMVP(Minimum Viable Product)を開発ごとに考えるようなイメージです。

次のメリットがあると考えています。

ユーザーに素早く価値提供ができる
効果やユーザーのフィードバックを早く得られる
結果が素早く得られるため、軌道修正や撤退の判断が早期にできる
リリースあたり開発ボリュームを減らせるため見積もりのブレを減らせる

エンジニアのモチベーションの観点からも、早期にリリースすることで開発者のモチベーション向上につながりやすく、すべて作り込んで無駄になった場合のモチベーション低下も回避しやすいと考えています。

実例の紹介

ここからはこれまで紹介した考え方を実際に活かした「請求フローのシステム化」プロジェクトの事例を紹介します。

プロジェクトの概要

Findy Freelanceではユーザーの稼働後サポートとして請求書の作成代行と業務委託報酬の代理徴収を行っています。そのため、ユーザー個々の稼働状況を確認し、内容に応じて請求書を作成して企業に送信する必要があります。

これらの作業の多くは手作業で行われていました。サービス利用者の拡大に伴い運用の限界が見えたため、請求フローをシステム化するプロジェクトが立ち上がりました。

請求フローの理解

私は開発リーダーとしてプロジェクトを途中から引き継ぎました。その時点で請求業務のドメイン知識がほとんどありませんでした。そのためPdMにヒアリングしながら請求フローの図を作成し、どの役割の人がどのタイミングで何をするのかを把握しました。つまり「なぜ、いつ、だれが？」の観点を確認しました。

情報を整理することでエンジニアユーザー、企業担当者、社内の営業担当者および経理など多くのステークホルダーが関与しているとわかりました。以後の開発で各々の視点を意識でき、先を見据えながら起案時よりもさらに価値のある仕様に繋げることができました。

設計の見直しによるシンプル化

次に、設計の見直しを行いました。プロジェクト引き継ぎ前は、手作業で管理されていた情報をそのままデータベースに移す形で設計が進んでいました。

例として、Findy Freelanceの契約スキーム上「企業とファインディ間の契約条件」と「ユーザーと企業間の契約条件」の2種類の契約情報が必要です。当初はこれらを1つのテーブルで管理する設計でしたが、本来は別の情報であり、それぞれの契約変更のタイミングも異なるため、別のテーブルで管理することにしました。

これによりテーブルとモデルクラスの役割が明確になり、シンプルになりました。また、2種類の契約情報がそれぞれいつ変更されたのかも管理できるようになりました。設計の見直しには時間がかかりましたが、その後の改修や運用コストを考慮すると、見直して良かったと考えています。

スコープの決定とリリースの分割

プロジェクト引き継ぎ時、システム化に必須な機能と便利な機能がIssueに混在していました。せっかくシステム化するならと多くの要望が積み上がっていましたが、スコープが不明確でした。

そのため、PdMを中心に関係者と協議してスコープを決めました。早期の運用開始を目指し、必須機能のみを最初にリリースしました。例えば、次の機能は最初のリリースから除外しました。

社内管理画面の利便性向上
ダッシュボードの作成（初回リリースではBigQueryからのデータ参照で代替）
ユーザーがログインページから報告した稼働時間の確認（報告時にユーザーへメール送信しているため）

これらの機能は実運用後に必要性を再検討することにしました。スコープを決定し、リリースを分けることで運用開始までのリードタイムを短縮しました。また、実運用をしたことで発覚した必要となる機能や改修があり、最初からすべて作りこまなくてよかったと考えています。

終わりに

以上が開発をする前に私が考えていることとその実例です。誰かの参考になれば幸いです。ここに書いてあるようなことは普段から考えているという方も多いのではと思います。読んでくださった方々が開発に際して考えていることなど是非コメントをいただけると嬉しいです。

また、ファインディではエンジニア領域のプロダクトの開発をするため、開発エンジニアが提供価値を考えるにあたり自然とユーザーの視点にたって考えることがしやすい環境であると感じています。エンジニアへの価値提供に少しでも興味を持っていただけた方は、ぜひカジュアル面談のお申し込みをお待ちしております。

ファインディの採用情報はこちら↓

herp.careers

また、ファインディの開発メンバーが登壇するイベントを4/24（水）12:00~13:00で実施します！開発生産性や開発のパフォーマンス向上にご興味ある方はconnpassページより是非お申し込みください！ developer-productivity-engineering.connpass.com

2024-04-18

Findyの新規サービス Findy Toolsはどのようにして開発されたのか？

こんにちは。

Findy で Tech Lead をやらせてもらってる戸田です。

先日、弊社からFindy Toolsがリリースされました。

今回は、そのFindy Toolsがどのようにして開発されたのか、開発の背景や工夫点などを紹介していきます。

それでは見ていきましょう！

Findy Toolsの概要

紹介

Findy ToolsのLP画像

Findy Tools は開発ツールに特化したレビューサイトです。第三者の視点で実際にツールの選定をした企業の生の声を集めることで、ツール選定に関する不安を解消し、導入検討に必要な情報を提供します。

「Findy Tools」を開発ツールの導入検討をしているユーザーが利用すると、実際にツール選定をした大手企業やメガベンチャー企業の技術責任者やエンジニアによるレビューを集めることができ、導入検討がスムーズになります。

また、開発ツールを掲載するベンダーには、実際の利用企業の声を活かしたコミュニティマーケティングによる新規顧客の獲得や、認知向上をご期待いただけます。

システム構成

システム構成は次の通りになっています。

Ruby on Rails
React
Next.js
- App Router
bulma
GraphQL
AWS
- S3
- CloudFront
- Aurora
- Fargate

上で挙げた構成に特に強いこだわりはなく、既存資産の流用をしやすかったことと、リプレイスや変更しやすいという理由でこの構成になっています。

APIとフロントエンドを疎結合で設計し、どちらか一方を作り直しやすくしたり、GraphQLを用いることでqueryそのものを変更することなく、呼び出し先のエンドポイントを切り替えることでアプリケーションの振る舞いを変えずにAPIを切り替えることができるような構成にしています。

開発

スケジュールとリソース

今回の開発はα版、β版と2回に分けて段階的にリリースしました。

α版は2023年9月から2023年10月で開発し2023年11月上旬にリリース、β版は2023年11月から2024年1月まで開発し、2024年1月下旬くらいにリリースしています。

開発リソースはα版は1人、β版は2024年に入ったあたりから2人で、それに加えてインフラ担当1人で開発をしました。

基本的にβ版リリースまではアプリケーション側の1人で開発していました。

新規サービスが当たるかどうかは実際に世に出してみないとわからないので、「最小限のリソースで最速でリリースする」という方針でした。

開発のポイント

既存資産を活用

最小限のリソースで、最速でリリースするという方針だったので、まず「全てを1から作る」という選択肢は可能な限り避けました。

幸い弊社には既に運用されてるシステムがあり、そこからの流用を決めました。

具体的には次の内容を流用しました。

アプリケーションの実行基盤まわりの共通コード
フレームワークの各種設定ファイルや設計思想
デプロイやCIのワークフローのコード

共通コードや各種設定ファイル、設計思想は既存の各サービスでほとんどが統一されており、コピペして少しいじったらすぐに使えるような状況に整備されています。

またデプロイやCIまわりは全てGitHub Actionsに統一されており、こちらもワークフローのファイルをコピペして少しいじるだけですぐに使えるようになっています。

これらの既存資産を流用することで、コードを書き、テストで守り、動作環境にデプロイし、最低限動くものを確認できる環境をすぐにセットアップできました。

ゼロからモノを作るうえで動くものを用意することは非常に重要です。動くものをメンバーと共有して確認することで、認識の齟齬を防ぎ、余計な修正作業を減らすことが出来ます。

データ投入を簡略化

データ投入は開発の中でも時間を取られる作業の1つです。

レビュワーの方から頂いたレビューデータや、各種マスターデータをデータベースに投入する必要があります。

α版の時点ではデータ投入を簡略化するために、全てのデータをseedで投入することにしました。

本来であればデータ投入用の管理画面を作るのがベストなのですが、α版のリリース前に1人で開発してる状況で管理画面を作るようなリソースはありませんでした。

機能の取捨選択

初期リリースの目的は多くのユーザーを獲得することではなく、「サービスが受け入れられるかどうかを可能な限り早い段階で判断する」ことにあります。

そのため、「サービスが受け入れられるかどうかの判断に必要のない機能」を初期リリースのスコープから外しました。

具体例を挙げると、β版リリースまでは画像アップロードの機能を外しました。

レビューデータやアバター画像などをアップロード出来るようにしたかったのですが、画像アップロードを実現しようとすると、色々と考えないといけないことがあります。

画像のアップロード先はどうするのか？削除は許可するのか？画像サイズはどこまで許すのか？などなど色々出てきます。

今回は画像のアップロードを許可せず、運営チームが用意した画像をS3に直接アップロードして、そこへのパスをseedに直接書くことで画像ファイルの管理を単純、簡略化しました。

この機能を簡略化するだけだと良くて1,2日程度の開発工数削減に留まると思います。しかし、このような取捨選択をいくつかすることによって、結果的に半月や1ヶ月程度の工数削減に繋がりました。

この機能を削減して大量に工数削減、といったものではなく、ミニマムな削減の意思決定を大量に行うことによって実現しているのです。

テストコード

色々な取捨選択の意思決定の中で、テストコードだけは切らずに必ず用意していました。

「時間が無いからテストを書かないのではなく、テストを書かないから時間が無い」というのは事実で、結果的にテストが守ってくれているおかげで、余計なことに時間を取られずにやりたいことに集中できるのです。

テストコードのお陰で、α版リリース以降に本番環境で発生した不具合、障害は記憶しているだけですが片手で数えられる程度でした。

管理画面を内製

α版のリリースにより、「このサービスが世に受け入れられる」ことを確認できたため、β版のリリースに向けて着手しました。

α版からβ版に向けて何を実現させるのかを検討している間、開発するものがなくて時間を持て余していたので管理画面を内製で実装することにしました。

各種マスターデータやレビュワーの方から頂いたレビューデータなど、運営で管理したいデータは多数あります。

それらの変更のたびにseedの再実行、データの変更を依頼するようなフローにしてしまうと、エンジニアが機能追加の作業に集中できなくなってしまいます。

β版リリースからはエンジニアを介さずにデータの追加、変更を運営メンバーだけで完結出来るようにしました。

管理画面の画面数は25個程度で、APIとフロントエンド込みで1人で2、3週間程度で開発しました。

管理画面はSSRが必要ないので純粋なReactのSPAで、CSSフレームワークにBulmaを採用しました。

管理画面を用意できたことによって、β版以降の開発時に運営メンバーからのデータ管理周りの依頼が無くなるので、開発作業に集中できるようになりました。

反省点

Findy Toolsの開発では、チャレンジ枠としてNext.jsのApp Routerを採用しました。

既存プロダクトに用いられているPages Routerからの移行を検証する狙いもありましたが、今回は上手くいかなかったと反省しています。

誤解を与えないように言うと、Next.jsのApp Router自体は悪いものではありません。

何が上手くいかなかったかというと、既存資産の流用をした結果、利用していたライブラリがApp Routerに対応出来ておらず、想定していた以上の工数を取られてしまったことです。

弊社ではApp Routerを初めて採用したケースであり、社内にノウハウが蓄積していなかったため、問題解決に時間がかかってしまいました。

今後、他サービスでのApp Routerの採用時に今回のノウハウを活用できるようになったと思いますが、今回のような開発スピードを優先されるケースで採用するべきではなかったかなと思います。

まとめ

いかがでしたでしょうか？

新規サービスの開発時にはリソースやスケジュールに大きな制約が課せられます。そのような状況下でやるべきこと、やるべきではないことの取捨選択の意思決定が非常に重要になってきます。

半年近く1人で開発をしてきたFindy Toolsですが、みなさまのおかげもありサービスが順調に成長しており、今では開発に着手しているエンジニアの人数を増やすことができました。

今後もFindy Toolsをより良いサービスにしていくために、引き続き開発を進めていきます。

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers

2024-04-15

Wallaby.jsを使ってフロントエンド開発のテストを効率化しよう

Findy Team+でフロントエンドエンジニアをしている川村(@peijun333)です。

Findy では、フロントエンドのコード品質と安定性を確保するために Jest などのテストフレームワークを積極的に活用しています。通常、Jest は CLI から実行してテスト結果をコンソールで確認しますが、コマンドを用意する手間や、テスト経過のデバッグのために都度 console.log などでその内容を確認しなければならずとても不便です。

そこで、今回はテストの自動化とリアルタイムなフィードバックを提供する JavaScript の統合テストツールである Wallaby.js を紹介します。Wallaby.js を導入することで、開発効率の向上が期待できます。

Wallaby.js とは？
前提条件
VS Code でテストの修正
Wallaby.js はリファクタリングに強い
スナップショットの更新
ユニットテストにおけるデバッグ機能の紹介
Wallaby.js を使ってみて
最後に

Wallaby.js とは？

Wallaby.js is an integrated continuous testing tool for JavaScript. It runs your tests immediately as you change your code (you don’t even have to save the file) and displays various results (including the code coverage, error and console messages) right inside your code editor, next to your code. Wallaby.js is great for doing JavaScript TDD (Test-driven development) or BDD (Behavior Driven Development), but it works great for other approaches as well.

公式ドキュメントより Introduction: What is Wallaby.js?

Wallaby.js は JavaScript の統合テストツールで、次のような機能があります。

リアルタイムなフィードバック
- Wallaby.js は、テストの実行に手動のステップが不要なため、コードを変更するとリアルタイムで結果をフィードバックしてくれます。
エディタ内でのテスト結果表示
- Wallaby.js は、コードエディター内にテスト結果を表示してくれます。エラーやカバレッジ情報などが、コードの隣に直接表示されるため、エディタから離れることなく、テスト結果を確認できます。
デバッグ機能
- Value Explorer を使用することで、任意の場所で値を調査し、呼び出し元のコールスタックを確認できます。また、コンソールログをエディタ上に表示する機能も備えており、デバッグプロセスをスムーズにします。

また、サポートしているコードエディタとテストフレームワークが豊富で導入がとても容易です。

Wallaby.js は OSS 開発では無料で利用できますが、商用利用の場合は有料です。ファインディではフロントエンドを開発するメンバーにアカウントを発行しています。

前提条件

ここから実例を交えて機能を紹介します。実例に使った動作環境は以下の通りです。

VS Code
- VS Code 上にWallaby.js の拡張機能をインストールする必要があります
- VS Code 以外のコードエディタもサポートされていますが今回は VS Code を使った紹介になります
React
- version 18.2.0
Jest
- version 29.6.1
React Testing Library
- version 14.0.0

Wallaby.js の導入に関する詳細な手順や設定方法については、公式ドキュメントを参照してください。

VS Code でテストの修正

Wallaby.js はサポートされているエディタ上で動作します。今回は VS Code で普段テストを書いている様子を紹介します。

以下は、GraphQL を用いてユーザーデータを正しく取得できているか確認するテストの例です。

+ expect(result.current.users).toStrictEqual([{ id: '1', name: 'name' }]);
- expect(result.current.users).toStrictEqual([{ id: 1, name: 'name' }]);

id が number 値ではなく string の '1' であるべきなのですが、上記動画の例では誤った結果を書いています。 Wallaby.js ではこのようにテスト結果がコードエディタ上(VS Code の例)にリアルタイムに反映されます。

予想される結果と実際の結果が異なる場合、赤色のテキストでエラー文が表示されます。そこにカーソルを合わせることで、具体的に差分内容を VS Code 上で確認できます。

- Expected  - 1
+ Received  + 1

  Array [
    Object {
-     "id": 1,
+     "id": "1",
      "name": "name",
    },
  ]

また、VS Code 上では左側の余白に四角のテストカバレッジインジゲーターが赤色から緑色に変わった様子が確認できたかと思います。これにより視覚的にテストのカバレッジを確認できます。

詳細: Editor Code Coverage Indicators

この機能のメリットは、エディタ上でテストの操作が完結でき、さらにリアルタイムに優れている点です。テストの実行や結果、失敗時のエラー原因の迅速な特定、ナビゲーション、差分ビューなど、すべてをエディタ上で行うことができます。

Wallaby.js はリファクタリングに強い

特にリファクタリングでは、 Wallaby.js の機能の 1 つである「リアルタイムにテスト結果がフィードバックされる機能」が発揮されます。

以下はユーザーデータから空の name を取り除けることを確認するテストの例です。

テスト結果と関数のインターフェイスはそのままで、ロジックのみをリファクタリングしています。こちらの例のように、リアルタイムにテストが失敗し、リファクタリング後ファイルを保存せずともテストが成功しました。

このようにリアルタイムにテストが落ちてくれるので、関数の影響範囲がわかりやすく、テスト結果からすぐにフィードバックされることで効率よくリファクタリングが可能です。

スナップショットの更新

次にスナップショットテストの更新について紹介します。スナップショットテストとは、UI が予期せず変更されていないかを確かめるテストです。Findy Team+では @testing-library/react を使いコンポーネントのスナップショットを撮影し、必要に応じて差分を更新しています。

はじめに Wallaby.js を使わずにJest のスナップショットを更新する手順をみてみましょう。

次の例は title と description を表示するコンポーネントのスナップショットテストです。

import { render } from "@testing-library/react";

import { TestComponent } from "./test.component";

const props = {
  title: "title",
  description: "description",
};

describe("TestComponent", () => {
  it("表示確認", () => {
    const { asFragment } = render(<TestComponent {...props} />);

    expect(asFragment()).toMatchSnapshot();
  });
});

実装コード

type Props = {
  title: string;
  description: string;
};

export const TestComponent = ({ title, description }: Props) => {
  return (
    <>
      <div>{title}</div>
      <div>{description}</div>
    </>
  );
};

@testing-library/react の render 関数を使いスナップショットを撮影しています。このテストを初めて実行すると次のようなスナップショットファイルが作成されます。

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`TestComponent 表示確認 1`] = `
<DocumentFragment>
  <div>
    title
  </div>
  <div>
    description
  </div>
</DocumentFragment>
`;

仕様の変更により、description を表示するタグを <span> タグに変更してみます。

- <div>{description}</div>
+ <span>{description}</span>

そしてテストを再度実行すると UI の差分によりテストが失敗します。

 ● TestComponent › 表示確認

    expect(received).toMatchSnapshot()

    Snapshot name: `TestComponent 表示確認 1`

    - Snapshot  - 2
    + Received  + 2

      <DocumentFragment>
        <div>
          title
        </div>
    -   <div>
    +   <span>
          description
    -   </div>
    +   </span>
      </DocumentFragment>

      12 |     const { asFragment } = render(<TestComponent {...props} />);
      13 |
    > 14 |     expect(asFragment()).toMatchSnapshot();
         |                          ^
      15 |   });
      16 | });
      17 |
 › 1 snapshot failed.

今回は description を表示するタグは div ではなく span タグが正しいのでスナップショットを更新する必要があります。

Jest でスナップショットを更新するには --updateSnapshot や -u オプションを使い更新します。 (またはウォッチモードで対話的に更新)

以上の手順を踏むことでスナップショットの更新が完了します。

今回は 1 ファイルのみの修正で変更差分も軽微なものですが、複数のテストが失敗した場合、目的のテストを見つける手間と時間がかかります。また、エディタからターミナルに移動しコマンドを実行する必要があるため、コンテキストを切り替える必要があり、多くの時間が消費されます。

次に Wallaby.js を使ったスナップショットの更新をみてみましょう。

エラーにカーソルを合わせ、差分を確認した後、右上のカメラアイコンをクリックしただけです。

失敗したテストをエディタで確認し、スナップショットを直接更新するだけなので、目的のテストを見つける手間も時間もかかりません。

ユニットテストにおけるデバッグ機能の紹介

Wallaby.js には Value Explorer という機能があります。これを活用することで、デバッグ作業を効率化でき手動でのログ出力作業を大幅に削減できます。

また、テスト実行ログに記録されている値に対して、呼び出し元(実装コード)の Call Stack を調べることもできます。

Value Explorer を使用することで、標準出力をコードに仕込まずともデバッグ作業を可能にしますが、使い慣れている console.log を使ったデバッグも Wallaby.js は対応しています。エディタ上にログの結果を表示できるため、コードとログを同時に確認しながらデバッグ作業を行うことができます。

Wallaby.js は多様なログの確認方法があり、当記事では紹介しきれないので気になる方はチェックしてみてください。

Introduction: Advanced Logging

Wallaby.js を使ってみて

Wallaby.js を使ってみて特にリアルタイムにテスト結果がフィードバックされる点はとても便利だと感じました。Wallaby.js を導入する前はファイル単位やテストケース単位で、テストを実行させる必要があり時間がかかっていましたが、リアルタイムにテスト結果を反映してくれるので実装に集中して開発を進めることができます。リファクタリングでは、リファクタリングの前後でインターフェイスが保たれているかをエディタ上のテストカバレッジインジゲーターから確認できる点は Wallaby.js の強みだと感じました。

FAIL	PASS

また、Smart Start という機能により、コードの変更により影響を受けた箇所のみ自動的にテストが実行されるので、とても高速にストレスフリーで動作してくれます。Findy Team+のように大規模なプロジェクトでも高速に動作してくれるのは非常に強みだと思います。

最後に

今回の記事では、JavaScript の統合テストツールである Wallaby.js について紹介しました。

Wallaby.js の導入により、開発プロセスの効率化やコードの品質・安定性の向上が期待できます。是非、Wallaby.js を活用して、よりスムーズなフロントエンド開発を実現してみてください。

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers

2024-04-12

出会っていたのはファインディ - 入社エントリ -

こんにちは、あるいはこんばんは。 @gessy0129 です。

このたび、ファインディに入社しましたので、入社エントリーをさせていただきます。

お時間のあるときにご覧いただければと思います。

ファインディに対する想いと気持ち

改めて、この度、ファインディ株式会社に正式に参加することとなりました。

パチパチパチパチ

昨年からいくつかのnote記事を執筆させていただいたところでございますが、それに絡めつつ、今回の気持ちを綴りたいと思います。

参考記事：

ANDPADを退任しました｜げっしー

2024年目標と決意と挑戦と｜げっしー

相変わらず、自身の掲げるミッションは、 半径数メートルから幸せの連鎖を生み出す という事だと思っています。

過去の在籍企業で、VPoEや開発本部長として長い間勤務をしてきました。その中で、ものづくりに集中しているエンジニアたちを支えていく事というのは相当なやりがいでした。エンジニアたちが幸せに業務出来る環境を整え、それが連鎖していくようにすること。これはとても楽しかったです。 ※ もちろんVPoE としての業務はこれだけではないです。

この領域を更に深め、挑戦するエンジニアを応援していきたいという思いが強まりました。

そして、その想いが高まった時、多くの選択肢の中からファインディと出会いました。

ファインディのミッション、ビジョン、バリューに共感し、これは非常に大きな出会いであると感じております。

エンジニアの可能性を拡げ、スタートアップのエコシステムに貢献できることを願っています。

やろうとしてること

ファインディは色んな事業を展開してます。

エンジニアの転職を支える転職事業
フリーランスエンジニアを支えるフリーランス事業
国内外のエンジニアと企業をつなげるグローバル事業
活躍するエンジニアを支えるTeam+事業
技術選定や意思決定をサポートするTools事業

などなどがあります。

これらの事業がすべて、挑戦するエンジニアのプラットフォームを作り上げ、エンジニアの可能性を広げることにつながると考えております。

そして、CEOの山田さんやCTOの佐藤さんが、この領域で挑戦しようとしていることに感銘を受けております。

ここで、素晴らしいメンバーと共に、挑戦するエンジニアが必要とするサービスを積極的に提供していきたいと思っております。

しかし、まだまだファインディ自体が、挑戦するエンジニア、挑戦したいエンジニアに積極的に選ばれる状況にあるとは言えないのではないかと考えております。

これは、ファインディにとっても僕にとってもさらなる伸び代だと思っております。

「ファインディに相談すればなんとかなる」という状況を作り上げることができればと考えております。

最後に

ファインディの対外活動にも積極的に参加していく予定でございます。

その際は、皆様、よろしくお願いいたします！

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers

2024-04-08

TestProfでワースト5のspec実行時間を8割削減していった話

Findyでエンジニアをしている松村（@shakemurasan）です。

以前、弊社の栁沢が「RailsのCIのテスト実行時間を10分から5分に高速化した話」という記事を投稿しました。

tech.findy.co.jp

本記事ではその少し前のお話、そもそもRSpecの実行時間自体にまだまだあった伸びしろ、特にFactory周りの問題をTestProfというgemを活用して解消していった話となります。

2024-04-05

【エンジニアの日常】エンジニア達の自慢の作業環境を大公開 Part1

自慢の開発環境を大公開

こんにちは。

Findy で Tech Lead をやらせてもらってる戸田です。

Findy 社の Tech Blog を開設して 1 ヶ月程度が経とうとしています。

このブログを通して弊社の技術情報だけでなく社内のエンジニアのことをもっと知ってほしいと考えた結果、今回から 自慢の作業環境を大公開 と題して、社内のエンジニアの作業環境と、そこに対する考え方、思いなどを発信していく事になりました。

弊社のオフィスは東京にありますが、北は北海道、南は福岡まで遠隔地からのフルリモートで JOIN しているエンジニアが多数在籍しております。

エンジニアの多くが各自の自宅から作業しており、きっと自分にとっての最高の環境を整えているはずです！

それでは、弊社エンジニア達の自慢の作業環境を見ていきましょう！

作業環境を大公開

戸田

というわけで初回は福岡から JOIN している Tech Lead の戸田の作業環境から紹介させてもらいます。

作業スペースの全体像はこんな感じです

戸田の作業スペースの全体像

基本的には DELLの32 インチの 4K モニタを使い、クラムシェルモードで作業をしています。

スピーカーはモニタのアーム部分に接続しており、イヤホンを繋げてボタン一個で出力切り替えが可能なので、普段はスピーカーを使い静かにしたい時はイヤホンを使う。ということが簡単に切替可能です。

Web カメラとマイクは別途購入して外付けで利用しています。リモートでの作業がメインとなるため、映像、音声環境は最低限のマナーと思い投資しました。

デスクは bauhutte というメーカーの昇降デスクを使っています。

この昇降デスクは電動でボタン一つで高さを自由に変更でき、横幅も奥行きも大きいので色々な作業シーンに合わせて利用することが出来るので非常におすすめです。

そして安心と信頼のバグ退散お守り。CI を通すときや重要なリリースの前に祈りを捧げます。

バグ退散お守り

手元周りはこんな感じ

戸田の作業スペースの手元周り

キーボードは HHKB Professional HYBRID Type-S を使っています。

今まで色々なキーボードを試しました。その結果、個人的に作業終了後の手元の疲れを一番小さく感じたのはこのキーボードでした。

特殊なキー配列ですが、慣れたらコードを書いたりコマンドラインを叩いたりしやすいキーボードだと思います。

マウスは Apple の Magic Trackpad を使っています。マウスに対する拘りはなくて、正直 Mac のショートカットアクションが使えれば何でもいいです。早くマルチペアリングに対応して欲しいです。

また、変わり種としては指の筋トレ用具を手元に置いてます。

事の発端は格ゲーをしてた時に思っていたより指が動かなくて、「人類は薬指と小指を思ってるより使ってないな？」と感じ、この二本の指を鍛えるために買いました。

リモート会議中とか、コードを考えてる時とかずっとこれで指を鍛えてます。これで鍛えだしてから薬指と小指がスムーズに動くようになり、キーボードのタイピングが今までよりもスムーズになった気がします。

作業用 BGM は HomePod mini と Apple Music の合わせ技を使っています。

iPad を HomePod mini とペアリングさせて、サブスクには新曲やサントラがどんどん追加されます。

作業スペースの横には趣味のプラモ作成スペースを、後ろには本棚とプラモケースと積みプラ。

プラモ作成スペース本棚と積みプラ

自分の好きなものに囲まれているというのは、毎日１人で黙々と作業する環境としては想像以上に重要だと思います。

毎日部屋に籠もって1人で作業しているので、五感に入るもので飽きが来ない環境を作ることが大事だと思います。

熊野

青森からフルリモートの熊野（@shoota）です。フルリモートは 2017 年夏からで 7 年目になります。

まずはメインのデスクから。

MacBook Pro 16” をノート用スタンドに載せ、デュアルディスプレイで作業をしています。 MacBook ディスプレイは基本的には Slack 専用で、ほぼすべての作業は外部ディスプレイ + 仮想デスクトップでこなしています。

外部ディスプレイは DELL の 4K ハブモニターに仕事用の MBP と個人用の Mac mini を繋いでいて、画面を切り替えると接続しているキーボードも自動で切り替わるのが気に入っています。

デスクライトを Amazon Alexa に接続し、デスク左側の Amazon Echo から音声操作できるようにしています。デスクから離れたあとにライトの消し忘れに気づくので、遠くからでも声でライトのオンオフができるのが便利です。 Echo は Spotify などの音楽再生をしたり、他の家電の操作にも使っています。

デスク右側は Anker の無接地タイプの充電器で iPhone のスタンバイ表示をしています。その隣には iPad mini をおいていて、ちょっとしたメモをしたり、作業をしながらオンラインイベントを見たりするときに使っています。

全体的に黒で統一するのが好きで、トラックパッドだけが白なのでそろそろ黒の方に買い替えちゃおうかなと思っています。

キーボードは Keychron の分離式キーボード Keychron Q11 QMK Custom Mechanical Keyboard、ポイントデバイスは Magic Trackpad2 です。