ID:82467さん

## シニアカー走行シミュレータ開発 **期間：** 2023年5月 〜 2026年2月 ### チーム情報 | 役割 | 人数 | 担当内容 | |------|------|----------| | エンジニア（自分） | 1名 | 要件定義・設計・実装・外部連携・デザイン指示まで一貫して担当 | | 上長エンジニア | 1名 | 実装物のレビュー・確認（稼働はスポット） | | 3D / 2Dデザイナー | 複数名 | アセット・UI制作（自分が仕様・指示を出しディレクション） | | 営業事務 | 1名 | テスト実施・マニュアル作成 | エンジニアとして開発全体を実質1名で推進しながら、デザイナー・事務など複数職種をハブとして動かす役割も担った。 ### プロジェクト概要 シニアカー（電動車いす）の安全利用促進を目的として、バーチャル空間で操作体験できるシミュレータを開発。病院・電動車いす安全普及協会へのヒアリングをもとに要件定義を実施し、上流工程から実装・リリースまで一貫して担当。 **技術スタック：** C# / Unity / Windows Forms / TCP・UDP通信 / Excel（データ駆動設定） --- ### 開発・実装内容A｜データ駆動型設計の導入 **【概要】** 仕様変更に柔軟に対応できるよう、パラメータをExcel・テキストファイルで管理できるデータ駆動型の設計・実装を担当。 **【どのような機能の開発・実装か】** シニアカーの走行パラメータ（速度・挙動特性など）、テキストの置換表、コースの組み合わせ設定といった要素をプログラム外部から調整可能な構成にした。 **【課題・問題点】** 仕様変更のたびにコードを直接修正すると、対応工数が増大するうえミスのリスクも高まる。また、調整可能な範囲を広げすぎると、プログラム側で特定の状態を制御しにくくなるトレードオフがあった。 **【打ち手・使用した技術】** 会社の既存知見としてデータ駆動設計の方針はあったが、どのパラメータを外部化するか・どこまでを可変範囲とするかは自分で設計判断を行った。プログラム制御が必要な特殊状態を壊さない範囲で外部化する境界を定め、ExcelおよびTxtファイルでの設定管理を実装。（自分が設計・実装） --- ### 開発・実装内容B｜歩行者AIの行動制御改善 **【概要】** 街中に出現する歩行者AIの挙動不自然さを解消するための設計・実装。 **【どのような機能の開発・実装か】** シミュレータ内の歩行者がプレイヤー（シニアカー）に対して適切に回避・すれ違い動作を行うAI挙動の制御。 **【課題・問題点】** 歩行者がプレイヤーの進路上で止まって動けなくなり邪魔になる、すれ違い時にキャラクターが重なるなどの問題が発生。複雑な条件分岐で回避ロジックを組もうとすると、ケースの抜けが生じ予期せぬ挙動の温床になっていた。 **【打ち手・使用した技術】** 複雑な行動パターンを排除し、シンプルな行動のみを取る設計方針に切り替えた。条件分岐を最小化することでケース漏れをなくし、挙動の調整もしやすい構造に。結果として目の前で止まる・重なるといった問題が解消され、デバッグ・パラメータ調整のコストも削減。（自分が設計・実装） --- ### 開発・実装内容C｜ログ出力の非同期処理化 **【概要】** ログ書き出し処理によるフレームレート低下を解消するためのパフォーマンス改善実装。 **【どのような機能の開発・実装か】** シミュレータ稼働中のログをリアルタイムで書き出す処理の最適化。 **【課題・問題点】** メインスレッド上でログ書き込みを行っていたため、書き込みのたびに処理が詰まり、画面のカクつきが発生していた。 **【打ち手・使用した技術】** ログをバッファに蓄積し、非同期でファイルに書き出す方式に変更。メインスレッドの処理をブロックしない構造にすることで、カクつきが体感上ほぼ解消。（自分が設計・実装） --- ### 開発・実装内容D｜Windows Forms × Unity の二画面構成 **【概要】** シミュレータ体験画面とUI操作画面を分離した二画面構成の設計・実装。 **【どのような機能の開発・実装か】** Unity製シミュレータ本体とは別に、設定・操作用のUIをWindows Formsアプリとして構築し、TCP/UDP通信で双方向に連携させる仕組み。 **【課題・問題点】** 実際にシミュレータを体験する人とUIを操作する人（スタッフ等）が異なるケースがあるため、画面を物理的に分ける必要があった。Unity画面内にUI操作を同居させる案も検討したが、UI表示のためだけにUnityの解像度を上げるとパフォーマンスコストに見合わず、操作性・表示品質の両立が困難だった。 **【打ち手・使用した技術】** 会社の既存知見（TCP通信・ソフト分離の設計パターン）をベースに採用しつつ、通信内容の仕様設計や本プロジェクトへの拡張・適用は自分で行った。UI専用アプリとしてWindows Formsを採用し、通信プロトコルは用途に応じてTCPとUDPを使い分けた。 - **TCP** — 双方で状態を保証する必要がある共有パラメータの同期に使用 - **UDP** — 状態保証は不要でUnity側への指示を送るだけでよい操作系の通信に使用 役割分離により体験者・操作者それぞれに最適な画面環境を実現しつつ、Unityのパフォーマンスへの影響を最小限に抑えた。（通信仕様の設計・実装は自分が担当）

## 弁理士向けWebサービス商用化改修 **期間：** 2024年8月 〜 2025年7月 ### チーム情報 | 役割 | 人数 | 担当内容 | |------|------|----------| | エンジニア（自分） | 1名 | 要件定義〜実装・バージョンアップ・テスト・運用対応まで一貫して担当 | | 上長エンジニア | 1名 | サーバー環境の準備・実装物のレビュー・確認 | PHP・Laravelの実務経験がない状態から独学でキャッチアップしながら、サーバー準備以外の開発全体を実質1名で完遂。 ### プロジェクト概要 取引先の特許事務所が社内利用していたWebツールを商用サービスとして展開するための改修プロジェクト。顧客との要件定義から実装・DB最適化・バージョンアップ・展示会対応まで一貫して担当。 **技術スタック：** PHP / Laravel（→v11へ移行）/ Tailwind CSS / MySQL / Docker / WordPress --- ### 開発・実装内容A｜DB検索パフォーマンス改善 **【概要】** 機能追加に伴い発生した検索速度の大幅な低下を解消するためのDB最適化。 **【どのような機能の開発・実装か】** ユーザーが条件を指定して特許関連データを検索する機能のクエリ・DB構造の見直し。 **【課題・問題点】** 機能追加後、検索処理がタイムアウトするケースが発生。データ数の多いテーブルへの直接参照や、文字列加工を伴うWHERE句が原因でクエリが重くなっていた。 **【打ち手・使用した技術】** 以下の3段階で対処した。（すべて自分が設計・実装） 1. **リレーションテーブルの活用とインデックス追加** — 大テーブルへの直接参照を避け、結合経由でアクセスする構造に変更。検索頻度の高いカラムにインデックスを追加。 2. **検索専用カラムの追加** — 文字列加工を伴うカラムを直接参照していた箇所に対し、加工済みの値をあらかじめ格納した検索専用カラムを新設。クエリ実行時の加工処理を排除。 3. **検索数の上限設定** — タイムアウトの根本対策として、1回の検索件数に上限を設けるよう顧客に提案・合意を得て実装。 結果として、タイムアウトが解消され、検索処理が約1秒以内で完了するようになった。 --- ### 開発・実装内容B｜Laravelの複数メジャーバージョン移行 **【概要】** 古いバージョンで稼働していたLaravelを最新のv11まで段階的にバージョンアップ。 **【どのような機能の開発・実装か】** 本番稼働中のシステムのフレームワーク自体を複数メジャーバージョンにわたってアップグレード。 **【課題・問題点】** メジャーバージョンをまたぐ移行では、記法の変更・非推奨APIの廃止・依存ライブラリとの互換性問題など、複数種類のエラーが同時に発生する。一気に移行すると原因の切り分けが困難になる。 **【打ち手・使用した技術】** 公式マニュアルに沿い、メジャーバージョンを1つずつ段階的に移行する方針を採用。各バージョン移行ごとにエラーを潰してから次に進むことで、原因特定を容易にしながら最終的にv11への移行を完遂。（自分が方針策定・実装） --- ### 開発・実装内容C｜非推奨ライブラリの代替選定・コード刷新 **【概要】** 開発中に発見した更新停止ライブラリの代替選定と、それに伴うコード全面修正。 **【どのような機能の開発・実装か】** 既存コードが依存していたライブラリのメンテナンス状況の調査と、安全な代替への切り替え。 **【課題・問題点】** 開発中に使用ライブラリの1つが更新停止していることを発見。そのまま使い続けるとセキュリティリスクや将来的な互換性問題につながる恐れがあった。 **【打ち手・使用した技術】** 代替ライブラリを調査・選定し、依存箇所のコードを全面的に修正。ライブラリの保守状況を能動的に確認する姿勢により、システムの持続性を確保。（自分が調査・選定・実装）

## Androidアプリ開発 **期間：** 2021年4月 〜 2023年4月 ### チーム情報 | 役割 | 人数 | 担当内容 | |------|------|----------| | エンジニア（自分） | 1名 | 企画・設計・実装・申請・保守まで一貫して担当 | | 上長エンジニア | 1名 | レビュー・確認（稼働はスポット） | | 2D / 3Dデザイナー | 1名 | アセット・UI制作（主に2D、一部3Dあり。自分が仕様・指示を出しディレクション） | ### プロジェクト概要 Unity / C#を使用したAndroidアプリを12本リリース（他に完成・未リリース4本）。企画立案からUI/UX設計・実装・ストア申請・リリース後の保守運用まで、開発全工程を担当。 **技術スタック：** C# / Unity / Firebase / Google Play Game Services / Google AdMob --- ### 開発・実装内容A｜クイズアプリ量産フローの構築 **【概要】** 同フォーマットのクイズアプリを効率よく量産できる開発フローの設計・構築。 **【どのような機能の開発・実装か】** プロジェクトのテンプレート化と、CSVによる問題・画像データの差し替え仕組みの実装。 **【課題・問題点】** 同形式のアプリを複数本リリースする必要がある中、毎回ゼロから開発すると工数が膨大になる。 **【打ち手・使用した技術】** プロジェクトをテンプレートとして複製し、画像と問題データのCSVを差し替えるだけで別タイトルとして成立する仕組みを構築。既存資産を最大限再利用することで、1本あたりの開発工数を大幅に削減し、短期間でのリリースサイクルを実現。（自分が設計・実装） --- ### 開発・実装内容B｜季節性コンテンツの企画・検索流入施策 **【概要】** ストア検索での流入増加を狙った、季節性テーマによるアプリ企画。 **【どのような機能の開発・実装か】** アプリのテーマ・タイトル選定における企画立案。 **【課題・問題点】** 多数のアプリが並ぶストア上で自然流入を増やすためには、検索需要が高まるタイミングを狙ったコンテンツ選定が必要だった。 **【打ち手・使用した技術】** 季節イベントや時事に合わせたテーマを選定し、検索需要が高まる時期にリリースを合わせる企画方針を立案・実行。（自分が企画立案・上長へ提案）