この記事は、CYBOZU SUMMER BLOG FES '25の記事です。
はじめに
こんにちは、kintone開発チームのkuraです。普段はkintoneのシステム管理画面や外部連携の新機能開発を担当しています。
私は2024年の新卒として入社し、現在のチームに配属されてから1年あまりが経ちました。学生時代はゲーム開発ばかりをしていて、入社時点ではほぼWeb開発素人だった私も2年目になり、学生の皆さんや社外の方と関わる機会も増えました。
その中でよくいただく質問が、「サイボウズの1年目は何をするのか」です。
そこで本記事では、私の1年目の業務を紹介し、どんなふうに業務に慣れていったか、そこで感じたこともあわせてお伝えします。
これまでに公開された同期や先輩方の1年目の振り返り記事も以下に掲載しておきます。あわせてご覧ください。
1年間の流れ
まず、1年目の仕事の概要を時系列で大まかに紹介します。
1~3ヶ月目
いわゆる研修期間です。入社直後はビジネス系も併せた人事研修、それが終わると開発本部の通称「開運研修」（開発・運用研修）が始まります。研修内容はオンボーディングチームが公開している以下の記事をご参照ください。
4~6ヶ月目
研修が一段落し、いよいよプロダクトチームに配属されます。モブプログラミングを活用しながらのオンボーディングで、膨大なコードのうち自チームで頻繁に触る領域について、より深い知識やコードの読み方のコツ、書き方の癖を学びます。私のいるチームは、普段はソロプログラミングを中心として動くことが多いです。しかし、レビューをゼロから行うより並走したほうが効率的な場合や、危険性の高い領域を扱う場合、あるいは今回のようにスキル伝達を目的とする場合は、モブプログラミングの恩恵が大きくなります。
加えてこの時期の私は、比較的新しい機能について、業務の合間に（先輩に一部教わりながら）ドキュメントをゼロから作成していました。最終的にコードを除いても約8000字と長くなりすぎたので、その後厳密さを落とした第2版も書いたりしました。この取り組みは領域理解やコードへの慣れの意味で、かなり効果があったように感じています。
7~9ヶ月目
小規模なタスクはソロで、影響範囲の広いものは先輩とモブで進める、という進め方に移行します。また、お客様からの問い合わせに関するコードやログの調査にも携わるようになります。
この頃はコードベースに慣れ始めたこともあり、特にテストコードの改善活動に力を入れていました。テストコードは望ましい挙動を定義したものであるため、内部的な機序や例外処理など、製品仕様をインプットすることにも繋がりました。
9~12ヶ月目、及びそれ以降
徐々にソロで取り組むタスクの規模が大きくなっていきます。難易度というより複雑さに応じて、ソロとモブを使い分ける、本来の弊チームに近い動きができるようになってきました。また、学生イベントなど採用活動の一部にもエンジニア社員として関わるようになります。
私が初めて「設計段階から開発に貢献できた」と思えたのはこの時期の新機能開発でした。既存実装を踏まえ、再利用可能な処理を探せたり新規の実装を適切に分割できたり、といった感覚がきちんとついてきたのはこの辺りでした。
1年目で得た学び
上述のような1年を過ごしたわけですが、学生時代の個人開発と比較すると、開発チーム全体としてさまざまな場面で工夫を施していることがわかりました。
「デカさ」に立ち向かう工夫
説明不要ですが、プロダクト規模がデカいです。チームもデカいです。リポジトリもデカいです。
ある機能について知ろうとして「で、この機能のコードはどこに……？」となる瞬間は今でもあります。ある機能を改修しようとして「で、この改修ってちゃんと意図しない変更引き起こさないよね……？」と不安を感じる瞬間もあります。
そのような規模に耐えるため、さまざまな工夫がされています。基本的なところでは、Linter、自動テストの整備といった、個人開発のレベルでも実施できるような対策は徹底されています。これらを欠くと仕事が回りません。学生時代の私がなかなか徹底できなかったことでもあり、基礎的な対策の大事さを痛感しました。
そのうえで、大規模開発特有の工夫もたくさん行われています。
影響範囲を抑えるためのアーキテクチャ導入、意図せぬ変更を検知するためのCIやVRTの充実、CIの実行時間を抑えるためのUIテスト削減……小規模開発ではコスパの悪い対策でも、この規模のプロダクトに導入すると十分なリターンがあることを実感する、1年目はその繰り返しでした。
仕様変更の影響を抑える工夫
B2Bプロダクトであるkintoneは、さまざまな規模、さまざまな属性のお客様に、安定した体験を提供する必要があります。また、kintone本体の仕様に基づき開発され、多くのお客様に利用されているプラグインも多数存在します。本体側の仕様変更はこういったkintoneに関わる全ての人に対し、影響が及ぶ可能性があります。したがって、大幅な仕様変更には慎重にならなければなりません。
その中でも継続した機能追加や開発を行うための工夫として、例えば「アップデートオプション」があります。ある機能が実装され正規の仕様となる前に、お客様側で該当機能を無効化できる仕組みです。現在、kintoneの新機能のほとんどはこのアップデートオプションを利用し、期限を予告した上で徐々にデフォルト化されていきます。この手法を取ることで、お客様側では急激な仕様変更を回避でき、開発チーム側では機能がデフォルトになる前からフィードバックを得られる状態を実現しています。
作り込む前にフィードバックを得る重要性はよく語られますが、明らかに発展途上な状態の機能をお客様に提供するわけにはいきません。その制約下でも段階的なリリースを実現する方法として、いわゆる機能フラグ的な考え方は、入社時点の自分にとっては驚くべきものでした。猶予期間を設けつつ機能をリリースする、そんな仕組みの開発は、個人開発の範疇ではなかなか実践しないものでしょう。
1年目で感じた課題
さて、ここまでは学びに焦点を当ててきました。
一方で、当然改善の余地があると感じた点もありますので、いくつか挙げてみることにします。
実行時間のかかる巨大コードベース
学びの項でも触れましたが、kintoneのリポジトリは巨大です。開発中にローカルでkintoneを立ち上げようとすると、特にバックエンドの修正時には結構な時間がかかります。1つ値を修正したい、1つロジックを試したい、そんな軽微な検証のために数分待つこともあります。
待ち時間の問題は自動テストにおいても現れます。UIを用いたテストでは実行結果が不安定になってしまい、ただでさえ時間がかかるテストの複数回実行が必要なこともあります。これに関する改善の取り組みは本リレーブログの別記事にて触れられているので、そちらの内容をご参照ください。
避けられないコミュニケーションコスト
kintone開発チームでは、機能領域ごとに組まれたサブチームが該当のコードを管理しています。これにより認識負荷を抑え、各チームがその裁量の下で手を加えやすい状態を作っています。
しかし、領域Aの機能aを実装するにあたり、領域Bに機能bが実装され、aはbを利用する形で実装されることが望ましい、そんな場面もあります。本来領域Bに属するべき内容が領域Aで実装されることを避けたいからです。
こういった場面では、領域Aのチームから領域Bのチームに機能追加や修正の依頼を投げ、領域B側で着手されるのを待ち、実装されたのを確認したのちに領域Aで再度作業を始める、そんな流れが必要になります。
また、様々な理由から領域Aのディレクトリに領域Cのコードが混ざっている、ということも発生し得ます。特に一部のフロントエンドでは、ライブラリのアップデートごとに、他チームとのコミュニケーションコストが発生しています。
定期的に訪れるコード考古学
長期運用のコードベースには、新しく参加した人の理解を阻む壁がいくつもあります。いわゆる「歴史的経緯」によって非自明な処理が書かれていたり、時期によって書き振りや採用されているライブラリが変化したり……
ドメイン知識を深めていくことで解消できる部分もありますが、とはいえ限界があります。その点では、モブ文化がうまく効いているようにも感じました。まさに運用でカバー、という感じですね。（あまりよくないことですが……）
しかし一部のライブラリは、もはやインターネット上に情報が残っておらず、社内ドキュメントが閲覧可能な最も詳しいドキュメントだったり、そのドキュメントが既に失われていたり、既存のプロダクトコードを参考に読み解かなければならなかったりという場面もありました。
それらのライブラリは徐々に置き換え作業を行なっていますが、移行作業にあたって過去のコードと対峙するのは結構大変です。まあ、その分理解できた時の達成感はひとしおなので意外と楽しかったりするんですが……
おわりに
さて、長々とつらつらと1年目のお仕事を振り返ってみました。目新しい話や突飛な話ではなかったかもしれませんが、サイボウズの風景を何となくイメージしていただけたでしょうか。新人の等身大の感想（いい表現ですね）として、読みづらい点はご容赦いただけると幸いです。
まだまだ知っていることより知らないこと、出来ることよりも出来ないことのほうが多いと感じる毎日ですが、次はもっと技術や実装に寄った話で寄稿できるよう、ネタを集めて研鑽を積んでこようと思います。
