職務経歴書（2023/4/26更新）

概要

• エンジニア歴：９年
• 主な担当：Webアプリ開発（フロントエンド・バックエンド）・Androidアプリ開発
• 元々はSIer、その後にWeb系企業に転職

職務経歴

2020 年 10 月〜現在：株式会社 ZAICO

株式会社 ZAICO

• 設計・開発〜リリースまで担当
• Webアプリ（Ruby on Rails）
• Androidアプリ（KotlinとJava）

Redisキャッシュ導入プロジェクト(2024/02)

概要

• RailsアプリケーションにRedisキャッシュを導入した。
• 発注点切れ在庫件数の取得に時間がかかっていたが、キャッシュを利用することで高速化した。

設計について検討したこと

• キャッシュの単位はどうする？ユーザー単位？事業所単位？
• キャッシュをどこに保存する？Redis？サーバー内？
• キャッシュの有効期限はどうする？
  など

課題・問題点

• ユーザーと在庫データはそれぞれ複数のグループに所属できる
• ユーザーは自身が所属していないグループの在庫データは参照できない
• そのため、発注点切れ在庫件数は、同じ事業所であっても各ユーザーによって異なる場合がある
• Webアプリサーバーは分散化されている

最終的に選んだ案、決め手

• キャッシュの取得単位と削除単位を分けることにした
• 具体的には、キャッシュの取得はユーザー単位で行い、キャッシュの削除は事業所単位で行った
• また、キャッシュをWebアプリサーバー内に保持すると、同じユーザーが別のWebアプリサーバーにアクセスした場合にキャッシュが共有されないため、Redisサーバーを採用した

キャッシュ導入の際の実装メモは以下にまとめています。
キャッシュ導入の実装メモ

論理在庫プロジェクト

概要

• 在庫管理アプリケーションzaicoでは現在の在庫数量と将来の入庫予定・出庫予定の数量を別々のテーブルで管理していた。
• 現在の在庫数量に将来の入庫予定・出庫予定の数量を加味した新しい数量（論理在庫と呼ぶ）を管理できるようにする。

チーム構成

• ２人チーム
• UI担当と自分。

設計について検討したこと

• 論理在庫を新しいテーブルとして管理するか？
• それとも在庫テーブルにカラム追加するか？
• もしくはカラム追加せず、表示するときに毎回計算するようにするか？
• 性能懸念はないか？
  など

課題・問題点

• 在庫テーブルは数千万件のレコードを持っており、適切に扱わないと性能懸念がある
• 在庫テーブルはアプリの根幹となるテーブルであり、安易に手を加えるのはリスクがある
• またzaicoはWebアプリだけでなくモバイルアプリもあるのでそれらの整合性を考慮する必要がる
  など

最終的に選んだ案、決め手

• 毎回計算する方法だと在庫件数が多い場合の性能低下が無視できないことが判明したので在庫テーブルにカラムを追加する方法を選択した
• ただしカラム追加時のALTER実行時に1時間程度時間がかかることが判明したので、メンテナンス時間を設けた
• またモバイル対応は後から行うことにし、まずはwebから開発・リリースすることでリスクを抑えた

実装時の工夫

手戻りの少ないように先に画面側のモックを作成し、関係者と認識を合わせておくことで手戻りのリスクを低くした。

使い回し防止プロジェクト

前提・背景

• 複数の端末を１アカウントで使い回されることが多々あった
• 課金はアカウント単位なので売上に影響あり

要件

• アカウントの使い回しを制限し、売上を増やす

設計について検討したこと

• アクセス解析を行なってどの程度使い回しされているか調査した
• いきなり使い回しを完全に禁止にするとユーザー影響が大きすぎると判断し、まずは警告メッセージの表示だけに留めた
• 使い回しテーブルの設計が必要

技術的な難しさは何か

• 使い回しの判定方法
  • １端末の定義をどうするか
  • アプリの場合はランダムUUIDを生成し、アプリのストレージに保存・参照する
  • ブラウザの場合はlocalStorage
  • ただし同じパソコンでも別ブラウザだと別端末判定になってしまう
• レコードの保存と削除のタイミング
  • 使い回しテーブルへのレコードの保存と削除はログイン・ログアウト時に行う一方、使い回し判定はメイン画面を開いた時に行う必要がある

最終的に選んだ案、決め手

• IPアドレスなどを考慮して別ブラウザでも同じ端末判定となるよう工夫した

実装時の工夫

• 使い回しOK端末数が変更になる可能性を考えて拡張性を意識した
• 特別な事情に備えて使い回し制限をアカウントごとに無効化できるフラグを用意した
• Featureフラグを用意して不具合があった時に迅速に制限を無効化できるようにした

2018 年 10 月〜2020 年 9 月 ：　株式会社 gyas

株式会社 gyas

病院の患者を管理するWebシステムの開発

仮想通貨ウォレットのハイブリッドアプリ開発

2014 年 04 月〜2017 年 03 月 ： 野村総合研究所

野村総合研究所

証券バックオフィス(The STAR)の開発

スキル

最低１年以上の業務経験があるものを以下に列挙します。

言語

Kotlin, Java, Ruby, TypeScript, JavaScript, Python, Node.js, PHP, Solidity

フレームワーク

Ruby on Rails, Vue.js, Nuxt.js, Cordova, Laravel, Knockout.js

データベース

MySQL, Oracle, MongoDB, Firestore, SQLite, PostgreSQL

クラウド

• Firebase(Firestore/Authentication/Hosting/Cloud Storage/Realtime Database)
• AWS(EC2・Route 53)

その他

Git, Docker Compose, Gitlab CI, CircleCI

強み・自己PR

• 要件定義からリリースまで幅広く担当した実績がある
• お客様と直接お話しして要件を詰めたり、問い合わせ対応をした実績がある
• 好奇心が強く、新しいことに取り組むことに抵抗感がない
• プライベートでも開発を行っており、ここ数年ほぼ毎日開発を行っている
• ドキュメント化が得意。暗黙的な手順をドキュメント化してきた。
• ロジカルシンキングが得意

やりたいこと

• 社会的課題の解決
  • 少子高齢化、教育、地球環境など社会問題を解決する開発ができると嬉しい
  • ただほとんどのアプリは少なからずそういう一面があるとも思うのであまりフィルタにはならないかも
  • 社内ツール開発とかはつらい
  • １社向けの専用アプリよりも多くの人たちに影響を与えられるアプリの方が嬉しい

職場環境についての希望

• フルリモートワークを希望
  • 住所が福岡県北九州市なので多分ほとんどの企業への出社は地理的に難しい
  • せっかくエンジニアなのでパソコンがあれば仕事できるので
  • 子どももまだ小学校低学年なので帰宅時に家にいてあげたい
  • 年数回の会社の集まりに参加〜くらいなら問題なし
• 土日休み
  • 子どもの休みとあわせたいので
• フレックスタイム制
  • 子ども関連で色々と予定が変わることも多いのでフレックスタイム制だとありがたいです

開発環境についての希望

• 背景の理解
  • 「誰のためになるのか？」「本当に必要とされているのか？」「どの程度困っているのか？現状はどうしているのか？」など背景を理解した上で設計・開発を行いたい。
  • 漫然と開発して結局誰にも使われない。。というのが一番悲しい
  • せっかくコストをかけて開発するのなら本当に役に立つ開発がしたい
  • 可能ならお客様とのMTGを自分で行いたい
• 設計
  • 設計も自分が関わりたい
  • テーブル設計、技術選定、APIやルーティングなどの設計も開発の醍醐味なのでぜひやりたい
• 開発（コーディング）
  • プログラミングも好きなので自分で手を動かしたい
  • ただしあまりに作業的なプログラミングは辛いので、設計と同時に開発できればベスト

　趣味の開発

仮想通貨 bot 開発（2018/08〜現在）

Python を使って仮想通貨 bot を開発・運用しています。
ありがたいことに現在のところはそれなりに利益が出ております。

特徴は以下の通りです。

• マルチスレッドを使った注文発注
• クラスを利用して取引所の差異を吸収
• MySQL を使って注文・約定・損益管理
• plotly や Grafana を使って損益を可視化
• リアルタイム API(websocket) の利用
• 機械学習（線形モデル）を使った価格予測

プログラムソースは公開しておりませんが、合計 1 万行以上となります。
ご興味があれば面談の際にお見せすることも可能です。

ライブポーカー用の HUD スマホアプリ(2019 年)

ライブポーカー用の HUD スマホアプリ(PWA)を開発しました。

資格

• 証券外務員一種
• 応用情報技術者
• TOEIC:730 点
• 簿記 3 級