こんにちは、ファインディ株式会社でフロントエンドのリードをしております 新福( @puku0x )です。 この記事では、 IT/Webエンジニアの転職・求人サイト Findy のメッセージ画面の改善についてご紹介します。 メッセージ画面の課題 メッセージ画面の改善 Apollo Clientキャッシュの利用 読み込み画面の条件修正 ページ設計の最適化 まとめ メッセージ画面の課題 Findyのメッセージ画面は数年前にデザインを刷新しました。 現在では、3種類のメッセージを表示するようになっています。 通常のマッチングのメッセージ プレミアムスカウトのメッセージ Findyからのメッセージ 機能拡充される一方で「読み込みが多い」「画面遷移がサクサク動くようにして欲しい」との声をいただく機会が増えていきました。 実際に触ってみると確かに読み込み画面が頻繁に表示され、画面遷移に時間がかかっていることがわかりました。 メッセージ画面の改善 Apollo Clientキャッシュの利用 最初に取り組んだのはキャッシュの利用です。 Findyのフロントエンドには既にApollo Clientが組み込まれていたので、データ取得の際に fetchPolicy: 'cache-and-network' を指定して体感速度の向上を狙いました。 www.apollographql.com この改修により、ページ切替時の読み込み時間（ローカル環境）は約1,200ms→約900msと高速化されました。 読み込み画面の条件修正 当時の実装では、キャッシュの有無に関係なく読み込み画面を表示するようになっていました。 新しい実装では、読み込み中かつキャッシュが無い場合のみに修正しています。 const { data , loading } = useQuery(..., { fetchPolicy : 'cache-and-network' } ); < Loading isLoading = { loading && !data } /> この改修では、ページ切替時の読み込み時間への直接的な影響はありませんが、体感時間は最大で300ms（読み込み画面のアニメーションの再生時間）ほど削減されていると思われます。 ページ設計の最適化 当時の実装では、前述した3種類のページを個別のファイルで実装し、内部にメッセージの一覧と詳細コンポーネントを持つという構成でした。 このため、ページ遷移の度に一覧と詳細コンポーネントの両方が再描画され、体感速度に課題を残していました。 解決にはページ設計の見直しが必要ですが、 Layouts はFindyのフロントエンドがまだApp Routerに移行できていないため利用できず、 getLayoutパターン も画面全体の再描画を防ぐことが難しいため見送りとなりました。 手詰まりかと思われましたが、他のページで採用されたCatch-all Segmentsの実装を参考に、Optional Catch-all Segmentsを使った実装が今回の要件に合致することがわかったため採用することにしました。 nextjs.org 新しい実装では、 [[...keys]]/index.page.tsx に3種類のページ実装が集約され、ページ遷移の際はメッセージ詳細コンポーネントのみが差し代わるようになっています。 この改修により、メッセージ一覧の不要な読み込みが削減されたため、ページ切替時の読み込み時間（ローカル環境）はメッセージ詳細のキャッシュが無い場合でも約500ms、キャッシュがある場合は読み込み時間をほとんど感じさせないほど大幅に高速化されました。 まとめ キャッシュの活用やページ設計の見直しにより、メッセージ画面のパフォーマンスを向上させることに成功しました。 改善できて嬉しい一方、Optional Catch-all Segments自体はPages Routerの基本的な機能でもあるので「よく調べてから実装していれば...」と反省する点もあります。 ドキュメントはちゃんと読みましょう（自戒）😇 メッセージ画面以外についてもパフォーマンス改善を進めて参りますので、今後もよろしくお願いします。 今回は採用を見送りましたが、App Router移行やReact 19の新機能を活用して更に快適に動作するフロントエンドが実現できればと考えております。 ご興味のある方・挑戦してみたい方はぜひ↓のリンクからご応募ください。私達と一緒にFindyをより良いサービスにしませんか？ ファインディは積極的にエンジニアを採用しています。CI/CD を始め、Four Keys、開発生産性、技術トレンド、転職市場など興味のある方は、お気軽にカジュアル面談を受けてみてください。 ファインディの採用情報はこちら ↓ herp.careers

こんにちは。 2024/05よりファインディ株式会社にデータエンジニアとして入社した田頭( tagasyksk )です。本記事では、データ変換サービスであるDataformについてその活用方法や導入後の効果についてご紹介します。 弊社では、現在次のような構成でデータ基盤を構成しており、BigQuery内でのデータ変換にDataformを利用しています。 この構成を踏まえてご覧いただければ幸いです。それでは見ていきましょう！ Dataformについて 導入の背景 データ基盤に必要な機能が揃っており、簡単に運用を始められること クエリ作成のハードルが非常に低いこと 導入後の効果 FindyでのDataform運用 導入しての課題 改善点 今後の展望 データの品質向上 データモデリング 終わりに Dataformについて サービスの説明については、 公式ドキュメント を引用します。 Dataform は、データ アナリストが BigQuery でデータ変換を行う複雑な SQL ワークフローを開発、テスト、バージョン管理、スケジュール設定するためのサービスです。 例えば、 BigQueryでスケジュール実行しているSQLをGit管理したい 依存関係のあるSQLを順番に実行してほしい クエリの実行結果が意図した挙動を行うかどうかをテストしたい というようなタイミングで活用できます。 導入の背景 Dataform導入前の課題点として、SpreadsheetやGASから利用されているクエリを管理できていませんでした。その結果、利用者が想定しているデータと実際にクエリで取得しているデータが異なっていたり、正しくないテーブルを参照しているケースが発生していました。 このような背景のもと、次のメリットを踏まえてDataformを導入しました。 データ基盤に必要な機能が揃っており、簡単に運用を始められること Dataformは無料でありながら、次のようなデータ基盤に必要な機能が揃っています。 依存関係を定義してDAGを構成できる 特定のタグが付与されたテーブルでワークフローを構成できる データリネージを可視化できる Gitと連携してクエリ管理ができる Google CloudのIAMでカラム単位での権限制御ができる Google Cloudのマネージドサービスなので、余計なメンテナンスをする必要もありません。 クエリ作成のハードルが非常に低いこと ソフトウェア開発の経験がないアナリストやBizサイドにとって、データ基盤への学習コストが低いことは非常に重要です。 Dataformでは.sqlxというSQLを拡張したファイル形式でクエリを開発します。 config { type: "table", "schema": "stg_hoge", "tags": [ "stg_hoge" ], "description": "ユーザー", "columns": { "id": "", "user_name": "ユーザー名", "created_at": "作成日", "updated_at": "更新日", }, "assertions": { "nonNull": [ "id", "user_name", "created_at" ], "uniqueKey": [ "id" ] } } SELECT id, user_name, created_at, updated_at FROM ${ref("lake_hoge", "users")} sqlxは普通のSQLとdescriptionやassertionを含む簡単なconfigで作成可能なので、学習コストが非常に低いです。 Gitを用いたクエリ管理に関しても、Dataform側がバックエンドで行ってくれます。ブラウザ内でクエリ開発からPR作成までが完結するため、Gitのコマンドを覚える必要がありません。 導入後の効果 Dataform導入によって、Bizサイドが作成したクエリをアナリスト・データエンジニアが適切にレビューできるようになりました。 mart層のモデルの数もDataform導入後約4倍となり、開発が活発になっていることが分かります。 また、社内メンバーにDataformの利点について聞いてみたところ、次のような声も聞きました。 1モデルあたり1ファイルの作成で済むので、開発の負担が減った 実行ログをDataformコンソール上で確認できるので、BigQueryと実行ログの横断が楽になった FindyでのDataform運用 ここからはDataformを運用していく上でどのような課題が生じ、どのように解決しているかを詳しく書いていきます。 導入しての課題 Dataform導入当初は、次のようなフローでクエリを開発していました。 データ基盤を運用していく中で、次の課題が生じました。 Production環境にあるテーブルに対してワークスペースからモデルを実行できてしまう Dataformのコンソール画面上から、まだレビューしていないモデルを実行できてしまうのは、意図しないスキーマの変換やデータ変換のバッティングが起きてしまいます。データエンジニア側としても望ましい状態ではありませんでした。 新しいワークフロー用のタグの追加忘れが頻発した Dataformではsqlx内に記述するタグを指定してワークフローを構成します。ワークフローの管理はTerraformで行っていたため、Dataform側のPRからはタグが追加されているか分からず、データ更新時にタグの追加忘れが発覚することがありました。 テーブル変更時、影響範囲が不透明でレビューしづらい クエリを修正する際、修正したテーブルがどのテーブルから参照されているかを確認できていませんでした。計算ロジックの変更がどのテーブルに伝播するのか分からず、レビューが不十分なままマージされてしまうことがありました。 改善点 クエリ開発フローを次のように変更しました。 緊急対応以外の開発は全てdevelop環境で行なうように取り決め、リリース作業を導入しました。また、CIパイプラインの中で次のような項目を自動でチェックし、事故を防止しています。 変更されたsqlxファイルを検出し、クエリとAssertionをDevelop環境で自動実行 変更モデルに依存しているテーブルを検出し、PR上に表示 dataform compile で取得してきたjsonをパースし、変更ファイルのテーブルを検索することで検出しています。 - name: Detect Referenced Table run: | DIFF_FILES=$(echo "${{ steps.get_change_files.outputs.diff_files }}") echo "referenced_tables<<EOF" >> $GITHUB_OUTPUT for file in $DIFF_FILES; do dataset=$(jq -r ".tables[] | select(.fileName == \"$file\") | .canonicalTarget.schema" definition.json) table=$(jq -r ".tables[] | select(.fileName == \"$file\") | .canonicalTarget.name" definition.json) referenced_tables=$(cat definition.json | jq -r ".tables[] | select(.dependencyTargets[]?.schema? == \"$dataset\" and .dependencyTargets[]?.name? == \"$table\") | .canonicalTarget | .schema+\".\"+.name" | awk '!a[$0]++') echo "**$file**" >> $GITHUB_OUTPUT echo "$referenced_tables" >> $GITHUB_OUTPUT done echo "EOF" >> $GITHUB_OUTPUT 開発に利用したワークスペースを自動で削除する Dataform CLIのdry-runでProductionの依存テーブルに問題が無いか確認 1 ワークフローで付与されているタグとsqlxファイル上で付与されているタグを比較し、ワークフローに無いタグをリリースPRで表示 ワークフロー構成で利用されているタグは、Google Cloud側から提供されているAPIで取得できます。 cloud.google.com APIで取得したタグとsqlxに付与されているタグを突合し、ワークフローに追加し忘れたタグが無いか確認しています。追加忘れが見つかった場合は、Terraformで管理しているリリース構成に新しいタグを追加して対応しています。 以上のような改善活動の結果、データの更新漏れやエラーが減りました。アラート対応が減ったことで、データエンジニアが他の業務に時間を割けるようになりました。 リリース導入前後でアラート数を集計してみたのですが、導入前1ヶ月のワークフローで生じたエラーは54件なのに対し、リリース導入後1ヶ月では25件と半分以下になっていました。 今後の展望 データの品質向上 クエリのレビュー体制を整えることができましたが、クエリやデータの品質にはまだ課題を残しています。 GASやスプレッドシート内で発行されていたクエリをDataformの管理下に置くことはできましたが、DRYの原則に反していたり、可読性に課題のあるクエリがまだ存在しています。 データ品質については、異常なデータを検知してアラートを出す仕組みが整える必要があります。Dataformではassertionやtestといった形式でテストを書くことができますが、現状はデフォルトでサポートされているassertion(nullチェックやuniqueKeyなど)を組み込んでいる程度です。 これからも社員が増えていくことが予想される中で、データ品質をどうやって維持・向上していくかはこれからも模索していきたいです。 データモデリング データ利用者がスムーズに分析を進めていくために、データモデリングは必要不可欠です。しかし、弊社ではモデリングに精通した人材がいないのが現状です。 5月からデータエンジニアとアナリストで定期的に集まってデータモデリングの勉強会を行い、チーム内のナレッジを揃えながら少しずつクエリの見直しを進めています。 ※一緒にデータモデリングをしていきたい方がいましたら、是非カジュアル面談にご応募ください！データモデリングを一緒にやっていきましょう！ 終わりに いかがでしたでしょうか？今回は弊社でのDataformの活用について書きました。 弊社ではデータ基盤を共に育てていくメンバーを募集しています。少しでも興味が湧いた方はカジュアル面談お待ちしております！ herp.careers herp.careers Dataform CLIがver3.0未満だとdry-runで検証できるのはDataform内での依存関係やテーブルの有無のみで、 declaration で宣言したデータソースがBigQuery上に存在しない場合などでエラーが起きません。( 最近のリリース で出来るようになったみたいですが、Dataform CLIのver3.0以上はbreaking changeが多いのでまだ試せていません...)現状は、データソースを参照するようなクエリはリリース時に目視チェックすることでカバーしています。 ↩

こんにちは！ ファインディの @Taka-bow です。 まもなく「開発生産性Conference 2024」が開催されます。2日目のキーノートスピーカーであるNicole Forsgren博士は、昨年はビデオ越しのご登壇でしたが、今回は来日してくださる予定です。 昨年は「SPACE：生産性フレームワーク」の研究についてご紹介いただきましたが、今回はどのようなお話を伺えるのでしょうか？ ご講演のタイトルは Mastering Developer Experience: A Roadmap to Success （デベロッパーエクスペリエンスを極める：成功へのロードマップ） とのこと。大変楽しみです。 dev-productivity-con.findy-code.io 博士は、書籍 "Accelerate" *1 の筆頭著者としても広く知られていますが、最近はデベロッパーエクスペリエンス（ DevEx : Dev eloper Ex perience）研究の第一人者としても注目されています。 そこで、そもそもデベロッパーエクスペリエンスとは何か？博士らの論文を引用しながら紐解きたいと思います。 デベロッパーエクスペリエンスの科学的な研究 Nicole Forsgren 博士らがデベロッパーエクスペリエンス（以降、DevEx）に関して発表した論文はいくつかありますが、今回は最近の2つの論文にフォーカスします。 1つ目は、昨年5月 Association for Computing Machinery（ACM）で発表された "DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity" 『DevEx: 何が実際に生産性を向上させるのか： 生産性を測定し改善するための開発者中心のアプローチ』 2つ目は、今年1月に発表された "DevEx in Action: A study of its tangible impacts" 『実践的 DevEx：その具体的な影響に関する研究』 どちらの論文も、DevEx の「質」が、開発生産性に大な影響を与えているという仮説を、科学的に証明しようと試みています。 デベロッパーエクスペリエンスの3次元 DevEx とは、ソフトウェアエンジニア（ここで指す開発者）が日々経験している業務、言い換えれば「エンジニアの業務体験や環境」そのものを指しています。 そして、影響を与える要因を「DevExの3次元」フレームワークと呼びます。 参照: Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53. それぞれ、 Feedback Loops (フィードバックループ) Cognitive Load (認知負荷) Flow State (フロー状態) と言います。これを意識することで DevExの改善ステップがより具体的にできます。 Feedback Loops (フィードバックループ) フィードバックループは、テスラのような自動運転の自動車をイメージすると分かりやすいでしょう。 自動運転車は、前方や左右の障害物、車間距離などを判断するために、センサーやカメラから得られる情報を高速で処理するフィードバックループが必要です。この処理が遅いと、障害物にぶつかってしまう可能性がありますよね。 Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons ソフトウェア開発組織は、デリバリーの遅延を減らしてアウトカムの流れを最適化しようとしています。遅延が減ることで、フィードバックと学習が迅速に行われ、速やかな軌道修正が可能となります。 研究によれば、頻繁なデプロイとリードタイムの短縮がパフォーマンス向上に繋がるとされています。迅速なフィードバックループは、開発者が障害なく作業を進めるのに役立ち、逆に遅いフィードバックループは中断や遅延を引き起こし、開発者のフラストレーションを増します。 フィードバックループを高速にするための改善案として、次の点が挙げられます。 開発ツールの高速化 ：ビルドやテストの時間を短縮。 人の引き継ぎプロセスの改善 ：コードレビューや承認の迅速化。 組織構造の最適化 ：チーム間の相互作用を合理化し、遅延を減らす。 これらの改善により、ソフトウェア開発の効率と生産性を向上させることができます。 Cognitive Load (認知負荷) 2011年に旧Twitterで話題になった案内板がありました。 その案内板がこちら 参照： https://note.openvista.jp/2011/redesigning-shinjuku-building-sign, CC BY-SA 4.0 さて、トイレに行くにはどちらに進めば良いのでしょう？前？右？左？と混乱する人が大勢いたそうです。 （正解は左） 少なくとも、ほとんどの人がぱっと見て分からない状態は「認知負荷が高い」と言えるでしょうね。 余談ですが、この案内板はその後認知科学の分野で研究もされ発表されました。 2016年度 日本認知科学会 第33回大会【矢印を用いた「組み合わされた方向サイン」のわかりやすさ： 構造，アイコン，加齢の効果】： 研究リンク ソフトウェア開発は複雑であり、ツールや技術が増えることで開発者の認知負荷が増加しています。認知負荷とは、タスクを実行するために必要な精神的な処理量を指します。 難しいタスクや新しいフレームワークの理解に取り組む場合、この負荷は特に高まります。また、情報の提示方法や精神的な処理が必要な場合も負荷は増加します。 高い認知負荷は、開発者が顧客に価値を提供する妨げとなります。不十分なドキュメントや複雑なシステムにより、開発者はタスク完了に多くの時間と労力を費やすことになります。 認知負荷を軽減するには、次の改善案が挙げられます。 不要な障害の排除 ：開発プロセスから不必要な障害を取り除く。 整理されたコードとドキュメント ：理解しやすいシステムを構築し、コンテキストやタスクの切り替えを減らす。 専任のDevExおよびプラットフォームチーム ：使いやすいセルフサービスツールを提供し、開発とリリース手順を合理化する。 これにより、開発者の認知負荷を軽減し、効率的に価値を提供できる環境を整えることができます。 Flow State (フロー状態) 弓道における基本的な射法の8つの動作を射法八節（しゃほうはっせつ）と言います。 足踏み（あしぶみ） 胴造り（どうづくり） 弓構え（ゆがまえ） 打起し（うちおこし） 引分け（ひきわけ） 会（かい） 離れ（はなれ） 残心（ざんしん） この中でも、6番目の「会」は、他が具体的な動作にも関わらず、これだけが少し違います。 簡単解説！射法八節 によると、 引分けが完成し、矢を放つ機会を待つのが「会」です。丹田に力を入れ、自然な呼吸を心がけます。肩と肘の高さに注意しましょう。体全体のバランス、重心に気を配り、的をしっかりと見つめます。 実際の動作は5秒ほどキープする必要があるそうですが、これがまさにフロー状態だと思います。周囲の音や考え事などの雑念があれば「会」とはならず、矢は的を外れてしまうでしょう。 Pierre-Yves Beaudouin / Wikimedia Commons 開発者は「フローに入る」や「ゾーンに入る」といった表現を使います。 これは、活動中に集中力と活力を持ち、完全に没頭するフロー状態を指します。この状態を頻繁に経験することは、生産性の向上、イノベーションの促進、従業員の成長に繋がります。研究によれば、仕事を楽しむ開発者はより高いパフォーマンスを発揮し、質の高い製品を生み出します。 フロー状態を妨げる主要な要因は、中断や遅延です。その他にも、自律性の欠如、目標の不明確さ、そして刺激的でないタスクが影響します。 フロー状態を作りやすくするためには 中断の最小化 ：会議をまとめて行い、計画外の作業を避け、支援依頼をまとめて処理する。 自律性の確保 ：開発者に自律性を与え、充実感のある挑戦的なタスクを提供する。 積極的なチーム文化の構築 ：リーダーはフロー状態を重視し、自律性とチャレンジの機会を提供する環境を作る。 これにより、開発者がフロー状態に入りやすくなり、生産性と製品の質を向上させることができます。 DevExの測定 「DevExの3次元」は、測定可能な領域を特定するためのフレームワークを提供します。開発者の認識やワークフローを捉えるだけでなく、全体的なKPI（主要業績指標）や「北極星指標」を含めることが重要です。表1では、包括的なKPI指標と3つの次元に沿った具体的な認識およびワークフロー測定の例を示しています。 表1 フィードバックループ 認知負荷 フロー状態 認識 (人間の態度と意見) - 自動テストの速度と出力に対する満足度 - コードベースの複雑さの認識 - 集中して中断を避ける能力の認識 - ローカル変更を検証するのにかかる時間に対する満足度 - 本番システムのデバッグの容易さ - タスクやプロジェクト目標の明確さに対する満足度 - 本番に変更をデプロイするのにかかる時間に対する満足度 - ドキュメント理解の容易さ - オンコールの際の中断性の認識 ワークフロー (システムとプロセスの行動) - CI結果を生成するのにかかる時間 - 技術的質問に対する回答を得るのにかかる時間 - 会議や中断なしでブロックする時間の数 - コードレビューのターンアラウンドタイム - 変更をデプロイするために必要な手動ステップ - 計画外のタスクやリクエストの頻度 - デプロイリードタイム（変更を本番にリリースするまでの時間） - ドキュメントの改善頻度 - チームの注意を必要とするインシデントの頻度 KPI (北極星指標) - ソフトウェア提供の全体的な容易さの認識 - 従業員のエンゲージメントや満足度 - 認識された生産性 最新の調査結果 DX社によるDevExの横断的調査が行われました。この調査は、DX社の顧客の中から研究調査に協力した219人からの回答を基にしています。アンケートに回答した人のうち、170人（77.6％）がテクノロジーを主な事業とする企業の社員であり、200人（91.3％）が従業員数500人以上の企業（中堅または大企業のしきい値）に勤務していました。 以下に、調査・分析結果の重要なポイントを示します。 フロー状態 深い作業に時間を割く開発者は、生産性が50％向上する。 集中時間を確保し、中断を最小限に抑えることが重要。 魅力的な仕事をしている開発者は、生産性が30％向上する。 タスク配分を再考し、燃え尽き症候群を防ぐことが必要。 認知的負荷 コードの理解度が高い開発者は、生産性が42％向上する。 コードを明確でシンプルにし、十分に文書化することが重要。 直感的で使いやすいツールやプロセスは、革新性を50％向上させる。 フィードバックループ コードレビューのターンアラウンドタイムが早いと、革新性（innovative）が20％向上する。 緊密なフィードバックループは、技術的負債を50％減少させる。 質問に迅速に回答することが、技術的負債を減らす鍵となる。 DevEx 改善のためにはどうやって組織に投資させるか 研究の結果、DevExの改善は個人、チーム、そして組織にとってプラスの結果を生み出すという証拠が明らかになりました。しかし、このデータを見ただけでは、組織が改善に向けて舵を切るとは限りません。 そこで、データドリブンかつ継続的な改善を始めるための5つのステップが提案されています。 現在の開発者体験のデータ収集 開発者の体験を把握するためにデータを収集する。これには、アンケートや専用ツールを使用して現在の課題や改善点を明らかにすることが含まれる。 データに基づいて目標設定 収集したデータを元に、改善すべきポイントを特定し、目標を設定する。ビジネスの優先事項とも照らし合わせる。 チームの成功をサポート 設定した目標を達成するために、チームに必要な支援を提供する。目標を共有し、進捗を定期的に確認する。 進捗を共有し、投資を評価 開発者や関係者に進捗を報告し、投資の効果を評価する。学んだことや驚いた点も共有し、改善策を調整する。 プロセスを繰り返す 再びデータを収集し、プロセスを見直して改善する。3～6ヶ月ごとにこのサイクルを繰り返す。 デベロッパーエクスペリエンス（DevEx）改善の重要性 日本では、デベロッパーエクスペリエンス（DevEx）の改善に関する研究はまだまだこれからだと言われています。しかし、これこそが今後のIT業界の競争力を大きく左右する重要な要素となるでしょう。 日本CTO協会が毎年実施している「開発者体験ブランド力」の調査は、すでに一部の企業にとって重要な指標となっていますが、今後はさらに実際のDevExに基づいたエビデンスデータを活用することが求められます。 例えば、アメリカやヨーロッパのIT企業では、DevExの改善が企業文化の一環として浸透しており、優秀な人材の確保や社員の満足度向上に直結しています。 論文 "DevEx: What Actually Drives Productivity" には実際のeBayとファイザーの実例が載っています これにより、企業のイノベーション能力や市場での競争力が劇的に向上しています。 日本のIT企業もこの潮流に乗り遅れることなく、DevExの重要性を認識し、積極的に改善に取り組む必要があります。 具体的な取り組みとしては、開発ツールやプロセスの改善、継続的なフィードバックループの確立、エンジニアの教育とスキルアップの支援などが挙げられます。これらの施策を通じて、開発者がストレスなく効率的に仕事を進められる環境を整えることができます。また、データに基づいた評価と改善を繰り返すことで、より具体的で効果的なDevExの向上が期待できます。 またチーム・トポロジーのイネーブリングチームとしてDevExチームを立ち上げてもよいかもしれません。 実際のDevExデータが調査されるようになれば、日本のエンジニアのDevExへの投資が見直されるかもしれません。 DevExの継続的改善サイクルが回り、結果として、企業全体の生産性や創造性も高まり、ひいては日本のIT業界全体の競争力が強化されるはずです。 経営者やマネジャーの皆様が率先してDevEx改善に取り組み、次世代のIT産業をリードする企業としての地位を確立するチャンスだと私は思います。 *1 : Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations"（邦題「LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する」）

こんにちは！ファインディでFindy Team+開発チームのEMをしている 浜田 です。 昨今、開発生産性を高めるための取り組みを行っている組織が増えてきていると感じています。 開発生産性を向上させるためには、まずは定量的に可視化することが重要です。 可視化することで現状を把握して、開発組織の伸びしろを発見したり、課題を明らかにし、改善活動に取り組みやすくなります。 一方、定量的な指標に焦点を当てすぎてしまい本質的ではない対応をしてしまい、指標は向上したものの実際の生産性は向上していなかったり、むしろ悪化してしまうこともあります。 この記事では、開発生産性指標を向上させるためにやってはいけないアンチパターンについて紹介します。 デプロイ頻度を向上させるために、デプロイプロセスは変更せずに実施回数を増やした デプロイ頻度は DORA が提唱するDevOpsの4つの指標(Four Keys)の1つであり、開発生産性の高い開発組織はこの数値が高いとされています。 そのため、開発生産性を向上させようと考えたときに最初に取り組むことが多い指標です。 デプロイ頻度はただ向上させるだけであれば簡単に向上させることができます。 現状のデプロイプロセスのまま実施回数を増やせば良いのです。 デプロイする回数を増やすだけでデプロイ頻度が向上して開発生産性が向上することもありますが、ほとんどの場合はデプロイ頻度だけが向上するだけで開発生産性は向上しません。 高いデプロイ頻度は、CI/CDが自動化されていたり、小さなパッチ単位でコードベースに変更を入れることができていたり、テスト自動化により変更のリスクが低減されているなど、様々なプラクティスが実践できている結果として得られるものです。 これらの前提を満たさないままデプロイ頻度を向上させることは、変更障害率が上がって障害対応する時間が増加したり、デプロイをすること自体の手間で開発する時間が減ってしまうなど開発生産性を悪化させる可能性があります。 無理やりデプロイ頻度だけを増やすのではなく、前述したプラクティスを実践するとことで、無理なくデプロイ頻度を向上させていきましょう。 リードタイムを短縮するために、全て実装し終わってからコミットする 開発生産性を可視化する際、リードタイムを指標として設定することは有効です。 なお、リードタイムには様々な定義がありますが、今回はGit/GitHubを活用し、コミットしてからメインブランチにマージされるまでの時間をリードタイムと定義します。 上記のリードタイムの定義には欠点があります。Gitの仕組み上ブランチを切った時間が記録されないため、開発に着手してからファーストコミットまでの時間が入っていません。 そこを逆手にとって、リードタイムを短縮するために全て実装し終わってからコミットするというアンチパターンが生まれます。 ただ、このようなことをしても数値だけが短縮されるだけで開発に使っている時間は変わりません。 それどころか、コミットを適切な粒度で行わないことで、コミットログが見づらくなったり、少し前の状態に戻したりすることが困難になります。 本来やりたいことは正しい指標を取得して伸びしろを見つけて本質的な改善に繋げることです。 このような数値ハックは、ただ無意味なだけではなく、コード管理の履歴が活用しづらくなったり、正しく数値を可視化していたら気づけるはずだった課題を見逃してしまう可能性もあるためやめましょう。 リードタイムを短縮するために、必要以上に細かいプルリクエストを作成する リードタイムを短くするプラクティスとして、1つ1つの変更を小さくすることがあります。 1つ1つの変更が小さいことで、実装の時間が短くなり、影響範囲が小さいためテストも容易になり、リードタイムが向上します。 変更サイズが小さいことを可視化するためには、プルリクエスト数を指標とすることがおすすめです。 変更サイズが小さい→さくさくプルリクエストがマージできる→プルリクエスト数が増加。というロジックです。 ただ、プルリクエスト数を指標とした場合、必要以上に細かいプルリクエストを作成するアンチパターンが生まれます。 例えば一括変換でできた機械的な修正であれば、それが複数ファイルに渡っていたとしても1プルリクエストにまとめるべきです。 これをファイルごとにプルリクエストを分割した場合、プルリクエスト数は増加しますが、分割の手間やレビュアーの負荷が増加することで開発生産性は悪化します。 プルリクエスト数はあくまで適切な粒度に分割できていることを確認するための指標なので、数だけを追い求めないようにしましょう。 プルリクエストの粒度については別の記事で詳しく紹介していますので、ぜひご覧ください。 tech.findy.co.jp レビュープロセスに時間がかかるので、コードレビューを省略してマージする リードタイムに着目した際、コードレビューに時間がかかっていることが課題として浮かび上がることがあります。 この課題を正攻法で解決する場合、コードレビューに時間がかかっている理由を分析して、課題を解消する必要があります。 以下によくある課題と解決例を挙げます レビュアーが特定の人物に集中しているのでレビュアーを増やして分散する プルリクエストのサイズが大きいことでレビューに時間がかかるので、プルリクエストのサイズを小さくする インデントや書き方の指摘が多いので、リンターやフォーマッタを導入して機械的に検知できる指摘は自動化する 指摘が多くなりやり取りに時間がかかっているので、ペアプロ/モブプロを導入する 一方でレビューにかかっている時間を最も簡単に削減する方法はコードレビューを省略することです。 ただし、コードレビューを省略することはお勧めできません。 コードレビューをすることでバグの発見やコード品質の向上につながったり、コードの内容を実装者とレビュアーで共有することでコードの属人化を軽減できたり、レビュアーの目を通すことで第三者が読みやすいコードになり保守性が向上します。 コードレビューはとても有意義な活動なので、省略せずに根本解決することで有意義にレビューしつつリードタイムを向上させましょう。 プルリクエストのサイズを小さくするためにテストコードを別のプルリクエストにする 意味のある最小単位でプルリクエストを作成して、小さい単位でサクサクマージしていくことは開発生産性を向上させるための有効なプラクティスです。 プルリクエストを小さくする際、テストコードを別のプルリクエストに分けたくなることがあります。 1つ目のプルリクエストでテストコードなしのコードのみ実装して、2つ目のプルリクエストでそのテストコードを書くという方法です。 この方法はプルリクエストのサイズを小さくできますが、一時的とはいえテストコードで守られていないコードがメインブランチに混入することになります。 テストで守られていないコードは何かしらの変更で不具合が混入しても気づくことができないため、品質低下につながります。 また、すぐにテストコードが追加されれば良いですが、別にすることでテストコードの実装を忘れてしまう可能性も高まります。 コードと対応するテストコードは1つのプルリクエストに含め、テストコードで守られていないコードがメインブランチに混入しないようにしましょう。 変更障害率を下げるために、デプロイ頻度を下げる 変更障害率はDORAが提唱するDevOpsの4つの指標(Four Keys)の1つであり、デプロイを起因とした本番障害の発生確率を指しています。 また、開発生産性に関係なく、変更障害率は関係者全員が低く保ちたいと願っているのではないでしょうか。 本番障害が発生する最大の原因はデプロイで不具合を混入させてしまうことです。 そのため、デプロイすることに慎重になり、デプロイ頻度が低下してしまうことがあります。 しかし、変更障害率を下げるためにデプロイ頻度を下げることはアンチパターンです。 デプロイ頻度を下げて、1回のデプロイに含まれる変更量が増えることで次の問題が発生します。 変更内容が複雑になり、相互作用や予期せぬ結果が発生する可能性が高くなり、本番障害が発生するリスクが高まる テスト範囲が広くなるため、テスト漏れが発生する可能性が高くなり、本番障害が発生するリスクが高まる 障害が発生した際、原因特定に時間がかかり、平均修復時間が増加する 影響範囲が大きくなるため、障害の影響範囲が広くなる可能性が高まる 変更障害率を下げるためのプラクティスは、デプロイ1回あたりの変更量を小さくすることです。 変更量が小さいことで、変更範囲を正確に把握できるので、テストが容易になってテストのリードタイムを短縮できたり、テスト精度が向上することで品質が向上します。 また、頻繁にデプロイするためには自動テストを充実させることも重要です。自動テストが充実していることで既存機能が壊れていないことを自動的に確認できるためリードタイムの向上や品質の向上につながります。 デプロイを過度に恐れず、デプロイあたりの変更量を小さくしたり、自動テストを充実させるなど開発生産性を向上させるプラクティスを取り入れることで変更障害率を下げましょう。 変更障害率を下げるために、hotfixでの対応を出し惜しみする 変更障害率を可視化するために、hotfixの数から算出することがあります。 前述した通り、変更障害率は誰もが低く保ちたい指標です。 そのため、本来はhotfixで即対応した方がベストだとわかっている場合でも、通常フローで対応してしまうことがあります。 hotfixを使わないことで、変更障害にカウントされないので結果として変更障害率は下がるかもしれません。 ただし、hotfixを使わなかったからといって発生した障害がなるなるわけではありません。 また、本来は変更障害率に計上されるべきものを計上しないことで、振り返りなどで課題に気づきづらくなり、自分たちの成長機会を妨げる可能性があります。 開発生産性の可視化を自分たちの成長機会に繋げるためにも、数値を良くすることばかりに注目するのではなく、正しく取るように心がけましょう。 まとめ ここまでで紹介したアンチパターンは開発生産性の数値を高めるための組織の能力に注目せずに、数値を向上させることだけを目標に設定してしまったために発生しているものが多いです。 このことは「グッドハートの法則」として広く知られています。 以下、ChatGPTによる説明です。 グッドハートの法則（Goodhart’s Law）は、経済学者チャールズ・グッドハートが提唱した概念で、「特定の統計的指標が政策目標として使われると、その指標はもはや信頼できるものではなくなる」という法則です。 つまり、ある指標が目標となると、人々はその指標を達成するための行動を取り始めるため、指標自体の本来の意味や有用性が失われるということです。 定量的な目標を設定することは開発生産性の現在地を把握するためには有効ですが、目標を達成するために本来備えておくべき能力を理解せずに数値だけを追い求めないようにしましょう。 なお、開発生産性の高い組織を目指すために備えるべき能力は、Google Cloudの DevOpsの能力 がとても参考になります。 また、DORA Core Modelにも開発組織のケイパビリティと開発生産性指標との関係が示されていますので、ぜひ参考にしてみてください。 出典: DORA’s Research Program 6月28日（金）・29日（土）に『LeanとDevOpsの科学』の著者であるNicole Forsgrenの来日、テスラ共同創業者元CTOの登壇など、国内外の開発生産性に関する最新の知見が集まるConferenceを開催します。 開発生産性に関する他の企業の取り組みや海外の事例に興味がある方は、ぜひお申し込みください！ dev-productivity-con.findy-code.io

こんにちは。 FindyでMLエンジニアをしているyusukeshimpo( @WebY76755963 )です。 今回はLLM Embeddingを活用した自動応答Botを開発&導入し、社内の問い合わせ業務を効率化することができたので、その取り組みを紹介します。 Botを開発することになった背景 弊社ではSlackを使用し、自社サービスに関する社内質問に回答するチャンネルを運用しています。 主にビジネスサイドからの技術的な疑問にエンジニアが答える仕組みです。 質問はテンプレートを使って送信され、エンジニアが回答しますが、このワークフローには次のような問題が発生しています。 同じ質問が異なる人から届いてしまう 質問の度にエンジニアの工数が発生してしまう 半期で70件以上の質問が発生し、1件につき1~1.5時間かかることもあります。 多くの質問は社内ドキュメントで解決可能ですが、検索がしづらく利用されていません。 質問に関連するドキュメントを渡すことで、エンジニアに質問する前に自己解決を促すことができます。 これがBot導入の背景です。 Bot導入のためのアプローチ Botの要件について Botを導入する理由は、質問対応でエンジニアの労力を減らすことです。 しかし、Kibela（社内の情報共有ツール）のQ＆A集やSlackの問い合わせ履歴などの社内ドキュメントは全て構造化されておらず、検索性に乏しいという課題があります。 また、Botが全てを解決するのは難しく、ハルシネーション（AIが実際には存在しない情報を生成する現象）の問題もあります。 これらを踏まえ、クイックに実装できる要件を考えました そこでBotの機能としては、 質問の内容に関連しそうな社内ドキュメントへのリンクを送る 上記で解決できたかを質問者にフィードバックしてもらう 解決できない場合はあらためてエンジニアへ質問を投げる というものにしました。 Botの構成 上記の要件を踏まえて、Botの仕組みは次のようにしました。 ① データの取得 ② データの構造化 ③ 類似度計算とBotの回答 ④ 質問者からのフィードバック 以下に、各処理について簡単に説明します。 ①データの取得 最初にデータの取得をKibelaとSlackからAPIを使って行います。 過去きた質問と同じ質問に回答できることや社内の基本的なドキュメントで解決することを考えて、KibelaとSlackチャンネルのメッセージ履歴をBotで使用するデータにしました。 ②データの構造化 今回の開発で最も重要なことの一つに、テキストデータの構造化処理があります。 フォーマットが異なる、または整備されていないテキストを扱うため、地道な作業で対応しました。 以下に、非構造の社内ドキュメントを構造化するプロセスを図示しています。 このプロセスを経て、最終的にKibelaとSlackから次の情報を持った構造化データを作成します。 ドキュメントタイプ(Kibela or Slack) テキスト ドキュメントのURL テキストのEmbedding(質問との類似度計算用) このように構造化することで、質問内容に合わせた関連ドキュメントを検索することができるようになります。 テキストデータ処理後、コサイン類似度計算のためにOpenAIのtext-embeddingを使用しました。 作成した構造化データはBot内で保持します。 ③類似度計算とBotの回答 質問者からのインプットである質問文をEmbeddingしたものと、構造化データ内のEmbeddingデータとのコサイン類似度を計算し、類似したドキュメントのリンクを渡せるようにします。 Botの返信内容として、質問と類似度の高いドキュメントのURLを採用します。 ④質問者からのフィードバック 最後に、質問者が想定している回答を、Botが応答できているかどうか確認するプロセスを設けました。 ここでは、望んでいた応答が得られたかどうかをフィードバックしてもらい、フィードバック別にその後のフローを分けています。 フィードバック後のフローについてはこの後の工夫した点のところで、詳細を説明します。 Bot導入時の工夫 Botの導入の際に工夫した点が以下2点あるので、それについても紹介をさせてください。 ワークフローの変更 データの準備 ワークフローの変更（フィードバックプロセスの追加） ハルシネーション問題に対応する為、Botはテキストで返答するのではなく類似度のリンクを返信するようにしています。 これにより、質問者がリンク先のドキュメントを参考に自己解決を促すようにしました。 しかし、Botが提案したドキュメントで解決しきれない場合があった為、既存のワークフローを「 自己解決できなかった場合に 、エンジニアへ質問として受け付けられる」よう工夫しました。 上記工夫を取り入れた変更後のワークフローを以下図のように変更しました。 このように、質問者がBotの応答で自己解決できるかをチェックし、解決できない場合に「いいえ」を選択するとエンジニアへ質問が飛ぶ仕組みとしています。 Slack APIによるフィードバックの作成方法 回答が役に立ったかどうかのフィードバックを作成する際に、Slack APIによる以下実装の要領で、質問者に手軽に回答してもらえるボタンを用意する事ができました。 @ app.action ( "feedback_yes" ) def handle_feedback_yes (ack, body, say): ack() thread_ts = body[ "message" ][ "ts" ] say( "あなたは「はい」を押しました \n フィードバックをありがとうございます！他にお問い合わせがある場合はフォームからお願いいたします。" , thread_ts=thread_ts) @ app.action ( "feedback_no" ) def handle_feedback_no (ack, body, say): ack() thread_ts = body[ "message" ][ "ts" ] user_group_id = "hoge" # SlackグループID（メンション先） say(f "あなたは「いいえ」を押しました \n <!subteam^{user_group_id}> \n 上記のお問い合わせが来ているのでご対応お願いいたします！" , thread_ts=thread_ts) このように、フィードバックステップを簡易に組み込む事ができたおかげで、Botでどのくらい自己解決を促す事ができたかどうかを後述のように可視化できました。 導入時点で組み込んでおいた事で、評価用プロセスの追加実装や別で実装する等の手間を省く事もできました。 データの準備 先述の通り、今回の仕組みによるBotを実装するにあたり、応答精度を高めるには様々な形式で保存されているテキストデータの クリーニングや加工 は重要なポイントの1つでした。 これまで、Botを構築し社内ドキュメントを検索するような用途で参照する事を想定していなかった為に、今回の用途に合わせてデータを丁寧に加工する事で、応答精度を高める事ができました。 今回紹介した仕組みで自動応答Botのデータとして応用する事を検討する場合は、ドキュメントが構造化されやすく整理されているかが意識されていると実装コストが削減できるようになると感じました。 例えば、Kibelaのような自由記述のテキストであれば、テンプレートを用意する等して形式を統一すると前処理が楽になります。 社内ドキュメントの整備には手間がかかるため敬遠されがちですが、このような用途に利用できることがわかれば、社内ドキュメントの整備に時間を割きやすくなるように思います。　　 Bot導入の結果 社内の問い合わせオペレーションを改善できた 実際にBotを導入してみて工数の削減ができたのかを集計してみました。 導入後2ヶ月で、お問い合わせ対応にかかる所要時間を 1/3減少 する事に貢献している事がわかりました。 オペレーションの改善になったポイント このように効率化できたポイントは、 問い合わせ対応のワークフローを改善できた ことです。 今まではどんな質問でも問い合わせとして送信していたものを、Botによる自己解決を促すプロセスを組み込んだワークフローにできた事で、 本来であれば自己解決する事ができた質問を炙り出す事ができるようになったから だと振り返っています。 Botを単純に導入するだけでなく、今回の評価プロセスのように「どんな課題に対してどのようにBotを組み込み効率的な仕組みを作るか」を意識することが大切です。 Botの精度は今後社内ドキュメントを充実させることで改善をしていきますが、質問への対応時間削減は実現できたので導入した甲斐はありました。 Botで社内向けの問い合わせ対応の効率化をしたいという方はぜひ参考にしていただければと思います！ 最後に 以上が社内お問い合わせの自動化Botの開発についてでした。 参考にしていただければ幸いです。 また、弊社では機械学習エンジニア・データエンジニアなど一緒に働いてくれるメンバーを募集しております。 興味がある方は↓からご応募してしていただければと思います。 herp.careers

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 弊社では本番環境へのデプロイを1日に複数回実行していますが、本番環境での不具合の発生率は低いです。 次の画像は弊社のあるプロダクトの直近1年のFour Keysの数値です。 平均で1日2.3回の本番デプロイを行っていますが、変更障害率は0.4%程度を維持しています。単純計算ですが、1年で障害が2件程度の水準です。 また、平均修復時間は0.3hとなっており、障害が発生しても20分以内には復旧できていることがわかります。 この数値を維持できている理由の1つにテストコードの品質があると考えています。 システムで発生する不具合を自動テストが検知することで本番環境への不具合の混入を事前に防ぐことができ、仮に不具合が発生したとしても修正内容が他の箇所に影響が出ないことをテストコードが保証してくれるため迅速に修正できるからです。 弊社ではテストカバレッジよりも、テストで何を守るのか？という観点を重視しています。その上でテストカバレッジの90％超えは珍しいことではありません。 しかし、実際にはカバレッジを意識したことはなく、システムを守るテストを意識した結果、勝手にカバレッジが上がっていただけなのです。 我々としては「全てのテストコードが通る」ことよりも、「コケるべき時にコケるテストコード」の方が重要だと定義しています。 この記事では、弊社で実践している「テストを通すためのテストコード」ではなく、「システムを守るテストコード」の書き方をいくつか紹介していきます。 それでは見ていきましょう！ 実例紹介 関数の実行状態のチェック 出力対象外のチェック チェックする値の厳密化 まとめ 実例紹介 関数の実行状態のチェック 特定の処理を実行したあとに、結果に応じてコールバック関数を実行するようなケースは少なくありません。 コンポーネントに関数を渡し、ボタンをクリックした時にその関数を実行するようなケースもあるでしょう。 このようなケースの場合、関数を特定の処理で実行する際に、その関数が適切に扱われているのかを守るテストケースが必要になります。 例えば正常系の次のようなテストコードがあるとします。 const mockOnSuccessCallback = jest.fn(); const mockOnErrorCallback = jest.fn(); const { result } = renderHook(() => useHoge( { onSuccessCallback : mockOnSuccessCallback, onErrorCallback : mockOnErrorCallback } )); act(() => { result. current .handleSubmit(); } ); expect (mockOnSuccessCallback).toHaveBeenCalledWith( 'test' ); hooksの関数を実行し、成功時に引数で渡したコールバック関数がパラメータ付きで実行されることを確認しています。 一見何の変哲もないテストコードですが、このテストコードには次の視点が抜けており、システムを守るテストとしては不十分です。 成功時の関数が複数回実行されたとしても通ってしまう エラー時のコールバック関数が実行されたとしても通ってしまう こういったケースでは、弊社では次のようなテストコードが推奨されます。 const mockOnSuccessCallback = jest.fn(); const mockOnErrorCallback = jest.fn(); const { result } = renderHook(() => useHoge( { onSuccessCallback : mockOnSuccessCallback, onErrorCallback : mockOnErrorCallback } )); act(() => { result. current .handleSubmit(); } ); expect (mockOnSuccessCallback).toHaveBeenCalledTimes( 1 ); expect (mockOnSuccessCallback).toHaveBeenCalledWith( 'test' ); expect (mockOnErrorCallback).not.toHaveBeenCalled(); このテストコードにより、「成功時に1回だけコールバック関数がパラメータ付きで実行され、エラーのコールバック関数が実行されない」ことを守ることができます。 この2つのテストコードのカバレッジは変わりませんが、システムを守ることができる内容が変更前よりも増えており、アプリケーションの振る舞いをより厳密に守ることができるようになりました。 出力対象外のチェック 特定の情報のみを返す処理がある場合、その情報が正しく取得できることを確認するテストケースが必要になります。 特定のユーザー情報を取得し、そのユーザーに紐付く各種情報を取得する処理はよくあるケースです。 このようなケースの場合、特定の情報のみを取得できることを守るテストケースが必要になります。 例えば次のようなテストコードがあるとします。 RSpec .describe User do describe ' .skills ' do let!( :user ) { create( :user ) } let!( :user_skills ) { create_list( :user_skill , 3 , user :) } it ' returns user skills ' do expect(user.skills).to eq(user_skills) end end end 特定のユーザーデータに紐付くスキルデータを取得することを確認しています。 一見何の変哲もないテストコードですが、このテストコードには次の視点が抜けており、守るテストとしては不十分です。 他のユーザーのスキルデータが混在してしまう可能性を否定できていない 対象のユーザーがスキルデータを持っていない場合の挙動を確認できていない 特に他のユーザーのスキルデータが混在してしまうケースが発生してしまった場合、最悪の場合インシデントにもなりかねません。 こういったケースでは、弊社では次のようなテストコードが推奨されます。 RSpec .describe User do describe ' .skills ' do let!( :user ) { create( :user ) } before do # NOTE : 他ユーザーのレコードが対象外になることを守る create_list( :user_skill , 3 , user : create( :user )) end context ' when user has skill ' do let!( :user_skills ) { create_list( :user_skill , 3 , user :) } it ' returns user skills ' do expect(user.skills).to eq(user_skills) end end context ' when user not has skill ' do it ' returns empty array ' do expect(user.skills).to eq([]) end end end end このテストコードにより、「他のユーザーのスキルデータが混在してしまう可能性を否定」し、「対象のユーザーがスキルデータを持っていない場合でも正常に処理を実行できる」ことを守ることができるようになりました。 対象のレコードをチェックすることだけではなく、対象外のレコードが本当に対象外になっているのかどうか、レコードが存在しなかった場合にエラーが起きないかどうかまで確認することで、アプリケーションの振る舞いをより厳密に守ることができるようになりました。 チェックする値の厳密化 特定の値を返す関数がある場合、実行時に期待する値が返ってくることを確認するテストケースが必要になります。 例えば次のようなテストコードがあるとします。 RSpec .describe User do describe ' .has_multi_skills ' do let!( :user ) { create( :user ) } before do # NOTE : 他ユーザーのレコードが対象外になることを守る create_list( :user_skill , 3 , user : create( :user )) end context ' when user has multi skills ' do before { create_list( :user_skill , 3 , user :) } it ' returns true ' do expect(user.has_multi_skills).to be_truthy end end context ' when user has skill ' do before { create( :user_skill , user :) } it ' returns false ' do expect(user.has_multi_skills).to be_falsy end end context ' when user not has skill ' do it ' returns false ' do expect(user.has_multi_skills).to be_falsy end end end end 対象のユーザーが複数のスキルデータを持っている場合にtrueを、それ以外の場合にはfalseが返ってくることを確認しています。 パッと見で特に問題は無さそうですが、 be_truthy be_falsy の仕様には注意が必要です。 it { expect( true ).to be_truthy } # passes it { expect( " hoge " ).to be_truthy } # passes it { expect( nil ).to be_truthy } # fails it { expect( false ).to be_truthy } # fails it { expect( false ).to be_falsy } # passes it { expect( nil ).to be_falsy } # passes it { expect( " hoge " ).to be_falsy} # fails it { expect( true ).to be_falsy } # fails be_truthy be_falsy はbooleanの値以外でも実行結果が変わります。 そのため、例えば関数が返す値がbooleanではなく文字列になってしまった場合にテストが通ってしまう可能性があります。 何かしらの値が入っていることを確認するテストケースであれば問題ありませんが、今回のケースではbooleanの値を厳密にチェックすることが要求されます。 こういったケースでは、弊社では次のようなテストコードが推奨されます。 RSpec .describe User do describe ' .has_multi_skills ' do let!( :user ) { create( :user ) } before do # NOTE : 他ユーザーのレコードが対象外になることを守る create_list( :user_skill , 3 , user : create( :user )) end context ' when user has multi skills ' do before { create_list( :user_skill , 3 , user :) } it ' returns true ' do expect(user.has_multi_skills).to be true end end context ' when user has skill ' do before { create( :user_skill , user :) } it ' returns false ' do expect(user.has_multi_skills).to be false end end context ' when user not has skill ' do it ' returns false ' do expect(user.has_multi_skills).to be false end end end end このテストコードにより、関数が返す値をbooleanの値で厳密にチェックすることが可能になり、関数の実装が壊れてしまった場合にテストがコケて教えてくれるようになります。 テストライブラリのマッチャーは便利で多用しがちですが、それらの仕様を理解し適切に利用することが重要です。 まとめ いかがでしたでしょうか？ テストコードは全て通ると安心しますが、本質はそこではなくコケるべき時にコケてくれるテストコードを書くことが重要です。 今回挙げた例はほんの一例です。弊社ではこの様にシステムを守るテストを重視しており、既存コードへの修正を行ったとしてもほとんどのケースをテストコードでカバーすることが出来ています。そのため安心して機能追加、リファクタリングなどを行うことができます。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは、ファインディのEND（ @aiandrox ）です！ 2024年4月30日より、ファインディは新オフィスに移転しました。 findy.co.jp 新オフィスのここがすごい！ 大崎駅から直結徒歩5分！雨に濡れずに出社できる！ 前オフィスの2.3倍の広さ！ オフラインイベントが開催できるイベントスペースが増えました！ この記事では、そんな新オフィスについて、エンジニア目線で紹介します（2024年5月時点）。 執務室について ソファ席・ハイテーブル パントリー イベントスペースについて 社内イベントの様子 オフラインイベントの様子 おわりに 執務室について 執務室は前オフィスと同じようにシンプルな作りです。1フロアで、大体徒歩5分あれば1周できるくらいの広さです。 最大500席入る広さですが、現在は出社メンバーが200人程度なので空席が多いです。毎月ガンガン新しい方にジョインしていただいているので、今後どんどん埋まっていく想定です！ この辺りはまだ空席です エンジニアの島はCエリアのサンパウロのあたりに位置しています。サインの名前はクラウドサービスのリージョンになっているので、なんとなく身近な感じ。 また、前のオフィスのときからそうでしたが、エンジニアの席には4Kモニターとエルゴヒューマンが完備なので、開発環境も◎。 さらに、新オフィスでは全席に有線LANが用意されるようになったので、回線速度もUPしました。最大1GBくらい出ます。 ソファ席・ハイテーブル 新しく入社したメンバーはチームメンバーと1on1をするオンボーディングがあるのですが、そのときにはソファ席を使うことが多いです。テイクアウトのランチのときにも大活躍です。 また、オフラインで設計の相談などをするときにはハイテーブルやスタンディングデスクを使うことが多いです。この席は予約がいらないので、ちょっとした相談やざっくばらんに話したいときに役に立ちます。 Flexispotの電動昇降なので、高さもらくらく調整できて使いやすいです！ パントリー ファインディのバリューの1つに「スピード」があります。そのためにも、1人あたりの生産性を高めるために業務用の電子レンジがあります。お弁当を食べるときも他の人を待つことがありません（自分は普段外食しているためあまり使っていませんが……）。 なんと最大1900Wの電子レンジ イベントスペースについて 最大の目玉がこれ！ 今までファインディでは数多くのオフラインイベントをしていましたが、イベントスペースを借りる必要がありました。新オフィスではイベントスペースが新設されたので、出社時にはイベントにふらっと遊びに行くこともできます。 とても広い！ こちらは最大100名収容できるようになっています。 また、イベントスペースには、エンジニア心がくすぐられるマークがたくさんあります。 入口からはsshで入ります メインスクリーンは普段はこんな感じ。よく見ると……？ こちらの扉の向こう側は執務室となっています 他にも、エンジニア心のくすぐられるサインがたくさんあるので、ぜひイベントスペースに遊びに来てご確認ください！ 社内イベントの様子 イベントスペースは予約していれば自由に使えます。 私は社内のボードゲーム会によく参加しているのですが、前のオフィスでは増えていく執務テーブルに圧迫されて活動休止していました。新オフィスでイベントスペースができたので、お昼に社内のメンバーでボドゲ会をやりました。 コトバーテル いかだの5人 また、社内限定の移転イベントの様子は以下から見ることができます！ note.com これだけ集まるとさすがに圧巻です オフラインイベントの様子 5月28日に開催されたオフラインイベント「 After RubyKaigi 2024〜メドピア、ZOZO、Findy〜 」の様子です。 配信ブースもあるので、オンライン/オフラインのハイブリット開催も可能です！このときのイベントもハイブリット開催でした。 配信ブースの機材 オンラインの配信画面 今後も、社内・社外問わずいろんなコミュニケーションのできるスペースとして使っていきます🙌 おわりに 新オフィス移転後も、ファインディはどんどんメンバーを増やしてさらなる成長をし続けます！ 現在、ファインディでは一緒に働くメンバーを募集中です。興味がある方はこちらからどうぞ！ herp.careers

こんにちは。 今年の4月より Findy Tools の開発をしている林です! この記事は 自慢の作業環境を大公開シリーズ の第4弾になります。 今回は3名のエンジニアの作業環境を紹介します！ 作業環境を大公開 林 私はオフィスへの出社と在宅のハイブリッドで勤務しており、自宅にも快適な作業環境を備えています。 デスク周りの全体像はこのようになっており、シンプルで機能性を重視した構成にしています。 ポイントは昇降デスクと34インチのウルトラワイドモニターです。 昇降デスクは FlexiSpotのEF1 を使っています。1日中座っていると体が凝るのと、疲れた時に気分転換で立ち作業をできて必要不可欠なものになっています。 ディスプレイは LGの34WN780-B を使っています。横に広いことでコードやウィンドウを3つくらい並べることが出来て作業が捗ります。また、ディスプレイアームが付属しており角度や位置を調整しやすいです。 さらに、14型のMacbook ProをノートPCスタンドに載せることでディスプレイの高さを揃えられて、Webカメラの位置もちょうど良くなるのが気に入ってます。 他にはメモや紙をつかって思考整理するためのノートとペン、iPadやKindle Paperwhite、私用のMacbook Airを横に置いてあります。 入力機器はメリハリがつくことや気分転換のため私用と社用で分けており、上段のが個人利用、下段が社用です。 私用は Keychron K1 のタクタイルスイッチと LogicoolのトラックボールERGO M575 を使っています。業務でもFigmaで図を書くときなどは、たまにトラックボールを使うこともあります。 社用は LOFREE Flow84 というリニアスイッチのキーボードとAppleのMagic Trackpadを使っています。元々、Keychron K1というキーボードだけを使っていましたが、リニアスイッチのキーボードも試してみたくFlow 84を今年になってから購入しました。打鍵感がスムーズでタイプ音も心地よく気に入っています。 昇降デスクが動く際、ケーブルに余裕を持たせておく必要があるので、天板にケーブルトレーを設置し、垂れるケーブルを最小限にしています。また、電源タップやUSB-Cのドッキングステーションを設置し、ここにケーブル類を集約することで、デスク上のケーブルがほとんど見えなくなりスッキリします。 以上、林の作業環境でした。 開 Findyでデータエンジニアやってる開です。 僕もハイブリットで働いているため最低限デスク周りは整えています。 デスクは FlexiSpot なんですが、手動で回すタイプのものです。 回す作業がちょっとした運動になるので気に入っています。 椅子は COFO Chair Premium を使っています。 ディスプレイは2枚を左右からアームで持ち上げて使っています。 1枚は新卒の頃から使っているものなので新しくしたく、4Kディスプレイを買うために家庭内稟議中です。 デスク上はこんな感じ。 キーボードは茶軸の MISTEL BAROCCO MD770 で、マウスは Logicool ERGO M575S ワイヤレストラックボール を使っています。 ハイブリットなので出社した際もなるべく同じ環境で働きたくキーボードとマウスは同じものを会社にも置いてます。 前はReal Forceが好きだったのですが、整体の先生に進められて2,3年前から分離キーボードを使うようにしています。 また WAVLINK のドッキングステーションを使っており電源や周辺機器への接続をこれ1つにまとめています。 仕事ではMacBook Pro 14インチを使っててクラムシェルで置いてます。 左上にはFine-day（Findyの全社総会）で頂いたPC拭きの上にイヤホンやドラゴンボール（三星球）を置いています。 いつか他の6つが見つかったときのために大切に保管しています。 デスク下はプライベートで使っているデスクトップPCを置いています。 GPU（RTX 4090）積んでるのでデータコンペに参加したりローカルLLMを動かしたりして遊んでます。 また引き出しやコードを収納するためのトレー、バックとヘッドホンを掛けるためのフックを用意して物を収納できるようにしています。 マイクには FIFNE K670 を使っています。 個人でポッドキャストやっているので吐息が入らないように風防はスポンジとポップガードの2重でやっています。 アームによって持ち上げることでタイピングした際の振動がマイクに伝わりづらくしています。 以上、開のデスク紹介でした！ 古田 前のお二人の記事を見て昇降デスクが欲しくなった古田です。 Findy Team+ でプロダクト開発を担当しています。 自分も出社と在宅のハイブリッドで働いていますが、一時期リモート中心だった時期に椎間板ヘルニアを患い、それ以来作業環境では「健康」に気を遣っています。 そんな作業環境がざっと次のようなかんじです。 モニタに関しては以前は大きめのデスクにトリプルディスプレイで配置をしていたんですがヘルニアになってからは首の可動域をあまり増やしたくないので、ノートPCの上部にモニタを配置してそれに併せてデスクも約90cmほどのコンパクトな物にしました。 キーボードは BAROCCO MD600 Alpha BT RGB という分割キーボードを使用しています。 分割キーボードを使うまでは整体に行くと「肩の筋肉ガチガチに固まってますね...」と言われるくらいに肩が凝り固まっていましたが、分割キーボードを使うようになってから肩周りは大分ラクになってきました。 現状の分割キーボードでも充分に満足なのですが、社内のエンジニアの中には分割キーボードにして右側キーボードの端にトラックボールを配置する自作キーボードとかを作っているメンバーも居たりしていつか理想の自作キーボードを作ってみたいと憧れる今日このごろです。 カーソル移動には Magic Trackpad を使用しています。 トラックパッドの配置場所は最初、収まりの良さから分割キーボードで挟んで置いていましたが、どうしてもトラックパッドを触る腕の肩が内巻きになりがちでした。 なので現在は分割キーボードの外側に配置しています。 作業環境なのか？と質問されたら回答に困りますが、作業時は常に着用しているということでアクティビティトラッカーの vívosmart 5 も紹介します。 アクティビティートラッカーなので用途としては色々あるのですが、作業をする上で一番ありがたいのがMoveアラートという一定時間身体を動かしていないとアラート通知をしてくれる機能です。 このアラート通知が来たら立ち上がってちょっとウォーキングをしたり、ストレッチをしたりして身体をほぐしています。 ストレッチの際は ハンドルチューブ などを使って胸を大きく開くようなストレッチをすると首や肩周りの凝りが軽減されます。 また座席には BackJoyのサポートクッション を必ず敷いて作業しています。これがあるかないかでは長時間作業した後の腰回りの疲労感が大分違ってきます。 以上、作業環境紹介という健康グッズ紹介みたいでしたが、古田の作業環境でした！ まとめ いかがでしたでしょうか？ 分割キーボードや昇降デスク、ストレッチグッズなど身体の健康に気を遣った環境が多かったですね！ やはりエンジニアは1日の大半をデスクで仕事をするので、作業環境の大切さを再実感しました。 何か参考になるものがあれば幸いです。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは、ファインディ株式会社で機械学習エンジニアをしていますsasanoshouta( @Edyyyyon )です。この記事は、ファインディでインシデントが発生した際に行なっている ポストモーテム の運用とその様子について、先日発生したインシデントを元に紹介をする記事となっています。 今回発生したインシデントについて まず、今回発生したインシデントについて軽く紹介をさせていただきます。一言で表現すると、 サービスの機能の1つを一時的に停止 させてしまいました。 ポストモーテムの様子 弊社ではインシデントが発生した際に ポストモーテム を実施して再発防止に努めております。 ポストモーテムとは？ そもそもポストモーテムとはなんだ？と言う方もおられるかもしれませんので、簡単にご紹介いたします。 ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。 *1 一般的にポストモーテムを実施するには一定の基準があり、基準を超えた障害が起きたときに実施するものです。 しかし弊社ではまだポストモーテムに対する知見や歴史が浅く、文化として根付かせるために、現在は練習も兼ねて小さい障害でもポストモーテムを実施するようにしています。 ポストモーテムの流れ 今回のインシデントを例に、ポストモーテムの流れを見る形で実施の様子をご紹介します。弊社の場合のポストモーテムは、以下の順序で実施されます。 当事者が事前に障害までのアクションを振り返る ミーティングで集まりアクションについてのフィードバックを実施する ネクストアクション決定とウォッチ 1. 当事者が事前に障害までのアクションを振り返る この手順について特筆する事はありませんが、弊社の場合はGoogle docsにてインシデントごとに管理をしているので、以下画像のように主催者からdocsの案内が来たタイミングで覚えている事が新鮮なうちに時系列での出来事の詳細を記載しています。 ポストモーテム実施前の連絡 2. ミーティングで集まりアクションについてのフィードバックを実施する 以下画像のような形で、事前に当事者が書き記した時系列でのイベントを振り返りながら、各イベントに関連するアクションの中で良かった点と改善点について参加者で話し合います。 ポストモーテム実施時の雰囲気例 少しだけインシデントの事について触れますが、「機能が利用不可になっている事が発覚してから復旧までをスムーズに行えた」と言う振り返りがありました。当日はゴールデンウィークの狭間時期と言う事もあり、本来のバックエンド担当者が不在の間に起きた出来事でもありました。しかし、日頃からサービス上で提供している機能のIaC化をコツコツ進めていた事で担当者不在の中でもスムーズな復旧対応が行えました。 3. ネクストアクション決定とウォッチ 2 で行なったイベント・アクションに対する振り返りをもとに、ネクストアクションを決定します。 以下は今回のインシデントにおけるネクストアクションにもなります。今回起きた事は、機能開発者が開発に必要なサービスとその権限をバックエンド運用者と 十分な意思疎通をしきれなかった事で起きたインシデント だと捉えています。ヒューマンエラーを起こしてしまった開発者目線のネクストアクションを今回は以下のように定めました。 開発に着手する前に管理者側と十分に意思疎通を図れるフローを制定し、運用する フローの中で定める項目 開発したい要件について運用者に事前共有する 開発の為に必要最低限の適切な権限を要求する 上記フローをポストモーテム実施後3日以内に作成し、次回週次の全体確認会で案内。 また、運用者目線でも開発時に「 今自分がどちらの環境を開いているのか目視で分かりづらいのでは 」との意見もあり、「 どの環境にいるのか分かりやすくする為の視覚情報を導入 」する事で同様のヒューマンエラーを防ぐ仕組みを導入する事になりました。 ポストモーテム後のネクストアクションを作成はしたものの、形骸化するものも中には少なからず存在すると思います。 なので、弊社ではネクストアクションを議論する際に意識するポイントとして、 具体性を持たせて明確なアクションにすること それを定期的にウォッチして進んだのか進んでないのかを確認し続けて放置しないこと の2点を常に意識してポストモーテムを実施するようにしています。 余談ですが、弊社では全エンジニアが直近の取り組みを持ち回りで定期的に共有する全体会のようなものを設けています。 その全体会の場でポストモーテムの内容と得られた知見を包み隠さず共有し、エンジニア組織全体の共有知見とすることを文化としています。 ネクストアクションにはインシデントを受けてどんな対策を打つか？を考える事に焦点が集中しがちだと思いますが、「当事者でないエンジニアも含む組織全体に対して共有する」という事も再発防止策の一つとして機能している事を実感しています。 ポストモーテム実施時に気をつけている事 上記弊社でのポストモーテムの様子を実際のインシデントを例に紹介しました。最後に、実施の際に気をつけている事について共有します。 犯人探し、批判をしない ポストモーテムで最も重要視している項目です。 ポストモーテムの目的は学びにあり、犯人探し、批判を行うとそれを恐れ当事者が真実を語らなくなり、その背後にある本当の原因に気づくことができなくなる為です。 批判ではなく、 根本原因の追求と分析に徹する 事を心がけるようにしています。 障害の根本原因を分析し、理解する 原因の分析が不十分だと、誤った再発防止策になり、結果として同じ障害が再発することに繋がりかねません。 客観的な視点で、 原因がシステムやプロセスにあることを意識して分析をする ようにしています。 人ではなく、仕組みで解決する 再発防止策が頑張る、気をつけるだけだと、再発防止を人に依存することになりますが、人はミスをする生き物です。 システムやプロセスを修正して、 人がミスしても被害を最小限にくい止める ように努めるようにしています。 問題点だけでなく、良かった点も指摘、称賛する 犯人探し、批判はご法度ですが、良かった点があれば何回でも称賛する事も大切にしています。 さいごに 改めまして、ご不便をおかけしましたユーザーの皆様に深くお詫びをするとともに、再発防止に努めてまいります。 今回のポストモーテムを通じて、開発を進める上で足りていなかった観点・過剰だった点を浮き彫りにする事ができたことは非常に個人として学びになりました。 この学びを活かして、より良いサービス創りに貢献できるよう個人・組織として精進してまいります。 *1 : ※ SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム より抜粋

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 早速ですが、これは弊社のとあるチームの1ヶ月のサイクルタイムです。 最初のコミットからマージされるまで平均3.6時間程度と、開発に着手したらその日のうちにリリースされるのがデフォルトとなっています。 今回はこの開発スピードを継続し、更に速くするために弊社で実践しているテクニックを紹介していきます。 それでは見ていきましょう！ タスク分解 Pull requestの粒度 テスト CI/CD 高速化 自動化 通知 まとめ タスク分解 開発タスクをアサインされた時、まず最初に タスク分解 をします。 タスク分解をすることによるメリットとしては、 工数見積もりの精度が上がる 対応方針の認識を他メンバーと合わせやすくなる 対応漏れに気づきやすくなり、手戻りの発生が少なくなる Pull requestの粒度を適切に保つことができる 他メンバーへの引き継ぎをしやすくなる などが挙げられます。 分解したタスク毎にPull requestを作成することで、Pull requestを小さく作り続けることが可能になります。 マークダウン記法のチェックボックスを使ってIssueにタスクリストを洗い出します。 終わったタスクから順にチェックボックスにチェックを入れ、タスク管理をします。 良いタスクリストを作成するためのコツは、 最初から完璧なタスクリストを作ろうとしない ことです。 まず最初に大枠のタスクを考え、そこから分解していくように意識してタスクリストを作成すると、結果的に詳細なタスクリストが完成しています。 完成したタスクリストを元にPull requestを作成していくと、結果的に適切な粒度でPull requestを作成できるようになるはずです。 例えば、何かしらのデータの一覧を返すREST APIを追加する場合、次のようなタスクに分解できます。 - [ ] APIの仮実装を行う - [ ] APIのエンドポイントを決める - [ ] APIのresponseの形を決める - [ ] モックデータを返す - [ ] データベースからデータを取得して返す - [ ] 検索条件に対応する - [ ] id - [ ] nameの部分一致 - [ ] ソートに対応する 小さくコツコツと修正を上乗せしていき、最終的に完成形に近づけていくような分解の仕方が良いでしょう。 大きな機能の実装担当になった際に、一度に全ての機能を実装するのではなく、 小さい機能追加を何回も繰り返して結果的に大きな機能を完成させる ようなイメージを持つと良いです。 まずタスク分解をして作成したタスクリストを他のメンバーにレビューしてもらいます。そこで認識を合わせることで、開発の進行がスムーズになります。 分解したタスクに沿って開発を進めていくと、そのタスクも更に分解したほうが良いことに気づくこともあります。 その際はどんどん分解していきます。結果的に分解されたタスクそのものが知見となり、今後の開発の参考になるからです。 Pull requestの粒度 Pull requestを小さくすることで開発生産性が改善することは既に知られている事実ですが、小さすぎても問題が出ます。 じゃあどうするのか？という話になりがちですが、これはPull requestの サイズ を気にしすぎていて 粒度 を考えていないために起こる問題です。 Pull requestを 小さくするのではなく、粒度を考える ことが、小さいPull requestを作り続けるための秘訣です。 では適切な粒度とはどういったものなのでしょうか？それは、 一つのことだけに注力している Pull requestです。 具体的に幾つかの例を挙げましょう。 例えば、「関数名を変更したので、それを利用してる1万行を一括置換したPull request」があるとします。 これは適切な粒度だと言えます。変更行数は1万行でサイズは大きいかもしれませんが、「特定の関数名を一括置換する」という1つのことしかしていないため、粒度としては適切です。 Pull requestの概要欄に一斉置換した旨を書いておき、CI通れば即mergeでOKです。 ※後述するように自動化テストが充実しており、守れるテストになっている前提です では「画面の開発中に別の画面のリファクタを入れ、変更行数は20行程度だったPull request」はどうでしょうか？ これは適切な粒度とは言えません。変更行数は20行でサイズは小さいかもしれませんが、「画面の開発」と「別の画面のリファクタ」という２つの事を同時にしているため、粒度としては不適切です。 仮に画面の開発の部分で不具合が発生しrevertが必要になった場合、画面の開発部分だけではなく別の画面のリファクタの部分も同時にrevertされてしまいます。 適切な粒度を考える上で、 Pull requestの存在意義が多岐に渡っていないかどうか？ ということを考えると良いです。 粒度が大きすぎると出てくる問題は色々とありますが、 レビューに時間が掛かり、レビュワー目線で考えるとレビューに対して精神的に負荷がかかる どこをどうレビューしたら良いのか分かりづらいため、レビューの質が下がり、結果的に不具合の発生率が高くなる Pull request上でのコミュニケーションが必要以上に増えてしまう 不具合発生時の影響範囲が広くなり、原因の特定に時間がかかる etc などが挙げられます。 Pull requestが大きすぎること自体の原因は組織によって異なりますが、 Pull requestの粒度が大きすぎることは、システム開発において何のメリットも生み出さない のです。 適切な粒度を維持し続けることにより、Pull requestのレビューに対する負担が減るためレビュー自体の質が上がることに加え、レビューの優先度が上がることに繋がり、結果的に開発スピードと品質の両方を担保できます。 テスト 実装コードに加えて、それの動作を保証するテストコードを同じPull request内で用意することをマストとしています。 実装コードよりもテストケースやテストの内容に対するレビューの方が多いこともあります。 弊社ではテストのカバレッジに対しての大きな拘りは特にありませんが、カバレッジよりも重要視していることがあります。 それは、そのテストが「守る」テストになっているかどうかです。通るべき時に通り、コケるべき時にコケるテストになっているかどうかが重要なのです。 例えば正常系の次のようなテストコードがあるとします。 const mockOnSuccessCallback = jest.fn (); const mockOnErrorCallback = jest.fn (); const { result } = renderHook (() => useHoge ( { onSuccessCallback: mockOnSuccessCallback , onErrorCallback: mockOnErrorCallback } )); act (() => { result.current.handleSubmit (); } ); expect ( mockOnSuccessCallback ) .toHaveBeenCalledWith ( 'test' ); hooksの関数を実行し、成功時に引数で渡したコールバック関数が実行されることを確認しています。 一見何の変哲もないテストコードですが、このテストコードには次の視点が抜けており、守るテストとしては不十分なのです。 成功時の関数が複数回実行されたとしても通ってしまう エラー時のコールバック関数が実行されたとしても通ってしまう こういったケースでは、弊社では次のようなテストコードが良いとされています。 const mockOnSuccessCallback = jest.fn (); const mockOnErrorCallback = jest.fn (); const { result } = renderHook (() => useHoge ( { onSuccessCallback: mockOnSuccessCallback , onErrorCallback: mockOnErrorCallback } )); act (() => { result.current.handleSubmit (); } ); expect ( mockOnSuccessCallback ) .toHaveBeenCalledTimes ( 1 ); expect ( mockOnSuccessCallback ) .toHaveBeenCalledWith ( 'test' ); expect ( mockOnErrorCallback ) .not.toHaveBeenCalled (); このテストコードにより、「成功時に1回だけコールバック関数がパラメータ付きで実行され、エラーのコールバック関数が実行されない」ことを守ることができます。 この2つのテストコードのカバレッジは変わりませんが、テストとして守ることができる内容が異なります。 弊社ではカバレッジよりもテストが守る内容の方に重きを置いており、結果としてカバレッジが上がっているだけなのです。 弊社のリポジトリではテストカバレッジが90％を超えているものも珍しくないですが、それはカバレッジを意識してテストを書いたのではなく、守るテストを書き続けることによって勝手に上がったものなのです。 このような一定の品質以上のテストコードが存在することにより、ライブラリのバージョンアップや既存処理のリファクタなどは「CI通れば即mergeでOK」という文化が根付いています。 全ての修正に対して動作確認を行うことは無く、テストコードのお陰でスピードと品質の両方を担保する状況を維持し続けることを実現しているのです。 CI/CD 弊社のCIのほとんどはGitHub Actionsで統一しています。 弊社ではPull requestが作成されるたびにテストやLinterなどを実行し、レビューの効率化やコードの品質を一定に保つようにしています。 高速化 CIの速度には非常に拘っており、様々な高速化の工夫をしています。CIの実行速度が遅いと、Pull requestをmergeするまでの時間が長くなってしまい、結果的にクリティカルパスになってしまうからです。 1つ目はキャッシュの活用です。GitHub Actionsが提供している各種パッケージをキャッシュする仕組みを利用することで、CIのセットアップに必要な時間を削減することが出来ます。 弊社ではいくつかのプロジェクトに Nx を導入しており、Nxが持つ 変更検知機能 と リモートキャッシュ機能 によってCIを大幅に高速化しました。 2つ目はテストコードの実行を並列化することです。 GitHub Actionsのmatrixと呼ばれる機能 を利用し、CIのワークフローそのものを並列実行できるようにしています。 テストファイルをいくつかのグループに分類し、それぞれのワークフローにグループごとのテストファイルを割り当てる独自のスクリプトを用意しています。 1つのワークフロー内で全てのテストファイルを実行してしまうと、テストファイルの数に比例してCIの実行時間が長くなっていきます。 しかしグループ分けをしてワークフローを並列実行することで、CIのトータルでの実行時間はほとんど変わりませんが、CIが完了するまでの時間を一定に保つことが出来るようになります。 詳細は 別記事 の方でも紹介しているので、興味がある方はそちらもご覧ください。 3つ目はGitHub Actionsのワークフローが実行される runnerのスペックを上げる ことです。 runnerのCPUのコア数やメモリを増やしたマシンを利用できるように設定し、テストコードの実行コマンドを見直して、同じワークフロー内でもテストコードを並列実行できるようにしています。 つまりワークフローそのものと、ワークフロー内の両方の並列化を実現しています。これにより、弊社では最大で40個のテストファイルを並列実行しているリポジトリもあります。 runnerのスペックを上げることにより利用料金の大幅な増額が予想されますが、GitHub Actionsの課金はrunnerの総実行時間に対して行われており、ワークフロー自体の実行が高速化される分、結果的に総実行時間が短くなり、課金額が必要以上に膨らんでしまうことを防いでいます。 自動化 CI高速化以外にも業務の効率化のため、ほぼ全てのプロジェクトにリリース作業を自動化する仕組みを取り入れています。GitHub Actionsのワークフローを手動実行するだけで、リリース用のPull requestが自動生成され、それをmergeするだけで自動的にstaging/production環境へのデプロイが実行されるようになっています。 更にPull requestのLabelsやAssigneesを自動で設定するようにもしています。 このように手間とコストを掛けてでもCI/CDの高速化と自動化の両方を実現させています。 通知 何かしらの異変、変化、依頼があった際に、そのタイミングでSlackに通知が飛ぶようになっています。 まずエラーや障害の検知です。本番環境でエラーや障害、各種負荷の増加が発生した際に、SentryやDatadogを通じてSlackに通知を飛ばすようになっています。この仕組みによって不具合や障害に最初に気づくまでの時間が短縮され、修正コードを本番環境にデプロイされるまでの時間が短縮されます。 次に開発時の通知です。GitHubのWebhookを通じて、Issueが作られた時やコメントが追加された際にSlackにメンション付きでリアルタイムで通知するようにしました。 特に効果が大きかったのはPull requestのレビュー依頼をメンション付きで通知することです。この仕組みによりファーストレビューまでの時間が短縮され、結果的にPull requestがマージされるまでの時間が短縮されました。 本来であればGitHubの公式APPを利用して通知を送信すればよいのですが、弊社では独自に開発したスクリプトを利用しています。 公式APPは通知内容の情報も入ってくるので一見すると便利ですが、弊社の開発スピードだと通知が多すぎて、逆に通知の内容が流れすぎてしまうことがありました。 そのため、もっとシンプルな内容を通知してくれる独自スクリプトを用いて通知を送信しています。 不具合や障害、レビュー依頼もコメントも、気づかないとそこから何も動きがありません。気づかないことがクリティカルパスになるのです。 まとめ いかがでしたでしょうか？ 弊社では開発生産性や開発スピードに重きを置いており、そのためには手間とコストを惜しまず日々改善を続けています。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers また、6月28日（金）・29日（土）に『LeanとDevOpsの科学』の著者であるNicole Forsgrenの来日、テスラ共同創業者元CTOの登壇など、国内外の開発生産性に関する最新の知見が集まるConferenceを開催します。 開発生産性に関する他の企業の取り組みや海外の事例に興味がある方は、ぜひお申し込みください！ dev-productivity-con.findy-code.io

こんにちは。ファインディでVPoEをしている 神谷 です。 沖縄、楽しかったですね、 観光、しましたか？ 私は龍が如く3の世界観を感じようと最終日に国際通りを1時間ほど散策しました。（そしてすぐに飛行機の時間・・・ ） 龍が如く8の名所巡りもしたいので、再来年のRubyKaigiは是非ハワイ開催にならないかな・・・ この記事では、RubyKaigi 2024に参加した皆さんがそれぞれ感じた、 「 Rubyを書くことが楽しい 」 「 Rubyコミュニティに参加することが楽しい 」 これらの想いが将来のキャリアに絶対につながる、という話を、普段採用に関わる私の目線で書こうと思います。 もちろんRubyKaigi不参加の方でも、将来のキャリアに悩んでいる方に読んでいただきたい内容です。 筆者はどんな人？ 私のRuby歴はRailsがバージョン1.0の時代からなので、18年ほどになります。 RubyKaigiは2014年に初参加したのを覚えています。 ファインディでは2018年からスポンサーをする機会があり、2022年から3年連続ブース出展をしています。ファインディブースで話して頂けた方々、ありがとうございます。 ファインディのブースの取り組みは、DevRelの まっきー がnoteに公開しているので、そちらを参考にしていただけると嬉しいです。 note.com 普段の業務はVPoEとして組織作りがミッションであり、採用はその中心となります。 2023年では私1人の面談・面接の回数が1年間で450を越え、入社予定も含めると40名規模のエンジニア組織になりました。お時間頂いた皆様、ありがとうございます。 その中で、Rubyistとの面談も3割ほどはあるのですが、RubyKaigi参加したことありますか？という質問に対して、参加していますと回答されるのは体感10%ほどです。 ご家庭事情や業務都合で参加できない方も多いと思いますが、今回のRubyKaigiに初参加の方も多数いらっしゃいました。初参加の方に参加理由を聞いてみたところ、「スポンサー企業に転職したのでついに参加できました」という方も何名かいらっしゃいました。 1000人以上のキャリアと向き合った中で感じること RubyKaigiのようなカンファレンスに参加されない方が多い中で感じる課題感となりますが、経験年数が長い方でもRailsのソースコードを読む経験が一度も無いという方や、gemのソースコードを追った経験が無い方も多くいました。Rubyは業務で使う言語なので、プライベートでは書かないようにしています、と宣言される方もいました。 私が面接の中でよく聞く質問として、「 メタプログラミングの中で好きなテクニックはありますか？ 」があります。 この質問に対する回答として 「先輩からメタプログラミングは絶対に使ってはいけないと教わったので、それ以来触っていません」 「Ruby始めた頃に使ってはいけないと教えられました。それ以外、業務で使うことが無いので、特に勉強する機会がありませんでした」 このような回答が多いです。 メタプログラミングは使い方を誤ると後で苦労することは実際にありますが、だからと言って勉強しないと決めてしまうのは非常に残念です。 技術として難しくもあるが楽しいものであり、理解が深まるたびにプログラミングを好きになる可能性もあると思っています。 Railsや様々なgemにはこの技術が有効利用されており、知らないとソースコードを読むのも非常に苦労するでしょう。 逆に、シンプルにプログラミングや技術を楽しんでいる方とお話するのはこちらも嬉しい気持ちになります。 余談：「 okuribito 」gemの開発者であり弊社社員の @shakemurasan さんと面接した時は、 method_missing の使い方のディスカッションが中心となりました。めちゃめちゃ楽しかったです。 そんな彼の記事はこちら↓ tech.findy.co.jp 弊社で活躍しているエンジニア、私が過去にご一緒した素晴らしいエンジニアの方々、全員に共通して言えることは、仕事とか関係なく技術そのものを楽しみながら探求している方が多いなと感じています。 楽しめることによって技術力が向上し、その技術力を使って課題解決し、顧客に価値提供していくという良いスパイラルが生まれているのではないでしょうか。 RubyKaigi 2024で感じたこと 今回のRubyKaigi 2024で感じたことは、裏テーマとして「 Ruby楽しもうぜ 」があったのかな？と思うくらい、Rubyや技術を全力で楽しんでいる方々の登壇が多かった印象です。 特に初日の @tompng さんの「 Writing Weird Code 」のキーノート。 最後に感動すら待っている、非常に素晴らしいキーノートでした。 何をやっているか全く分からなかったが（褒め言葉）、Rubyが楽しい言語だということが分かった、そう感じた方も多くいたと思います。 普段業務で使うプログラミング言語の1つ、多くの方にはそれだけのことかもしれませんが、言語そのものを楽しめることによって、エンジニアとしての成長速度が早くなると思っています。楽しめている方と楽しめていない方、長期スパンで見れば見るほどこの差は大きくなるのではないでしょうか。 また、コミュニティに参加することによって自分自身のスキルの立ち位置も把握しやすくなり、スキルの立ち位置を把握することこそが、スキルアップの近道だと思っています。 Ruby/Rails書籍の著者の方やgemの作者、コミッターの方々、本当に様々な方と（drink upなどを通して）お話する機会が多くあり、それがモチベーションにもつながっていきます。 「 Rubyを書くことが楽しい 」 「 Rubyコミュニティに参加することが楽しい 」 これらのシンプルなことが今後のキャリア形成において非常に重要なのでは、とあらためて感じたのでこのような記事にしてみました。 将来のキャリアに悩んでいる方、初心に立ち返り、自分が技術を楽しめているか振り返ってみるのも良いかもしれません。 最後に 5/28（火）に、「After RubyKaigi 2024〜メドピア、ZOZO、Findy〜」として、メドピア株式会社、株式会社ZOZO、ファインディ株式会社の3社でRubyKaigi 2024の振り返りを行います。 オンライン・オフラインどちらもあり、LTやパネルディスカッションなどコンテンツ盛りだくさんなのでぜひご参加ください！！ findy.connpass.com ファインディでは、これからもRubyを積極的に活用して、Rubyとともに成長していければと考えております。 そして、一緒に働くメンバーを絶賛募集中です。 興味がある方はこちらから ↓ herp.careers

ハイサイ、ファインディでTeam+を開発しているEND（ @aiandrox ）です。 RubyKaigi 2024最高でしたね！！私は2度目の参加でしたが、去年よりもみんなが笑っているところで笑えるようになり、各種イベントなどでいろんな方と話すことができたのでさらに楽しめました。 今回特に印象に残ったのは初日のKeynoteの「 Writing Weird Code 」でした。 「なるほどわからん」という感じで、正直半分以上わからなかったです。ただ、描画されたコードが格好よくてめちゃくちゃ感動しました。何が起きているのかはわからなかったけど、なんか浪漫のようなものを感じました。 せっかくRubyKaigiでQuineというものを知ったのだから、自分にどこまでできるのかはわからないけどやってみたい！ということで、Quineに挑戦してみました。 Quine（クワイン）とは Quineとは、自分自身のソースコードを出力するプログラムのことです。 すごい見た目でなければいけないのかと思いきや、Quine自体にデザインはなく、 cat と実行時の出力結果が同一になるものをQuineと呼びます。 eval $s = %w' o="eval$s=%w"<<39<<$s<<39<<".join";puts(o) ' .join しかし、私がやりたいのは見た目が格好いいやつなので、今回はデザインQuineを作るのを目標にしました。 いざ実践 まずは何からすればいいのか？ですが、最初に読むには「 あなたの知らない超絶技巧プログラミングの世界 」が一番わかりやすかったです。とりあえずこれを読んで手元で実行しながら、ざっくりとQuineの概要と考え方を頭に入れます。半分くらいは理解できていませんが気にせず進めました。 その後、他の実装記事なども読みつつ実際にコードを書いてみました。 RubyでうどんげQuine(とAA型Quineの作り方講座) で、AAのQuineを作る方法が紹介されていたので、それを参考にしました。詳細な作り方はこちらの記事に書いてあります。 まず、使いたい画像をAAに変換します。今回はFindyのロゴを使用しました。 その後、形を整えつつAAを 01 に置き換え、Quineを作成するための build.rb を作成しました。 細かいロジックは参考元 *1 の記事にあるので省略しますが、簡潔に書くと以下の通りです。 圧縮したAAデータ bin を元に、空白またはコード1文字分を o に追加していく 最初に eval$s=%w' 、最後に '.join があるので、その中のコードは空白を削除されたうえでRubyコードとして実行可能 # build.rb aa = <<~ END 00000000000111111100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000001111111111111110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000111111111111111111100000000000001111111111111111100011111100000000000000000000000000000000000011111000000000000000000000 00011111110000000001111111000000000001111111111111111100011111100000000000000000000000000000000000011111000000000000000000000 00111111000000000000011111100000000001111110000000000000000000000001110000000000000000000000000000111110000111000000000111000 00111110011110000000000111110000000001111110000000000000011111100001111111111111110000000111111111111111000111111000001111110 01111111111100000000000111110000000001111110000000000000011111100001111111111111111100001111111111111111000011111000011111100 01111111111000000000000011110000000001111111111111110000011111100001111110000011111100011111110000111111000011111100111111000 01111111000000000000000111110000000001111111111111110000011111100001111100000011111100011111000000011111000001111111111110000 00111110000000000000000111110000000001111111111111110000011111100001111100000001111100011111000000011111000000111111111100000 00111111000000000000011111100000000001111110000000000000011111100001111100000001111100011111100000111111000000011111111000000 00011111111000000011111111000000000001111110000000000000011111100001111100000001111100001111111111111111000000001111110000000 00000111111111111111111111110000000001111110000000000000011111100001111100000001111100000111111111111111000000001111100000000 00000000111111111111100011111000000000111110000000000000001111100000111100000001111000000000111111001111000000011111100000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111111000000000 END start_text = ' eval$s=%w ' end_text = ' .join ' aa_data = aa.split( "\n" ) x_length = aa_data.first.length y_length = aa_data.length last_point = aa_data.last.split( ' 1 ' ).last.length # 最終行に1がないパターンは考慮しない bits = aa.gsub( "\n" , '' ).reverse.to_i( 2 ) bin = [ Marshal .dump(bits)].pack( ' m ' ).gsub( "\n" , '' ) code = <<~ CODE b=" #{ bin } " n=Marshal.load(b.unpack("m")[0]) e=" #{ start_text } "<<39<<($s*3) o="" j=-1 0.upto( #{ y_length } * #{ x_length } -1){|i| o<<((n[i]==1)?e[j+=1]:32) o<<((i% #{ x_length } ==( #{ x_length - 1 } ))?10:"") } o[- #{ last_point + end_text.length + 2 } ,6]=""<<39<<" #{ end_text } " puts(o) CODE code = code.split( "\n" ).join( ' ; ' ) code << ' # ' file = File .new( ' quine_base.rb ' , ' w ' ) file.puts "#{ start_text } ' #{ code } ' #{ end_text }" これによって作成されたコードを実行すると、以下の出力を得られます。出力結果を quine.rb に記述して、 ruby quine.rb を実行すると、同じ結果になります。 これにてQuineの完成です🎉 eval $s = %w' b="BAhsK3oA+ AMAAAAAAAAAAAAAAAAA 8P8HAAAAAAAAAAAAA AAAgP/ /A4D/ //gBAAA A4AMAAP wB/AHw/x8/AAAAAHw AAMAPA H4Afg AAgAMA AMCHAz j4PAAf wA8 A/PD/ B/z /8Y Of/wP gA/g BgB/+ /8P/P3 z48T8A eAD/f/DDD3784Ye fH/4AgA/g/w9++M CPD/jg /4EPAP AB/P/BDx/w8 QEf+B /wA4Af gB8A+O EDPn7wA/4B/AP+AfA DAD98wIf/f4AfAP7 //wB+ AOCHD/ jg/w/wAQD+ Pz6A DwD44AEP4OcBPwA AAAAAA AAAAAA AAAAA8 AM=";n= Marsha l.load (b.unp ack("m" )[0]) ;e="eval$s=%w"< <39<<( $s*3) ;o=""; j=-1; 0.upt o(15*125-1){ |i|;o <<((n [i]==1)?e[j+=1] :32);o <<((i %125= =(124 ))?10 :"");};o[- 16,6]= ""<<39 <<".jo in";pu ts(o) #b="B AhsK3o A+AMAA AAAAAAAA AAAAAAA8 P8HAAAAA AAAAAA AAAAAg P//A4 D///g BAAAA4AMAAPwB/AH w/x8/A AAAAHwAAMAPAH4AfgAAgAMA AMCHAz j4PAAf wA8A/ PD/B/ z/8YOf/wPgA/gBg B/+/8 P/P3z48T8AeAD /f/DD D3784 YefH/ 4AgA /g/w 9++MCP D/jg /4EPAP ' .join ここまではわりとスムーズにできました。 eval$s=%w' から '.join' まではRubyコードなので、 # の後はコメントアウトとして好きな文字を入れることができます。例えば、 code 変数内の e を変更すると、 puts(0) 以降を # で埋めることができます。 e= "#{ start_text }" << 39 <<( $s + " # " * 500 ) eval $s = %w' b="BAhsK3oA+ AMAAAAAAAAAAAAAAAAA 8P8HAAAAAAAAAAAAA AAAgP/ /A4D/ //gBAAA A4AMAAP wB/AHw/x8/AAAAAHw AAMAPA H4Afg AAgAMA AMCHAz j4PAAf wA8 A/PD/ B/z /8Y Of/wP gA/g BgB/+ /8P/P3 z48T8A eAD/f/DDD3784Ye fH/4AgA/g/w9++M CPD/jg /4EPAP AB/P/BDx/w8 QEf+B /wA4Af gB8A+O EDPn7wA/4B/AP+AfA DAD98wIf/f4AfAP7 //wB+ AOCHD/ jg/w/wAQD+ Pz6A DwD44AEP4OcBPwA AAAAAA AAAAAA AAAAA8 AM=";n= Marsha l.load (b.unp ack("m" )[0]) ;e="eval$s=%w"< <39<<( $s+"# "*500) ;o="" ;j=-1 ;0.upto(15*1 25-1) {|i|; o<<((n[i]==1)?e [j+=1] :32); o<<(( i%125 ==(12 4))?10:"") ;};o[- 16,6]= ""<<39 <<".jo in";p uts(o )##### ###### ######## ######## ######## ###### ###### ##### ##### ################ ###### ####################### ###### ###### ##### ##### ############### ##### ############# ##### ##### ##### #### #### ###### #### ###### ' .join 色を付けてみる とりあえず、ほぼコピペをすることでQuineが作成できたので、次は色を付けてみたいと思いました。 eval の中は自由にコードが書けるので、わりと簡単にできるのでは？と思いましたが、そんなことはなく、かなり苦労しました。 こちらが今回作成した色付きQuineです。 実際のロゴと重ねるとこんな感じ。 コードはこちら↓ github.com 以下に、実際に作ってみて自分が感じた点について記載します。 データを圧縮するのが難しい このQuineでは、AAを成形するためのデザインコードと色付けロジックに関するコードを持っています。また、それらを描画するコードもあるため、すべてをQuine内に収める必要があります。つまり、 AAの字数 - (AAを描画するロジックの字数 + 色付けロジックの字数 + 描画コードの字数) > 0 にしなければなりません。 Findyロゴをできるだけ大きくすることでコード文字数を確保し、色付けロジックをstringにして実行コード内でeval展開することで対応しました。 irb(main):018> colors_bin = [ Marshal .dump(colors)].pack( ' m ' ).gsub( "\n" , '' ) => " BAhbFG86ClJhbmdlCDoJZXhjbEY6CmJlZ2luaRI6CGVuZGkCZAFvOwAIOwZGOwdpAvQBOwhpAggCbzsACDsGRjsHaQKUAjsIaQKoAm87AAg7BkY7B2kCPgM7CGkCUgNvOwAIOwZGOwdpAuMDOwhpAvwDbzsACDsGRjsHaQKKBDsIaQKcBG87AAg7BkY7... " irb(main):019> colors_text = colors.to_s.gsub( ' ' , '' ).gsub( "\n" , '' ) => " [13..356,500..520,660..680,830..850,995..1020,1162..1180,1328..1345,1495..1510,1660..1675,1825..1840,1990..2005,2155..2170,2320..2336,2490..2506,2655..2669] " irb(main): 020 > colors_bin.length => 408 irb(main): 021 > colors_text.length => 156 # 252字の削減！ 「Ruby Committers and the World」で `frozen string literal の話題のときに mametterさん が話していた「1byteを切り詰めている」とはこういうことかと思いました。 また、AAロジックをQuine内で持つことで、AA成形コードを削減することができるようですが、これについてはどうすればいいのかわからず断念しました。 文字コードの意識が難しい 出力する文字列を、実行コード・出力両方として扱う関係上、そのまま使うことができない文字もあります。そういったものは、ASCIIコードを使うことでエラーを回避します。 例えば、 "\e[34m" などのエスケープシーケンスを使うことで出力文字に色を付けることができます。 しかし、 \e をそのまま記述すると文字列として解釈されます。そのため、生成されたQuineを実行するとそのまま文字列が出力されてしまいます。 （1敗） しかし、 27.chr で "\e" と同値を出力することができます。 *2 ちなみに、 #chr で文字列に変換しているのは + メソッドを使うためなので、 << で文字連結する場合は文字コードの整数のままで問題ありません。 エスケープシーケンスを追加することにより、細かい位置の調整が難しくなる $s に代入する %w で空白を許容した文字列を改めて実行可能なコードにするために、AAのコードの終わりの箇所に '.join を挿入しています。しかし、エスケープシーケンスのそれぞれの文字列が1文字として扱われるため、最後の調整が難しかったです。 今回は以下のようにしましたが、AAが変わると若干崩れるので、最後は手作業で地道に調整することになりそうです。 # build.rb end_text = ' .join ' end_text_start_point = last_point + end_text.length output_text_length = "\e [0m# \e [m " .length # エスケープシーケンスを使って白字を1字出力する必要な字数（`#`は仮の文字列） real_output_text_length = end_text.length * output_text_length # エスケープシーケンスを考慮した上で確保すべき文字数 # （一部省略） code = << CODE l= #{" ' " .ord } .chr o[- #{ end_text_start_point + real_output_text_length } , #{ (end_text.length + 1 ) * output_text_length } ]=l+" #{ end_text } " CODE 感想 eval 内ではRubyのコードを素直に書くことができるので、超絶技巧を使わなくてもQuineでAAを書くことはできました。 ある程度完成しないとコード自体が動かないのでデバッグしづらいし、理解できていない部分もたくさんあります（irbとはずっと付きっきりでした） 。でも、コードを書いていい感じの見た目ができるのがとても楽しかったです！！ おまけ この記事をレビューしてもらったところ、早速カスタマイズLGTMをいただきました🙌 最後に 5/28（火）に、「After RubyKaigi 2024〜メドピア、ZOZO、Findy〜」として、メドピア株式会社、株式会社ZOZO、ファインディ株式会社の3社でRubyKaigi 2024の振り返りを行います。 オンライン・オフラインどちらもあり、LTやパネルディスカッションなどコンテンツ盛りだくさんなのでぜひご参加ください！！ findy.connpass.com また、ファインディでは、これからも新しいものを取り入れつつ、Rubyを積極的に活用して、Rubyとともに成長していければと考えております。 一緒に働くメンバーも絶賛募集中なので、興味がある方はぜひこちらから ↓ herp.careers *1 : RubyでうどんげQuine(とAA型Quineの作り方講座) *2 : クックパッド春の超絶技巧パンまつり 超絶技巧プログラミング編 資料

こんにちは！ファインディでTeam+開発チームのエンジニアメンバーの 西村 です。 この記事では、私が聞いたRubyKaigi 2024のセッション「Lightning Talks」より「Enjoy Creative Coding with Ruby」で紹介されたクリエイティブコーディングを試してみたので共有します。 クリエイティブコーディングとは クリエイティブコーディングとは、アプリケーションのような機能的なソフトウェアを作るのではなく、プログラミング言語を使ってビジュアルアートを創作することです。 クリエイティブコーディングをはじめるまでの背景 私は、RubyKaigi 2024の「Lightning Talks」より「Enjoy Creative Coding with Ruby」で、初めてクリエイティブコーディングについて知りました。 Miyuki Koshibaさんのスライド資料を引用させていただいています。 スライド内にある作例を見て、自分も創りたい！！と思う素敵LTでした！！ speakerdeck.com DAY2の終わりに、クリエイティブコーディングを試しました。 すると、LTの内容通り、数行のコードでブラウザ上に図形を描画できたので、とてもワクワクしました！ もう少し凝ったものを創りたいと思い、ファインディのロゴを創ることにしました。 セットアップ index.htmlに必要なスクリプトを読み込ませるだけで始めることができます。ローカルPCにRubyやほかのライブラリをインストールすることは不要です。 これをもとに、index.htmlを作成します。 github.com scriptタグには、次のライブラリを読み込ませる必要があります。 p5jsライブラリ ブラウザ上で円、四角や三角関数を使った図形等を描画できるようにするライブラリ p5rbライブラリ p5jsとRubyを橋渡ししてくれるライブラリ ruby.wasm ブラウザ上でRubyを実行できるライブラリ <script type="text/ruby"> タグ内に書いたRubyコードが実行され、 <main> タグ内に描画されます。 < html > < head > < script src = "https://cdn.jsdelivr.net/npm/ruby-3_2-wasm-wasi@next/dist/browser.script.iife.js" ></ script > < script src = "https://cdn.jsdelivr.net/npm/p5@1.5.0/lib/p5.js" ></ script > < script type = "text/ruby" src = "p5.rb" ></ script > < script type = "text/ruby" > # ここにRubyで処理を書く </ script > </ head > < body > < main > </ main > </ body > </ html > 創ったもの ファインディのロゴをクリエイティブコーディングで描きました。 創作物は 外部公開 しています。 リポジトリは、こちら↓ github.com どう創ったのか ライブラリが対応している図形を組み合せることで、ファインディのロゴを創れそうだなぁと思いました。 ひとつずつ解説していきます。 まずは、外円部分を描画します。 def draw # 色設定 gray = color( 165 , 165 , 164 ) white = color( 255 , 255 , 255 ) blue = color( 26 , 90 , 164 ) background(white) # 輪郭を消す noStroke() # 外円 fill(gray) arc( 200 , 200 , 300 , 300 , radians( 0 ), radians( 360 ), PIE ) fill(blue) arc( 200 , 200 , 300 , 300 , radians( 130 ), radians( 300 ), PIE ) # くり抜き fill(white) circle( 200 , 200 , 210 ) end つづいて、外円部分の青い部分の端を鋭角にします。 外円とくり抜きの間に下のコードを追加します。 # 外円 ... fill(gray) arc( 284 , 115.5 , 150 , 90 , radians( 190 ), radians( 260 ), PIE ) fill(blue) arc( 96 , 270.3 , 150 , 90 , radians( -60 ), radians( 80 ), PIE ) # くり抜き つづいて、外円から横に伸びる青い部分を描画します。 ※ 青い部分はFindyのFを表しています。 このFの横棒が一番難しかったです。 複数の円を組み合わせて描画する必要があり、それぞれの図形の位置を調整することが大変でした。 # くり抜き ... # 外円から横に伸びる青い部分 fill(blue) rotate( -0.15 ) arc( 127 , 270 , 200 , 200 , radians( 200 ), radians( 290 ), PIE ) fill(white) arc( 127 , 270 , 132 , 132 , radians( 200 ), radians( 360 ), PIE ) arc( 190 , 231 , 125 , 125 , radians( 200 ), radians( 250 ), PIE ) 最後に、外円の右下に四角形を描画すれば、完成です！🎉 # 外円から横に伸びる青い部分 ... # 外円から伸びる四角形 fill(gray) translate(width / 1.25 , height / 1.25 ) rotate(radians( 55 )) rectMode( CENTER ) rect( -5 , 75 , 70 , 45 ) このように部品ごとにコーディングしていくと、簡単に創ることができます！ デザインチェック 本物のロゴと並べて、デザイナーにチェックしてもらいましたが、Fの文字の形を中心にたくさん突っ込まれました。 いただいたフィールドバックの一例です！ 「Fの２本の横棒の右端の角度がいまひとつ」 「外円から横に伸びる青い部分の描画が甘い」（画像を拡大しながら） 本物のファインディのロゴ クリエイティブコーディング作成ロゴ 自分のクリエイティブコーディングの技術力はまだまだなので、今後向上させていきたいです！ 終わりに Xの#creativecoding を見ると、様々なクリエイティブコーディングが投稿されています。 気になる方は是非見てみてください。 また、少しでもクリエイティブコーディングに興味を持っていただけたら、嬉しいです！ 5/28には「After RubyKaigi 2024〜メドピア、ZOZO、Findy〜」として、メドピア株式会社、株式会社ZOZO、ファインディ株式会社の3社でRubyKaigi 2024の振り返りを行います。 LTやパネルディスカッションなどコンテンツ盛りだくさんなのでぜひご参加ください！！ findy.connpass.com ファインディでは、これからも新しいものを取り入れつつ、Rubyを積極的に活用して、Rubyとともに成長していければと考えております。 そして、一緒に働くメンバーを絶賛募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは、あるいはこんばんは。 @gessy0129 です。 沖縄、行ってきました！ 観光、しませんでした！ とても楽しかったです！ 今回、ファインディブースでは、 Ruby歴×Ruby関連のカンファレンス参加回数は？ というアンケートと 日替わりでRuby Code Quiz を実施しました！ 全体的なブースの話はDevRelの まっきー がまとめているのでそちらをご覧ください！ note.com 本記事では、エンジニアなら気になるであろうFindy Ruby Code Quizの解説をしていきたいと思います！では、早速見ていきましょう！ 一日目 - Rubyバージョンの組み合わせ 問題 下記、実行結果のRubyバージョンの組み合わせを答えてください。 なお、ひとつのバージョンはひとつの選択肢にのみ回答できます。 Ruby versions: 3.3.0 or 3.2.0 or 3.1.0 or 3.0.0 ① irb> Time .new( " 2024-05-15T11:11:11Z " ) => 2024 - 05 - 15 11 : 11 : 11 UTC ② irb> Time .new( " 2024-05-15T11:11:11Z " ) => 2024 - 01 - 01 00 : 00 : 00 + 0000 ③ irb> Time .new( " 2024-05-15T11:11:11Z " ) <internal :timev >: 310:in ` initialize': invalid value for Integer(): "2024-05-15T11:11:11Z" (ArgumentError) ④ irb> Time .new( " 2024-05-15 " ) <internal :timev >: 409:in ` initialize': no time information (ArgumentError) 選択肢 ①: 3.2.0、②: 3.0.0、③: 3.1.0、④: 3.3.0 ①: 3.3.0、②: 3.2.0、③: 3.1.0、④: 3.0.0 ①: 3.1.0、②: 3.0.0、③: 3.2.0、④: 3.3.0 ①: 3.0.0、②: 3.1.0、③: 3.3.0、④: 3.2.0 正解と回答率 正解 ✅ 1. ①: 3.2.0、②: 3.0.0、③: 3.1.0、④: 3.3.0 回答率 14.15％ 53.77％ 19.81％ 12.26％ 解説 RubyのバージョンアップのNEWSを追いかけていれば解けるという問題です。 Ruby3.3.0のNEWS https://github.com/ruby/ruby/blob/v3_3_0/NEWS.md Time.new('2023-12-20') # no time information (ArgumentError) これを知っていたら④が3.3.0だとわかります。 Ruby3.2.0のNEWS https://github.com/ruby/ruby/blob/v3_2_0/NEWS.md Time.new now can parse a string like generated by Time#inspect and return a Time instance based on the given argument. Time.newはinspectが出力するstringからパースできるようになった。これで、①は3.2.0以上とわかります。 Ruby3.1.0のNEWS https://github.com/ruby/ruby/blob/v3_1_0/NEWS.md At the same time, time component strings are converted to integers more strictly now. Time.new(2021, 12, 25, "+07:30") #=> invalid value for Integer(): "+07:30" (ArgumentError) Ruby 3.0 or earlier returned probably unexpected result 2021-12-25 07:00:00, not 2021-12-25 07:30:00 nor 2021-12-25 00:00:00 +07:30. そもそも3.1.0までは文字列だけをいれるユースケースはなかったようです。3.0.0以前は文字列だけだとよくわからない挙動になっていたけど、この対応でチェックを厳密にしたことで文字列だけだとエラーになったのではないかと推測します。変更意図などはCommiterの方々に解説求めたい部分です。 ただ、このNEWSの内容を全てを記憶してるのは難しすぎになってしまうので、回答の選択肢を4択にしています。4択なので3.3.0の挙動を知っていたら1番目と3番目の2択に絞れると思います。 これに加えて、3.2.0の挙動を知っていたら①は3.2.0以上とわかるので1番目が答えだとわかります。また、3.2.0の挙動を知らなかったとしても、①〜③は全く同じコマンドを実行しており①が正しく挙動しているので①の方が新しいバージョンだと推測できます。これでも1番目が答えだとわかるようになってます。 二日目 - 代入されているオブジェクトはどれ？ 問題 fooに代入されているオブジェクトは次のうちどれでしょうか？ (Ruby: 3.3.0で実行した場合) irb(main): 001 > foo = ?? ? irb(main): 002 > foo.include?( 3 / 2 ) => true irb(main): 003 > (foo + [ 3 ]).inject( :+ ) => 9 irb(main): 004 > foo.last => NoMethodError 選択肢 1..3 [1, 2, 3] Set.new([1, 2, 3]) Enumerator.new { |y| [1, 2, 3].each { |i| y << i } } 正解と回答率 正解 ✅ 4. Enumerator.new { |y| [1, 2, 3].each { |i| y << i } } 回答率 25.37％ 4.88％ 39.02％ 30.73％ 解説 メソッドに対しての出力結果から元の値を当てる という問題形式を使ってみたかった問題です。 そこから逆算して、ちょっと似ているクラス（Range, Array, Set, Enumerator）を当てるようにしてみました。 irb(main):002 の出力は引っ掛けで、3/2 => 1になるのですべてtrueになる。 が、直感的には3/2 => 1.5という考えを利用して、1..3では？と思わせて問題を難しくしました。 irb(main):003 は、同じ値は重複しないというSetの特徴を利用から、Setを除外できるようになっている。また、Rangeには+メソッドがないのでエラーになる。 irb(main):004 は、Setには順番がなく、Enumeratorは外部イテレータなので最後の要素が特定できないという特徴を利用している。 実行結果を見るのが一番早いですね。 選択肢1 irb(main): 001 > foo = 1 .. 3 => 1 .. 3 irb(main): 002 > foo.include?( 3 / 2 ) => true irb(main): 003 > (foo + [ 3 ]).inject( :+ ) (irb): 3:in ` <main>': undefined method ` + ' for an instance of Range (NoMethodError) irb(main):004> foo.last => 3 Rangeには+メソッドがないのでNoMethodErrorになるのと、lastメソッドがあるので結果が返ってきます。 選択肢2 irb(main): 001 > foo = [ 1 , 2 , 3 ] => [ 1 , 2 , 3 ] irb(main): 002 > foo.include?( 3 / 2 ) => true irb(main): 003 > (foo + [ 3 ]).inject( :+ ) => 9 irb(main): 004 > foo.last => 3 lastメソッドがあるので結果が返ってきます。 選択肢3 irb(main): 001 > foo = Set .new([ 1 , 2 , 3 ]) => #<Set: {1, 2, 3}> irb(main): 002 > foo.include?( 3 / 2 ) => true irb(main): 003 > (foo + [ 3 ]).inject( :+ ) => 6 irb(main): 004 > foo.last (irb): 4:in ` <main>': undefined method ` last ' for an instance of Set (NoMethodError) 同じ値は重複しないというSetの特徴から 003 の結果が6になります。 選択肢4 irb(main): 001 > foo = Enumerator .new { |y| [ 1 , 2 , 3 ].each { |i| y << i } } => #<Enumerator: ...> irb(main): 002 > foo.include?( 3 / 2 ) => true irb(main): 003 > (foo + [ 3 ]).inject( :+ ) => 9 irb(main): 004 > foo.last (irb): 4:in ` <main>': undefined method ` last ' for an instance of Enumerator (NoMethodError) 正解ですね！！ 有識者の方に解説モトム Setには順番がない と書きましたが、firstはあります。なので、こうなります。 irb(main): 001 > foo = Set .new([ 1 , 2 , 3 ]) => #<Set: {1, 2, 3}> irb(main): 002 > foo.first => 1 なんでfirstがあるのか、詳しい方のコメントを待っています。Enumerableを継承しているからと言われたらそれまでと言えばそれまでですがｗ 三日目 - 正しい出力結果は？ 問題 次のコードを実行した出力結果で正しいのはどれでしょう？ (文字コード UTF-8、Ruby: 3.3.0で実行した場合) hoge = [ ?1 , ?2 ].zip([ ?3 , ?4 ], [ ?5 , ?6 ]).transpose.flatten hoge.reject! hoge = hoge.map{|n| n.ord}.sort puts hoge.join( " , " ) 選択肢 1, 2, 3, 4, 5, 6 6, 5, 4, 3, 2, 1 49, 50, 51, 52, 53, 54 54, 53, 52, 51, 50, 49 正解と回答率 正解 ✅ 3. 49, 50, 51, 52, 53, 54 回答率 17.19％ 14.06％ 60.94％ 7.81％ 　解説 問題文のコードを読みにくくするため、わざとインデントやスペースを入れていない。というちょっとイジワルをしました。 [Integer, Integer]に対して、なにかしら変換するのはひっかけるポイントが少ないので、String→Integerへ変換するようにして、複雑さを増すようにしています。 # zipメソッドを使う人はあまりいなそうなので、採用 > hoge = [?1,?2].zip([?3,?4],[?5,?6]) => [["1", "3", "5"], ["2", "4", "6"]] # ノーマルなRubyistは2次元配列を扱うことが少ないはずなので、transposeメソッドを採用 irb(main):003> hoge = hoge.transpose => [["1", "2"], ["3", "4"], ["5", "6"]] # Rubyistはflattenを結構使っている気がする。ここは配列を入れ子にしたくないから、採用 irb(main):004> hoge = hoge.flatten => ["1", "2", "3", "4", "5", "6"] # なにかやっていそうだけど、Enumeratorに変えているだけ irb(main):006> hoge = hoge.reject! => #<Enumerator: ...> # ordメソッドが、StringからIntegerへ変換することを知っているかチェック # sortメソッドが降順 or 昇順どちらで並び替えているか試す irb(main):007> hoge = hoge.map{|n|n.ord}.sort => [49, 50, 51, 52, 53, 54] irb(main):008> puts hoge.join(", ") 49, 50, 51, 52, 53, 54 さいごに 4/1 からクイズ作成を開始して、約4日ほどでほぼほぼ今の形まで出来上がりました。ラフで色んな案を出して、煮詰めていく過程がとても楽しかった（らしい）です。 また、 knuさんがブースに遊びに来てくれてPostしてくれていたのがとても嬉しかったです！来ていただいてありがとうございました！ Findyさんの問題良問ですね！ 自分がSetとEnumeratorとirbセッション4行目の登場人物すべての作者なのに、足し算を勘違いして誤答してしまったｗ #RubyKaigi pic.twitter.com/qkXyemZZkn — Akinori Musha (@knu) 2024年5月16日 問題は @hamchance0215 、 @aiandrox 、 @sontixyou が作成してくれました！ありがとうございました！ 5/28には「After RubyKaigi 2024〜メドピア、ZOZO、Findy〜」として、メドピア株式会社、株式会社ZOZO、ファインディ株式会社の3社でRubyKaigi 2024の振り返りを行います。 LTやパネルディスカッションなどコンテンツ盛りだくさんなのでぜひご参加ください！！ findy.connpass.com ファインディでは、これからもRubyを積極的に活用して、Rubyとともに成長していければと考えております。 そして、一緒に働くメンバーを絶賛募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは！ファインディでTeam+開発チームのEMをしている 浜田 です。 以前公開した記事「ファインディはRubyKaigi 2024 にPlatinum Sponsorsとして協賛します！」で紹介した通り、ファインディはRubyKaigi 2024に協賛しており、現地で参加してきました！ tech.findy.co.jp 今週(5/20〜25)はRubyKaigi 2024の振り返りも兼ねてRubyKaigiに関連した記事を投稿していきます！ この記事では、私が聞いたセッションの中の1つ「 Unlocking Potential of Property Based Testing with Ractor 」で紹介されたGem「 PBT 」を試してみたので共有します。 Unlocking Potential of Property Based Testing with Ractor 「 Unlocking Potential of Property Based Testing with Ractor 」は、Property Based TestingをRubyで実行するためのGemを作成し、さらにRactorを活用することでテストパフォーマンスを向上させる話でした。 speakerdeck.com セッションの中でも触れられていましたが、Property Based Testingを聞いたことがある方は20%ほどとのことだったので、この記事でも簡単に紹介したいと思います。 Property Based Testingでは、従来の入力値を開発者が列挙してテストする手法(セッションではExample Based Testingと呼んでいました)とは異なり、入力値の性質(プロパティー)を指定してテストケースを自動生成して網羅的なテストを行うことができます。 私は以前ファインディ主催で開催した「 t-wadaさん、ymotongpooさんに聞くテスト戦略最前線 」というイベントでt-wadaさんから紹介されて興味を持ちました。 スライドも公開されているので、興味がある方はぜひご覧ください。 speakerdeck.com この記事では、Gem「PBT」を使ってProperty Based TestingをRubyで実装しつつ、従来のテスト手法であるExample Based Testingとの違いを比較します。 試してみた それでは早速試していきます。 今回使用したRubyと主要なGemのバージョンは次の通りです。 Ruby 3.3.1 PBT 0.4.1 RSpec 3.13.0 今回は入力値を3倍にして返却する triple というメソッドを実装します。単純にするため入力値は整数のみ考慮します。 class PropertyBasedTest def self . triple (value) # valueを3倍にして返す end end それではまずいつも通り入力値を開発者が列挙してテストするExample Based Testingでテストを書きます。なお、テストはRSpecを使用します。 triple のテストを書く場合、皆さんはどのような入力値のパターンでテストを書きますか？ 今回は、正の整数 / 負の整数 / 0 の3パターンのテストケースを書きました。 Example Based Testingの場合、開発者がテスト条件を満たす任意の値を選んでテストコードを書くため、適当に選んだ 22 / -5 / 0 を指定しました。 RSpec .describe PropertyBasedTest do describe ' .triple ' do context ' when example-based testing ' do subject( :add ) { described_class.triple(number) } context ' when input value is 22 ' do let( :number ) { 22 } it { is_expected.to eq 66 } end context ' when input value is -5 ' do let( :number ) { -5 } it { is_expected.to eq( -15 ) } end context ' when input value is 0 ' do let( :number ) { 0 } it { is_expected.to eq 0 } end end end end 実行結果は次の通り。無事テストが通りました🙌 PropertyBasedTest .triple when example-based testing when input value is 0 is expected to eq 0 when input value is 22 is expected to eq 66 when input value is -5 is expected to eq -15 Finished in 0.1124 seconds (files took 4.22 seconds to load) 3 examples, 0 failures ところが、 triple メソッドには未知のバグが埋め込まれていました。 3の倍数、もしくは3のつく入力値が与えられた場合は異常終了するというバグです。 今回のテストではたまたま3の倍数や3がつく数値をテストケースに含めていなかったため、このバグを見逃してしまいました。 このような見逃しを回避するための手法として、Property Based Testingが有効です。 Property Based Testingは、入力値の性質(プロパティー)を指定してテストケースを自動生成し、網羅的なテストを行うことができます。 では、PBTを使ってテストを書いてみましょう。 テストコードを見ていただければわかる通り入力値の具体的な値は指定しておらず、整数であること( Pbt.integer )のみを指定しています。 RSpec .describe PropertyBasedTest do describe ' .triple ' do context ' when property-based testing ' do it do Pbt .assert( verbose : true ) do # 入力値が整数であることを指定 Pbt .property( Pbt .integer) do |number| result = described_class.triple(number) # 結果が3の倍数であることを確認 expect(result).to eq number * 3 end end end end end end 実行結果は次の通り。正しくエラーが検出されました。 Randomized with seed 19396 PropertyBasedTest .triple when property-based testing example at ./spec/models/property_based_test_spec.rb:42 (FAILED - 1) Failures: 1) PropertyBasedTest.triple when property-based testing Failure/Error: Pbt.assert(verbose: true) do Pbt.property(Pbt.integer) do |number| result = described_class.triple(number) expect(result).to eq number * 3 end end Pbt::PropertyFailure: Property failed after 5 test(s) seed: 113103392077172016306707556593348939592 counterexample: 3 Shrunk 8 time(s) Got RuntimeError: (´Д｀) ｻﾝｯ!! app/models/property_based_test.rb:5:in `triple' spec/models/property_based_test_spec.rb:45:in `block (6 levels) in <top (required)>' (長いので省略) Encountered failures were: - 614700 - 307350 - 153675 - 76838 - 38419 - 4803 - 301 - 38 - 3 Execution summary: . √ -929894 . √ 440110 . √ -801140 . √ -194044 . × 614700 . . × 307350 . . . × 153675 . . . . × 76838 . . . . . × 38419 . . . . . . √ 19210 . . . . . . √ 9605 . . . . . . × 4803 . . . . . . . √ 2402 . . . . . . . √ 1201 . . . . . . . √ 601 . . . . . . . × 301 . . . . . . . . √ 151 . . . . . . . . √ 76 . . . . . . . . × 38 . . . . . . . . . √ 19 . . . . . . . . . √ 10 . . . . . . . . . √ 5 . . . . . . . . . × 3 . . . . . . . . . . √ 2 . . . . . . . . . . √ 1 . . . . . . . . . . √ 0 # ./spec/models/property_based_test_spec.rb:43:in `block (4 levels) in <top (required)>' Finished in 0.08717 seconds (files took 4.23 seconds to load) 1 example, 1 failure PBTではデフォルトで100通りのテストを実行します。 Property failed after 5 test(s) と表示されているので、5回目のテストでエラーが発生したとわかります。 counterexample にはエラーが発生した入力値のうちShrunkして発見した最小の値が表示されています。今回は 3 が入力された場合にエラーが発生したことがわかります。 また、 Shrunk 8 time(s) とのことなので、8回Shrunkして最小の値 3 を見つけたことがわかります。 無事バグが検出できたので、コードを修正して再度テストを実行します。 今回は無事テストが通りました🎉 PropertyBasedTest .triple when property-based testing example at ./spec/models/property_based_test_spec.rb: 42 Finished in 0.09535 seconds (files took 4.28 seconds to load ) 1 example, 0 failures このようにProperty Based Testingを活用することで、開発者に依存した入力値ではなく、網羅的なテストを行うことができるため、開発者が予見できていないバグを見つけやすくなります。 今回のサンプルコードは単純な処理なのでテスト実行時間にほとんど差がありませんが、通常はPBTの方が試行回数が多くなるためテスト実行時間は長くなります。そのため、様々なインプットのパターンを網羅すべきテストケースなど適材適所で活用いきたいと思います！ 5/28には「After RubyKaigi 2024〜メドピア、ZOZO、Findy〜」として、メドピア株式会社、株式会社ZOZO、ファインディ株式会社の3社でRubyKaigi 2024の振り返りを行います。 LTやパネルディスカッションなどコンテンツ盛りだくさんなのでぜひご参加ください！！ findy.connpass.com ファインディでは、これからもRubyを積極的に活用して、Rubyとともに成長していければと考えております。 そして、一緒に働くメンバーを絶賛募集中です。 興味がある方はこちらから ↓ herp.careers

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

こんにちは、ファインディ株式会社でフロントエンドのリードをしております 新福( @puku0x )です。 この記事では、転職サービス Findy の開発チームにおける開発生産性の向上に対する取り組みをご紹介します。 以前の状況 モノリスの解体 開発基盤の刷新 コンポーネント設計の刷新 テストの拡充 CI の高速化 改善の効果 まとめ 以前の状況 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 *1 : https://dev.to/puku0x/angular-react-2h4j

こんにちは、あるいはこんばんは。 @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でファインディ株式会社が大きくなったこともあり、会議室サイズは比較的大きめです！

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

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