Swift・iOS

Swiftを中心に学んだことを記録に残すブログです。技術に関係ない記事もたまに書いています。

エンジニアの職務経歴詳細

 

査定・買取アプリ（2020/10~）

概要

2020年9月にリリースした新規アプリのプロジェクトに、iOSアプリ開発担当として参加しています。

  • 役割

         iOSアプリ開発

  • 担当工程

         要件定義、設計、開発、テスト、運用/保守

  • 主な使用技術

          Xcode、Swift、SwiftUI、CocoaPods、LINE SDK for iOS Swift

          Git、Bitbucket、SourceTree

          MVVM

  • チーム規模（計7名）

          iOS 2名

          Android 1名

          API 1名

          デザイナー 1名

          ビジネス 2名

 

開発詳細

プッシュ通知機能とお知らせ画面の実装
  • 担当工程：要件定義、設計、開発
  • 役割：iOSアプリ開発
  • 利用技術・関連ツール：Xcode、Swift、Git、CocoaPods、Firebase Cloud Messaging
  • 概要:

査定アプリにて、プッシュ通知機能とお知らせ画面の開発を一人で行いました。

 

プッシュ通知機能ではFirebase Cloud Messagingを採用しました。採用理由としては、すでにFirebase Crashlyticsをプロジェクトに採用していたことで導入が容易であることと、メンバーが過去にFirebase Cloud Messagingを扱った経験があることから、プッシュ通知機能をリリースした後の改修や障害対応のスピードが担保できると考えたためです。

 

技術的な調査に関しては、業務外で簡単なモックを作成し、その内容をブログに残しました。モックをビジネス側のメンバーに見せることで、スピーディに要件定義を進めることもできました。

※対象のブログ記事:【SwiftUI】プッシュ通知を選択した時に特定の画面に遷移する - Swift・iOS

 

お知らせ画面ではSwiftUIを用いてお知らせを一覧で表示する画面とお知らせの詳細内容を表示する画面を実装しました。当時はiOS14とiOS15をサポートしていたのですが、TabViewの挙動がOSごとに違うため苦戦しました。具体的には、お知らせに関するタブを選択した時に、お知らせ一覧のViewで"onAppear(perform:)"を実装していると、iOS15では正常に"onAppear(perform:)"が一度だけ呼ばれるのに対して、iOS14では"onAppear(perform:)"が何度も呼ばれ続けてしまうという現象です。お知らせ一覧画面を表示する時には最新の情報を表示したいため、タブを選択した時にリロードをしたいのですが、上記のような不安定な挙動に対応する必要がありました。実際には、"onAppear(perform:)"での実装は避けて、"onChange(of:perform:)"でタブの選択状態を監視したうえでリロードを実行するようにしました。SwiftUIの挙動の不安定さに対して柔軟に解決方法を考える必要があることを学べた経験になりました。

 

ログイン機能
  • 担当工程：要件定義、設計、開発
  • 役割：iOSアプリ開発
  • 利用技術・関連ツール：Xcode、Swift、Git、CocoaPods
  • 概要:

IDとパスワードでのログイン、LINEログイン、Sign In with AppleのiOSアプリ側の技術的な調査と開発を一人で担当しました。
ログインしている会員限定のコンテンツなどの拡充のため実装することになりました。


設計としてはMVVMとCombineを採用しています。


LINEログインのボタンはUIKitを前提に作られているため、UIViewRepresentableを使用して表示し、LINEログインのデリゲートメソッドについてはCoordinatorを利用することで使えるようにしました。
アプリ側でアクセストークンを発行して、サーバー側でログイン処理を行い、処理が成功すれば独自のアクセストークンを発行してアプリに返すような設計にしました。


Sign In with Appleに関しては、SwiftUIを採用しているため、AppleのフレームワークであるAuthentication Servicesフレームワークの構造体SignInWithAppleButtonを利用して実装しました。
設計としては、まずアプリ側でApple IDによる認可のリクエストを行い、デリゲート関数authorizationController(controller:didCompleteWithAuthorization:)で認可コード（authorizationCode）を取得してサーバーへリクエストします。その後、サーバー側でログイン処理を行い、処理が成功すれば独自のアクセストークンを発行してアプリに返すようにしています。


スムーズに開発に入れるよう、業務外でログイン機能のモックを作成し、技術のキャッチアップを行いました。また、実装したことをブログに残しました。
※対象のブログ記事:【SwiftUI】ログイン画面の実装まとめ - Swift・iOS


※会社都合により開発案件の優先順位が変更されたため、ログイン機能の本格的な開発は一旦保留となっています。

 

---------------------------------------------------------------------------------------

ECアプリ（2018/07~）

概要

アプリの売上改善を目的として、企画と開発業務を1人で担当しました。


企画フェーズでは、アプリの利用状況や売上を元に開発内容の検討したり、社長へ開発内容に関する決裁をとったり、開発後の売上改善の成果を社長へ報告したりしていました。


開発フェーズでは、要件定義/設計/開発/テスト/運用保守まで一貫して行い、必要なアイコンなどのデザイン方針の検討も担当していました。


このアプリの担当になってから、月間最高売上額を約4倍に伸ばしました。

  • 役割

          iOSアプリ開発、API開発

  • 担当工程

          企画、要件定義、設計、開発、テスト、運用/保守

  • 主な使用技術

          Xcode、Swift、CocoaPods、Firebase、LINE SDK for iOS Swift

          Git、Bitbucket、SourceTree、Bitrise、fastlane

          PHP、Laravel、ZendFramework、Linux、Apache、MySQL、VisualStudioCode

          HTML

         MVC、MVP

  • チーム規模（計3名）

          iOS/API 1名

          デザイナー 1名

          ビジネス 1名

 

開発詳細

CI/CD環境の構築

TestFlightでの配布や審査提出作業を手作業で行なっている状況だったため、いつヒューマンエラーが起きてもおかしくない状態でした。そこで、Bitriseとfastlaneを使ってCI/CD環境を0から一人で構築しました。

 

CI/CDに関するサービスにはJenkinsやCircleCIなど他にも選択肢はあったのですが、コストが最小限に抑えられることと、アプリのCI/CDに注力していることからBitriseが最適だと思い採用しました。

 

審査提出まで全てBitriseで完全に自動化することも検討したのですが、非エンジニアが審査提出前にApp Storeに掲載する文言の編集をすることが度々あるため、完全自動化にこだわりすぎずにプロジェクトの運用に合わせるようにワークフローを作成しました。

 

本番環境用の具体的なフローとしては、fastlaneのmatchを使った証明書を読み込み、CocoaPodsをインストール、ビルド番号を設定、dSYMをFirebase Crashlyticsにアップロード、App Storeへアップロード、処理結果をSlackで通知するようにワークフローを作成しました。

 

証明書管理の改善

証明書の更新などの管理業務を担当していたものの、属人化していたため仕組み化が必要と感じていました。

 

そこで、上長に提案、許可を得たうえで管理方法を検討しました。自社のiOSエンジニアは私含めて2人しかいない状況、かつ、今後も増員の予定がなかったため、将来的には最悪iOSの知識がない人が証明書を更新するという事態も起こりうると考えました。

 

そのため、証明書の管理の知識がなくても簡単なコマンドで証明書の更新や削除を実施できるfastlaneのmatchを導入することにしました。

 

事前に業務外で証明書の管理者側と証明書を利用する開発者側両方の導入方法についてサンプルアプリを作って試したうえで、導入方法をブログにまとめておきました。そうすることで、工数を削減しつつ、手戻りなく迅速に証明書管理の体制を整えることができました。

 

検索機能のネイティブ化

ブランド検索機能、カテゴリ検索機能、キーワード検索機能、検索結果のソート機能、検索結果の絞り込み機能、検索履歴機能を開発しました。


レコメンド商品を表示する機能がヒットしたことを受けて、「ユーザーの好みに合った商品をいつでも手軽に、かつ、すぐにチェックできる」というUXに手応えを感じていました。
そのため、「自動で」ユーザーの好みに合った商品を訴求するレコメンド機能に対して、「手動で」ユーザーの好みに合った商品を訴求する検索機能に着目しました。
当時の検索機能はWKWebViewに依存していたため、検索機能にたどり着くまでの表示速度が遅かったり、アプリ特有のUXが体感できていませんでした。
また、過去数ヶ月の検索機能経由の売上を確認したところ、緩やかに落ちており、アプリ全体の売上に占める割合も少なくなっている傾向に気付きました。
ECアプリの主要な機能である検索機能が落ち込んでいることは、同時に伸び代が非常にある状態であると感じたため、開発に着手しました。


ブランド検索機能はUISearchControllerを使用して実装しました。
インクリメンタルサーチによってユーザーが最後まで検索ワードを入力する手間を省けるよう工夫しました。


カテゴリ検索機能はUITableViewで実装しました。
ユーザーに文字を打つという手間を取らせないように、選択するだけで検索できるようにしました。


キーワード検索機能はUISearchBarで実装しました。
UISearchControllerと比較してUIのカスタマイズが柔軟にできるためUISearchBarを採用しました。
また、UISearchBarの選択時に各検索機能の一覧をUITableViewで表示させました。
UISearchBarはTOP画面に表示するため、「UISearchBarを選択すればやりたい検索方法に素早くアクセスできる」UXを実現したかったためです。


検索結果のソート機能は、ソートボタンを選択するとUICollectionViewに表示した商品一覧画面の上からソートの選択肢が半モーダルビューで表示されるような仕様にしました。
半モーダルビューはcontainerViewにUITableViewを埋め込むことでソートの選択肢を表示し、また、レイアウトの制約を付け替える+アニメーションによって表示と非表示を切り替えました。
UXの観点から、ソートボタンの位置はユーザーの指が届きやすい場所にするよう工夫しました。


検索結果の絞り込み機能のUIはソート機能とほぼ同様で、CollectionViewに表示した検索結果が表示された商品一覧の画面の上から絞り込み条件の選択肢が半モーダルビューで表示されるような仕様にしており、半モーダルビューはcontainerViewにUITableViewを埋め込むことで絞り込み条件の選択肢を表示し、また、レイアウトの制約を付け替える+アニメーションによって表示と非表示を切り替えました。
ソート機能と同様に、絞り込みボタンの位置はユーザーの指が届きやすい場所にするよう工夫しました。
また、絞り込み機能は絞り込む条件が多く、ユーザーの意図した検索ができることが魅力ですが、ユーザーの手間にならないようにUITableViewで選択肢を提示するなど、可能な限り文字を打たせる作業が発生しないよう工夫しました。
さらに、カラー選択画面は実際の色を表示して直感的に選択できるように、UITableViewのセルにカラー名だけでなく、背景にカラーを設定した円形のViewの表示するよう工夫しました。


検索履歴機能は、キーワード検索した際の入力ワードをUserDefaultsで保存しておき、保存したワードをUITableViewで表示しました。
検索履歴を選択すると、UICollectionViewで実装された検索結果画面に遷移する仕様にしました。
検索履歴機能は当初実装する予定がなかったのですが、このアプリ担当になってから何度も他社アプリの検索のしやすさに対する自社サービスの検索の使いづらさを感じていたので、開発当初から「ユーザーがいかに手軽に自分のやりたい検索ができるか」が検索機能の売上の成果に直結すると思っており、検索履歴機能は絶対に実装したいと内心思っていました。
そこで、当初は工数面で検索履歴機能までは開発できないと判断されていたのですが、検索機能の実装方法を業務外でキャッチアップすることで実装期間を短縮し、追加で検索履歴機能を開発する工数を確保した上で、社長から決裁を得て追加で実装しました。


検索機能をリリースした結果、リリース前のアプリの月平均の売上に対して、約130%の売上を安定して毎月出せるようになりました。
また、検索機能の中でも検索履歴機能が貢献する割合が大きく、自分の熱意や工夫によって追加で実装した機能が結果を出せたことはよかったと思っています。

 

レコメンド機能

ユーザーの商品の好みに合わせたおすすめ商品一覧を表示する機能を開発しました。


プッシュ機能経由での売上は好調を維持していた一方で、売上の多くを占めるTOPページにあたる画面経由での売上は停滞していたため、月あたりのアプリ全体の売上がなかなか上がらない状態に苦しんでいました。
そのため、競合他社のアプリや、InstagramをはじめとするSNS系のアプリを分析し、「自社のアプリはユーザーの好みに合った商品をいつでも手軽に、かつ、すぐにチェックできるというUXが実現できていないことが問題である」という仮説を立て、その検証のために開発に着手しました。


アプリ側では、APIから取得したレコメンド商品をStoryboardとAutoLayoutを使ったUICollectionViewで実装しました。
レコメンド商品を可能な限り多くユーザーに見せるため、UICollectionViewはページネーションに対応しました。
セルはUIのデザイン上、別の画面でも使いまわせるためXibを導入しました。
WKWebViewを多用するため「画面表示が遅いアプリ」という課題がありましたが、レコメンド商品一覧画面で表示が遅いことは致命的であることから、画像ライブラリであるNukeを導入しました。
導入後、WKWebViewを使用した画面が表示に平均数秒かかっていたのに対して、平均1秒以内に表示させることができました。


機能をリリース後、レコメンド画面経由での売上が思っていたよりも伸びなかったため、「何が各ユーザーにとっておすすめの商品と言えるのか」、「どのように画面に商品を表示すればユーザーは自分にマッチした商品だと感じるのか」という観点から仮説を立て直し、API側でおすすめ商品の抽出方法を調整したり、アプリ側でUIの調整を行うことで検証を進めました。
その結果、最終的にはアプリの月間売上全体の約25%を占めるほど機能がヒットし、売上の底上げに貢献できました。

 

Swiftのバージョンアップ対応
  • 役割：iOSアプリ開発
  • 利用技術・関連ツール：Xcode、Swift、Git、Bitbucket、SourceTree
  • 概要:

Swift3からSwift5へのバージョンアップ対応を行いました。


単純にバージョンアップ対応が遅れていたことや、開発する上でライブラリを使うことを検討したいものの、バージョンが古いと使えないものがあったため対応しました。


バージョンアップ対応を始めるまでに苦労したことは、経営陣の理解を得ることでした。
直接売上につながらない対応なので、最初は決裁を得ることができませんでした。
そこで、再度経営陣とミーティングを設定しなおし、直接売上に貢献しない対応ではあっても中長期的には売上向上に貢献できることを伝えました。
バージョンを上げれば最新のライブラリを入れることができ、それによって経営陣も認識していた画像表示の遅さなどの問題に取り組めることが伝わり、決裁を得ることができました。


バージョンアップ対応では、バージョンアップ実行時に発生する警告の解消を自動で行ったところ、自動挿入されたコードでエラーが発生する現象が発生しました。
単純に自動処理に任せるのではなく、ひとつひとつの警告を調べながら対応することで、不要なコードが自動挿入されないようにしながらバージョンアップを完了することができました。

 

iOSの証明書更新対応
  • 概要:

Apple Developerで開発用証明書やProvisioning Profile、APNs用証明書を更新しました。また、証明書更新に伴いFirebaseに設定してあるAPNs用証明書も更新しました。


iOS担当が自分1人で、かつ過去の対応ログや社内Wikiが一切残っていない状態だったため、証明書の有効期限に関して把握している人もいない状態でした。
私は入社する前に個人でアプリをApp Storeへリリースした経験があったため、担当しているアプリの証明書の有効期限に関しては注意を払っており、証明書の有効期限が切れてから対応をするという最悪の事態を回避できたのはよかったと思います。
しかし、証明書更新後にSigning Certificateのエラーが発生して対応に時間がかかってしまったり、Firebase Cloud Messagingのプッシュ送信が止まってしまう重大な障害が発生してしまいました。
慎重に調査と対応を行ったにも関わらず失敗してしまったのは、証明書の知識や、対応方法に関する知識があいまいなまま、「早く更新しないと」という焦りが勝ってしまったことが原因だったと反省しています。


障害発生時には、とにかくやりきらないといけないという気合で乗り切った側面が大きかったのですが、障害解消後、二度と失敗したくないと強く思い、証明書の知識を再度調べたり、更新方法の手順を社内Wikiに残したり、自分用にもメモとして、更新対応で失敗した原因についてブログに残したりしました。
※対象のブログ記事:【iOS】証明書を更新する時にハマった点とその解決法 - Swift・iOS


更新に失敗してしまった次の更新タイミングでは、ミスなくスムーズに対応できたため、反省を生かせたと思っています。

 

LINEログイン

アプリにおけるLINEログイン機能を新規開発しました。


当時、担当していたアプリのWeb版において、LINE経由での会員登録が飛躍的に伸びていたこと、Web版よりアプリ版の方が売上の伸び幅が大きかったことがきっかけで、Web版で会員登録したユーザーをアプリ側に流すことを目的に開発することになりました。


当初は、Web版に実装されているLINEログイン機能をWKWebViewで使用してログインできるようにするだけなので、WKWebViewのWKNavigationDelegateでLINEログインを実行できるようにLINE関連のURLの読み込みを許可するよう設定すればよいと思っていました。
しかし、Web版に実装されていたLINEログイン v2.0を実際にWKWebViewで動かしてみると、LINEログイン後のコールバック処理が正常に完了できずエラーになってしまいました。
そのため、アプリ版用にLINEログインを一から開発することになりました。


具体的には、WKWebViewに表示されたサイトでLINEログインを選択した時に、LINE SDK for iOS Swiftを使用してアクセストークンを取得してAPI側に渡し、PHPのフレームワークであるZend Frameworkが使われているAPI側でアプリ版専用のログイン処理を追加、ログインが成功したらセッションをアプリ側でKeychainAccessを使って保持することで、WKWebViewでもログイン状態を保持できるようにしました。

 

お知らせをHTMLで表示

プッシュ通知を選択すると遷移するお知らせの詳細な内容を表示する画面を、単純にテキストを表示する画面だけでなく、HTMLを表示する画面も選べるように変更しました。また、変更に伴い、非エンジニアがHTMLを登録できるマスタ画面を基幹システム側で開発し、アプリのAPI側の開発も行いました。


開発の背景としては、当時、プッシュ通知機能によってキャンペーンページなどへユーザーを誘導する導線はできてきていたものの、当時の単純なテキストしか表示できないお知らせ詳細画面では、ユーザーへの注目商品のアピールなどといった、購入にダイレクトに繋がるような訴求が難しかったためでした。


アプリ側はHTMLの表示にWKWebViewを使用しました。
過去にWKWebViewを導入した経験があるのでスムーズに開発できたと思います。
マスタ画面側は基幹システムの仕様に沿ってPHPとHTMLで実装する必要があり、API側はPHPのフレームワークであるLaravelで実装されていたため、自分の未経験分野での開発となりました。
業務時間内だけでは技術のキャッチアップが追いつかないと判断して、業務外でもPHPやLaravelに関する学習をすることで納期内に開発を完了することができました。
特にAPI側の開発は、アプリ側のリクエストをどのように受け取り、そしてどのように求めている情報をレスポンスとして返すのかを実装面から理解することができ、結果的にアプリ側のレスポンスのデコード処理に関する理解も深まったため、エンジニアとしての成長を実感することができました。


開発の成果としても、ユーザーへの商品訴求力が強まり、プッシュ通知経由での売上が飛躍的に伸び、月あたりのアプリ全体の売上が開発前と比較して約3倍に上昇させることができました。

 

プッシュ通知選択時の挙動改善
  • 担当工程：要件定義、設計、開発、テスト
  • 役割：iOSアプリ開発
  • 利用技術・関連ツール：Xcode、Swift、CocoaPods、Git、Bitbucket、SourceTree、Firebase Cloud Messaging
  • 概要:

Firebase Cloud Messagingを使って送信されたプッシュ通知を選択すると、お知らせ画面の詳細画面にダイレクトに遷移するよう改修しました。


当時、プッシュ通知を送信しても、ユーザーがなかなか内容をチェックしてくれず、プッシュ通知経由の売上が伸びていなかったため、プッシュ通知を選択すれば自動的に内容をユーザーがチェックできるようにすることで売上を改善しようとしました。


実際にプッシュ通知周りの実装を確認すると、Firebaseのライブラリのバージョンがかなり古く、当時のFirebaseのドキュメントの内容と大きく異なっていました。
このままでは正確な実装前の調査や実装が難しいと感じたため、ライブラリのバージョンアップ対応からはじめ、最新の実装に変更することで解決しました。


リリース後、プッシュ通知経由でキャンペーンページなどの特定のコンテンツへ誘導できた数を増やすことができました。

 

WKWebViewへの移行
  • 担当工程：要件定義、設計、開発、テスト
  • 役割：iOSアプリ開発
  • 利用技術・関連ツール：Xcode、Swift、Git、Bitbucket、SourceTree
  • 概要:

アプリで多用していたUIWebViewが非推奨となったため、WKWebViewへの移行を実施しました。


個人的には、「WebViewに依存するアプリ」という課題感を持ちながらも、開発メンバーが私1人かつ増員の予定がなかったので、中長期的にネイティブ移行をしていきたいと考えていました。
ただ、社長としてはネイティブ移行に時間をかけたがらず、WebViewで可能な限り作りたい機能を早くリリースしていくことを強く希望していました。
そのため、UIをUIWebView時代のような見た目にカスタマイズできたり、ログイン機能の改善で必要なセッションの引き継ぎなどに対応できるWKWebViewを採用することで、まずは社長の要望に答えることができるようにしました。


WKWebViewに移行することの決裁を社長から得るため、SFSafariViewControllerとWKWebViewを使った簡単なモックを自主的に作ることで、それぞれのメリットとデメリットを説明するだけでなく、見た目の違いを直に把握してもらうことで、開発後に認識の齟齬が起こらないようにしました。


移行した結果、非推奨のUIWebViewの撤廃やカスタマイズ可能な幅を確保できただけでなく、読み込み速度も最大で約1秒短縮することができ、社長に評価してもらうことができました。

 

---------------------------------------------------------------------------------------

その他

業務外で工夫していることに関して

開発のスピードを重視する環境のため、事前に業務外で案件に関連する技術や実装方法を調べてサンプルレベルのものを実装し、その内容をGitHubやブログに残すことでスムーズに実務での実装に入れるよう準備しています。その結果、当初の想定よりも開発工数を削減でき、また、削減した工数分他の案件も追加で開発できるため、アプリ改善のスピードを担保するために入社以来上記の取組みを続けています。

 

プロジェクトメンバーとの関わり方に関して（マネジメント面）

アプリの企画が独りよがりにならないよう、サービス側のメンバーや、デザイナーを巻き込んで企画を検討するようにしています。その際、巻き込まれたメンバーの意欲を引き出すために、メンバーの専門分野や自分が意見を欲しい部分に関しては、「自分の意見を前面に出さずにまずは素直に頼る」、「もらった意見を積極的に企画案に取り入れてみる」ことを心がけていました。また、意見を取り入れた企画で売上が改善したら、報告義務はなくてもお礼をしに他部署まで行ったり、一緒にメンバーと喜んだりすることで、メンバーが「意見を出してよかった」、「また関わってやるか」と思ってもらえるようにしていました。他メンバーを巻き込んで企画を進めていることに関しては、経営層からも「リーダーとしてチームを率いるポテンシャルがある」と評価していただいています。

 

社内での評価に関して

経営層からは、開発案件の企画からリリース後の保守対応までの段取りの良さや、他部署のメンバーを巻き込んで数字面を分析しながら改善する力を評価されています。また、部署内のマネジメント層からは、継続的に業務外で技術のキャッチアップを行ったり、自分から開発案件に関して意見を出したりする自走力と、納期内に必ずやりきってくれるという信頼があると評価されています。担当者が自分1人で当事者意識を持たざるをえない環境の中で、自主的にやりきる工夫をしてきたことが評価につながったと思っています。