この記事はサイボウズアドベントカレンダー17日目の記事になります。

こんにちは。サイボウズで働いているエンジニアのもやし丸です。

エンジニアとして働き始めて今年で3年目になります。

入社1年目のときは自分の3年目の姿なんて全く想像できませんでした。どんなエンジニアに成長しているかなー。そもそも仕事続けられているのかなー。と期待と不安が入り交じる感情を抱きながら仕事をしていたことを覚えています。

今はどうでしょう？いざ3年目になってみたら転職を考えていました。

ちなみに1年目の活動はブログに書いてあるので、もしよければ読んでみてください。

dev-moyashi.hatenablog.com

仕事では kintone のフロントエンド刷新プロジェクトに携わっています。プロジェクトの概要はkintoneのフロントエンド刷新に向けた取り組みに記載しています。

blog.cybozu.io

2021年9月から転職活動をはじめました。年始、遅くても2022年の3月には別の会社で働く予定で活動していました。しかし、転職活動の過程で、働く目的や譲れないもの、価値観などを改めて考えた結果、サイボウズで働き続ける選択をしました。

この記事では、転職活動を始めたきっかけからサイボウズで働き続ける選択をするまでの過程を書こうと思います。

転職活動を始めたきっかけ

所属しているチームのあり方が自分に合っていないのではないかと感じていました。

自分が所属しているkintone開発チームはメンバーが全体で60人以上いるチームです。職能別にチームが別れていて、その中に更に小さいチームがある体制になっています。縦割りはなく、必要に応じて小さいチーム同士が連携しながら仕事をしています。

僕は大きくなり続けるアプリケーションのすべてを理解することに限界を感じていました。自分が認知できる範囲以上のものを扱っていると日々感じていました。アプリケーションの全体を見ることができていないので、何か発言するときも、偏った意見になっていないか、考慮不足なのではないか、と自分自身の意見に自信を持つことができず、常に不安な気持ちを抱えていました。全員の前で無知を晒して恥をかくことに怯えていました。

僕はチーム全体に関わることを話す心理的ハードルが高いと感じていました。しかし、心理的ハードルの感じやすさは人それぞれです。同じ環境でも主体的にチーム全体に疑問を投げかけ、物事を前に進められる人もいました。だから、僕はいつしかチーム全体に関わることは、全体を俯瞰して見ることができて、みんなをまとめられる人にお任せするようになりました。すると、仕事への向き合い方が悪い方向へと変化しました。チームの関心事を自分事として捉えることができず、チーム全体に関わることについて考えることを放棄するようになりました。自分の仕事のことだけを考えるようになりました。徐々に仕事がつまらなくなっていきました。自分の役割がよくわからなくなり、僕はチームに居ても居なくてもどちらでもいい存在だと考えるようになりました。

このような体験を経て、僕は自分の見える範囲で責任を持って仕事がしたいと考えるようになりました。まだ成熟していないアプリケーションかつ、規模の小さいチームで意思決定して進められる環境だったら、責任感も芽生えて主体性を発揮できるかもしれない、仕事が楽しくなるかもしれない、と考えていました。だから、そのようなチームで、興味のあるプロダクト、技術領域がマッチしているチームを探しました。しかし、残念ながら希望が叶うチームをサイボウズで見つけることはできませんでした。僕は己の未熟さ故にサイボウズで働き続けることができないことを悟りました。

転職するために何をしていたか

Findyでいいねを付けてくれた企業と面談したり、転職ドラフトに登録したり、リファラル採用を受けたりしていました。

転職ドラフトでは現在の年収+50万円を希望額として提示しました。結果、19社からオファーをいただきました。指名していただいた企業の皆様ありがとうございました。

すべての企業と面談する時間はなかったので、しっかりレジュメを読んでコメントしてくれていると感じた企業に絞って面談させていただきました。

転職活動中の気付き

転職活動中は様々な企業の方と面談させていただいて、自分を見つめ直すきっかけになりました。面接、面談では「チームワーク向上に繋がる製品（チームメンバーの信頼関係の構築を支援するソフトウェア）を作っている企業で、エンジニアとして良いチームを作りながら開発したい」と話していました。では、なぜサイボウズでそのようなチームが実現できないのか？説明する必要があるので理由を考えていたら、誰かが環境を整えてくれることを待っている自分に気が付きました。

理想のチームは与えられるものではなく、自分たちでつくるものですよね。転職活動での気付きを経て、今の開発チームを一人ひとりがオーナーシップを持って開発できるチームに変えられないか考えるようになりました。上手くいかなかったら転職すればいいという気持ちが背中を押してくれました。

一人ひとりがオーナーシップを持って開発できるチームを目指して

メンバー全員が主体性を発揮できるチームにしたいと思っていました。一人ひとりがオーナーシップを持って、小さいチームで意思決定をして物事を進められるようにするには、小さいチームが見る範囲を絞る必要があると考えていました。各々の小さいチームが常にアプリケーション全体を見なくても共通の目標に向かうことができる。小さいチームの担当範囲が明確である。小さいチームの意思決定が他の小さいチームに影響しない組織構造を求めていました。

まずはチームの理想の形を考えていたマネージャーに今のチームの形を変えられないか相談しました。新しいチーム体制への案はあったものの、実現の目処が立っていなかったので、「今すぐ実現しませんか？」と提案してみることにしました。他のメンバーも現状のチーム体制についてどのように感じているのか聞いてみたかったので、話しかけやすいメンバーとざつだんする時間も作りました。結果、新しいチーム体制に関心があるメンバーを集めて議論を重ねることになり、フロントエンド刷新プロジェクトチームから新体制へと移行する目処を立てることができました。

一方で、チームの担当範囲を明確にして、チームの規模を小さくすると本当にメンバーが主体性を発揮できるようになるのか確信が持てていませんでした。主体性を持てるかは人によると思いますが、まずは自分が主体性を持てる人間なのかを明らかにしたい気持ちが強くなっていました。そこで、少人数で取り組むことができて、影響範囲が小さい仕事を探してみることにしました。見つけたのは kintone のリッチテキストエディタの開発です。当時 kintone 本体とは別リポジトリで開発が進んでいたため、開発、提供、運用を見据えて独立して動くことができると判断しました。開発にはQAエンジニアをお招きして、リッチテキストエディタのテスト自動化を目的に、QAエンジニアが管理している手動テストの試験一覧を一緒に眺めて自動テスト用の試験に置き換えたり、QAエンジニアも自動テストを書けるようにテストツールの調査、整備を行いました。最終的にはリッチテキストエディタの品質の責任を Webエンジニア、QAエンジニア両方が持てることを目指しました。

これらの活動は 12/11 に開催された Developers Boost にて発表させていただきました。

speakerdeck.com