ID:40883さん

スタートアップ企業の起業数ヶ月後、サイトリリースの直前のタイミングでジョインしました。 バックエンドだけでなく、ブロックチェーン関連や three.js も書いています 1つのプロジェクトで自分が使っている技術の幅は非常に広いです 多くのプロダクトをリリースしており、その多くに関わっているので順に書きます # Anique.jp(ECサイト) 現在・過去のアニメ・漫画作品などの「デジタル所有権」をブロックチェーン上で売買するサービスです アニメの名シーンのセル画を版元が販売し、ユーザ一人だけが購入することができます。 ユーザが購入した記録は Ethereum の台帳に記録され、永久に残ります デジタル所有権の購入者は、購入者にだけ許された権利を行使することができます（そのセル画を実際の額縁に入れた絵画にして購入するなど） 購入者は、その所有権を別の誰かに売ることができます。 新しいユーザが購入すると、その記録もまた台帳に記録されます。新しいユーザもまた購入者の権利を行使することができます ブロックチェーンを使っているため、公式でない場所での転売ができません。そのため、デジタル所有権が移動するたびに版元に利益が渡るようになっています。 ## Ruby on Rails バックエンドを実装しました 出品、販売周りや、当選者の抽選機能などを実装しました。adminツールも整備しました 月に2回ほど商品リリースがあり、その度に新しい販売方法やセット売りなど新機能の実装が必要で コードの複雑さが増大していく状態にありました ## 設計 ジョインした段階では、ActiveModel が(Rails アプリケーションではよくあることですが)ドメインになっておらずただのORマッパーになっていたので - ドメインの知識を持たせる - アトミックであるべき処理は必ずメソッドを用意し実行させる - インスタンスが不正状態にならないようにする - 抽象化 - 抽象クラス(DBテーブルに紐づかない)を生成し共通処理を分離 - 販売方法を抽象化 - 販売商品を抽象化 - 購入方法を抽象化 できるだけ互いを疎結合にすることでソフトウェアの複雑度を増大させないようリファクタリングしました ## CMS の整備 CMS 管理するデータは、cms 操作モジュールを作成 モジュールをインクルードし、JSON(入力データ) とDBレコード(出力)の対応のみ記述すれば簡単にCMSデータをDBに投入できる設計・実装を行いました ## Ethereum アニークは、イーサリアムトークンを使ってデジタル所有権を管理するサービスです コントラクトは私がジョインした時点ですでに実装・検査も完了していたので、直接コントラクト(solidity)を書くことはありませんが、 プロジェクトがRoR なので当初は rails クライアントである ethereum gem を使って実装していましたが、 ドキュメントや使用者の数も少ないため情報が得にくく、 web3 ライブラリを使うように変更しました admin 機能で blockchain(イーサリアムの public チェーン)に対する操作（自社DBとも整合を担保しつつ）を提供するなどの機能を作成しました 自社DB で所有権の移動をコミットするタイミングと、blockchain の台帳に所有権の移動が記録されるタイミングに無視できない隔たり（場合によっては数時間を超えることもありました）があるため、 所有権の移動をユーザにどう見せるか（どう気付かせないか）ということをプロダクトレベルまで遡ってチームとして検討しました 実装者としては、デバッグが困難であるなどやや難度の高い作業でしたが、振り返ってみれば単に外部サービス（極端にレスポンスにムラがある）を扱うことと基本は変わらなかったと感じます 現在は、さらなる取引量の増加を見込んで、blockchain を upgradable contract に変更することや 新たな技術をリーダーエンジニアを中心にキャッチアップしています。（直近だと Cadense に注目しています） # オンライン展覧会 アニメ・漫画などのコンテンツをWeb上の3D空間に再現した展覧会で閲覧できるようにするサービスです アニメの名シーン、書き下ろしイラスト、設定資料集、監督や声優への音声インタビューなど（これらを総称して「アートワーク」と呼称しています）を展示しビューできるサービスです。ここからグッズ販売へつなげる導線もあります https://lp.anique.jp/exhibition/shingeki/ ## three.js Blenderで作られた3Dの展覧会モデルをWebGLで表示するため three.js ライブラリで3Dモデルを表示しました アートワークの数によって展覧会の部屋の数や形が自動で変化する機能を作っています。fbx のデータのオブジェクトに命名規則を指定し、アートワーク数によって適切なオブジェクトだけをロードしてビューに配置するなどしています。 また、画面に映らないアートワークをメモリから適切に削除するなどして、長時間いてもブラウザがクラッシュしないようなメモリ管理を徹底しました 移動、表示の拡大・縮小など操作感もこだわっています ## DatoCMS コンテンツ管理CMSツールです 管理データをモデリングすることができ、構造化された形のデータ管理ができるので、展覧会のような膨大な数や種類のデータを管理するのに非常に便利です ヒアリングの上、適切なデータモデリング、およびデータのバリデーション(これもDatoCMSの機能です。文字数の範囲、画像サイズの上限、他のリレーションデータとの整合性など)を定義しました さらにこれらのデータを扱うドキュメンテーションをNotionで作り、チームのデータ投入担当者たちに共有し、早い段階でデータ管理をエンジニアから手離れさせました。これにより高速で展覧会事業が回せるようになっています # AttackOnTitanLegacy 進撃の巨人のNFTを販売するサービスです 現在北米向けに展開しています 進撃の巨人のキャラクターをNFT化し、販売・二次流通しています。 Flow blockchain を使っています https://aotlegacy.com/ ## Flow Flow blockchain に関する実装をほぼ一人で行いました Flow blockchain の調査 Cadenceによるコントラクトの実装とmainnetへのデプロイ Cadenceを操作するAPI群をマイクロサービス化して作成。こちらは Flow ライブラリの充実していた GoSDK で作った後、Anique社内の技術スタックをTypeScript に揃えたいという意向が入ったため、JS SDK で再度同じものを作っています 秘密鍵の管理 GCP Workflowを使い、バックエンドサーバとマイクロサービスの連携インフラを整備 バックエンドからマイクロサービスの呼び出し、およびコールバック処理を実装 などが具体的な作業内容になります Ethereum でなく Flow を導入した理由は、トランザクション手数料の安さ、コントラクトの安全性や柔軟性などによる今後のアプリケーションの展開が行いやすいことが決め手になっています mainnet へのコントラクトはこちらにデプロイされています https://flowscan.org/contract/A.e2e1689b53e92a82.AttackOnTitanLegacy/overview また DB のトランザクションと Flow のトランザクションを矛盾なくエラーなく協働させる設計と実装を重視しました たとえばユーザが NFT を購入するとき、Aniqueの購入APIをまず呼び出します APIがDBに「購入処理中」を記録し、Flow マイクロサービスを呼び出します Flow マイクロサービスは Flow blockchain に購入トランザクションを実行します Flow トランザクションが完了するのを GCP Workflow がポーリングし、完了を検知したら、AniqueのコールバックAPIを呼び出します コールバックAPIは、Flowトランザクションの結果やeventを読み取り、エラーがないか、eventがDBの現状と矛盾がないかなどを確認して、DBに「購入完了」を記録します Flowトランザクションの種類は10以上、Flow event の数も10前後あり、DBの状態と突き合わせる処理は数が多く大変ですが、テストも含め固く書きました Flowトランザクションがエラーになった時の対応、 1つのAPIの操作がFlowトランザクションでは2つになる場合もあるのでそれに対応、 これらに加え、購入処理中の場合は、該当NFTは購入などの処理を禁止するなどバックエンド側へのバリデーションも行っています 今後の拡張にも耐えうるよう適切な抽象化をした上での設計を心がけています 複雑になりがちでFlowの深い知識も求められる部分ですが、サービスが運営する上でネックになってしまわないよう入念に作りました エラー時の対応方法なども、他のエンジニアメンバーと繰り返し行い、ドキュメントも整備していたおかげで、リリース直後から私の手離れをして運営ができています。 # 次 現在進行中のプロジェクトです 引き続きFlow blockchain 周りをほぼ一人で手がけています

ゲーム配信プラットフォーム 視聴者はコメントで参加でき、ギフトを送ることなどもできます ゲーム開発者もプラットフォームに参加でき、自身の作ったゲームが配信されると、収益の一部を受け取れます [https://fingger.com/](https://fingger.com/) ### 技術スタック - C#, Unity(WebGL), dotnet - Azure ### チーム状況 - バックエンドエンジニア1~2人（途中から1人追加） - Unityエンジニア1人 - つまりフロントエンド以外はほぼ1人でやってました ### 業務の詳細 - ゲームとサーバサイドがRPCで常時接続しているというプロダクトの特性上、バックエンドエンジニアとUnityの両方を知っているということで重要な箇所を任されていました - UnityWebGLで動いているゲームと、サーバサイドをRPCで常時接続し、配信者のプレイ結果（Unity→サーバ）や視聴者のコメント（サーバ→Unity）を相互に通信し続ける仕組みを作りました - この時 MagicOnion というライブラリを使ったのですが WebGL 版がなかったため、MagicOnion 作者の方達とコンタクトをとりながら WebGL 版を作っていただいてました - YouTube 配信のコメントを取得して表示するため、YouTube API への認証やリクエスト取得してUnity へ送信するなどの仕組みも実装しました - YouTube API にだいぶ詳しくなりました - YouTube 以外の配信サービスの対応も予定されていたため、DDD でいうところの domain層と Infrastructure層を明確に切り分けて YouTube 依存の部分を Infrastructure層に閉じ込めたりしてます - ゲーム開発者向け機能のAPIを実装 - ゲーム（配信者が遊ぶゲームのこと）の登録や、ゲーム内アイテムの登録など - AppStore を参考に - そのほかガチャや特殊コメント登録機能など - 疎結合かつ拡張性を持つよう設計 - リソース（ゲーム、アイテム、ガチャなど）のバリデーションを可能な限りそのままコードに表現できるようなモデリング・実装を心がけてました - 序盤はバックエンドエンジニアが自分だけという時期も長かったので、API 設計や機能設計も1人でやっていました - 稼働が週2日だったのですが、1日で設計+ドキュメンテーション、1日で実装とテスト、という感じでAPI群を作っていて、割といいテンポ感で進めてました

### プロダクト説明 メガネのJINSが出した新しいメガネデバイスで、装着すると感情や体調が測れるものがあり、それを使って新しい体験を提供するゲームです。コミケ(2017冬)出展 [https://wakupaku.hmup.jp/blog/blog/report-iot-jinsmeme](https://wakupaku.hmup.jp/blog/blog/report-iot-jinsmeme) ### 技術スタック - Unity, Live2D, iOS, JINS MEME SDK ### チーム状況 - エンジニア1名 - あとはデザイナー1人いたかなくらい ### 業務の詳細 - ノベルゲームでメガネデバイスで新しい体験を、ということでコミケ1ヶ月前の時点で話をもらい、ノベルゲームならなんとかなるやろと思い着手。 - JINS社のメガネデバイスを借り、専用SDKももらって開発 - メガネで計測した各種計測値から、ユーザの状態（感情など）を示す評価値の計算式などは、JINS社のエンジニアの方とコンタクトをとりながら実装 - ノベルゲーム部分に関しては、Unityで評価の高いアセットを知っていたためそれをフル活用することで対応。アセット作者の方も面識のある方だったのでスムーズに導入。会話データなどは発注社からもらったものをもとに自分で作成 - キャラクターの動きはLive2Dを使いました。2年くらい前にちょっと使ったことがあるくらいでしたがすぐ導入できました。データはデザイナーの人に用意してもらってます - 起動時のデバイスのキャリブレーションや認識機能、プレイ中にデバイスが切れたりした際の再接続、再キャリブレーションなどの機能も（仕様に含まれていたわけではありませんが）用意。出展当日は自分がアテンドするわけではないため、その辺りの機能を用意しJINS社の方に使い方の指導などもしておきました。当日は問題なく動いていたようです

# 概要 美容外科の情報メディアサイトです # 技術スタック - Ruby on Rails # 担当箇所 ## 地域検索 ## ソーシャルログイン OAuth, OpenID Connect に対応し、LINEやTwitterでログインできる機能を実装 メールアドレスログインしたユーザが後からSNS連携できる機能、 一度連携したSNSの連携を解除する機能（ただしSNS以外のログイン方法を登録している場合のみ） やることは割と多いです ## 画像アップローダ ユーザが自分で術前・術後の症例写真をアップロードできる機能があるため、それに関する実装をしました Carrierwave を使用しました。基本的にはこれで対応できましたが 画像サイズを適切にリサイズする必要が出てきたため、 MiniMagick も導入しました ## クエリ最適化 その他、レスポンスが遅い原因となる SQL の最適化などは随時行っていました ## amp対策 Google Search Console など ## GA 計測 イベント仕込みなど（分析自体は別のメンバーがしていました）

### プロダクト説明 3人ほどでチーム組んでiOS,Android向けのカジュアルゲームを10本くらい作ってました ### 技術スタック - C++, cocos2d-x - iOS で Obj-C, Xcode - Android で Java, AndroidStudio - 他に Firebase, Fabric, deployGate, 各種広告SDK など ### チーム状況 - エンジニアは1名（自分だけ）、他にプランナー兼デザイナーが1人、プロデューサー的な人が1人 ### 業務の詳細 - cocos2d-x で作っていました（この頃はまだ Unity が 2D ゲームを作るのに向いていなかったため） - クッキークリッカー系、ワンボタンアクション、ランゲーム、シューティングなどジャンルはいろいろ - カジュアルなゲームで早く作るのが目的だったので、最初に大まかなイメージを共有してまず作り、全員で見て意見を出してまた直して…というのを繰り返して作ってました - 広告SDKを入れたり、効果を測定してました - 複数社のSDKを入れてたので、効果を見て表示割合をすぐに変えられる仕組みとか仕込んでました - 広告の会社さんの勉強会に出たり、担当さんとやりとりして効果的な広告の出し方を相談したりとかもしてました - 一番バズったやつで、いい外車買えるくらい売り上げが出ました

# 概要 ソーシャルゲームの開発運用です。 iPhone,Android 向けスマホゲーム。現在もサービスが続いています クライアント側はUnity、サーバサイドは Rails です。 このゲームを作る以前に、DeNAとの合弁会社でソーシャルゲームを2本作成しており（Ruby ではなく Perl だったのでレジュメには起こしていません） そのスキル・ノウハウを本社内へ持ち帰って、社内開発のソーシャルゲームの開発・運営に生かし伝授するミッションでもあったプロジェクトです プロジェクトは1年ほど開発が行われた状態で、途中参加した形です # 技術スタック - Ruby on Rails - AWS # 担当箇所 ## サーバサイドの機能実装 - ガチャ - ギフト - イベント - バトルなど プロジェクトには途中参加したのですが、既存メンバーはコンソールゲームの経験しかない者がほとんどで、Rubyの書き方がC++のようだったり、DB、SQLの記述なども非効率だったりしたので レビューも時間を割いて行いました 水平シャーディングも実装。柔軟性を考慮し、ユーザIDとシャードキーのマッピングテーブルで管理する方法を取りました ちなみに、プロジェクトにジョインした段階ですでに、マスターデータとユーザデータが別DBで管理されていたので、マスターデータはマスターシャード（1つ）のみに、ユーザデータだけをシャーディングする方式となりました マスターデータの投入フローは（DB1つのため）簡易で済むと言うメリットがありましたが、マスターデータとユーザデータがJOINできずコーディングが冗長になると言うデメリットが大きく 水平シャーディングを導入する段階に合わせて、マスターデータをユーザデータと同一DBで管理する方式に移行すれば良かったと今は思います ## サーバとクライアントの連携 クライアント（モバイル）側はUnityで実装されていました ゲームの各メニュー画面は js で実装されており、js ファイルを WebView で表現されていました 当初、この js ファイルはアプリ本体にバンドルされる形になっており、更新するにはアプリのアップデート(つまりAppStore, GooglePlayへのサブミット)が必要になっていました メニュー画面は、月2回のイベントごとにレイアウトが自由に変更できる必要があると考え、 js を自社サーバ経由で動的に更新できる仕組みをサーバ・クライアント両チームに跨って提案、 クライアントアプリの動的更新が可能になるようインフラ面も含めて提案し改善しました ## 運用 DB参照・更新用のバックツールを作成 Excelデータをインポートし対応するテーブルのレコードを生成 比較、参照、投入処理など 外部キー制約の関係でテーブルの投入順序に依存がある場合も考慮するなど プロジェクト内にあるどのPCのツールからでも、どの環境のDBに対しても操作が可能なように変更（本番環境は除く） ## セキュリティ 運用中に OpenSSL の Heartbleed バグ(CVE-2014-0160) が公開されたため、社内インフラチームと共に対応にあたりました（といってもAWSのインスタンスを立ち上げ直した程度ですが） # その後 Rails やDB、管理ツールなどのスキルをメンバーに普及し、 チームがイベント運営も軌道に乗ってこなせるようになったのを見て、 退社し独立しました

- マクロスのソシャゲ - 3Dシューティングで、当時のソシャゲとしてはまだ少なかったガッツリゲーム性のあるもの - モバゲー - [https://www.4gamer.net/games/151/G015141/20120615048/](https://www.4gamer.net/games/151/G015141/20120615048/) ### 技術スタック - C#, Unity ### チーム状況 - バンダイナムコとDeNAが合弁会社BNDeNAを設立してソシャゲの開発を始めました - 元々サーバサイドの技術に興味があり、それを聞きつけて志願し、立ち上げ直後の会社に異動させてもらいました - とはいえ自分のスキルとしてはサーバは未経験で Unity はすでにかなり触っていたので、Unity としてチームに貢献することにしました - サーバサイド（バックエンド）はメンバーの仕事を横で見て自分で勉強しており、次のゲームの時に戦力になれるよう準備していました（実際次のゲームでサーバ側をやらせてもらいました） - 開発メンバーとしてはエンジニアはUnityが3人、サーバサイド（バックエンド）が2人 ### 業務の詳細 - Unity - 3Dシューティング部分（いわゆるインゲーム）を1人で作りました - 自機の操作、敵機や弾丸の挙動、エフェクトや音声の再生とか諸々全部 - メンバー内で特にUnityに詳しかったので教える側にも多く回ってました - WebView

- PS VITA で発売された塊魂のゲームです - 2011/12/17 発売 - [https://www.youtube.com/watch?v=CE_oHcy4BeE](https://www.youtube.com/watch?v=CE_oHcy4BeE) ### 技術スタック - C++、PS VITA ### チーム状況 - エンジニア10人くらい ### 業務の詳細 - サウンドプログラミング - サウンドに関するプログラミングをすべて行いました - 数千種類ある効果音の再生制御と管理 - BGMの再生。塊の形状に応じてBGMのピッチが変化する仕組みも実装 - サウンドクリエイターと意見交換をしながら、このような面白い取り組みを多く入れました。今までで一番やりやすいプログラマの人だと評価してもらいました - エンディングミニゲーム - PS VITA はジャイロセンサーがあるのですが、それをゲーム内で使う場面がありませんでした。せっかくなので塊をジャイロで転がしてみたいという思いがあり、ジャイロで遊べるミニゲームを作ってディレクターに見せたところ評価してくれ、エンディングミニゲームとして採用されました

# 概要 アーケードゲームの開発です SYSTEM357 という、PlayStation基盤と同じもので開発していました その後、PlayStation3 への移植も行いました # 技術スタック C++ # 担当箇所 ## リグ 重力、キャラの移動、風などの情報を元に、3Dモデルの服や髪のボーン位置を計算し揺れているように見せました ## レーシング 専用の操舵コントローラを回してレースゲームとして遊べるよう実装 ## UI ゲームプレイ中のUI実装など ## コイン投入と安全装置 アーケードゲームなので、100円玉を入れた判定によりゲームを開始またはコンティニューする機能 また、筐体が動くゲームなので、プレイが止まると筐体も停止、コンティニューすると稼働再開 さらに二人プレイ可能なので、一方だけコンティニュー状態の場合も停止させるなど アーケードゲーム特有の問題点をハードウェア面も考慮しながら要件定義と実装しました ## PS3モーションコントローラ アーケード稼働後、PS3に移植されました モーションコントローラに対応してUIを作成（コントローラを振って選択するなど） ## 立体視版 さらに、立体視が流行り始めた頃だったため、メガネ着用で遊べる立体視バージョンも作成されました。 視錐台変換行列（ゲーム空間内のカメラ座標から、スクリーン座標に変換するための行列）を立体視用に改良して、右目用画像・左目用画像を出力できるよう実装などしました。