ID:1068さん

# 背景 2年ほど前に一斉リジェクトをされたポイント系アプリをiOSガイドライン4.2に準拠しなおして 再リリースする必要があった。 開発期間はエンジニアリソースを割ける1ヶ月。 # チーム アプリの基本動作もわからないチームだったためそこからレクチャーを行った。 # 対策 チーム全体を巻き込むためデプロイ頻度をあげる。 デプロイ頻度を上げやすいようにfastlaneでコマンド一発で配布できるようにした。 fastlaneで配布したらslackに通知を送ってすぐにチームで確認できるようにしその場で議論しその場で修正し更にデプロイを行いみんなで作ってる感を出した。 1ヶ月の開発期間でガイドライン4.2に準拠させるために フッターメニュー、レフトメニューをネイティブで実装しその他はウェブビュー。 PUSH通知をネイティブ実装で行い、端末側の通知の許可状態を監視し設定画面への誘導動線確保。 ウェブビューにはプログレスバーやプルリフレッシュ、シェアボタン等をおいて少しでもリッチにみえるように対応。 # 運用面 リリース後は事業部に引き継ぐ必要があるため、事業部のウェブエンジニアをアプリエンジニアにコンバートできるように エンジニア経営層に掛け合いリソースの調整を行い運用に引き込んだ。 ※前回は運用できるエンジニアがおらず保守運用されず2年以上放置されたため。 # 結果 無事リリースができた。 が、やはりアプリで掲載ができないコンテンツがありそのコンテンツをアプリでは削除しているため 現状はかなりユーザー評価が低くなってしまっている。

# チーム作り KPIに対して施策を行うが、見込みが足りてないにも関わらず施策が出せず全然目標達成できないチームでした。 が、キープMTGを導入して足りないなら施策を考えたりチューニングしたりきっちり目標を追うように自分が動きチームに働きかけてキャッチアップできるチームを作った。 動くようにしてからはチューニングを含めて10倍ほどの施策は行えるチームになった。 # アプリエンジニアのジョブローテ エンジニア4人体制でサーバサイド、アプリの運用をしていたのですが アプリができるエンジニアに偏りがあり業務分担があまりできていませんでした。 特にAndroidは一人しか書けなかったため、差し込み案件が発生すると作業が中断してしまい フォローにも入れないといった状況になっていました。 そこで、上司に状況説明と改善案を提案し iOSエンジニア→Android PHPエンジニア→iOS へ、ジョブローテができるように働きかけました。 そのなか、私はPHP,iOSが書けるため、PHP→iOSアプリへのコンバートの手伝いをしました。 PHPからアプリへのコンバートでは、スレッドやデリゲートの概念がないためとっつきにくいため まずは苦手意識が出ないようにそのあたりが出ない、画面表示系のタスクから行い なれてきたタイミングでペアプロを行い進めていきました。 また、Obj-cで書かれているページをSwift化することで復習する機会も用意しました。 それにより無事ウェブエンジニアをアプリエンジニアへとコンバートさせ チームのリソースをフレキシブルに動けるようにしました。 # TwitterSDKの導入 古くから運用されていたり、アプリとウェブでエンジニアが分断されて運用されいたせいで SDKが利用されずウェブビューでツイッターログインが動いていました。 このせいでTwitterアプリでTwitterにログインしているにもかかわらず ウェブで再度ログインが必要になっていました。 チーム内では当たり前になっていましたがこれではSNSログインのメリットが全然享受できていないので アプリとウェブに改修を行いTwitterSDKの実装を行いました。 これによりTwitterログインの利用が倍ほどになりました。 # 広告ライブラリ共通化 - 2012年から動いている - Obj-CとSwiftが混在 - 広告SDKが数年前から更新されていない - 広告の初期化処理がいろいろな箇所点在 - 使われてないコードが残ったまま 以上のような状況で、運用しており全然クリエイティブでない広告SDKの導入や アップデートに時間を取られたり、広告SDK起因のクラッシュがよく出ていた。 - SDKの棚卸し、要らないSDKとコードの削除 - SDKのCocoapodsでの管理への移行 - 広告呼び出し部分の一元化 - 広告の先読み 以上を行い、SDK導入や更新時間を短くし本来やるべき業務への時間確保や CFRの向上、収益の向上ができました。 # メモリリークによるクラッシュの改善 再現性のないクラッシュの問い合わせがユーザからよくきていたので よく使われる画面のソースコードの読み込みを行いメモリリークの改善を行った。 ほとんどデリゲートの循環参照やblocksの中での強参照が原因だったので プロジェクト内でデリゲートを宣言をすべて検索し適切に変更したり blocksの記述を追って一通り変更しました。 これによりほぼ毎日着ていた原因不明のクラッシュの問い合わせは届かなくなりました。

# 業務内容 - DB設計、開発 - API設計、開発 - WEB設計、開発 - iPhoneアプリ設計、開発 - SEO 主なトピックは以下のとおりです。 # コーディネートまとめ記事 当時、キュレーションサービスが流行っておりSEOなので集客効果が話題になっていましたが コンテンツの著作権などグレーな部分な多く問題になっていました。 そこで、自社サービスのコーディネート画像を自社サービス内で記事を作れる仕組みを作りました。 これにより、記事の外部提供が行え新しいチャネルの獲得に繋がり LINEアカウントメディアにも配信をスタートし友達100万人を超える規模まで成長しました。 また、ユーザにも掲載されることで承認欲求を満たせたり提携先のECサイトへの動線の確保など 様々なメリットを産めるコンテンツになりました。 # 提携ECサイトの商品を横断検索できるWEBページ もともと商品データはクロールしてDBに格納されていたがそれを掲載するページがなかった。 無茶な営業が1週間で静的HTML納品のデザインにシステムを当てろといってきたので大急ぎでRoRで作成しました。 静的ページしか納品されなかったので初日は一通り目を通し必要なページのURLの洗い出し 必要となるメタデータのリストアップ、足りないページの依頼タスクを出して早め早めに不確定要素を確定しながら 順次ページを作成していき、一つ一つのページの作り込みに時間を掛けすぎず一通りページを作成しました。 それによって十分に考慮できていなかったページなどを早めに察知し早めに対応することでなんとか一週間で乗り切れました。 # Obj-CからSwiftへの移行作業 2013年から動いているアプリだったのでObj-cで書かれておりレガシーなコードも多く技術的な負債が溜まっていた。 ただ、サービス成長のために開発を長期間ストップすることはできないのでできるだけストップせずに動けるよう 基盤となるAPIやMODEL周りはObj-Cのまま残してコントローラなど比較的変更の多い箇所をSwift化していきました。 それにより通常の開発と並行して進め3ヶ月の開発期間で実施することができました。 ▼検索結果ページの最適化（SEO対策） コーディネートの検索結果ページをGoogleに送っているのですが「赤 カーディガン」や「カーディガン 赤」などのような文字の順番が違うせいで検索結果ページが同じ検索結果にもかかわらず2ページ存在することになり Googleに重複コンテンツとして扱われていました。 そこで、よく検索される色、アイテムの情報を辞書として管理し検索ワードをMecabで分割し 検索キーワードを正規化することで重複コンテンツの減少を図りました。 また、他にもカーディガンをカーデと略したりMA-1をMA1と書いたりするような文字のゆらぎにも対応し SEO対策だけでなく、ユーザにもカーデ、カーディガン両方で検索しても同じ検索結果を出すことができるようになりました。

#業務内容 - WEBサーバ構築、WEBサーバアプリケーション構築・保守 - サービス運営、サービス設計 - ディレクション業務（4人のメンバー管理） - 新人エンジニアの教育 # ファッションスナップ スタート時にコンテンツが確保できないため読モを抱えてる事務所にお世話になってスナップ撮影を行った。 当日集まった女の子たちにその場で会員登録してもらい、撮影し実際に投稿してもらうなどをやってもらった。 当日不具合があったり、わかりにくいフローがあったらその場で修正してアップロードしたりしてかなりバタバタしましたが ユーザの生の声が聞けたり度胸も付きました。 その結果、イベントでの撮影だけでなく自分でカメラを持って街に出て声をかけて撮影したり 会員登録用のチラシを配ったり積極的に動けるようになりました。