こんにちは、フロントエンドエンジニアのmehm8128です。 僕は25卒としてサイボウズに新卒入社し、内定者アルバイト時代も合わせると1年半なのですが、正社員としてはちょうど1年が経ちました。弊社1年目ではどんなことができるのかという参考に、書いてみました。
フロントエンド基盤の刷新
サイボウズのほとんどのフロントエンドエンジニアの多くは、主力製品であるkintoneのフロントエンド基盤の刷新プロジェクトに参加しています。 普段は個人としてアクセシビリティに関する発信を多くしていることから、業務でもアクセシビリティ関連のことをメインでやっていると思われていることがあります。しかし実際には、フロントエンド全般に幅広く関わっています。
今のkintoneの大部分は、Google Closure Toolsというフレームワークで作られています。しかしこれは2024年にEOLになったこともあり、今では「Google Closure Toolsといえばサイボウズ」と言えるくらい他で見ないものになってしまいました。そこでフロントエンド基盤の刷新プロジェクトでは、kintoneを全てReactに置き換えています。
その中でも僕のいるチームはkintoneのアプリ機能という、kintoneの中でも最も基本的な機能の刷新を行っています。アプリ機能の画面では、ユーザーがシュシュっと作成したアプリに対してレコードを追加したり、そのレコードの一覧や詳細情報を閲覧したりすることができます。
もう少し詳しい説明は過去の記事をご覧ください。
現在のチームのメンバー構成としては、EM1人、SWE5人（自分はここ）、QA2人となっています。多いときは内定者アルバイトメンバー含めてもう4人ほど所属していました。
内定者アルバイトのメンバーを除くと自分は最年少ですが、フロントエンド基盤の刷新はやることが多く、かつなるべく最短で完了することが求められていることから、新卒1年目の自分でもタスク管理や内定者アルバイトメンバーのサポートを行うことが多くあります。それ以外は、与えられたタスクやコードレビューをひたすらこなしたり、必要に応じて他チームとの連携を図ったりしています。
ここからは具体的な業務内容をいくつか紹介していきます。
インライン編集機能の実装
前述の内定者アルバイト時の記事にも記載したのですが、インライン編集は僕がメインで実装した大きい機能のうちの1つです。 レコード一覧のテーブル行で編集ボタンをクリックすると、テーブル上でそのレコードの情報を編集できます。記事にも書いたのですが、モード切り替え、各フィールドのUI配置、編集した値の保存処理、データの変換処理という複数の作業が必要で、規模が大きいタスクでした。
kintoneはアプリのフォームに様々な種類のフィールドを配置することができ、それぞれ特徴が違います。例えば以下のような特徴を持つフィールドがあります。
- 値を編集できるフィールド
- 例：文字列（1行）フィールドやユーザー選択フィールド
- 値を編集できないフィールド
- 例：ラベルフィールドや作成者フィールド
- フィールドの中にフィールドを入れられるフィールド
- 例：テーブルフィールドやグループフィールド
- 編集画面では編集できるけどインライン編集では編集できないフィールド
- 例：添付ファイルフィールドやルックアップフィールド
これらを踏まえて、編集できないときの表示や、そもそもテーブル上に表示しない場合、通常は編集できるけど特定のユーザーには編集権限を与えられていない場合、などを意識しながら実装する必要がありました。もちろん全部1人で実装したわけではないですが、基盤部分は僕が実装したのでkintoneのアプリ領域の複雑さを体験できる良いタスクでした。
グラフ設定ダイアログの実装
グラフ設定ダイアログは、半年ほど前に実装したものです。こちらも多くの部分を僕が実装しました。 kintoneでは、アプリに登録されたレコードの情報をグラフ形式で閲覧することができます。レコード一覧画面・レポート画面の「グラフを設定」ボタンをクリックして開くダイアログ上で、グラフの種類や集計に使うフィールド、絞り込みなどの設定をすることができます。
アプリ設定画面でも同様のグラフ設定画面があり、そちらは既に他チームが実装済みだったので、中心となるロジックはそちらから取ってくることができました。しかし、アプリ領域の仕様・既存コードとの整合性を取ったり、URLのパラメータから取得した初期値をグラフ設定ダイアログ用に変換して適用したりする作業にかなりの時間を費やしてしまいました。 反省点としては、もう少しコンポーネントテストやロジックの単体テストを多く書きながら進められると良かったのかもしれません。ちなみに最近『単体テストの考え方/使い方』を読んだので、個人的にフロントエンドテストについてもう少し探求してみたいと考えています。
デザイナー・デザインシステムチームとの連携
チームの中でも、僕はデザイナーチームやデザインシステムチーム（厳密にはデザインテクノロジストという、デザインシステムに限らず開発チームとデザイナーチームとの橋渡しをする役割を持っているチーム）との連携を取ることが多いです。僕がロジック寄りの領域よりも、HTMLやCSS、アクセシビリティなどUI方面の領域に興味を持っていることから、いつの間にか自分がこの役割を担うことが多くなっていました。
具体的な例として、定例ミーティングを紹介します。
週1で30分、僕が所属する本体開発チームに加えてデザイナーチーム、デザインシステムチームの3チームから一部のメンバーが集まって合同でミーティングを行い、アプリ領域の開発を進める上での相談事を持ち込んで議論しています。 例えば本体開発チームからは、以下のような議題を持ち込むことが多いです。
- デザイナーさんに作ってもらったデザインを実装する上で技術的に難しく、妥協案を相談したい部分
- 少し複雑なインタラクション実装において、アクセシビリティを確保するための実装方針
- 既存のデザインシステムのI/Fのままでは実現するのが難しそうな箇所
逆にデザイナーさんからはデザイン上の相談をデザインシステムチームに持ち込むことが多いのですが、そのときに本体開発チームとしてそのデザインをどれだけのコストで実現できそうかという情報提供を行うことがあります。
もちろん本来はデザインシステム自体に関する相談以外は、本体開発チームとデザイナーチームとの間で議論を完結させられることがベストです。しかし、フロントエンド基盤の刷新は新機能実装ではなく既存の仕様の踏襲が求められるため、本体開発チームとデザイナーチーム間のコミュニケーションに時間がかかってしまうことがあります。そのため、デザインシステムチーム（デザインテクノロジスト）に橋渡しをしてもらうことでスムーズな連携を実現できています。
詳しくは以下の記事をご覧ください。
こういったミーティングを経て、個人的な課題として、去年はデザイナーさんの目線でUIを検討したり議論したりするということがあまりできていなかったという感覚がありました。そこで今年は、デザイン系のインプットを増やしたりデザイナーさんの考え方への理解を深めたりして、より迅速で効率的なコミュニケーションを取れるようにし、製品価値を高めていきたいと考えています。
JSAPIの実装
kintoneにはJavaScript API（JSAPI）という機能があります。
例えば以下のようなメソッドを実行したり、イベントハンドラーを登録したりすることで、ブラウザ上でJavaScriptからkintoneの画面を操作するAPIを実行できるようになっています。これはカスタマイズやプラグインを作るときに利用できます。
// 開いている画面のアプリのIDを取得できる window.kintone.app.getId();
// レコード追加画面を表示したタイミングでイベントを発火させることができる window.kintone.events.on("app.record.create.show", (event) => { // フィールドの値を書き換えることができる event.record["フィールドコード"].value = "値"; return event; });
React刷新では単純に画面上の機能を実装するだけでなく、このようなJSAPIの実装も行っています。2026年3月時点でアプリ領域で使うことができるJSAPIは120件以上あり、全画面共通のもの以外は僕たちのチームで実装しています。 特に最近半年ほどで、画面上のボタンの表示・非表示を切り替えられるようなJSAPIなどが新たに現行の画面でたくさん実装されたので、刷新後の画面でもそれに追従する必要がありました。
例として僕が実装に関わったJSAPIを1つ紹介します。
kintone.app.record.setFieldShown(fieldCode, isShown)というsetter系のJSAPI及び、それに対応するgetter系JSAPIであるkintone.app.record.isFieldVisible(fieldCode)があります。これはレコード追加・編集・詳細・印刷画面で利用できるJSAPIで、各フィールドの表示・非表示を切り替えられます。
それだけ聞くと一見単純なJSAPIのように思えますが、実はそうではありません。
箇条書き形式でこのJSAPIの仕様の一部を紹介します。
- 前述の「フィールドの中にフィールドを入れられるフィールド」であるグループフィールド自体を非表示にすると、その中に含まれているフィールドも非表示になる
- よって
isFieldVisible()で、グループフィールドに含まれているフィールドかどうかの確認が必要 - テーブルフィールドも同様
- よって
- DOMごと消してしまうのではなく、CSSの
display: noneなどを使ってDOMを保持したまま非表示にしなければならない- なぜなら、
kintone.app.record.getFieldElement(fieldCode)というJSAPIで要素を取得してDOMを書き換え、setFieldShown(fieldCode, false)で非表示にし（DOMを消し）、再度setFieldShown(fieldCode, true)で表示すると、一度DOMを完全に消している影響で、書き換えた内容がリセットされてしまうから
- なぜなら、
- 2026年2月版リリースから入った機能追加で、ラベル・罫線・スペースフィールドにも対応した
- これらは引数としてフィールドコードを指定するのではなく、別概念の「要素ID」というものを指定する必要がある
- しかし、フィールドコードでも要素IDでも第一引数に指定するので、実装側で値を受け取るときはどちらとして指定されたのかが分からない
- フィールドコードは一意だが、フィールドコードと要素IDは衝突する可能性があるので、その場合にはフィールドコードを優先して処理する必要がある
- そしてこれらの計算に使うデータ構造は複雑（ref：kintoneアプリ領域で扱う巨大データ）
- などなど...
このように、色々なことができる便利なkintoneだからこそ、フロントエンドのロジックは複雑で様々なことを考慮して実装しないといけません。今回は単体テストを書きながら実装を進めたので比較的早い段階である程度の不具合や考慮漏れには気づくことができたのですが、後から見つかった不具合もいくつかあり、kintoneにおけるテストの重要性を痛感しました。
モバイル版の実装
kintoneのモバイル版はページが分かれているので、PC版とは別で作る必要があります。 しかし、モバイル版は基本的にPC版にある機能が削られただけのもので、一部挙動が異なるくらいです。去年の12月中旬くらいに着手したものだったので、ちょうどAIの使いどころでした。デザイナーさんに作ってもらったFigmaのスクリーンショットを貼り付けて、「PC版の機能をこのスクショ通りにモバイル版に移植して」といったプロンプトを打つだけで、Claude Codeが大部分の実装を行ってくれました（人間2人で作業を進めました）。
細かい部分は人間の手で直したり機能追加したりしつつでしたが、PC版の全画面を1ヶ月程度でモバイル版に移植し終えました。その後はQAさんの試験で見つかった不具合を取り除いたり、後回しにしていたモバイル画面におけるJSAPIを再びAIの力を借りながら追加したりしています。
今まで個人的にはAIをあまり使ってきませんでしたが、チーム内でドキュメントの整備やSkillsの整備などを進めており、AIの効果的な使い方を学ぶいい機会になりました。kintoneのフロントエンド開発におけるAI活用については、以下の記事をご覧ください。
フロントエンド基盤の刷新まとめ
新卒で入って、kintoneという大規模プロダクトの最も利用される領域の開発に関われているのは、とても大きな経験です。レガシーならではの辛みや複雑な仕様・データ構造と向き合わなくてはならない場面が多いですが、そこをいかに上手く設計し、保守性なども考えながら実装を進めるかということを考えるのは楽しいし、なかなかできない経験であると思います。 また、UIをそのまま移行するのではなくて、より使いやすいデザインにしながら移行しているので、デザイン的な観点でもデザイナーさんと一緒に考えることや、よりアクセシブルな実装を考えながら開発を進めることが多くあります。ここは特に自分の得意・興味のある分野なので楽しく進めることができた上で、まだ自分に足りない部分に気づくことができて成長のきっかけにもなっています。 ちなみに内定者アルバイト期間も含めた1年半で、400件以上のPRをマージできたようです。
フロントエンド基盤の刷新自体はまだもう少し続きますが、引き続き頑張っていきたいです。
探求・発信
サイボウズのフロントエンドといえば、探求・発信のイメージを持ってくださっている方も多いと思います。 半年ほど前に、サイボウズのフロントエンドエンジニアの探求活動についての記事を出しましたが、ここではそれ以外の探求・発信活動について紹介します。
例えばカンファレンスへの参加は探求活動の1つとして考えられると思います。 東京近辺のカンファレンスは、基本的に業務として参加可能です。これによって他社の業務内容や知らない技術について新しい知識を得ることができたり、界隈の人たちと繋がることができたりします。学生の頃はあまりカンファレンスやイベントには参加していなかったのですが、サイボウズの場合は特に登壇者側の立場で参加する先輩も複数人いるので、良い機会になっています。
また、去年1年間はサイボウズがW3Cに加入したことから、Web標準に対する探求活動が多くありました。 毎月投稿しているWeb 標準動向は、僕が発案して半年以上続いているものです。サイボウズがWeb標準に興味を持っていることを外部の人に知ってもらうきっかけになっているのはもちろん、執筆メンバーが探求を続けるモチベーションの1つにもなっています。これからも続けていきたいと思います。
関連して、TPAC 2025への参加もありました。日本での開催だったということもあり、対面参加とオンライン参加を合わせて10名程度のメンバーが参加できました。 僕はサイボウズに入るまでWeb標準についてほとんど知らず、W3Cといえば「WCAGやARIAの仕様書などで名前を見るもの」くらいの認識でした。しかし、W3CやWeb標準に詳しい・興味を持っている先輩方の流れに乗って自分も参加することにしました。 その結果、GitHub上でのやり取りや、毎週のミーティングの議事録などでWeb標準の作られ方について知ることができたり、TPACにも1週間フルで現地参加させてもらってWebの仕様が決まっていく光景を生で見ることができたりしました。
詳細なレポートは以下の記事をご覧ください。
このように時間やお金を使って普段の開発業務以外にも様々な経験をさせてもらえるのは、自分たちのポテンシャルを信じて投資してくれるマネージャーの方々のおかげなので、学んだことをしっかり還元していきたいと思います。
まとめ
1年半働いてみて、サイボウズはフロントエンドエンジニアとして働く上でとても良い環境だと感じています。 基本的なUI機能の実装から他チームとの連携、モバイル版対応、JSAPIという他社ではあまり触れないような機能開発など、1年半で色々なことを経験させてもらいました。少し機能開発から離れると、様々な専門性を持ったメンバーと一緒に、業務の一環として探求・発信活動も行うことができています。
2年目以降はさらに成長しつつ、周りにも良い影響を与えられるように動いていきたいです。
