ウルトラ深瀬

# 概要 - マンション管理組合向けマンション自主管理サポートアプリプロジェクトの開発 # 担当フェーズ - 立ち上げフェーズ - 新規機能開発 - 機能設計 - 詳細設計 - 運用保守 # メンバー - PM1名 - ディレクター1名 - iOS2名(運用フェーズは1名) - Android2名(運用フェーズは1名) - テスター2名 - サーバサイド5名(運用フェーズは3名) # 使用技術 - Swift - Flux + MVVM - RxSwift - RxCocoa - RxDataSource - RxMoya - Firebase - Auth0 # 業務内容 - 各種機能開発 - アプリの主要機能であるお金周りの機能の実装 - Auth0を利用した認証機能の実装 - Push通知の実装 - 強制アップデート機能の実装 - エラーハンドリングの実装 - ローカルバリデーションの実装 # 実績・取り組み - FluxのStoreをキャッシュとして活用した省エネ設計 　Store内のObservableにBehaviorRelayを渡す様に設計し、一度他の画面で叩いたAPIレスポンスの結果を他の画面でもう一度叩くことなく取り出せる様にしたことで、APIの叩く回数を減らしユーザーへのストレス軽減にも繋げられたと思います。具体例としては一覧や詳細画面から先の編集画面において、編集元の初期値となる一覧/詳細画面の値などでの利用です。また、仕様上内容の更新の頻度が少ないコンテンツ（選択肢としての銀行一覧情報や、サービス内の一部の情報）のGETにおいては、アプリ起動中に一度叩いたレスポンスを繰り返し利用し、画面を開くたびに無駄にAPIを叩いてしまわない様に制御をしました。また、レスポンスを通常の変数ではなくObservableとして格納することで、コンテンツの編集後に叩く一覧や詳細画面のGETが返ってきたタイミングでbindが貼られている表示画面が自動的に更新される仕組みになり、コンテンツの更新をよりスムーズにすることが出来ました。 - 端末の文字サイズ設定への可変対応における横並びラベル系UIのレイアウト崩れ対策 　当アプリがITリテラシーの低い中高年者向けということもあり、端末設定での文字サイズに追従してアプリ内の文字サイズも可変対応させることは重要なUX要素の１つでした。その為DynamicTypeを用いてラベル系はStoryboard上で、ボタン系はコードにて共通の設定をし、それぞれ指定の幅まで拡張＆改行させる対応を施しました。ここで頭を悩ませたのが要素横並び系のレイアウトへの対応でした。例えばタイトルと説明など、どちらも重要で文字サイズが大きい場合でも最後まで表示させたい場合がありました。結論としては「Content Hugging Priority」と「Content Compression Resistance Priority」「優先度の高い要素に最低横幅指定の設定」などを組み合わせて対応しました。また、基本的にStackView in ScrollViewにすることで改行した際に全体レイアウトが自動調整されるように実装をしました。また、今回は制約を組み合わせて文字サイズ可変に対応しましたが、サービスのデザイン時点で要素横並びの様なレイアウトが崩れやすい構造を多用していないか、他のアプローチがないかなどを提案していくことも必要かもしれないと学びました。 - プッシュ通知開封時の関係画面への自動遷移実行時にAuth0の自動再認証が干渉して稀に遷移失敗するバグの解決 　プッシュ通知を開いたタイミングで通知に関係のある画面へ自動遷移させる実装をしましたが、その際に稀にAuth0の自動再認証が同時に走ることでタイミングが合わずに自動遷移に失敗するバグがありました。ケースとしては、通知開封時点でアプリが起動されていなかった場合且つ、ネットワーク状態によって認証に時間がかかった場合でした。認証完了後のHOME画面への遷移処理の方が後に来た場合には、通知に関係のある画面へ自動遷移した後に再度HOME画面に戻ってしまう事象です。その対策として、通知開封時に認証が走っていた場合には関係画面への自動遷移処理を予約処理として登録＆後の任意のタイミングで実行できるクラスを作り、認証が完了した後のHOME画面にて処理を実行させることで対応しました。クラスはシングルトンで任意のキー名と共にFunctionに内包した処理を登録し、実行時にもキーを指定して登録の有無をチェックして実行させています。また、意図せずキー名の重複などで処理が書き変わってしまうことを防ぐ為、enumのStringValueにてキー名を指定し、他に存在する処理の視認性向上も測りました。 - 保守性と技術適性の観点による、RxDataSourceから標準UITableViewへの実装差し替え等、オーバースペックな技術選定の見直し 　当時Rxでの書き方への統一の意味合いでRxDatasourceを導入しましたが、後輩エンジニアへの学習コストの高さと導入必要性が見合わないことを問題視し、標準UIKit実装（UITableView / UICollectionView / 各種アニメーション）の差し替えを行いました。オーバースペックだと判断した主な理由としては、RxDatasourceの売りでもある差分更新の恩恵を受ける様な複雑な画面仕様が少ないことが挙げられます。また、これは当アプリのデザイン仕様自体がITリテラシーの低い高齢者向けに組まれていることからあえて複雑な操作性が求められる画面デザインを避けたことが起因しています。以上の経験から、現在では技術的好奇心と実装コストや納期との兼ね合いを慎重に判断し、エンジニアの自己満開発になってしまわない様に気をつけています。また、限られた開発工数の中でもそれらを顧客やサービスへの価値づくりに回せるように意識しています。

# 概要 - 遠隔医療＆電子カルテ系アプリのプロジェクトの開発リード # 担当フェーズ - 立ち上げフェーズ - 新規機能開発 - 機能設計 - 詳細設計 # メンバー - PM1名 - ディレクター1名 - iOS2名 - Android2名 - テスター3名 - サーバサイド3名 # 使用技術 - Swift - MVVM + Store - CoreNFC - RxSwift - RxCocoa - RxMoya - Firebase # 業務内容 - 各種機能開発 - CoreNFCを活用した物理ICカードとの連携認証実装 - SMS認証の実装 - Push通知の実装 - 強制アップデート機能の実装 - エラーハンドリングの実装 - ローカルバリデーションの実装 # 実績・取り組み - サーバーエラー構造の統一形式の提案 　サーバーサイドとのエラー構造の取り決めにおいて、拡張性があり且つ全てのエラーパターンでも共通の型で対応できるスキーマを提案しました。これは社内の他プロジェクトで起きていた開発上の障壁やチーム内での認識齟齬などによる実装のズレなどの失敗例を元に考えたものです。エラーの種類ごとに専用のスキーマを定義、ドキュメントにてそれらを管理していましたが、メンバーが入れ替わるにつれてサーバーサイドエンジニア内での共有漏れや、アプリメンバーとの認識のずれなどによる実装のズレなど混乱が発生し、その都度APIの修正依頼をするなどの手間が発生していました。その経験から当プロジェクトでは、全てのエラーで共通の型を使用し、３桁のエラーコードの他により細かくケース分けするための手段としてルート階層にオプショナルな６桁の拡張エラーコード、さらに最下層にオプショナルのKeyを配置しそれぞれの振り分けに関する取り決めを作りレアケースへの対応をしました。 - SMS認証入力画面での自動ペーストでカーソルがずれる問題の対策 　SMS認証コードを入力する６つのフォームが並んだ画面において、カーソルが左端からずれた場所に置かれている際、コード受信時のキーボード上部に表示される「メッセージから○○○○○○」というサジェスチョンをタップした場合に入力位置がずれてしまう問題が見つかりました。調査の結果、キーボード上のサジェスチョンとそのタップによる自動入力はiPhone端末自体の仕様で制御されており、アプリからそれを検知する正当な術がないことが判明しました。その為、対策としてキーボードが空の状態ではどのカーソル位置でも強制的に入力値を一番左に移動させて書き換えてしまう提案も考えましましたが、ユーザーの意図との乖離が大きな挙動はユーザーへの混乱に繋がるという判断に至りました。結論として、遷移時に最初から左のカーソルをFirstResponderに指定した上で、さらにキーボードが閉じられてしまった後で再度いずれかのフォームがタップされた際には各フォーム上に設置した透明ボタンを作動させ、一番左のフォームにカーソルを当てる制御を追加する方法で対処しました。 - ストア審査におけるテスト認証時の物理ICカード＆SMSが必須である問題の解決案提案（リジェクト回避提案） 　サービスへのログイン認証においてSMS認証と物理ICカード認証（NFC）が必須であるというサービス仕様があり、アメリカApple社で行われるストア審査でのリジェクトが懸念される問題がありました。SMS認証に関しては以前にApple社から審査時のみスキップする特別対応を求められた経験があった為、審査用の特別な導線の提案を行いました。物理ICカードによるNFC認証に関しては、アメリカのApple社へカードを送付することは現実的では無いと判断し、対応の結論としては審査提出ページにて英語での事情説明と、実際のユーザーが行うSMS認証＆NFCカード認証の様子を収めたデモ動画を撮影し、提出することで結果的に無事審査を通過することが出来ました。また、審査時には製品版と全く同じバイナリを提出する必要があった為、審査用の分岐コードを最小限に抑える必要がありました。その為にNFC認証だけでなくSMS認証も全てデモ動画の内容に含めることでスキップし、結果としては審査用に用意した電話番号＆パスワードでのログイン時のみ特別なアクセストークンを受け取り、それ以降の認証は全てスキップするというシンプルな実装にすることで製品版への影響を最小限にすることが出来たと思います。

# 概要 ARで遠くの木の高さを計測する業務支援アプリのモック開発 # 担当フェーズ - 要件ヒアリング - デザイン - 機能設計 - モック開発実装 - 現場検証 - 改善提案 # メンバー - PM1名 - ディレクター1名 - iOS1名 # 使用技術 - Swift - ARKit - SceneKit - Photoフレームワーク # 業務内容 - 要件ヒアリング - 画面デザイン作成 - ARを用いた垂直計測方法の考案実装 - 遠く離れた対象物への計測オブジェクトの射出実装 - 計測オブジェクトの設置位置を微調整するコントローラー盤の実装 - 撮影画像のExif情報を遠くの対象物の位置情報に書き換える処理実装 - 現場検証 - 改善案考案 # 実績・取り組み - ざっくりとした要望「遠くの対象物を離れたところから高さを計測したい」への実現方法の考案 　AR技術を用いて垂直計測を行うことは比較的容易でしたが、対象物への距離を正確に測ることはライダースキャナでも距離の限界があることなどから現実的では無いと判断し、別途市販のレーザー計測器と組み合わせることを提案しました。そして、対象物への距離を取得した後に対象物の根本に計測オブジェクトを指定距離分射出し、そこから垂直に高さを計測する方法を考案しました。また、対象物に一度近づくことができる場合も想定して木の根本に直接計測オブジェクトを設置する方法も別途用意し提案しました。この実装考案に関して社内の技術責任者であるCTOから評価して頂くことが出来ました。 - モックアプリを用いた公園での現場検証テストにて、平均誤差１割未満という要望をクリアする精度を実現 　モックアプリを実際に用いた公園でのテストにて高さ7m〜15m程の木と街灯一本、合計8本を計測しました。実際の木の高さは影を比較する手法にて計測し、平均結果はクライアント要望の誤差１割未満をクリアする結果を残すことが出来ました。 - 精度向上への提案 　現状の実装の問題点として、計測オブジェクトが木の頂点付近に達した時の判断には複数の角度から確認する必要があることと、計測者によるムラが発生してしまうことが考えられました。その改善提案として、計測オブジェクトに円盤状の補助パーツを付けることにより、視覚的に頂点到達の妥当性を判断することがより正確にできる仕様を考案しました。この改善仕様に関しては社内のコンサル責任者からも評価して頂くことが出来ました。

# 概要 - ARシューティングゲームアプリプロジェクトの開発（サービス名：AR-GunMan） # 担当フェーズ - 立ち上げフェーズ - 新規機能開発 - 機能設計 - 詳細設計 - 追加機能開発 - 運用保守 # メンバー - iOS1名（個人開発プロジェクトの為） # ソースコードリンク https://github.com/Fukase-Takamasa/AR-GunMan # 使用技術 - Swift - MVVM - ARKit - SceneKit - ParticleSystem - CoreMotion（加速度とジャイロセンサー） - AudioKit - AudioToolBox - RxSwift - RxCocoa - Firebase # 業務内容 - 各種企画開発 - ARKit（SceneKit）を活用したシューティングゲーム実装 - 加速度とジャイロセンサー（CoreMotion）を活用したネイティブならではの直感的操作の実装 - ParticleSystemを活用した爆発等の特殊効果実装 - SCNActionを活用した各種３Dモデルの細やかな動きを実装（発砲時の反動、銃の持ち手の緩やかな手振れ、ユーザーの移動に合わせた銃の横揺れなど） - 的とロケットランチャー３Dオブジェクトの自作実装 - Push通知の実装 # 実績・取り組み - ステイホームを逆手に取ったAR演出の考案 　的の設置範囲をおおよその室内サイズに合わせ、屋内で身体を動かしながらストレスを発散できるユニークなアプリを企画しました。的の設置範囲の選定にあたってはユーザーが立った状態で端末を構えていることを想定し、縦の範囲は床までの距離を考慮して下は短く上を長めに設定するなどの工夫をし、的の位置のリアリティを考慮した仕様を考案しました。 　 - 加速度とジャイロセンサー（CoreMotion）を活用したネイティブならではの直感的操作の実装 　弾の発射やリロード（補充）などのアクションにはありきたりなUIButtonではなく、ネイティブアプリならではの加速度とジャイロセンサーを活用し、身体を動かすアクティブな体験を考案しました。弾の発射アクションでは端末を的に向けて強く振る又は実銃の反動を再現する様に後ろに強く振ることを採用しました。この仕様はミリタリーな趣味を持つ人の趣向も満たしつつ、尚且つ強制的に照準をブレさせることで、反動をなるべく抑えないと的に当たらない＝大人も本気で遊べる仕組みを作る為でした。 　　 - 衝突検知によるシューティング実装 　SCNPhysicsContactDelegateを用いた衝突検知により、的へのヒット判定を正確に行うことでよりゲーム性を向上することが出来ました。 - ParticleSystemを活用した爆発等の特殊効果実装 　ロケットランチャー着弾時の爆発にParticleSystemを使用し、迫力のある特殊効果演出を自作しました。 - SCNActionを活用した各種３Dモデルの細やかな動きを実装 　- 発砲時の反動：リアルな反動を再現する為、座標移動の角度を研究しました。 　- 銃の持ち手の緩やかな手振れ：リアルな３Dモデルも静止していると平面の画像に見えてしまい勿体無い為、FPSゲームでよく見る様な人間の緩やかな手ぶれを再現しました。これを再現するために、垂直移動とX軸回転を組み合わせ、さらに実行秒数をあえてずらすことで不規則な動きを作り出し、より自然な動きを実現しました。 　- ユーザーの移動に合わせた銃の横揺れ：これまたFPSゲームでよく見る様なユーザーが走っている時の武器の乱れた動きを再現するため、ユーザーの素早い移動を検知する実装を行いました。タイマー機能により一定秒数前からのSCN座標内移動距離に応じてユーザーが素早く移動したと判断した時に、横揺れと縦揺れを組み合わせた動きを実行し、よりゲームらしさを高める実装を行いました。 - 的とロケットランチャー３Dオブジェクトの自作実装 　的とロケットランチャーの３Dオブジェクトに関しては、無料の素材で気に入ったものがなかった為、SCNオブジェクトを変形＆組み合わせることで自作し、当アプリオリジナルなオブジェクトをローコスト実装しました。