| key | value |
|---|---|
| Name | 内田 正輝 |
| @foobar |
- Elixer
- Kotlin
- などなど
- Phoenix
- Android
- などなど
- Flux
- WebSocket
- WebRTC
- オブジェクト指向設計
- 関数型での実装
- 安定した人格
- 日本語
- ネイティブ
- 英語
- テキストベースでならやりとり可能
- ワンオペ/チーム開発問わずにPMと報連相して適切な立ち回りを相談し、実行できます
- サーバーサイドKotlin
- データモデリング含めた要件定義
- Elm
- Kotlin Multi Platform
- Swift UI/iOS
- 未経験Androidエンジニアの教育
- 業界未経験で入ってきた人員を１人称開発できる状態にしています
- 指導方針
- 心理的安全性と本人のモチベーションを優先し、緊急度の高いもの以外は実装の順番などは本人にまず選んでもらってから、私は難しい部分や面倒な部分をフォローすることで、複数人の人員がフロー状態でいられるように指導しました
職務: Webアプリケーションエンジニア → Androidエンジニア
- バックエンド
- 設計
- コーディング
- 運用保守
- WebSocket
- Elixir/Phoenix
- Redis
- memcached
- REST-API
- Bootstrap
- Supervisor/Worker
- RDS Aurora for MySQL
- 概要
- 自社開発ソーシャルゲーム案件
- 規模
- 20名(うちサーバーサイド3-6名)
- 役割
- メンバー
- 担当
- サーバーサイド
- 詳細設計
- プログラミング
- バグ修正
- 期間
- 2018/08 - 2019/04
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問題によるタイムアウトで毎回ホーム画面で落ちてしまってた時、運よく会社にいたのでそのまま出勤し該当部分を修正してその日のうちに解決したら社長からの覚えがよくなったこと
- Android
- コーディング
- 運用保守
- WebSocket
- WebRTC Skyway
- RxJava
- MVVM
- Kotlin
- EventBus
- DataBinding
- REST-API
- 概要
- 技術広報イベントデモ用自社開発オンラインクレーンゲーム
- 規模
- 15名(うちAndroidエンジニア3名)
- 役割
- メンバー
- 担当
- Androidネイティブ
- プログラミング
- バグ修正
- 期間
- 2019/04 - 2019/05
- WebSocketを用いたクレーン台操作機能の設計・実装
- WebRTC Skywayを用いた動画視聴機能の実装
- 先輩Androidエンジニアが0になった後に報告が来たバグの修正
初めて参画したElixir案件が売上が振わず規模縮小になり、 新規開発が無くなったことで社内での身の振り方を考えている時にAndroidエンジニアが続々と辞職していく状況になっている事を知り、 社内の他案件にサーバーサイドエンジニアとして入ってPHP / Laravelをやるよりも、 全くやったことのないアプリエンジニアにキャッチアップしてでもKotlinで仕事がしたかったため移籍願いを出し参画。 名前も聞いたことなかったWebRTCの技術に触れられたことや、 社内案件だったため派手でさえあればアニメーションで楽しめたのがよかったです。
- Android
- 詳細設計
- コーディング
- 運用保守
- WebSocket
- WebRTC Sora
- HLS
- RxJava
- MVVM
- Kotlin
- EventBus
- DataBinding
- REST-API
- Firebase
- Jetpack
- Realm
- 概要
- 受託開発オンラインクレーンゲーム
- 規模
- 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ヶ月の駆け出しと大差ないとこからワンオペでキャッチアップしていくのは少し胃もたれするような濃度の開発でした。
初めの頃は残業が常態化していながらも自分のできることが増えていくのが楽しく、 納期の事故も一度も起こさずに頑張ってこれたため良い案件でした。
キャッシュフローが必要になったためという発注元の意向で新規開発停止で保守運用のみになり、 インフラ・サーバーの最低限の保守要員以外はプロジェクトを離れることになってしまったのが残念な気持ちです。
- Android
- アーキテクチャ設計
- 詳細設計
- コーディング
- 運用保守
- Coroutine
- Flux
- Kotlin
- Navigation Component
- DataBinding
- REST-API
- Realm
- 概要
- マンション管理士業の代行システム
- 規模
- 20名(うちAndroidエンジニア1 - 3名)
- 役割
- リーダー
- 担当
- Androidネイティブ
- 技術選定
- アーキテクチャ設計
- Utilクラス設計
- 詳細設計
- プログラミング
- バグ修正
- 期間
- 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から作ったプロダクトなので、 もし転職でご縁があったとしても、全体設計レベルの話や認証周りでのバグを相談されたら土日などで手伝いにいくことがあるかもしれませんがご了承いただきたいです。