ID:42329さん

# プロジェクト概要 自社開発ソーシャルゲーム案件 # 規模 20名(うちサーバーサイド3-6名) # 役割 メンバー # 担当 サーバーサイド、詳細設計、プログラミング # 期間 2018/08 - 2019/04 # 用いた技術一覧 - WebSocketを用いた最大20人でのリアルタイムバトルの保守 - WebSocketを用いたオークションロジックのリファクタ・バグ改修 - WebSocketを用いたレイドバトル参加者のリアルタイムマッチング機能の設計・実装 - 上記を実現するDB及びSuperviserのリファクタ・設計・実装 - WebSocketのコネクション管理とオークション・バトル・マッチング等のリアルタイム性が高いIOのためのRedisのデータ構造の設計・実装 - Unityチームと協業しながらのREST-APIの実装 - UnityチームのC#ロジック部分のモブプログラミング - bootstrap・AdminLTEを用いたプランナー・ディレクター・デバッガーの作業効率化のための管理画面機能の設計・実装 # 感想 21の頃から趣味と副業でアフィリエイトやFX自動売買のためのプログラムを書いていましたが、 業務としては初の案件だったので今でも感慨深く思います。 特に大変だった点を挙げると、 - Web系の実装経験はPurePHPとWordpressプラグインの改造しかやったことが無かったのになかなかに技術的に難易度の高い実装ばかりだったこと => 「プリンシプルオブプラグラミング」や「リーダブルコード」などの書籍について聞ける先輩がいたので、休日に読んでわからない点は聞いて理解していくことで適応しました - WebSocketを用いたオークション処理のロジックが全てContloller的な場所に書かれていたこと => 納期に余裕のあるタイミングでわかったことだったので、RedisとのIO処理・オークションのビジネスロジックの2つのロジックのために新規モジュールを新規作成しそれぞれに切り出しました - 普通のWeb開発ではそうそう使わないWebSocket・Superviser・アクターモデル等の知識 => 記事が英語ですらほとんどなかったので、担当プロジェクトをイニシャルコミットから順番に読んでいき、次にPhoenixFWのORMとWebSocketのライブラリの全コードと、FW内でsupervisorが使われている部分を仕事の空き時間と休日に読破してキャッチアップしました - 当時のネットではElixirの日本語情報がほぼ無かったので、英語で探すのが基本でなければライブラリ内の実装を読まなければバグの解決ができないことがままあったこと => 基本はGoogle翻訳を頼りますが、プログラミング関連の話題であれば英語のリーディングが苦にならなくなりました。 よかった点としては、 - 実務2ヶ月くらいでDB設計をさせてもらえたこと - 実務2ヶ月くらいでWebSocketの実装をさせてもらえたこと - Elixirのライブラリやフレームワークのコードを読むことにハマって、センスの良い設計の勉強になったこと - たまたま飲み会で終電逃して会社に泊まった日の次の土曜日にサーバーがN+1問題によるタイムアウトで毎回ホーム画面で落ちてしまってた時、運よく会社にいたのでそのまま出勤し該当部分を修正してその日のうちに解決したら社長からの覚えがよくなったこと

# プロジェクト概要 技術広報用自社開発オンラインクレーンゲーム # 規模 15名(うちAndroidエンジニア3名) # 役割 メンバー # 担当 Androidネイティブ、プログラミング、デバッグ対応 # 期間 2019/04 - 2019/05 # 用いた技術一覧 - WebSocketを用いたクレーン台操作機能の設計・実装 - WebRTC Skywayを用いた動画視聴機能の実装 - 先輩Androidエンジニアが0になった後に報告が来たバグの修正 #感想 初めて参画したElixir案件が売上が振わず規模縮小になり、 新規開発が無くなったことで社内での身の振り方を考えている時にAndroidエンジニアが続々と辞職していく状況になっている事を知り、 社内の他案件にサーバーサイドエンジニアとして入ってPHP / Laravelをやるよりも、 全くやったことのないアプリエンジニアにキャッチアップしてでもKotlinで仕事がしたかったため移籍願いを出し参画。 名前も聞いたことなかったWebRTCの技術に触れられたことや、 社内案件だったため派手でさえあればアニメーションで楽しめたのがよかったです。

# プロジェクト概要 受託開発オンラインクレーンゲーム # 規模 10名(うちAndroidエンジニア1名) # 役割 ワンオペ・オフショアリーダー # 担当 Androidネイティブ、詳細設計、プログラミング、デバッグ対応 # 期間 2019/06 - 2020/12 # 用いた技術一覧 - 既存プロジェクトの全画面の見た目を新受託先に合わせて修正 - AgoraSDKとSocket.IOによるリアルタイム動画・クレーン操作の機能を廃止作業 - WebSocketを用いたクレーン台操作機能の設計・実装 - WebRTC Soraによるプレイヤー動画機能の設計・実装 - ExoPlayerを用いたHLSその他ユーザー動画視聴機能の設計・実装 - WebViewとWebhookを用いたフロント実装とのデータ通信機能の設計・実装 - Adjust・FirebaseAnalyticsを用いたユーザー情報収集機能の設計・実装 - TapJoyを用いたアドネットワーク機能の設計・実装 - GooglePlay課金システムの機能の設計・実装 - バックグラウンドからのローカルプッシュ配信機能の設計・実装 - EventBusを用いたナビゲーション機能の設計・実装 #感想 Androidエンジニアとして一番力が付いたと思う案件。 社長が私がAndroidエンジニアに参画する前に受託していたオンラインクレーンゲームのプロジェクトを 1.5ヶ月で約25画面のガワを貼り替えてそのまま保守契約という他者からの乗り換え案件を獲得してきてくれた。 最初はガワだけと聞いていたのに、インフラからの要望でAgoraSDKからSoraに乗り換えたいから それ前提で他社が開発したなぜかWebSocketで動画配信するシステムにネットワーク周りを差し替えて、クレーン操作もSocket.IOからWebSocketに変更(納期はそのまま)というタスクも追加されて大変でした。 保守が始まってからはかねてより予定していたWebSocketでの動画配信からWebRTC Soraへの乗り換えとプレイ中のユーザー以外にはHLSでの動画配信というシステムへの差し替え。 他にもAdネットワークのTapJoy、FirebaseAnalytics、Adjust、などのサードパーティSaaSの取り込みや、 起動時のローディング画面で40秒近くユーザーを待たせていたものを6秒に縮めたり、 コロナが流行り始めた頃から仕事を無くしたオフショアエンジニアSESと協業するようになったり、 サーバーのDBでメインのPrimaryKeyが変わるレベルでのゲームシステムの大改修など、 触って2ヶ月の駆け出しと大差ないとこからワンオペでキャッチアップしていくのは少し胃もたれするような濃度の開発でした。 初めの頃は残業が常態化していながらも自分のできることが増えていくのが楽しく、 納期の事故も一度も起こさずに頑張ってこれたため良い案件でした。 キャッシュフローが必要になったためという発注元の意向で新規開発停止で保守運用のみになり、 インフラ・サーバーの最低限の保守要員以外はプロジェクトを離れることになってしまったのが残念な気持ちです。

# プロジェクト概要 マンション管理士業の代行アプリ # 規模 20名(うちAndroidエンジニア1 - 3名) # 役割 リーダー # 担当 Androidネイティブ、アーキテクチャ設計、クラス設計、詳細設計、プログラミング、レビュアー # 期間 2019/10 - 現在 # 用いた技術一覧 - 約200画面あるアプリの0 -> 1のアーキテクチャ設計 - Navigation Componentを用いたナビゲーション機能の設計・実装・レビュー - Github Actionsを用いたCI / CDの設計・レビュー - Auth0を用いた認証機能の設計・実装 - Kotlinのマルチモジュール機能によるレイヤードアーキテクチャの設計 #感想 この案件が始まりということでアサイン中だったオンラインクレーンの稼働を0.5に減らし(実際は0.8くらい)、 0.5という稼働(実際はこちらも0.8ぐらい)で始めたこの案件ですが、世の中ではAndroidエンジニアの採用はとても難航しているので、 正直1人で全部やるとなると会社に住むレベルになるのではないかと初めは戦々恐々でした。 ですがインターンや新卒や転職などで全員業界未経験(1人はAndroid未経験)ですが後輩が入ってきてくれて、 インターンの方は結局会社で受けていく案件とやりたいことが合わないとのことで他の企業での採用となりましたが、 2人の後輩に恵まれ常識的な稼働でなんとか開発を進められています。 最初この案件は200画面あるとの話をPMとデザイナーから聞いた時、 オンラインクレーンでもユーザーのゲーム進行状況や所有ポイントやABテストの都合などで 画面のナビゲーション先が玉虫色に変化したり、 複数の画面で同じデータを参照したい時Pure MVVMとRxJavaが流行っていた頃にベストプラクティスとされていたFat ViewModelでは複雑性を管理しきれなくなる予想が立ったので、 RealmをStoreとしてMVVM + Fluxのアーキテクチャを採用し、 Kotlinマルチモジュールによるアーキテクチャに沿った依存方向の強制とドメイン別のフォルダ分けによる可読性・保守性の向上とコンパイルの高速化を実現し、 ほとんどQiitaの記事そのままでしたが後輩と相談しながらGithub ActionsによるCI/CDの導入 ナビゲーションについては当時海外でもほとんど採用事例のなかったNavigation ComponentとSafeArgsを採用することで、 GUIでのナビゲーション管理とStyleによる見た目の共通化で、 後輩と協力しながら200画面をこの短期間で結構なクオリティで開発しきることができました。 当時出たばかりだったViewPager2などの最新のマテリアルデザインコンポーネントも使えるものはどんどん取り入れていき、 サーバーサイドからのオーダーでFirebase AuthenticationやAWS CogniteではなくAuth0の0 -> 1の実装経験を積めたのも個人的には大きかったかなと思います。 Navigation Componentとそれに付随したnavGraphViewModelの仕組みについては、 記事がないためOSSを読むしかなかった状況なので、XMLのパーサーやNavControllerの内部の大体の仕組みが勉強できたこともこれからのAndroidエンジニアとしてはだいぶ実力で差別化できる点ではないかと思います。 ちなみにこの開発と並行してUtil系のライブラリとして使えそうな部分をGithubサブモジュールとして切り出して、 OSSとしての公開などもやってみました。 このプロジェクトのAndroidアプリは私が0から作ったプロダクトなので、 もし転職でご縁があったとしても、全体設計レベルの話や認証周りでのバグを相談されたら土日などで手伝いにいくことがあるかもしれませんがご了承いただきたいです。