こんにちは！フロントエンドエキスパートチーム兼 Mira チームで活動している@nus3_です。
サイボウズが提供するkintoneは 10 年以上にわたり多くのユーザーにご利用頂いています。現在、kintone の開発が引き続きスケールできるように、Closure Toolsから React へと置き換えるフロントエンドリアーキテクチャプロジェクト(フロリア)が絶賛進行中です。
フロリアの詳細については次の記事をご覧ください。
Mira ってなんですか？
フロリアプロジェクトにはいくつかのチームがあります。それぞれのチームはフロリアのゴールを達成するために、チームごとにオーナーシップを持って日々活動しています。
フロリアのゴールの一つに 「kintone のすべてのページが React によって表示されている」というものがあります。このゴールを達成するために、kintone の内部をこっそりと、利用者に気づかれない形で React に置き換えるのが Mira チームです。
Mira というチーム名が決まるまで
フロリアでは各チームがやることやゴールを事前に共有してもらった上で、プロジェクト参加メンバーがどのチームに参加したいかのアンケートを取り、その結果を踏まえてチーム体制を決めました。1
チーム体制の決定後、まず最初にやったことがチーム名を決めることでした。
フロリアの思想に「各チームがオーナーシップを持つ」という項目があります。自分たちがオーナーシップを持つために、自分たちでチーム名を決めることはとても重要だったと当時を振り返って思います。(実際は楽しく決めていただけですが、愛着が湧いてチームを意識できるようになったと思います)
次の画像は実際に kintone 上でチーム名の投票をしている様子です。
筆者的には多少の事故2がありつつも、このチームのゴールにマッチしているという理由で「安定感ある穏やかさ」という意味を持つ星言葉である Mira(ミラ)がチーム名に採用されました。
余談ですが Mira チームの Slack では毎日朝会前に妖精(bot)が星言葉を教えてくれます。
チームのミッションとゴールの明文化
チーム名を決めたあとはじめに取り組んだのはチームのミッションとゴールの明文化です。プロジェクトオーナー(PO) が不在の場で自然とこの話し合いがはじまったことから、Mira チームには元々我が強いオーナーシップを意識している人が多く集まっていたのかもしれません。
Mira チームのミッションは UI を変えずに内部実装を React に置き換えてリリースするサイレントリリースのための仕組みを作ることです。
サイレントリリースを実現するために、メンバー間でやるべきことの認識を揃えつつ短期的なゴールを決めました。miroを使って共同編集しながら意見を出し合い、議論を進めてゴールが無事に決まって全米が泣いた様子が次の画像からも伺えます。
Mira チームを構成する癖の強い個性的なメンバーたち
Mira チームは様々な領域に強みを持つ、個性豊かなメンバーで構成されています。
- プロダクトオーナー
- エンジニア 兼 スクラムマスター
- フロントエンドエキスパートチームから 2 名のエキスパート(自分で書くと恥ずかしい)
- Design Technologist3
- 趣味で React を使い始めちゃう QA
Mira チームが発足してから 4 ヶ月経ち、現在とても順調にチームで活動できていると感じています。そう感じるのは、チームが達成したいことに対して、メンバーが各々の役割+α を行えているからです。
例えば次のようなことを行っています。
- QA メンバーがフロントエンドのテストコードを書くモブに参加したり、プルリクエストをみたりする
- エンジニアと Design Technologist が一緒にアクセシビリティに関する実装と確認をする
- エンジニアと QA メンバーが一緒にテスト設計を行う
QA メンバーに関しては、テストしているフロントエンドがどのように実装されているのかに興味が湧いてしまい、趣味で React を使った簡単なアプリケーションを作ったりしています。
このように専門領域以外の+α の活動を、自分が得意な領域以外のことをメンバーが互いに教え合うことで自分の領域を広げています。
フロリアを構成するチームと人数
フロリアがプロジェクトとして始まる際には、1 チームを 5〜9 人で構成するという方針でチーム体制を決めました。これはチームトポロジーの「チームファースト思考」を参考にしており、チームのメンバーが一人一人を認知できる状態で安定して活動できるようにという考えがあります。
合わせて、可能な限りチーム内で意思決定を完結できるようにさまざまなスキルを持った人が集まったクロスファンクショナルな体制を志向しています。ただしこれは、一人一人が全ての役割をできるようになるのではなく、チーム全体で全ての役割を持っていればいいという意味です。その中でそれぞれが持つ強みでチームを強くしていくことを目指しています。
現在フロリアでは 4 つのチームで 30 人 以上のメンバーが活動しています。
ボケやすかったのはチーム人数が関係してた？
フロリアがプロジェクトとして発足する前、kintone の脱レガシー活動は 20 人ほどが集まった 一つのチームで行われていました。このチームのとあるミーティングに筆者が参加した際「こんなに大勢の人がいる中でしょうもないボケやツッコミをいれてメンバーの時間をとったら申し訳ないな」と思い、あまり冗談などを言うことができませんでした。参加者が多いことから、ミーティング中に発言する機会が全くないメンバーもいました。
フロリア以前は人数の多さや時間の関係から、全員がコミュニケーションを取ることは難しかったですが、今のチームのミーティングでは全員が発言できるようになっています。話しやすい状態ができたことで、筆者も自然とボケる回数が増えました。ボケること自体がチームにとってプラスかどうかはさておき、冗談が言える空気は大事だと考えています。
発言のしやすさについては人数がすべての原因かは定かではありませんが、現状のチームでは活発な議論が行えており、オンラインだとしても会話を行う機会が自然と作れるようになったと感じています。
Mira チームができてからの初週の振り返りと、最近の振り返りのコメント量の差からも、チームメンバーが（いい意味で）しょうもないことを言う回数が増えている様子がわかります。この記事を書くにあたって改めて見てみたのですが、如実に差があることには筆者も驚きでした。
チームがオーナーシップを持つことは楽しい
フロリアでは、チームがオーナーシップを持てるチーム体制やアーキテクチャにすることをとても大切にしています。この考えがベースにあるので、Mira チームも日々オーナーシップを持って開発することができています。
チームがオーナーシップを持つことでゴールを達成する過程においてチームで決定することが増え4、決定をする際にメンバー各々が自然とチームのタスクを自分ごととして考えるようになりました。
チームがオーナーシップを持ってメンバーが主体的に行動できる状態は、単に与えられたタスクを消化するのとは異なり、ゴールを達成するためにより良い方法はないかを思考したり、より難易度が高いことに挑戦できたりとても楽しいです。
オーナーシップを持ったチームによって生まれた挑戦できる環境
去年の 12 月に Mira チームができてから、kintone の内部実装をこっそり React に置き換えるための方針や、技術選定などの土台の部分をメンバーで決めつつ進めてきました。この記事の執筆時点（2022 年 4 月）ではまだリリースしていませんが、チームで決めた方針と作った土台に基づいて、React への置き換えを進めています。
チームごとに独立した技術選定と設計
フロリアではチーム毎に Monorepo でアプリケーションやパッケージなどを管理するアーキテクチャを採用しています。これはチームがオーナーシップを持てるようにするための一環でもあります。また、チームが担当するアプリケーションの境界が明確になっているので影響範囲が特定しやすく、チームが自由に技術選定や設計をすることができます。
このアーキテクチャのおかげでフロリアの別チームが決定した技術や設計にとらわれず、Mira チームで自由に技術選定や設計ができます。たとえば、他チームがビルドツールとしておもに webpack を使っている中 Mira チームでは Vite を使い、テスト時のトランスパイラには SWC(@swc/jest) を採用しています。ほかにも他チームで採用している Redux を Mira チームでは使わないといった独立した決定ができています。フロリア内の各チームがフロリアでのゴールを達成するために同様にさまざまな取り組みをしており、その内容を日々 Slack やスプリントレビューで知ることができるのが個人的な楽しいポイントです。各チームの良さそうな取り組みは積極的にパクる取り入れています。
開発プロセスの裁量
また、Mira のゴールであるサイレントリリースは、単にユーザーからみた UI の振る舞いを変えることなく React に置き換えるだけではなく、リリースまでの速度を上げることも含まれています。スピード感を持って開発に臨めるように、利用するツール選定からプロダクトオーナーの受け入れ基準などの既存の開発プロセスを大きく見直しました。
コミュニケーションを促進する取り組み
開発プロセスの改善以外にも、メンバー間の連携がスムーズに取れるようになるべく非同期で作業を進めつつ、各々が困った時にはすぐに Huddle(Slack) や Gather などで声がけできるようにして、非同期と同期を切り替えやすい体制にすることでコミュニケーションのボトルネックを減らす工夫をしています。
上記の取り組みの詳細や Mira チームが行っていることの詳細については、今のところ@mugi_unoが書いた、次の記事しかありませんが、どんどん発信していこうと思っています。
今後はチームで決めた方針と作った土台をもとに、React への置き換え難易度が高い画面を置き換えていくことで、ナレッジを溜めつつ、爆速で kintone を React にこっそり置き換えていこうと思っています。
以上が Mira チームの紹介になります。
この記事が大規模なプロダクトのフロントエンド刷新を、実際にどのようなチームでどのように行っているかの参考になれば幸いです。
一緒に挑戦できるメンバーを募集しています
チーム発足当初、渾身のボケが誰からもいじられなかった筆者ですが、今では Gather でこんな扱いを受けるぐらいにはチームに溶け込めたかなと思っています。
kintone のように大規模で長く続いているプロダクトのフロントエンドを、持続可能で自律的な体制・アーキテクチャに刷新する機会はなかなか多く経験できるようなことではなく、個人的にとても貴重な経験を積めていると思います。
この記事を読んでフロリアに興味を持ったそこのアナタ！現在、フロリアでは次のポジションで募集を行っていますので、ご応募お待ちしております！！
筆者が所属するフロントエンドエキスパートチームも募集しています！
QA エンジニアも募集しています！
- アーキテクチャとチーム体制の話についてはkintone フロントエンドリアーキテクチャプロジェクトで大切にしていることに詳細があります。↩
- このチーム名を決めるとき入社して 1 ヶ月程度だった筆者は、チームメンバーとの親睦を深めるために出した duke（ゴ ◯ ゴ 13 からインスパイアされた渾身のボケ）が誰からも触れられなかったという事故↩
- Design Technologist についてはこちらの記事が参考になります。新卒 2 年目のエンジニアが Design Technologist を名乗ることになった話↩
- 決定の過程は毎回 ADR に記録しています↩
