ID:13838さん

# プロジェクト概要 機器制御アプリ開発 ## 業務内容 機器制御アプリのバージョンアップ開発 ### 詳細内容 機器制御アプリのバージョン5系がリリースされた後に開発に参加。 アプリケーションは，Kotlin Multiplatform Projectを使用してビジネスロジック部分を共通化し， UI部分をAndroidはKotlin，iOSはSwiftを使用していた。 iOS開発はほぼ未経験だったため早急にSwiftやXcodeの使い方などを覚え， 簡単な不具合やバージョン4系のアップデート対応などをやりながらプロジェクト内を把握。 現在バージョン5系へのる新規機能の実装を行なっている。 ### プロジェクト人数・役割 - プロジェクト人数 - プロパーエンジニア9名 - 協力会社エンジニア1名 - 役割 - 協力会社エンジニア1名 ### 環境 - 開発環境 - Android Studio - Kotlin - Android Jetpack - ktor - Xcode - Swift - Storyboard - アーキテクチャー - MVP - その他 - Slack - Confluence - Figma - Trello ### 問題点 - Xcode，Swift及びStoryboardなど使い方が全くわからなかった。

# プロジェクト概要 携帯キャリア向け健康管理アプリの開発 ## 業務内容 健康管理アプリの新規開発 ### 詳細内容 健康管理アプリの新規開発でアプリの開発が半分程度終わっている段階で開発に参加。 未完成部分の機能を担当。 開発に当たっては次の３点が求められていた。 - 早急な仕様把握 - 早急なAndroidプロジェクト（ソースコード）の把握 - 未完成部分の機能実装 アプリ内の３画面程の新規画面の開発（調査・設計・コーディング・テスト）を担当。 １つの画面内にプログレスバーやグラフ（棒グラフや折れ線グラフ）があり、 表示する内容毎にプログレスバーやグラフの表示内容を切り替える等の開発規模が大きな画面を担当。 また，プロパーエンジニアリーダーがiOS側につきっきりであったため， Androidエンジニア内で相互レビューを行なっていた。 ### プロジェクト人数・役割 - プロジェクト人数 - プロパーエンジニアリーダー１名 - Android協力会社エンジニア３名 - iOS協力会社エンジニア３名 - 役割 - Android協力会社エンジニア ### 環境 - 開発環境 - Android Studio - Kotlin - Android Jetpack - Dagger - Retrofit - groupie - MPAndroidChart - CircularProgressBar - アーキテクチャー - MVVM - マルチモジュール - その他 - Slack - JIRA - InVision ### 問題点 - iOS開発が遅れていてプロパーエンジニアリーダーがiOS側につきっきりであった - 仕様の最終的な変更などが仕様書やデザインに反映されていなかった（Slackのやり取りを追っていく必要があった）

# プロジェクト概要 テレビ局向け動画再生アプリの開発 ## 業務内容 既存動画再生アプリのリニューアル開発 ### 詳細内容 リニューアルアプリのデザインやワイヤーフレーム、モックアプリ（iOS）が完了し、実装の始め頃に参加。 アプリのリニューアルに伴ってサーバーとのAPIもすべてリニューアル開発することになり、 アプリを開発する際にサーバーとのAPIが未確定なまま開発が始まり次のような流れで開発を行った。 - デザインやワイヤーフレームの各機能を実現するための技術調査 - サーバーとのAPI仕様が確定するまでは、アプリのUI部を先行して開発 - API仕様が確定したものから社内にダミーサーバーを用意してUI部と通信部分の繋ぎ込み アプリ内の10画面程の新規画面の開発（調査・設計・コーディング・テスト）を担当。 ### プロジェクト人数・役割 - プロジェクト人数 - プロパーエンジニアリーダー１名 - Androidプロパーエンジニア２名 - iOSプロパーエンジニア１名 - Android協力会社エンジニア１名 - iOS協力会社エンジニア２名 - ディレクター２名 - デザイナー１名 - 役割 - Android協力会社エンジニア ### 環境 - 開発環境 - Android Studio - Kotlin - Android Jetpack - Koin - Fuel - moshi - groupie - その他 - Teams - Jooto - Zeplin ### 問題点 - APIが想定と違ったり、実装してい行くうちに何度も変更したりして出戻りが発生 - スケジュールがタイトであった

# プロジェクト概要 Android向けIPアクションゲーム開発 ## 業務内容 ゲーム用コントローラーでAndroid(ゲームアプリ)を制御するシステム開発 ### 詳細内容 Android(ゲームアプリ)を新規リリースするにあたり、そのゲームアプリに特化したゲームコントローラーを販売する事が決まっていました。 ゲームコントローラーはBluetooth Low Energy（BLE）でAndroidと接続し、BLEの通信でAndroidと命令のやり取りを行います。 ゲームコントローラーのROM FIXは製造工程上アプリリリースの数か月前であり、ゲームコントローラーのROM FIXの約１か月前にジョイン。 開発内容としては主に次の２点となる - ゲームコントローラー操作確認アプリの開発 - Unreal Engine 4上でAndroidのBLEを制御するためのプラグイン開発 1. ゲームコントローラー操作確認アプリの作成 ゲームコントローラーのROM FIX(１か月後)までにAndroidアプリとゲームコントローラーをBLEで繋ぎ、Androidからゲームコントローラーの制御及びゲームコントローラーからAndroidアプリの操作で問題ない事が確認できるアプリの作成。 AndroidのBluetooth Low Energy（BLE）制御は未経験だったため、早急に制御方法を調査し、ゲームコントローラーの制御仕様にそってゲームコントローラー操作確認アプリを作成。 2. Unreal Engine 4上でAndroidのBLEを制御するためのプラグイン開発 ゲームアプリはUnreal Engine 4で開発しているため、Unreal Engine 4上でAndroidのBLEを制御する必要があり、BLE制御するためのプラグイン開発。 Unreal Engine 4はC++でプログラムを書いていて、AndroidのBLEを制御はJAVA APIを使用することでしか使用出来ない。 このため、Unreal Engine 4から命令を受けるC++側の実装及びJAVA層に命令を伝達しAndroid BLEのJAVA APIを呼び出すモジュールを実装。 ### 問題点 ゲームコントローラーのROM FIXが迫っている中のジョインで、ゲームコントローラーの確認及び修正時間を考慮すると２週間〜３週間程度の短い期間でゲームコントローラー操作確認アプリの開発を求められた。 ### 問題点の対応 iOS側は先行開発していたため、iOS開発者へ詳細の確認。 早急なAndroid Bluetooth Low Energy（BLE）制御の確認及び参考コードの調査。 ### プロジェクト人数・役割 - プロジェクト人数 - マネージャー１名 - 協力会社Androidエンジニア１名 - 役割 - 協力会社Androidエンジニア ### 環境 - 開発環境 - Android Studio - Android SDK - Android NDK - Java - C++ - Unreal Engine 4 - その他 - Slack

# プロジェクト概要 カーナビ向けAndroid OS(Android 8.1)開発 ## 業務内容 Android Framework内にアプリケーションの起動優先度管理を行うManager開発 ### 詳細内容 アプリケーションの優先度とは，優先度の高いアプリの起動中であれば優先度の低いアプリの起動命令を待機させ，優先度の高いアプリの終了後に起動させる仕組みである。 カーナビではギアをバックに入れた状態ではリアカメラの映像を表示したり、車の異常時は緊急画面を表示したりしている。このような画面は他のアプリの起動によって阻害されてはカーナビの仕様上まずいためアプリに優先度をつけて起動の管理を行っています。 開発内容としては主に次の２点となる - 前機種（Android 6.0）からAndroid OSのバージョンが上がることによりアプリケーションの起動優先度管理を行うManagerの再開発 - ２画面に対応したアプリケーションの起動優先度管理を行えるようにする開発 1. アプリケーションの起動優先度管理を行うManagerの再開発 再開発するにあたり，各処理毎にイベント名を決めイベント毎に処理を別けるように変更し，各イベント処理後にオブザーバーにて後処理を行うように変更。 2. Robolectricを使用したユニットテストの導入 Android OSをビルドし実機にて動作確認するのには非常に工数が掛るため（実機で一回確認するのに早くても１時間程度），Robolectricを使用したユニットテストを追加（合計テスト件数3000件程）し，最低限の動作保証を確認出来てからAndroid OS上での確認を行い時間のかかる処理の削減を行ってきました。 3. ２画面に対応したアプリケーションの起動優先度管理 Android 8.1上で２画面に対応したアプリケーションの起動優先度管理を行えるかの技術的調査を行った。 明示的に画面を選んでアプリの起動を行うことが可能なのか，別の画面へ切り替え起動が可能なのか，画面の表示内容を入れ替える事が可能なのか等の技術的調査を行い，対応案を纏めメーカーへ報告。 ２画面に対応したアプリケーションの起動優先度管理システムの設計・実装・ユニットテストの作成を行った。 ### 問題点 1. Androidを常時２画面の状態で動作させているため、Androidの互換性テストスイート(The Compatibility Test Suite (CTS))で様々なエラーが発生。 各種エラー内容を調査し，対応方法を提案。メーカーと対応方法の合意後，Androidの互換性テストスイート中はAndroid AS-ISの動作に影響を与えないようシステムの変更実装。 2. 画面のちらつき問題 ２画面の位置を入れ替えたり，高速にアプリケーションの切り替えを行うと，一瞬画面が黒くなったり，一瞬前のアプリケーションの画面が見えたりといった問題が多数発生。 Android FrameworkのActivityManager，WindowManagerでアプリケーションの起動・終了処理の詳細な把握，起動時や終了時のアニメーションやその他のWindowの状態などを詳細に把握し各問題に対して修正方法の提案・実装。 ### プロジェクト人数・役割 - プロジェクト人数 - プロパーエンジニア３～４名（２名退職） - 協力会社エンジニア１名 - 役割 - エンジニア ### 環境 - 開発環境 - Android OS(Android 8.1) - Android Studio - Java - C++ - Gson - Gradle - Robolectric - Mockito - PowerMock - Jacoco - その他 - Git(Git Lab) - Skype - Slack - Rational Team Concert

# プロジェクト概要 デジタル動画販売において国内最大手のデジタル動画販売アプリの開発 ## 業務内容 既存動画再生アプリにデジタル動画商品の観覧・購入機能を追加するためのアプリリニューアル開発 ### 詳細内容 WEB（PCサイト及びSPサイト）でデジタル動画販売を行っていてアプリでもデジタル動画販売を行いたいというところで開発に参加。 開発に当たっては次の２点が求められていた。 - SPサイトでできることはアプリでもできるようにすること - なるべく使用できる既存のAPIを使用する このため開発当初はWEB（PCサイト及びSPサイト）の画面構成，各画面のAPI等の調査を行い，ディレクター，デザイナー及び開発メンバーとアプリの画面構成の設計を行いました。 アプリの画面構成決定後はWEB（PCサイト及びSPサイト）のAPIの使用と，使用できないものやAPI化されていない部分の情報はサーバーサイドエンジニアにAPI作成依頼を行いながら各画面を作成していきました。 アプリ内の20画面程の新規画面の開発（調査・設計・コーディング・テスト）を担当。開発開始からリリースまでの期間は約6か月となります。 ### プロジェクト人数・役割 - プロジェクト人数 - プロパーエンジニア１名 - 協力会社エンジニア３名（１名途中参加） - ディレクター１名 - デザイナー１名 - 役割 - エンジニア ### 環境 - 開発環境 - Android Studio - Java - Gson - ZXing - その他 - JIRA - Git(Stash) - Skype - Slack ### 問題点 - リニューアル開発のために各所からエンジニアが集まったため開発当初はギクシャクしていた - リリース当初はクラッシュ率が高かった - 担当画面ごとに属人化していた（アプリリニューアル開発後２名退職） 　 ## 業務内容 リニューアル開発後の機能追加及び保守。派生アプリ（Android TVアプリ, VR動画再生アプリ）開発 ### 詳細内容 #### 問題点の改善 リニューアル開発ではほぼレビュー無しに開発者が作成したコードをコミットできていた。このため次の導入を実施 - GitFlow的な運用の導入 - ２人程のレビュワーにレビューしてもらうことの徹底 - Jenkinsを使った自動ビルド確認 クラッシュ通知をSlackで受け取れるように連携し、直ぐにJIRAへ課題登録を行い機能追加対応との優先度を考慮した作業振り分け 各画面とその画面で呼び出しているAPIの資料化（全部で120API程使用していた） #### 機能追加対応 低価格月額サービス機能，無料体験機能，纏め買い機能，VRコンテンツの販売等の各種機能追加を担当。 対応に当たってはディレクター，デザイナーと画面構成の設計を行い，サーバーサイドエンジニアとAPIの設計を行ってきました。 ### プロジェクトにおける自身の役割 リニューアル開発から開発しているメンバーが私一人になってしまっていたため、各開発メンバーへTT。 開発メンバーの成果物に対してのレビューの実施。 ドキュメント化。 ### プロジェクト人数・役割 - プロジェクト人数 - プロパーエンジニア１～２名（１名退職及び２名途中参加） - 協力会社エンジニア１～５名（４名途中参加） - ディレクター１名 - デザイナー１名（各機能毎にデザイナー１名） - 役割 - リードエンジニア ### 環境 - 開発環境 - Android Studio - Java - Gson - ZXing - その他 - JIRA - Git(Stash) - Skype - Slack - OpenGrok

# プロジェクト概要 スマートフォン向けのAndroid OS(Android 4.0～5.1)開発 ## 業務内容 Android Media FrameworkのAudio開発 ### 詳細内容 1. Android Frameworkの調査 AndroidのFrameworkはAndroidのコードネームが変わるたびに大幅な修正が施されます。 担当したバージョンは次の通りです。 - Ice Cream Sandwich (4.0) - Jelly Bean (4.1, 4.2, 4.3) - KitKat (4.4) - Lollipop (5.0, 5.1) AndroidのFramework(OS)内にメーカー独自の対応を入れているため，バージョンが上がるたびに，Android Framework(OS)内にどのような変更が施されたのかの把握と，メーカー独自の対応に関する影響の把握を行う必要があります。 そのため，Android Media FrameworkのAudio部分に関して調査を実施。 2. バージョンアップの都度メーカー独自の対応の適用 Androidのバージョンアップ毎に過去に施してきたメーカー独自の対応を適用していく必要があります。最新のAndroid OSでのAndroid Media Frameworkの調査結果に基づきそのまま適用できるものはそのまま適用し、設計から修正が必要なものは設計・実装・テストを行ってメーカー独自の対応の更新を実施。 3. Hi-Res Audio開発 メーカーよりHi-Res Audioの再生及び出力を行いたい旨の要望を受けて，そのための調査・設計・実装・テストを担当しました。 WAV，FLAC，Apple Lossless(ALAC)の非圧縮音声や可逆圧縮音声フォーマットに関してHi-Resの再生をサポート。 MP3やAAC等の非可逆圧縮音声はHi-Res相当に出力を行うアップコンバートをサポート。 開発期間は１年ほどとなります。 開発ではまず，Android Media Frameworkを詳細に調査し，メーカー側に説明するための資料を纏め。どのように変更すればHi-Res Audioの再生が可能なのかの設計提案を行い，設計に沿って実装を行いました。 また，調査してもわからない個所などはチップメーカー（Qualcomm）へ問い合わせながら作業を進めていきました。 4. Auto Testの追加 Android Media Frameworkのテストを行うテストモジュールが存在しますが，それではメーカー独自の対応に関するテストを行えません。 メーカー独自の対応もサポートしたテストモジュール（InstrumentationTest）の開発を行いました。 ALACのテストや通話中の音楽再生等特殊なケースの自動化にも対応。 ### 問題点 1. 長時間労働 Android Media Frameworkのソースコードはソースコードのみで30Ｍ～40Ｍの巨大なシステムであり，Android AS-ISではHi-Res Audioの再生はサポートされていない，また誰も開発したことのない機能の開発のため有識者も存在しないため開発は困難で長時間労働（最大で月300時間以上の労働）であった。 Android Media Frameworkの把握（Android OSのVersionが上がるたびに実施）では再生ボタン押下～Audioデータのデコードまで，デコード後～リサンプリング、エフェクト加工処理まで，その後の音を出すまでの処理とある程度処理範囲を分けチーム内で担当者を割り当てて調査しチーム内で教え合う事で調査時間がなるべく少なくなるように対応。 各修正パッチの動作確認には最新環境での動作確認が必須となるが，Androidのソースコード取得には1時間程度かかりＯＳビルドには２～３時間必要となる。出社してからこのような作業を行っていては時間がかかるため，動作確認が必要な時は午前５時頃からソースコードを取得しビルドを自動で行うようにしておき，出社時にすぐに確認が行えるような環境を整えて作業時間が減るように対応。 2. 想定はしていたが動かしてみないとわからない不具合の対応 Hi-Res Audioの再生をしながらの通話やHi-Res Audioの再生をしながらのスピーカーでアラーム再生などで音が出なかったり，Hi-Res Audioの再生が普通の再生に切り替わってしまったりと問題が多発して長時間労働の一つの要因にもなった。 設計やソースコードの見直しの徹底及びチップメーカー（Qualcomm）に各問題点をどうすれば解決できるかアドバイスを求めたりして解決を図った。 ### プロジェクト人数・役割 - プロジェクト人数 - プロパーマネージャー１名 - 協力会社エンジニア３名 - 役割 - エンジニア ### 環境 - 開発環境 - Android OS(Android 4.0～5.1) - Java - C++ - C - その他 - Git(Gerrit) - OpenGrok

# プロジェクト概要 国内書店向け電子書籍アプリの開発 ## 業務内容 既存電子書籍アプリの機能改修 ### 詳細内容 既にアプリケーションが運営されている状態で既存電子書籍アプリの機能改修のため参加。 下記機能の開発を担当。 - XMDFのライブラリ更新 - .bookライブラリの更新 - EPUB対応 - 纏め買い対応 - UI改修 - 電子書籍ページめくりの高速化 - アプリ外ファイルの読み込み #### XMDFのライブラリ更新 XMDFとはシャープが開発した電子書籍コンテンツのフォーマットである。シャープ社より新しいライブラリとしてソースコード(C,C++)の提供を受け，それを既存のアプリケーションで使用できるよう対応。 #### .bookライブラリの更新 ボイジャー社より提供を受けている.bookライブラリの更新 ### EPUB対応 オープンフォーマットである電子書籍ファイルフォーマット規格に対応する開発。ライブラリ側はC++での開発。 ### 纏め買い対応 漫画など複数タイトルが存在するコンテンツでは一度に複数の購入ができるように対応したいとなり，仕様決め段階から参入。 買う時のUIの見せ方，買った後の本棚の見せ方などのUI面や，アプリとサーバーサイドの通信API決めなどに関わり，その後のアプリの実装も対応。 ### 電子書籍ページめくりの高速化 電子書籍のデコード処理をC++に移行することで処理を高速化。 ### アプリ外ファイルの読み込み ユーザーが独自にダウンロードしたコンテンツ(PDF，EPUB)をアプリで読めるように対応。 ### プロジェクト人数・役割 - プロジェクト人数 - プロパーエンジニア５名（Android，iOS含む） - 協力会社エンジニア３名 - デザイナー１名 - テスター１名 - 役割 - エンジニア ### 環境 - 開発環境 - Android SDK - Android NDK - Eclipse - Java - C++ - C - その他 - Trac - Subversion

# プロジェクト概要 携帯キャリア向け音楽プレーヤーアプリの開発 ## 業務内容 フィーチャー・フォン向けで運用されていた音楽プレーヤーアプリのAndroidアプリ化対応 ### 詳細内容 携帯キャリアがAndroid OS(2.0)搭載端末を発売するにあたり，フィーチャー・フォンで使用されていたアプリを，Androidアプリ化するための開発。 音楽プレーヤーアプリのAndroidアプリ化対応を担当。 下記機能を担当 - 音楽プレーヤーアプリ(Android)とPC上の音楽管理アプリとの通信（USB通信）機能 - 各端末メーカーがアプリを組み込むための導入手順書作成 #### 通信機能 携帯キャリア作成の通信仕様書に沿った通信プロトコルの実装。 PC側から送られてきた音楽データをAndroid デバイス側に保存及びPC側に送った音楽ファイルをAndroid デバイス上からの削除。 上記実装の単体・結合検査の実施。 #### 導入手順書 各端末メーカーはこのアプリケーションをプリインストールで組み込む必要があるため，その作業手順書の作成。 ### 問題点 スケージュールがとても短い中，チームメンバー全員がAndroidアプリの開発未経験なこと，2010年時点でAndroidの有識者がほとんど存在しなかったことなどから開発は困難で長時間労働（最大で月350時間以上の労働）であった。 また，数件の音楽ファイルなら問題にはならないが，数千件の音楽ファイルのやり取りや通信中のSDカード外し、USBケーブル外しなどでは問題が多数発生した。 結合・システムテストは他チームの開発メンバー等に手伝ってもらい開発者は実装・不具合調査に注力することで期限までに対応した。 ### プロジェクト人数・役割 - プロジェクト人数 - プロパーエンジニア３名 - 協力会社エンジニア２名 - 役割 - エンジニア ### 環境 - 開発環境 - Android SDK - Android NDK - Eclipse - Java - C++ - C - その他 - Subversion

仕事後や土日の時間を使ってAndroidアプリをリリースしています。 https://play.google.com/store/apps/developer?id=SACRED+SANCTUARY.INC&hl=ja - 企画，デザイン，コーディング，リリースまですべて1人で担当