サイボウズにエンジニアとして入社して１年たったので振り返る
今一緒に仕事してる同僚がブログこんなブログを書いてて、触発された感じです。 せっかくなので自分も記録として残そうと思います。
これが自分の転職初日のツイート
今日が新しい職場のサイボウズ初出社日でした😀
— Nokogiri👨🏻💻 (@nkgrnkgr) June 13, 2019
これから大阪でkintoneの開発に携わります👩🏻💻 pic.twitter.com/ZSEczfhOW7
この時も完全にsakitoさんのツイッターみて、俺もやろうってパクったやつ。
パクリ駆動発信。
まず軽く自己紹介
ブログでは何も書いてなかったと思うので自己紹介をしておくと
2019年6月からkintone開発チームでプログラマーをしています 大阪オフィスに所属しています。ただし新型コロナウイルスによる感染拡大に伴い、今は自宅からリモート開発しています。
主にkintoneの新規機能開発のプロジェクトに参画しています。
最近 Cybozu Tech Meetup #1 kintone開発チーム というイベントで登壇しました。
「kintone × リモートモブプログラミング」
入社するまで
サイボウズが転職二回目です。
新卒でSIerに入り７年くらい働いたあとに１度転職して、toB向けの自社クラウドサービスの開発・保守をやっているところに入りました。
いわゆるSIerからWeb系エンジニアに転職したというやつです。
そこからサイボウズ に転職したのは、サイボウズは優秀なエンジニアが多く在籍しているイメージで、そこに入って自分ももっとスキルアップしたいと思ったからです。
実は新卒で入ったSIerを退職するときに、当時の上司（課長）に「自分は２年以内にエンジニアとしてサイボウズかY社に入るのが目標です。」と言って出て行きました。
当時の上司からすると「こいつ何言ってんだ？正気か？」みたいな感じだったのではないかな〜と思います。（当時の上司に会ったらドヤ顔したいw。いや、実際あったらしないけど。）
入社してから感じたことなど
めっちゃ情報がオープン
社内のコミュニケーションは kintone や Garoon 上で行われており、プライバシーやセキュリティに関わること以外はほぼフルオープンです。
オープンなコミュニケーション自体はすごく良いと思っています。オープンであるからこそいろんな人が議論に参加できますし、議論の経緯をあとから見ることができます。
ただ、すべての情報を見ることはできないので、自分で自分に必要な情報を見極める必要があります。 全部みてるととてもじゃないけど時間が足りないです。これが結構難しくてこれは今でも課題です。
早く結果を出したくて焦っていた
中途入社の人あるあるだと思いますが、即戦力として入社するわけなので、早く成果を出せるようになりたいと焦っていた時期がありました。
kintone チームはモブプログラミング を採用しています。
kintoneのモブプログラミング に関してはこちらの記事をご参照ください
入社して3ヶ月くらいは、モブの中であまり発言ができずモヤモヤした時期が続いていました。
ドライバーをやればただ、指示通りコードを書くだけでナビゲーターになっても特に有用な発言ができないことがありました。
もちろんkintoneのドメイン知識もありませんし、スキルとしても自分が足りていないこともあってなかなか結果を出せていなかったと思います。
早くチームに慣れるために意識していたこと
モブの中でとにかく質問すること
自分の中でよく使った手法としては
「認識があっているか確認させてください！○○っていう認識であってますか？」
っといって自分の理解があっているかメンバーに確認していました。
自分の言葉で言語化すると自分の頭が整理されますし、間違っていればちゃんと指摘してもらえます。
自分が理解できないままモブが進んでいくのが一時期ストレスだったのでちゃんと分かっていないときにはモブを止めるようにしました。
ドライバーの回数を多めにやる
モブの中で今やっている作業や次にやることを呟きながらドライバーをやります。
ドライバーは指示を待つことも可能ですが、自分が宣言しながら進めると早い段階でナビゲーターから指摘が入り軌道修正しやすいです。
またナビゲーターは逐一指示する必要がないので周辺コードをみたりちょっと先を確認するなど視野が広がります。
結果として慣れていない人がドライバーをやることで学習が進みますし、クオリティの高いコードをかけるのかなと思います。
ドライバーをやることでより集中して作業に取り組めますが、どうしても視野が狭くなりがちで周辺のコードに気を配れなかったり考慮漏れが発生してナビゲーターから指摘を受けます。
この流れ自体は悪くないですがやっぱりみんなコードを書きたいのでずっとこの方法をとることはベストではない気がします。
空き時間を使ってコードを読む
モブを実施する時間は9:45~17:00と決まっているので、朝の9:00~9:45, 17:00~18:00までは各人の勉強時間などに当てています。 この時間を使って、今取り組んでいるタスクの周辺のコードを読んでみたり、モブでは採用しなかったコード修正の方法を試したり など探求をすることで kintoneのドメイン知識を得ていくようにしています。
最近は少し慣れてきたので、少し先で実装しそうなタスクの事前実装調査をして仕様の実現方法を試したりしています。
最近挑戦していること
kintoneのReact化
基本的にkintoneの新規機能開発を実装してきましたが、4月くらいから kintone の React化というプロジェクトに取り組んでいます。
kintoneのフロントエンドは
Closure Tools | Google Developers
というライブラリでほぼできています。
2010年にリリースされたフルスタックフロントエンドのライブラリで、このライブラリ自体はGoogleがGmailなどに採用していることもあってかなりよくできています。
ですが、ReactとTypeScriptで作る昨今のフロントエンドの開発と比べると記載が冗長になったり、実装を読み解くのが難しいと感じる部分が多々あります。
以前からReact化したいという方針はありましたが、4月くらいから本格的にフロントエンドをReact化していくプロジェクトが開始しました。
元々Reactはずっと趣味運用しているサービスで使っていたり、それ以前からずっと書いてきてました。
もしkintoneのReact化が本格化する際は自分も関わりたいと思っていたので今関われてめちゃくちゃありがたいです。
このkintoneのReact化はkintone開発チームだけでなく、フロントエンドエキスパートチームのメンバーと一緒に活動しています。
フロントエンドのツール選定やビルド周りのサポート、実装方針まで今は一緒のモブの中で開発しており、いつもフロントエンドエキスパートチームのメンバーの専門性には助けられています。
多分Cybozuの一番の福利厚生はプロダクト開発チームが特定技術要素の専門チームのサポートを受けれることだと思います。
kitnoneのエンジニアはフロントエンドとサーバーサイド両方を開発する必要があるので、技術探求が分散しがちです。
特定技術要素で専門性の高いメンバーがサポートしてくるのは心強いです。
サーバーサイドのテストコード改善
hamcrest -> AsserJ移行
kintoneのサーバーサイドのテストコードは JUnit4 + hamcrestを使っていました。
今後 JUnit5に移行していくにあたりJUnit5では assertThatが同梱*されなくなります。
そのためhamcrestをやめてAsserJ移行をする作業を個人の空いている時間を使って進めていました。
何人かの有志メンバーで2ヶ月くらいかけてコツコツ潰しながら全てhamcrestを全て駆逐していきました。
現在は jmockitを外すためにMockUpを駆逐していく取り組みをしています。
2年目以降の展望
とりあえずまだまだ kintone のコードはわからないところが多く、先輩方に教わることが多いです。 技術力的にも足りてない部分も多く自分がモブを引っ張っいけるくらい技術力とドメイン知識をつけていくことが直近の展望です。
おまけ
We are hiring!!!!
kintoneチームではエンジニアを募集しています！
興味がある方がいらっしゃれば、カジュアル面談なども行っていますお気軽にお声がけください🙇🏻♂️
もし興味あるという方は、TwitterでDMいただければ、幸いです！
