プロダクト志向のエンジニア
「よりよいプロダクトを開発したい」という気持ちがエンジニアとしての強いモチベーションとなっています。
事業を深く知り、伸ばせることを目標としています。技術領域を深める、広げることにも関心があるため、バックエンドを中心にフロントエンド、インフラまで幅広く習得したいです。
このプロジェクト詳細は公開されていません
複数サービスで共有可能にするため、認証基盤をAuth0へ移行している。実装工数とUXのバランスを取りつつビジネスサイドと競技しながら、設計から実装まで携わっている。
担当サービスは SPA 構成のためフロントエンドのタスクが多く、フロントエンドエンジニアの作業がボトルネックとなり、作業が滞りやすい状況にあった。私自身はフロントエンドの開発経験は少なかったが、プライベートの時間を投下しキャッチアップ。JavaScript(ES6)、Vue.js、StoryBook、Atomic Design の学習を行った。業務では Rails の Haml テンプレートで実装された画面の SPA 化のフロントエンドを担当した。Atomic Design に則って、コンポーネントごとに実装し、都度 StoryBook を利用しながら進めた。結果的に、フロントエンドエンジニアの過負荷を軽減し、チームの開発速度向上に貢献できた。自身としても、技術領域を広げられ楽しい経験だった。
チーム内には OpenAPI に関する知見が少なかったため、ミーティングを開催して知見を集約。結果として、バックエンドエンジニア、フロントエンドエンドエンジニアが並行して開発をを進められるような体制づくりに貢献。
4年以上運用されているサービスであり、ローンチ当初はグロース優先のためテストコードを実装していなかった影響により、参画当初はテストコードがあまり書かれていない状況だった。API サーバーへの機能追加時に既存コードのテストコードを追加することでカバレッジを高めた。
会計システムとの連携機能の改修を、仕様策定から、開発、テストまで一気通貫で担当した。機能の具体的な内容は、データベースから受注データを取得し、会計システムの連携用に CSV データに変換するものだった。仕様策定では、業務フローから会計システムに連携するために必要な仕訳データを洗い出しなどを行い、会計の知見を活かすことができた。業務フローが複雑で実施すべきテストケースが多かったため、 全ての条件ごとに RSpec による 自動テストを用意し、デグレードしないよう配慮しながら進めリリースした。
コーディング規約が統一されておらず、チーム内で Pull Request レビュー時に些末な指摘が多くなってしまう点に課題を感じ、RuboCop を Linter/Formatter として導入。主に自動修正によって5000行をを修正しリリース。
10年来のシステムで、メンテナンスに時間がかけられていなかった影響で、ソースコードの可読性が低い状況にあった。準備として、テストが書かれていない機能にはリファクタリング実施前にテストコードを追加した。システムの中でもお金が関わるため特に重要な「請求・返金機能」に絞って、リファクタリングを実施。同内容の関数が様々な場所に定義されているため、機能・役割ごとにモジュールに関数を集約させ、呼び出し元ではモジュールの関数を使うようにして、重複したソースコードを排除した。また、使用されていない機能も多々あったため、利用状況を確認しながら該当のソースコードを削除した。
Heroku へのデプロイ時に Slack へ通知が飛ぶよう連携設定を追加した。
検索画面の検索結果は従来「更新日の降順」で表示していたが、今回の開発で次の順で表示できるようにした。
1. X週間以内に「作成」された求人を作成日の降順で表示
2. X週間以内に「更新」された求人を更新日の降順で表示
3. その他の求人を作成日の降順で表示全文検索システムの経験は Apache Solr が初めてだった。ドキュメント等でインデックス処理やクエリのシンタックスについてキャッチアップ。実装では検索回数をできるだけ減らせるようパフォーメンス面への配慮しながら進めた。検索結果総数やページネーションの観点から、単体テスト(Model Spec)で異常系・正常系のテストケースを網羅し、統合テスト(Feature Spec + Turnip)で正常系をカバーして、リリースした。
DBに格納されたデータを抽出し CSV にフォーマットし、FTPで送信する機能を担った。定期的に実行するタスクだったため、特にパフォーマンス面に配慮した実装をした。ログでクエリの結果を見ながら、N+1 問題が発生しないよう Eager loading を利用して解決した。
帳票用に DB からデータを抽出し、 CSV として出力する機能を担った。複雑な入力条件や出力条件に対応するために、業務ロジックが長大になりがちだった。「わかりやすい命名」や「関数の分割(抽出)」、「条件記述の単純化」といったプログラミングの基本を徹底することで可読性の担保を意識した。今後の設計変更に耐えうるように、テスト駆動開発によるテストファーストで進めた。また、フォーマット処理するために Ruby でのコレクションの操作(each, map, select, inject, each_with_object)の違いを理解し、副作用の有無を意識しながら実装する習慣が身についた。