ID:1068さん

## プロジェクト概要 小説投稿サービスにEMとして参画し、その後PdM、事業責任者へと役割を広げながら、開発組織の構築、プロダクトのグロース、事業運営まで一貫して担当しました。 参画当初は新卒エンジニア1名が中心となって開発している状態だったため、EMとして技術面・開発推進をフォローしました。その後、事業成長に合わせてエンジニアを増員する際には、開発をリードしながら新たなメンバーが開発に参加できる体制を構築しました。 ## PdMとしての取り組み 開発体制の拡大後はPdMも担当し、プロダクトのKPI設計や施策立案にも責任範囲を広げました。 サービスは無料で利用できる広告メディアモデルであり、ユーザーあたりのLTVが低く、有料マーケティングに大きなコストをかけにくい事業構造でした。一方で、検索経由の流入はすでに一定規模あり、関連キーワードの掲載順位には改善余地があったことから、SEOを主要なグロース施策の一つとして位置づけました。 Search Consoleなどのデータをもとに検索ニーズや掲載順位を分析し、改善施策を継続的に推進。その結果、対象キーワード群の平均掲載順位を4位台から2位前半まで改善し、検索流入を約2倍に拡大しました。 また、当初はディレクターが施策や仕様を考え、デザイナーがデザインし、エンジニアが実装する受発注型の開発体制となっていました。その結果、エンジニアやデザイナーが「依頼されたものを作る」ことに留まり、ユーザー課題や施策の背景を踏まえて、より良い解決策を検討する機会が少ないことを課題と捉えました。 そこで、職種を問わず課題や背景を共有して議論し、エンジニア・デザイナー自身が解決策の提案から検証まで担える体制へ変更しました。 この体制の中で、デザイナー2名がシニアへ昇格し、うち1名はその後マネージャーへ、エンジニア1名はシニアを経てスペシャリスト職へ進みました。 ## 事業責任者としての取り組み その後、事業責任者に就任し、最大13名規模のチームを管掌。プロダクト開発に加えて、事業計画・予算策定・損益管理、採用・評価・育成まで担当しました。 ユーザーインタビューから利用者層に関する課題を特定して翌年度の事業方針を策定するなど、プロダクトだけでなく事業全体の意思決定を担いました。 最終的には事業の継続性を評価し、役員へ撤退方針を提案。縮小後もサービスを継続できるよう、ClaudeCodeのスキル等で半自動化体制を構築中。

# 概要 個人開発で作っていた読書ノートのアプリに読書から得られる学びを効率的にするため、本の引用した部分をChatGPTで別の利用シーンを考えたり、更に理解を深めるための問いを出すようにした。 # 目的 社内プロダクトでAI活用を推進する際に肌感覚を掴むためまずは簡単に実装したかった。 # 構成 元々のFlutterで書かれた CloudFunctionのHttpトリガーでPythonでAPIをOpenAIを叩くように作りました。 Pythonを選んだのは機械学習やAIはPythonのイメージがあったのでライブラリも豊富そうだったので選択しました。 が、CloudFunctionのエミュレーターが動かないしOpenAIのライブラリはTypeScriptでもあったのでTypeScriptでよかったと今では思います。 # 気をつけた点 ## APIコール数 元々、クライアントはFlutterｘFirebaseで作っていたのでFirebaseAuthを利用していたので、APIコールはFirebaseAuthでの認証を必須にし ## APIキーなどの秘匿 ソースコード上にキーを埋め込まずに、SecretManagerを使ってAPIキーを環境変数化して利用。 # 得られた効果 このアプリ自体は公開はされていますが、自分以外使っていないのでなんの効果もありません。 ただ、実際に自分で作ったことがあるので自身のチームメンバーへの説得力や勘所には役立ちました。 実際に自身のプロダクトにはChatGPTの活用事例が作られ、メンバーの自己研鑽に発破を掛けられました。

# 背景 なにかイチからサービス設計をしたくて、新しくFlutter言語を学びたかったので作ってみました。 # サービス原案 妻になにか困ってることはないかと尋ねたところ、結婚して家族が増え、家族の子供が生まれ誕生日を覚えきれないとの課題をもらった。 # ビジョン 大切な人との大切な日をより良いものにする。 # アプリの公開リンク https://giftreminder.page.link/store # 設計思想 将来的には誕生日を管理した上で、その相手が欲しかったものや過去にあげたものもらったもの、同年代の人が欲しいプレゼントを見つけられるアプリにしたかったが、ネットワーク効果が必要だったり、記事コンテンツ作成にはコストが掛かるためまずはツールとしての完成度を高め、誕生日管理ツールとして一人でも使い続けられるアプリを作る。 # システムアーキテクチャ ## Flutter ### 選定理由 1. 社内のアプリエンジニアリソース不足 2. 個人開発のためリソース不足 ## Firestore、Firebase ### 選定理由 新たな言語を扱う際は、慣れ親しんだ言語選定を行うので。 # こだわったポイント 妻からヒアリングし、アイデアが膨らみ過ぎる部分で本質的な課題の抽出からのMVP設計。 # 現状の課題と対策 - 継続率 - 翌月継続率が45%。目標とする数値は翌月継続50% - 目的が明確なアプリにも関わらず、初日の誕生日の登録が80%しかないので95%程度までは上げる - 誕生日だけでなく、結婚記念日や付き合った日などの記念日も管理し接触頻度を増やす

# 業務内容 自分で開発したTODOアプリ「ママスケ」のレビューが低かったので★4にした。 https://apps.apple.com/jp/app/id1322323262 # やった内容 - アプリ上の体験で、アプリに馴染んだであろうタイミングでのレビュー依頼API実装 - 上記対応で増えたレビューへのすべて返信・修正、カイゼン対応 - Twitter上で頂いた要望のアプリへの反映　https://twitter.com/mama_sche 以上の対応でレビュー数は90件を超え、評価は★4になりました。

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