リテールアプリ共創部 - モバイルアプリ開発テックリードの働き方のご紹介

リテールアプリ共創部 - モバイルアプリ開発テックリードの働き方のご紹介

Clock Icon2025.02.04

こんにちは。リテールアプリ共創部のきんくまです。

この記事では、リテールアプリ共創部のモバイルアプリ開発(iOS/Androidのアプリ開発)でテックリードをしている私の働き方をご紹介します。

(この記事は昨年10月に弊社の会社説明会で発表した内容をもとに情報を加筆したものです)

自己紹介

最初に自己紹介をします。
以前はWebフロントエンド系の開発をしていました。
その後クラスメソッドにiOSエンジニアとして入社して、一番最初にこれからご紹介する案件を引き継ぎました。
そこからプロジェクトが大きくなり開発メンバーも増えて、途中でテックリードとなりました。

会社説明会20241009_3

リーテルアプリ共創部とは

つぎに私の所属するリーテルアプリ共創部についてです。
紹介ブログが公開されていますので、ぜひご覧ください。

https://dev.classmethod.jp/articles/retailapp20241001/

担当しているアプリと案件のご紹介

アプリ概要

  • 衣料と雑貨のECを扱うネイティブモバイルアプリ
  • アプリとWebがある
  • ネイティブモバイルアプリ
    • iOS: App Store
    • Android: Google Playで配信
  • 会員数900万人超
  • EC売上高 年間480億円超
  • うちアプリ経由は約100億円
  • 開発言語
    • iOS: Swift、Android: Kotlin
  • 使用サービス: FCM, Crashlytics, App Distribution, KARTE
  • クリーンアーキテクチャ
  • 昨年1年半ほどかけた大規模な改修を行った
    • ただし裏側なのでユーザーは気がつかない内容

私がプロジェクトに入った6年前から、どんどんアプリが成長していき、ユーザー数や売り上げが伸びていった感じです。
お客様の中でもアプリがとても重要な存在となっております。

開発チーム

会社説明会20241009_1

現在のチームメンバーは全部で10名です(上の図は昨年10月の会社説明会のときのもので、そこから1名さらに増えています)

6年前は、プロマネ+iOS+Android+デザイナーの4名体制だったので、ずいぶん大きくなりました

打ち合わせなど

  • 朝会(毎日30分〜1時間程度。全員参加)
    • チェックイン(5分雑談。毎日1人ずつ順番に担当。業務に関係ないことを話してもらう)
    • 前の日に決まったこと、チーム内でやりとりしたことの振り返り
    • 開発スケジュールの共有(軽い進捗確認)
    • 相談して決めることも行う
  • 社内定例(毎週1時間程度。全員参加)
    • 先週やったことをそれぞれ振り返り
    • 時間がかかる相談ごとも行う
  • 3社定例(毎週1時間程度。社員が参加)
    • クライアント、EC側ベンダー、アプリ側ベンダーの弊社が参加
    • 3社で相談や共有することを議題にする

この中では毎日行っている「朝会」を大事にしています。
開発内容についてメンバーに共有したり、チーム内でいろいろと相談をします。
また毎日5分のチェックインがあります。1日1人で当番が順番に回ってきます。最近行った場所、遊んだゲーム、見た映画、買ったもの、とりとめもない話など、業務に関係ない話題をしてもらいます。これで、その人がどんな人なのかを少しずつ知ることができて、メンバー間の親しみやすさにつながっていると思います。

そのほか

  • 残業は毎日平均1時間弱くらい(自分の場合)
    • ときどき忙しいときはあるが、ふだんはそれほどでもない
  • 土日祝日は休み

基本的に勤怠はスケジュール通りです。要件が重なってとても忙しくなるときもありますが、ふだんは平常運転です。

テックリードの仕事のご紹介

ここからは、テックリードの具体的な仕事内容をご紹介します。

テックリードの仕事(概要)

  1. 技術調査(メイン)
  2. 仕様書作成と調整(メイン)
  3. 保守対応(発生ベース)
  4. 開発メンバーからの技術や仕様の相談対応(毎日よくある)
  5. 開発メンバーとの1on1(週1で1人ずつ)
  6. 社内テスト実施

自分の役割的に大事なのは1と2です。
上記内容のそれぞれについては次の項目から詳しく説明します。
それから、ソースコードを書くということについては以下になります。

  • プロジェクトのソースコードは書かない
    • 開発メンバーが書く
    • 実装サンプルは自分が書くこともある
  • Pull RequestのコードレビューはOSごとのリーダーにお任せしている

私はもともとiOSのエンジニアでプロジェクトに参加しましたが、現在はリポジトリにコミットされるソースコードは書いていません。ただし実装のサンプル用のコードを書いたりすることはあります。
また、プルリクのレビューもOSごとのリーダにお任せしていますので、私がやることはありません。(たまにある)

1. 技術調査

  • これから開発する要件を、先行して技術調査を行う
  • 実際に自分で手を動かしてそれがどんなものかを探る
  • 仕様書を書く上でも必要
    • 何ができて、何ができないのか
    • どのくらい実装期間がかかりそうか肌感覚を知る
  • 開発メンバーにつまりそうなポイントと、実装ポイントを伝える
  • これにより開発がスムーズに進む
  • クライアントがSaaSを使った新しい機能をWeb側に先行して取り入れることがよくある
  • アプリはその後に実装することが多い
  • SaaSはWeb側は対応しているが、アプリ向けに対応してないことがほとんど(つまりアプリ向けは新規)
  • そのため、どのように実装するか調査し、検討する
  • ときにはSaaS提供会社と打ち合わせをして、アプリ向けにどう作るかの相談も受ける

開発要件で必要な技術調査を先行して行います。
APIを叩いたり、Web版で行っているものをどうやってアプリに取り入れるか考えます。
またSaaSの提供会社様と打ち合わせをして、アプリ向けの開発の相談をうけたり、一緒に仕様を検討します。

自分ができること、できないこと

  • 自分ができること
    • iOSの開発
    • Webフロントエンドの開発
  • 自分ができないこと
    • Androidの開発(簡単な調査は可能。実践は難しい)
    • できないことはAndroidのメンバーに相談する
    • いろいろ確認してもらったり、話を聞く

iOSとWebの開発はできるのですが、Android開発はできないので、調査や仕様をどうするか検討するときはAndroidメンバーに相談しています。

2. 仕様書作成と調整

  • 要点を抑えて仕様書を作成する

    • 実装内容をしっかりイメージして作る
    • 違う人が見ても同じものを作れるように(OSがiOSとAndroidで2つあるので大切)
    • 作成する中で出た不明点や矛盾点などを書き出しておく
    • 細かいAPIリクエストパラメータも自分で実際に動かしてチェックして作る
  • 実装開始前に、仕様書をクライアントとしっかり読み合わせする

    • 今回の要件の範囲
    • UIの見せ方
    • 仕様書作成時にわかった疑問点
    • 細かい内容までクライアントと合意をとる
    • 仕様を調整したり、要件を調整したり(別フェーズに分けたり)

仕様書作成は、誰がみても同じものを作れるようにすることを心がけてます。(これは書かなくてもわかるだろう?ではなく、面倒くさがらずにきちんと書く。なるべく省略しない。わかりやすく簡潔に書く)

それから、社内で仕様書を読み合わせして細かい疑問点などをまとめてから、クライアントとも読み合わせを行います。開発が進んで、チーム内やお客様などプロジェクトに関わる人が「そう思ってなかった」などということがないように、きちんと説明をして合意をとります。一見合意が難しい場合もたまにありますが、資料をしっかりとまとめて丁寧に説明をしたり、何パターンか別案を考えて、現実的な落とし所をクライアントに相談します。最終的にクライアントを安心させられると良いと思います。

技術調査と仕様書作成で気をつけていること

開発がスムーズにいくことを意識する

  • 開発が手戻りしない(ムダな実装にならない)
  • 開発の手が止まらない(あらかじめいろいろ手配する)
  • クライアントと意識を合わせる

とにかく開発が前に進み続けることを意識します。

3. 保守対応

  • 実運用をしているとエンドユーザーからのお問合せがくる(弊社に直接ではなくクライアント経由)
  • アプリに関係あるバグと思われるもの
  • 開発担当にふる前に、私が調査できるものはまず行う
    • 開発メンバーに無駄な負担をかけないようにする

保守対応では、自分でも調査できるものは自分でまず行います。必要があればチーム内で相談して、各メンバーに相談します。

4. 開発メンバーからの技術や仕様の相談対応

  • 実際に開発に入ると、開発メンバーから技術的な相談や、仕様の矛盾などの相談がくる
  • それを一緒に考えて解決する
  • 自分の判断だけで解決できないときは、プロダクトマネージャーやクライアントにも相談し調整する

実際に作ってみないとわからない問題や、仕様書の時点では気が付かなかった矛盾点などが出てきます。
それをどうすれば良いか考えて、一緒に解決できるようにします。
どうしても調整ができなそうであれば、プロマネに相談したり、さらにクライアントにも相談します。

5. 開発メンバーとの1on1

  • 開発メンバーと30分の1on1を実施
  • 毎週1人ずつ。7週間で1周(各メンバーから見ると7週ごとに1回。頻度が多すぎないように)
  • メンバーから話を聞くことが目的
    • メンバーから何かあったときに気軽に相談してもらえるような雰囲気づくりも意識
  • 内容: 担当要件だったり、業務に関係ない雑談

1on1を行って、何か困ったことがないか?聞いたり、また、気軽に相談できる関係づくりとして雑談を行ってます。

やりがいについて

いま担当しているアプリ開発のやりがいについては以下になります。

  • お客様の自社EC売上高の中で、5年くらい前にアプリ経由の売上比率は10%くらいだった
  • 現在は自社ECの売上高も伸びていて、アプリ経由の比率が50〜60%くらいになっている
  • アプリ開発を継続する中で、アプリが売上に貢献していることや、お客様が喜んでくれることがうれしい
  • チームの雰囲気が良い
  • 1年半かけた大きなシステムリプレイスを成功させて、チームメンバー同士の信頼感と、チームの開発力もより高まった

プロジェクトの規模が大きくなると、大変なところもありますが、メンバーもやる気があり、とてもやりがいがあります。

以上が、現在担当しているモバイルアプリ開発のテックリードのお仕事内容の紹介となります。ではでは。

関連リンク

https://dev.classmethod.jp/articles/retailapp20241001/

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.