ID:22673さん

# 概要 ## プロダクト オリジナルタイトルとして開発していたものを、IP向けにリニューアルしてフルネイティブで開発したものです。 ## 開発体制 Android - Kotlin, iOS - Swiftでオリジナルタイトルとして開発されていたものを、IP向けにリニューアルするタイミングで加入しました。 社内のエッジなメンバーを集める形でチームが組成されています。 ## 開発時の状況 当時Swiftはまだ1.2->2の過渡期であり目まぐるしく環境が変わっていました。 Kotlinに関しても、まだJetBrainsが自主的に出している状態で、Androidの公式言語ではありませんでした。 また、当時各言語で流行っていたReactiveProgrammingを導入しており、メンバー全員が手探り状態でした。 GoogleMapを使用した位置ゲームであり、両OS対応の開発環境の実現が当時としては困難であったため、それぞれのOSでの実装となりました。 # 学習について 各言語ともアプリのリリースまでにはRC版になっている前提で開発を始めたため、braking changeが毎月のように発生する状況でした。そのため、チームでは各言語のリリースをチェックするのはもちろんのこと、お互いが見つけた勉強会には積極的に参加していきました。またGotanda.mobileを開催し、Android/iOSの垣根をなくした勉強会を数回行い、情報を取りに行くだけでなく集めて広げる活動も行いました。 チーム全体が自然体でやっていき/のっていきを実現しており、私の中でのデベロッパーチームの理想形の原点になっています。

# 概要 ## プロダクト モバイルゲーム開発。 Play Store/App Store 100位以内に入る位置ゲーム。 ## 業務範囲 当プロジェクト規模拡大に伴い、前記の位置ゲームプロジェクトから、途中参加しました。 エンジニア業務の設計/コーディングから始まり、必要に応じてUX観点の施策提案から、チームビルディング、スクラムマスター等を行っています。 後述するカメラアプリは本アプリと平行して着手しています。 # エンジニアリングについて システム/仕様的な課題を見つける、課題を作ることから開始し、IA設計〜実装までデザイン以外を一通りやります。 例えば、ガチャの排出の結果が最大限凸だった場合、今までは消費アイテムを排出していました。コレを止め、いわゆる交換所とそこで使う交換ポイントを新設し、そのポイントを排出するよう変更する要求がありました。私は、コレに対して世界観付与からチームで行えるよう調整を行い、UXエンジニアとして世界観を加味したIA設計を行いました。 実装に関しては、多対多の交換を行うUIは今までアプリ上には存在しなかったため、デザイナと協力し新規UIを設計し、実装しました。他、API設計〜バックエンドまで一通り行いリリースすることができました。 また、これに際しガチャシステムの作り直しを行い、ガチャ体験と収益性の向上に寄与しました。

# 概要 ## プロダクト 上記位置ゲームアプリのキャラクターを使用したスピンオフカメラアプリ。SNS上での拡散力と、位置ゲームとしての体験向上を意図したもの。 ## 業務範囲 要件定義、アーキテクチャ選定〜設計〜実装〜リリース、ディレクション、プロジェクトマネジメント、プロモーション戦略 ## 開発体制 エンジニアx2, ディレクタx1, デザイナx1 # 要件定義について 位置ゲームのスピンオフとしてカメラアプリを作ることは親和性はあるでろうという仮定のもとで、プロジェクトが開始されましたので、まず、実際にどういったユーザ層に使ってもらえるのか、ユーザのペルソナを定義し、ユーザストーリーに起こすことで、ニーズの発掘を行うことから始めました。 また、そのニーズを実現するための費用とマイルストーンについても計画を行いました。 # アーキテクチャ選定について 開発工期が限られている中で、Android/iOSリリースということで、使用エンジンは最初からほぼUnity一択でした。 アプリの規模はミニマムですが、ミニマム前提でMVVMで設計を行うと後々の拡張がつらくなる自体が想定されます。かといってflux等の大規模アーキテクチャで設計を行うのは現在の要件ではマッチョです。 そこで、今回の設計はReduxをベースにし、StoreからViewへの単方向バインドのみを実装、ActionCreatorやReducerはMVVMのVMで省略するという方針で設計しました。これにより、軽量な実装と大規模アプリケーションの拡張性を両立目指しました。また同時に、クリーンアーキテクチャに見られる内側への参照関係も採用し、テスタビリティも確保しました。 # 設計について デザイナの工数をアサインできましたので、画面遷移図はGoogle図形描画で済まし、早々にデザイナさんにSketchでモックアップをお願いしました。 また、スピンオフアプリの性格上、リリース後のメンテナンスが行き届かなくなる事が予測されたため、コードのみやすさが最優先と定義し、以下のような原則を適用しました。 * コルーチンよりもRxによるストリーム処理を推奨 * Rxに流すものはプリミティブ型や、Entityオブジェクト * 無意味な継承は行わない * クリーンアーキテクチャ風にできるだけ近づける努力をする # ディレクション 開発が軌道にのり始めるとエンジニアが追加でアサインされ、各役割ごとの作業を進めていくフェーズですが、そこでディレクタが突然いなくなります。しかし、代わりのディレクタのアサインは行われず、ディレクションや、プロモーション戦略を考えていく必要が出てきました。結果から言うと、この役割は半分失敗に終わります。 それは、戦略や計画を立てることはしましたが、開発に工数を取られ、実行や調整を行う工数が工面できなかったためです。この問題に対し、タスクを委譲できる単位に切り分け、他チームに分散して巻き取ってもらう調整をつけ解決しました。 # マネジメント このプロジェクトではマネジメントにも挑戦しました。 このプロジェクトに課せられたミッションは大きく3つで以下のとおりです。 * カメラアプリの本体アプリである位置情報ケームのゲーム外のユーザ体験を向上させる * SNSにおける画像つき投稿のコンバージョン率の高さを利用した拡散力の獲得 * できれば年初から始めて、GWまでにリリースしたい このプロジェクトにおいてまずはリリース時期が最大のネックでした。位置ゲームのスピンオフという立ち位置上、行楽シーズンに間に合わせるのは至上命題です。 また、拡散力についての要求もありますので、アプリの快適さや、写真のクオリティーも落とせません。 つまりこれは、短納期高品質が要求される難題でした。 これに対して私は、まずリーンスタートのアプローチを取ることで、GWに間に合わないという事態を回避しました。 また、カメラアプリ開発で工期を取られる中でも、比較的省コストで実現できるフォトコンテストをGWでのバイラルを狙い開催します。 こちらはフォトコン以前に行ったイラストコンテストの焼き直しですが、イラコンより参加の敷居が下がるため、投稿数を稼げる目論見がありました。 このプロジェクトでの心残りは、自分のポリシーに反し、結果的にマイクロマネージメントになってしまっていた事です。 プレイイングマネージャーで起こりがちな事態ではありますが、短納期も相まって、同じ轍を踏む結果となってしまいました。 この反省から、健全なデベロップメントチームを作るためのプラクティスとしてスクラムを学習し、後述の駅メモ2期でのSMとしての振る舞いにつなげるきっかけとなりました。