kintone 新機能開発チームに 23 新卒で入った、エンジニアの宇都宮、柿崎、宮村、和渕、デザイナーのかやです。
23 新卒として一緒に入社した他チームの同期から、kintone 開発について聞いてみたいことを募集しました。
その中からいくつかピックアップして、みんなで答えていきました！
以下のような方の参考になると嬉しいです。
- サイボウズに興味を持ってくれている就活生
- 24 卒・25 卒で kintone の開発に興味を持ってくれている人
- 配属で kintone 新機能開発を希望するサイボウズの新入社員
質問
質問 1 : kintone と他チームを比べて特徴的だなと新卒目線で感じていることは何ですか？
質問 1 : kintone と他チームを比べて特徴的だなと新卒目線で感じていることは何ですか？
モブプログラミング
和渕：これはモブプログラミング。モブプログラミングの時間多いねって他の同期に言われた。他チームと比較すると、長いんだと感じた。
領域ごとのチーム分割
宮村 : ユーザーの動線ごとに、チームが分かれているっていうところも特徴的だなと。
かや : 質問なんだけど、エンジニアが領域ごとにチームを分割しているのってなぜ？
和渕 : 1 つは、認知負荷を下げる目的がある。あと、自立性を高めて、価値提供のスピードを上げる目的があるね。
この記事がわかりやすいかも。
speakerdeck.com
宮村 : あと、担当範囲が狭いからこそ、その分野にフォーカスすることができて、その領域の専門になれるっていう側面もあるなと感じた。
新機能開発ができる
宇都宮 : 他チームでここまで新機能の開発してるとこってあんまりないかも。
和渕 : ユーザーにダイレクトに届く新機能開発ができるっていうのは嬉しい。
柿崎 : SNS で自分が開発した機能にポジティブな反応を見つけたときは嬉しかった。そういうのも kintone 新機能開発ならでは。
和渕 : こんな魅力的なチームがあっていいんでしょうか。
質問 2 : 1 年を振り返って 1 番大変だったことは何ですか？
質問 2: 1 年を振り返って 1 番大変だったことは何ですか？
リリースのプロセス理解が大変
和渕：リリースのプロセスが 1 番大変だった。提供環境が複数あるし、提供順のルールもある。そこに、アップデートチャネルの概念もあるし、把握が難しい。今でもドキュメントを見返すときがある。
「アップデートチャネル」っていうのは、以前は新機能が適用されるタイミングが一律で月一度だったのが、2023年5月以降「アップデートチャネル」の「最新チャネル」か「月例チャネル」を選択することで、新機能を使えるタイミングをユーザーが変えられるようにした機能だね。
アップデートチャネルについて
柿崎：いまだにちゃんとわかってるか微妙。リリース担当の方の仕事も複雑そう。
宮村：確かに複雑。ただ、今社内で改善の動きが起こっている。
リリースのやり方がより自由になっていくと思われるので、逆に考慮すべき点は増えそうな気がしている。
例えばデスクトップ通知とか。お客様の反応を見ながらリリースしたい機能だったので、一部の環境のみに先行提供してみたり。考えることが多かった。
和渕：考えることが多いことに対して、進め方でそこを軽減していった感じ？
宮村：決めの問題の調整が難しかった印象かな。
判断の難しさ
宇都宮：サブチームも裁量が大きいのは感じてて、その中で判断基準となるユーザー像がないから、実装時の判断に自信持てない。ベテランの人もそうだと思うけど、それが 1 番大変。自分の判断がいいのか悪いのか評価が難しいってところ。
かや：自分たちも普段 kintone を使う 1 ユーザーだけど、それで理解できてるのってエンドユーザーにとっての kintone のごく一部に過ぎなくて、情シスとかアプリ管理者とか立場が違えばよく使う機能や画面も違うし、価値を感じてもらえる部分も違う。だからそこを想像して判断するの難しいよね。
柿崎：今 React 化をやっていて、どこからやってくかという判断が難しい。大体先んじて React 化検証していたチームが大体優先順位を決めてくれているけど、自分のチームも担当することになって、何をどこまでやるかを自分たちで決めないといけないから、このフィールドはユーザーが何のためにどういう場面でどこまで作るのかっていうのが難しい。先輩の判断見てうまく判断できるようになりたい。
和渕 : みんな共通して、ユーザー像の把握が難しいっていうのがありそう。
柿崎 : いろんな属性のユーザーがいるからね。
質問 3 : 想定通りだったこと / 想定外だったことは何ですか？
質問 3 : 想定通りだったこと / 想定外だったことは何ですか？
機能理解が大変
和渕：kintone の全体感を掴むのは大変なんだろうな、と想定していたが、想定通り大変だった。
いつになったら kintone なんとなくわかったって言えるんだろうって今でも感じる。
柿崎 : 機能領域ごとにサブチームに分かれている。それでも、自分の領域でもわからないことはまだあるし、他の領域となるとわからないことが全然あって、確かにって思った。
チーム内でのタスクの進め方として、モブプロが中心だったのは想定通り。kintone 新機能開発チームならではの色だなと思う。
和渕 : エンジニアは機能領域ごとにチームが分かれていて、業務を進める上で理解するべきことの幅が限られているけど、デザイナーは領域分かれていない。kintone 全体を見ないといけない大変さとか難しさとかある？
かや ：「前に同じようなところのデザインを担当した人が継続して担当する」とかざっくりとした分担は部分的にあるけど、明確には分けてないので担当しうる範囲は基本全部。なので今は新しいタスクに取り組む度に該当する機能とか画面を理解するところから入っている。デザイン変えるとなった場合全体がわかってないと他の部分にどう影響するかを考慮しきれないから、それは難しいなと思う。
和渕 : エンジニアの自分の領域内ですら、こんな機能あったんだ、ってなるから、全領域見てるってことはその発生頻度が凄そう。
かや :特定の領域に特化していると、ユーザー像とか機能の使われ方がある程度限定される分想定しやすいとかある？自分の担当領域だったら結構理解できてる？
和渕 : 理解しているかどうかだと、まだまだ難しい。ユーザー理解の部分が特に乏しい。
宮村 : ユーザー理解は自分でも難しいなあと感じる。自分たちが必要だと判断したところが意外と必要なかったり、逆に、あまり使われないかな、と想定したところが重要だったり。
リリースのスピード感
かや : 新機能をリリースするときにしっかりユーザーテストしたりして徹底的に検証するイメージを持っていたけど、素早くリリースして実際のユーザーに使ってもらう中で判断していくというスタンスがあることに驚いた。それを可能にしているのは先述の「アップデートチャネル」というもので、「最新チャネル」を選択したユーザーにより多くの新機能を早いタイミングで使ってもらえるようになったというのが背景としてあるよね。
提案が通りやすい ＆ 変化が求められる
柿崎 : サブチームに分かれていて、1 つのチームが小さいから、開発の進め方とかスクラム開発の体制とかに対して、提案が通りやすいのは嬉しい想定外だった。とりあえずやってみようっていう流れがある気がする。
和渕：わかる。成長途中のチームだなっていうのが想定外。チームとして歴史があるから、安定していて、進め方の型決まってると思ってたけど、変化を求められてる段階だったっていうのが意外だった。
柿崎：ちょこちょこ変わってく部分がある気がする。
製品の伸び代
かや：製品の「伸び代」も予想以上に大きかった。歴も長いし既にたくさんの人に使ってもらっているから、ほぼ完成系の製品だと思ってた。けど実際は「ここ改善したい」っていうのがたくさん出てくるし新しい機能や画面を追加することも多いし、まだまだやれることがたくさんある。伸び代だね。
和渕 : 伸び代あるのはいいことですから。
コードが整備されている
宇都宮：読みづらいコードなかったのが意外。歴史長いと割と読みづらいコードが多いイメージ。ただ、そんなコードがなくて、いい想定外だった。
柿崎：フロントエンドのフレームワークの刷新もするしね。Closure Toolsに比べて React はわかりやすい気がする。
質問 4 : やりがいを教えてください！
質問 4 : やりがいを教えてください！
ユーザーからのフィードバック
和渕 : 1 つはさっきも話に上がった、自分の作った機能に対してのフィードバックが直接くるっていうのがあるよね。
柿崎：Days とかでも大規模なイベントがあって、実際のユーザーと関われたりどう使ってくれているのかを知られたりするのはモチベーションになる。
days.cybozu.co.jp
様々な制約を超える達成感
和渕 : kintone に限らないかもだけど、サイボウズとしてパートナービジネス戦略をとっているからこその考慮点がある。考えないといけないこと多くて難しいからこそ、そこを超えるやりがいはある。
これはサイボウズじゃないとできない経験の 1 つなんだろうなと感じる。
かや : 制約がいっぱいあるからこそ、そこを超えられたときの達成感がある。
ユーザーとして改善したいところを自分で改善できる
かや : 普段 kintone を使っているからこそ「ここ直したい」「こうだったらいいな」みたいなことが出てきやすくて、それを自分の手で良くしていける可能性があるのはいいなと思う。愛着も湧くしね。
実際に、入社後に行った改善の例としては、チェックボックスの改善があるよ。
note.com
コード書くのが楽しい
宮村：コード書くの楽しい。kintone のコードを書くの楽しい。
和渕：どこら辺楽しい？これだけ規模が大きいコードを書けるところとか？
宮村：それもある。元々のコードが綺麗だから、あ、いいコード書けたってなりやすい。
和渕：既存コードがしっかりしているよね。
わからないことをどんどん追求できる
宇都宮：kintone の仕様や設計などで、わからないこと多すぎる。芋蔓式に出てくる。終わりが見えないから、いつまででもできる。kintone はドキュメントが整備されているから、自分で解決できる。人に聞かないとわからないでしょみたいなのが、他のプロダクトに比べるとなさそう。調べやすいのはいい。
対象顧客が多いからこそのやりがい
和渕：対象顧客が多いからユーザー像掴みにくい、手触り感持ちにくいなとは感じつつ、やりがいだなと感じている。
まとめ
みんな、楽しく色々なことを学びながら、 1 年間を過ごせていたことがわかりました！
kintone の新機能開発について少しでも雰囲気が伝わっていると嬉しいです。
2 年目も頑張っていきます！
