はじめに
どうも tattsun です。
今年ももう残りわずかになり、年末に差し掛かるということで振り返りブログを執筆します。入社してから今日まであっという間でした。自分の社会人生活の中でもトップレベルに時間の経過を早く感じる一年でした。
今年の動き
とりあえず自分の記憶を頼りに書いてみる …スカスカじゃん
「え、仕事していたよね」という気持ちになりましたが、人間の記憶なんてそんなものなのでちゃんとメモやドキュメントを残しましょうということですね。
気を取り直してログを遡って書き直すとこんな感じになりました。
実際には、合間に不具合改修やリファクタリングなどをしていたりするので完璧に表現しているわけではないです。大まかにはこんな感じだったなと記憶が戻ってきました。
数字で見る
やはり定量的に振り返る必要もあるのでいくつか数字を出してみました。
GitHub
Contribution を見るとこんな感じで、昨年と比較しても倍くらい増えていました。delyはとにかく前に進む力が強いので細かくアウトプットを出すという部分に重きを置いて開発をしていましたが、それでも自分の開発スピードやスキルアップしたという実感が今年はあります。
今年、作成したPR数についても調べてみました。入社してからこれまで578件のPRを作成していました。月次にすると約80件作成していることになります。つまり、1日4件は平均してPRを作成していることになる…（すごい💪）
| 総数 | 月次 | 日次 |
|---|---|---|
| 578PR | 80PR | 4PR |
ドキュメント
今年は、ドキュメントもたくさん作ったので調べてみました。基本的に Notion を利用しているのですが抽出が難しかったので手作業で数えました。全社的に展開したもののみで42件のドキュメントがありました。（タスクのチケットや個人的なログは除く）
42件のドキュメントと言われて自分でもピンとこないのですが、月次で6件なので1週間に平均1件はドキュメントを作成していることになりますね…（すごい💪）
| 総数 | 月次 |
|---|---|
| 42件 | 6件 |
Slack
どのくらいコミュニケーションを取ったかも可視化してみました。8月ごろからは Swift6 対応や広告関連のプロジェクトをやっていたのでコミュニケーション数が増加していますね。エンジニア以外ともすり合わせする機会が多かったので個人からチームに広がり、他チームまで巻き込んで仕事をしているのがわかりますね（いいね👍）
今年の学びを振り返る
今年は、この辺りが学びとしてありました。
- ドキュメント・設計書の書き方
- クラシルリワードのアプリ設計・構成
- Testable に実装する
- Swift Concurrency の理解
- 広告関連の理解
ドキュメント・設計書の書き方
直近半年はドキュメントをたくさん書きました。
上司に「施策で実装する時に設計書を書いてみて欲しい」と言われたのがきっかけで仕様書などのドキュメントを書き始めました。学生時代よりノートを作るのが好きだったのでそれ自体は苦になりませんでした。しかしレビューしてもらうと考慮が足りていなかったり見せ方が適切ではなかったりと、最初は指摘も多く受けました。
回数を重ねたことや、他の人が書いたドキュメントを読むことでブラッシュアップされていき、テックブログも初めは苦手意識を持っていたものの、書き始めるとスムーズに書けたので成長を実感しました。
一連の流れをステークホルダーとやりとりすることで、どのようなアウトプットが必要で誰にいつまでに見せる必要かなど、一連の作業が洗練されました。
1on1で「不安です」とぼやいている自分
ドキュメントを書くのは当たり前のことですが、スピード感が求められるとどうしても疎かになりがちな部分でもあります。ドキュメントを書かずに開発しても後で手戻りが発生したり、後からそもそもこの設計って…みたいな話になることがよくあるのでスピードが落ちているように見えるだけで実際には近道だったりもします。
出展: ハイキュー 24巻より
クラシルリワードのアプリ設計・構成
Swift6 対応の一環でクラシルリワードの構成とそれぞれの責務を整理しました。人の入れ替わりなどによって、当初想定していなかった構成が各所で出来上がっており、改めてこうあるべきだよねという認識をチームで揃える動きをしました。
チームに共有したドキュメント（一部抜粋）
これに取り組んだおかげでクラシルリワードが元々、どういう設計で作られたかが理解出来ました。エンジニアは新しい技術やトピックに追従していくことも重要ですが、それが今の設計に合っているかを慎重に見極める必要があります。よくあるのが1つのアプリでアーキテクチャが何世代にも渡っていて、移行完了する目処もないパターンです。
当時の導入した経緯もわからず、ドキュメントもないので空中分解している恐ろしいプロジェクトを自分も過去に経験したことがあります。
幸いにもクラシルリワードは比較的新しいアプリであり、設計もシンプルなため、全体像がわかって、それぞれがどういう役割なのかの認識さえ揃っていれば問題ありませんでした。過去の経緯や初期の設計を調べつつ、自分の理解を深めるとともに現状の実装からどうあるべきかをまとめることが出来ました。
細かい部分はどうするかを決める必要がありますが、概ね良さそうな手応えをチームから感じたので属人化しないようにしつつ、設計適合性についてレビューで目を光らせておきます。
Testable に実装する
クラシルリワードでは、テストを書く習慣があるのでコードを見るとテストを意識して実装されているのがわかります。もちろん、自分もテストを意識して実装しますが、それはミクロな視点の話であり、マクロな視点からちゃんと考えられていないことに気づきました。
これに気づいたのも設計書を書くことで、クラシルリワードや施策の設計に限らず設計に対する理解の深化が大きな要因です。テストを書くことで不具合の発生を事前に防ぐことが出来るのでテスト可能な実装になっているかどうかはとても重要です。直近だと、AsyncStream や広告周りのテストをどうするかを考えていました。（またその話はテックブログとして投稿します🙇）
テストも含めて設計であることを忘れずにより高いレベルでコーディングや設計が出来るように次は他のアーキテクチャなどを勉強してみようと思っています。今の自分の感覚を上手く言語化出来ていないのでまだ理解が足りていないなと感じつつ、新しい視点を持てたのは事実なので成長を実感出来ていて嬉しいです。
Swift Concurrency の理解
Swift6 対応もあり Concurrency と向き合う時間が多くありました。特に actor に関しては設計でも頭を悩ませた部分であり、そのおかげで理解が深まりました。
理解が深まると現状の課題が見えてきて、それに対してどうやって解消するかをあらゆる観点から考えていました。100％理解しているとは思わないので引き続き学習する必要はあります。
まずは自分がたくさんインプットして、チームに対して指針を示せるようにするのが目先の目標です。
delyでは、Swift Concurrency Guideline の作成・SwiftLint による Sendable や MainActor の検知で実装の揺らぎを防ぐ仕組み作成を進めています。
これによりチーム全体でのコード品質向上を図っています。
広告関連の理解
広告周りの実装は初期からあるようで事業影響が大きいため、なるべく触らないというのが暗黙のルールになっていました。しかし、AppLovin の仕様変更に伴い、どうしても対応する必要があったため、自分が設計・開発を担当しました。大体はわかっていても、詳しくは知らないという状態だったため、どうやって広告が配信されるのかや配信される広告がどうやって決まるのかなど実装以外の部分の理解も深まりました。検証していると「なぜ配信されない…」ということがよくありましたが、仕組み自体を理解すると「なるほど」となることも多く、スムーズに実装が終えられました。
元々、テストがなかったのですが今回の対応でテストを追加出来たのも良かったです。
出典: ポプテピピック(大川ぶくぶ)
まとめ
今年は、成長がとても実感できる一年でした。改めて振り返ってみるとチームに対しての行動が多かったことに驚きました。自分では特に意識しているわけではないですが、周りを巻き込んで意思決定や認識を揃えようという動きが出来ているのはとても嬉しいです。
来年はもっとアウトプットする予定であり、社内やチームだけでなくテックブログの執筆や登壇などさらに対外的にもアウトプットをしていきます。
Discussion