こんにちは、サイボウズ 25卒エンジニアチームです。
今回、サイボウズの25卒エンジニアの中で内定者アルバイトを行っているメンバーの中から、内定者バイト体験記を書いてくれる人を募ってこの記事にまとめることにしました。
Webアプリケーションエンジニア、フロントエンドエンジニア、生産性向上エンジニア、プロダクトデザイナー、QAエンジニアの5人が集まってくれたので、それぞれが書いたものを順番に紹介していきます。
Webアプリケーションエンジニア くらっち
Webアプリケーションエンジニアとして内定をいただいているくらっちです。
私は、kinotneのアプリ設定画面を改善するチームに週2回のシフトで参加しています。
最初の1ヶ月は環境構築やオンボーディング課題をメンターの方に教わりながら進めました。
今回は私が担当したタスクをいくつか紹介します。
1. E2Eテストの改善: 不必要なUI呼び出しをAPIへ切り替え
kintoneでは、アプリの作成・編集をアプリ設定画面で行います。kintoneのE2Eテストにおいて、アプリの一覧画面などの一部のテストケースでは、前準備としてアプリの作成・編集が必要です。その際にアプリ設定画面を呼び出して準備をしているものがありました。しかし、このようなテストケースでは、テストの対象はアプリ設定画面ではないため、本来は画面を呼び出す必要はありません。また、画面操作によるテストは時間がかかり、テストの不安定さにもつながります。その点、APIを使うと、画面操作を省略してテストに必要なアプリを準備できるため、時間短縮ができテストが安定します。そこで、画面操作をAPIの呼び出しに切り替える改善を行いました。
JavaでE2Eテストを書いた経験はありませんでしたが、既存のコードを参考にし、分からない箇所はメンターの方に質問しながら進めました。進める上で難しかった箇所は、対象のテストがアプリ設定画面の操作をテストしているかの判断です。画面操作のテストをAPI化するとアプリの保守性を低下させてしまう可能性があります。テストの仕様書やコードを1行ずつ確認し、アプリ設定画面の操作をテストしているのかをメンターの方と相談しながら修正すべきテストを整理しました。
2. アプリ設定画面のテスト拡充
kintoneではリファクタリングのため、サーバサイドのコード分割を実施しました。
詳しくはこちらの記事をご覧ください。
コード分割を通じてクラスの責務が明確になったり、素早く開発ができるようになったりしました。しかし、現状のテストでは、確実に他領域を壊していないと判断できないという課題があります。そこで、他領域に公開している部分のクラスの振る舞いが壊れていないかのテストを拡充することが必要です。このテスト拡充の一部を任せていただくことになりました。
進める上で難しかった箇所は対象のクラスに対して必要十分なテストを書くことです。
テストを書きすぎてしまうと、意味のないテストが生まれたり、細かすぎるテストによって保守性が低くなったりします。一方、テストが不足していると、クラスが正常に動作していることを保証できません。必要十分なテストを書くために、クラスの振る舞いに注目して、テストをシンプルにすることを意識しました。
テストを書くためには対象のクラスを深く理解する必要があります。そのため、アプリ設定チームのコードをより深く理解できる良い機会になりました。
フロントエンドエンジニア mehm8128
フロントエンドエンジニアとして内定をいただいている、mehm8128（めふも）です。
僕はkintoneのフロントエンド刷新プロジェクトの一環として、アプリ画面のReact化を行っているチームに週3のシフトで参加させていただきました。
脱Closureプロジェクトについてはこちらの記事をご覧ください。
blog.cybozu.io
このチームでは主にkintoneのアプリのレコードの一覧画面や詳細画面、追加画面、編集画面をReactで刷新しています。
1週間1スプリントのスクラム開発を行っていて、毎日の朝会に加えてプランニングやリファインメント、レトロスペクティブなどを行っています。これらのミーティングにも参加させていただきました。
最初の2週間はチームの先輩とSlackのハドルを繋いで環境構築をしたり、1つのタスクを完了するまでの一通りの流れをペアプロで教えてもらったりしました。
その後は基本1人でタスクを進めていき、詰まったらSlackで聞いたり、必要に応じてハドルを繋いだりしていました。僕が行ったタスクをいくつか紹介します。
レコード編集画面の画像サムネイル表示
添付ファイルフィールドにファイルを添付したときに、サムネイルを表示できるようにしました。サムネイルを表示できる条件が複雑だったので、思ったより時間がかかってしまいました。
僕のチームではTesting LibraryとVitestでインテグレーションテストを書いていて、QAエンジニアの方に作成してもらったテストケースを実装します。テストの書き方自体は知っていたけど実際に書いたことはそんなに多くなかったので、書くことができてよかったです。
kDSチームとの連携
kintoneではkDS（kintone Design System）という社内デザインシステムを利用して開発をしています。kDSについては以下の記事を参照してください。
kDSのコンポーネントを用いて開発をしていると、時々実装したいUIが既存コンポーネントでは対応し切れない場合があります。そういった場合にはkDSチームと相談をし、コンポーネントの改修や代替案を一緒に検討するのですが、僕も今回いくつか相談させていただきました。
例えばTextButtonコンポーネントでは、今まではボタンの中身にテキストしか入れることができず、アイコンを入れたい場合に利用することができませんでした。今回このコンポーネントにアイコンとテキストを一緒に入れたいユースケースが現れて、kDSチームに相談をしました。
他にもMenuコンポーネントについての機能要望をまとめて相談したりと、kDSチームとのやり取りを通じてデザインシステムの運用や改善プロセスを体験することができました。僕はデザインシステムやアクセシビリティなどに興味があるので、今後デザインシステムの意思決定の部分をもっと知っていきたいと思っています。
インライン編集
kintoneのレコード一覧画面にはインライン編集という機能があります。テーブルのレコード行で編集ボタンをクリックすると、そのレコードをテーブル上で直接編集できます（一部対応していないフィールドもあります）。フロントエンド刷新にあたり、通常表示モード（下記画像の1行目）とインライン編集モード（下記画像の2行目）の切り替えやテーブルの各フィールドのセルを編集可能にする部分など、基本的なところから僕が実装を行うことになりました。
新たに実装する量が多かったので、開発は以下のような流れで複数Pull Requestに渡って実装しました。
- インライン編集のモード切り替えをできるようにする
- 編集した値の保存処理やデータの変換処理を書く
- 各フィールドを編集可能にする
編集画面で既に保存処理などが用意されていたのでそれを流用すれば大体できたのですが、それでも全フィールド分のデータ変換処理を書いたり、フィールドの編集権限があるかどうかの確認を行ったりと、考慮しなければならないことが色々あって大変でした。特に最初は実装方針に自信がなかったので、最低限動くようにしたところで一旦レビューをお願いして方針の修正を行ったり、できるだけ手戻りが少なくなるように意識して実装を進めました。
上記の3ステップがそれぞれ1週間ずつくらいで終わり、同時進行で他のエンジニアメンバーにも関連タスクを進めてもらいながら、一通りインライン編集機能を実装することができました。
またインライン編集以外にも、レコード一覧テーブル上にテーブルフィールドを表示する実装を、先輩とのペアプロやデザイナーチーム・デザインテクノロジストの方々などと相談して実装することができました。
反省点としては再レンダリングの抑制等、パフォーマンスの観点であまり良いとは言えないコードを書いてしまっていたことです。そのため、後から他のメンバーに改善していただくことがありました。今後はパフォーマンスについても意識して実装していきたいなと思いました。
感想
最初は、リリースがしばらく先の画面の実装をメインでやらせてもらっていたので時間をあまり気にせずゆっくり開発を進めていたのですが、途中からは他のメンバーと同じような本流のタスクをやらせてもらいました。インライン編集という重めのタスクを進めることで、大きなプロジェクトでどのようにファイル分割がされていてどのように状態やデータの管理・変換が行われているのかを知ることができて面白かったです。
上記のタスクの他、Frontend Weeklyの記事執筆やkintone認定 アソシエイトの取得なども行うことができました。それ以外にもkintoneのフロントエンド刷新を行っているエンジニアで集まるイベントや、サイボウズの開発・運用に関わるメンバーが一斉に集まる「開運まつり」などにも参加させていただき、楽しく他のメンバーとの交流をすることができました（リンクは過去の開催記事です）。
また、kDSチーム及びデザイナーチームとの連携や、Frontend Weeklyなどを通したフロントエンドエキスパートチームとの交流などもできて、とても楽しかったです。
実は、内定者バイトとして参加する前はkintoneを実際に使ったことはあまりありませんでした。しかし、社内でも色々な用途で使われていたり、11月に参加させていただいたCybozu Daysでも様々な企業様に使っていただいていることが分かったので、正社員として入社後も開発に貢献できるように頑張りたいと思います。
生産性向上エンジニア 星にゃーん
生産性向上エンジニアとして4月に入社する、星にゃーんです。
生産性向上チームは、サイボウズの開発者がスムーズに開発を進めるための基盤開発・運用をはじめとする、生産性向上のための様々な支援を行うチームです。
生産性向上チームの内定者アルバイトとして取り組んだタスクと、その取り組み方について紹介します。
主なタスク
社内向けリバースプロキシのAWS移行
生産性向上チームでは、社内のエンジニアに手軽なHTTPS環境を提供するリバースプロキシを運用しています。
このリバースプロキシとDNSはオンプレで動いており、システムの老朽化が運用上の負担になっていました。
そこで、社内向けリバースプロキシのAWSへの移行を行っています。
上述の記事にもある通り、リバースプロキシとDNSのデータはkintone上で管理されています。
kintoneで管理しているデータをAWSに同期するロジックの整理に貢献しました。
FourKeys基盤の改良
社内向けに提供しているFourKeysダッシュボードの性能改善に取り組みました。
Google CloudのBigQueryを利用したデータベースの設計を見直し、クエリコストを削減しました。
生産性向上チームのtakamin55さんが、以下の記事でクエリコスト削減の詳しい内容を解説しています。
zenn.dev
取り組み方
生産性向上チームでは、13:30-17:00の時間帯をモブプログラミングに充てています。
25分ごとに5分の休憩を取るポモドーロ・テクニックを採用し、各ポモドーロごとにドライバーを交代しています。
基本的に生産性向上チームのタスクはモブプログラミングで進めているため、AWSやkintoneなど背景知識が必要なタスクも、チームメンバー同士で細かく情報共有しながら取り組めます。
そのため、特に知識の不足を負担に感じることなく、スムーズに業務に取り組めました。
また、午前には「探求タイム」と呼ばれる、自由な学習時間が設けられています。
この時間をうまく使って、社内研修の資料を読んだり、AWSなどの技術について学ぶことで、効率よく業務に必要な知識をキャッチアップできています。
感想
色々な事情が込み入った結果、10月から3月まで内定者アルバイトとして働くことになりました。
人事やチームの方々には、素早く検討、受け入れをしていただき、感謝しています。
4月からの社会人生活がとても楽しみです。
プロダクトデザイナー こばりょー
こばりょーくんは少し早めに内定者アルバイトを終了したため、別で書いてもらいました。 以下のURLから閲覧できるので、ご覧ください！ note.com
QAエンジニア すずりん
自己紹介
QAエンジニアとして内定をいただいたすずりんです。
入社前に業務への解像度を高めてJSTQBのFoundation Level資格取得に向けた勉強をしたいと考え、内定者アルバイトを希望しました。
6月よりオンラインでの内定者アルバイトを開始し、現在は週三回・午後にGaroon開発のQAエンジニアが所属しているSpicaチームに参加して不具合の再現確認を行っています。
内定者アルバイトで行ったこと
1.研修
内定者アルバイトを始めてすぐの期間はGaroonチームで研修を受けました。研修ドキュメントは整備されていて、効率よく業務に必要な知識を学ぶことができました。
研修では、実際にGaroonを構築して、Garoonの機能について学ぶ機会が多くあります。
Garoonにはパッケージ版とクラウド版が提供されているので、両方の環境を構築する練習をしました。
私は学校の授業程度でしかLinuxを使ったことが無かったため、パッケージ版の構築にかなり苦戦しました。
パッケージ版の構築は、Linuxサーバーを構築した後、Garoonをインストールします。
手順 : Linux環境にインストールする方法について
VMの作成・OSのインストール・サーバー設定と躓きポイントがたくさん詰め込まれていました。
コマンドやディレクトリの構造等、わからないことだらけでしたが、分報で相談するとすぐに先輩方が教えて下さり、操作を身につけることができました。
初回の研修時は環境設定～構築まで丸々2日かかってしまいましたが、現在は10分もあれば設定ができるようになりました！(未だにsystemctl start httpd.serviceを忘れるのは気を付けなければいけません)
2.不具合再現確認
不具合再現確認は、登録された不具合の再現に必要な条件を確認し、改修判断に必要な情報を埋めていくタスクです。
再現確認は画面上の操作だけでなく、APIの利用やリクエスト改竄が必要な内容もあり、PostmanやBurp Suiteを使用して検証を行いました。これらのツールの使い方・Webアクセスの仕組みについても学ぶことができました。
Postman公式サイト: Postman
Burp Suite公式サイト: Burp Suite
また、再現確認をする際には期待結果として正しい挙動を知っておく必要があります。似たような動きをする他のアプリケーションとのずれが無いかを確認する中でドメイン知識や「どういう箇所で不具合が起こりやすいか」を学ぶことができました。
3.ドキュメント・不具合報告作成
社内でGaroonを使っている社員のみなさんや、お客様から報告された挙動を確認して、不具合と判断した場合は不具合報告を記録する必要があります。
Garoonチームでは、すべての不具合報告が英語で書かれています。この記述が非常に難しかったです。どんな読み手でも同じ受け取り方をして、複数の解釈が生まれないようにするためには、様々な工夫が必要でした。
注意点はすでにドキュメント化されていましたが、実際に書いてみると多くの文法ミスをしてしまったり、日本語の表現をそのまま使うと別の解釈になってしまったりしました。初めて見る人の観点をもってセルフレビューすることに苦戦しました。
レビューを頂きながら修正を重ねましたが、新しい文章を書くとまた別のミスが出てくるので、入社後も課題の一つとして、意識して直していきます。
4.QAゼミ・勉強会への参加
Garoonチームでは月に一度、サブチームの活動を共有するQAゼミという取り組みがあります。
様々なチームで起こった事例について発表があるため、実際にそれぞれのチームはどのような分野の業務をしているのか、またどのような技術を使っているかを知ることができ、QAエンジニアとしてどのような業務に携わっていきたいかを考えるきっかけになりました。
社内の勉強会では24卒の先輩方の発表を聞く機会も多くあり、来年にはここまではっきりと根拠を持った判断ができるようになりたいと強く思いました。
ここに書いた内容以外にも、受入テストや不具合/仕様の判断等、Spicaチームの定常業務を幅広く経験させていただきました。
まとめ
内定者アルバイトを始める前は入社後のオンラインコミュニケーションに不安がありました。入社してからもチームの人や同期とコミュニケーションが取れるのか、自分だけ情報に取り残されないかというのが主な懸念点でした。
この不安を解消できたのは、分報形式で進捗を共有する仕組みのおかげです。質問をすることへのハードルが低く、先輩方がどのようなタスクを行っているかも見ることができました。
SNSをよく使用している私にとっては、行ったことをリアルタイムで文章に起こすことに慣れ親しんでいたのも大きな要因かもしれません。毎日の夕会や1on1を通じてチームのみなさんとコミュニケーションが取る時間をいただけたこともありがたかったです。
実際に操作をしたり業務をしたりして学ぶことで、ただ机上で勉強するよりもできることが増えていることを実感できたとともに、内定者の立場で自由に学ぶ時間をいただけたことは非常に貴重な経験でした。
この経験を生かして、資格取得に向けて勉強を続けつつ、入社後も根拠を持った判断ができるQAエンジニアになれるよう頑張ります！
総括
それぞれの記事は社内kintoneで内定者バイト体験記用アプリを作成し、そこにそれぞれのレコードの作成して記事の内容をまとめていました。そしてレコードのコメント欄で、互いに記事の内容についてレビューをしたり質問をし合ったりして記事を完成させました。
4月からはまた新鮮な気持ちで新人研修などを受講しつつ、内定者アルバイトで溜めた経験値を開発に活かしていけたらと思います。
