YOUTRUSTに入社して1ヶ月で取り組んできたこと

はじめに

こんにちは。株式会社YOUTRUSTでWebエンジニアをしております、石井と申します。

2022年6月1日からYOUTRUSTにジョインし、現在はtoCプロダクトの開発に従事しています。

入社してまだ1ヶ月しか経っていないのですが、新メンバーとしてこの1ヶ月どのようなことに取り組んできて、これからどのようなことに取り組んでいきたいかをお伝えします。

youtrust.jp

組織に対して取り組んだこと

事業部メンバー全員と1on1を実施

私が所属するSNS事業部では、副業・業務委託のメンバーも含めて30人程度のメンバーが在籍しています。入社して1週間経った頃にメンバー全員と1on1を実施しました。

社内で1on1についての取り組みをしたいとSlackにコメントしたときに皆さんから温かいリアクションをたくさん頂けたことはすごい印象的です。

当時のSlackの様子

どのような課題を感じていたか

自分の中で顕在化していた課題があったわけではなかったですが、将来的に以下の課題に当たる可能性があると考えました。

  • 誰に何を聞いたらいいのかわからない(プロダクト開発以外の領域だとなおさらわからない)
  • 事業部全体としてどのような領域やメンバーの関わりがあって成り立っているのかなどの事業部の全体の解像度が上がらない

その他にも一緒に働く皆さんのことが知りたいという気持ちと一緒に働く皆さんに私のことを知ってもらいたいという気持ちがありました。

この取り組みを通してどのような効果があったのか

どのような領域の関わり合いがあって事業が成り立っているのか、プロダクト開発という領域ではないところも含めて全体の解像度を上げることができました。 またSNS事業部に、どのようなスペシャリティを持ったメンバーがいるのか把握することができ、メンバーの役割や担当領域への理解が進みました。 特に副業・業務委託のメンバーに関しては業務で関わったことが無いメンバーともコミュニケーションが取れたのは自分にとって良い機会でした。

小話ですが、一部のメンバーからこの機会を設けることに対してとてもポジティブな言葉をいただき、一緒に働くメンバーの良さという一面も再認識できる機会となりました。

今後の仕事の関わりの中で効果を実感する日が来ると嬉しいなと感じています。

プロダクト開発プロセスに対して取り組んだこと

emoji prefixの導入

emoji prefixとはcommitメッセージの先頭に意味づけされた絵文字をつけるcommitルールです。 基本的にはgitmojiというサービスの内容を参考にし、必要に応じて取捨選択、チーム内で新しいユースケースの絵文字をカスタマイズしていく方式で実施しました。

gitmoji.dev

現状チームでは以下のテンプレートでcommitにemoji prefixをつけています。

emoji prefixのテンプレート

課題と効果

将来的に課題になりそうだと思う点に「レビュアーの負荷」というものがありました。例えば、プルリクの中で1commitが1000行あるものをレビューするレビュアーの負荷はかなり高いと思います。

今回のemoji prefix導入の最大の効果は、適切なcommit粒度を考えるきっかけを作ること、commitごとに意味づけすることによりどの部分を重点的にレビューするべきなのかわかりやすくすることなど、レビュアーの負荷軽減に寄与するものだと思います。

例えば、機械的にコードに変更が加わるもの(rubocopやeslintなどのFormatterなどが代表的です)は、機械的に修正されたものだとわかるようにすることで、レビュアーの負荷を軽減することにあると思います。

その他の効果として、commitの粒度が揃うことにより過去の経緯を追いやすくなったりするということもあります。

開発者が普段からcommit粒度を意識しながら開発することにより、中長期で継続的にレビュー負荷と開発スピードに貢献できるプロセスにするための土台作りができたのではないかと思っています。

リファクタリング推進委員会の設立

こちらは現在も続いている取り組みですが、中長期でコードの品質を担保し続けるための仕組みづくりをしていくという目的のもと発足させたものになります。

直近の課題の洗い出しから中長期で継続的にコードの品質向上に取り組んでいけるよう、プロセス側の改善もしたいと思っており、その第一弾として現状のリファクタリング項目洗い出しとそれをGitHubプロジェクトにて管理できるようにするという取り組みを実施しました。

以下リファクタリング項目の洗い出しから優先度決めまでをしたワークショップの様子です。(細かい内容はお見せできないのですが雰囲気だけでも...!)

FigJamでのワークショップの様子

課題と効果

課題として、プロダクト開発プロセスを仕組み化できないとなかなかリファクタリングタスクに取り組む時間を作り出すことは難しいと思います。

また往々にしてリファクタリングタスクの優先度は上がらないものです。事業貢献に影響しているかどうか分かりづらいからです。また優先度の高いものからどんどん取り続ける開発スタイルの場合、リファクタリングのタスクが取れる時間はかなり先になってしまうかもしれません。

そのため今回の取り組みは、リファクタリングをする項目を可視化して把握できることとリファクタリング項目を継続的に溜めていき、継続的に消化していく仕組みとセットで初めて価値が出るものだと思っています。 まだリストアップしただけなので、そこまで価値は出ていませんが、これから開発プロセスも少しづつよくしていきたいと思っています。

Issueテンプレートのリニューアル

GitHubのIssueで開発タスクを管理しているのですが、リファクタリング、バグ修正、機能追加、機能改善ごとにテンプレートを使い分けるようにしました。 GitHubのIssueテンプレートを選択できるようにし、目的ごとにIssueに必要な情報量を統一させるようにしました。

https://docs.github.com/ja/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#configuring-the-template-chooser

現在は以下のような項目のIssueテンプレートを選択できるようになっています。

Issueテンプレートの選択画面

課題と効果

先程のリファクタリング推進委員会の部分とも関連するのですが、開発チームとして一定期間あたりの進捗というものが定量的に可視化されておらず、進捗というものがふわっとしている状態に課題を感じたことが発端です。

一定期間でどのくらいの進捗が出せるのかわからない(もちろんブレはある前提として)と、機能実現のための見積もりの不確実性が高くなり、結果として早く終わりすぎる、もしくは納期を延長・エンジニアが頑張ってなんとか終わらせるという状態に陥ってしまう可能性があると考えます。

完璧な精度の見積もりをすることは難しいと思いますが、一定期間あたりの開発チームの進捗が測れる形で可視化できている場合、将来的にはそのうちの何%をリファクタリングタスクに使うなどの意思決定もできるようになると思っています。

今回のIssueテンプレートでは見積もりというものは入れていませんが、少なくとも統一的なフォーマットでIssueの粒度を揃えていくことで計測可能な情報の土台を作っていこうと考えています。なのでこの取り組みも効果が出るのは少し先になるかもしれません。

最後に

プロダクト開発の仕事と平行してではありますが、入社1ヶ月で取り組んできたことの共有でした。 私としては、入社してからプロセスの改善への取り組みの声を他のメンバーが積極的に議論、取り組みへの協力をしてくれたことが印象的で入社直後から自分の意見や取り組みの発信を受け入れてくれるいいチームだなと改めて思いました。

これから更に皆さんに良いプロダクト価値を届けられるように頑張りたいし、このチームなら頑張れるとそう思いました。

最後に宣伝にはなりますが、現在YOUTRUSTでは一緒にプロダクト価値を提供してくれるWebエンジニアの方を募集しています!興味のある方はチェックしてみてください!

herp.careers