環境
- cordova-plugin-fcm 2.1.2
事象
cordova-plugin-fcm を入れている状態でcordova build android すると表題のエラーになりました
bitflyerのDBメンテナンス時間判定(python)
毎週土曜日の午前 2 時～午前 11 時頃にデータベースのバックアップ作業を実施しております。作業中は複数回、数十秒にわたり通常よりも注文処理が遅れる可能性がございます。ご不便をおかけいたしますが、何卒よろしくお願いいたします。
— bitFlyer（ビットフライヤー） (@bitFlyer) April 19, 2019
※ 作業時間は前後する可能性がございます。
上記の通り bitflyer は土曜日の午前２時〜１１時頃まで DB メンテナンスを行っており、この間は処理が遅れることを公式に発表しています。
実際、4/27(土)のデータは以下の通りで、数十秒の遅延が多発しています。
という訳で DB メンテナンス時間の判定を行う関数を書きました。
大した処理ではないですが誰かのググる時間を１秒でも短くできれば幸いです。
…
bitflyerでwebsocketに接続できない子羊たちへ
ようこそ、迷える子羊たちよ。
bitflyer の websocket が繋がらなくて困ってるのですね？
悪いことは言わないから今すぐ websocket のバージョンを確認しましょう。
pip list -v|grep websocket
もしかしてまだ 0.4x 系を使ってませんか？
0.4x 系を使って良いのは小学生までですよ？
…
職務経歴書（2026/4/9更新）
目次
概要
- 1990年生まれ（36歳）
- 福岡県北九州市在住
- 広島大学工学部卒業
- エンジニア歴：12年
- できること
- Webアプリ開発（フロントエンド・バックエンド）
- Androidアプリ開発
- 職歴
- 株式会社 Azit：2025年02月〜現在
- 株式会社 ZAICO：2020年10月〜2024年12月
- 株式会社 gyas：2018年10月〜2020年09月
- フリーランス：2018年04月〜2018年09月
- 野村総合研究所（NRI）：2014年04月〜2018年03月
スキル
最低１年以上の業務経験があるものを以下に列挙します。
言語
- 現在メイン: Ruby, TypeScript
- 過去に業務経験あり: Kotlin, Java, JavaScript, Python, Go, Node.js, PHP, Solidity
フレームワーク
- 現在メイン: Ruby on Rails, Next.js
- 過去に業務経験あり: 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
- 要件定義からリリースまで幅広く担当した実績がある
- お客様と直接お話しして要件を詰めたり、問い合わせ対応をした実績がある
- 好奇心が強く、新しいことに取り組むことに抵抗感がない
- プライベートでも開発を行っており、技術力向上に努めている
- ドキュメント化が得意。暗黙的な手順をドキュメント化してきた。
- ロジカルシンキングが得意
弱み・課題
- マネジメントやチームリーダーの経験が少ない
- 技術領域が広い反面、突き抜けた専門領域がない
- 目的や背景が見えにくい仕事ではモチベーション維持が苦手
- 転職回数が多め。しかしいずれもネガティブな理由ではなく、新しい技術への挑戦・チーム開発・リモートワークなど、明確な目的を持って選んできた。その結果、年収についても最初の転職時のみ一時的に下がったが、それ以降は段階的に向上している。
やりたいこと
社会的課題の解決
- 少子高齢化、教育、地球環境など社会問題を解決する開発ができると嬉しい
- 社内向けツール開発よりも、エンドユーザーに届くプロダクト開発の方がやりがいを感じる
- １社向けの専用プロダクトよりも多くの人たちに影響を与えられるサービスの方が嬉しい
キャリアの方向性
- エンジニアとしての12年の開発経験を活かし、PdM（プロダクトマネージャー）を目指したい
- 設計や技術選定の判断ができる「開発もできるPdM」が理想像
- AI時代にコーディング自体の価値が変わる中で、「何を作るか」を決められる人材でありたい
職務経歴
2025 年 2 月〜現在：株式会社 Azit
- 配送プラットフォームのWebアプリの設計・開発を担当
- フロント：（Next.js, TypeScript, Tailwind CSS）
- バックエンド：（Ruby on Rails）
2025年のgithubの貢献状況
配送サービス自動切り替え機能の開発（2025年）
背景
- Uber,Wolt,Menuなど複数の配送サービスを管理する配送プラットフォームが開発対象
- ユーザーが「料金優先」「距離優先」などの条件を指定すると、最適な配送サービスを自動的に選択してくれる
- ユーザーが指定した時間内にドライバーが見つからない場合、キャンセル依頼を自動送信してくれる
課題
- キャンセル依頼が自動送信された後、次の配送サービスに対して、ユーザーが手動で配送依頼し直す必要があった
要件
- キャンセル依頼が自動送信された後、次の配送サービスに自動的に配送依頼し直してあげる
いくつかの設計案
- 案A: 「現在試行中の配送サービス」だけを管理する方式: 既存の配送依頼テーブルに「今どの配送サービスを試行中か」を管理するカラムを1つだけ持たせる方式。シンプルだが、過去に試行した配送サービスがどういう状態で終わったかが残らない
- 案B: 配送サービスごとのステータスを管理する方式（採用）: 配送依頼ステータステーブルを新規追加し、配送サービスごとのステータス（未募集/募集中/ドライバーマッチ済み/キャンセル済み）を管理する
最終的に選んだ設計案
案Bを採用した。以下がその決め手。
- 障害時の状態追跡: 案Bなら各配送サービスのステータスが独立して記録されるため、障害発生時にどのサービスがどの状態で止まったかを正確に把握できる
- 次候補の算出がシンプル: 配送依頼ステータステーブルから「未募集」の配送サービスを取得し、ユーザーが選択した優先順に従って次候補を決める。別途キューやリストを管理する必要がない
開発でハマった点・難しかった点
- キャンセルJobと外部イベントのタイミング競合: キャンセルJobが発火する前に、外部配送サービスから先にキャンセルされる場合があった。その際、二重にキャンセル＋自動切り替えの処理が実行されてしまった。対策として、キャンセルJob実行時に「対象の配送サービスがまだ募集中か」をステータスで必ずチェックし、既に終了済みならスキップする設計にした
- イベントログのエラーハンドリング: 初期実装ではログ記録に失敗すると配送処理全体が打ち切られる実装になっていた。チーム内で話し合った結果、「ログは観測用データであり、ログ書き込みエラーで配送処理を止めるべきではない」となり、ログ記録に失敗した時はSentry通知のみ行いメイン処理は継続する設計に修正した
2020 年 10 月〜2024 年 12 月：株式会社 ZAICO
- 在庫管理プロダクトの設計・開発を担当
- Webアプリ（Ruby on Rails）
- Androidアプリ（KotlinとJava）
Redisキャッシュ導入プロジェクト（2024年）
背景
- 在庫管理アプリケーションzaicoでは、画面表示時に発注点切れ在庫件数を毎回DBから取得していた
- 発注点切れ在庫件数の取得には、在庫テーブル・発注点管理テーブル・グループ系の中間テーブルなど複数テーブルのJOINが必要だった
- 在庫データは数千万件あり、発注点切れ在庫件数の取得に時間がかかっていた
課題
- 発注点切れ在庫件数の取得が遅く、画面表示のパフォーマンスに影響していた
要件
- 発注点切れ在庫件数の取得を高速化すること
前提
- ユーザーと在庫データはそれぞれ複数のグループに所属している（多対多の関係）
- ユーザーは自身が所属していないグループの在庫データは参照できない
- そのため、同じ事業所であっても各ユーザーによって、発注点切れ在庫件数が異なる
- また、Webアプリサーバーは分散化されている
いくつかの設計案
- 案A: DBに保持する方式: 在庫データの更新時に発注点切れ件数を再計算してDBに保存する方式。画面表示時の集計が不要になるが、在庫データの更新頻度が高いため更新のたびに再計算が走りDBへの書き込み負荷が増える。また、実際の在庫データと件数カラムの二重管理になり、不整合のリスクがある
- 案B: 事業所単位でキャッシュを取得・削除する方式: シンプルだが、同じ事業所でもユーザーのグループ所属によって見える在庫が異なるため、不正確な件数が返ってしまう
- 案C: ユーザー単位でキャッシュを取得・削除する方式: ユーザーごとに正確なデータを返せる。ただし在庫データが更新された時に、影響を受けるユーザーを特定して個別にキャッシュを削除する必要があり、削除漏れによる古いデータ表示のリスクがある
- 案D: ユーザー単位でキャッシュを取得・事業所単位でキャッシュを削除する方式（採用）: ユーザーごとに正確なデータを返しつつ、削除は事業所単位でまとめて行う。一部のユーザーのキャッシュが不必要に削除されるが、削除漏れが起きない
最終的に選んだ設計案
案Dを採用した。以下がその決め手。
- 正確性と削除の確実性の両立: ユーザー単位で取得することで正確な件数を返し、事業所単位で削除することで削除漏れを防げる。多少の過剰削除は「その1回だけ遅くなる」だけで、業務上問題ない
- 分散サーバー環境への対応: サーバー内メモリキャッシュだと、同じユーザーでもアクセス先のサーバーが変わるとキャッシュが効かない。キャッシュサーバーを導入することでどのサーバーからでもキャッシュを共有できるようにした
開発でハマった点・難しかった点
- キャッシュの有効期限の設計: 有効期限を長くするとキャッシュヒット率は上がるが古いデータが表示されるリスクが高まり、短くすると頻繁にDBアクセスが発生してキャッシュの意味が薄れる。最終的には、在庫データ更新時に能動的にキャッシュを削除する方式にし、有効期限は「万が一削除漏れがあった場合の安全策」として長めに設定した
キャッシュ導入の際の実装メモは以下にまとめています。
キャッシュ導入の実装メモ
論理在庫プロジェクト
概要
- 在庫管理アプリケーションzaicoでは現在の在庫数量と将来の入庫予定・出庫予定の数量を別々のテーブルで管理していた。
- 現在の在庫数量に将来の入庫予定・出庫予定の数量を加味した新しい数量（論理在庫と呼ぶ）を管理できるようにする。
設計について検討したこと
- 論理在庫を新しいテーブルとして管理するか？
- それとも在庫テーブルにカラム追加するか？
- もしくはカラム追加せず、表示するときに毎回計算するようにするか？
- 性能懸念はないか？
など
課題・問題点
- 在庫テーブルは数千万件のレコードを持っており、適切に扱わないと性能懸念がある
- 在庫テーブルはアプリの根幹となるテーブルであり、安易に手を加えるのはリスクがある
- またzaicoはWebアプリだけでなくモバイルアプリもあるのでそれらの整合性を考慮する必要がある
など
最終的に選んだ案、決め手
- 毎回計算する方法だと在庫件数が多い場合の性能低下が無視できないことが判明したので在庫テーブルにカラムを追加する方法を選択した
- ただしカラム追加時のALTER実行時に1時間程度時間がかかることが判明したので、メンテナンス時間を設けた
- またモバイル対応は後から行うことにし、まずはwebから開発・リリースすることでリスクを抑えた
実装時の工夫
手戻りの少ないように先に画面側のモックを作成し、関係者と認識を合わせておくことで手戻りのリスクを低くした。
使い回し防止プロジェクト
前提・背景
- 複数の端末を１アカウントで使い回されることが多々あった
- 課金はアカウント単位なので売上に影響あり
要件
- アカウントの使い回しを制限し、売上を増やす
設計について検討したこと
- アクセス解析を行なってどの程度使い回しされているか調査した
- いきなり使い回しを完全に禁止にするとユーザー影響が大きすぎると判断し、まずは警告メッセージの表示だけに留めた
- 使い回しテーブルの設計が必要
技術的な難しさは何か
- 使い回しの判定方法
- １端末の定義をどうするか
- アプリの場合はランダムUUIDを生成し、アプリのストレージに保存・参照する
- ブラウザの場合はlocalStorage
- ただし同じパソコンでも別ブラウザだと別端末判定になってしまう
- レコードの保存と削除のタイミング
- 使い回しテーブルへのレコードの保存と削除はログイン・ログアウト時に行う一方、使い回し判定はメイン画面を開いた時に行う必要がある
最終的に選んだ案、決め手
- IPアドレスなどを考慮して別ブラウザでも同じ端末判定となるよう工夫した
実装時の工夫
- 使い回しOK端末数が変更になる可能性を考えて拡張性を意識した
- 特別な事情に備えて使い回し制限をアカウントごとに無効化できるフラグを用意した
- Featureフラグを用意して不具合があった時に迅速に制限を無効化できるようにした
2018 年 04 月〜2018 年 09 月：フリーランス
詳細割愛
2018 年 10 月〜2020 年 9 月 ： 株式会社 gyas
病院の患者を管理するWebシステムの開発
詳細割愛
仮想通貨ウォレットのハイブリッドアプリ開発
詳細割愛
2014 年 04 月〜2018 年 03 月 ： 野村総合研究所
証券バックオフィス（The STAR）の開発
詳細割愛
趣味の開発
仮想通貨 bot 開発（2018年8月〜現在）
Python を使って仮想通貨 bot を開発・運用しています。
ありがたいことに現在のところはそれなりに利益が出ております。
特徴は以下の通りです。
- マルチスレッドを使った注文発注
- クラスを利用して取引所の差異を吸収
- MySQL を使って注文・約定・損益管理
- plotly や Grafana を使って損益を可視化
- リアルタイム API(websocket) の利用
- 機械学習（線形モデル）を使った価格予測
プログラムソースは公開しておりませんが、合計 1 万行以上となります。
ご興味があれば面談の際にお見せすることも可能です。
ライブポーカー用の HUD スマホアプリ（2019年）
ライブポーカー用の HUD スマホアプリ(PWA)を開発しました。
| 項目 | 内容 |
|---|---|
| アプリ | アプリを開く |
| ソース | ソースを見る |
| 新規 or エンハンス | 新規 |
| チーム | 1 人 |
| 担当・役割 | すべて |
| 画面数 | ６画面 |
| 利用技術 | PWA、Vue.js、Cordova |
| 主な機能 | ハンドの記録、キャンセル、メモなど |
資格
- 証券外務員一種
- 応用情報技術者
- TOEIC:730 点
- 簿記 3 級