ID:85898さん

## プロジェクト概要 東芝テック株式会社向け次世代リテールPOSシステムの新規開発。Flutter／Dartを用いたクロスプラットフォームアプリケーションの開発に、プロジェクトの初期段階から参画。顧客から提示された要件・HTMLプロトタイプをもとに、共通UIコンポーネントの開発やPOS業務機能の設計・実装を担当。 ## チーム構成・役割 - Flutter開発チーム：4名（テクニカルリード1名、開発者3名） - QAチーム：2名 - マイクロサービス開発チーム：6名（テクニカルリード1名、開発者5名） - 自身の役割：Flutterエンジニアとして機能開発・実装を担当。チーム内ではテクニカルリードに次ぐ経験者の一人として、若手メンバーへの技術的なアドバイスやコーディングに関する支援も実施。また、英語・日本語の両方に対応できるメンバーとして、顧客と海外開発チーム間の技術的なコミュニケーションを支援。 ## 担当業務・技術的な取り組み ### 1. 共通UIコンポーネントおよびテーマ機能の開発 **【概要・開発内容】** POSアプリケーション全体で利用する共通UIコンポーネントの設計・実装を担当。ボタン、ダイアログ、入力フォームなどをFlutterの再利用可能なWidgetとして開発。 **【課題・問題点】** アプリケーション内の複数画面で共通のUIコンポーネントを使用するため、画面ごとに異なる要件や状態（有効・無効など）に対応しながら、アプリケーション全体のデザインと操作性に一貫性を持たせる必要があった。また、ユーザーが利用中にテーマカラーを変更できる仕組みも必要だった。 **【工夫したこと・技術的なアプローチ】** - FlutterのWidgetを活用し、複数画面から共通利用できるUIコンポーネントを実装。 - ボタンなどのコンポーネントについて、有効・無効状態に応じたスタイルの切り替えに対応。 - FlutterのThemeDataやThemeModeを拡張し、独自のテーマ管理機構を組み合わせ、アプリケーション全体のテーマカラーを実行時に変更できる仕組みを実装。 - ライトモード・ダークモードの両方に対応し、テーマ変更を各画面のUIに反映。 **【成果】** 共通UIコンポーネントとテーマ機能を構築し、アプリケーション全体で統一されたデザインと操作性を実現。複数画面におけるUIの再利用性と保守性の向上に貢献。 ### 2. POSチェックアウト・決済処理機能の開発 **【概要・開発内容】** POSシステムの主要業務機能であるチェックアウト処理の開発を担当。現金投入から注文・決済情報の送信、レシート印刷までの一連の処理を実装。 **【課題・問題点】** チェックアウト処理では、現金投入機器、バックエンドAPI、デバイスブローカー経由のプリンターAPIなど、複数の外部システム・機器と連携する必要があった。それぞれの処理を連携させ、POSアプリケーション上で一連の業務フローとして実現する必要があった。 **【工夫したこと・技術的なアプローチ】** - デバイスブローカーが提供するAPIを通じて釣銭機と連携し、投入金額を取得・確認する処理を実装。 - 注文情報および決済情報をバックエンドAPIへ送信する処理を実装。 - デバイスブローカー経由でプリンターAPIと連携し、レシートデータを送信する処理を実装。 - API通信や外部機器との連携で発生するエラーを考慮し、異常発生時のエラーハンドリングおよび復旧処理を実装。 **【成果】** 釣銭機、バックエンドサービス、プリンターとの連携を含むチェックアウト機能の実装に貢献し、POSシステムにおける主要な業務フローを構築。 ### 3. 売上ジャーナル検索・結果表示機能の開発 **【概要・開発内容】** POSシステムに蓄積された売上ジャーナルを検索するためのフォーム画面、および検索結果の一覧・プレビュー画面を開発。 **【課題・問題点】** 業務要件に基づいた検索条件の入力インターフェースと、検索結果を確認するための一覧・詳細プレビュー画面を実装する必要があった。 **【工夫したこと・技術的なアプローチ】** - 売上ジャーナルの検索条件を入力するフォームUIを実装。 - 検索結果を一覧表示する画面を開発。 - 個々の検索結果の内容を確認できるプレビュー画面を実装。 **【成果】** 売上ジャーナルの検索から検索結果の確認までを行うための画面機能の開発に貢献。 ### 4. HTMLプロトタイプの解析およびFlutterへのUI再実装 **【概要・開発内容】** 顧客から提示されたHTMLプロトタイプをUI仕様の参考資料として、Flutterによる画面の再実装を担当。 **【課題・問題点】** HTMLプロトタイプには画面レイアウトやデザインに関する明確な仕様書がなく、各UI要素の配置、サイズ、色、アニメーションなどの詳細をソースコードから読み解く必要があった。単純な画面構成の再現だけでなく、プロトタイプの視覚的な表現や動作をFlutter上で再現することが課題だった。 **【工夫したこと・技術的なアプローチ】** - HTML／CSSのソースコードを調査し、レイアウト構造、各要素の寸法、色、アニメーションなどのデザイン情報を分析。 - GitHub Copilotを活用し、HTML／CSSソースコードの解析やFlutterによる参考実装の生成を行い、技術調査および実装方法の検討を効率化。 - 分析した情報をもとにFlutterでの実装方法を検討し、HTMLプロトタイプのUIをFlutter Widgetとして再構築。 **【成果】** 明確なUI仕様書が存在しない状況でも、既存のHTML／CSSプロトタイプを技術的に解析し、FlutterによるUI実装を推進。AIを活用したソースコード解析も取り入れ、仕様理解から実装までの作業効率向上に貢献。 ## その他の担当業務・貢献 - 顧客要件に基づく技術的な実現方法の検討。 - 基本設計書・詳細設計書の作成およびレビューへの参加。 - 単体テストの作成および不具合修正。 - 若手Flutter開発メンバーへの技術的なアドバイスやコーディング支援。 - 日本語・英語による顧客と海外開発チーム間の技術的なコミュニケーション、翻訳・通訳支援。 ## 開発環境・技術スタック - 言語：Dart - フレームワーク：Flutter - 状態管理：Riverpod - 開発OS：Windows

### プロジェクト概要 Toyota Woven Cityの居住者・来訪者などを対象とした、Flutterによるクロスプラットフォームモバイルアプリの開発。アプリ内で利用可能な複数のミニアプリを提供し、ユーザーが必要な機能を選択して利用できる仕組みを開発。 ### チーム体制・役割 - **チーム構成：** Scrumによる単一チーム体制。Flutter開発者4名（テクニカルリード1名、開発メンバー3名）、バックエンド開発者約5名、QAエンジニア2名。プロジェクトマネージャーおよびプロダクトオーナーと連携。 - **担当役割：** Flutter開発メンバーとして、機能開発、既存機能の保守・改善、単体テスト・Widgetテストの実装、コードレビューなどを担当。 ### 担当業務・技術的な取り組み **1. ホーム画面のイベント表示機能** - **【課題・問題点】** - プロトタイプ段階のアプリにおいて、ホーム画面から開催予定のイベント情報を分かりやすく確認できるUIが必要だった。 - **【工夫したこと・技術的なアプローチ】** - ホーム画面にイベント情報を横スクロールで表示するカルーセルUIをFlutterで実装。 - イベント選択時には、詳細情報を全画面で表示する画面遷移を実装。 - プロトタイプ段階のデータソースとしてFirebase Firestoreを利用し、イベント情報の取得・表示を実装。 - **【成果】** - ホーム画面からイベント一覧の確認、個別イベントの詳細確認までをシームレスに行えるUIを実現。 **2. ミニアプリの有効化・オンボーディング機能** - **【課題・問題点】** - メインアプリ内でミニアプリを有効化する際、動画、静止画像、利用規約の表示、ユーザーの同意取得など、複数のステップを組み合わせたオンボーディングフローが必要だった。 - ミニアプリごとに表示内容や手順が異なるため、アプリ側の実装を固定せず、バックエンドの設定に応じて柔軟に表示できる仕組みが求められた。 - **【工夫したこと・技術的なアプローチ】** - バックエンドから取得した設定情報を読み取り、動画・静止画像・利用規約・同意取得などの各ステップを順番に表示する仕組みをFlutterで実装。 - 設定情報に基づいてオンボーディングの内容と表示順序を動的に構成できるようにした。 - **【成果】** - バックエンド側の設定変更によってオンボーディングの内容や順序を変更できる仕組みを実現し、アプリの再リリースを必要としない柔軟な運用を可能にした。 **3. Riverpodを利用した状態管理・チャット機能の改善** - **【課題・問題点】** - Riverpodを広範囲に利用するアプリにおいて、複数画面間で共有する状態を適切に維持する一方、不要になった状態を適切なタイミングで破棄する必要があった。 - チャット機能では、バックエンドAPIから取得するデータとWebSocketによるリアルタイムデータストリームを組み合わせて管理する必要があった。 - **【工夫したこと・技術的なアプローチ】** - Riverpodの`autoDispose`および`keepAlive`を活用し、Providerの利用状況に応じて状態のライフサイクルを制御。画面遷移後も維持すべき状態と、不要になった際に破棄すべき状態を適切に管理。 - チャット機能の開発の一部を担当し、バックエンドAPIから取得したデータとWebSocketによるリアルタイムデータストリームを画面状態に反映する処理の実装およびデバッグを担当。 - **【成果】** - 複数画面間で共有する状態の維持と不要な状態の破棄を適切に制御し、アプリ全体の状態管理の安定性向上に貢献。 - チャット機能におけるAPIデータとリアルタイムデータの連携に貢献。 **4. テストカバレッジの改善** - **【課題・問題点】** - 過去にリリースした機能において、Unit TestおよびWidget Testが不足している箇所があり、アプリ全体のテストカバレッジは約60%だった。 - 新規機能の追加や変更によってテストカバレッジが低下することを防ぐため、継続的に品質を維持する仕組みも必要だった。 - **【工夫したこと・技術的なアプローチ】** - 既存機能のテスト不足箇所を補うため、Unit TestおよびWidget Testを追加実装。 - CI/CDパイプラインにテストカバレッジの最低基準を設定し、Pull Requestによって基準値を下回る場合はマージできない仕組みを導入。 - プロジェクト離任時点では、最低カバレッジ基準を75%に設定。 - **【成果】** - チーム全体でテストの追加と品質維持に取り組み、アプリ全体のテストカバレッジを約60%から約75%まで改善。 - Pull Requestのマージ時にカバレッジ基準をチェックすることで、テスト品質を継続的に維持する仕組みを確立。 **5. Androidのアプリ言語設定に関する改善提案** - **【課題・問題点】** - Androidアプリの言語切り替えについて、OS標準のアプリ別言語設定との一貫性を保ち、ユーザーがより簡単に設定を変更できる方法が求められた。 - **【工夫したこと・技術的なアプローチ】** - アプリ内にAndroid OS標準のアプリ言語設定画面へ遷移するショートカットを設ける方法を提案。 - OS側で設定されたアプリ言語をアプリ内にも適切に反映する仕組みを実装。 - 提案は採用され、アプリへの実装まで行われた。 - **【成果】** - OS標準の設定画面を利用した言語切り替えを実現し、Androidの標準的な操作性との一貫性を向上。 ### その他の業務 - Scrum開発プロセスにおけるタスク遂行、仕様確認、プロダクトマネージャー・プロダクトオーナー・バックエンド開発者との連携。 - 既存コードのリファクタリング、コードレビュー、技術ドキュメントの作成・整備。 - Mocktailを利用したUnit Test・Widget Testの実装およびテストカバレッジの維持・改善。 ### 技術環境 - **言語：** Dart - **フレームワーク：** Flutter - **状態管理：** Riverpod - **データソース・通信：** Firebase Firestore、REST API、WebSocket - **テスト：** Mocktail、Unit Test、Widget Test - **開発手法：** Scrum

### プロジェクト概要 楽天ペイAndroidアプリの機能開発・保守、および決済プラットフォーム向けAndroid SDKの開発。既存アプリのJavaからKotlinへの段階的な移行とClean Architectureの導入を進めながら、新規機能開発や本番環境で発生した不具合の調査・対応を担当。 ### チーム体制・役割 - **チーム構成：** Androidチーム5名（セミテックリード1名、開発メンバー4名）、iOSチーム4名（セミテックリード1名、開発メンバー3名）。バックエンドチームおよびQAチームはそれぞれ独立した体制。 - **担当役割：** Android開発メンバーとして、主に楽天ペイAndroidアプリの機能開発・保守を担当。既存機能の改修、新規機能実装、API連携、テスト、不具合調査などに従事。 ### 担当業務・技術的な取り組み **1. 既存Androidアプリのモダナイゼーション（JavaからKotlinへの移行・Clean Architectureの導入）** - **【課題・問題点】** - 大規模な既存Androidアプリの保守性・拡張性を向上させるため、JavaからKotlinへの段階的な移行とClean Architectureの導入を進めていた。 - プロジェクトには多数の外部ライブラリや依存関係が存在しており、移行対象の選定やライブラリのバージョンアップによる既存機能への影響を慎重に検証する必要があった。 - 既存機能への影響を最小限に抑えながら、段階的に新しいアーキテクチャへ移行することが求められた。 - **【工夫したこと・技術的なアプローチ】** - 既存のJavaクラスをKotlinへ移行するとともに、新規機能についてもKotlinで実装。 - MVVMアーキテクチャを採用し、ViewModelとLiveDataを利用したUI状態管理を実装。 - View Bindingを活用し、UIとロジックの分離および保守性の向上に取り組んだ。 - 大規模な既存コードベースとライブラリ間の依存関係を考慮し、移行対象やライブラリの更新範囲を慎重に選定。バージョンアップによる既存機能への影響を確認しながら段階的に移行を実施。 - **【成果】** - 既存JavaコードのKotlin化と新規機能のKotlinによる開発を通じて、アプリのモダナイゼーションおよびClean Architectureへの移行を推進。 - 既存機能への影響を考慮した段階的な移行により、従来のアプリケーションとの互換性を維持しながら、今後の機能拡張や保守性向上に向けた基盤整備に貢献。 **2. クレジットカード利用開始前のオンボーディング機能** - **【課題・問題点】** - クレジットカードを申し込み済みで、物理カードがまだ届いていないユーザーに対し、カード情報が手元になくても楽天ペイの支払い方法として登録できるようにする必要があった。 - ユーザーの申し込み状況など複数の条件を確認し、クレジットカードを支払い方法として追加できるかを判定する必要があった。 - 開発初期段階ではバックエンドAPIのモックデータしか提供されておらず、フロントエンド側の開発・検証を効率よく進めるための工夫が必要だった。 - **【工夫したこと・技術的なアプローチ】** - バックエンドチームからSwagger形式で提供されたAPI仕様書に基づき、Androidアプリ側のAPIインターフェースおよび連携処理を実装。 - APIの実データが利用できない開発初期段階では、Charles Proxyを利用してAPIリクエスト・レスポンスをシミュレーションし、フロントエンドの実装と動作確認を並行して推進。 - クレジットカードの申し込み状況など、複数の条件に応じた利用可否判定と支払い方法への追加処理を実装。 - 決済に関わる重要なユーザーフローであることを踏まえ、さまざまな条件や処理パターンを想定した探索的テストを重点的に実施。 - **【成果】** - 物理カードの受け取り前でも、所定の条件を満たしたユーザーがクレジットカードを支払い方法として登録できるオンボーディング機能の開発に貢献。 - Charles ProxyによるAPIレスポンスのシミュレーションを活用し、バックエンドAPIの実データが利用可能になる前からフロントエンド開発と検証を進めることで、開発効率の向上に貢献。 - 探索的テストを通じて、複数の利用条件や画面遷移を含む一連の処理の動作を検証。 **3. 本番環境の不具合調査・原因分析** - **【課題・問題点】** - カスタマーサポート（CS）から報告される本番環境の不具合について、ユーザーの操作状況や発生条件を特定し、原因を調査する必要があった。 - アプリ側のログだけでは問題の発生箇所や原因を特定できないケースもあり、複数の情報源を組み合わせた調査が必要だった。 - **【工夫したこと・技術的なアプローチ】** - CSから起票された不具合チケットをもとに、バックエンドAPIサーバーのエラーログとアプリ側で記録されたテレメトリデータを照合し、問題の発生箇所を調査。 - CXプラットフォームKARTEのユーザーセッション追跡機能を活用し、ユーザーの画面遷移や操作履歴を確認することで、不具合発生時の状況を把握。 - 複数のログ・追跡データを組み合わせて原因を切り分け、問題が発生している機能を特定したうえで、該当機能の担当開発者へ調査結果を共有。 - **【成果】** - サーバーログ、アプリのテレメトリデータ、ユーザーセッション情報を活用し、本番環境で発生した不具合の原因特定を支援。 - 問題が発生している機能や状況を明確にすることで、担当開発者による修正対応を支援し、調査・切り分けの効率化に貢献。 ### その他の業務 - 単体テストの実装およびPull Requestのコードレビュー。 - カスタマーサポートやプロダクトマネージャーからの問い合わせ対応。 - Android SDKの開発立ち上げに参加し、外部パートナー向け決済連携機能の開発に着手。 - 日本語・英語・中国語を用いた関係者間のコミュニケーションおよび通訳・翻訳支援。 ### 技術環境 - **言語：** Kotlin、Java - **アーキテクチャ：** MVVM、Clean Architecture（導入推進） - **Android Jetpack：** ViewModel、LiveData、View Binding - **API連携：** REST API、Swagger - **開発・調査ツール：** Android Studio、MITMプロキシ、Karte - **その他：** Git、Pull Request、単体テスト

**プロジェクト概要** 香港のHSBCが提供するP2P・B2C決済アプリ「PayMe」のAndroid版の開発・保守。新機能の開発に加え、既存機能の改善、アクセシビリティ対応、本番環境の不具合調査・修正などを担当。 **チーム構成・役割** - Android・iOS開発者約20名で構成され、3～4つのScrumチームに分かれて新機能開発、既存機能の保守、技術的負債の解消などを担当。 - QAチームは開発チームとは別に設置。 - 開発メンバーは同一タイムゾーン内の2つの地域に分散しており、リモートでのコミュニケーションを通じて開発を推進。 - Android開発メンバーとして、新機能の開発を中心に、既存機能の改善や本番環境の不具合修正にも従事。 ### 1. 割引クーポン機能の開発 【課題・問題点】 - ユーザーが利用可能な割引クーポンを一覧表示し、使用前に取得する機能を開発。 - クーポンには取得可能な数量や期間に制限があり、取得済み・未取得などの状態を分かりやすく表示する必要があった。 - クーポン券をイメージした不規則な形状の枠線や、切り取り線のようなデザインを、画面サイズやフォントサイズが異なる端末でも崩れずに表示する必要があった。 【工夫したこと・技術的なアプローチ】 - クーポンの取得状態に応じた一覧表示や、取得可能なクーポンの状態管理を実装。 - AndroidのXMLレイアウトを工夫し(`ConstraintLayout`の活用など)、複雑なチケット風デザインを実現。 - 異なる画面サイズやフォントサイズでの表示を確認し、レイアウトの一貫性を確保。 【成果】 - クーポンの取得状態や利用条件をユーザーが把握しやすい画面を実現。 - 多様な端末環境においても、デザインの一貫性を維持したUIを実装。 ### 2. eKYC（オンライン本人確認）機能の開発 【課題・問題点】 - 複数のステップで構成される本人確認フローにおいて、ユーザーごとの手続き状況に応じて適切な次のステップを表示する必要があった。 - セルフィー撮影や身分証明書の画像確認には、サードパーティ製の本人確認ライブラリとの連携が必要だった。 【工夫したこと・技術的なアプローチ】 - ユーザーの本人確認状況を判定し、完了済みのステップを考慮して次に実施すべき手続きを制御する処理を実装。 - サードパーティ製の本人確認ライブラリをAndroidアプリに組み込み、セルフィー撮影や身分証明書の画像確認機能と連携。 【成果】 - ユーザーの本人確認状況に応じて、適切な手続きを進められるeKYCフローの実現に貢献。 ### 3. 生体認証によるログイン・決済認証機能の開発 【課題・問題点】 - ログイン時や決済実行前の認証にAndroid OSの指紋認証機能を利用。 - 一部のSamsung製端末では指紋センサーに不具合が確認され、生体認証を正常に利用できないケースがあった。 【工夫したこと・技術的なアプローチ】 - Android OSが提供する生体認証機能を利用した認証処理を実装。 - 指紋センサーに不具合が確認されたSamsung製端末を対象外として扱い、生体認証が利用できない場合はPIN認証へ切り替える仕組みを実装。 【成果】 - 生体認証を利用したログイン・決済認証を実現するとともに、特定端末での不具合発生時にもPIN認証による代替手段を提供。 ### 4. アクセシビリティ対応の改善 【課題・問題点】 - 会社全体で進められていたアクセシビリティ改善活動の一環として、視覚に障がいのあるユーザーや大きなフォントサイズを利用するユーザーにも配慮したUIへの改善が必要だった。 - 既存の画面レイアウトの一部はフォントサイズの拡大に十分対応できず、表示崩れが発生する可能性があった。 【工夫したこと・技術的なアプローチ】 - Android公式ドキュメントや外部アクセシビリティ専門ベンダーからの推奨事項を参考に、TalkBack対応やContent Descriptionの設定、フォントサイズ変更への対応を実施。 - 特にフォントサイズ拡大への対応では、既存レイアウトの構造を見直し、デザイナーと協力して画面表示を改善。 - Android OSやフレームワークの仕様に関する技術的な知見を共有し、実現可能なUI改善方法を提案。 【成果】 - TalkBackやフォントサイズ変更への対応を通じて、アプリのアクセシビリティ向上に貢献。 - デザイナーや外部専門ベンダーと連携し、ユーザーの利用環境に配慮したUI改善を推進。 ### 5. 本番環境の不具合調査・修正対応 【課題・問題点】 - QAチームやカスタマーサポートから報告される本番環境の不具合について、発生条件や原因を特定し、修正する必要があった。 - ユーザーの利用環境や操作状況によっては、開発環境で同じ問題を再現できないケースもあった。 【工夫したこと・技術的なアプローチ】 - まず開発環境で不具合の再現を試み、Android StudioのDebuggerなどを利用して原因の切り分けを実施。 - ローカル環境で再現できない場合は、必要に応じてサーバーログを依頼するとともに、アプリのクラッシュレポートも確認し、原因調査を実施。 - 原因を特定した後は、自ら修正を実装。長時間解決に至らない場合は、他のメンバーに相談し、チームで解決に取り組んだ。 【成果】 - 不具合の再現確認から原因調査、修正実装まで一貫して対応し、アプリの品質維持と安定稼働に貢献。 - 必要に応じてチームメンバーと連携し、難易度の高い不具合の解決にも取り組んだ。 **その他の担当業務** - Scrum開発プロセスに沿ったスプリント計画、デイリースクラム、レビュー、レトロスペクティブへの参加。 - チームメンバーとのコードレビューや技術情報の共有。 - 新機能の実装に加え、Mockitoを用いたユニットテストを作成し、機能の正常性や処理の妥当性を検証。 - QAチームとの連携による機能検証・不具合対応。 **技術環境** - 言語：Kotlin、Java - フレームワーク・ライブラリ：Android SDK、RxJava、Mockito - UI：Android XML Layout - 開発ツール：Android Studio、Git - 開発手法：Scrum、アジャイル開発

**プロジェクト概要** Android TV向けの動画配信アプリケーションおよびセットトップボックス（STB）向けプラットフォームの開発。ATV、i-Cable NewsのAndroid TVアプリ開発に加え、OpenSky.tv STB向けのAndroid TV OSランチャーのカスタマイズを担当。 **チーム構成・役割** - Android開発チームのテクニカルリードとして、4名の開発メンバーを技術面からサポート。 - PMOが示す全体方針に沿って、各メンバーがプロダクトバックログから担当タスクを選択する開発体制。 - チーム内で技術的な議論を行い、メンバーの経験や知識レベルを考慮しながら、実装しやすく保守性の高いアーキテクチャや技術方針を検討・決定。 - コードレビューや技術的な質問への回答、問題解決に向けた方向性の提示を通じて、メンバーの開発を支援。 - テクニカルリードとしての技術的な役割に加え、自身もアプリケーションやランチャーの設計・実装に従事。 ### 1. Android TV向け動画配信アプリケーションの開発 【課題・問題点】 - i-Cable Newsアプリでは、ライブTV配信とVOD（Video on Demand）の両方に対応する必要があった。 - ATVアプリでは、VODを中心とした動画視聴機能の提供が求められた。 - 配信動画はDRMで保護されているため、動画プレイヤーがDRM対応コンテンツを正常に再生できることを確認する必要があった。 【工夫したこと・技術的なアプローチ】 - ExoPlayerを採用し、Android TV向けの動画再生機能を実装。 - ExoPlayerが提供するAPIを利用して、アプリケーションのUIや操作性に合わせた再生コントロールをカスタマイズ。 - DRMで保護された動画コンテンツについても、プレイヤーとの連携や再生動作を確認し、正常に視聴できるよう対応。 【成果】 - i-Cable NewsのライブTV配信・VOD機能、およびATVのVOD機能を備えたAndroid TVアプリケーションをリリース。 ### 2. OpenSky.tv向けAndroid TV OSランチャーのカスタマイズ 【課題・問題点】 - OpenSky.tv STB向けに、動画コンテンツを探しやすく、直感的に操作できるホーム画面を実現する必要があった。 - ホーム画面には複数の動画コンテンツ一覧を横方向のカルーセル形式で表示し、画面全体は縦方向にスクロールできる構成が求められた。 - 横方向・縦方向のスクロールが組み合わさるため、フォーカス移動やスクロール操作を含めた画面全体の動作を適切に制御する必要があった。 【工夫したこと・技術的なアプローチ】 - AOSP（Android Open Source Project）で公開されている既存のAndroid TVランチャーのソースコードをベースに、製品要件に合わせてカスタマイズ。 - ホーム画面に複数の横スクロール型カルーセルを配置し、画面全体を縦方向にスクロールできるレイアウトを実装。 - Android TVの操作性を考慮しながら、複数方向のスクロールが共存する画面構成を検討・調整。 【成果】 - OpenSky.tv STB向けに、動画コンテンツをカルーセル形式で表示するカスタマイズ版Android TVランチャーを開発・リリース。 ### 3. i-Cable Newsアプリの可変サイズグリッドUIの開発 【課題・問題点】 - i-Cable Newsアプリにおいて、ニュースコンテンツを柔軟に配置できるグリッド形式のUIが必要だった。 - 通常の均等サイズのグリッドではなく、複数の行・列にまたがる異なるサイズのアイテムを混在させ、空きスペースを後続のアイテムで効率的に埋める必要があった。 - 採用したオープンソース実装にはスクロール動作に問題があり、既存コードの調査と修正が必要だった。 【工夫したこと・技術的なアプローチ】 - オープンソースプロジェクトをベースに、3列構成の可変サイズグリッドUIを実装。 - 1×1、2×2、3×1、3×2、3×3など、複数のサイズのアイテムを配置できる仕組みを構築。 - アイテムの配置状況に応じて空きスペースを後続のアイテムで埋めることで、柔軟なレイアウトを実現。 - 元のオープンソース実装で発生していたスクロール関連の不具合について、コードを調査・デバッグし、問題の修正に取り組んだ。 【成果】 - 異なるサイズのコンテンツを柔軟に配置できるグリッドUIを実現。 - オープンソース実装のスクロール問題を修正し、アプリケーションへの組み込みを実現。 ### 4. 開発プロセス・CI/CD環境の改善 【課題・問題点】 - 開発チームとQAチームが継続的にビルドを共有できるよう、ビルド作成やリリース配布の効率化が必要だった。 - コード品質やテストカバレッジを継続的に確認できる仕組みも必要だった。 【工夫したこと・技術的なアプローチ】 - 既存のJenkinsパイプラインをチームやQAチームの運用に合わせてカスタマイズ。 - 自動・手動のビルド実行やリリースのデプロイに対応し、QAチームが必要なタイミングでビルドをダウンロードできる環境を整備。 - JaCoCoをビルドパイプラインに組み込み、テストカバレッジレポートを自動生成。 - SonarQubeをコード品質の可視化・確認用ダッシュボードとして利用し、定期的に品質状況をレビュー。 【成果】 - ビルド作成とQAチームへの配布を効率化し、継続的な検証を支援。 - テストカバレッジとコード品質を確認できる環境を整え、開発品質の維持・改善に貢献。 ### 5. 技術リード・チームメンバーへの技術支援 【課題・問題点】 - メンバー間のAndroid開発経験や技術知識の差を考慮しながら、チーム全体で円滑に実装を進められる開発体制が必要だった。 - アーキテクチャや技術選定によっては、特定のメンバーに知識が偏り、実装時の理解度や作業効率に差が生じる可能性があった。 【工夫したこと・技術的なアプローチ】 - 実装開始前にメンバーと技術的な議論を行い、チーム全体が理解しやすく、無理なく実装できるアーキテクチャや技術方針を検討・決定。 - メンバーから寄せられる技術的な質問に回答し、必要に応じて問題解決に向けた方向性や調査方法を提示。 - コードレビューを通じて実装内容を確認し、技術的な改善点や設計上の注意点を共有。 【成果】 - チームメンバー間の知識格差や実装時の認識のずれを抑え、チーム全体で開発を進められる体制づくりに貢献。 - 技術的な意思決定と実装支援の両面から、チームの開発品質と生産性の向上を支援。 **プロジェクト成果** - ATV、i-Cable News、OpenSky.tvの3製品をリリース。 - 特にi-Cable Newsアプリは、3製品の中で最も多くダウンロードされ、比較的高いユーザー獲得実績を達成。 **技術環境** - 言語：Java - アーキテクチャ：MVVM - フレームワーク・ライブラリ：Android SDK、ExoPlayer、AOSP Launcher - CI/CD・品質管理：Jenkins、JaCoCo、SonarQube - 開発手法：アジャイル開発、コードレビュー、技術ディスカッション