ID:1068さん
2021年10月回 指名
2020年12月回 指名
3年後の目標や野望
ビジネスや組織を動かせる人間になる
いままではサービスのテックリードや、新機能の開発、チームの体制づくりまでのレイヤーしか携われておらず
影響範囲が狭いと感じておりもっと広い世界を見てみたいと思うから。
他人事ではなく自分事で、ビジネスを作ったり組織を変えたり作ったりしたい。
自身の責任の下、サービスをゼロイチで作ったり
組織のアウトプットではなく、アウトカムの責任を持って作っていきたい。
プロジェクト経験
このプロジェクト詳細は公開されていません
このプロジェクト詳細は公開されていません
このプロジェクト詳細は公開されていません
ポイントアプリリニューアル
背景
2年ほど前に一斉リジェクトをされたポイント系アプリをiOSガイドライン4.2に準拠しなおして
再リリースする必要があった。
開発期間はエンジニアリソースを割ける1ヶ月。
チーム
アプリの基本動作もわからないチームだったためそこからレクチャーを行った。
対策
チーム全体を巻き込むためデプロイ頻度をあげる。
デプロイ頻度を上げやすいようにfastlaneでコマンド一発で配布できるようにした。
fastlaneで配布したらslackに通知を送ってすぐにチームで確認できるようにしその場で議論しその場で修正し更にデプロイを行いみんなで作ってる感を出した。
1ヶ月の開発期間でガイドライン4.2に準拠させるために
フッターメニュー、レフトメニューをネイティブで実装しその他はウェブビュー。
PUSH通知をネイティブ実装で行い、端末側の通知の許可状態を監視し設定画面への誘導動線確保。
ウェブビューにはプログレスバーやプルリフレッシュ、シェアボタン等をおいて少しでもリッチにみえるように対応。
運用面
リリース後は事業部に引き継ぐ必要があるため、事業部のウェブエンジニアをアプリエンジニアにコンバートできるように
エンジニア経営層に掛け合いリソースの調整を行い運用に引き込んだ。
※前回は運用できるエンジニアがおらず保守運用されず2年以上放置されたため。
結果
無事リリースができた。
が、やはりアプリで掲載ができないコンテンツがありそのコンテンツをアプリでは削除しているため
現状はかなりユーザー評価が低くなってしまっている。
画像SNS
チーム作り
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人のメンバー管理）
- 新人エンジニアの教育
ファッションスナップ
スタート時にコンテンツが確保できないため読モを抱えてる事務所にお世話になってスナップ撮影を行った。
当日集まった女の子たちにその場で会員登録してもらい、撮影し実際に投稿してもらうなどをやってもらった。
当日不具合があったり、わかりにくいフローがあったらその場で修正してアップロードしたりしてかなりバタバタしましたが
ユーザの生の声が聞けたり度胸も付きました。
その結果、イベントでの撮影だけでなく自分でカメラを持って街に出て声をかけて撮影したり
会員登録用のチラシを配ったり積極的に動けるようになりました。
マネージメント能力
社内横断のアプリチームをマネージメントしました。
1．自分を含めた3人のチームの目標管理
2．アプリ5媒体両OSの保守運用
3．ウェブ3媒体の保守運用
4．アプリリニューアル
※2018/7〜11（現在）
1．自分を含めた3人のチームの目標設定・管理
多くの媒体を見ないといけないチームなので、横断的に運用しやすい目標
メンバーが走りやすい目標
2．アプリ5媒体両OSの保守運用
3．ウェブ3媒体の保守運用
アプリの新OS対応や、不具合対応、機能開発を滞りなく
4．アプリリニューアル
ウェブビューアプリを１ヶ月でiOSガイドライン4.2に準拠できるレベルでのリニューアル
3人しかメンバーがおらず、扱える言語も限られてるため業務が一人に集中しがちになった。
比較的更新の少ないAndroidは一旦保留にして、メンバーのiOSレベルのキャッチアップを行った。
サーバサイドに関しては、3人共できるのでドキュメント整備や無駄なフローをなくし属人化を排除した。
また、要らない業務の棚卸しなどを行い省力化を図った。
媒体をまたいでの作業を行うため頭のスイッチングコストがサービスアサイン時より多くなってしまうので
定例MTGの見直しを行い他のメンバーの定例はなくし必要な情報はすべてSlackで共有する形に働きかけた。
媒体横断での業務をするため仕事が見えにくくなるのでgithub issueとGASとSpreadsheetで
作業を見える化し自分より上の管理層にも説明がしやすい状況を作った。
また、issueには優先度や種類（バグや機能開発）などを設けているのであとからバグに多く時間が取られているなどを振り替えれる形にし
バグが多く出ていてクリエイティブな仕事ができていないのであればどこで出やすいのか等を見直し
リファクタリングなどを行える状態を作りました。
PdMの育成支援プロジェクトをマネージメントしました。
- PdMを行うために必要なスキルの設定
- そのスキルを得るためのカリキュラムの設定
- メンバーの選定・面談
- カリキュラムの運営
暫く続くプロジェクトです。
2020年4月頃〜
メンバーをプロダクトマネジメントができるようにする。
- ステークホルダーの要望をただ遂行するプロジェクトマネジメントではなく、プロダクトの成長にコミットできる
- 自分の専門領域でないチームメンバーと同じ言語で会話ができる
- 業務の優先度を正しく決定できる
- プロダクトマネジメントトライアングルを健全に機能させる
現状多くの事業担当者が、自分より役職が高いステークホルダーに業務依頼され、声の大きな人の案件から順番に対応しただの調整役になってしまっている問題が発生していた。
正しく優先度を決めるためには、各ステークホルダーが言っている内容を正しく理解し、いまなにが重要なのかを決める必要がある。
が、自分の得意でない領域に関しては役職が上の人間に言われるとそのまま進めてしまう良くない文化が形成されていた。
そのままでは、成長する機会もなく状況が変わらないので、プロダクトマネジメントトライアングルを参考にプロダクトマネジメントに必要と言われる18領域の勉強を行う仕組みを創ることにした。
上記内容をまとめ、勉強方法には読書を選び、カリキュラムを作成した。
社内でプロダクトに責任を持っているメンバーを選定し勉強会を開催した。
当初はおすすめ書籍を元に、自身がいま感じている課題を解決できそうな領域を好きに選んでもらい、自身のペースで進めてもらうことにしたが、領域に偏りが出たり、進捗に偏りが出てしまった。
そこで、読書を行った領域に関してはチェックを付けてもらいレーダーチャートを埋めていく方式に転換し年内にレーダーチャートを埋める目標を設定した。
また、進捗に問題がある件に関しては自身で決めたペースを作ってもらいいつまでにどうするといった目標を設定し毎週成果を発表してもらうことで解決した。
約半年間を進める中で6名のメンバーがこのカリキュラムを実施し2名が各領域の知識を一通りインプットを行い次のステップに進んでもらうことになった。
このプロジェクトの振り返りでは以下のようなKPTがあがった。
Keep
- 自分では選ばない領域の本を読めた
- 社内での横のつながりが作れた
Problem
- バラバラに読むので知らない領域の本を読んで内容発表されても分からない
- もっと濃い目の議論がしたい
- 本を用意するのが手間
- 実業務に活かしきれない部分がある
- 本慣れしてない状態で、1冊目に重い本を読むと心が折れる
- ペースがまちまちになって、なかなか領域を埋められない
Try
- 指定図書の設定
- 読書の順番を指定
- 半年の期間を決めて、達成出来ない場合は時期見直し
上記振り返りを経て2021年は更に追加で4名のメンバー追加、達成した2名は実際のプロダクトマネジメントで行った課題設定と解決をメンバー同士で共有しより実践的なプロダクトマネジメントを学んでもらうカリキュラムを行う予定。
PdMの育成支援プロジェクトをマネージメントしました。
- PdMを行うために必要なスキルの設定
- そのスキルを得るためのカリキュラムの設定
- メンバーの選定・面談
- カリキュラムの運営
以前からやってる活動のセカンドシーズンです。
2021年1月頃〜
ファーストシーズンで出た課題を解決し、より濃いインプットができる環境を作る
やったこと
ファーストシーズンで出た課題をもとに第一期で一緒に勉強してきたメンバーに本の選定を相談しつつ
半年で読み切れる量になるように書籍の選定を行った。
約8人の参加者が居たので、曜日を分けてクラス化して議論がより活発化するようにした。
課題１
自分ともうひとりの運営メンバーがファシリテートを行っていたので、このままだとどちらかが退職した場合に終わってしまう。
上記課題を解決するために2021年7月〜は第二期の卒業生たちに協力をお願いして読書会のファシリテートを引き継ぎをお願いした。
この際にやり方を引き継ぐのではなく、プロダクトマネジメントを行う上で必要な知識の土台を作る目的を改めて伝えて
好きにやり方を変えていい旨を伝えて引き継いだ。
結果的に、読書会はそのままで各書籍で社内の有識者をゲストとして招いてディスカッションする形になった。
やりづらくなるとダメなので、自分自身は会には参加せず、定期的にヒアリングをして問を立ててメンバー自信で改善出来るように心がけた。
課題２
座学を学ぶばかりで、アウトプットにまだ繋がっていない。
上記課題を解決するために、基礎的な座学を学ぶベーシック、学んだ知識を活かすアドバンスとコースを分けて開催することにした。
ベーシックの方は、上述した形で他のメンバーにファシリテートを任せた。
アドバンスでは各参加者のミッションをヒアリングし、どういった方針でそれを達成するのかを参加者同士で共有し、質問し合うことで理解を深めたり、思い込みを取り払ったりした。
この結果、今まで思い込みで効果があると思い追っていた指標にデータ的根拠が実はなく前任者からそのまま引き継いでいた指標に気づき新たに取るべき指標をチームで振り返りきっかけになったり、各メンバーの自身のキャリアを考え視座が上がることにつながった。
アピール項目
アウトプット
今後、身につけなければいけないと思っている技術は何ですか？
- Androidアプリ
- awsやgcpのようなクラウドサービス
上記を身につければどんな体制のチームでもフォローに入ったり同じ言葉で会話できるので
チームマネジメントを行いやすいし、チームのパフォーマンスを最大化できると考えているので。
あなたが一番パフォーマンスを出せるのはどんな環境ですか？
- エンジニア、デザイナー、ディレクターそれぞれが意見をぶつけ合いサービスを良くしようとする意思があるチーム
- 自分に求めていることを明確にし、任せてくれる環境
- アンテナが高く新しい技術や手法などを実務に落とし込めるレベルで取り入れたり、取り入れることに寛容なチーム