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

こんにちは。

FindyのFreelance開発チームの久木田です。

今回は 自慢の作業環境を大公開 のPart3になります。

前回までの記事はこちら ↓

👉 自慢の作業環境を大公開シリーズ

Part3は関西特集ということで、大阪と京都からフルリモートでJOINしているエンジニアたちの作業環境を公開します!

作業環境を大公開

久木田

まずは大阪から JOIN している久木田の作業環境から紹介していきます。

作業環境の全体像はこんな感じになっています。

ディスプレイ3台PC2台おいても広々スペース

会社支給の MacBook Pro 14インチ をノート用スタンドに載せて使っています。

ディスプレイはノートPCのディスプレイを含めて4枚使っていて、左からブラウジング用・コーディング用・Slack用・Datadog等の監視ツールのダッシュボード閲覧用として使っています。

このデスクですが、工務店を営む父親に頼んで、一緒に手伝いつつ、天板の木材から切り出して、取り付けてもらったものになります。

音声環境周りですが、自分は Anker PowerConf S3 というスピーカーフォンを使っています。

スピーカーフォン:Anker PowerConf S3

マイクも色々試しましたが、途中で耳を塞ぐのが個人的に好きじゃなかったのに気がついてから、このスピーカーフォンを愛用しています。

ミュートボタンが Zoom と Google Meet のミュートと連動してくれているのもお気に入りポイントです。

ちなみにカメラは MacBook のカメラの方が、市販されている廉価なWebカメラより性能が良いと思っているので、そのまま使っています。

キーボードは HHKB Professional2を使っていて、トラックボールは Kensington スリムブレードトラックボール を使っています。

HHKBのUS配列が好みです

ボールを横回転させてするスクロールが慣れると快適

キーボードは大学院生の頃からHHKBが好きで(当時は廉価版のHHKB Lite2 for Macでしたが)、この画像のキーボードは社会人になった7年前くらいからずっと使っているものです。

トラックボールは前職の上司の方からお下がりとしてもらって以来、このKensingtonのスリムブレードを使っていて、今使っているものは2代目になります。

トラックボールも親指タイプのものなど色々試した結果、このデバイスに落ち着きました。

広い画面を移動するのに、トラックボールはおすすめです。

そして使っている椅子もこだわっているものの1つになりまして、ハーマンミラーの エンボディゲーミングチェア を使っています。

背面の青いデザインも気に入っています

大阪にハーマンミラーストア心斎橋があり、そこへ行って色々な椅子を試した結果、この椅子を選びました。

背もたれが背骨のカーブにフィットしているので体重重めの自分も快適に座れています。

後ろにデスクトップPCが見えていますが、これは私用のPCで左のディスプレイの入力切替をして使っています。

ディスプレイの奥にあるのが自分でパーツを取り寄せて組み立てたPC

前回や前々回の作業環境紹介では私用と仕事用でデバイス共用している人が多かったですが、自分はmacとwindowsでOSが違っていたり、トラックボールだとゲームがやりづらかったりするので、手元のデバイスも全く別のものを用意して使っています。

最後に机の角に飾っている好きなものごちゃまぜディスプレイを写して自分の作業環境紹介は終わります。

攻殻機動隊・ウマ娘・ガンダム・にじさんじ

金丸

次に京都から JOIN している金丸の作業環境を紹介します。

作業環境の全体はこのようになっています。

ディスプレイとノートPCを最小限のスペースで設置しています

会社支給の MacBook Pro 14インチ をノートPC用アームに載せて使っています。 デスクの幅が120cmのためノートPCを宙に浮かせることでスペースを節約しています。

デスクには COFOの昇降デスク を利用し、定期的に立ち上がって作業をするようにしています。 天板の裏がマグネットになっているため、マグネットフックで雑に収納できるところが気に入っています。

ディスプレイは HP社の曲面ディスプレイ を利用しています。

ディスプレイに設置したライトで常に明るい

WQHD、USBハブ機能、USB-C(USB PD) に対応しているため、給電 + USB ケーブル1本で出来るところが気に入っています。 ウルトラワイドなディスプレイですが曲面になっているため違和感なく使えています。

スピーカーにはクラウドファンディングで購入した ovo を利用しています。

マットな金色がデスクに映えます

コンパクトな本体でも音割れが少なく、気に入っています。

通話には eMeet Luna を利用しています。

有線/Bluetooth切替可能で取り回し◎

本体にノイズキャンセリング機能がついているため、タイピング音などが軽減されるところが気に入っています。

キーボードは分割キーボードの 7sPro を利用しています。

レトロっぽいキーキャップが好み

「HHKBの配列で分割キーボードを使いたい」という要望を満たしているキーボードで、キースイッチを変えながら3年くらい使っています。 ホットスワップに対応しているのでキースイッチの変更が出来るところもお気に入りポイントです。 現在は alpacaスイッチ をセットして利用しています。

マウスは MX MASTER 3Sを利用しています。

勢いよく動かしてもカーソルがブレない点がお気に入りです

トラックパッド、トラックボールと試してみたのですが、結局マウスに戻ってきて以来、このマウスを利用しています。

最後に推しを詰め込んだディスプレイを紹介して、作業環境紹介を終わります。

カニさん・ガブモン・幽遊白書・ズートピア

西村

最後に、京都からフルリモートで Findyの転職サービス を開発している西村の作業環境を紹介します。

妻と同じ部屋でリモートワークをしているため、机を向かい合わせるように設置しています。奥に見えるのが妻側のデスクです。

あまり広くない部屋なので、作業スペースもコンパクトです

ディスプレイは DELL U2720QM を使用しています。4K 27インチのディスプレイなので、これ1つでも十分に作業が可能です。 MacBook Pro 16 をスタンドに載せて、デュアルディスプレイとしています。MacBook は主に Slack 専用としています。

こだわりポイントとしては、目線を下げないためにディスプレイをスタンドの上に置いていることです。 猫背気味で首や肩に負担を掛けがちなので、それを軽減できないかなと考えてこのようにしています。

また、ディスプレイと正対するように座ることも意識しています。 リモートワークを始めた初期に、目線を左右どちらかに寄せ続けて首や腰の片側だけが痛くなってしまった。という苦い経験から、このような工夫をしています。

ただ、少し目が疲れやすく感じるので、本来であればもう少しディスプレイとの距離を取りたいと考えています。 しかし部屋の広さの関係で、これ以上奥行きのあるデスクを置くことができないので、この状態で我慢しています。

キーボードは Keychron K2 を使用しています。

Keychron K2 のキーボードと木製のパームレスト

元々は HHKB を使ってみたいなと思っていたのですが、値段が高くてなかなか手が出せていなかったところに前職時代の先輩に勧められて購入しました。 比較的安価だったので試しに使ってみたところ、とても打ちやすく非常に気に入っています。かれこれ3年以上経ちました。

マウスは Apple の Magic Trackpad を使っています。マウスに対するこだわりはなく、友人からプレゼントしてもらったものをずっと使い続けています。

また、手首から先の負担を減らす目的で、 FILCO のパームレスト を使っています。肌に優しそうという理由で木製のものを選びました。

今回はデスクの写真を撮るタイミングだったのでかなりスッキリとしています。Findyでは社内輪読会も行っており、業務時間中にもチームで同じ書籍を読みエンジニアのレベルアップを図っています。日常的には、その輪読会用の書籍が置いてあったりすぐに読み返したりできるようにしています。

購入して1年ほど経ってから成長の兆しが見え始めたお気に入りのサボテン

まとめ

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

やはり、キーボードにはそれぞれこだわりがありましたね!

また、今回の記事を通して意外にもスピーカーマイクを使っているのが自分だけではないことに驚きました。 自分の環境でも記載しましたが、マイクの物理スイッチはおすすめなので是非試してみてください!

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

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

Findy転職フロントエンドの開発生産性を向上させるためにやったこと

こんにちは、ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 この記事では、転職サービス Findy の開発チームにおける開発生産性の向上に対する取り組みをご紹介します。

以前の状況

2020年頃の Findy は Ruby on Rails と React のモノリス構成で作られていました。 機能の増加に従いコードが複雑化し、しだいに開発スピードが伸び悩むようになりました。

ここで Findy Team+ で算出した当時のリードタイムを見てみましょう。

2020年のFindyのリードタイム

上記のグラフから次のことがわかります。

  • 改修が本番に適用されるまで 約1週間 かかる
  • プルリクエストがレビューされるまで 約5日 放置される
  • プルリクエストのレビュー完了までに 約2日と半日 かかる

1年を通してプルリクエスト数の平均が2.0を超える日が無かったことからも苦しい状況であったことが推測できます。

モノリスの解体

前述の通り Findy は Rails モノリスで作られており、CI にフロントエンドとバックエンドの両方が含まれていることから、画面の文言を1つ更新するだけでも長い CI 待ちが発生します。

この状況を打破するために、Findy で最初に行われた取り組みは「Rails モノリスの解体」でした。

約3ヵ月かけてバックエンド側を Rails の API モード、フロントエンド側を Next.js で再実装するという大掛かりなプロジェクトでしたが、これによりフロントエンドとバックエンドで独立して動けるようになったため、先述した CI 待ちを大幅に短縮できました。

実際の効果は note の記事 にて弊社 CTO が紹介しておりますので、そちらも是非ご一読ください。軽微な改修であれば1日で修正するスピードを実現し、最速でユーザーに価値を届ける基盤を作ったのがモノリス解体の大きな効果と言えるでしょう。

開発基盤の刷新

2021年5月、モノリス解体後のフロントエンドが晴れてリリースされました。大きな不具合もなく無事に終わったと安心したいところですが、まだ残っている課題を解決しなければなりません。

フロントエンド側に残された課題は次の通りです。

  • バージョンの古いツール・ライブラリが多数
  • コンポーネントの書き方が古い
  • 型(Flow)はあるがうまく動作していない
  • テストが書かれていない
  • 見通しの悪いフロントエンド設計

最初に、依存ライブラリのアップデートや使われなくなったライブラリを削除していきました。また、Dependabot を導入し定期的に更新する体制を整えました。

次に Nx を導入し、モダンな開発環境へ移行していきました。Nx は前職で利用した経験があり、コマンドひとつで TypeScript + React + Jest + ESLint + Prettier が揃った開発環境を作成できるため移行は短期間で済みました。ここで導入した Nx は、後の CI 高速化への布石となります。

Findy には開発当初から React が用いられておりましたが、この時はまだコンポーネントが Class Component で書かれてありました。今後の React エコシステムの発展に追従するべく Function Component への書き換えも同時に進めました。

Flow から TypeScript への移行は直接書き換えるのが難しかったため、一度全てのソースコードから Flow の型アノテーションを外して純粋な JavaScript にし、その後 TypeScript で書き直しました。移行の早い段階で strict: true で書くようにしたため、Null チェック漏れによる不具合を大幅に削減できたと思います。

当時は API レスポンスに対しても手作業で型付けを行っていましたが、API の仕様が複雑であったりドキュメントと同期するのが難しかったことから、後に REST API から GraphQL に移行し、GraphQL Code Generator による型生成が採用されるようになります。

コンポーネント設計の刷新

当時の実装では、コンポーネントは Container Component / Presentational Component のパターンで書かれてありました。メンバーの習熟度やテストのしやすさを考慮し、基本設計は踏襲しつつ、下記に示すようなデータの流入元に着目した三層構造へと拡張しました。

コンポーネント名 カスタムフック名 扱うデータ
Page Component Params Hook ブラウザURL
Container Component Facade Hook API や ストレージ等
Presentational Component Presenter Hook フォーム

各層での責務が明確になったことで実装時の混乱が少なくなったと思います。

余談ですが本設計は筆者が Angular コミュニティから得られた知見を React アプリケーションに転用したものとなります。不思議な縁もあるものですね。*1

テストの拡充

プロジェクト進行中にいくつかの不具合に遭遇することがありましたが、それらのほとんどはテストがあれば防げたものでした。将来的な変更に耐えられるよう、テストの拡充は早期に着手しました。幸いバックエンド側では既に「テストを書くのは当たり前」という文化が根付いていたため、フロントエンドのテスト導入のハードルは高くありませんでした。

当時はまだメンバー全員がフロントエンドのテストに慣れている訳ではなかったため、テストのお手本となるような実装例を増やしていくことから始めました。まず、ユーティリティ等の入出力の関係が明らかなものからユニットテストを書き、次にコンポーネントのスナップショットテスト、それからインタラクションテストや結合テストといったように範囲を広げていきました。

また、テストを書くモチベーションを向上させる工夫として Wallaby.js のような可視化ツールを導入しました。Wallaby.js については次の記事もご参照ください。

tech.findy.co.jp

今では全員が当たり前のようにフロントエンドのテストを書くようになりました。テストによって守られているという安心感もさることながら、テストを書くことが習慣化したことによって「テストを書きやすいように設計が洗練される」といった副次的な効果が得られたのも嬉しいところでした。

CI の高速化

コードベースが増え、ビルドやテストの実行時間が増えていくと、CIの待ち時間も長くなっていきます。CI 時間の増加はリードタイムの増加に直結するため、改善は必須でした。

開発基盤を刷新するにあたり、CI 時間の増加は予め想定されていたため Nx を導入し、 nx affected コマンドによる変更検知によって必要なジョブのみ実行することで CI の高速化を図りました。ジョブの再実行といった変更検知だけでは高速化が難しいものに対しては Nx Cloud を導入し、リモートキャッシュを活用した高速化を実施しました。

結果は次の通りです。CI 時間は平均6分で、キャッシュヒットしない場合は16〜17分かかることもありますが、早い時は2〜3分で終わるようになりました。

ジョブ単位の詳細を次の図に示します。

Nx Cloudによる高速化の内訳

Nx Cloud 導入により300時間以上の CI 時間を削減できました。ここではフロントエンド側のCI高速化を取り上げましたが、バックエンド側の取り組みも記事にされておりますので、ご興味のある方は是非ご一読ください。

tech.findy.co.jp

改善の効果

それでは、モノリス解体をはじめとした様々な取り組みの成果を見ていきましょう。次の図は2023年における転職サービスの Findy のフロントエンドとバックエンドそれぞれのリードタイムを計測した結果を示しています。

フロントエンド バックエンド

リードタイムが100時間を超えていた状況から大幅な改善ができました。特にフロントエンドに関してはマージまでの時間が8時間を切っていることから、高速な開発を実践できていると言えます。

フロントエンドのアクティビティの変化についても見ていきましょう。モノリス解体が実施された2021年と比較すると、近年のアクティビティ量は著しく増加しています。

2021年 2023年

もちろんこれはメンバーの増加が主な要因として考えられますが(採用チームの皆さんいつもありがとうございます)、それだけでなく、一人あたりのアクティビティが増えた(=一人あたりのパフォーマンスが向上した)ことも結果に貢献していると思います。

2021年(1人あたり) 2023年(1人あたり)

2021年当時の倍のアクティビティを示しているので、単純計算で開発生産性も倍になっていると言えますね!頑張った甲斐がありました 💪

まとめ

ファインディでは「モノリスの解体」「開発基盤の刷新」「CI の高速化」を実施し、開発生産性を向上させることに成功しました。

数年前まではファインディも開発スピードに伸び悩んでいたと知って驚いた方も多いかもしれません。ここ数年で大きく成長できたのは社内の優秀なメンバーの協力あってのものだと感謝しています。

ここまでご覧いただいた方は、ファインディはそこまで特別なことをやっている訳ではない とお気付きになられたかと思います。

1つ1つの積み重ねが今の私達の開発を支えています。

日々の改善を大事にしていきましょう。


ファインディは積極的にエンジニアを採用しています。CI/CD を始め、Four Keys、開発生産性、技術トレンド、転職市場など興味のある方は、お気軽にカジュアル面談を受けてみてください。

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

herp.careers

ファインディはRubyKaigi 2024 にPlatinum Sponsorsとして協賛します!

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

ファインディは昨年に続きRubyKaigi 2024 でPlatinum Sponsorsとして協賛します。RubyKaigi 2018からここまで継続して協賛できているのは、様々な御縁のおかげだと感じています。Rubyコミュニティおよびファインディを応援してくださる方には感謝の気持ちでいっぱいです。

Platinum Sponsorsとして実施すること

今年のファインディは、ブース出展とDrinkupを2件実施させて頂く予定です。

Drinkupはconnpass上にオープンさせて頂いています。

findy.connpass.com
findy.connpass.com

ほぼほぼ埋まってしまいましたが、ぜひご参加頂けると嬉しいです!

ブースには、Findy Team+の開発リーダーである@ham0215をはじめ、@yuichiro826、CTOの@ma3tkやVPoEの@kxmxyxが参加します。僕もいる予定ですので、ぜひ遊びに来てください!

ブースはこちらです!

ブース内容の全貌については、現在、最終の内容をFixさせるための作業を実施中です。ご期待頂ければ幸いです! 一部、公開させて頂きますと、Ruby Code Quizというクイズを用意しております。開催期間中は内容が毎日変わるので、ぜひ毎日挑戦しにきてください!

前年からの振り返り

昨年のRubyKaigiから早一年が経過しました。この間のファインディの変化を、一年前と比較しながらご紹介します。主にRubyに関係することをメインにピックアップさせて頂きました。

プロダクト開発状況変化

Findy Team+を使って、弊社がRubyで開発している主要バックエンドリポジトリの確認をしました。
2023年4月と2024年4月の対比です。

直感的に分かりやすく増加してますよね!

グラフだけだと分かりにくいかもしれないので、具体的な数字で表現させて頂きます。

コミット数:1.49
PR数:1.56
コミット人数:1.34
オープンからマージまでの平均時間:13%削減

人数が増えると開発時間が長くなったり指標が悪化することもあるのかな?と思いながら見ていたら主要スタッツが軒並み向上していて正直言って驚きました。

普段はこういうグルーピングで見ることがないのでなかなかに新鮮な図です。

Ruby biz Grand prix 2023 ソーシャルインパクト受賞

rubybiz.jp

RubyKaigi 2023の参加をきっかけにRuby bizにも応募させて頂きまして、ソーシャルインパクト賞を受賞することが出来ました。本当にありがとうございます。

今回のRubyKaigiにも参加予定の@ham0215からのRubyに関する熱いコメントもあり、これから先、Rubyへの貢献をより一層強めていきたいと考える事が出来ました。

この度はソーシャルインパクト賞をいただくことができ、誠に光栄に思います。エンジニア組織の開発パフォーマンス向上を支援するSaaS「Findy Team+」が、日本発の「Ruby biz Grand prix 2023」で受賞をできましたこと、大変喜ばしい限りです。当社では、今回受賞した「Findy Team+」だけではなく、多くのプロダクトでRubyが使われており、Rubyコミュニティや「Ruby on Rails」をはじめとした多くのライブラリなどのおかげでユーザーへ爆速で価値を届けることができております。今後も「Ruby」への恩返しの意味も込めて、Rubyを活用したサービス開発やエンジニア向けのイベントや事例記事の公開などを行い、Rubyコミュニティの発展に寄与してまいります。

(エンジニア組織支援SaaS「Findy Team+」が「Ruby biz Grand prix 2023」でソーシャルインパクト賞を受賞 | ファインディ株式会社のプレスリリースの受賞コメントから引用)

Rubyを使用した新しいプロダクトFindy Toolsがリリース

Findy Toolsは数ヶ月でプロダクトリリースができ、現在も着実に成長中のサービスです。プロダクトとしては未成熟な部分もありますので、皆様からのフィードバックも数多くお聞きしながらプロダクトに反映していきたいと考えています。ブースなどでぜひお聞かせ頂ければ幸いです!

Findy Toolsに関する具体的な内容はテックブログに記載をさせて頂いたのでそちらもぜひご参照ください!
tech.findy.co.jp

いかがでしたか?ファインディのこの一年の歩みをダイジェストでお届けしました。

ファインディ社は引き続きRubyとともに成長していければと考えております。

そして、一緒に働くメンバーを絶賛募集中です。

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

herp.careers

おまけ

ファインディは4月29日にオフィス移転をしました!移転後のオフィスの会議室にもRubyがあります!Rubyでファインディ株式会社が大きくなったこともあり、会議室サイズは比較的大きめです!

ファインディにエンジニアとして入社していいなと思ったこと3選

こんにちは、2024/3/18 からファインディに入社した本田です。

ファインディでは、Findy Team+ という、エンジニア組織の開発生産性を可視化し、開発チームやエンジニアリングメンバーのパフォーマンスを最大化するためのサービスの開発に携わっています。

今回は、入社して一ヶ月ちょっとが経ったので、入社して新メンバーとしていいなと思ったことをご紹介したいと思います。

オンボーディングがわかりやすい

入社すると初めにオンボーディング用 Issue が作成、アサインされていて、いつまでにどういうことができるようになっているために何をしてくのか、というのが一通りまとまっていて、すごいわかりやすかったです。

オンボーディング用 Issue には、次のようなことが記載されています。

  • 新メンバーがキャッチアップすべき事項の一覧

    • 環境構築手順や必要なツールのセットアップ手順、設定項目など
    • コーディング規約やその元となる思想
    • 携わる各リポジトリの役割や、各アプリケーションのアーキテクチャ
    • 各種定期ミーティングの一覧やその内容
  • いつ頃までにどういう業務ができるようになっているかの期待の目安

    • メンバーの経験、スキル、やっていきたいことなどを鑑みてマネージャーと個別にすり合わせもしている

こんな感じにオンボーディングのゴールと期間が定義されていて、
この後にこれらのゴールに向けて知るべきことやそのための資料が記載されている感じです。

初日からこの Issue を見つつメンターの方と密にコミュニケーションを取りながら環境構築や携わるプロダクトの理解をスピード感持ってキャッチアップできました。

個別に知るべきことを逐次教えてもらうのではなく、全体として何を知ってどういう状態になるべきかがわかると、必要に応じて能動的に情報をキャッチアップする動きもでき、非常にやりやすく感じました。

good first issue からコードで貢献できる

急ぎでない簡易かつ新しく参画した人向けの Issue を good first issue というラベルを付けて管理していて、新メンバーはまず good first issue から着手して、開発の流れや携わるプロダクトのコードベースを理解、習得していきます。私もこの流れで開発を始めました。

各 good first issue の Description は新メンバーでも理解できるようちゃんと書かれていて、前述のオンボーディング Issue で紹介されているドキュメントも読みつつ理解しながら Issue を対応していきます。

実際私も他のオンボーディングプログラムを受けつつ3週間ほど good first issue を対応していきましたが、15営業日で 34 PR を出してコードで貢献できました。

他のオンボーディングプログラムもあって波はありますが平均して3PR/日くらいできています

もちろんオンボーディング期間はしっかりインプットすることが大切ではありますが、それもやりつつ入社してすぐに何かしら貢献できることは自信にも繋がりましたし、いいバランスでインプットとアウトプットを両立できました。

レビューがすごく速い

めちゃくちゃ速いです。 PR のレビュアーをアサインしてだいたい 10 分以内、遅くても 1-2時間以内にレビューされます。 もちろんレビュアーの方の状況にもよりますが、体感7-8割くらいの PR は 10 分くらいでレビューされる印象です。

レビュアー一人当たり4件/日、平均しても1h以内にレビューされてます

これにはいくつかの要因がありますが、一番大きいのはバッチサイズを小さくしてリードタイムを短くすることで手戻りやコンフリクトを防ぐ、ということが文化として根付いていることが大きいと感じています。

そのために、

  • PR の粒度を極力小さくする
  • レビュアーは極力優先してレビューする

といったことが徹底されています。

なお、ここらへんの話は先日開催された Qiita Conference での弊社CTO佐藤の発表で詳しく触れていますので、ご興味ある方はぜひご一読ください。

speakerdeck.com

まとめ

他にもご紹介したいことはたくさんありますが、今回は特に新メンバーにとっての開発者体験について3つピックアップして紹介させていただきました。

入社して1ヶ月経過しての感想としては、ファインディは開発スピードを大切にする組織文化が根付いているなと思いました。 より良いプロダクトを作ってより多くのユーザーに良いプロダクトを提供するためにも、開発スピードはその源泉になるものだと思っています。 それをエンジニアとして各々が理解して体現している組織なので、私にとって新しい挑戦ができる環境だと感じています。

このスピード感を自分も体現し、プロダクトの成長と自分の成長を重ねながら良いプロダクトを作っていきたいです。

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

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

【エンジニアの日常】エンジニア達の自慢の作業環境を大公開 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

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

こんにちは。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

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