Discover companies you will love
スパイダープラス株式会社 / プロダクト開発部プラットフォーム部MobileチームEM
▼根幹 私は、高校生の時から29歳まで格闘技をやっていました。 25歳の時に新人王を取得し、その後はプロとして、活動しておりました。 10年以上格闘技を続けてこれたのは、そこで出会った仲間たちのおかげだと思っています。
ユーザーへ最速で最大価値を提供するための環境を整える
/assets/images/5766078/original/27f6a23a-ab92-4bc4-bd52-612fc6f503b7?1605088114){kind=avatar}
組織横断のモバイルチームにおけるエンジニアリングマネージャーとして、2~8名のチームをリード。 「ユーザーに最速で最大価値を届けるための環境づくり」をミッションに、技術負債返却、開発文化の醸成、技術スタック設計、アジャイル開発支援など、技術と組織の両面からモバイル開発の土台強化を推進。
▼ 技術面での成長支援 ペアプログラミングを実施し、実装手法を口頭と実装で見せながら、リアルタイムでフィードバックを行うことで知識共有を促進。この取り組みにより、メンバーの技術的な自信が向上し、コードレビューでの指摘事項が減少。Swift/SwiftUIの新機能導入/リファクタリングにも積極的に取り組めるようになった。 ▼ キャリア面での支援 メンバーに「なりたい自分」を常に意識させ、そのために何が必要かを逆算するように1on1（週1回・1時間）で共有。日々の業務の中でも小さなフィードバックを期待値とともに伝えることで成長を促した。この結果、メンバー全員が自身のキャリアパスを明確化し、技術ブログの定期執筆/外部へイベントへの登壇/率先して声をかけてペアプロやコードレビューを行うなどの成長が見られた。
スマートフォンアプリケーションの「TELLER（テラー）」のiOSとAndroidの開発
▼内容 自社で運用予定のiOSアプリ（雛形は存在している）を完成させ、収益をあげる ▼成果 売上 ¥250万/月（最高値） ASO 特定ワードで1位 ▼対応 以前在籍していたエンジニアが作成途中のiOSアプリにて修正と補填をし、リリースした。 その後、効果測定ツール「Adjust」と「Repro」を導入。 「Adjust」では、流入元による効果計測。 「Repro」では、アプリ内でのユーザーの行動の効果計測と、 プッシュ通知による再訪（リテンション）と、アプリ内メッセージによる行動促進を目的に使用。 「Adjust」の計測を基に、効果のいい広告の出し先を選定し、出向依頼。 アプリの成果最大化のためにKPIツリーを作成し、ノードのKPIをあげるための施策を提案し、 自ら実装して、「Repro」にて効果の計測を行う。 ▼担当範囲 ・施策の企画 ・デザイナーとのUX提案/依頼 ・機能の実装 ・効果測定 ・広告の出し先の選定 ▼実装機能 ●アプリ ・WEBページ表示 ・為替情報を使用したチャート表示 ・為替の売買をデモで行う機能 ・プッシュ通知 ・RESTAPI連携 ・Repro連携 ・Adjust連携 ・強制アップデート機能 ●サーバー ・API作成 ・アプリ内表示用記事作成 ・アフェリエイト案件登録用管理画面 ●計測 ・Slackへの計測内容通知機能 ▼使用技術 ●アプリ 「Swift」にて実装 ライブラリ管理は「CocoaPods」 バージョン管理は「GitHub」 API通信は「Alamofire」 チャート表示は「ios-Charts」 基の設計が「MVC」だったため、それを踏襲 ●サーバー 「PHP」で実装 アプリ内表示用記事作成には、WordPressを使用 ●計測 社内コミュニケーションツールが「Slack」だったため、前日の計測内容を通知する「PHP」を作成 ┗Cronによる定期実行 ▼アプリ内表示用記事作成について アプリ内に載せる記事作成には「WordPress」を使用しました。 記事を作成するのは、エンジニアではなくライターであり、文字装飾や画像の配置など編集を自身でできるようにしたかったため、「WordPress」を選定しました。 ▼売上をあげるために 売上になる部分がアフェリエイトという、出口が1つでしたのでどうしたらそこまで導けるかを、まず測定していました。 測定には「Repro」のアクセス分析が役立ちました。 アクセス分析により、「何を行ったユーザーが売上に繋がっているか」を把握し、 そこに導くために、アプリ内メッセージやプッシュ通知を送っていました。 （例：売上が多いのは、学習コンテンツを読んだユーザーだとすれば、いかに学習コンテンツを読ませるかを施策する） そもそもアプリを起動してもらえない（長く使用してもらわない）と始まらないため、リテンション率をあげる事にも注力しておりました。 その際には「Repro」のアクセス分析だけでなくファネル分析も役立ちました。 アクセス分析で継続率の高いユーザーの行動を把握し、ファネル分析で離脱ポイントを見つけ、いかに離脱をさせないか、コンテンツの充実やそのタイミングでInAppを出すなどを行い、離脱を防ぎました。 （例：デモトレードを5回以上連続でプレイしたユーザーの方が、 デモトレードを2回しかプレイしなかったユーザーより、CV率がよかった 仮説：デモトレードを複数回かつ、連続でプレイさせることが、CVに繋がる 施策①：デモトレードを連続でプレイさせるために、プレイ後の勝敗画面を変更 施策②：起動後にすぐにプレイさせるために、起動時にInnAppにて、URLスキーム実装） ▼売上をあげるために2 売上の向上のために、1人では出来ない部分が多々ありました。 アプリアイコンや、ストアキャプチャ、ストア文言、アプリ全体の世界観etc... 施策の企画にしてもそうですが、1人よりも大勢の方がアイデアを出せるものだと思っています。 そう言った際には、周りの助力を得て、様々なアイデアを出し合い、膨らませるだけ膨らませ、 その中から、選定していく方法を取っていました。 アイデアには、真面目なものから馬鹿げたものまで存在し、選定するのに苦労しましたが、すごく有意義なものだったと思います。 そのアイデア出しがあったから、様々な施策を試すことができ、売上をあげることができたのだと思います。 ●選定基準 ・開発工数とインパクトの概算を算出し、工数は少ない、もしくは影響の大きいものから優先度をつけて 選定 ●アイデア抜粋 ・プッシュに画像をつける ・学習コンテンツを漫画にする ・期間中に〇〇したユーザーに欲しい本プレゼント ・動画配信 ●施策抜粋 ・プッシュの配信時間 ・プッシュの配信数 ・為替の売買をデモで行う時のゲームレベリング ・チャット機能 ・ランキング ▼ASO向上 アプリをダウンロードしてもらうためには、ユーザーに見てもらわないと始まらないため、ASOにも力を入れました。 主に行ったことは、高評価レビューを書いてもらうことです。 様々な施策を行いましたが、1番効果がよかったものは、「レビューを書いたら〇〇が解放」といったユーザーにインセンティブがあるものでした。 ▼心残り 「多少バグがあったとしても、とにかく早くリリース」というのが会社の方針でした。 作成したプログラムには拡張性や保守性はなく、機能を追加する度に、ツギハギをしている気分だったのが、すごく心残りです。 ▼総括 全てが未経験だったにも関わらず、そして、先輩エンジニアがいるわけでも、 教えてくれる方がいない中での、全てを手探りなトライ＆エラーでしたが、 周りの方も付き合ってくれて、協力があったからこそ、結果も伴うことが出来たんだと思います。 このプロジェクトのおかげで、ビジネススキルも磨かれたましたし、いいアイデアを出す場の作り方（ケースバイケースですが）も学べました。 難しい技術は一切使用せずとも、これだけの成果を出せると知れたのもいい経験になりました。 惜しむものは別事項でも書きましたが、「作成したプログラムには拡張性や保守性はなく、機能を追加する度に、ツギハギなっていること」が、残念です。
▼依頼 既存サイト内でDBのデータを表示ができないから、早期で直して欲しい ▼調査 Rubyで構築されたAPIサーバーに、Rubyを使用するために必要な環境が揃っていないことと、 Rubyコードが破損していたことが判明 (pumaが入っておらず、RubyのコードではDBデータからAPI作成を行う部分が抜けていた) ▼調査方法 Route53からドメインが正しく設定されているか確認 → 問題なし ロードバランサーからのヘルスチェックがエラー → EC2側と判断 EC2は起動されている → 内部設定と判断 コマンドで環境が構築されているか実行 → pumaが入っていないことが判明 RubyファイルのAPI作成部分が存在していなかった → 復旧後の調査でDBデータを取得する部分は見つけられたが、 それを整形している部分が見当たらなかった ▼原因 元々作成した者がいなくなっており、その後引き継いだ者がおらず、 エンジニアでないクライアント本人が、EC2のサーバーを削除/再構築し、 前任者がGithubに残していた古いバージョンのRubyコードをサーバーにあげていたことにより発生 ▼対応 クライアントから早期復旧が最重要事項だったため、慣れているPHPへ言語の変更することで、 サイトの復旧(プログラム作成時間)まで4時間で対応 ▼担当範囲 クライアントへのヒヤリングを行い、状態の把握を行う。 クライアント自身で、削除/再構築を行ったことが判明したため、おおよその見当をつけた。 また、AWSアカウント（IAM）の作成方法のドキュメントを作成し、クライアントへ依頼。 ヒヤリング後、上記調査方法を行い、原因を究明。 新規EC2へLAMP環境の構築を行い、RDS連携,API出力を行い、サイトを復旧。 ▼修正内容 ●環境 ・AWSEC2の構築 ┣Linax ┣Apach ┣MySQL ┗PHP ・各種AWS設定 ┣ELBとEC2の繋ぎこみ ┗セキュリティグループ設定 ●機能 ・DB接続/データ取得 ・データの整形/出力 ▼使用技術 フローが、「DB接続→データ取得→整形→出力」と単純なものだったため、PHPのみで実装。 DBデータが大容量だったため、SELECT文のJOIN方法やDBのインデックスを意識した。 ▼なぜPHP? 本来ならばRubyで復旧すべき事柄だが、私がRubyをやったことがなく、 今回の依頼が早期復旧が最重要事項だったため、調べながら復旧していくRubyよりも早くできるため、 PHPを選択しました。 ▼総括 クライアントとのやりとりをする上で、非エンジニアにいかに、理解してもらうか説明するかがすごく苦労したプロジェクトでした。 極力専門用語を使用せず、噛み砕き、必要な資料を用意することに注力しました。 また、速度重視のプロジェクトであったため、技術的に拘りたいところもあったが、目を瞑るところには目を瞑り、折り合いをつけた提案と開発を行うことができた。
スパイダープラス株式会社 / プロダクト開発部プラットフォーム部MobileチームEM
▼ 技術面での成長支援 ペアプログラミングを実施し、実装手法を口頭と実装で見せながら、リアルタイムでフィードバックを行うことで知識共有を促進。この取り組みにより、メンバーの技術的な自信が向上し、コードレビューでの指摘事項が減少。Swift/SwiftUIの新機能導入/リファクタリングにも積極的に取り組めるようになった。 ▼ キャリア面での支援 メンバーに「なりたい自分」を常に意識させ、そのために何が必要かを逆算するように1on1（週1回・1時間）で共有。日々の業務の中でも小さなフィードバックを期待値とともに伝えることで成長を促した。この結果、メンバー全員が自身のキャリアパスを明確化し、技術ブログの定期執筆/外部へイベントへの登壇/率先して声をかけてペアプロやコードレビューを行うなどの成長が見られた。
