ファインディ株式会社でフロントエンドのリードをしている新福( @puku0x )です。 弊社では Nx を活用してCIを高速化しています。この記事では、最近導入した Nx Agents でフロントエンドのCIをさらに高速化した事例を紹介します。 Nxについては以前の記事で紹介しておりますので、気になる方は是非ご覧ください。 tech.findy.co.jp フロントエンドのCIの課題 Nx Agents Nx Agents導入の結果 Nx Agents利用上の工夫 プロジェクトを細かく分割する Node.jsのバージョンを揃える キャッシュの活用 特定のステップの省略 高度なエージェント割り当て まとめ フロントエンドのCIの課題 これまで「キャッシュの活用」や「並列化」「マシンスペックの向上」といった工夫により、フロントエンドのCIを高速化してきました。 しかし、コードベースの増大により時間のかかるタスクにCI時間が引きずられてしまう問題が顕著になってきました。 次の図は、キャッシュヒットしなかった場合のCI時間の一例です。 他のタスクが早く終わっても一番時間のかかるタスクを待つ必要があるため、結果としてCI時間が伸びる傾向にありました。 Nx Agents タスク単位の並列化では、CI時間のボトルネックを解消するのが困難です。 「DTE（Distribute Task Execution）」はその問題を解決する手法であり、Nx CloudにはDTEのマネージドなサービスである「 Nx Agents 」が提供されています。 Nx Agentsの動作イメージ（Nx公式ドキュメントより抜粋） Nx Agentsは今年2月にリリースされました。費用はGitHub Actionsより安価となっています。 blog.nrwl.io Nx Agents GitHub Actions（Larger runner） Linux 2コア $0.0055/min $0.008/min Linux 4コア $0.011/min $0.016/min 参考: Nx Cloud - Available Plans GitHub Actions の課金について - GitHub Docs 使い方は非常に簡単で、NxワークスペースをNx Cloudに接続した後、CIのタスク実行前に次のようなコマンドを追加するだけです。 npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" 利用するマシンの数やスペックは、変更の影響範囲に応じて動的に設定できます。 npx nx-cloud start-ci-run --distribute-on=".nx/workflows/dynamic-changesets.yml" # .nx/workflows/dynamic-changesets.yml distribute-on : small-changeset : 3 linux-medium-js medium-changeset : 6 linux-medium-js large-changeset : 9 linux-large-js DTE自体はGitHub Actionsの matrix の機能を用いて構成することも可能ですが、CIが失敗した場合は 必ずDTEホスト側のマシンをRe-runする必要があります 。検証した限りでは誤操作を確実に防ぐ方法が無かったため、Nx Agentsの利用をおすすめします。 Nx Agents導入の結果 Nx Agentsを有効にした場合のCI時間の例を示します。 このワークフローでは、アプリケーションのビルドやテスト、型チェックなどを全てNx Agentsで実行する構成となっています。 npx nx-cloud start-ci-run --distribute-on=".nx/workflows/dynamic-changesets.yml" npx nx affected --target=build,build-storybook,test,lint,stylelint,typecheck --configuration=ci npx nx-cloud complete-ci-run 元の構成では約18分かかっていたものが約11分になりました。 CI本体が約10分、後述する事前処理が追加で約1分かかる計算です。 CI時間は約7分削減されており、およそ 40% ほど高速化できたということがわかりました。 各タスクが複数のエージェントで分散実行されたことで、タスク単位で並列化していた場合よりも高速化できました。 Nx Agents利用上の工夫 Nx Agentsは今年リリースされたばかりのサービスであるため、ドキュメントの不備やノウハウの不足といった課題があることに注意しましょう。ドキュメントに示されているセットアップの例は、最低限のものしかないため最適化の余地があります。 ここでは、弊社で実践している利用上の工夫を紹介します。 プロジェクトを細かく分割する DTEの性質上、単体のタスクの実行時間が長くなるほどエージェントの利用効率が下がります。 コードを全て apps/** 側に置くとキャッシュヒット率が下がりCI時間も延びるため、まずは libs/** に分離することから始めると良いと思います。 共有ライブラリについては、コンポーネント系、ユーティリティ系で別のライブラリとして作ると良いでしょう。 弊社の場合、例えばビルド時間が 2分 を超えるようなものを確認した場合は、モジュールの移動や分割を実施しました。 分割が難しい場合は、Nx Agentsの実行対象から外すといった工夫が必要かもしれません。 Node.jsのバージョンを揃える nx-cloud-workflows の workflow-steps/install-node は nvm に対応しています。nvm以外の管理ツールを利用している場合は自前でセットアップ用のスクリプトを書く必要があります。 例として asdf を用いる場合のスクリプトを示します。 # .tool-versions nodejs 20 . 18 . 0 # .nx/workflows/agents.yml launch-templates : custom-linux-medium-js : resource-class : 'docker_linux_amd64/medium' image : 'ubuntu22.04-node20.11-v10' init-steps : - name : Checkout uses : 'nrwl/nx-cloud-workflows/v4/workflow-steps/checkout/main.yaml' - name : Setup Node.js script : | git clone https://github.com/asdf-vm/asdf.git $HOME/.asdf --branch v0.14.1 source $HOME/.asdf/asdf.sh asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git asdf install nodejs echo "PATH=$PATH" >> $NX_CLOUD_ENV CI時間は5〜10秒ほど延びますが、Node.jsのバージョン不一致によるエラーを回避できます。 キャッシュの活用 workflow-steps/cache を利用した依存ライブラリのキャッシュはほぼ必須と言えるでしょう。 node_modules をキャッシュすることで大幅な時間削減が可能です。 # .nx/workflows/agents.yml launch-templates : custom-linux-medium-js : （中略） - name : Restore NPM Cache uses : 'nrwl/nx-cloud-workflows/v4/workflow-steps/cache/main.yaml' inputs : key : '.tool-versions' paths : ~/.npm base_branch : '<デフォルトブランチ名>' - name : Restore Node Modules Cache uses : 'nrwl/nx-cloud-workflows/v4/workflow-steps/cache/main.yaml' inputs : key : '.tool-versions|package-lock.json|yarn.lock|pnpm-lock.yaml' paths : node_modules base_branch : '<デフォルトブランチ名>' - name : Restore Browser Binary Cache uses : 'nrwl/nx-cloud-workflows/v4/workflow-steps/cache/main.yaml' inputs : key : '.tool-versions|package-lock.json|yarn.lock|pnpm-lock.yaml|"browsers"' paths : | ~/.cache/ms-playwright base_branch : '<デフォルトブランチ名>' ここで示した例では、以前の記事と同様に ~/.npm をキャッシュすることで、 node_modules がキャッシュヒットしなかった場合でも可能な限り高速動作するようにしています。 tech.findy.co.jp workflow-steps/cache の使い勝手は actions/cache とほぼ同じです。デフォルトブランチ以外にキャッシュを共有する場合は、デフォルトブランチへのpush時にキャッシュを更新すると良いと思います。 # .github/workflows/update-cache.yml on : push : branches : - '<デフォルトブランチ名>' paths : - package-lock.json jobs : cache : runs-on : ubuntu-latest steps : （中略） - uses : actions/cache@v4 id : cache （中略） - run : npx nx-cloud start-ci-run --distribute-on="3 linux-small-js" - name : Install dependencies if : steps.cache.outputs.cache-hit != 'true' run : npm ci - run : npx nx-cloud complete-ci-run 設定可能な最小エージェント数は 3 である点に注意しましょう。 安く済ませたいところではありますが... 特定のステップの省略 2024年10月現在、Nx AgentsではGitHub Actionsのような条件分岐の構文はサポートされていません。適宜スクリプトを書いて対応しましょう。 # .nx/workflows/agents.yml launch-templates : custom-linux-medium-js : （中略） - name : Install Node Modules (if needed) script : | if [ ! -d node_modules ] ; then npm ci fi 高度なエージェント割り当て --distribute-on=".nx/workflows/dynamic-changesets.yml" は記述が簡潔である一方、現状では small medium large の3段階しか設定できません。また、負荷に応じてマシンスペックを上げるといった高度な割り当てもサポートされていません。 nx.dev Nx Agentsの今後のアップデートに期待しても良いですが、待ちきれないという場合は次のように、メインジョブの前段で nx show projects --affected を実行し、 outputs 経由でオプションを渡すと良いでしょう。 jobs : check : runs-on : ubuntu-latest outputs : distribute_on : ${{ steps.output.outputs.distribute_on }} parallel : ${{ steps.output.outputs.parallel }} steps : （中略） - uses : nrwl/nx-set-shas@v4 with : main-branch-name : ${{ github.base_ref }} - name : Get affected projects id : get_affected_projects run : | length=$(npx nx show projects --affected --json | jq '. | length' ) echo "length=$length" >> $GITHUB_OUTPUT - name : Output id : output run : | if [ $ {{ steps.get_affected_projects.outputs.length }} -gt 20 ] ; then echo 'distribute_on="4 custom-linux-large-js"' >> $GITHUB_OUTPUT echo 'parallel=4' >> $GITHUB_OUTPUT elif [ $ {{ steps.get_affected_projects.outputs.length }} -gt 10 ] ; then echo 'distribute_on="3 custom-linux-medium-plus-js"' >> $GITHUB_OUTPUT echo 'parallel=3' >> $GITHUB_OUTPUT else echo 'distribute_on="3 custom-linux-medium-js"' >> $GITHUB_OUTPUT echo 'parallel=2' >> $GITHUB_OUTPUT fi main : needs : check runs-on : ubuntu-latest steps : （中略） - name : Setup Nx Cloud run : npx nx-cloud start-ci-run --distribute-on=${{ needs.check.outputs.distribute_on }} - run : npx nx affected --target=build,test,lint -parallel=${{ needs.check.outputs.parallel }} この手法は dynamic-changesets.yml による判定と nx affected で検出された影響範囲に乖離がある場合にも有効です。 まとめ この記事では、Nx Agentsの導入によりフロントエンドのCIを高速化した事例を紹介しました。 Nx Agentsの提供するDTEの仕組みは、タスク単位の並列化を超えた高速化が可能です。 一方で、プロジェクトの細分化が十分でない場合や、単一のタスクが非常に時間のかかる場合では期待する効果が得られないため、適材適所で利用するのが良いでしょう。 国内のNx Agents導入事例はまだ少ないと思われますが、検証中に得られた知見は今後も発信していきますので、是非お役立てください。私たちの取り組みが少しでも皆様の助けとなれば幸いです。 現在、ファインディでは一緒に働くメンバーを募集中です。 ご興味がある方は↓こちらからご応募ください。 herp.careers

【エンジニアの日常】エンジニア達の人生を変えた一冊 Part1 では大変ご好評をいただきました。 今回はPart2としまして、弊社エンジニアの人生を変えた一冊をご紹介いたします。 ぜひ、読書の秋のお供としてご参考にしていただければ幸いです！ 人生を変えた一冊 SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム プログラマが知るべき97のこと この本を読んだきっかけ Clint Shankさんのエッセイ「学び続ける姿勢」 Karianne Bergさんのエッセイ「コードを読む」 この本から学んだこと Clean Coder プロフェッショナルプログラマへの道 まとめ 人生を変えた一冊 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム オライリージャパン Amazon こんにちは。ファインディでSREを担当している大矢です。ファインディ一人目のSREとして入社し、SRE歴は8年目になります。 「Site Reliability Engineering -- How Google Runs Production System」の日本語訳は、多くのエンジニアに愛読されている名著です。 GoogleのSREチームの取り組みも書かれており、これからSREを目指す方はもちろん、既にSREとしてご活躍されている方も、まだ本書を読まれていないようでしたら是非一度手に取って頂きたい一冊です。 私はかつて2010年代前半から中盤まで大規模なシステムでインフラエンジニアとして働いていましたが、実際はSREに近い業務を担っていました。 同システムでは開発メンバーとのコミュニケーションは活発でモニタリングやCI/CDも導入していましたが、運用面に対して次のようなプレッシャーを感じていました。 システム変更に対する失敗は許容されない 手作業による環境構築や運用が多い 24/7でのオンコール担当 これらのプレッシャーに対する答えの1つが「SRE Book」でした。 この本ではSLIやSLO、エラーバジェット、ポストモーテム、トイルといったSREにとって重要な概念や、オンコール体制の考え方が解説されています。 例えば前述のプレッシャーに対しては次のようなアプローチをとることができます。 SLI/SLOを定めエラーバジェットに基づいた運用をおこないポストモーテムを活かす トイルを減らすため自動化を進める オンコール体制は適切な人数で適切な持ち回りを行う 上記は当たり前のことかもしれませんが、私自身の考えを整理するうえで強力な後押しをしてくれました。 ところで、ファインディではプロダクト毎にSLI/SLOを設定しエラーバジェットに基づいた振り返りを推進しています。 弊社SREチームは立ち上げから日が浅いですが、これからもこの一冊で得た知識を活かし、ファインディのサービスをより信頼性の高いものにしていきたいと考えています。 プログラマが知るべき97のこと プログラマが知るべき97のこと オライリージャパン Amazon 開発推進チームで、RubyとRustとTypeScriptを書いているバックエンドエンジニアの 西村 です。エンジニア歴は4年目です。 この本はエンジニアとして仕事していく中で素晴らしい知見を共有してくれるエッセイ集です。 エッセイ集であるため、タイトルが気になるエッセイから読んでいく形でも問題ないです。 どのエッセイも経験豊かなエンジニア達が執筆しています。例えば、システム設計に熟練したエンジニアやプログラミング言語のコミッタが執筆している豪華な一冊になっています。 エッセイのテーマは、リファクタリング、設計原則、エンジニアとして仕事をしていく姿勢、テスト等の様々なものがあります。 この本を読んだきっかけ 私がエンジニアとして働いて半年ほど経った頃、自分の理想の姿へ近づくために、どうすればいいのか分からなくなった時期でもありました。 そんな中、毎週通っていた ジュンク堂書店池袋本店 でたまたま「プログラマが知るべき」という文字が目に入って、この本を読み始めました。 次のエッセイを読んで、自分がどうすればいいのかを思いつくきっかけになりました。 当時の私を助けてくれたエッセイは次のものです。 Clint Shankさんのエッセイ「学び続ける姿勢」 このエッセイでは、自分自身で学び続けるために、書籍やインターネットを利用した学習やレベルの高い人と仕事をすることなどが推奨されています。 また、技術の進化に対応できるように、常に学び続ける重要性についても書かれています。 このエッセイを読んで、当時は次のことを毎日欠かさずやっていました。 仕事でわからなかったライブラリのメソッドや仕組みをその日のうちにライブラリのドキュメントを読む ライブラリの挙動を理解するためにローカルPCでコードを動かす このエッセイにある「普段利用しているライブラリについての知識を深める」という記述を参考にしていました。 現在、数ヶ月前から新規プロダクトでRustの検証をしています。そんな中、Rustのことをもっと知りたいと思い、 Osaki.rs というコミュニティを立ち上げて、勉強会を開催しています。 この勉強を立ち上げた背景のひとつに、このエッセイにある「勉強会を自ら立ち上げる」という記述を参考にしています。 このOsaki.rsは、connpassのメンバー数が40人ほどになりました。これからもRustの勉強会を続けていきます。 Karianne Bergさんのエッセイ「コードを読む」 このエッセイでは、エンジニアが他のエンジニアや自分の過去のコードを読むことの重要性について述べられています。他のエンジニアが書いた読みやすいコードを読むことで、自身の成長につながると強調されています。 また、過去に自分が書いたコードを読み返すことで、スキルの向上を確認でき、さらなるやる気が湧くとも述べられています。 このエッセイを読んで、当時は次のことを毎日欠かさずやっていました。 自分が関わるプロダクトのリポジトリの全てのプルリクエストに目を通す チームメンバーが作成したプルリクエストを読むことで、チームメンバーがどのようなコードを書いているのかを知ることができ、自分のスキルアップにつながると考えていました。 現在、Rustらしい書き方と読みやすいコードの書き方が分からない時、スター数が多いライブラリのソースコードを読んで、Rustらしい書き方を日々学んでいます。 この本から学んだこと 上記のエッセイを読んで、当時悩んでいた自分がどうすればいいのかを思いつくきっかけになりました。 ぐずぐず悩んでなにも動かないより、少しだけでもいいから知らなかったことを潰していく・挑戦していくことの大切さを学べたと思います。 キャリアやこれから何を学ぶ？と悩んだときは、今でもこの本を読み直します。 また、定期的に書店へ行って、素晴らしい書籍を探しています。 Clean Coder プロフェッショナルプログラマへの道 Clean Coder プロフェッショナルプログラマへの道 作者: Robert C.Martin KADOKAWA Amazon 2024年4月にファインディへ入社して、 Findy Tools の開発をしている林です。 私からは Clean Coderプロフェッショナルプログラマへの道 という本を紹介します。 私はエンジニアとして働き始めて2年目に本書を読みましたが、自身が業務の中で感じていた課題とその解決策のヒントの多くを得られました。 そして、この本の考え方が日々の業務に大きな影響を与えてくれたと考えています。 本書は、タイトルの通り「プロフェッショナルプログラマ」になるための技術的なスキルだけでなく、コミュニケーション力やエンジニアリングに対する向き合い方などのソフトスキルに焦点を当てて紹介されています。 ここでいう「プロフェッショナル」とは、「責任を取る」姿勢を持つことと定義されています。これは、エンジニアが求められた仕様を実現するためのコードを書くだけでなく、最終的にビジネスの成果を達成する責任を果たすことを意味します。 本書では、エンジニアが直面しやすい具体的な課題とその解決策が解説されています。例えば： プロダクトにバグが生じる テスト駆動開発（TDD）や、効果的なテスト戦略の構築が重要。 無理な要求や納期に間に合わない場合 明確に「ノー」と言い、仕様を交渉することがプロの姿勢。 精度の高い見積もりができない PERTやプランニングポーカーなどで具体的な数値を挙げ、現実的な見積もりをする。 チームワークの問題 プログラミングは一人で完結するものではなく、他者との円滑なコミュニケーションが不可欠。 特に印象に残ったのは、本書の第2章にある無理な要求に対して「ノー」と言うことの重要性です。 私は本書を読む前、プロフェッショナルなエンジニアとは、どんな要求にも対応する技術力を持つべきだと考えていました。 しかし、本書を読んで、「できないことは断る」ということもプロフェッショナルの責務であることに気づかされました。 さらに、「試しにやってみる」という曖昧な言葉も問題視されています。 このフレーズは、調査の時間を指しているのか、あるいは実装を試すことを意味しているのかが不明瞭で、誤解を招きかねません。 私自身、何気なく使っていた言葉なのでより明確に何が問題で何をするのかを具体的に言うようにしました。 本書の内容は一朝一夕で身につくものではありませんが、私は業務で困ったときに何度も読み返しています。 特に、最近エンジニアになった方や「プロフェッショナルとは何か？」と漠然としている方にとって、強い指針となる一冊です。ぜひ手に取ってみてください。 まとめ いかがでしたでしょうか？ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。こんばんは。 開発生産性の可視化・分析をサポートする Findy Team+ 開発のフロントエンド リードをしている @shoota です。 先日、 END が 【フルスタックエンジニアへの道！】React と TypeScript の修行をした話 というタイトルで、フルスタックエンジニアを目指すためのフロントエンドの修行の記事を投稿いたしました。 こちらの記事では React / TypeScript において個人学習程度のレベルにあった END が、機能開発を自走可能になるまでの内容が書かれています。 そこで本記事では、END の成長と挑戦をサポートし、実際に指導にあたった私がメンター視点での話をいたします。 育成のはじまり 下準備 ゴール設定 助走をしてもらう 実践 育成の方針と実践 トレードオフ 3 ヶ月の成果と分析 プルリクエストの可視化 メンティーの分析 メンターの分析 所感とまとめ 成長したいエンジニアを探しています！！ 育成のはじまり Findy Team+の開発メンバーはバックエンド・フロントエンドにそれぞれ主軸を置きつつ、多くのメンバーがその垣根を超えた貢献ができることを目指しています。 そのなかでバックエンドを主軸としていた END がフロントエンド領域に集中して挑戦したいという話が持ち上がりました。 フロントエンドメンバーの比率が少なく、「片手間ではなく集中して挑戦する」という決意もあり、自分としても前向きに指導担当をさせてもらいました。 下準備 ゴール設定 急に育成をするとなっても何となく始めてしまうとちゃんと成長できているのか、育成をサポートできているのかどうかがわからなくなります。 まずはじめに私がしたのは、エンジニアリングマネージャー(EM) とのすり合わせでした。 具体的には次のような質問から「どのくらいの時間でどこまでできるようになるのか？」をある程度の幅で決めていきました。 メンティーが目指すゴールはどのレベルか？ EM の期待するゴールはどのレベルか？ どれくらいの育成期間をとるか？ ゴールのレベルもざっくりと 3 段階を想定しました。 基本はバックエンドを主軸としつつも、状況にあわせてフロントエンドも書けるようになりたい バックエンド・フロントエンドに分け隔てなく両輪で活動できるようになりたい フロントエンド主軸に移りたい 結果 2 番目のレベルをイメージしながら、 「フルスタックな動きをキャリアの目標として想定しつつ、まずはフロントエンドを自走できるレベル」 を 「とりあえず 3 ヶ月」 で目指してみようとなりました。 助走をしてもらう もともと個人で React は書いたことがあるといっても、Team+の膨大なコードの前に立つとなかなかどこから手を付けたらよいかと不安になるものです。 なのでまずはメンティーの心の準備体操として、フロントエンドの考え方をまとめた読み物を書きました。 読み物 MVC アーキテクチャやオブジェクト指向といった馴染みの概念と照らしながら、どんなパラダイム・シフトが待っているのかをブログのように書いておきました。 このほか、これまでにもフロントエンドの設計や React の思想などに関する社内記事を書いていたので、それらも合わせて共有しておきました。 実践 育成の方針と実践 自分で調べたり考えたりしたことがいちばん身につくので、基本的には寄り添い過ぎず、私のなかでいくつかのゲートを設けて見守ることを計画しました。 私はこれまでもジュニア層のフロントエンドエンジニアの育成経験があったので、これらのゲートが多くの人がぶつかる壁であることを知っており、これをクリアできてそうかをみながらサポートの強弱をつけていく算段です。 成長ステップ React に Props を渡して単純な HTML を出力するコンポーネントを書ける コンポーネントを組み合わせた大きなコンポーネントを型を含めて書ける ユーザーインタラクションのハンドラーを純粋な関数として書ける バックエンド API との通信インターフェースを理解し、コード生成ができる データとコンポーネント間を TypeScript をつかって型安全かつ整合してつなぐことができる 多くの場合に Step. 3 と Step. 5 がよく詰まるポイントで、ここを乗り切るための知識や理解のための伏線を張っていくように、ドキュメントなどをプルリクエストや Slack でどんどん渡していきました。 特に Step. 5 がジュニア層の鬼門で、それまでの React Component の積み上げと API の型定義を同時に整理しなければならないため、データとビジュアルの責務分離、そのための関数と型の設計などで苦戦します。 渡した資料の中で、誤読しやすいものや前提知識が多く必要なものは口頭で補足するなどしながら、これまでの理解度を測って次のステップに必要なものを選んでいくようにしました。 こうして Step. 5 を乗り越えるための理解が積み上がるように進路補正をしていきました。 トレードオフ このように挑戦するメンティー側にはいろいろな壁を超えるための頑張りが必要になってきますが、一方でサポートするメンター側も、自分のパフォーマンスを維持し続けるのが難しくなってきます。 どれくらいの厚みのサポートが必要かは個々人によって違いますが、少なくともメンターの 20%くらいはサポートに力を注ぎたいものです。 Findy では Findy Team+ を使って自分のパフォーマンスを計測する習慣がありますが、私は 育成に際してこの数値がある程度は落ち込むことを覚悟 の上で、その落ち込み幅をできるだけ小さくすることにも挑戦していました。 私のマネージャーにもこの想定の落ち込み幅のすり合わせをし、育成と自己パフォーマンスのバランスをとっていることを 1on1 などで話しています。 パフォーマンスを可視化することで数値の変動にきちんと理由付けをできるのが Findy Team+ を使っていく最大の利点です。 3 ヶ月の成果と分析 プルリクエストの可視化 実際には想定よりも成長速度が安定していたので最初の 2 ヶ月弱で設定したゴールに到達しそうでしたが、とりあえずはそのまま 3 ヶ月間みっちりと進めてみました。 難易度が高すぎないタスクを中心に実施してもらってはいたものの、最終的にフロントエンドへの プルリクエスト数は私とほぼ同等かそれ以上 が出せるようになっていました。 Team+のグラフで可視化してみると次のようになりました。 青が私、オレンジがEND メンティーの分析 先ほどのメンター（私）とメンティー（END）の両方の PR 作成数でした。これをメンティー（END）だけに絞ると、中盤に数値の谷があります。 実はこれが狙い通りで、前述の想定した Step と期間を照らし合わせることで成長の過程が見えてくるようになります。 育成方針とパフォーマンスの谷 はじめは単純な HTML 合成のための Component 作成（Step. 1, 2）で伸びていく数値が、ユーザーインタラクションの実装 (Step. 3) が始まると徐々に鈍化していきます。 インタラクションの実装に慣れてくるとバックエンド API との連動 (Step. 4) のイメージもつきやすきなってきますが、いざこれらをつなごうとすると考慮することが一気に増えるため、数値が下がっています。 そしてこの鬼門を乗り越えると、またぐんぐんと順調に伸びていく事がわかります。 メンターの分析 次に自分がメンターをしている期間にどれくらいのパフォーマンス影響があったかを見てみます。 同じ期間での私の PR 作成数をグラフにすると、何ともつまらないくらいに変化が少ないグラフになりました。 メンターのPR作成数 しかしこれには秘密があります。 まずメンターを始めてからメンティーのプルリクエストはすべてレビューしており、すぐに自分のパフォーマンスに対する影響を感じていました。 具体的には次のようなことを、プルリクエストがあがるごとに都度実施していたためです。 設計意図を汲み取りにくい構造になっている部分を読み解く 厳密でない型定義によって型チェックをすり抜けている箇所がないかチェックする 指摘内容とともに実装サンプルを書いたり、その理由を示すリファレンスを探して提示する。 そこでマネージャーと相談して、自身のプルリクエスト作成数が 4 以下にならないように水準を維持していくことを宣言し、レビューの濃度を調整していったのです。 （それまでの私の平均プルリクエスト作成数は 5.6〜5.8 程度でした） 「そこまで狙い通りにプルリクエスト数を調整できるものか？」と思われるかもしれません。 しかし自分のパフォーマンスを落としては開発が進まず、また一方でメンバーの成長にも投資しなければ全体の生産性が高まりません。この 実績と投資のバランスを自分の数値を軸にする ことで全体最適を図っていったのです。 もっと自分がプルリクエストを書ける状況でもその分は育成への投資に使いました。こうしてマネージャーと合意したパフォーマンスを維持しながら、最大限の育成を進めるのは意外と難しくありません。 所感とまとめ 今回の育成期間の全体を通して、おおむね計画どおりに進めることができました。もちろんメンティーのポテンシャルの高さやメンターの経験もあってのことですが、次のような点が成功への道しるべになったと思います。 メンティーのゴール設定を 技術リードとエンジニアリングマネージャーの両者 で合意してから開始したこと 適切なステップとぶつかる壁を用意したこと 成長のための「適度なストレス」を感じ続けられるようにすることで、モチベーションを維持 最も大きな谷を超えるための準備としてサポートを意識した メンターのパフォーマンスへの影響とその保証ラインも適切に設定し、 そのパフォーマンスラインを指標として サポートの厚みを可変できるようにしたこと これらによって、開始時に設定したゴールを超えて爆速で成長してもらえました。 卒業の様子 最後に、「メンティーの分析」であげた END のプルリクエスト作成数グラフをもう一度みてみると、非常にゆるやかなダニングクルーガー曲線になっており、非常に興味深いなと思いました。 成長したいエンジニアを探しています！！ バックエンド主軸のあなたでもフロントエンド開発を自走できるレベルまで成長することが出来ます。 もちろんフロントエンドが大好きなあなたも、リードエンジニアを目指してスキルアップできることでしょう！ ぜひ、ご応募お待ちしております (∩´∀ ｀)∩ herp.careers

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 既に皆さんも御存知かと思いますが、弊社では開発生産性の向上に対して非常に力を入れています。 以前公開した↓の記事で、弊社の高い開発生産性を支えている取り組み、技術についてお話させていただきました。 tech.findy.co.jp ありがたいことに、この記事を多くの方に読んでいただき反響をいただいております。 そこで今回は、↑の記事でも紹介されている「Pull requestの粒度」について更に深堀りしてお話しようと思います。 Pull requestの粒度は、弊社にJOINしたら最初に必ず覚えてもらう最重要テクニックの1つです。 それでは見ていきましょう！ 大きなPull request 適切な粒度とは 適切な粒度を維持するために タスク分解 迷ったら小さく レビューを最優先にする CI高速化 feature flag運用 topic branch運用 まとめ 大きなPull request Pull requestのレビュー依頼が飛んできて確認したら、大きなPull requestでブラウザをそっと閉じた経験がある方は少なくないと思います。 大きなPull requestにおけるデメリットは数多く存在します。 パッと思いつくデメリットを列挙してみます。心当たりがある読者の方もいるのではないでしょうか？ topic branchの生存期間が長くなり、結果的にbase branchとの差分が大きくなりconflictの発生確率が高くなる 変更内容が多岐に渡るため、問題発生時の原因特定に時間が掛かってしまう revert時に余計な内容までrevertされてしまう レビューの質が落ちる レビュワーが見るべき範囲が広くなるため、認知負荷が大きくなる あとで見とこ、、、となりがち 結果的にtopic branchの生存期間が長くなる base branchとの差分が大きくなる conflictの発生確率が高くなる 指摘内容が増え、結果的に手戻りが増える etc このようにデメリットは数多く存在します。システム開発において大きなPull requestの存在は、円滑な開発を阻害する要因となるでしょう。 では「大きなPull request」とは具体的にどんなPull requestのことを指しているのでしょうか？ 適切な粒度とは ここでサイズと粒度の違いを説明する必要が出てきます。 そのPull requestが1つのことに注力できているかどうかが、粒度を語る上で非常に重要なポイントになります。 Pull requestのサイズとは、コードの変更行数や変更ファイル数のことを指します。 しかし、コードの行数や変更ファイル数が多かったとしても、変更内容が一意であれば問題ないはずです。 例えば、関数名を変更して一括置換した場合を例に挙げましょう。変更ファイル数は多くなりますが、変更内容は一意です。 こういったケースの場合、Pull requestの概要欄に一括置換した旨を記載しておけば、変更内容を全て確認せずとも変更後の関数名をレビューし、CIが通ればマージ出来るはずです。 一方、Pull requestの粒度とは、コードの変更内容のことを指します。 例えば、変更ファイル数が少ない一方、データ取得・データ加工・描画処理を同じPull requestで対応した場合を例に挙げて考えてみましょう。 この場合、それぞれの処理は全く異なる内容です。しかし同じPull request内で対応してしまったため、変更内容全てを一度にレビューする必要があり、レビュワーに対する認知負荷が大きくなってしまいます。 極論ですが、たとえ変更行数が1万行を超えていたとしても、変更内容が一意であれば問題は無いと考えています。 逆に変更行数が20行程度の不具合修正の中に「ついでにリファクタ」した内容が含まれていた場合、粒度が大きいと判断しPull requestを分割すべきなのです。 なぜならば、もし不具合修正に失敗していてrevertしようとした際に、ついでにリファクタした内容もrevertされてしまうからです。こういったケースの場合、リファクタをしたPull requestを別で作成します。 つまり本質はコードの変更行数や変更ファイル数ではなく、変更内容そのものにあるということを理解できたかと思います。 粒度が適切であれば、1行だけの修正でも、1万行の修正でも問題ありません。 10のプルリクを1回レビューするよりも、1のプルリクを10回レビューする方が、作成者、レビュワー共に負担が少ないのです。 適切な粒度を維持するために タスク分解 Pull requestの粒度について完全に理解したので、これからは適切な粒度でPull requestを作るぞ！と思い立っても、すぐに実現させるのは難しいものです。 理解はしているけど、やってみるとやることがどんどん増えていき、結果的にPull requestが肥大化しがちです。 それを解決するのがタスク分解です。概要は↓のページを参照してください。 tech.findy.co.jp タスク分解に関しても、別の機会で詳細にお話できればと思います。 迷ったら小さく とは言え、最初のうちは粒度に対して悩むことが出てくると思います。 もっと作り込んでからレビュー依頼を出す？それとも今の段階で出す？でも修正内容が小さすぎないか？などといった葛藤は自分にも経験があります。 そういう時は、より小さい粒度の段階でレビュー依頼を出すことをオススメします。レビューのやり取りの中で粒度に対する議論を行い、そこで認識を合わせればOKです。 Pull requestを大きく作って後から分解するより、小さく作って後から修正内容を追加する方が圧倒的に楽だからです。 まずは小さすぎても良いので小さく作り、そこから肉付けしていくようなイメージでPull requestを作成していくと良いでしょう。 レビューを最優先にする Pull requestの粒度が小さくなった場合、レビュー依頼に対して最優先で取り組む必要があります。 なぜならば、マージしないと次の修正に着手出来ない場合に、レビューがボトルネックになり結果的に開発スピードが遅くなってしまうからです。 自分の作業を一時中断して、10分程度レビューして自分の作業に戻るとコンテキストスイッチを戻すのが非常に難しいと思います。 でも心配しなくてよいです。Pull requestの粒度が適切であれば、レビュワーが確認する内容も小さくなるためレビューに掛かる時間が短縮されます。 そのため、自分の作業を一時中断することになったとしても、すぐまた自分の作業に戻ることができるようになります。 弊社では1つのPull requestのレビューに掛ける時間はほんの数分程度となっています。1分以内で終わることもあります。 粒度が適切なPull requestが当たり前となれば、レビューを最優先にする習慣、文化が組織に根付くはずです。 CI高速化 粒度が小さくなってくると、当然ながら作成されるPull requestの数が増えます。つまりCIの実行回数も比例して増えていきます。 CIの実行回数が増えた状態で実行速度が遅いと、逆に開発効率が落ちてしまいます。CIが遅いからPull requestの粒度も大きくなってしまうといったケースも見たことがあります。こうなってしまうと本末転倒です。 そこでCIの高速化も同時に進めた方が良いでしょう。詳細はこの記事では割愛しますが、↓の別記事を参考にしてみてください。 tech.findy.co.jp feature flag運用 Pull requestの粒度は適切にしたいが、本番環境には影響を出したくない。というパターンはfeature flagを使うと良いでしょう。 ローカル環境でのみ実行されるようなコードにしておいて、その状態を維持しつつbase branchにマージし続けます。本番公開OKのタイミングでfeature flagを解除し、本番環境に反映します。 feature flagの運用方法はSaaSを使う、ライブラリを使うなどの方法がありますが、今回は一番カンタンに導入できる方法の、コード上にフラグを埋め込んで切り替える手法を紹介します。 実際にコードの例を見てみましょう。 export const SampleComponent = () => { const isEnabledNewLabel = process .env.FEATURE_NEW_LABEL === 'true' ; return ( < div > { isEnabledNewLabel && < span > NEW </ span > } < span >Sample</ span > </ div > ); } ; 環境変数に埋め込まれている FEATURE_NEW_LABEL の値によって、 NEW の表示を切り替える単純なcomponentです。 この仕組みにより、ローカル環境の環境変数をtrue、本番環境の環境変数をfalseにすることで、本番環境に影響を与えずに新機能の開発を進めることが可能になります。 開発が完了して本番環境に反映する際には、本番環境の環境変数をtrueにすることで新機能を公開できます。何かしらの問題が発生した場合、本番環境の環境変数をfalseに戻すことで、新機能を非公開に変更可能です。 本番環境で問題が起きなければ、環境変数のフラグとコード上の分岐を削除します。 この手法はfeature flagの管理が煩雑になったり、コード内の分岐やテストケースが増えるといったデメリットもありますが、Pull requestの粒度を適切に維持するためには非常に有効な手段です。 本番環境に影響を出さずに、Pull requestの粒度を適切に維持し続け、スピード感を持って開発する手段の１つとして活用してみてください。 topic branch運用 様々な事情によってfeature flagを使えない、使いたくない場合の手段として、topic branch運用を紹介します。 base branchからtopic branchを切って、そこから更にdevelop branchを切ります。develop branchからtopic branchへのPull requestを作成し、そこで粒度を維持しつつレビューをします。 本番反映OKのタイミングでtopic branchからbase branchへのPull requestを作成し、マージします。このタイミングでのレビューは必要最低限でOKです。なぜなら、develop branchからtopic branchへのPull requestでレビューしているからです。 この手法により、base branchにはリリースのタイミングまで変更内容が反映されません。そのため本番環境への影響を与えず、Pull requestの粒度を適切に維持し続けることが可能になります。 定期的にbase branchからtopic branchへ変更をmergeしておくのがポイントです。topic branchの生存期間が長くなるので、base branchとの差分が大きくなりconflictが発生しやすくなるからです。最低でも1日1回はbase branchの修正内容を取り込んでおくと良いでしょう。 まとめ いかがでしたでしょうか？ 粒度を適切に維持することで、レビュワー、レビュイーの両者に対して優しいPull requestを作成し続けることができます。 弊社では最重要テクニックの1つとしていますが、比較的カンタンに覚えることができ、コツさえ掴めば誰でも実践できる内容です。 是非、皆さんも試してみてください。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは、ファインディでFindy Team+（以下Team+）を開発しているEND（ @aiandrox ）です。 普段はバックエンドの開発をメインで担当しているのですが、3ヶ月間フロントエンドの開発に挑戦する機会がありました。短い期間でしたが、フロントエンドテックリードから直接指導してもらいながら実装をすることで、フロントエンドの開発を一人でできるくらいに慣れることができました。 今回は、その経験と学びについて書いていきます。 フロントエンドに挑戦する前の自分について フロントエンドに挑戦することになった経緯 フロントエンドを学ぶ上で助けられたこと フロントエンドのノウハウが溜まった記事の充実 開発ツールが揃っている テックリードとマンツーマンでタスクをやっていく react.devの輪読会 つまづいた点 タスク粒度を適切に分割すること Team+のフロントエンドの責務の考え方 TypeScriptで慣れる必要があったこと 3ヶ月の挑戦の成果 自身の伸びしろ おわりに フロントエンドに挑戦する前の自分について もともとはバックエンド（Ruby on Rails）の開発をメインでしていました。 前職では特にバックエンドとフロントエンドが分かれておらず、Rails View / CoffeeScript / FlowType / jQuery / Reactの混在したフロントエンドを触っていました。また、個人開発でReact / TypeScriptを触ったことはあったものの、あくまでも動くことを重視していたため、アーキテクチャの意識はあまりしていませんでした。 Team+のフロントエンドでは、前年に修正プルリクをいくつか出したので、アーキテクチャはなんとなく把握していました。しかし、既存の実装を踏襲したまま一部を修正する程度だったので、新規でComponentを作ったことはありませんでした。 フロントエンドに挑戦することになった経緯 もともと個人開発などもしていたので、フロントエンドへの興味もありました。将来的にはフルスタックエンジニアとしてスキルを広げたいという思いもありましたが、まずはバックエンドの技術を身に付けることを優先していました。そんな中、「フロントエンドの手が足りないんだけどやってみない？」という提案がありました。 いい機会！ということで、「やりたいです〜」「テックリードと一緒にやってもらおうと思ってます」「やったー」とトントン拍子で進んでいきました。 フロントエンドを学ぶ上で助けられたこと フロントエンドに挑戦するにあたり、以下のサポートがあることにより、スムーズに実装を進めることができました。 フロントエンドのノウハウが溜まった記事の充実 社内記事に「フロントエンドを書くときに何を考えているか、どうしているか」というものがあり、これを参考にできました。「データ層を扱うものはデータ層の責務に閉じ込め、プレゼンテーション層は見た目に注力する。つまり、Pureな Presentational Componentは原則としてロジックを持ってはならない」といった基本的な考え方と、実際に画面を作るときの作業工程を書いていたので、とても役立ちました。 基準の考え方があったので、迷ったときにこれに立ち返ったり、「この場合はどうなのか？」と具体的に質問することができました。 開発ツールが揃っている 開発中はJavaScriptの統合テストツールWallaby.jsを使用していたので、デバッグがスムーズに進み、開発作業が非常に効率的になりました。 tech.findy.co.jp また、CIによって一定の品質が自動的に担保されるので、レビュー前に自分で気付けることも多かったです。ESLintは実装に寄ってくれている感じがあり、hooksの依存などを自動で補完してくれるため初学者としては安心できました。 テックリードとマンツーマンでタスクをやっていく テックリードとは同じチームなので、朝会で進捗の共有をするとき悩みポイントを共有したりしていました。また、実装方針に悩んだときは分報チャンネルに投げて拾ってもらったり、都度ペアプロなどでサポートしてもらいました。 また、自分が作成したプルリクに関してはすべて見てもらっていたので、私の理解度を把握されていました。そのため、プルリクの実装についての指摘や、理解度が浅そうなところなどがあったタイミングで呼び出していただきました。都度口頭で説明されたり自分からも「この理解で合ってます？」と壁打ちすることで、具体的な話から理解度を高めることができました。 ※「体育館裏」は一見怖そうに見えるかもしれませんが、怒られたりすることはありません。コワクナイヨ react.devの輪読会 もともと、フロントエンドをメインとするメンバーでReact公式の Learn React の輪読会を行っていたので、自分も途中から参加するようになりました。 書かれている文章だけだと言葉や概念が難しかったのですが、輪読会では具体的な解説があったりわからない点を質問できたりしたので、実践を理論で補強できました。これにより、プルリクで指摘された内容について「つまりそういうことなのか」と理解できるようになりました。 つまづいた点 タスク粒度を適切に分割すること バックエンドに関しては、技術的にもドメイン的にも慣れているので、1つのクラスごとにプルリクを作成することができていました。しかし、フロントエンドに関しては、ローカルの画面で動く状態まで実装すると大きすぎるプルリクになることがありました。 これを解消するために、1つずつ実装した箇所のテストを書くことで安心してプルリクを出すことができました。バックエンドでは当然のように考えていたことでしたが、フロントエンドではつい画面でのデバッグをしようとする心が働いてしまっていたことを自覚しました。 また、最初はComponentを分割して実装するという意味をあまり理解できておらず、中途半端な状態で1プルリクにしたりもしていました。 Team+のフロントエンドの責務の考え方 フロントエンドの設計は以下のようになっています。 コンポーネント名 カスタムフック名 扱うデータ Page Component Params Hook ブラウザURL Container Component Facade Hook API や ストレージ等 Presentational Component Presenter Hook フォーム Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog この思想をなんとなく頭に入れていたものの、実際に実装している途中で、「この記述はFacadeで書くべきなのか、Presenterで書くべきなのか」と迷うことがありました。 例えば、GAトラッキングの記述を最初はFacadeに書いていたのですが、「GAの実行はUIのクリックアクションをトリガーとするので、Presenterに書くのが適切」といったフィードバックを受けました。propsで渡された関数をPresenterでwrapするといったやり方が、最初は選択肢になかったので、新鮮に感じました。 また、ContainerからContainerを呼んでいる場合もあり、どのようにコンポーネントを分割するべきか迷う場面もありました。画面内のAPIを基準にFacadeを分割し、それに応じてContainerを組み立てていくとわかりやすかったです。 TypeScriptで慣れる必要があったこと 今まで書いてきたRuby / Railsと比較して、TypeScriptには型があるというのが大きな違いですが、個人的にはその堅牢さの中でJavaScriptの関数などを使いこなすのが難しかったです。 例えば、以下のような点です。 null や undefined だけでなく、 0 もfalsyな値になる 配列に対して find を実行すると戻り値が undefined になりうるため、必ず値が存在する場合に find を使うと、型と実態が合わなくなってしまう 3ヶ月の挑戦の成果 この機会に、1つの新機能をテックリードと2人で分担して開発しました。私は、以下のような一覧画面と分析画面をそれぞれ2画面ずつ担当しました。 一覧画面 分析画面 また、安定してプルリクを作成することもできるようになりました。 この3ヶ月を通して、React全体やTeam+のフロントエンドでの設計思想を学び、コンポーネントの責務の分離や状態管理の方法について、実践を通して理解することができました。これにより、他のエンジニアへのレビューもある程度自信を持って行えるレベルになりました。 改めて感じたのは、ただ動けばいいのではなく、Reactで可読性・設計を考慮したコードを書くのは難しいということでした。記述方法の自由度が高い分、意図を設計として乗せる必要がある（テックリードからの受け売り）というのを実感しました。 自身の伸びしろ 今回の挑戦では表示するデータを取得するものばかりだったので、フォーム処理やデータの更新などに今後は積極的に挑戦したいです。 また、react.devの輪読会や共通コンポーネントを変更しようとしたときに、自分の実力不足を感じました。TypeScriptの知識不足や型の伝播を読み解けなかったり、既存の実装の変更対象がわかっても修正方法がわからない、概念はわかるが名称を知らない、などの伸びしろを見つけました。これに関しては、実際にやってみたり他の人のプルリクを参考に考えることを積み重ねていくことで、自身の糧にしていくつもりです。 ライブラリに関する理解もまだ浅いので、今後は開発にくわえて、フロントエンド環境のメンテナンスをできるような知識も増やしていきたいです。 おわりに このように、ファインディではフルスタックを目指す環境で働くことができます。また、現在ファインディでは共に働く仲間を募集中です。興味のある方は、こちらのページからぜひどうぞ！ herp.careers

こんにちは。 2024/7/1 からファインディに入社した斎藤です。 ファインディでは、 Findy Team+ という、エンジニア組織の開発生産性を可視化し、開発チームやエンジニアリングメンバーのパフォーマンスを最大化するためのサービスの開発に携わっています。 今回は、私が入社初月からさくさくアウトプットできた理由についてご紹介します！ 入社初月からプルリク1日4件出せました ファインディでは1日あたり4件プルリクを作成するというのを1つの指標としています。 入社直後は慣れるまでは結構厳しい指標だなと思っていたのですが、この記事で紹介する様々な仕組みのサポートもあり気がついたら初月から達成できていました。 中途入社あるあるだと思いますが、入社直後になかなか成果が出せなくてプレッシャーを感じてしまうということがあります。 簡単なタスク中心ではありますが、初月から貢献しているという実感が持てたので心理的にもたくさんプルリクが出せて良かったなと感じています。 ※1日4件という数値はあくまでアウトプット量の参考です。 闇雲にプルリクをたくさん出せばいいということではありません。アウトプットをプロダクトの成果につなげることが大切です。 入社1ヶ月目プルリク数 1日平均4.6件!! 入社2ヶ月目のプルリク数 1日平均5.7件!! 入社初月からさくさくアウトプットできた理由 Good First Issueの粒度が適切であったこと 新しく参画した人向けのIssueとしてGood First Issueを準備する文化がファインディにはありますが、粒度として難しすぎず簡単に終わりすぎず良い粒度で取り組めるタスクになっていました。 その中で複数箇所に同じ修正を加える作業があり、それをなるべく速く終わらせる意識で対応しました。 例：同じリファクタリングを複数ファイルに渡って対応するタスク ある処理を別ファイルに移動するというリファクタリング 対応すべきファイル名が列挙されていてわかりやすい スムーズな開発を支えるレビューとCI/CDがあること 入社前は開発生産性を可視化するプロダクトを開発しているくらいなので、さぞかし開発がしやすいんだろうなーと思っていましたが、 入社後はその想像を超えて開発がしやすい環境だなと感じました。 特に次のことが要因で開発をサクサク進めることができています。 レビューが速い！とにかく速い！ 1PRあたりオープンからレビューまでの平均時間：3.3h プルリクの粒度を小さくして出す文化が根付いているためレビュー負荷が少ない リリース作業が楽で、時間が取られない リリースPR作成、e2eテストが自動化されていて基本的にマージボタンを押すだけで完了できる この辺りは他の方の 入社エントリー で詳しく紹介されているのでもしよかったら見てみてください。 メンターと密にコミュニケーション メンターとの1on1で不慣れな点を解消しつつ、やることを明確に設定していただけたことで開発に集中できました。 1on1で印象的だったのは一度に多くの情報をインプットしないようにしていただけたことです。 入社後に必要な情報を適切なタイミングで適切な量に分けてインプットしていただけたので、ストレスなく業務に慣れることができました。 適切な頻度(私の場合は週1回)でメンターとの1on1があり、そこで課題を解消できた 1on1以外でも都度メンターに質問して迅速に疑問点を解消でき、開発に集中できた ふりかえりをして日々改善が行われる 私のチームでは2週間に1回の頻度でFindy Team+の「KPTふりかえり」機能を使ってふりかえりを行っています。 そこで出た課題に対する打ち手を議論して改善に繋げる取り組みがとてもいいなと思いました。 ふりかえりで出たアクションはまずは試しにやってみましょうという感じですぐに実行されます。 アクションがすぐに実行されるというスピード感がとてもいいなと思いました。 そしてやってみたアクションについてどうだったかも合わせて次のふりかえりで確認しているので 継続的に改善が行われる仕組みになっています。 新しく参画した私が感じた課題はすでに改善のアクションが進んでいるという状態でした。 (なので課題が思いつかないという課題があります。。。) このように現状に満足せず、より良くするにはどうしたら良いかを全員で考え行動していることが高い開発生産性に繋がっているんだろうなと感じました。 挙げられたProblemに対してTryを設定 全てのコードベースを把握していなくても既存を壊さない仕組み またテストカバレッジが99%で、自分の改修で他へ影響があった場合にはちゃんとテストが落ちるようになっています。 このように、自分の開発に集中できる仕組みが整っているため、 最初から全てを把握していなくても、安全に開発を進めることができます。 なので、全くプロダクトの知識がない入社直後でも 自分の担当作業に集中できるので、サクサクプルリクを出すことができました。 不明点は遠慮せずにすぐに聞いたり相談できる 前述したメンターとの1on1もありますが、定例以外でも不明点はすぐにSlackのメッセージやハドルで聞くことが推奨されています。 オンボーディング資料にも「不明点は都度Slackやハドル、(出社している場合は)対面で確認しましょう！」と明記されており、みなさん快く応じてくれます！ また、ファインディではSlackでtimes(分報)チャンネルを各自持っています。 自分のtimesで疑問をつぶやくといろんな人が助けにきてくれる文化があるので助かっています！ 今後の抱負 ファインディのバリューであり、自分の強みでもある「スピード」を大切に爆速で開発をやっていきたいです！ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

ファインディ株式会社でフロントエンドのリードをしております 新福( @puku0x )です。 GitHub Actionsは、CI/CD以外にも様々な業務の効率化に役立ちます。 この記事では、弊社で実施しているGitHub Actionsを使った自動化について紹介します。 自動化 担当者アサイン ラベル設定 リリース QAチェック項目の抽出 定期実行 まとめ 自動化 担当者アサイン 開発フローの中では、Pull requestを作ってからレビューに出すまでにいくつかのタスクを行うことがあります。 弊社では、Pull requestの作成者がAssignee（担当者）となる場合が多いため、↓こちらのActionを用いてアサインの自動化をしています。 github.com - uses : kentaro-m/auto-assign-action@v2.0.0 with : repo-token : ${{ secrets.GITHUB_TOKEN }} addAssignees : author runOnDraft : true Assigneeのみ自動化しているのは、レビューに出すタイミングをPull requestの作成者側で制御したかったためです。 レビュアーについては、GitHubの標準機能でレビュー用のGitHubチームを作ってランダムアサインするようにしています。 ラベル設定 弊社では、Pull requestをラベルを用いて管理しているチームもあります。 付与するラベルについては、セマンティックバージョニングと相性の良いものが用いられることが多いです。 GitHub - azu/github-label-setup: 📦 Setup GitHub label without configuration. ラベル設定の自動化は、公式のActionがありますので比較的導入しやすいでしょう。 github.com actions/labelerは、最近の更新でブランチ名を基にラベルを設定する機能が追加されました。 この例では、ブランチ名の先頭が feat や fix 等であった場合に対応するラベルを付与するようにしています。 'Type: Feature' : - head-branch : [ '^feat' ] 'Type: Bug' : - head-branch : [ '^fix' , '^bug' ] モノレポの場合、ファイルのパスに対応するラベルを設定すると、どのプロジェクトに影響するか判断しやすくなります。 'Scope: App1' : - changed-files : - any-glob-to-any-file : - apps/app1/**/* - libs/app1/**/* 'Scope: App2' : - changed-files : - any-glob-to-any-file : - apps/app2/**/* - libs/app2/**/* actions/labelerは、Pull requestのタイトルを基にしたラベル設定には、2024年9月現在だと対応していないようです。 その場合は、手動でGitHubのAPIを呼ぶシェルを組む必要があります。 run : | pr_title=$(curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \ -H "Accept: application/vnd.github.v3+json" \ "https://api.github.com/repos/Findy/***/pulls/${{ github.event.pull_request.number }}" \ | jq -r '.title' ) if [[ $pr_title =~ ^feat ]] ; then pr_type='Feature' fi curl -X POST -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \ -H "Accept: application/vnd.github.v3+json" -d '{"labels": ["Type: '"$pr_type"'"]}' \ "https://api.github.com/repos/Findy/***/issues/${{ github.event.pull_request.number }}/labels" いつか公式のActionにも欲しいですね！ リリース 手順の多いリリース作業も、弊社では自動化を取り入れて負担を減らしています。 ここではフロントエンド系のリポジトリに採用されているものを紹介します。 バージョニング用ワークフローを実行 バージョニング用Pull requestが自動生成される バージョニング用Pull requestをマージ バージョニング用Pull requestのマージを起点にリリース用Pull requestが自動生成される （プロダクトによってはここでStaging環境へのデプロイも実行されます） リリース用Pull requestをレビュー後、マージ リリース用Pull requestのマージを起点に本番デプロイ 開発者は「ワークフローの起動」と「自動生成されるPull requestのマージ×2」というシンプルな手順で本番デプロイまでできるようになります。 また、 Conventional Commits に準拠したコミットメッセージを採用しており、自動バージョニングやリリースノートの自動生成といった恩恵も得られています。 デプロイ頻度はFour Keysの指標にも入っていることから、チームの健康状態を知る手掛かりになります。可能な限り高い頻度でデプロイできるよう、仕組みはしっかりと整備していきましょう💪 参考: https://dev.to/puku0x/github-actions-1mi5 QAチェック項目の抽出 リリースの際に、QA担当者がチェックすべき項目をPull requestの履歴から自動抽出しているチームもあります。 まず、 .github/PULL_REQUEST_TEMPLATE.md に次のような項目を設定しておきます。 次に、リリース時に起動するGitHub Actionsから、チェック済みの項目を抽出するスクリプトを起動します。 def category_by_pull (pull) return :planner_qa_pr if body.include? " - [x] 企画側QA " return :developer_qa_pr if body.include? " - [x] 開発側QA " return :other_pr end リリース用のPull requestの本文に反映されるため、QA担当者が何を見るべきかがわかりやすくなります。 定期実行 cron が使えるのもGitHub Actionsの良いところです。 on : schedule : - cron : '30 0 * * 1-5' # 平日09:30 (JST) 休日・祝日の考慮が必要な場合は、次のように前段に判定用のジョブを仕込んで needs で繋ぎます。 check : outputs : is_holiday : ${{ steps.check_holiday.outputs.result }} steps : - run : npm install @holiday-jp/holiday_jp - uses : actions/github-script@v7 id : check_holiday env : TZ : 'Asia/Tokyo' # タイムゾーン固定必須 with : script : | const holidayJp = require('@holiday-jp/holiday_jp'); return holidayJp.isHoliday(new Date()); some_job : needs : check if : needs.check.outputs.is_holiday == 'false' outputs は string で返ってくるため、 boolean で扱いたい場合は fromJson(needs.check.outputs.is_holiday) のように変換すると良いでしょう。 まとめ この記事では、GitHub Actionsを使った様々な自動化の手法を紹介しました。 公式が提供するActionの他にも、世の中には有用なActionがたくさんあります。 サードパーティ製のActionの利用については、「要件を満たせるか」「セキュリティ上の懸念はないか」「継続的なメンテナンスが期待できるか」等が選定の基準となるでしょう。 前回の記事では GitHub Actions高速化の事例 を書いておりますので、合わせてご覧いただけたらと思います。 弊社の他のGitHub Actions活用事例は、次のスライドで紹介しております。 ファインディでのGitHub Actions活用事例 - Speaker Deck こちらの発表については、connpassのイベントページにアーカイブ動画へのリンクを載せております。皆様の参考となれば幸いです。 findy.connpass.com ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに こんにちは。プロセス改善・アジャイルコーチで、Tech Blog編集長の高橋（ @Taka_bow ）です。 皆さんは、2021年6月に生まれた GitHub Copilot を利用していますか？ この生成AIベースのコーディング支援ツールは、コードの自動補完や生成、関数の自動生成、エラー修正支援など、開発者の作業を多面的にサポートします。 ファインディでは2023年3月から導入し、開発チーム全員が日常的に活用しています。Findy Team+で効果を測定した結果、コーディングの効率化やコミュニケーションコストの削減、さらには開発者の満足度向上など、多くの利点が確認されました。 今回は、このような ソフトウェア開発における生成AIの影響を分析した最新の論文を紹介 します。GitHub Copilotが開発プロセスにもたらす変化や、開発者の生産性への影響についての研究が書かれた、興味深い論文です。 はじめに 生成AIが高度なスキルを要する仕事に与える影響 実験の概要 具体的な成果 シニア開発者には控えめな効果 ジュニア開発者への影響 シニア開発者への影響 詳細な比較 ツール採用パターンの違い 補足：Accentureの実験初期のデータ破棄（論文付録D） おわりに：試されるのは「人間」 お知らせ！ 生成AIが高度なスキルを要する仕事に与える影響 2024年9月5日、GitHub Copilotに関する1つの論文がプレプリントサーバーのひとつ SSRN(Social Science Research Network) に公開されました。 papers.ssrn.com 直訳すると 「生成AIが高度なスキルを要する仕事に与える影響：ソフトウェア開発者を対象とした3つのフィールド実験からの証拠」 といったところでしょうか。 査読前論文なので、現在は誰でも読むことが出来ます。 この論文は、Kevin Zheyuan Cui氏（プリンストン大学）、Mert Demirer氏（マサチューセッツ工科大学）、Sonia Jaffe氏（マイクロソフト）、Leon Musolff氏（ペンシルベニア大学ウォートン校）、Sida Peng氏（マイクロソフト）、およびTobias Salz氏（マサチューセッツ工科大学）によって執筆されたもので、 大規模な実験 の結果を分析した科学的アプローチの成果が記されています。 実験の概要 この研究では、GitHub Copilotの効果を検証するため、大規模なランダム化比較試験が行われました。実験の舞台となったのは、Microsoft、Accenture、そして匿名のFortune 100エレクトロニクス製造会社の3社です。 驚くべきことに、この実験には実に 4,867人 もの開発者が参加しました。 参加者は2つのグループに分けられ、一方には GitHub Copilot が提供され、もう一方は 従来の開発手法 を継続しました。この比較により、GitHub Copilotが本当に開発者の生産性を向上させるのか、客観的に検証することが目的でした。 また、各社の実験期間は次の通りです。 Microsoft ：2022年9月初旬から2023年5月3日まで（約7ヶ月間） Accenture ：2023年7月末から2023年12月まで（約4ヶ月間） 匿名の大手企業（Fortune 100） ：2023年10月から2ヶ月間（段階的にロールアウト） このような実験の設計により、異なる企業環境や期間での GitHub Copilotの効果を包括的に評価することが可能となりました。 具体的な成果 実験結果は、GitHub Copilotの効果を明確に示しています。 GitHub Copilotを使用した開発者グループでは、次のような顕著な改善が見られました。 タスク完了数: 平均で26.08%増加 （標準誤差: 10.3%） コミット数: 13.55%増加 （標準誤差: 10.0%） コードコンパイル回数: 38.38%増加 （標準誤差: 10.0%） これらの数字は、GitHub Copilotが開発作業全体の効率を確実に向上させていることを示しています。特筆すべきは、経験の浅いジュニア開発者への効果です。このグループでは、 GitHub Copilotの採用率がより高く 生産性の向上がより顕著 であったことが報告されています。このことから、GitHub Copilotが特にキャリア初期の開発者のスキル向上と生産性増加に大きく貢献する可能性が示唆されています。 シニア開発者には控えめな効果 この研究で特に注目すべきは、GitHub Copilotがジュニア開発者とシニア開発者に与えた影響の違いです。 ジュニア開発者への影響 GitHub Copilotは、経験の浅い開発者に対して特に大きな効果を示しました。 新しいコードの書き方や構文を効率よく学習 タスクの進捗が大幅に向上 プルリクエスト数が40%増加（シニア開発者は7%） これらの結果から、GitHub Copilotはジュニア開発者にとって単なる補助ツールを超えた 学習ツール としての役割を果たしていると考えられます。 シニア開発者への影響 一方、シニア開発者に対する影響は比較的小さいものでした。これには次のような要因が考えられます。 すでに確立された作業スタイルがある 新しいツールの採用に対する慎重さ 詳細な比較 次の表は、ジュニアとシニア開発者におけるGitHub Copilotの効果の違いを示しています。 項目 ジュニア開発者 シニア開発者 プルリクエスト増加率 40% 7% コミット数増加率 21% 16% ビルド数増加率 29% 13% GitHub Copilot採用率 82.1% (±2.1pp) 76.8% (±2.1pp) 採用後1ヶ月後の継続使用率 84.3% 74.8% GitHub Copilot提案受け入れ率 25.2% 24.7% 注：この研究では、会社での採用時の職位や在職期間に基づいて開発者を「ジュニア」と「シニア」に分類しています。具体的な基準については詳細が明らかにされていません。 ツール採用パターンの違い 実験結果から、GitHub Copilotの初期採用率は予想外に低かったことが分かりました。 Microsoftでは最初の2週間で採用率が42.5%にとどまり、 リマインダー後に64%まで上昇 。Accentureでは全体で約60%の採用率でした。 この結果は、新しいツールの導入には単なる提供以上のものが必要だということを示しています。適切なトレーニングやサポートが不可欠で、段階的な導入や定期的なリマインダー、効果的な使用法の教育セッションなどが有効な戦略となりそうです。 これらの知見は、GitHub Copilotに限らず、新技術の導入時に直面する一般的な課題を反映しています。単にツールを導入し、現場任せにするだけでは、効果的に活用できないでしょう。急速に進化する開発環境では、新ツールを戦略的に導入し、継続的にサポートすることが、組織の競争力を保つうえで極めて重要です。 補足：Accentureの実験初期のデータ破棄（論文付録D） Accentureの実験には意外な展開がありました。2023年4月に同社が実施した大規模なレイオフ（19,000人の従業員削減）により、当初の実験が中断を余儀なくされたのです。 このレイオフは実験にも大きな影響を与えました。 実験参加者の42%が影響を受ける データの質に問題が生じる GitHub Copilotの使用状況や採用データの記録が不十分に 結果として、この初期実験のデータは信頼性に欠けるものとなりました。しかし、204人の開発者に絞って行った分析では、次のような傾向が見られました。 プルリクエスト数: 39.18%減少 (標準誤差: 36.78%, 統計的に有意ではない ) コミット数: 43.04%増加 (標準誤差: 38.80%) ビルド数: 12.33%増加 (標準誤差: 53.60%) これらの結果は統計的な信頼性が低く、実験結果としては参考程度にとどめるべきでしょう。 おわりに：試されるのは「人間」 この研究から、GitHub Copilotがソフトウェア開発者の生産性向上に確かな効果をもたらすことが明らかになりました。特に、ジュニア開発者への顕著な効果は注目に値します。 一方で、シニア開発者への効果が限定的だった点も興味深い発見です。これは、経験豊富な開発者がすでに高いスキルを持ち、AIのサポートをそれほど必要としていない可能性を示唆しています。 しかし、ジュニア開発者がAIの提案を鵜呑みにするリスクも考慮する必要があります。ここで、シニア開発者によるコードレビューの重要性が一層高まると言えるでしょう。 調査会社の 米ガートナーが発表した内容 によると、AI コードアシスタント（生成AI）に関するマジック・クアドラントと共に、次のような予測がなされていました。 戦略的計画の仮説 2027年までに、ソフトウェア開発ライフサイクル（SDLC）のあらゆるフェーズを拡張するためにAIを活用するプラットフォームエンジニアリングチームの割合は、5%から40%に増加する。 2027年までに、80%の企業がAIで拡張されたテストツールをソフトウェアエンジニアリングツールチェーンに統合しており、これは2023年初頭の約15%から大幅な増加となる。 2027年までに、AI生成コードに対する”ヒューマン・オーバーサイト”（人間がAIに対して動きを見たり止めたりできる） *1 が不足しているために、本番環境に流出するソフトウェア欠陥が25%に達し、2023年の1%未満から大幅に増加する。 2028年までに、90%の企業のソフトウェアエンジニアがAIコードアシスタントを使用するようになり、2024年初頭の14%未満から増加する。 2028年までに、生成AI（GenAI）の使用により、レガシーアプリケーションのモダナイゼーションコストが2023年の水準から30%削減される。 Figure 1: Magic Quadrant for AI Code Assistants ここでも、人間側によるチェックが不足することでソフトウェア欠陥の上昇が予測されており、結局のところ、 AIツールの活用と人間の経験や判断力のバランスが、質の高い開発プロセスの鍵 となりそうです。 私たちに求められるのは、技術の進化を単に観察するだけでなく、それを最大限に活用しつつ、人間ならではの創造性や洞察力を発揮していくことです。この新しい時代の開発環境で、私たちはどのような価値を生み出していけるでしょうか。その答えを、皆さんと一緒に見つけていきたいと思います。 お知らせ！ 現在、私と一緒にイネイブリングチームの立ち上げを行うメンバーを探しています！ イネイブリングチームは、単なる開発支援を超えた重要な役割を担います。 組織全体のエンジニアリング力を向上 開発スキル向上のためのトレーニングやワークショップを実施 プロセス改善の提案とコーチングを行い、開発生産性とDevExを向上 社内外のエンジニアを対象とした活動を展開 このチームで、ファインディの成長エンジンとなりませんか？興味がある方は、ぜひこちらをクリックしてみてください↓ herp.careers 他にも、ファインディでは一緒に働くメンバーを募集中です。 herp.careers *1 : AIの文献で良く出てくる"human oversight"は適した日本語訳がなく、一旦このように訳した

ファインディ株式会社でフロントエンドのリードをしております 新福( @puku0x )です。 弊社では、数年前に社内のCI環境をすべてGitHub Actionsに移行しました。 この記事では、弊社のGitHub Actions活用事例の内、CI高速化についてご紹介します。 なぜCI高速化に力を入れるのか CI高速化 キャッシュの活用 ジョブの並列化 Larger Runners まとめ なぜCI高速化に力を入れるのか 当ブログをはじめ弊社では、たびたびCI高速化の大切さについて言及しています。 Findyの爆速開発を支えるテクニック - Findy Tech Blog RailsのCIのテスト実行時間を 10分から5分に高速化した話 - Findy Tech Blog Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog これはなぜでしょうか？ 開発が進むにつれて、コードベースが肥大化し、CIの待ち時間が増えていくのは皆さんにも経験があると思います。 CIの待ち時間が長いとついレビューを放置してしまいがちです。 レビューが遅いとブランチの生存期間が伸び、コンフリクトの発生確率が上がります。 コンフリクトを解決しても、CIが遅い状態ではまた同じことの繰り返しとなるでしょう。 GitHubの調査では、開発者は多くの時間をCI待ちに費やしていると報告されています。 github.blog 見方を変えると、CI高速化はコーディングの効率化と同程度のインパクトがあると言えます。 チームの開発生産性を支える基盤として、弊社はCI高速化に力を入れているのです。 CI高速化 キャッシュの活用 弊社では、 actions/cache を使って、依存関係のインストールを省く工夫を取り入れています。 ここでは例として、フロントエンド系のリポジトリのワークフローを紹介します。 - uses : actions/setup-node@v4 id : setup_node with : node-version : 20 - uses : actions/cache@v4 id : cache with : path : node_modules key : ${{ runner.arch }}-${{ runner.os }}-node-${{ steps.setup_node.outputs.node-version }}-npm-${{ hashFiles('**/package-lock.json') }} - if : steps.cache.outputs.cache-hit != 'true' run : npm ci フロントエンド周りのCIを組んだことのある方はピンと来たかと思います。 このワークフローでは、 node_modules ディレクトリをキャッシュしています。 npm公式では非推奨とされていますよね？ なぜこのような書き方でも大丈夫なのでしょうか？その秘密はキャッシュのキーにあります。 key : ${{ runner.arch }}-${{ runner.os }}-node-${{ steps.setup_node.outputs.node-version }}-npm-${{ hashFiles('**/package-lock.json') }} キャッシュキーとして、OSやNode.jsのバージョン、パッケージマネージャーの種別などが細かく設定されています。 node_modules ディレクトリのキャッシュが非推奨とされる理由は、異なる環境で実行されることによるファイルの不整合を防ぐためです。これに気を付けていればキャッシュしても良いのです。 ※最近のGitHub ActionsではArmランナーが利用できるため、キャッシュキーにCPUアーキテクチャを追加するとより堅牢になるでしょう。 node_modules がキャッシュヒットしなかった場合を考慮して、 .npm ディレクトリのキャッシュも含めると次のようになります。 - uses : actions/setup-node@v4 id : setup_node with : node-version : 20 - uses : actions/cache@v4 id : cache with : path : node_modules key : ${{ runner.arch }}-${{ runner.os }}-node-${{ steps.setup_node.outputs.node-version }}-npm-${{ hashFiles('**/package-lock.json') }} - uses : actions/cache@v4 if : steps.cache.outputs.cache-hit != 'true' with : path : | ~/.npm key : ${{ runner.arch }}-${{ runner.os }}-node-${{ steps.setup_node.outputs.node-version }}-npm-${{ hashFiles('**/package-lock.json') }} restore-keys : ${{ runner.arch }}-${{ runner.os }}-node-${{ steps.setup_node.outputs.node-version }}-npm- - if : steps.cache.outputs.cache-hit != 'true' run : npm ci 弊社の場合では、これでおよそ20秒〜30秒ほど高速化できました。 ジョブの並列化 バックエンドのテストを例に挙げます。このワークフローでは、 matrix 機能を用いてテストを10並列で動作させるようにしました。 strategy : matrix : ci_node_index : [ 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 ] steps : - name : Test env : CI_NODE_TOTAL : ${{ strategy.job-total }} CI_NODE_INDEX : ${{ matrix.ci_node_index }} run : | # get spec files order by filesize TEMP_FILE_PATH=$(mktemp) git ls-tree -r -t -l --full-name HEAD | grep '_spec.rb' | sort -n -k 4 | awk '{ print $5 }' | ./scripts/ci/rspec_split_files.sh > $TEMP_FILE_PATH # echo outputs echo "====SPEC FILES COUNT====" cat $TEMP_FILE_PATH | tr ' ' '\n' | wc -l echo "====SPEC FILES====" cat $TEMP_FILE_PATH | tr ' ' '\n' # run rspec bundle exec parallel_rspec -- --format progress -- $(cat $TEMP_FILE_PATH) #!/bin/bash i = 0 ret = () while read -r line do if [ $[ i % $[ CI_NODE_TOTAL ]] = $[ CI_NODE_INDEX ] ] ; then ret += ($line) fi let i++ done echo ${ret[ @ ]} 単純にテストを均等配分するのではなく、ファイルサイズでソートするという工夫が施されています。これは、テスト実行時間がファイルサイズに比例するという仮定に基づいています。 これらの工夫により、実行時間が従来の約半分になるまで高速化できました 🚀 詳細は↓こちらの記事をご覧ください。 tech.findy.co.jp Larger Runners 基本的には並列化でCI高速化を目指しますが、難しい場合はLarger Runnersを使うのも手です。 （並列化の可否の判定は、テスト対象ファイルの分割を外部から制御可能かどうかで決めています） Larger Runnersは、契約しているプランが「GitHub Teamプラン」または「GitHub Enterprise Cloudプラン」の場合に利用可能です。 最大で64コアまでスペックアップできるらしいです。いつか使ってみたいですね！ docs.github.com Armランナーについては先日GAとなったこともあり、積極的に移行を検討するようになりました。 github.blog 3割程度のコスト削減ができることから、既に社内のいくつかのプロジェクトではLinux Armランナーに完全移行しています。 2024年9月現在では、 ruby/setup-ruby などサードパーティの対応が進んでいないものもあります。移行の際は動作検証を十分にしておくと良いでしょう。 参考までに、弊社のフロントエンドでの高速化の例を示します。 Build Test 2コア 15m8s 12m7s 4コア 8m38s 6m56s スペックアップするとコストは増えますが、その分CIの待ち時間の削減が期待できます。実質的な負担に大きな変化が無い場合は強気でスペックアップしていきましょう 💪 まとめ いかがでしたでしょうか？ この記事では、弊社のGitHub Actions活用事例の内、CI高速化についてご紹介しました。 CIの待ち時間については、「継続的デリバリー」の書籍を参考に 10分以内 を目指すと良いでしょう。 www.kadokawa.co.jp 実際に弊社では、これらの取り組みを行う前は1PRあたり15分〜20分ほどかかっていたCIが、10分以内の完了を目指して取り組んできた結果、平均5分程度まで高速化できた例もあります。 弊社にはCIの整備に関心の高いメンバーが多く在籍しております。勉強会等でお会いする機会がありましたらぜひお声がけください。 CIは5分以内！素早い開発サイクルを支えるCI - Speaker Deck ファインディでのGitHub Actions活用事例 - Speaker Deck こちらの発表については、connpassのイベントページにアーカイブ動画へのリンクを載せております。 findy.connpass.com 次回へ続きます！👋 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 突然ですが皆さんは本を読みますか？ エンジニアという職業柄、技術書やビジネス書など、様々なジャンルの本を読む機会が多いのではないでしょうか？ そこで今回は、人生を変えた一冊と題して、弊社エンジニア達のお気に入りの一冊を紹介していきます。 それでは見ていきましょう！ 人生を変えた一冊 戸田 ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略 ジョナサン・アイブ 高橋 1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え 森 アジャイルサムライ――達人開発者への道 まとめ 人生を変えた一冊 戸田 ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略 ソフトウェア・ファースト 作者: 及川 卓也 日経BP Amazon 及川卓也さん著の本で、DX（デジタルトランスフォーメーション）の本質を理解するためには必読の一冊です。 2024年9月には内容を大幅改定した第2版が発売予定とのことで、こちらも合わせてチェックしておきたいですね。 ソフトウェアファースト第２版　あらゆるビジネスを一変させる最強戦略 作者: 及川 卓也 日経BP Amazon 内容としては、日本のIT史の振り返りから始まり、現在の問題点の指摘、そしてDXの在り方、進め方について詳しく解説されています。 また、これからの時代の強い開発組織の在り方や作り方にも言及されており、エンジニアだけではなくマネージャーや経営者の方にも是非読んで欲しい一冊になっています。 実際に読み進めていくと共感できる部分が多く、「わかっているけど中々実行に移すことができない」という方にヒントを届けてくれるような内容でした。 この本が世に出た当時、自分は30代に入ったばかりで、いわゆるマネージャーとしてのキャリアを少しかじっていた頃でした。 経営陣がやって欲しいことと開発組織がやりたいことがズレている感覚が少なからずあり、この本を読んだことによってそれらがクリアになり、実際に実行に移すことが出来たことがありました。 自分が抱いていた感覚というものは当時所属していた組織特有のものではなく、社会全体の問題であるということを再確認できたため、逆に割り切って行動に移すための勇気を貰うことができました。 おそらくこの本と出会っていなかったら、今でも違和感と葛藤して何も進められないままだったと思います。そういうこともあり、エンジニア人生のターニングポイントとなった1冊になったと思います。 ジョナサン・アイブ ジョナサン・アイブ　偉大な製品を生み出すアップルの天才デザイナー 作者: リーアンダー ケイニ― 日経BP Amazon 1冊と言っていながら、もう1冊の紹介をさせてくださいｗ かのスティーブ・ジョブズが絶対的な信頼を寄せたデザイナー、ジョナサン・アイブ氏の生い立ち、学生時代、アップル入社後のiMac、iPhone、iPad、MacBook Airなど数々の革新的な製品づくりでの試行錯誤、社内での争いまでを描いた一冊です。 モノづくりに対する思考や姿勢、デザインに対する考え方など、エンジニアにも多くのヒントを与えてくれる内容になっています。 この本が世に出た当時、自分は20代中盤くらいで若く、これから何をしてキャリアを考えるべきなのか模索していた頃でした。その時にこの本と出会い、何気なしに読んでいくとアイブ氏のモノづくりに対する姿勢に驚かされました。 詳細は本を読んでいただきたいのですが、例えば新製品のデザインをする際、彼は数百、数千パターンのプロトタイプを作るそうです。 そのパターンなのですが、素人からみたらパッと見だと全く同じデザインに見えるそうです。しかしこれらは全て数ミリ単位で違うそうで、その違いを比べつつ、最終的なデザインに辿り着くそうです。iPhoneやMacbookなどのデザインも最初はこのようにして生まれたとのことで驚かされました。 これを読んだ時、自分が悩んでいたことが実はまだ甘い考えだったと気付かされました。世界的プロダクトを生んだデザイナーだとしても、まず最初に泥暗いことをやり切っているからです。 自分程度のエンジニアが今の段階でウダウダ悩んでいる暇があったら、目の前のことに集中して1個ずつ泥暗いことをやり切り続け、引き出しを増やすことに集中しようと決意できました。 おそらくこの本と出会っていなかったら、今でもウダウダ悩んで手を動かしていなかったかもしれません。この本もまた、エンジニア人生のターニングポイントとなった1冊になったと思います。 高橋 ファインディでエンジニア兼プロセス改善コーチをしている高橋（ @Taka_bow ）です。 1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え 1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え 作者: エリック・シュミット , ジョナサン・ローゼンバーグ , アラン・イーグル ダイヤモンド社 Amazon シリコンバレーの伝説的コーチでありスティーブ・ジョブズの親友でもあったビル・キャンベル。 『1兆ドルコーチ』は、彼の様々な教えを記録した本です。著者は元Google会長のエリック・シュミット、元Google SVPのジョナサン・ローゼンバーグ、元Googleで経営コンサルタントのアラン・イーグルの3名。（すでに著者がすごい面子！） この3人のみならず、ビルの指導を仰いだ起業家たちの多くが今日のテクノロジー業界を牽引しています。現在のGAFAMの隆盛は、ビルの影響力なくしては語れないと言われています。 私が好きなエピソードの1つに、Googleがマネジャーを「全廃」し管理職のいない組織を作った直後の、ラリー・ペイジとビルのやりとりです。 ビルは言います。 「ここにはマネジャーを置かないとダメだ」 ラリーは答えにつまった。ちょうどマネジャーを全廃したばかりで、彼は結構満足していたのだった。(後略) 二人はどちらも譲らず、しばらく堂々めぐりの議論を続けた。とうとうビルはラリーの流儀にならって、それならエンジニアに直接聞いてみればいいと言った。(中略)ビルはその一人に、マネジャーがほしいかと訪ねた。 ええ、という返事だった。 なぜだ？ 「何かを学ばせてくれる人や、議論に決着をつけてくれる人が必要だから」 その日彼らは数人のソフトウェアエンジニアと話したが、答えはほとんど同じだった。 このエピソード 1 は、たとえテック企業でもマネージャーがきわめて重要な存在であることを示しています。エンジニア組織のマネジメントで悩みがあると、今でも読み返します。 森 FIndy バックエンドエンジニアの森 @jiskanulo です。 アジャイルサムライ――達人開発者への道 アジャイルサムライ――達人開発者への道 作者: ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ , 西村直人 , 角谷信太郎 オーム社 Amazon アジャイル開発を進める上でのチーム作り、見積もり計画、日々の開発と多岐にわたって解説があり入門書としておすすめです。 アジャイルサムライ日本語訳版が出版された2011年当時、IT業界のエンジニアが集まり各章を読み合わせる輪読会のコミュニティが日本各地で生まれました。 このコミュニティは次第に盛り上がり、翌2012年には原著者のJonathan Rasmussonさんを日本にお招きして参加者100人超えの大イベント Agile Samurai Dojo Gathering 2012 を開催するに至りました。 蒔かれた種子は今も世界でも芽吹いているでしょう。 私個人の当時の思い出を記します。 2010年に当時勤めていた企業を退職、数ヶ月の無職期間を経て新しい会社に勤めていました。 ユニットテストを導入して安全に開発するための仕組みづくり、営業メンバーの業務効率化のためのツール作成、社内サーバーの管理やデータセンターへのラッキングなどなど会社とプロダクトに貢献するべく取り組んでいました。 そんな日々を1年ほど過ごし、ただ作業をこなすだけで1日終わってしまう作業者になっているなと感じていました。　 一人でできることは限界があるとも感じており、チームを組んでよりよい課題解決のやり方を模索しどうすればいいプロダクトを作れるのか、そもそもいいプロダクトとは…と色々なことに思い悩んでいました。 思い悩んでいるなかでアジャイルサムライに出会い、この本を通じてコミュニティに参加して他の方と交流を深めることで同じような悩みを抱えている仲間がたくさんいることを知りました。 ファインディ社に入社してから、この本にある「達人開発者」の振る舞いをあらためて心がけようとしています。 まとめ いかがでしたでしょうか？ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers （引用）エリック・シュミット. ジョナサン・ローゼンバーグ. アラン・イーグル. 櫻井　祐子 (翻訳). 1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え. ダイヤモンド社, 2019/11/14, p.63 ↩

はじめに 皆様、はじめまして。Findyでプロダクト開発部/SREとしてジョインしました安達（ @adachin0817 ）と申します。今年の6月に入社し、ちょうど3ヶ月が経ちました。本日は、SREチームの立ち上げに関する0から1のプロセスと、今期の取り組みについてご紹介させていただきたいと思います。 SREチーム発足 2023年までは、バックエンドチームがインフラを担当していました。しかし、サービスの拡大に伴い、バックエンドチームのリソースが不足し、SRE的な改善が十分に行えない状況が続いていました。そこで、昨年からSREの大矢とチームリーダーの下司（ @gessy0129 ）がジョインし、現在は3名体制で活動しております。 SREチームの位置づけとミッション SREチームは横断的なSRE活動をしており、これを「横断SRE」と指しています。一方で、各プロダクトにおいてSRE的な役割を担っていたメンバーは「Embedded SRE」と呼ばれ、引き続き改善活動を担当しています。 SREチームは現在、チームを作り上げていく段階にあり、まだまだやることが多く残されています。こうした背景を踏まえ、SREチームの短期および中期におけるミッションを設定しました。 短期ミッション 「ファインディの事業成長を支えるための、SRE組織のあり方の確立」 中期ミッション 「社員全員が事業成長に集中できような仕組みを構築し、提供する」 SREの存在意義 SREは道を作るために存在する リスクを受け入れ、管理する SLOを計測する トイルの削減 モニタリングする 自動化する 他プロダクトの支援 SREチームの業務の進め方 アジャイル開発手法を採用しており、各メンバーにはそれぞれIssue（タスク）が割り当てられます。一週間イテレーションで管理し、Issueのクローズを目指しています。毎朝、GitHubのProjectsを使用してカンバンボードを確認し、今日のタスクや困っていることを共有や、雑談をしています。また、毎週金曜日にはチーム全体で振り返りを行い、Findy Team+を活用しながら内容をKibelaに記録し、全員が閲覧できるようにしています。さらに、隔週でEmbedded SREチームとのお茶会も実施しており、取り組みたいことを共有する場を設けています。 カンバン/ステータス ステータス 内容 To Do Issueを作成した状態、未着手 Parent In Progress 親子関係のあるIssueの親 In Progress 進行中のIssue Done 対応が完了したIssue では、今期SREチームの取り組みについてご紹介していきたいと思います。 今期の取り組みについて 全環境のTerraform import化 これまで全ての環境がTerraformで完全にコード管理されていない状態でしたが、現在は全リソースをコード化することで一元管理を実現し、環境間での設定の整合性が保たれるようになりました。まずは既存の設定を棚卸しし、リソースをインポートすることで、今後の変更や拡張がより容易になっています。さらに、Terraform Cloudを活用しながら、今後はmodule化を進めて、効率的でスケーラブルなインフラ管理を目指しています。 Findy Toolsのインフラ改善 私が入社してからFindy Toolsのインフラ改善として、いくつか対応していきました。まずは、RDSのSSL/TLS証明書更新とAuroraのマイナーバージョンアップを開発環境から本番環境まで3日で実施しました。次に監視とオブザーバビリティの強化では、元々はインフラリソースをモニタリングしておらず、SentryのエラートラッキングとAPMのみでした。そこでDatadogでのインフラリソース(ECS、外形監視、CloudFront、RDS、イベントログ、WAF)、APMなどを対象に、アラートをTerraformで管理し、ダッシュボードを手動で運用するようになりました。普段見えていなかった部分がオブザーバビリティの向上によって可視化されていきました。 また、SLI/SLOの策定を進め、ページ表示速度やリクエスト成功率の目標を設定し、エラーバジェットとバーンレートの管理を進めていきました。SLOの振り返りは隔週で実施しており、アラートが発生した際に、開発メンバーと改善案を話し合えることは非常に重要だと感じています。 最後に、Rails serverやNode.js、MySQL8の開発環境の構築を改善し、Justfileを活用して自動化を進めました。JustはMakefileと比較すると、シンプルで直感的な構文で、シェルスクリプトに似ています。また、依存関係の管理が簡単なため、学習コストも低いです。これにより、開発メンバーはスピーディーに構築できるようになりました。以下フロントエンドのJustfileになります。 Frontend Justfile # Justfile for setting up development environment # Install Homebrew and essential packages install_homebrew: @echo "Installing Homebrew if not already installed..." @if ! command -v brew >/dev/null 2>&1; then \ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"; \ else \ echo "Homebrew is already installed."; \ fi install_essential_packages: @echo "Installing essential packages..." brew install coreutils curl git # Configure Git configure_git: @echo "Configuring Git..." git config core.ignorecase false # Install asdf and Node.js install_asdf: @echo "Installing asdf if not already installed..." @if ! command -v asdf >/dev/null 2>&1; then \ brew install asdf; \ echo -e "\n. $(brew --prefix asdf)/libexec/asdf.sh" >> ${ZDOTDIR:-~}/.zshrc; \ else \ echo "asdf is already installed."; \ fi install_nodejs: @echo "Installing Node.js..." @if ! asdf plugin list | grep -q 'nodejs'; then \ asdf plugin add nodejs; \ else \ echo "Node.js plugin is already added."; \ fi asdf install nodejs asdf reshim nodejs # Install mkcert and create certificates install_mkcert: @echo "Installing mkcert if not already installed..." @if ! command -v mkcert >/dev/null 2>&1; then \ brew install mkcert; \ mkcert -install; \ else \ echo "mkcert is already installed."; \ fi create_certificates: @echo "Creating local certificates..." mkcert -cert-file localhost.pem -key-file localhost-key.pem localhost 0.0.0.0 hoge-web # Install npm packages install_npm_packages: @echo "Installing npm packages..." npm ci # Run all tasks all: install_homebrew install_essential_packages configure_git install_asdf install_nodejs install_mkcert create_certificates install_npm_packages これらの改善については、7月の弊社DevRelイベントでLTを行いましたので、まだご覧になっていない方はぜひスライドをご確認ください。 findy.connpass.com speakerdeck.com AWSセキュリティ周り向上 AWSセキュリティの強化策として、Security Hubの実装を検討しましたが、予想以上の導入工数と既存ダッシュボード機能の現状を考慮した結果、我々の要件により適した別のアプローチを模索することにしました。複数のSaaSセキュリティサービスを検討し、最終的にShisho Cloudを選定しました。Shisho Cloudは使いやすさとコスト面で現在のファインディ社の課題にマッチしており、現在はAWSセキュリティポリシーガイドラインを作成し、Embedded SREチームと協力して対応を進めています。 「Findy Team+」オブザーバビリティ周り強化 Findy Toolsで培ったオブザーバビリティやSLOの経験を活かし、Findy Team+のSRE支援も行いました。元々設定されていたDatadogのアラートはTerraformで管理されていなかったため、まず棚卸しをし、全てをTerraformでimport化しました。しきい値などは次のように環境変数で管理し、テンプレート化することで他のプロジェクトにも適用可能にしました。SLOの策定にはまだ改善の余地がありますが、今後はミッションクリティカルな領域にも取り組んでいき、開発メンバーと振り返りを実施していく予定です。 rds.alert.tf resource "datadog_monitor" "rds_cpu_alert" { name = "[${var.service_name}]rds_cpu_alert" type = "metric alert" query = "avg(last_5m):avg:aws.rds.cpuutilization{rds:${var.service_name}-${var.environment}} by {dbinstanceidentifier} > ${var.rds_cpu_critical_threshold}" escalation_message = "RDS CPU usage for ${var.service_name}_${var.environment} instance has exceeded ${var.rds_cpu_critical_threshold}%" notify_no_data = false notify_audit = false timeout_h = 1 include_tags = true monitor_thresholds { critical = var.rds_cpu_critical_threshold } message = <<-EOT @${var.slack_channel} EOT tags = local.combined_tags } 今期まだやりきれていないタスク DevSecOpsの推進に向けたセキュリティ基盤のさらなる整備 AWSコスト最適化 開発メンバー生産性の向上 開発環境 完全Docker化とJustfile化 ECS Arm化 Stg複数環境 自動化 デプロイ高速化 後半では、AWSコスト最適化や開発メンバーの生産性向上のために、さらなる効率化とやりやすさを追求し、インフラ管理や開発プロセスの改善を進めています。 まとめ SREチームの発足と今期の取り組みについて、簡単にご紹介させていただきました。チームの立ち上げからインフラの改善、セキュリティ対策まで、多岐にわたる課題に取り組んできましたが、まだやるべきことがたくさんあります。(Issueが100個以上あります) 今後も引き続き、SREチームとしてサービスの信頼性向上に努めていくのと同時にSREに興味のある方は、ぜひ一緒に働きましょう！カジュアル面談お待ちしております🙏 herp.careers findy-code.io findy-code.io

こんにちは。エンジニアの佐藤( @t0m0h1r0x )です。 今回は、弊社で現在進めている Emotion から CSS Modules への移行について紹介します。 移行の背景、検討した代替ライブラリ、そして最終的な決定について話していきます。 移行の検討理由 代替ライブラリの検討 Panda CSS Pigment CSS CSS Modulesへの移行 今後の展望 まとめ 移行の検討理由 弊社では現在、CSS-in-JSライブラリとしてEmotionを使用しています。ピュアなCSS記法を好むメンバーが多いので、EmotionのTagged Template Literal記法がチーム文化との相性も良く、これまで活用してきました。 一方で、フロントエンド開発フレームワークに Next.js を採用しており、そちらではApp Routerへの移行を進めています。 App RouterのメリットはやはりReact Server Components（RSC）の活用だと思います。RSCはユーザー体験と開発者体験の向上につながる重要な機能ですが、2024年9月現在、その仕様上EmotionでRSCをスタイリングできません。 このような背景から、RSCに対応できる新たなCSSライブラリの検討を始めました。 代替ライブラリの検討 代替ライブラリの選定にあたっては、パフォーマンスやAPIの使い勝手といった要素も大切ですが、チームとの相性も重要な要件としました。特に、Tagged Template Literalをサポートしていて、Emotionとの書き心地に互換性があることをポイントとしました。 Panda CSS Panda CSS は Chakra UI のチームが開発しています。CSSの記法としてObject LiteralかTagged Template Literalを選択できますが、後者には機能制限があるようです。 詳細については 公式ドキュメント を参照してください。 Pigment CSS Pigment CSS は Material UI のチームが開発しています。 こちらも要件と合致しそうなのですが、開発初期段階のためプロダクション利用には検討が必要です。 ちなみにPigment CSSは、最近リリースされたMaterial UI v6に、experimentalなopt-inとして組み込まれました。さらなる開発が期待できそうです。 CSS Modulesへの移行 上記の検討を踏まえ、弊社では一時的に信頼と実績があるCSS Modulesへの移行を決定しました。その理由は次の通りです。 プロダクトとチームの要件に合致 他ライブラリへの将来的な移行が比較的容易 一方でCSS Modulesの採用にあたっては、特に次の点に留意しています。 TypeScriptによる型定義 動的スタイリングの実装 仕様がメンテナンスモード 型定義には Happy CSS Modules を使用して、自動生成することで対応しています。 動的スタイリングについては、コード中にpropsベースのスタイリング実装が多くなかったことや、コンポーネントのルールを整備していたことで不要なcomponent targetingを予め減らせていたため、現時点では大きな支障は出ていません。 仕様についてはメンテナンスモードであるものの、長らくこの状態が続いていながら今の所大きな問題は起きていないため安定しているのではないかと思っています。 参考: Future of CSS Modules · Issue #187 · css-modules/css-modules · GitHub Interoperability across tools and support plain JS modules imports · Issue #1050 · webpack-contrib/css-loader · GitHub 今後の展望 CSSを取り巻く環境は日々進化しています。例えば、React v19からは<style>のホイスティングがサポートされる予定であり、それを活かした RESTYLE というライブラリも登場しています。 このような状況を踏まえ、当面はCSS Modulesへの移行を進めつつ、新たなライブラリの登場にも注目していきたいと思います。 まとめ EmotionからCSS Modulesへの移行は、弊社のフロントエンド開発環境を大きく変える重要な取り組みでした。 RSCとの互換性という課題はありましたが、暫定的な解決策を見つけつつ、より良い選択肢を模索し続けていきたいと思います。 弊社では一緒に働いてくれるメンバーを募集中です。興味を持っていただいた方は是非こちらのページからご応募お願いします。 herp.careers

はじめに Findyでデータエンジニアとして働いている開（ hiracky16 ）です。 この記事ではGoogle Cloudの製品であるCloud DLPを中心に弊社で取り組んでいるデータマスキングについて紹介します。 弊社はFindyやFindy Freelanceなど人材に関する事業を取り扱っているため個人データがより集まりやすい環境にあります。 ファインディの組織が日々拡大しサービス拡張していく中で、利用者の安全性を担保し、データにおけるリスクを低くするためのデータ基盤づくりが求められてきました。 データ基盤には事業部のデータを集約しているため、利用者にすべてを公開してしまうと運用を誤り、思わぬ事故につながる可能性が上がります。 ただ、閲覧できないと困る業務もあり、データの閲覧権限を絞りすぎてもリスクがあります。 今回は、個人データなどのセンシティブなデータを自動で検出・マスキングを行い、業務に必要な場合にのみ閲覧できる状態にする取り組みについてご紹介します。 権限周りの基本設計 マスキングの前に権限周りの基本設計を説明します。 データセットにはレイヤーを設けており、それぞれ次のようになっています。 source ... ローデータが入っているテーブル staging ... ローデータをBigQuery用に加工したテーブル intermediate ... CTEなどのテーブル mart ... 利用用途ごとに用意したテーブル まずはデータ基盤を利用するにあたり用途ごとにロールを定義しようと考えました。 用途以外のことができてしまうと誤操作によってデータを書き換えたり、消してしまったりするおそれがあるためです。 データの用途は大きく3つに分けることができ、特定のデータを定期的に見ることやBigQueryコンソールやDataformで自分のほしいデータを作ること、外部ツールにデータを連携することになります。 これらの利用用途ごとに権限を付与するためのロールを作りました。 また1ユーザーごとにロールを付与するのは大変なので、Googleグループを用意しあらかじめ付与しています。 こうすることでグループへの追加・削除によりロールの管理が比較的簡単な操作で可能になります。 更にデータマートに相当するデータセットは用途ごとに作りGoogleグループのメールアドレスをデータセットのIAMメンバーとして追加しておきます。 ロール できること Google Cloudプロジェクト上のIAMロール 対応するGoogleグループ 管理者 全てのデータセットに対して編集 プロジェクトレベルのオーナー - 編集者 source以外のデータセットへの編集、またDataformなどの周辺サービスの利用 プロジェクトレベルの「BigQueryユーザー」と「BigQueryデータ編集者」 editor （各データセットの）閲覧者 特定の mart_ で始まるデータセットの閲覧 プロジェクトレベルの「BigQueryユーザー」とデータセットレベルの「BigQueryデータ閲覧者」 mart_sales, mart_external_system 上記のようにデータセットごとにIAMロールを付与するためのTerraform Moduleを公開しているのでよかったらお使いください。 registry.terraform.io ポリシータグによる動的マスキング 基本的に個人データはsourceからstagingへの伝搬時にセンシティブなデータを省いています。 また上記の通り権限が絞れているので一見問題なさそうに見えますが、 mart データセットの中には業務システムに使うものもあり個人データが含まれます。 そういったデータをグループに属する全員が閲覧できる状態というのは望ましくありません。 このような場合には、カラムレベルでポリシータグを付与し、許可されたユーザーには通常のデータを、許可されていないユーザーにはマスキングされたデータを表示させています。 タグの付与はDataformのconfigで行っています。 次のように書くとテーブルが作られる際にタグを付与してくれます。 config { type: "table", "schema": "stg_hoge", "description": "ユーザーテーブル", "columns": { "id": "ユーザーのID", "email": { description: "メールアドレス", bigqueryPolicyTags: ["projects/project-hoge/locations/asia-northeast1/taxonomies/fuga/policyTags/piyo"] }, "tel": { description: "電話番号", bigqueryPolicyTags: ["projects/project-hoge/locations/asia-northeast1/taxonomies/fuga/policyTags/piyo"] } }, } ... マスキングのルールもいろいろなものがあります。 なお今回は試していませんが、BigQuery UDFをルールに追加できます。 cloud.google.com 動的マスキングの方法はわかりました。 ただ、個人データに対して曖昧な理解のまま運用してしまうと付与忘れや、付与しすぎて情報量が落ちてしまうおそれがあります。 そこで役立つのがCloud DLPです。 Cloud DLPによる個人データ検出 Cloud DLP（Data Loss Prevention）は、機密性の高いデータを検出、分類、保護するために設計されたGoogle Cloudのサービスです。 Cloud DLPにはBigQueryのデータをスキャンして個人データに該当するテーブル、カラムを検出してくれる機能が備わっています。 この検出を定期的に実行することによりポリシータグを付与する候補となるカラムを特定できます。 テーブルはサンプルですが、検査するとデータリスクが中程度〜高のカラムに個人データが含まれていそうなことが一目でわかるようになります。 以下は公式ドキュメントに載っていたイメージになります。 cloud.google.com DLP APIを用いてテキスト内の情報をマスキング ポリシータグを使ったマスキングは値全体をマスクしてしまいますが、ロングテキストの場合一部だけマスクしたいといったニーズが存在します。 例えば、商品レビューのテキストデータをポジネガ判定したい場合、テキスト全てをマスクしてしまうとポジネガ判定に使う情報が落ちてしまいます。 DLP APIを使うとテキスト中の個人情報をマスクできます。 DLP APIによるマスクの手順は「個人データの検出」と「データの匿名化」の2ステップがあります。 「個人データの検出」では事前に用意された検出器（INFO TYPE）を使い検出できます。 INFO TYPEは特定したい情報、例えば名前や電話番号、住所など情報の種類ごとに違います。 INFO TYPEはGCSに置いた辞書から自作でき、固有名詞にも対応できます。 下記が事前に用意されたINFO TYPEのリファレンスです。 cloud.google.com 「データの匿名化」は検出したINFO TYPEごとにどのように情報をマスクするかを定義します。 DLP APIにはPython ClientがあるのでこれをCloud RunにデプロイしてBigQueryからリモート関数で呼び出せるようにしています。 declare text string; set text = """ 私は山田太郎です。 本日はよろしくお願いします。 山田 090-0000-0000 tensyoku.taro@gmail.com """; select text, `function_dataset.dlp_api`(text) as masked_text; まとめ Cloud DLPの機能を使うことでマスキングする術をまとめてみました。 データ利活用が増えることは喜ばしいことですが、常にデータの扱いを気にしながらデータ抽出や分析するのにも限界があります。 これからもデータエンジニアとして安全に意思決定をサポートするデータ基盤を作っていきたいと思っています。 弊社ではデータ基盤を共に育てていくメンバーを募集しています。少しでも興味が湧いた方はカジュアル面談お待ちしております🙏 herp.careers herp.careers

Findyでエンジニアをしている栁沢（@nipe0324）です。 今回は、Findyの名物企画である「 コントリビューション・オブ・ザ・イヤー2024中間発表 」の裏側を公開します。裏側を知り、キャンペーンをより楽しんでもらえたら嬉しいです。 キャンペーン期間中にXでシェア後にフォームから応募することで「Anker充電器（Findyオリジナルデザイン入り）」が抽選で当たるかも！？ ぜひお申し込みください。 👇👇👇 コントリビューション・オブ・ザ・イヤー2024中間発表を試してみる コントリビューション・オブ・ザ・イヤーとは コントリビューション・オブ・ザ・イヤーの裏側 裏側①：コントリビューション・オブ・ザ・イヤーのランキング表示 裏側②：コントリビューション・オブ・ザ・イヤーのOGP表示 コントリビューション・オブ・ザ・イヤーを楽しんでください コントリビューション・オブ・ザ・イヤーとは コントリビューション・オブ・ザ・イヤーとは、Findyの名物企画の1つです。 1年間のGitHubのコントリビューション数やFindyユーザー内でのランキングを見ながら開発成果を振り返る期間限定のイベントです。 コントリビューション数を見ることで、自分が日々どのくらいGitHubで開発しているかを知ることができます。 コントリビューション数やランキングを見るにはFindy上で自分のGitHubアカウントを連携している必要があります。もしまだGitHubを連携してない方は こちら から連携してみてください。 過去5回ほど開催しており、多くの方に楽しんで頂けました。 過去のコントリビューション・オブ・ザ・イヤー 実際にXのシェアでは次のような声があり、開発の振り返りとして楽しんで頂けたようです。 ことしもがんばった 【yshrsmzさんの2023年の振り返り】 2023年にGitHubで4,341コントリビュートし、月間の最大は462(4月)、一日あたりの平均は13/日でした。 あなたも今年のGitHubでの活動をチェックしよう！ https://t.co/4saXCthnEV #コントリビューション・オブ・ザ・イヤー2023 — せーい(CodingFeline) (@_yshrsmz) 2023年12月20日 草はやしきれなかったのが悔しい 【mogmetさんの2023年の振り返り】 2023年にGitHubで4,715コントリビュートし、月間の最大は663(2月)、一日あたりの平均は13/日でした。 あなたも今年のGitHubでの活動をチェックしよう！ https://t.co/MzvBGuMw8k #コントリビューション・オブ・ザ・イヤー2023 — もぐめっと❄️ITイノベーター (@mogmet) 2023年12月21日 今回は、 「 コントリビューション・オブ・ザ・イヤー2024中間発表 」 ということで、2024年の1月から6月のコントリビューション数とランキングを振り返ることができます。 コントリビューション・オブ・ザ・イヤーの裏側 コントリビューション・オブ・ザ・イヤーの主要な機能について2つ紹介します。 裏側①：コントリビューション・オブ・ザ・イヤーのランキング表示 裏側②：コントリビューション・オブ・ザ・イヤーのOGP表示 裏側①：コントリビューション・オブ・ザ・イヤーのランキング表示 コントリビューション・オブ・ザ・イヤーでは、Findyユーザー内で「期間内のコントリビューション数のランキング」を表示しています。（ランキングの数字は上位の方のみ表示） コントリビューション・オブ・ザ・イヤーのランキング表示（※データはサンプルです） 実装にあたり、SQLでランキング表示を実現すると、クエリが複雑になりパフォーマンスも出しにくいという問題がありました。 そのため、Redisの ZREVRANK を採用しました。 ZREVRANKはソート済みセットのスコアが高いものから低いものに並べてデータを取得可能で、次のような形でシンプルにランキング表示を実装できます。 # ランキングの取得処理イメージ def contribution_ranking # zrevrankを使ってランキングを取得 ranking = redis.zrevrank(store_key, user.id) return nil if ranking.nil? # zrevrank は0始まりで順位を返すので、1を足して1位からの順位にする ranking + 1 end このように、Redisの機能をうまく利用することで、シンプルな実装で、ランキングの値を高速に取得しています。 裏側②：コントリビューション・オブ・ザ・イヤーのOGP表示 また、コントリビューション・オブ・ザ・イヤーでは、XでシェアしてもらったときにOGP画像を表示しています。 Xのポスト時のOGP表示（※データはサンプルです） Xのポスト上でOGP画像を動的に生成する流れは次のようになっています。 X上でOGP画像を動的に生成するシーケンス図 XからFrontend（Next.js）がリクエストを受けて、Next.jsのサーバーサイドレンダリング（SSR）の機能を使ってOGP画像のURLを返す OGP画像の生成は、内製のOGP画像生成サービスを利用して、APIの動的データをつかってユーザーに応じたOGP画像を生成している ちなみに、内製のOGP画像生成サービスは、Findy内でOGP画像を生成するマイクロサービスを用意しており、他機能のスキル偏差値やおみくじなどのOGP画像を生成するためにも使われている特徴的なサービスです。 また、今後の技術的な取り組みとしてNext.jsのApp Routerを活用することで、OGP画像の生成をNext.js上で実現できないかも思案しています🤔 コントリビューション・オブ・ザ・イヤーを楽しんでください 現在、「コントリビューション・オブ・ザ・イヤー2024中間発表」が期間限定で開催されています。 ぜひ、2024年上半期のコントリビューション数を振り返って、2024年後半のモチベーションにつなげてもらえると嬉しいです。 キャンペーン期間中にXでシェア後にフォームから応募することで「Anker充電器（Findyオリジナルデザイン入り）」が抽選で当たるかもしれません！ 👇👇👇 コントリビューション・オブ・ザ・イヤー2024中間発表を試してみる

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 弊社では遠隔地フルリモートで働いているメンバーが多数おり、北は北海道から南は福岡まで、全国各地に点在しています。 本社は東京にあって関東在住のエンジニアも多数おり、遠隔地フルリモートの人数の比率で言うと半々くらいでしょうか。 実を言うと、弊社のフルタイム勤務でのエンジニアの遠隔地フルリモート勤務の第一号は私なのです。 2020年7月にJOINしてから４年以上、ずっと福岡から遠隔地フルリモートで働いていますが、第一号の私が結果を出すことで「出社・フルリモート関係なく成果が出るよね」と思ってもらうために、当初は本当に頑張りましたｗ 結果として弊社では、「ハイスキルなエンジニアであればフルリモートでも問題ない」という認識になり、遠隔地フルリモートで働くエンジニアが増えていきました。 そこで今回は、私がフルリモート勤務をする上で心がけていることを公開しようと思います。 それでは見ていきましょう！ 心がけてることリスト とりあえず自分のtimesになんか書く わからないこと。上手くいったことは全力でアピールする メンションには最優先で反応する テキストと通話の使い分け とはいえ出社も大事だよね？ まとめ 心がけてることリスト とりあえず自分のtimesになんか書く 弊社ではエンジニアを中心にSlackで自分自身のtimesチャンネルを持つようにしています。 timesチャンネルは一般的に使われている運用方法ですが、「開始します」「終了します」だけの書き込みになってしまっている人はいませんか？ このtimesチャンネルの使い方というのが重要で、 とりあえず自分のtimesになんか書く ということを心がけています。 つぶやく内容は何でもいいです。無言よりは数万倍マシです。 フルリモート勤務だと出社メンバーの顔も、他のフルリモートメンバー同士の顔も見えないので、お互いに存在感を出すことが重要です。 そのため、自分自身に割り当てられたtimesチャンネルで好きなようにつぶやくことが、フルリモート勤務でのコミュニケーションの1つの形だと思っています。 作業ログ的に自分の作業をtimesに記録することもオススメです。作業途中に詰まった時などに、timesを見てくれた他のメンバーが助け舟を出してくれることがあります。 timesが無言なのはダメゼッタイ。 わからないこと。上手くいったことは全力でアピールする 自分が何に困ってるのか、何に苦しんでいるのかは、自分から発信します。 先ほど紹介した自分のtimesチャンネルに書いてもいいですし、そこから直接メンションして誰かに助けを求めるのもいいでしょう。 作業に詰まって１人でずっと悩んで結果的に1日潰しました。はオフィス出社でもそうですが、フルリモート勤務においては特に信頼を大きく失ってしまいます。 わからないことだけじゃなくて、解決したこと、上手くいったことは特に全力でアピールします。 嬉しいことは形に残ったほうがいいので、timesにガンガン書き込みます。 周りのみんなも全力で祝福しましょう。 わからないこと、上手くいったことといったような作業の進捗に関わる発信は都度行うようにしています。 メンションには最優先で反応する 何かしらの作業をしていても、自分へのメンションを優先してチェックします。 今の作業に集中したいなら、「あとで確認する」旨を相手に伝えたり、リアクションアイコンを付けます。 「メンション送ったのに反応が何もない」ということは、相手からしたら「無視されてる」のか「忙しくて見れてない」のかが分かりません。 まずは「あなたのメンションを見てますよ」ということを伝えます。 テキストと通話の使い分け テキスト、通話でのコミュニケーションを適切に使い分けることを心がけています。 テキストでのコミュニケーションだけではどこかしらで必ず限界がきますが、テキストにも形に残る、非同期でコミュニケーションできるといったメリットもあります。 これは誰が相手でも、自分がどれほどテキストコミュニケーションが上手いと思ってても、必ず限界があります。 あ、これ伝わってないなと察したり、認識が一致していないと感じたらハドルやZoomで繋いで通話をします。 その際、議事録的なものを書いて対面で話した内容のサマリを議事録として形に残します。その議事録を後で相手に送り、認識が合ってるかどうかを確認します。 議事録は必要があれば他メンバーが見える場所にも共有します。そうすることで何の話をしていたのか、何で困っていたのかを他のメンバーが把握できるようになります。 また、テキストは後々まで形に残るので、相手への感謝や称賛はテキスト、リアクションで送ります。 逆に文脈を口頭で伝えたほうがよい話、ネガティブな話は対面で、ハドルやZoomを使います。自分が言及されているのを他の人に見られたり、後々まで形に残るのは良い気分ではないです。 あと自分の場合は、不定期に自分のtimesチャンネルのハドルを開いて雑談をする「お茶会」を開いています。 なんか話したい、雑談したい、相談したいことがあるなど、動機は何でもOKです。エンジニア以外の職種の子が参加してくれることもあります。 とはいえ出社も大事だよね？ ここまでフルリモート勤務での話を書いていましたが、やはり出社しての対面コミュニケーションに勝るものはありません。 遠隔地フルリモートで勤務していたとしても、1年に数回は出社して対面コミュニケーションを取るようにしています。 自分の場合は4ヶ月に1回程度、費用は会社持ちで1週間程度出社しています。 その期間は自分の作業よりも出社メンバーとの対面コミュニケーションを重視しています。 この期間での対面コミュニケーションにより、帰宅後のお互いのコミュニケーションのハードルが下がり、結果的に意思疎通がスムーズになります。 まとめ いかがでしたでしょうか？ 今回の記事が、フルリモート勤務での悩み事に少しでも役に立てれば幸いです。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 2024年の2月末に弊社テックブログを開設してから半年が過ぎようとしています。 今年は上半期だけで31個の記事を投稿しており、テックブログを開設してから6月いっぱいまでで週に1~2記事のペースで投稿できています。 また総PV数は10万PV、はてブ数は1200を超え、多くの方に読んでいただいているようです。いつもありがとうございます！ イベントでお会いした方や、弊社に応募していただき面接でお会いした方からも「テックブログ読んでます！」と言っていただけることが増えてきており、改めて技術広報の重要性を感じています。 そこで今回は、2024年上半期の弊社テックブログの振り返りと称しまして、2024年上半期の人気記事達を紹介します。 それでは見ていきましょう！ 2024年上半期の人気記事 【エンジニアの日常】エンジニア達の自慢の作業環境を大公開シリーズ 開発生産性指標を向上させるためにやってはいけないアンチパターン 開発生産性を上げるために開発をする前に考えていること Findyの爆速開発を支えるテクニック Findyの爆速開発を支える「システムを守るテストコード」の実例3選 Wallaby.jsを使ってフロントエンド開発のテストを効率化しよう ファインディにエンジニアとして入社していいなと思ったこと3選 まとめ 2024年上半期の人気記事 【エンジニアの日常】エンジニア達の自慢の作業環境を大公開シリーズ tech.findy.co.jp 弊社テックブログの最初のターニングポイントとなった記事です。おそらくこのシリーズが出ていなかったら、総PV数が10万を超えることはなかったでしょう。 2月末にテックブログを開設してから1ヶ月程度が経った頃にPart1が公開され、想定以上の反響があったため、Part2、Part3と続けてシリーズ化された人気シリーズの1つです。 もともとテックブログを開設した理由の1つに、エンジニア採用を強化したいという狙いがありました。 採用を強化する上で技術的な発信は重要ですが、それと同じくらい文化の発信も重要だと考えており、まずはどんなエンジニア達が働いているのかを知ってもらいたいという思いからこのシリーズを企画しました。 おかげさまで多くの方に読んでいただき、上半期のPV数の3割はこのシリーズが占めています。 内容としましては、弊社エンジニアたちの自宅での作業環境を写真付きで紹介しており、ガジェットやキーボード、デスク周りのアイテムなどが紹介されています。 ちなみに記事のタイトルですが、タイトルを考えるのに行き詰まった私がChatGPTにタイトル案をいくつか生成してもらい、その中から選んだものですｗ いや〜生成AIって便利ですね！ 開発生産性指標を向上させるためにやってはいけないアンチパターン tech.findy.co.jp 記事単体のPV数としては上半期1位の記事です。 開発生産性を向上するためにやったほうがいいことは多くの記事が発信していますが、こちらはその逆でアンチパターンを紹介しています。 一見、「そんなの当たり前やろ」と思うかもしれませんが、その当たり前をきちんと明記したことに価値があると思います。 やってはいけないことを理由付きできちんと説明できるからこそ、正しい方法を理解、実行できるのです。 開発生産性に興味関心がある方には是非一読していただきたい記事となっています。 開発生産性を上げるために開発をする前に考えていること tech.findy.co.jp 記事単体のはてブ数としては上半期1位の記事です。 こちらも開発生産性に関する記事で、実際にコードを書く前にやるべきこと、準備すること、考えることを紹介しています。 いかに速く、シンプルに、効率よくリリースしてユーザーに価値提供をするか、という視点で書かれており、開発において重要なポイントがまとめられています。 Findyの爆速開発を支えるテクニック tech.findy.co.jp 弊社は開発生産性、とりわけ開発スピードには非常に拘っています。 この開発スピードを継続し、更に速くするために弊社で実践しているテクニックをいくつか紹介しているのがこの記事です。 タスクの分解の仕方やPull requestの粒度、テストコードの考え方などをシンプルにまとめている記事となっています。 開発生産性の向上に着手したいけど何から着手したらいいのかわからない。という方には是非読んでいただきたい記事です。 Findyの爆速開発を支える「システムを守るテストコード」の実例3選 tech.findy.co.jp 先ほど紹介した「Findyの爆速開発を支えるテクニック」の記事で紹介したテストコードに関する内容を更に掘り下げた記事となっています。 実際のテストコードを交えて、具体的にどのようなテストコードでシステムを守るのかを説明しています。 実際に読んでみると、抜け落ちていた視点などもあるかと思いますので、ジュニアエンジニアの方にもシニアエンジニアの方にも是非1度読んでいただきたい記事です。 Wallaby.jsを使ってフロントエンド開発のテストを効率化しよう tech.findy.co.jp Wallaby.jsはフロントエンド開発において非常に便利なツールです。 多数のIDEに対応しており、ほぼリアルタイムに修正内容を反映しつつテストコードの実行結果を表示してくます。 この記事では、Wallaby.jsの使い方や設定方法、実際にどのように活用しているかを紹介しています。 フロントエンドのテストコードを書くのが苦手だったり、テストコードをもっと効率的に書きたい！と思ってる方にオススメの記事です。 ファインディにエンジニアとして入社していいなと思ったこと3選 tech.findy.co.jp 実際に弊社にJOINしてくれたエンジニアが、入社して1ヶ月程度経ってから感じたことをまとめた記事です。 JOIN直後のエンジニアが弊社の開発環境をどのように感じているのか、どのような点が良かったのかなど、長年弊社に在籍している自分からは気づかない視点もありました。 弊社に興味を持ってくれている方には是非読んでいただきたい記事となってます。 まとめ いかがでしたでしょうか？ ここでは紹介しきれなかった記事も多数ありますので、それらも是非読んでみてください。 全体的に見て、開発生産性やフロントエンド関連の記事に対しての反響が大きかったように感じます。 下半期も引き続き、これらのトレンドを追いつつも技術的な挑戦を続け、社内の文化、雰囲気なども含めてテックブログを通じて発信できればと思います。 今後とも弊社テックブログをよろしくお願いします。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

ファインディ株式会社でフロントエンドのリードをしております 新福( @puku0x )です。 この記事では、ファインディで導入しているモノレポ管理ツール「 Nx 」について紹介します。 モノレポとは Nxとは Nxワークスペースの作成 Nxの機能 コード生成 変更検知 依存関係の管理 キャッシュ機構 自動マイグレーション まとめ モノレポとは モノレポは全てのコードベースを単一のリポジトリで管理する手法です。 monorepo.tools コードの共通化や可視化、ツール・ライブラリの標準化、一貫性のあるCI/CDパイプラインを構築できるといったメリットがあります。また、マイクロサービスと相性が良いとも言われています。 circleci.com ファインディでは主にフロントエンド系のリポジトリをモノレポとして運用しています。 アプリケーションとそれに関連するフィーチャー、UIライブラリがひとつにまとまっているため、複数のリポジトリを移動することなくコードを参照できます。 Nxとは Nx はモノレポ管理やアプリケーションのビルド、テストの実行、コード生成などの機能を備えた統合的なツールです。 nx.dev モノレポ管理ツールは他にも Lerna や Turborepo などがあります。アプリケーション開発において有用な機能が多くあることや、コミュニティが活発で継続的なメンテナンスが見込めること、前職で導入実績があったことなどがNxを選んだ理由です。 後述する「変更検知」や「キャッシュ機構」といった機能は、Pull Requestの粒度を細かくするファインディの開発スタイルと高い親和性があり、導入当初から私達の開発を支える頼もしいツールとなっています。 大手企業でも採用事例が増えており、Nxはモノレポ管理ツールとして有力な選択肢といえるでしょう。 https://npmtrends.com/lerna-vs-nx-vs-turbo （個人的に推していたOSSがここまで有名になったことには感慨深いものがありますね！） Nxワークスペースの作成 create-nx-workspace を実行するとワークスペースを作成できます。 Reactをはじめ、メジャーなフレームワーク用のプリセットもあるためすぐに開発を始められます。 npx create-nx-workspace@latest <ワークスペース名> --preset=react-monorepo --appName=<アプリケーション名> --bundler=webpack --e2eTestRunner=playwright --style=scss --nxCloud=skip 詳細は公式のチュートリアルをぜひご覧ください。 nx.dev Nxの機能 コード生成 nx generate コマンドでプロジェクト（アプリケーションやライブラリ）を作成できます。 npx nx generate @nx/react:application --name=<アプリケーション名> --directory=<ディレクトリ> --routing=false --e2eTestRunner=playwright --projectNameAndRootFormat=as-provided npx nx generate @nx/react:library --name=<ライブラリ名> --directory=<ディレクトリ> --bundler=rollup --unitTestRunner=jest --projectNameAndRootFormat=as-provided nx generate で実行できるGeneratorは自分で作ることもできます。 nx.dev ファインディではフィーチャー用のファイル一式を生成するGeneratorを作って開発を効率化しているチームもあります。また別の機会に紹介できればと思います。 変更検知 Nxはプロジェクト間の依存関係を自動的に算出する機能を備えています。 npx nx affected --graph を実行すると次のように依存関係を可視化できます。 npx nx affected --target=build のように指定すると、変更のあったプロジェクトとそれに依存する他のプロジェクトを全てビルドしてくれます。 nx affected は変更されたコードに関するプロジェクトのみ実行する 個人的なおすすめは、npm-scriptsやCI上で実行するコマンドを nx affected ベースにすることです。 "scripts": { "build": "nx affected --target=build", "test": "nx affected --target=test", "lint": "nx affected --target=lint", ... }, 必要なタスクのみ実行されるためスピーディーに開発できます。 依存関係の管理 Nxが持つプロジェクト間の依存関係はLintルールにも応用されます。 ファインディでは、 @nx/enforce-module-boundaries ルールを適用し、意図しない依存関係の逆転が起こらないように制御しています。 nx.dev 具体的には、各プロジェクトに次のようなタグを設定し、 { " name ": " utils ", " sourceRoot ": " libs/utils/src ", " projectType ": " library ", " tags ": [ " scope:shared ", " type:util " ] , ... } - apps/ - app1 (scope:app1) - app2 (scope:app2) - libs/ - app1/ - feature-dashboard (scope:app1, type:feature) - ui (scope:app1, type:ui) - app2/ - feature-user (scope:app2, type:feature) - ui (scope:app2, type:ui) - utils (scope:shared, type:util) .eslintrc.json に対応するルールを設定しています。 " @nx/enforce-module-boundaries ": [ " error ", { " allow ": [] , " depConstraints ": [ { " sourceTag ": " scope:shared ", " onlyDependOnLibsWithTags ": [ " scope:shared " ] } , { " sourceTag ": " scope:app1 ", " onlyDependOnLibsWithTags ": [ " scope:shared ", " scope:app1 " ] } , { " sourceTag ": " scope:app2 ", " onlyDependOnLibsWithTags ": [ " scope:shared ", " scope:app2 " ] } , { " sourceTag ": " type:feature ", " onlyDependOnLibsWithTags ": [ " type:ui ", " type:util " ] } , { " sourceTag ": " type:ui ", " onlyDependOnLibsWithTags ": [ " type:ui ", " type:util " ] } , { " sourceTag ": " type:util ", " onlyDependOnLibsWithTags ": [ " type:util " ] } ] } ] 設定したルールを図にするとこのようになります。 scope がプロジェクト間の依存関係、 type が内部のレイヤーの依存関係を表します。 @nx/enforce-module-boundaries ルールが設定されたプロジェクトでは依存してはいけないモジュールに対してエラーが表示されます。 大規模なコードベースの管理においては、モジュール同士の依存関係の制御が非常に重要であり、こういった「かゆいところに手が届く」機能を持っていることがNxの魅力でもあります。 キャッシュ機構 Nxは一度実行されたコマンドのキャッシュを保持しており、同じコマンドが実行された場合にキャッシュから結果を再現する機能を持っています。 nx.dev また、関連サービスである「 Nx Cloud 」のリモートキャッシュ機能を有効にすると大幅なCI高速化が可能です。 実際にファインディでは、キャッシュの活用で毎月1,000時間以上のCI時間を削減できました。 自動マイグレーション Nxには Codemod や Angular CLI の ng update と似たコマンドが備わっています。 nx.dev npx nx migrate latest npx nx migrate --run-migrations nx migrate を実行すると、Nx本体と各種プラグイン、 react や eslint 、 typescript などの依存ライブラリ・ツールがまとめて更新されます。 バージョンアップに伴うマイグレーションは手動で対応すると大変ですが、Nxでは自動化されています。メンテナンスの手間が省けると同時に属人化も抑えられるため重宝しています。 まとめ この記事では、Nxの概要と基本的な機能について紹介しました。 Nxは単なるモノレポ管理ツールに留まらず、「開発者体験の改善」や「開発生産性の向上」といったポテンシャルを秘めています。 ✨✨✨ Nxはいいぞ！ ✨✨✨ Nxはいいぞおじさんから伝えたいことは以上です。 より詳細な活用法やNx Cloudの高度な機能については、今後の記事で取り上げる予定ですのでご期待ください。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 突然ですが皆さんは、開発をするうえで欠かせないツールやOSSはありますか？ キーボードやマウス、マイクといった物理的なツールは机を見ればわかりますが、他のエンジニアがどういったツールを使って効率化しているかは、その人の画面を見ないとわかりません。 そのため、他のエンジニアがどういったツールを使って効率化しているのか、実は意外と知らないということが多いのではないでしょうか？ そこで今回は 推しツール紹介 と題して、弊社エンジニア達が日々の開発業務で愛用しているツールやOSSを紹介していきます。 それでは見ていきましょう！ 推しツール紹介 戸田 git-cz git-cz-for-api-developer 新福 Nx vscode-spell-checker 森 Rectangle Hammerspoon Vimium まとめ 推しツール紹介 戸田 git-cz まず紹介したいのがgit-czというツールです。 github.com このツールはnpmのパッケージで、ステップに沿って選択、入力を行うことでコミットメッセージのフォーマットを統一することが可能になります。 パッケージをインストールしてコマンドを実行すると、cliで次のような出力が表示されます。 hoge@fuga Piyo % npx git-cz cz-cli@4.3.0, @commitlint/cz-commitlint@19.2.0 ? Select the type of change that you're committing: (Use arrow keys) ❯ feat: A new feature fix: A bug fix docs: Documentation only changes style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) refactor: A code change that neither fixes a bug nor adds a feature perf: A code change that improves performance test: Adding missing tests or correcting existing tests ここでコミットの種類を選択します。 機能追加、バグfix、ドキュメント修正などの選択肢を選び、その後にコミットメッセージを入力すると、自動的にコミットメッセージが作成されます。 選択肢だけではなく、コミットメッセージの内容を入力するステップもあり、全部のステップを通ると自動的にコミットメッセージが作成されコミットを実行します。 hoge@fuga Piyo % npx git-cz cz-cli@4.3.0, @commitlint/cz-commitlint@19.2.0 ? Select the type of change that you're committing: docs ? What is the scope of this change? (See README for more details; e.g. project name): piyo ? Write a short, imperative tense description of the change: (max 188 chars) (13) update readme ? Provide a longer description of the change (press enter to skip): ? Are there any breaking changes?: No ? Does this change affect any open issues?: No ✔ Preparing lint-staged... ✔ Running tasks for staged files... ✔ Applying modifications from tasks... ✔ Cleaning up temporary files... [test-git-cz aaaaaaa] docs(piyo): update readme 1 file changed, 1 insertion(+), 1 deletion(-) 弊社では各リポジトリに導入しており、コミット時に実行することでコミットメッセージのフォーマットの統一を行っています。 フォーマットが統一されているため、リリース時のリリースノートを自動生成したり、リリース内容の分類を自動で行ったりすることが容易になります。 git-cz-for-api-developer git-czをForkして、API開発者向けにカスタマイズしたものもあります。 github.com こっちのツールを利用してコミットメッセージを作成することで、SemanticVersionに対応したコミットメッセージを作成できます。 hoge@fuga Piyo % npx git-cz-api ? Select the release type of change that you're committing: patch: patch update ? Select the type of change that you're committing: ✏️ docs: Documentation only changes ? Write a short, imperative mood description of the change: [-------------------------------------------------------------] 49 chars left patch-docs: update readme ? Provide a longer description of the change: fix hoge fuga ? List any breaking changes BREAKING CHANGE: ? Issues this commit closes: [git-cz-test aaaaaaaaa] patch-docs: ✏️ update readme 1 file changed, 1 insertion(+), 1 deletion(-) hoge@fuga Piyo % git log commit aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (HEAD -> git-cz-test) Author: test <example@gmail.com> Date: Wed Jun 26 17:27:10 2024 +0900 patch-docs: ✏️ update readme fix hoge fuga 弊社ではAPIを提供しているリポジトリで導入しています。 コミットメッセージのフォーマットが統一されているため、SemanticVersionに対応したリリースノートを自動で作成し。major updateがある場合に一目でわかるように仕組み化しています。 興味がある方は是非試してみてください。 新福 フロントエンドTech Leadの新福( @puku0x )です。好きなツールを発表します。 Nx 一番は何と言っても「Nx」です。社内のフロントエンド系のリポジトリのほぼ全てに導入しました。Nxのコア機能自体はフレームワーク非依存であるため、バックエンド系のリポジトリに導入される日もそう遠くないでしょう。 github.com 元々は前職でCRAに代わるツールを探していたことがきっかけで触れるようになりました。今ではCI高速化に欠かせない存在となっています。Nxはいいぞ。 余談ですが、Nxで作成したプロジェクトには、VS Code拡張として「vscode-jest-runner」が推奨されています。 github.com ファイル単位でテストを実行できるので、Wallaby.jsと同じぐらい重宝しています。 Wallaby.jsをどのように活用しているか気になった方はこちらの記事もご覧ください。 tech.findy.co.jp vscode-spell-checker VS Code拡張については他にも「vscode-spell-checker」がオススメです。タイポの検出に一役買ってくれます。 github.com 設定を変更すれば、よくある英単語の他にも技術用語や固有名詞などもチェックできます。企業名やサービス名を登録しておけば早い段階でミスに気付けるため便利です。 { " version ": " 0.2 ", " language ": " en ", " ignorePaths ": [] , " dictionaries ": [ " en_US ", " project-words ", " softwareTerms ", " misc ", " companies ", " typescript ", " node ", " html ", " css ", " bash ", " npm ", " powershell " ] , " dictionaryDefinitions ": [ { " name ": " project-words ", " path ": " ./.cspell-project-words.txt ", " description ": " Project Words Dictionary ", " addWords ": true } ] } 直近のPRでのタイポに心当たりのある方はぜひ導入しましょう。 森 2024年6月に入社しました森 @jiskanulo です。 できるだけキーボードから手を離さずに作業を続ける、という観点で私が利用しているツールをご紹介します。 Rectangle Rectangle はウィンドウの移動、リサイズをキーボードショートカットやドラッグ移動で行うことができるMacOS用のアプリケーションです。 操作しているウィンドウをモニター左半分や右半分にリサイズする、最大化最小化をする、複数ディスプレイを接続している場合に別ディスプレイへ送る、ということができます。 私の場合は次のようにショートカットを設定しています。 ショートカット ふるまい Ctrl + Shift + Alt + h ウィンドウをモニター左半分にリサイズ Ctrl + Shift + Alt + l ウィンドウをモニター右半分にリサイズ Ctrl + Shift + Alt + j ウィンドウをモニター中央半分にリサイズ Ctrl + Shift + Alt + s ウィンドウをモニター中央に配置 Ctrl + Shift + Alt + k ウィンドウを最大化 Ctrl + Shift + Alt + ← ウィンドウをモニター左上にリサイズ Ctrl + Shift + Alt + → ウィンドウをモニター右下にリサイズ Ctrl + Shift + Alt + ↓ ウィンドウをモニター左下にリサイズ Ctrl + Shift + Alt + ↑ ウィンドウをモニター右上にリサイズ Ctrl + Shift + Alt + n ウィンドウを次のディスプレイに移動する Ctrl + Shift + Alt + p ウィンドウを前のディスプレイに移動する Hammerspoon Hammerspoon はツール操作を自動化するためのMacOS用のアプリケーションです。 キーボードショートカットの組み合わせでアプリケーションを操作、alertの実行などをLuaを記載して定義できます。 主に ターミナル Alacritty とメモツールの Obsidian を起動、最小化、最大化するショートカットを登録しています。 Gitの操作やコマンド実行したいときにAlacrittyを画面最大化しコマンドを実行終えたら最小化、メモを残しておきたいことがあればObsidianを起動してメモを記述し元の作業に戻る、というように使っています。 ショートカット ふるまい Ctrl + Command + 6 Alacrittyを全画面に表示、もう一度押すことで最小化 Ctrl + Command + 7 Obsidianを全画面に表示、もう一度押すことで最小化 Vimium 最後に Vimium です。これは名前の通りにViのキーバインドのようにキーボードだけでブラウザを操作するGoogle Chrome拡張機能です。 ページ上のリンク要素を表示してキー入力で開く、ブラウザ履歴の戻る進む、前後のタブに表示を切り替える、ブックマークを検索してタブを開くなどの操作が行えます。 ブラウザ履歴の操作は標準のショートカットでも可能なのですが、Vimiumの設定で右手だけで無理なく操作が行えるようにしているのでインターネット閲覧が快適になります。 とくにリンク要素の表示機能はマウスカーソルを細かく操作せずにリンク要素を開くことができるので重宝しています。 ショートカット ふるまい f リンク要素の一覧を表示、さらに表示されたキーを押してリンク先に遷移 Shift + f リンク要素の一覧を表示、さらに表示されたキーを押してリンク先を別タブで開く Shift + h ブラウザ履歴を戻る Shift + l 前のタブを表示する Shift + j 次のタブを表示する Shift + k ブラウザ履歴を進む まとめ いかがでしたでしょうか？ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは。 Findy Freelance の開発をしている中坪です！ この記事は 自慢の作業環境を大公開シリーズ の Part 5 になります。 今回はそれぞれ住む場所や普段担当するプロダクトが異なる 3 名のエンジニアの作業環境を紹介します！ 作業環境を大公開 中坪 まずは名古屋からフルリモートワークをしている中坪の作業環境です。 デスク全体はこのようになっています。 デスクは FlexiSpot EF1 を使っています。 ボタン 1 つであらかじめ設定しておいた高さに自動で昇降してくれるので、気軽に立ち座りを繰り返すことができます。 ディスプレイは LG 35WN75C-B を使っています。 シンプルに画面が広くて作業しやすい点とデスクのサイズにちょうどよく収まっている点が気に入っています。 机の上、左側にはポモドーロタイマーと Amazon Echo Show があります。 このポモドーロタイマーは振るとカウントダウンが開始されて、90 度倒すと止まります。 特に集中して作業したいタイミングで使います。この記事もこのタイマーを使って書いています。 Echo Show は主にエアコンを操作したり、ラジオをかけたりするのに使っています。 「アレクサ。エアコンの温度 25 度にして」などと言うとその通りに設定してくれるので、リモコンを使わずに済むのが便利です。 ラジオは radiko で RaNi Music♪ をよくかけています。 音楽だけをずっとかけてくれるのがお気に入りポイントです。 デスクの右側には Anker 737 MagGo Charger があります。 毎日 iPhone、AirPods、Apple Watch を使っているのですが、それらすべてを充電できます。ワイヤレスって便利ですね。 キーボードは Keyball61 をメインで使っています。 見た目の通り、トラックボール付きの分割キーボードで、ホームポジションから全く指を動かさずにマウス操作ができるため、とても気に入っています。 一度これに慣れると、普通のキーボードに戻れないという感覚があります。 慣れていないはんだ付けに苦労しながら組み立てたので愛着も湧いています。 キースイッチは Kailh Box Silent Pink を使っています。押下圧約 35g で適度に軽く、静音性も高いので気に入っています。 また最近、 torabo-tsuki(M) という無線接続のマウスボール付き分割キーボードを組み立てました。 まだ、仕事で使えるほどキー配置と操作に慣れていないので、プライベートで練習している最中です。 以上、中坪の作業環境紹介でした！ 嶋村 Findy Team+ のバックエンド開発を担当している嶋村です！ 現在は出社とリモートワークのハイブリッドで勤務しており、作業環境はこのようになっています。 Macbook をノート PC スタンドに置き、モニタ 2 枚を配置しています。 それぞれ用途としては、Mac が Slack 用、横置きモニタがエディタ用、縦置きモニタがブラウジング用といった感じです。 Mac はノート PC スタンドの上にあるため基本的に位置は固定していますが、2 枚のモニタはそれぞれモニターアームで縦横の向きや位置などは自由に動かせる形になっています。 位置の調節がメインの用途ですが、スタンドが不要になって下のスペースが空くのでモニターアームは重宝しています。 マウスは無線のものを充電次第で交換しながら使っています。 左は安めで買った静音のマウスで、小さくクリック音が静かなのでオフィスへ持ち込むのに適しています。 右はロジクールの G Pro X Superlight で、その名の通り軽くて持ちやすいです。 また、普段 PC でゲームをしているため、大きめなマウスパッドを使用しています。 キーボードは HHKB Professional Type-S の無刻印モデルを使用しています。 7~8 年使っていて色が少々汚いのはご容赦ください。 奥に見えるのは Realforce GX1 で、デスクトップ PC 用途です。 静電容量無接点式の打鍵感が気に入っており、ずっと Realforce か HHKB がメインです。 あとは奥にチラッと映っていましたが、水を入れるだけで使える陶器の加湿器を置いています。 加湿効果としては通常の加湿器には及びませんが、電源不要で水を入れ替えるだけでよいのと、見た目がかわいいので気に入っています。 以上、嶋村の作業環境でした！ 松本 Findy のフロントエンド開発を担当している松本( @bennkyougirai )です。普段は福岡からリモートワークをしています。まず私の作業環境の全体像はこんな感じです。 デスクは電動昇降式で　 FlexiSpot のフレームを使っています。 ディスプレイは DELL の 4k モニタを使っています。自分にとっては少し広すぎたので、次回はもう少し小さいものを選びたいです。 モニターにはモニターライト( Quntis デスクライト モニターライト バーライト )を取り付けています。コンパクトで場所を取らない、それでいて明るさも十分です。価格がお手頃なのも良いです。 キーボードは Ultimate Hacking Keyboard の分割キーボードを使っています。左右のキーボードにはオプションパーツを装着できて、左にはマウスクリックボタン、右にはトラックパッドを追加しています。キーボードの設定の自由度も高くて、カスタマイズしやすいのが特徴です。 マウスは MX Ergo と Apple Magic Trackpad を使っています。メインは MX Ergo を使っていて、Apple Magic Trackpad はマウスジェスチャーや Miro のようなスクロール操作が必要なアプリで使用しています。 業務での通話には、 OpenComm を使っています。長時間使用しても疲れづらく相手に届く音質も良いので気に入っています。私の使用しているのは 1 つ古い型ですが、最新のものも良いものが出ているので興味がある方は是非チェックしてみてください。 まとめ キーボードなどもそれぞれ個性的でこだわりが感じられました！ 個人的には松本さんと嶋村さんのキーボードを見て、バックライト付きのキーボードにロマンを感じました。 また、ノート PC をスタンドに置いて使うスタイルも試してみたいと思いました。 ブログを読んでくださっている皆さんの作業環境構築の参考になれば幸いです！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは！ファインディ CTOの佐藤( @ma3tk )です。 表題の通り、約1年半ほどの期間をかけて「エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～」(以降、開発生産性の教科書)という本を執筆しました。 本日(2024年7月11日)発売となりましたので、改めて「開発生産性」に対する思いをお伝えしたり、本の内容の一部をご紹介したいと思います。 「開発生産性の教科書」のご紹介 エンジニア組織を強くする 開発生産性の教科書 本の概要は次のとおりです。 項目 詳細 タイトル エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～ 著者 佐藤 将高、Findy Inc. 発行 技術評論社 定価 2,860円（税込） 発売日 2024年7月11日 ISBN 978-4297142490 購入 Amazon / 楽天ブックス 全国書店、その他オンライン書店 電子版 Gihyo Digital Publishing / Amazon / 楽天ブックス 全国書店にてお買い求めいただけますので、是非チェックしてみてください。 そもそもなぜ本を執筆しようとしたのか 元を辿ると、2019年末頃から Findy Team+ (当時はFindy Teams)というサービスを僕が開発し始めた時に遡ります。 「エンジニア組織で困っていることってなんですか？」 この問いをおおよそ20〜30社のCTOやVPoE、開発部長やEMの皆様とお話してきました。 エンジニア組織課題を深堀りさせていただく中で、よりよい組織を作っていきたいという思いを受け取りました。少子高齢化や開発内製化の動きを受けエンジニア採用が難しくなる中で、在籍しているメンバーの技術力を向上し、組織の開発生産性を向上させることに興味関心をいただきました。 「何をどうしたら組織が良くなるのかがわからない」 「生産性を上げる必要があるが、初手に困っている」 お伺いする中で、開発生産性の向上に直結する打ち手で迷うことが多いと学びました。ファインディでも開発生産性の向上をどう実現するか、Findy Team+のサービス利用者の悩みを解決するお手伝いをさせていただいたく上でどう価値提供ができるかを模索し続けてきました。 「開発生産性」の理解が難しいように感じてしまう サービスを通じた価値提供を続ける中で自分自身が感じたことは、「開発生産性という言葉は多義語で、どう定義するといいのかわからない」ということでした。 開発生産性についてずっと調べ続けていくと、Four KeysやSPACEといった概念が出てきて混乱したり、「数値化して本当にエンジニアにとって嬉しいのか？」というような疑問を自分自身でも考えるようになりました。今となっては理解が進みましたが、初学のタイミングでは整理に時間を要しました。同じように難しく感じてしまう方もきっといらっしゃると思います。 開発生産性についてどこかで学んだことがある方は多くはないはずです。1年ほど前からエンジニアの方を始め、プロダクト開発に関わる様々な方・経営者の方に開発生産性に関する知見を共有するためには本を書くことで「開発生産性に対しての理解を向上する」ことが実現できそうであると思い立ちました。 今回の本では、「開発生産性」という言葉の難しさを少しでも紐解き、どんな組織でも取り組みやすい入門書として出版するに至りました。 「開発生産性を上げるために大事なこと」を多くの人に知ってもらいたい Findy Team+のサービスをリリースする中で、「監視されるのではないか？」「数値を可視化するリスクがあるのではないか？」というご意見が特に多いです。 本書によって開発生産性を向上させるための認識を統一し、誤解を減らしたいと思っております。本書の中にも「監視するのではなく、認識を揃える」という内容も記述しています。 組織の定量化にフォーカスが当たりがちですが、開発生産性を上げて顧客に価値を多く提供することや、もっと言えば売上やKPI向上へつながるような開発に集中できることが大事だと思っています。そのため、定量化そのものよりも定量化して過去と比較することで「どこに課題がありそうか？」を知るための道しるべのようなものかと思っています。 開発生産性指標を向上させるためにやってはいけないアンチパターン - Findy Tech Blog の記事にも書いているように、数値に影響しないようにハックをすることではなく、現在のプロダクト開発においてどこがボトルネックかの目星をつけ、定量的にすることで他者との認識を揃えることが本質だと思っています。 数値だけを追ってしまうと監視につながってしまいかねませんし、数値に現れにくい「社内のメンバーの積極的なヘルプ」や「積極的なミーティングのファシリテーション」などを誰もやらなくなってしまいます。これでは本末転倒ですね…！ こういった誤解や誤用があるため、本書によってそれを少しでも減らしたいと考えています。そして、これまで以上に事業貢献につながる開発ができる世の中で溢れてほしいと考えています。 本書の特徴：入門から実践まで網羅している教科書であること 改めて、本書の特徴としては大きく3つあります。 1. 体系的に整理された開発生産性の知識が学べる 前述したようにFindy Team+の開発を通じて、プロダクトオーナーとして「開発生産性」について色々調べてきました。しかし、「開発生産性」について体系的にまとまっているものがあまりなかったため、改めて自分の理解度向上も兼ねてまとめなおしました。 2. 実践への第一歩として、始めやすさにフォーカスした 海外の訳書などはアカデミックに研究が重ねられており、非常に良質な本があります。特に、 LeanとDevOpsの科学 は「開発生産性」について学ぶうえで是非読んでほしい一冊です。一方でどう始めるとよいのかについて自分はもっと情報が欲しかったこともあり、「開発生産性の教科書」は取っ付きやすさを大事にし、具体的にどうするといいのかを私自身の実体験や企業事例を交えながらなるべく読みやすい言葉遣いで記載しています。是非どちらも読んでいただくと「開発生産性」に対する理解が深まると思います。 3. 成功へのヒントとして事例を5社集めまとめた また、ファインディ社を含め5社の事例を集めました。 BuySell Technologies社：生産性の高さをIR資料に掲載し、社内外での評価を高めたことで、エンジニア採用にも好影響を与え、候補者からの関心を引いたお話 ツクルバ社：開発生産性を向上させるための基盤を作ったことで、iOSアーキテクチャの改修プロジェクトを成功させ、変更行数の削減やサイクルタイムの短縮を実現したお話 クラスメソッド社：開発生産性を向上させるための予算獲得や施策実行をしたことで、エンジニア組織全体のモチベーションも向上し、エンジニアリングの効率化と品質向上を実現したお話 ワンキャリア社：SPACEフレームワークの実現や毎日のリリース体制への移行を進めたお話 ファインディ社：CI時間の短縮やテストコードの拡充によるサービスの安定性と開発フローの改善の話 具体的にどう進めるとどんな効果があるかについても読める一冊に仕上げております！ また、執筆にご協力いただいた各社のご担当者様に、心より感謝申し上げます。 開発生産性の向上とこれから 本記事では開発生産性の教科書の一部をご紹介させていただきました。 開発生産性を向上することで、個人の市場価値も上げられたり、組織のKPI/売上がよりよいものになるだけではなく、組織そのものの雰囲気がよくなることにもつながってくるはずです。あくまでも数値は健康指標として扱いながら、課題を見つけ出し解決に向けて進めることが大事だと思っています。 ファインディは「挑戦するエンジニアのプラットフォームをつくる」というビジョンの元、様々なエンジニアの皆さまやエンジニア組織においてより前向きに挑戦できる環境を一緒に作れたらと思っています。 改めて、今回の本を執筆するにあたりご協力いただいた方・編集の皆様、ありがとうございました。「開発生産性の教科書」が皆様の挑戦に役立てられたら嬉しいです。是非興味を持っていただけたらお手元にとっていただけると幸いです。 購入は以下からどうぞ！ Amazon 楽天ブックス 全国書店、その他オンライン書店 また、こういったイベントもありますのでよかったらご参加どうぞ〜！ d-plus.connpass.com