概要
みなさんこんにちは！こんばんは！
dely株式会社にてクラシルリワードのiOSアプリの開発を行っている、iOSエンジニアのtakkyです！
年の瀬ということで、入社してから今までの振り返りを行いたいと思い、この記事を書いてみました。振り返り方法としては、利用可能なデータを活用して、自分自身の取り組みを9ヶ月分振り返りたいと思います！
具体的には、Github上で確認できる開発データや、自身のブログ執筆や登壇回数などをもとに振り返ります。社内のプライベートなデータはもちろん利用できないので、外部に共有して問題ない範囲に限ります。
なお、ここで使用するデータについては、「数値が高い＝良い、低い＝悪い」という意図ではありません。私や所属スクラムの特性上、特定のアクションを数多く実施する傾向があるため、あくまでも参考情報としてご覧いただければと思います🙌
9ヶ月間何やってたかタイムライン
データで振り返るとは言いましたが、最初はざっくり、4月から12月末まで自分がどんなことしていたのかを簡単にタイムラインにして、振り返ってみます。
4月から12月末までのタイムライン
オレンジは、自分が所属するスクラムでの実装で、ブルーはiOSチームで自分が持っていたタスクになります。（登壇関連はiOSチームでのタスクではないのですが、便宜上iOSに配置しています。）
自分が所属するスクラムは、場合によりますがほとんどの機能を1週間のスプリント内で実装してリリースされるので、細かくは区切らずかなりざっくりと上記のようなスケジュールで開発に携わっていたかと思います。
中でも印象的なのは、後掲している『動画広告のターゲティング実装』や『ナーチャリングUI実装』・『友達招待実装』などが挙げられます。
『動画広告のターゲティング実装』
全くのドメイン知識無しでキャッチアップをしながら、配信の仕組みを実装したりQAしたりして広告配信周りの実装の概要を理解する良い機会になりました！どのような仕組みになっているかを理解できていたことで、その後も広告周りの実装での調査が捗り、思考が整理できた気がします。
入社したてでも影響範囲の大きい実装はすぐにでも任せてもらえるのは、すごく良い環境だなと実感したのも覚えています。
『ナーチャリングUI実装』と『友達招待実装』
1~2週間内で3~4画面に跨る実装や複雑なロジックの実装などを行い、これぞdelyの質のいいものを早く作って検証してみるサイクルの真骨頂かなとも思い、実装が終わった後はやり切った感はありましたね！
『ナーチャリングUI実装』は以下に添付しているような、ステップごとにコインがもらえるような機能でミッションの達成状況に応じてチェックポイントを細かく制御して、どの程度ミッションが完了しているかを分かりやすくする実装が肝でした。
また、上部に表示されているゲージUIは、Riveと言われるアニメーションファイルを活用しての初の実装だったので、リッチなUIの実装の幅がかなり広がったなと感じました！
ナーチャリングUI実装画面
友達招待実装に関しては、既存の友達招待の仕組みを大きく刷新したものを導入するというもので、友達招待を行った上で一定の基準を満たすと、以下のようなルーレットを回しコインを獲得できるような機能になります。
友達招待のルーレット画面
ユーザーが属しているランクによって回せるルーレットを変更したり、こちらの実装でもRiveアニメーションを利用してUIをリッチにしたりとかなりタイトなスケジュールで細かい調整を行なってリリースしたので、全力で実装すればかなり早くかつ正確に実装できるようになったなとも実感できた開発タスクでした！
上記の機能も無事にリリースされたので、数値を追いつつ目指した形になれているかもしくは、そうなるために手を加えるなどしてよりいい状態に持っていきたいですね。
『エラーハンドリングの基本方針策定』
こちらはモバイルアプリ全体でエラーハンドリングの基本方針統一し、ドキュメントに残して共通認識を持つためのプロジェクトを行なっていた期間です。iOS・Androidチームで例外処理が発生した時のエラーハンドリング方法は、ある程度統一されていたのですが暗黙の了解のような状態であったので、自分が再定義し言語化することで両OS間で統一するプロジェクトを行なっていました。
この際にクラシルリワードアプリのエラーハンドリングについてのあるべき姿を鑑みた方針を定義でき、実装時のコミニケーションコストや不適切なエラーハンドリングによるインシデント等は起こっていない状態を保てています。
PRのテンプレートにチェックボックスを求める簡易的な方法ですが、今のところはこのミニマムな運用で回っており、PR作成時に解析ツール等での検知の仕組みは作成しなくてよさそうです！🙌
PRテンプレートのチェックボックス
また現在進行形で行なっているのは、アプリ内でJSONを特定の型にデコードする際に例外処理が発生したら検知できる仕組みを作成するプロジェクトで、1月中を目処に終了する予定です。
magic pod運用方針策定
アプリをよりスケールしていくにあたって今以上にデグレが起きていないか確認するテストを効果的に運用し外部品質を維持し続ける方針を作成していくプロジェクトを実行中です。現状のmagic podの運用に関してはこちらにあります。
これら全てのプロジェクトが無事終了したら、再度フォーカスしてテックブログを書きたいと思います！
実装に関するデータ
ここからは、Githubや社内で管理しているデータを利用しうる限りで利用して振り返ってみます。
エンジニアみんな大好き、Githubの「草」の状況についてです。
気がつけば草が生い茂っている状況で色が濃い週は、大きめの機能実装でスクラムの機能開発に全てを注いでいる週かと思います。
ただ、4~5月の草が濃い箇所は入社当初に開発に慣れず、無駄にコミットをしてた記憶があるのでその影響で濃くなっているのではと考えています。
自分のアカウントのProfile
どの期間にどの機能を実装したかもある程度わかるのですが、ある程度濃い箇所は上記の『9ヶ月間何やってたかタイムライン』で記載している印象に残った実装を行っていた期間ですね。
次は、自分がメインブランチへマージしたPR数をみてみましょう。
こちらはクローズしたものもありますが、記憶には数件しかないので、この数値がマージした数とほぼ同値とします。
クローズした（=マージした）PR数
2024/12/25(水)時点で、603PRが該当していました。中には機能実装だけでなくリファクタリングやiOSアプリの基盤側の修正を行ったPRも含まれているので、クラシルリワードで実装した全てのPR数がこちらになります。
単純計算でざっくり出してみたら以下のような数値になりました。
1日平均約3.12件PR作成しているみたいですね🙌
そうなってくると、PRをよりクイックに作成する必要がありこの作成時間を短縮できないものかと考えたいところです。（もちろんレビューワーの方や将来PRを見るかもしれない方へ正確に分かりやすい状態で作成）
上記の数値になっている要因を振り返ってみると、クラシルリワードのモバイルチームでは、FeatureFlagを利用したトランクベース開発を採用しており、ユーザーに影響無い実装はブランチを細かく切ってどんどんメインブランチにマージする戦略をとっているので、ベースとしてPRが多く発生する仕組みにはなっているのでこれぐらいの数値感になるのではないでしょうか。
スピード感を大事にして実装するクラシルリワードのモバイル開発組織においてマッチしているブランチ戦略なので、ぜひ試してみていただけると嬉しいです。
（※モバイルアプリの開発手法や開発組織全般に関する記事はこちら）
ユーザーへの影響が無い実装を行って、ユーザーさんに機能が提供される実装を行ったPRのラベルは、FeatureFlagで機能の表示制御を入れたPRもしくは単純に表示するようにロジック変更が加えられたPRなどになります。
以下ではFeatureラベルがついたPR数を単純に算出したら、81PRでした。
機能をリリースするためのPR数
自分がこの9ヶ月間走り続けたのは、38スプリント（約38週間）となるので、毎週2~3個の何かしらユーザー影響のある実装をリリースしていることになりますね！
iOSチームのアプリアップデートタイミングは週に平均すると3回程度になるので、実装したものがすぐにユーザーさんに届けられるのも良い環境だなと思います！
レーダーチャートにもあるとおり、逆に自分がレビュワーとして他の方のPRのレビューしたPR数も出してみたところ、1231レビューしたことになります。
叩いたコマンド
gh pr list --repo owner/repo --search "reviewed-by:UserName is:closed"
出現した数値
Showing 30 of 1231 pull requests in owner/repo that match your search
気になって、自分が所属する期間内にiOSチームのメンバーがマージしてクローズされたPRの数は、以下のような数値が出ました。
クラシルリワードiOSの４月からのPR数
チームメンバーの皆さんも凄まじい量のPRを出されており、クラシルリワードiOSの日々の開発量とスピードが感じられました！！🙌
いろんな数値を見てきましたが、実装の数値として最後にクラシルリワードiOSのコントリビューションを見てみたいと思います。
クラシルリワードiOSの全期間コントリビューション
クラシルリワードは2年半前ぐらいから開発が行われており、その中で自分は9ヶ月実装していたわけですが、3183コントリビューションあり、意外にも上位に食い込むようになっていて、開発にかなりコミットできている状況であるのかなと思います！
スクラムとして開発した施策数やiOS全体の機能リリース数も見てみたいところですが、こちらについてはまた誰かが話してくれることを期待しておきます。🙏
コミニケーションツール関連
OffersMGRという管理ツールにて、Slackのコミュニケーションを取得してみたところ、Slackでのコミュニケーションの数がみられますが普段特段指標等も無いため、比較するものもなくとりあえずこれだけ誰かとコミュニケーションをとっていることはわかります。
OffersMGRにより算出されたSlackのコミニケーション数
また、以下の発信関連データでも触れるのですが、テックブログ『ドメイン知識のキャッチアップの際に行ったこと』にもある通り、日々自分が行動したり得た情報をSlackの自分のスレッドに追記していき言語化しているので、言語化する週間がついてきていることによる数値上昇になるのかなと思います。
この言語化に関しても、言語化をするアクション数としては申し分はないと思うので、今後はより的確かつ密度の濃い端的な言語化を行えるように意識したいです！
発信関連のデータ
対外向けに行われる勉強会で人生初の登壇を経験しました。20分程度の尺でターゲティング動画広告配信の話をしたのですが、『業務でキャッチアップしたものを自分の言葉にして相手に伝わりやすく話す』という日頃業務でも心がけていることを行うとてもいいチャレンジになりました！
また、テックブログの執筆は共著のものも含めると3記事投稿しました。（※この記事を含めると4記事目になります。）過去に投稿したテックブログの内容については、以下のリンクから確認いただけると嬉しいです！
登壇やテックブログで発信をすることで、日々自分が業務を行う際にエンジニア同士の会話やSlackで言語化することの延長線上だと思い、今後もキャッチアップしたことは継続して発信していきたいと思います！
弊社でもDevelopment Guidelineの『成長と学び』にて、テックブログでの発信やカンファレンスでの発信について大事にしているので、今後も継続して投稿&登壇していきたいところです！
さいごに
ざっと振り返ってみて本当に密度の濃い9ヶ月間だったなと改めて思いますし、開発に関わった機能がユーザーさんに触っていただけて嬉しい気持ちで一年を締めくくることができました！
毎年この時期に個人的に振り返りを行ってはいるのですが、Github上のデータや自分が実装したことをタイムラインにして、振り返るのは初だったので今年一年で行ったことを丸っと振り返れられてよかったですし、来年はどのような年にして何をしたいのかも頭の中で整理できる機会になりました！
（ちなみに今のところざっくりの来年の目標は自動化できることは今以上に自動化していくことと、技術的にもドメイン的にも新たな領域にチャレンジしていきたいと考えています！）
また同時期ぐらいに入社したiOSチームのたっつんさんの振り返りブログもあるので、ぜひご覧ください！🙌
良いお年を！！
関連記事
Discussion