ID:63991さん

# 概要 弊社のとある転職サイトでは、求職者がアプローチされたくない企業を登録することができます。 弊社サイトにまだ登録していない企業も事前にアプローチ禁止にしておきたいというニーズから、従来はアプローチ禁止にしたい企業の名前を登録しておいて、その文字列に企業名が部分一致したらアプローチ禁止にするというロジックを実装していたのですが、企業名はかなり重複するため、アプローチ禁止にしたくない企業もアプローチ禁止になってしまうという問題が発生していました。 そこで、さまざまな方法を検討した結果、国税庁が提供している API を参照し、アプローチ禁止にしたい企業の法人番号を弊社DBに保存しておくことで、弊社サイトに登録していない企業もアプローチ禁止にすることができるようにしました。 # チーム構成・担当した役割 この問題を提起してくださった方やデザイナーの方と相談し、私が仕様決定から実装までを担当しました。スタイル調整についてはデザイナーの方にお願いしています。 # 技術的なアプローチ 国税庁の API が CORS を許可していなかったことから、 Rails の API から国税庁の API に問い合わせる方法を取りました。Rails の API がアプローチ禁止と設定した企業の一覧を返してくれるようにし、Vue.js のコンポーネントで受け取ることで、リアルタイムで設定が反映されるようにしています。 また、従来の文字列によるアプローチ禁止設定からの移行のため、全ユーザーに対してアプローチ禁止企業を設定しなおす Rake タスクを実装しました。実行時間の観点から国税庁の API への問い合わせ回数はできるだけ減らしたく、ユーザー単位でまとめて国税庁 API に問い合わせを行いたいと考え、設定された単語の全探索ではなく、ユーザーの全探索を行う方針としました。 # 成果 法人番号を軸としたアプローチ禁止企業設定の仕組みを構築することができました。 また、従来の文字列ベースでのアプローチ禁止企業設定の仕組みを廃止したことで、分かりにくいテーブル名が並んでいたり、ロジックの解読に苦労したりする状況を改善でき、システムのロジックの見通しがかなり良いものとなりました。 本取り組みについて、企業テックブログに記事を書きました。 https://made.livesense.co.jp/entry/2023/07/26/083000

# 目的・背景 現在開発を担当しているプロダクトでは、様々な職種の人が要件を定義する体制になっています。そのため、仕様書を作成する際にデザイン関連のすり合わせを行う工数を削減したく、デザインシステムを構築しようという機運が高まっています。 CSSフレームワークとしては Bootstrap, Inspinia を使用していますが、Bootstrap では見た目のスタイルと配置用のスタイルが分離されておらず、スタイルを柔軟に指定することが難しいという課題があります。そこで、Bootstrap を剥がして TailwindCSS を導入することになりました。 デザインコンポーネントの作成などはデザイナーが実行する予定ですが、その前段階として、Bootstrap と TailwindCSS が同居した状態を構築する作業を担当しました。 # 課題 担当プロダクトではビルドツールとして esbuild を使用しており、既存のビルドフローに影響を与えないように TailwindCSS を導入する必要がありました。結局、 application.scss で TailwindCSS のライブラリをインポートさせることで解決しました。 また、TailwindCSS では、ビルド後の CSS ファイルの容量を削減するため、テンプレートファイルで使用済みのユーティリティクラスのみをビルドするという機能があります。これによって、今まで使っていなかったユーティリティクラスを新たに使用しようとする場合に、明示的に esbuild でのビルドを再実行してあげる必要がありました。これを解消するために、今まで js や scss, css のみを監視していた chokidar で slim ファイルも監視してあげるようにし、slim ファイルが更新されたら esbuild でのビルドが実行されるようにしました。 また、プロジェクトの進捗管理として、作業内容の大枠が見えてきた段階でマイルストーンを設定し、進捗と期限の対応関係を見れるようにして進めました。 # 成果 7月頭に始動し、8月末までの導入を目指していましたが、予定を前倒しして8月頭に完了することができました。 現在デザイナーがコンポーネントの構築などを行っていますが、特に TailwindCSS を使用するにあたって不便などの報告はいただいていません。 本取り組みについて、企業テックブログに記事を書きました。 https://made.livesense.co.jp/entry/2023/08/10/083000

# 概要 弊社のとあるプロダクトでは、毎月イベントを開催し、ユーザーがそのイベントに参加することが収益の源泉となっています。 イベントに参加するユーザーを増やして収益拡大を目指すため、次回のイベント参加意思を確認するためのモーダルに、イベントのトピックスを掲載するプロジェクトになります。 # 担当 プロジェクトオーナーは別の方が担当してくださっていますが、私は 企画〜実装〜効果検証 を一手に担っています。 プロジェクトオーナー1人、開発者1人（私）、アドバイザー1人 の3名で実施しているプロジェクトになります。 # 使用技術 Ruby on Rails / Vue.js / MySQL # 技術的なアプローチ - Rails でイベントのトピックス情報を取得し、Vue.js で実装されたコンポーネントに渡しています。基本的に、次回のイベントで表示するべき情報を厳選し、それをもとに Rails 側で情報を取得するロジックを適切に定義する作業になります。 - 私がプロジェクトに加入する以前は AB テストを行なった実績がなかったため、AB テスト実行のための社内サービスを活用して AB テストが行えるようにしました。 # 工夫した点 - ロジックは頻繁に変更される一方で、複数のロジックで共通に用いられる条件も存在するため、一つ一つのロジックを ActiveRecord の scope として切り出し、ロジックごとに組み替えができるようにしました。イベントの参加登録終了から次回の参加登録開始までの時間が長くない中で、毎月連続してロジックを変更する助けとなりました。 - グロース施策は試行回数を稼ぐことが大切だと考えているため、AB テストを導入することにしました。月に一度のイベントに対してモーダルが表示されるため、例えば上半期を通して参加ユーザー数を向上させたいとしても、毎月1つのロジックしか実装していなければ最大でも6ロジックしか試すことができません。ABテストを導入して、場合によっては一度に3ロジックを戦わせたりすることで、月に一度のイベントでも多くのロジックを試すことができるようになりました。 # 結果 AB テストの結果、次回のイベント情報を表示しないパターンが勝利し、イベント意思確認モーダルが表示された段階ですでにユーザーの参加意思はほぼ固まっているという結論になりました。 本施策によって参加者数を向上させることはできませんでしたが、芽がない施策を早く切り捨て、可能性のある施策に移ることができたのは成果の一つかと思っています。

# 概要 弊社のとあるサービスにおいては、長らく自前のシステムを使って請求計上処理を行なっていたのですが、自前のシステムゆえ、手動での運用が発生せざるを得なかったり、法律改正のたびに大規模なシステム改修プロジェクトを立ち上げなければならなかったり、退職者が多くて全ての仕様を把握しきれていなかったりと多くの問題がありました。そこで、サービスの請求計上部分だけを外部サービスに切り出し、請求計上処理の信頼性を向上させるプロジェクトを立ち上げました。 # 担当 開発チームのメンバーとして、システム構成の設計とバックエンド開発を担当しました。 プロジェクト全体としては8名、そのうち開発チームは3人でした。プロジェクトの後半から、開発チームの代表をするようになりました。 # 使用技術 Ruby on Rails / MySQL # 技術的なアプローチ - 請求計上に必要な情報を必要に応じて分割して取得し、外部サービスに POST する Rails の API を作成 - 外部サービス上にスクリプトを実装し、Rails から送信された情報をインポート # 工夫した点 - 法律改正対応のためリリース期限が定められており、またその期限が差し迫っていたので、請求計上処理の作業者と連携し、必要最低限の実装を行う方向で調整しました。例えば、Rails の API を実行するためのGUIなどは作成せず、 Chrome 拡張の HTTP クライアントで POST リクエストを行うようマニュアルを作成し、リクエストがエラーになったらエンジニアに連絡をしてもらうという体制を構築しました。 - 外部サービスの API を実行してレコードを送信する方法では一度に送信できるレコード数に制限があったため、Rails 側ではカンマ区切り文字列を送信し、外部サービス側でカンマ区切り文字列を CSV に変換してインポートする設計としました。 - 今回導入した外部サービスに対する知見が社内になかったため、運用側も含めてスクラムを組み、外部サービスの仕様調査も含めてチケット化し、スプリントを回していました。 # 成果 担当するプロダクトがサービス終了となったため、それに合わせてこのプロジェクトも道半ばで解散となってしまいました。 ただ、個人としては、途中から開発チームの代表を務めていたことで、技術面や、主体性などのマインド面での成長をすることができました。

# 概要 Ruby は毎年新しいマイナーバージョンがリリースされ、それに伴い毎年マイナーバージョンが EOL となる傾向にあります。運用しているプロダクトの Ruby のバージョンがこのスケジュールに遅れをとっていたため、バージョンアップ対応を行いました。 メジャーバージョンアップ、マイナーバージョンアップを1つずつ実行しました。 # チーム構成 基本的に実装からエラー監視までひとりで行いました。打鍵の部分だけダブルチェックが必要だったため、他部署の方にご協力いただいています。 # 関連する技術 Ruby / Ruby on Rails / Docker / docker-compose / CircleCI / GitHub Actions # 技術的なアプローチ 基本的に、以下のようなアプローチで実行しました。 1. バージョンを上げる前に、自動テストで Warning を発生させ、それを解消する。 1. Warning に対応しきったらバージョンを上げてみて、自動テストが落ちる箇所を修正する。 1. 自動テストが落ちた箇所の修正が終わったら、プロダクト全体にわたって打鍵を行う。 1. リリース後、一定期間は他のリリースは控えてエラーを監視する。 自動テストはある程度は実装されているものの、プロダクト全体が十分網羅されているとは言えないため、自動テストで賄えない部分の画面を手動で確認するプロセスが必要になりました。 打鍵項目は多岐にわたったため、その洗い出しを行う過程に最も苦労しました。 # 成果 バージョンアップそのものが成果と言えますが、打鍵の過程で不必要なメソッドが定義されていることに気づいたり、一度も実行されていなくて気づかれなかったバグを発見したりと、システム全体の改善点の洗い出しを行うこともできました。 別のメンバーが対応した Rails のバージョンアップと合わせて、開発者体験を向上させることもできました。

# 概要 社内のエンジニアが継続的に情報発信をする助けになるように、エンジニア採用広報チームが発足されました。 以前よりテックブログなどの媒体は存在していましたが、それらのメンテナンスは有志によってなされており、媒体の存在自体知られていなかったり、記事の投稿数にムラがあったりする状態が長らく続いてきました。 そこで、ブログや周辺の媒体をチームで管理することで、弊社のエンジニア組織のブランディングを強化しようというプロジェクトになります。 # やったこと・成果 半期ごとに弊社の広報活動の現状を振り返り、改善したい点を列挙することで目標を設定しております。 * 記事数を目標として設定し、計画的にチームで記事を作成したところ、記事数を3年ぶりの水準に引き上げることができた。 * ブログを書くムードを高めるためのイベントを開催したり、記事内容のレビューやアドベントカレンダーの開催など、記事を書くためのサポートを手厚く行ったりしたことで、テックブログが前年比約2倍のPV数を記録した。 チームとして積極的に活動することで、テックブログ自体の活性化やPVの増加には貢献することができたので、現在はチームとして積極的に活動しなくても情報発信が活発になることを目標に活動しております。 # 役割 中学受験国語や中学の口語文法の授業、大学院での論文執筆などで鍛えられた文章力が自分の強みだと思っており、自分の記事の執筆だけではなく、他の人の文章のレビューにもかなりの貢献をすることができていると自負しております。主語と述語の対応や、助詞の使い方、誤字脱字の修正、情報の流れがスムーズになるような文章の組み替えなどです。 また、目標設定などの文脈で、現在我々が置かれている状況を客観的に把握し、今後どういう方向性に向かうべきなのか、そのためにはどうしたらいいかを考えることにも貢献できていると感じます。

# 概要 [ソニックガーデンジム](https://www.sonicgarden.jp/sggym_202206) という、オンラインのプログラミングキャンプに参加しました。 指定された課題に対して実装を行い、ソニックガーデンの社員の方がレビューをしてくださるプログラムです。 # やったこと 要件が決まっているものをひたすら実装・レビューに対応していく流れになります。 # 学んだこと - Rails Way に則った書き方や、きれいなテストの書き方などを徹底的に叩き込まれました。自社プロダクトの開発をしていると、すでにプロダクションコードがメチャクチャになっていることもしばしばで、ゼロから実装を行なってレビューを受ける経験は貴重だなと感じました。 - テストを書くべき部分と書かなくても良い部分、モデルスペックとシステムスペックの使い分けについて解像度が上がりました。この辺りも、業務のコードではなんとなくで済ませてしまうことも多いです。

# 概要 上記ソニックガーデンジム内の個人プロジェクトとして、ネイティブアプリ開発に取り組みました。電車に乗るときに、どのドアから乗車すれば乗り換えに便利かを教えてくれるアプリになります。 もともとネイティブアプリ開発に興味を持っていたこと、できれば Android も iOS も実装したいこと、身近にレビューをしてもらえる環境が整っていたことから、 Flutter で実装しました。 バックエンドの API や LP などは Ruby on Rails で実装しています。 # チーム構成 レビュアーが数人いますが、基本的には一人で企画し、開発を行っています。 アプリのコンセプトをもとに、アイコンのデザインやアプリの色使いを決める作業にも取り組みました。 # 使用技術 Flutter, Ruby on Rails, RSpec, Capistrano, AWS, BugSnag, Inkscape

# 概要 ハッカソンに参加し、ブラウザで動作するゲームを作りました。 # 戦略 抽象的なお題を与えられ、それに沿っていればどんなプロダクトでもエントリーできるという、自由度が高いハッカソンでした。 諸事情あり個人での参加になったこと、開発できる期間が実質24時間で他のチームより圧倒的に短かったこと、受賞チームの決め方などを考慮し、できるだけ手に馴染んでいる技術でシンプルなものを作成し、アイデア勝負より完成度を上げに行く方針で臨みました。 # 関連する技術 React.js, GitHubPages React.js で実装された静的ページを GitHubPages にデプロイする方法を取りました。 # 成果 https://verdy89.github.io/h2o_block_game/ こちらを実装しました。 ハードウェアを作成しているチームが多く、結果としてはファイナリスト21チーム中9位でしたが、不利な条件にしては健闘したかなと考えています。 参加レポートをブログにまとめています: https://ryoito.jp/articles/ad0cfb89