ID:79252さん

# 概要 PCの操作ログを収集し可視化することで、業務 の効率化を支援するツール # 役割 - プロダクトロードマップに沿った開発計画 - 技術選定 - アーキテクチャ選定 - 要件定義~保守運用まで開発業務全般 - コードレビュー - ピープルマネジメント - エンジニア採用 ## マネジメント観点 - チーム内での行動指針の策定。会社ビジ ョン、事業部OKRに沿った行動を心がけ れるような、行動指針を策定した。この行動指針を意識すれば必然的に、半期に 1回の社内の評価に繋がるような内容で ある。スプリント毎にメンバーの目標、 行動指針に沿った行動の振り返りを行い、メンバーの成長に繋がるフィードバックやネクストアクションの設定を行なった。 - 事業部のOKRをPdMがプロダクトロードマップとして落とし込んだ。それを私 がスクラムに落とし込み、スプリントが進むと同時にロードマップを歩めるようにスクラム開発を進めた。 - チーム内での役割の明確化と仕組み化。 明示的に1人1人に役割・責務を提示し た。また、属人化にならないかつ、いつ誰がアサインされても業務が回るような仕組み化を行なった。 - メンバーのロードマップの作成とタスクへのアサイン。各メンバーに将来自分が なりたい像のロードマップを作成してもらい、共有してもらっている。自分は今どの位置で、何を満たせば次のステップ に進めるかという定量的なゴールも自身で設定してもらっている。業務の中で、 メンバーが設定したロードマップを歩め るようになタスクをできる限りアサイン するようにしている。 # 課題 - 私が参画した時点でエンジニア0名、β版のみのリリース、導入企業2社、改善が見られない ようであれば、事業部の撤退予告を会社から告 げられていたタイミング。 - 技術面では、リリース中のβ版も不具合多発、 ソースコードは前任者のオレオレFWになって おり解読不可能、各種環境変数の引き継ぎなし 等、とても開発を進められる状態ではなかっ た。 # 打ち手 - 事業部存続、新規顧客獲得がこの時の目標。 選択肢は2つ。 ①既存のコードに改修をかけつつ、新規顧客獲得のための施策を打つ ②フルリプレイスの実施 ②を実施。既存コードを読み解く時間で1から実装し直した 方が速いと判断したため。 # 結果 - 会社から宣告された期限(4ヶ月)内でフルリプレイスに成功 - 導入企業50社まで増加させることに成功 - 新たに予算を確保することができ、エンジニア2名(正社員1名、業務委託1名)、PdM補佐1名の採用に成功 - 社内の別事業部と協業を行なっていく方針の確約

# 概要 PCゲームをプレイするためのゲームランチャー 開発 # 役割 バックエンド開発 # 課題 - MAU100万人程のシステムを、バックエンドはPHPからGolangへ、クライアント側はPHP のWebアプリからElectronのデスクトップア プリへリプレイスしたばかりであった。そのため、クリティカルエラー(操作続行不可能)が 頻発していた # 打ち手 - エラーログ設計を行い、ログ出力時にエラーコードを振るようにした。これによって、エラー 発生数と改修の優先順位づけを行えるようにした。 - 開発優先で雑に実装されたコードをテスタブル なコードに修正し、品質の担保を図った。 - キャッシュ戦略の見直しや実装のメモリ管理方法の見直しを図った。 # 結果 - 基本的には1関数1責務というテストタブルなコードに書き換えることができ、テストカバレッジ80%程度を保つことができた。これによ り、null pointerなどのクリティカルエラーを 限りなく0に近づけることができた。 - タイムアウトによるエラーを限りなく0に近づ けることができた。

# 概要 UFOキャッチャーをオンラインでプレイできる アプリ # 役割 要件定義~保守運用まで開発業務全般 # 課題 - 人的リソース(シニア層)の不足により、ビジネスサイドが提案した施策等が実施できずに、売上が停滞していた。 # 打ち手 - 私が参画することで、1人のシニア層のエンジニアだけで回していた業務やタスクの属人化をなくす。 - 担当分野をわけることで、知見を集中させ、短期的な開発速度を向上させた。 # 結果 - ビジネスサイドからの施策をスピーディに実施することができた。コロナ禍という大きな要因 もあり、決して私1人の力ではもちろんない が、私が在籍した期間は過去最高の売上を上げることができた。

# 概要 ゲームセンターのUFOキャッチャー等のゲームで 使用できる利用券の配信や、電子決済でのゲームプレイ、ゲームプレイの度に付与される経験値からランキングの算出・会員グレードの変動など、ゲームセンターを利用するユーザーのためのアプリ # 課題 - 元々は外注でPHPで作られていたシステムを、内製化する必要があった。同時に、社内の デファクトスタンダード技術としてGolangに していきたいとのことであったため、内製化と 同時にGolangへのリプレイスが必要であっ た。仕様書や設計書は外注先からもらうことが できなかった。 - 事業譲渡のタイミングであり、商標権の問題等から絶対的に期日を守る必要があった。 - 期日の短さとプロジェクト難易度の高さから、どんどんメンバーが離れていった。バックエンドチームはGolang未経験の私だけになっ た。 # 打ち手 - 実装を始める前に、とにかく既存のコードを読み漁り、簡易的な仕様書を起こした。 - 時間的ロスが許されない状況であったため、PM、クライアントチームと密に連携を取り、手戻りを限りなくなくすようにした。 - あとは「とにかくやる」これしかなかった。 # 結果 - 期日内に約100本のAPIをリプレイスし、大きな不具合なくリリースすることができた。事業 譲渡元の企業は日本トップクラスのエンタメ企 業であるが、経営陣から感謝の言葉をいただいた。