リーナーに入社して3ヶ月経った - tanaken’s blog の続編です。
株式会社Leaner Technologies（以下、リーナー）に入社して6ヶ月が経ちました。
直近3ヶ月のこと
5月下旬〜7月上旬
フロントエンドのフレームワークを移行に取り組んでいました。 この取り組みの全体像については「リーナー、Nuxt.jsからNext.jsに乗り換えたってよ - リーナー開発者ブログ」にまとめられています。
この取り組みは約1年前に開始されたもので、自分は最終段階でこの取り組みに加わったことになります。 取り組みを推進していたメンバーが別のプロジェクトに移るという事情もあり、自分が推進者の役回りを引き継いで「残りをきっちり最後までやりきる」を目標にガツガツと実装していきました。
無事に最後までやりきれて本当によかったです。各画面の移行実装に留まらずにさまざまなこと（エラーハンドリング周りの処理の改善、UIデザインコンポーネント集へのコミット、E2E・VRT、CloudFrontでの新旧画面への振り分けなど）に取り組めたこともよかったですね。フロントエンドの実装に対する理解が深まりました。
7月中旬〜下旬
上述の取り組みがいったん完了した時点で新画面に完全に移行した状態にはなりました。 ですが、「ここちょっと気になるけど急ぎじゃないからあとでやろう」といった積み残しはそれなりにありました。
積み残したことはタスクとして積んであったので、それらを棚卸しして優先順位をつけ、7月の残りの期間で潰せるだけ潰していきました。
8月
8月からは開発チーム内の役割の入れ替えをして、自分は「問い合わせ担当」として動き始めました。 プロダクトへの理解を深める手段として、問い合わせに答えるのはすごく良いですね。ユーザーのことも知れるし、機能も知れる、本当にお得です。しかもたのしい。
「問い合わせ担当」という名前ですが、エラー監視ツールからの通知の対応やライブラリのバージョンアップを主導する役割も担っています。このあたりもプロダクトのコードベースへの理解を深めるきっかけが山ほどあります。たのしい。
感じてること
ユーザーに新たな価値を感じてもらえるような取り組み
自分自身はほとんどできてないなと感じています。
フレームワーク移行の取り組みは基本的に画面の見た目や挙動を変えないことを目指して取り組んでいたので、新たな価値が増えないのは致し方ない部分はあるものの。
8月はもっとそういう動きができてもよかったんじゃないかなと思っています。 ちょっと問い合わせ対応に夢中になりすぎた＆コストを掛けすぎた（もっとスピーディーに解決できる問い合わせもあった）ので、そのへんは改善ポイントかなと思っています。
ユーザーにとって分かりやすい変化 = 新たな価値を、コンスタントに提供していく、というのは忘れずにやっていきたいところです。 （水面下でほかのメンバーが大きめな機能の開発を進めていたりはするわけですが、それ以外の価値提供もしっかりやっていく）
スピード
上述の価値提供の話にも通じるんですが、とにかくもっと速くできることは速くやっていかなきゃならんな、という想いがあります。
コードベースが大きくなってきて複雑さが増しているなかで、速度を上げて開発することは簡単ではないですが、チャレンジしていきたい。
また、コードを書くところ以外の部分でも速度を上げる余地はありそうとも思います。
たとえば「どの課題に対してどう解決するか = 何をつくるか」を決めるところ。 自分は「安易に解決策を実装してしまって負債になること」を恐れる傾向があります。ブレーキを踏みがちなんですよね。 その傾向を自認したうえで、もうちょいブレーキを緩めてみてもいいかもしれないと思っています。
自分たちのようなスタートアップはスピードが最大の強みと言っても過言じゃないはずで、中途半端にブレーキを踏んで強みを潰さないようにせねば、と感じています。
再構築
という話をした一方で、中長期的なことを考えたときに見直しておくべきシステム内部の課題もありそうです。
1年前に「フロントエンドフレームワークを移行する」という意思決定をしてやり遂げたことで、いまフロントエンドの開発は以前よりやりやすくなっています。
これと同じように、いま向き合うべき課題に向き合っておくことで、将来の開発速度をあげることができるかもしれません。
これからやること
プロダクトの理解を深めて機能リストを整備する
引き続き、問い合わせ対応を起点としてプロダクトの理解を深めていきます。加えて、理解したことを「機能リスト」に追記していきます。
「機能リスト」はプロダクトの機能をまとめたNotion DBです。 最近はこれのメンテナンスが滞っているので、構成の見直しやメンテナンスのポリシーを定めて改めて活用していきます。
現状の機能を整理し、誰でもアクセスできる状態にすることで、問い合わせが解決するまでの速度をあげることができるし、今後新たな価値（現状の機能との差分）をつくるときも活用できる情報になると考えています。
向き合うべきシステムの課題とそうでない課題を切り分ける
システムの課題を洗い出して、取り組むべき課題といったんおいておく課題を明確にします。
取り組むべきと判断した課題については、いつ着手していつまでに解決するのかを決めます。
以上、入社6ヶ月のふりかえりでした。
淡々と書いたけど、とてもアツく燃えています。やるぞ！！！！
