サイボウズで内定者アルバイトを始めて１ヶ月経った話

Swift SwiftUI iOS 内定者アルバイト

１. はじめに 📕

こんにちは！サイボウズ 2026年度新卒で今年の４月からiOSエンジニアとして内定者アルバイトをしています。ちゃんくろです！ 今回は４月から１ヶ月が経って、内定者アルバイトでどのようなことをしたのかを振り返る機会があり、そこでこれまでに取り組んできたことについて記事にすることになりました。

ⅰ. 内定者アルバイトをすることになったきっかけ

内定をいただいたときにはSwift歴が１年未満だったというのもあり、純粋な技術力の懸念は個人的に大きいと感じていました。個人開発では特定のアーキテクチャをメインに一定のレベルで頭打ちになってしまっているような意識がありました。そこで人事の方を通して上長の方と内定者バイトに関しての話をする機会をいただきました。内定者バイトという形で、技術力を新卒のタイミングまでに即戦力レベルまで底上げを行うことや、チームの方とのコミュニケーションを問題なく取れるようになることなど目標に業務に入ることになりました。

2. 実態 💻

実際にサイボウズで内定者アルバイトをするにあたって働き方や実際に取り組んだタスクなどの実体を後述できればと思います。

ⅰ. 働き方 🧳

  • 大学の研究等があるため週3日, 1日7時間稼働

実際に稼働を始めるにあたって、チームの方や上長の方がとても丁寧に対応してくださり、無理なく予定を組むことができました！

ⅱ.タスク 📝

ⅲ. 学び 🎓

基本的にサイボウズではキャッチアップやOSS活動を業務時間内に行っても良い文化があり、Issueの消化中に見つけたOSSの修正点をその場で解消することができます。 僕自身これまでOSSコントリビューション未経験だったため、実際に取り組む際にはとても得るものが多かったと思っています。 その中でもTCAに関するものでは多くの学びが得られました✏️

a. TCAコントリビュートの中で 🏹

内容としてはTCAをキャッチアップする際に取り組んだTutorialに不備があったためその修正案を出したというものです。TCAではいくつかのアップデートや破壊的変更などがこれまで行われており、Tutorialが最新の内容に対応しておらず、ビルドが通らないなどの問題に対する修正でした。

Apple関連のドキュメントではよくDocCというドキュメントコンパイラが使われます。

実際にDocCが表示されている画面
TCAについて説明しているDocCの一部
上記のように変更箇所がわかるようにハイライトがつけられるのですが、これがとても厄介でした。 と言うのも、修正箇所がわかるように前後のファイルが必要であるため同じ内容が記載されたファイルを作成する必要があったり、どのタイミングでどのような修正を行うのかを理解していないと修正の意図が読めないドキュメントになってしまったりするためです。

具体的に、TCAにコントリビュートする中で以下のようなことを学んだのでそれを後述しようと思います。

  • TCAの何が良いのか
  • 逆に何が良くないのか

TCAでは他のアーキテクチャと比べるとテストやプレビューの作成を行う面で大きなメリットがあると言われています。実際にTutorialの再現や小さいプロダクトを作成する際にDIを行う際のモックの差し込みやすさは普段、個人で開発する時と比べてとてもスムーズに行える印象でした みなさんが個人開発でテストを書くことはない場合でもPreviewを作成する際に行うDIで十分利便性を享受できると思います。

では逆にどのような良くない点があるのでしょうか？ おそらくそれは、キャッチアップコストでしょう。 TCAはこれまでアップデートが盛んでその中には破壊的変更も少なくはありません。実際に自分がキャッチアップをしていく中で、出回っている記事はほとんどが古い書き方で公式のドキュメントを見ても追いついていない箇所が思っている以上に存在しました。もちろんAIは古い情報しか知らない。という中で新しく、正しく動くコードを見つける作業は良い体験とは言えません。しかしその分サンプルコード数は充実しているので最新のドキュメントを少し古い書き方をしているサンプルプログラムに適応させていく形を取ることで十分対処可能ではあると思います。

僕がここまでで学んだ内容はおそらくTCAに関しての知識のうち半分にも満たないと思います。そのためまだまだ足りない部分はありますが、それでもTCAを利用する価値はあるのではないかと感じました。 OSSにコントリビュートすることで普段の開発とは違った刺激を受けることができたのでモチベーションの維持にはとても効果的だったと今振り返って思います。 もし、新しい業務先でTCAを使っていてキャッチアップが必要な場合はTutorial以外にもコントリビュートしてみることをお勧めします！

b. テストのマイグレーションを行う中で✈️

はじめに自分が担当したタスクはXCTestからSwift Testingへのマイグレーションでした。 個人開発や、これまでの実務でテストを書くことはほとんどなかったためiOSにおいて業務レベルのテストを見るのは初めてでした。このような場合、マイグレーション前のテストを見ながらマイグレーションを行うことが多くなるのではないでしょうか？ そうすると、プロダクトコードに対する理解が浅いままでもテストが通ってしまう、という状況が発生します。僕の場合はまさにその通りでした。 この場合何が誘発されるかというと元々確かめたい事象への理解が半端であるためテストの内容が気づかないところで変わってしまう可能性があります。そうなると偽陰性（壊れているのにテストが通る）や偽陽性（壊れていないのにテストが落ちる）を引き起こすきっかけになり得ます。また、なぜテストが落ちているのか。なぜテストが通っているのかを正しく理解できていないためマイグレーションにおける記法以外何も学びを得られない機会になってしまいかねません。 そのため、プロダクトコードへの理解はどのようなタスクであっても長期的に見た場合には必須になると感じました。

3. 課題 📚

これまで、つらつらと成功体験的なものをメインで記載してきましたがその反面課題も浮き彫りになってきた１ヶ月でした💦

  • プロダクトコードへの理解の不足
  • アーキテクチャに関しての理解の不足
  • テストに関しての理解の不足

上記の課題に対して、もちろん時間をかけて消化するIssueを増やす。みたいな体育会系的思考は必要だと思います。ただ、それだけでなく、テストを書く際にプロダクトコードから何を確かめたいのかを把握したり、Issue消化の際には周辺コードを理解するといったような目標を立てながら進めていきたいと思います！