オフィスの外観

内定者アルバイトを終えて

2024-3-1

目次

目次

  1. はじめに
  2. 背景
    1. 就活
    2. 実務経験が欲しいぞ
  3. ジョインする
  4. 取り組んだこと
  5. チームでの開発
    1. スクラム開発
    2. 役割とPBIの進め方
    3. 学び・感想
  6. イベント
  7. まとめ

はじめに

24卒としてサイボウズに内定をもらってから、フロントエンドエンジニアとして内定者アルバイトをしていました。

期間は2023/10/1~2024/2/29までの5か月間。

本当はせっかくだし少し踏み込んだこと書こうと思って、アルバイト最終日に「どの辺からグレーゾーンなんですかね?ここって社外秘ですか?」とか聞いてましたが、最終日だし、わざわざレビューしてもらうのもなんかな...と思ったので、 踏み込まずに感想ベースで個人ブログにだらだらとまとめました。

背景

早く働きたい!と思った動機として一応書きますが、本質ではないことも話しています。

ジョインするからがアルバイト体験記です😌

就活

私は2022/8~2023/5月末まで、University of Technology Sydney(UTS)に2セメスター交換留学しており、Information Technology を専攻していました。

就活期間はその期間内でした。

留学当初は生活に慣れるので精一杯だったり、バックパッカーしてたりで(詳細は後日(?))、

「まー、インターンも実務経験もないし、就活とか無理だし、帰国したら院進しようかな。過去問取り寄せなきゃ。」と考えていました。一応研究室の先生に相談したところ、

先生:「どうせM1になっても就活あるんだから、経験としてやっといてもいいんじゃない?」

私:「🫡」

という流れで晴れて就活生活がスタートしました。(この時点で2023/1なので、今考えると24卒インターン経験なしとしては😱。当時はそんなことも知らない。)

ℹ️ Info
留学中に日本企業の就活ができたのは、渡航国と日本との時差が2時間(サマータイム)しかなかった&ITエンジニアとして就活してたのでオンラインで内定承諾まで完結できたからです。加えて、留学先では11~2月までがSummer Holidayだったので、就活に集中できる時間が確保できたこともラッキーな要因でした。

それからは自己分析と企業研究を並行しながら、サポーターズに登録して、企業を提案してもらって、合いそうなとこを受けていく流れでした。(留学中まともに日本語を喋ってなくて、めちゃくちゃ思考力が落ちていた(外国語副作用)気がしたので、急いで日本人の友達を作ったり、面談や受ける企業数を増やして慣れていたという点で少し特殊な手法をとっていたかもです)

とはいえ就活生としての技術力はほぼなかったので、いろんな企業が公開している技術試験をやったり、以前Vue.jsで作っていたアプリをReactに書き換えたりして、就活駆動開発していました。

それから1か月半〜2か月、色々(住んでいた家を追い出される、新学期が始まるなど)ありましたが、就活を続け、2023/3初旬に第一志望だったサイボウズの内定を承諾して就活を終えました。



どうしてサイボウズなのかは自分のなかで諸説ありますが、パッとふわっと出てくるのは、なぜか面接が楽しくて、素の自分で話してるなと感じられたからです。

実務経験が欲しいぞ

とはいえ、内定をもらってからの方が将来に対する不安が込み上げてきました。

インターン経験・実務経験ないしはチーム開発経験も薄い私がこのまま来年から社会の波にのまれるのは非常に好ましくないと思いました。

サイボウズでは、定期的に内定者が集まれるイベントがオン・オフラインで用意されています。

そのなかで同じフロントエンド職能として内定をもらっている同期と話す機会があり、「内定者バイトとかないんかねー?」という話題になりました。

そんな"ほざき"を人事の方に相談してみたところ、「現状では考えていないですが、検討してみます!」と議論の場に持っていってくださり、チームに受け入れ体制を整えてもらって、働くことができるようになりました。

学生の希望を真摯に聞き入れてくださった人事の方やチームには感謝でいっぱいです。

ジョインする

たくさんの協力があって実現したサイボウズでの内定者アルバイトは2023/10/1~始まりました🌷

サイボウズではさまざまなグループウェア製品のプロジェクトが進行しているのですが、私はkintoneというグループウェア製品の開発チームに配属されました。

あなたの「その仕事」にkintone(キントーン)| 業務アプリをノーコードでつくれるサイボウズのクラウドサービス
キントーンは、プログラミングの知識がなくても、ノーコードで業務のシステム化や効率化を実現するアプリがつくれるクラウドサービスです。散在するエクセルや、煩雑なメール、紙の書類の山、バラバラなシステムなど、業務を非効率にしている困りごとを解決できます。
あなたの「その仕事」にkintone(キントーン)| 業務アプリをノーコードでつくれるサイボウズのクラウドサービス favicon https://kintone.cybozu.co.jp/
あなたの「その仕事」にkintone(キントーン)| 業務アプリをノーコードでつくれるサイボウズのクラウドサービス

フロントエンド職能採用であったため、そのなかでもフロントエンドリアーキテクチャチーム(通称:フロリア)という、現状Closure Toolsで書かれているkintoneのフロントエンド実装をReact+TypeScriptに刷新するチームへ配属されました。

📝 Memo
実際は刷新だけではなく、他にもkintoneのフロントエンドを継続的に開発可能にしていく取り組み(テスト拡充、アクセシビリティ改善、パフォーマンス計測など)が行なわれている

フロリア カテゴリーの記事一覧 - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズ株式会社、サイボウズ・ラボ株式会社のエンジニアが提供する技術ブログです。製品やサービスの開発、運用で得た技術情報やエンジニアの活動、採用情報などをお届けします。
フロリア カテゴリーの記事一覧 - Cybozu Inside Out | サイボウズエンジニアのブログ favicon https://blog.cybozu.io/archive/category/フロリア
フロリア カテゴリーの記事一覧 - Cybozu Inside Out | サイボウズエンジニアのブログ
kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
kintone フロントエンドリアーキテクチャプロジェクトリーダーの @koba04です。 昨年末から、kintone フロントエンドリアーキテクチャをプロジェクト(フロリア)として再構成してスタートさせました。フロリアという名前は社内での公募により決定しました。 今回はプロジェクトで目指していることについて紹介します。本プロジェクトの開始前に Cybozu Meetup で話したスライドや動画も公開されているのでよければ見てください。 speakerdeck.com www.youtube.com これまでの取り組みについては下記の記事にて紹介しています。 blog.cybozu.io 3 …
kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ favicon https://blog.cybozu.io/entry/2022/02/04/171154
kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ

フロリア内でもチームはさらに細分化されており、中でもkintone内でアプリを作成する画面(以下参照)の刷新をするReactoneチームで働くことになりました。

アプリ作成画面 アプリ作成画面

kintoneのような大規模プロダクトの刷新でも、このようにページ単位でチームが細分化されているため、各チームがしっかりオーナーシップを持っており、技術選定やアーキテクチャ設計に対する議論を活発にしながら開発できるのはいいなと感じました。

取り組んだこと

私が内定者期間中に携わった具体的な刷新項目は以下でした。

  • 一覧画面の刷新(追加・編集・複製・削除・DnDなど) 一覧画面 一覧画面
  • フォーム画面(アプリ作成画面の図参照)の一部フィールドの刷新

チームでの開発

スクラム開発

開発サイクルは木~水1週間を1Sprintとするスクラム開発で、大体以下のような感じでした。

  1. 火:バックログリファインメント
  2. 水:スプリントレビュー、レトロスペクティブ、スプリントプランニング
  3. 木:スプリント開始
  4. 毎日:朝会(デイリースクラム)

PBIの管理にはGithub Projectsを使っていましたが、途中からZenHubを使用していました。 基本的にカンバン方式なのはGH Projectsと一緒なのですが、ZenHubでは消化SPに基づいてベロシティーが計測されたり消化PBIの変化がわかりやすかったり、データの可視化の面で優れているなと思いました。 (稼働日的にスクラムイベントめちゃくちゃ参加できたわけではないですが......)

役割とPBIの進め方

チームはPG(3~4人)、QA(2人)、SM(1人)から構成されていて、それぞれがドメイン知識を活かしてPBI消化にコミットしており、とても贅沢な開発環境だったと思います。

以下は取っていたPBI消化までのサイクルです。

  1. スプリントプランニングでPBIが決まる
  2. PBIに基づいてタスクを箇条書きし、Issueを作る
  3. Issueの機能実装をする(ペアやモブプロで実装する。場合によってはソロ)
  4. QAの方と自動テスト観点のすり合わせをする(Integration Test, Browser Test, E2E, VRTがある。Issueの種類によってどの観点でどのテストをどのくらいやるかが異なるので、そこを擦り合わせる)
  5. 自動テストを実装する
    • Integration: Jest+Testing Library
    • Browser: Storybook+Playwright
    • E2E: Selenium
    • VRT: Storybook+Chromatic
  6. セルフレビューをする
  7. PGレビューに出す
  8. レビュー修正をする->Accepted
  9. QAの方に手動テストをしてもらう
  10. 手動テストクリアしたら晴れてマージ💯

機能の実装には必ず適切な種類と粒度のテストが伴うようになっています。

学び・感想

毎回多くのことを学んだのですが、アルバイト期間を通して特に印象に残っている部分をピックアップします。

PRの出し方

先に述べたように、私はチーム開発の経験が薄かったので、最初はこうしたサイクルを覚えること、PRを出すときの振る舞いなどにとても不安がありました。(チーム開発に対する不安を解消するためにアルバイトをしたかったまである)

最初の方に先輩PGの方にべったりペアプロしていただいたことで開発フローを掴むことができ、だんだんソロやモブプロできる時間が増えてきました。

また、社内ドキュメントやADRが非常に充実しているため、ソロプロで困ったときはよく活用していました。

レビュアーに伝わりやすいPRを出すために気をつけていたことは、PRのテンプレートを用意することと、セルフレビューを挟んでからレビューしてもらうことです。

PRテンプレートは個人のリポジトリなら用意するようにしているのですが、社内リポジトリのテンプレートを新たに作るのもちょっと気がひけったので、私はChrome拡張機能を使用して以下のようなPRテンプレートのスニペットとして登録しています。

PRのテンプレートがあることで、毎回均一な情報濃度のPRを作成できます。

Text Blaze
A powerful text expander Chrome extension. Optimize everything you type with auto text snippets, templates and macros.
Text Blaze favicon https://blaze.today/
Text Blaze
## 🏁 Outline
 
## 🔗 References
 
## 📝 Description
 
## 📸 Image
 
## ✅ Test

セルフレビューに関しては、実装できたら自分でコード差分を読まずにレビュアーをアサインしてしまっていました。

そのため、コード差分がわかりにくそうな部分にはコメントをつけてからレビュー依頼するように心がけています。

そうすることで、無駄な差分やミスに気づけますし、実装中にした小さな意思決定を相手に伝えられるのでレビューコストの削減が期待できました。

テスト実装

技術的な面では、React+TypeScript, Reduxは面識が濃かったですし、StorybookやChromaticも個人的に使用していたので知識を活かせました。

しかし、当初はテスト実装の経験が薄く、Integrationテスト項目1つPassするにも業務時間の半分近くかかったりしてました。

そもそも、 「どんなテストを」「どのように」「どの方法で」「どのくらい」 実装するのかがわかっていなかったため、前述した「QAの方と自動テスト観点のすり合わせ」というプロセスやテスト設計のADRがとても勉強になりました。

QAの方と自動テスト観点のすり合わせを行なうときは、QAの方が事前に用意してくれている各テスト項目に関して以下のような点を中心にQA<->PG間ですり合わせます。

  • どんなテストを: 期待結果の確認
  • どのように: そもそも実装可能か・実装手順の確認

    1. XXのボタンを押してダイアログを開く-> 2. 文字列を入力する-> 3. 保存ボタンを押す-> 4.画面を再読み込みする-> 5. 値が保存されていることを確認するなど
  • どの方法で: Integration Test, Browser Test, E2E, VRTの選定基準ADRを参考に
  • どのくらい: 他のテスト項目と本質的に重複していないか・本当に実装の必要があるか

また、テストを書くようになったことで、アクセシビリティツリーを意識した実装や、テストコードを書きやすくするための適切な抽象化の粒度・コード設計を考慮できるようになりました✅

📝 Memo
抽象化やコード設計に関してはデザインパターンが大きく関与しており、すべてではないですが、Zennで書いたReactデザインパターンについての記事でまとめています。

※TSで書けるIntegrationやBrowserテストは割と手がさくさく動くようになりましたが、Javaのコードを触ってSeleniumで動かすE2Eテストは今でも苦手です🤮

イベント

内定者同期とのイベントも含めて、たくさんの社内イベントの参加も経験させてもらいました。

  • 社内勉強会:Reactドキュメントを読む会

    23新卒の先輩方がやっていた社内勉強会に24卒内定者が途中から参加する形でした。 内容はhttps://ja.react.dev/learnを回しで読んでいく形で、Reactに対する理解を深めることができました。

  • ブログWeek

    社内で技術探求やブログを書く時間が設けられている週があり、その期間は業務としてブログ記事を書いていました。

    好きな内容で探求活動をして良かったので、私はReactにおけるデータフェッチ方法を調査して記事にまとめました。 はじめてブログなんて書くのでとても不安だったのですが、フロントエンドエキスパートチーム(FEE)の方たちから技術的な指摘や日本語面でのアドバイスをいただくことができ、心理的安全性の高さを感じました。

  • Reactoneミートアップ

    普段一緒にお仕事をしているReactoneのメンバーとオフラインで会える最初の機会でした🌟

    今回は各地から福岡オフィスに集まってのミートアップでした🍜

  • Cybozu Days

    開発に携わっているプロダクトが個人や他企業にどのような影響を与えているのかを知ることができました。刷新プロジェクトであまりユーザーからのフィードバックが得られない中、貴重なイベントだったと思います。

  • 内定者オフラインイベント@東京オフィス

  • Advent Calendar

  • 開運祭り、Cybozu Frontend Day 2024

    開発本部・運用本部のメンバーが東京オフィスに集まって、LTやOSTを通して交流する機会でした。一方的に認知していたあんな方やこんな方と会えたり、直接話す機会をがあったり、終始Wowでした🫢

まとめ

サイボウズで内定者アルバイトをした感想をまとめました。

誰かに伝える目的<記憶の保存という感じの書き方でだらだらとなってしまいましたが、この記事がチーム開発に関する解像度を少しでもあげるものになれば幸いです。

学生時代にこんなに恵まれた環境を経験できたことをとても幸せに感じていますし、4月から入社したらもっともりもり頑張っていきたいと思います🐣🔥

新人研修で他の同期と会えたり、開発本部の講座受けられるのも楽しみ!

それまで、学生としての余生を楽しむ旅に出ようと思います。(To be continued...)

Copyright © 2024 saku 🌸 All rights reserved.