テクノロジーとビジネスのハブのような存在となり、サービスを伸ばしていける人材になりたいと考えています。
新卒から営業2年半、エンジニア3年半を経験しました。
短期的にはwebエンジニアとして、技術力を高め、価値提供のできる人材になりたいと考えておりますが、
中長期的(3〜5年後)には、エンジニアリングの視点を持ちながらプロダクトの成長に貢献できるようになりたいと思います。
このプロジェクト詳細は公開されていません
技術スタック:Ruby on Rails , Ruby, Mysql, AWS,Slim,SCSS
法人開発グループで主に金融機関様向けの資産管理サービスBFMを開発しております。
スクラムマスター兼バックエンドエンジニアとして、要件定義、設計、実装を行なっております。
5名(業務委託2名、正社員3名)
スクラムマスター
アプリケーションエンジニア(メンバー)
・企画側と相談、調整し、現在のシステム状況を加味しながら、開発スケージュールの作成
・スプリントバックログの作成、管理・ストーリーポイントによるチームパフォーマンスの見える化
・採用活動への参加(一次選考、リファラル採用、募集求人の作成)
・スクラムマスターとしてスクラムイベントの運営、管理、進行、障害要因の排除
・外注先、顧客とのタスクの確認、調整
・リリーサーとしてチケットのデプロイ、リリースの管理
・バックエンドエンジニアとして、実装、テスト
クレジットカード連携機能の追加
【内容】
社内でマイクロサービス化されているクレジットカードのAPIからデータを取得し、連携機能を追加するプロジェクト
【課題】
銀行口座のみの連携からクレジットカードの連携を追加することで、ユーザーの資金状況の全体を見える化できるようにする
参加したタイミングで、進捗が芳しくなく見込みから1ヶ月弱ぐらい遅延しており、実装現状完了までのフローを認識できていなかった。
【解決策】
スクラム開発を導入して、完了までのチケットを分割し、miro,JIRAを活用しながら進捗を日次で見える化し、進捗を見える化しました。
実装面では、対象のデータのやりとりがマイクロサービス化されたAPI を介して行われていたため、dry-rb をいう gem を用いてオブジェクトの attribute を型定義し、API を介して取得されたオブジェクトと API を見える化しました。
アプリケーション規模も大きくなっていたので Rails way から離れリポジトリパターンを導入し、上記のdry-rb を用いてエンティティをしっかり型定義し、リポジトリ層 Service 層と責務をしっかり明記することでアプリケーションの見通しを良くしました。
またService層については複数のmodelに跨ったビジネスロジックを実装する場所として、チームの認識を揃え、コマンドパターンを導入し、servieの命名でどのような処理をしているものなのかを表現できるような命名にし、call()で呼び出せるようにしました。
【結果】
保守性の高いコードを、チーム全体を巻き込みながら、
納期内に実装することができました。
このプロジェクト詳細は公開されていません
アプリ上でのExcel関数の実装
【課題】
当初は四則演算のみを再帰的に処理する構造となっており、SUM、MAX、IFなどの関数拡張に対して柔軟性がなく、機能
追加のたびに大きな改修が必要となる構成だった。
【解決策】
構文解析によるExcel関数対応機能の開発を担当しました。汎用性と拡張性を重視し、構文解析器(ANTLR)を導入して、Excel関数の式全体を抽象構文木(AST)として解釈できる基盤を構築しました。これにより、新たな関数や構文の追加にも柔軟に対応できるようにしました。
バックエンドでは、SUM、MAX、COUNT、IF、AND、AVERAGEなどのサポート対象関数を整理し、関数ごとの対応可否を返却するインターフェースを設計・実装。フロントエンドでは、関数式に応じた入力フォームや挙動を動的に構成する仕組みを導入しました。
また、関数間の依存関係を解析し、トポロジカルソートを活用することで循環参照の検出を実現。数百~数千の関数が定義されるケースでも処理速度が低下しないよう、Web WorkerやKotlin Coroutinesを用いた非同期処理を取り入れ、パフォーマンスを大幅に改善しました。
さらに、Excelの制約(例:AND関数の引数は最大255個、IF関数は最大64ネスト)についても調査し、関数ごとの仕様制限を整理・反映。実装優先度や仕様の整備については、チームと議論を重ねながら進行しました。
【結果】
多数の関数に対応可能な柔軟な関数パーサーを提供することで、関数機能追加の工数を大幅に削減し、大規模シートの関数再計算においても、UIの遅延なく快適な操作性を保つことに成功しました。
技術的負債が高かった旧来のロジックを刷新し、新機能の追加や検証が容易な構造へ移行したことで、他メンバーからの改修もしやすいコード基盤を構築することができました。
タスク単位ではなく必要な機能単位でインフラからフロントエンドまでを設計、実装、テストできるプレイヤーとしての実行力を強化すること
攻撃的なコミュニケーションをとるメンバーがいないこと、全員でプロダクトを改善して作成していくという文化がある環境