短期間だけ別チームで仕事をする「レンタル移籍」でソフトウェア開発の知識共有を促進！ユーザベース独自のチーミング制度を体験ベースで紹介する

レンタル移籍のススメ短い期間だけ別のチームで仕事知識共有を推進してアジャイルを加速！

あなたの組織に「あの人が抜けたら動かない」というチームはありませんか？関わっていた人が組織からいなくなって誰も詳細を知らないAPIが存在したりしませんか？アジャイル開発を導入しているのに、組織としての成長が止まっていると感じることはありませんか？

「どうすれば組織全体の知識共有を促進し、自己組織化を加速できるのか？」「どうすればキーパーソン依存のリスクを低減できるのか？」「どうすればチームごとのよい取り組みを組織全体に広げられるのか？」これらは多くのエンジニア組織が直面している課題でしょう。

私たちユーザベースのスピーダ事業のProduct Teamでは、こういった課題を解消するために「レンタル移籍」という人事制度を実施しています。レンタル移籍はこれらの課題を同時に解決できる取り組みであり、アジャイルをさらに加速させます。

1週間だけ他のチームに移籍できる独自の制度

ここまで読んだ方の多くは「レンタル移籍？聞いたことないな」「アジャイルにそんなプラクティスあったっけ？」と思ったのではないでしょうか。知らないのも当然です。レンタル移籍は、私たちが独自に実践している自己組織化を加速させる取り組みです。

レンタル移籍を一言で言うと、3ヶ月に1度、社内の好きなチームで1週間働くことができる制度です。特別な理由がない限り、Product Teamでは全員がこの制度を利用して、他チームで1週間仕事をしています。なお、Product Teamとは私たちの開発組織全体の呼び名で、この中にチームは20くらいあります。

ここからは、おそらく世界的に見てもユーザベースだけで行われている「レンタル移籍」という独自制度について、私（@Sicut_study）自身の体験談を踏まえながら紹介します。読み進めるにつれて「レンタル移籍を導入してみたい」と思ってもらえるように深掘りしていきます。

レンタル移籍に取り組む4つの目的

私は2年前にユーザベースに転職してきましたが、最初にこの制度を聞いたときには驚きました。

「1週間も人が抜けたら業務が回らなくなってしまうのではないか？」「もし抜けるのがチームの中心人物だったら開発が回らなくなるのではないか？」「他のチームに行ったとしても技術も違うし、やっていることやプロダクトも違うので戦力になれないのではないか？」

しかし、このような不安の中でレンタル移籍を意図的に行うことが重要なのです。レンタル移籍を実施するのには、4つの目的が存在します。

目的1. わざと障害が起きた状態にしてみる

ユーザベースでは、アンチフラジャイル（反脆弱）を目指す一環として、カオスエンジニアリングに取り組んでいます。カオスエンジニアリングに関しては、過去に紹介した記事がありますのでぜひお読みください👇

カオスエンジニアリングとは、意図的に障害を起こし、挙動を確認してシステムの改善につなげる考え方です。そしてカオスエンジニアリングはシステムだけでなく、ヒューマンリソースに対しても適用が可能です。

レンタル移籍においても、メンバーが1週間チームから離れることで「運用のやり方が分からない」「問い合わせが来たけど残ったメンバーでは対応できない」といった問題が発生することがあります。さすがに問題が起きたら「キーパーソンに声をかけてもいいの？」と聞かれますが、原則として連絡をとってはいけないのです。そのため、以前その施策に関係していた人などに相談して、最終的には何とか解決します。

このようにレンタル移籍したメンバーと1週間連絡をとらないという制約を設けることで、キーパーソンがチームから隔離されたときに起こる問題をあぶり出すことができます。そしてわざと問題を起こすことで、チームメンバーの知識や技術の差をなくす活動でもあるのです。

目的2. チームシャッフルと同じような知見の共有を

私たちは、レンタル移籍以外にもさまざまな独自の取り組みを日々行っています。中でも面白いのが「チームシャッフル」という制度です。

多くの会社では、配属されたチームから所属が変わることは、多くても年に1回程度だと思います。私たちの組織では3ヶ月に1回、チームメンバーの半数（2名程度）が入れ替わります。つまり、チームで最も在籍が長いメンバーでも、半年で別のチームへ異動することになるのです。

チームシャッフルの仕組みや利点については、こちらの記事で図解しています👇

ユーザベースのチームシャッフルの図版 — ▲ Agile Journey「アジャイルリーダーシップとはなにか？どう実践するか？権力ではなく影響力でアジャイルな組織をつくるために【対談】」より

チームシャッフルは、他のチームで仕事をするという点で、レンタル移籍に近いものがあります。むしろレンタル移籍の方が、短期間でチームシャッフルするようなイメージなのです。そのためチームシャッフルで得られるベネフィットは、レンタル移籍でも得ることができます。

例えば、私たちはマイクロサービスを採用しており、社内には多くのAPIがあります。技術選択もチームに委ねられるため、マイクロサービスの実装言語もJavaやKotlinやRustから、F#というあまり耳馴染(なじ)みのない名前の言語までさまざまです。定期的にチームのメンバーを入れ替えることで、そんな多様なAPI実装や開発言語に触れる機会があります。

さらに「〇〇APIは（退職した）△△さんしか分からない」「このAPIを触ったことがあるメンバーが誰もいないからメンテナンスできない」といった、チームが自己完結して起きる問題（サイロ化）を防ぐことができます。つまり知識共有を、チーム全体で行うことができるのです。

レンタル移籍でも、この効果は十分発揮されています。例えばレンタル移籍で来たメンバーが、チームで利用するAPIに詳しかったことで開発がスムーズに進むということも頻繁に起きています。

目的3. コミュニケーションの活性化

「エラーが発生したけど対応が分からない」「このAPIが何をしているのか知りたい」「関数プログラミングに詳しい人からアドバイスをもらいたい」。開発していると、誰かと話をしたい状況がよくあります。

もしあなたが入社1日目で、他のスタッフをよく知らない状態だったらどうでしょう？「誰に聞けばいいのだろう？」「前に座っている人がエンジニアかどうかすら分からない」「そもそも初対面なので声をかけること自体のハードルが高い」。これは、それまでのコミュニケーションが不足しているために起きる問題です。

初対面という極端な例を出しましたが、自分のチームでしか話をしない人にも起きうるケースでしょう。この対策として、レンタル移籍でコミュニケーションを活性化することができます。おそらくレンタル先のチームにはあまり話したことのない人がいますが、一緒に働くことでコミュニケーションが取れるようになります。自分のチームに戻ってからも、レンタル先のメンバーには気軽に声を掛けることができます。

また1週間仕事をすると、誰が何を知っているか・得意なのかも分かるので「この問題は〇〇さんに聞けば分かりそう」と、より適切な人に聞くこともできます。マイクロサービスの採用により多様な技術が使われていることと、チームを頻繁にシャッフルすることを通して、Product Teamには「知らないことは、知っている人に直接聞く」という文化が根付いています。この文化において、コミュニケーションを活性化させることは重要な役割を果たしています。

なお、レンタル移籍は2020年8月にメンバーから提案された制度で、当時からコロナ渦でのコミュニケーションを活性化することを目的としていました。現在では知見の共有などの目的をもった取り組みに進化していますが、コミュニケーションを活性化したいという思いは変わりません。

目的4. チームを離れて分かる世界の広さ

レンタル移籍を行うと「他のチームはこんな開発をしているんだ」という気づきを得ることができます。

自分のチームだけで働いていると、そのチームの働き方に順応していきます。「もっとこうすればよくなる」という目線がだんだんと鈍くなってしまい、新しい取り組みに挑戦する機会も少なくなりがちです。レンタル移籍によってレンタル先のチームのよい取り組みを持ち帰ることや、自分のチームのよい取り組みをレンタル先のチームに広げることが可能です。

Product Teamでは、チームごとに扱っている技術が全く異なり、パイプライン1つをとってもさまざまです。そして、チームは週に1度のふりかえりを通してどんどん成長していきます。自分のチームで当たり前にやっていることが、他のチームから来た人にすると「まさに求めていたもの」となる可能性があります。逆に他のチームで働くことは、新しい取り組みに気づくチャンスでもあります。

レンタル移籍は、一見すると受け入れる側が「来た人に丁寧に教えないといけない」という印象もあるかもしれませんが、受け入れるチームにも大きなベネフィットをもたらすと考えられます。つまり「レンタル移籍して来た人」と「受け入れるチーム」のどちらにも、他のチームから学ぶことを意識するだけでお互いに成長できる制度となっているのです。

レンタル移籍の手順 ─ 希望調査からふりかえりまで

ここまでレンタル移籍を行う目的を紹介しました。実際に取り組んでみたいと思った方もいるのではないでしょうか。ここでは、Product Teamが実際どのようにレンタル移籍を実施しているのかを紹介します。

手順1. レンタル移籍したいチームの希望調査

レンタル移籍は3ヶ月に1度行われるため、4半期の初めに希望レンタル先のアンケート調査が行われます。ソフトウェアエンジニア・機械学習エンジニア・SREエンジニア・テストエンジニアなど職能に関係なく、どのチームに移籍することも可能です。

レンタル移籍では、チームから出ていくメンバーと来てくれるメンバーの人数をそろえるため、各チームに5人ずつ希望でき、希望者が多い場合は希望者同士で相談して決めます。

スプレッドシートでアンケートを取る — ▲ アンケートでは受け入れるチームに希望者が記名する

手順2. レンタル先のチームと移籍時期を相談

レンタル先が決まったら、次にレンタル先のチームメンバーといつから1週間働くかを相談します。レンタル先のチームから提示されることもあれば、移籍者が自分のチームの都合にあわせて「この日から1週間働きたい」と希望することもあります。

日程調整

手順3. レンタル先で1週間働く

レンタル先のチームで仕事をします。最初に「なぜレンタル移籍でこのチームを選んだのか？」と目的を聞かれることが多いです。レンタル移籍はお互いにメリットがある仕組みなので、チームもレンタル移籍して来た人に対して目的を最大限叶えてあげられるようにしたい気持ちがあります。

そのため移籍して来た人がユーザーストーリーに多く入れられるよう、多くの場合でペアプログラミングのメンバー交代などを調整してもらえます。こうすることで、ドメインをより深く知ることができます。

また開発だけでなく、関係者とのミーティングにも参加します。こういったエンジニア以外の普段は関われない関係者と交流することが、プロダクトについて詳しく知るきっかけになります。

手順4. レンタル先でのふりかえり

レンタル移籍の最終日には、30分程度で「レンタル移籍ふりかえり」を行います。ユーザベースではふりかえりの文化が根付いており、1週間のイテレーションごとにふりかえりを行っていますが、レンタル移籍のふりかえりはチームのふりかえりとは別に行われます。

ふりかえりには多くのフレームワークがありますが、レンタル移籍のふりかえりには以下のフレームワークを使うことが多いようです。まず前半の15分程度で、次の4軸に対して「よかったこと」と「のびしろ」をそれぞれ付箋に記入します。

チームから、移籍して来た人に対して
チームから、チーム自身に対して
移籍して来た人から、チームに対して
移籍して来た人から、移籍して来た人自身に対して

後半の15分で、書いた付箋を読み上げます。このレンタル移籍ふりかえりを行うことで「チームを成長させるきっかけ」や「レンタル先で得た学び」などを整理でき、レンタル移籍の目的である「自己組織化」や「他チームのよい取り組みを持ち帰る」ことにつながります。

最後に、感謝を伝えて終わりになります。

手順5. レンタル元での「カオスふりかえり」

1から4までは移籍する人とレンタル先のチームの話でしたが、その裏ではキーパーソンの抜けたチームがカオスに直面しています。ここでもふりかえりがよく行われます。これを「カオスふりかえり」と呼びます。

チームからキーパーソンが1週間抜けて「どんな問題が起きたか？」「残されたメンバーはどう思ったか？」などをチームでふりかえります。もし何らかの課題が見つかれば、それをチームで解決するアクションを考えて、実施していくことになります。

レンタル移籍をよりよく実践する細かなルール

レンタル移籍の仕組みは紹介してきた通りですが、よりよく実践するため少しだけルールがあります。

ルール1. 社歴やポジションによって対象外にする

レンタル移籍を行うときに、現在のチームで仕事に慣れることが重要な時期と判断されるメンバーは対象外となります。例えば社歴が入社半年未満であったり、タイトル（評価テーブルにおける等級）に応じたりして決められます。別のチームに異動することでかえって混乱しないように、ルールとして設けています。

ルール2. 職種を問わずどのチームに移籍してもよい

Product Teamには、ソフトウェアエンジニア・機械学習エンジニア・SREエンジニア・テストエンジニアがいます。ソフトウェアエンジニアと機械学習エンジニアが混在して構成されたチームもあれば、SREエンジニアだけで構成されているチームもあります。

たとえソフトウェアエンジニアがSREのチームで仕事をしても、チームに「これまでなかった気づき」を持ち帰ることができるという考え方から、レンタル移籍先に制限はありません。

私はソフトウェアエンジニアですが、ソフトウェアエンジニアだからといってソフトウェアエンジニアのチームをレンタル先に選ぶ必要はありません。SREチームや機械学習チームに移籍して、普段は触れることのない専門的な技術を体験することも可能です。

ルール3. 来てほしいメンバーをチーム側から指名できる

レンタル移籍は、移籍を受け入れるチームにとっても知識の吸収に活用できます。Product Teamには「分からないことは知っている人にすぐ聞く」という文化があり、もしチームメンバーが誰一人知らない技術的な課題があっても最終的には周囲に相談して解決するので大きな問題にはなりません。しかし、初動でコストなどを見積もりづらいといった不安はあります。

そこで活用できるのが「レンタル移籍の指名制度」です。チームから直接「〇〇さんにレンタル移籍として1週間来てほしい」とお願いすることができます。

例えば、Product Teamでは「マイクロフロントエンド」というアーキテクチャによる開発が増えています。新しいチームが組成されてマイクロフロントエンドに挑戦することになったものの、メンバーの誰もその開発経験がないということはよくある話です。指名制度を活用してマイクロフロントエンドの経験があるメンバーに1週間入ってもらうことで、開発をよりスムーズに進めることができます。

私のレンタル移籍体験から ─ 移籍する側と受け入れる側

私は入社して2年になりますが、レンタル移籍も5回ほど体験しました。ここでは、私にとって印象的だった経験を紹介していきます。レンタル移籍をより具体的にイメージしてもらえるのではないかと思います。

体験1. 初めてのレンタル移籍で指摘された「のびしろ」

レンタル移籍は、入社して半年すると利用できます。私もそのタイミングでレンタル先のチームを選ぶことになりました。その選択は、技術を学ぶためにレンタル移籍先のチームを選ぶというパターンでした。

その頃の社内の状況は今でも鮮明に覚えています。とあるチームで、新しいプログラミング言語が採用されました。それがF#で、マイクロソフトが開発した関数型のプログラミング言語です。採用したチームのメンバーは口をそろえて「F#の開発体験が最高」「F#はイケてる」と言っていました（そこから社内でF#が大流行し、今では多くのプロジェクトで採用されています）。

入社半年でひよっこの私は「なぜF#が社内で話題になっているのか知りたい」「やったことがない関数型プログラミングを学んでみたい」と考えて、F#を採用しているチームにレンタル移籍しました。初めてのF#で思う存分開発させてもらったり、スピーダという大きなサービスのリリースを体験させてもらったり、学ぶことはたくさんありました。終わって所属チームに戻ったときに「F#最高でした」と言ったのを覚えています。

新しい技術に触れる目的は達成できたものの、反省点もありました。それは、受け入れてくれたチームに与えられるものがなかったことです。レンタル移籍は、来た人にも受け入れるチームにも、どちらにもメリットがある制度です。しかし、その頃の私はそこを理解しておらず「与えられただけ」になってしまいました。

次の図が実際の「レンタル移籍ふりかえり」の様子です。これで「（所属チームである）シンFORCAS的視点を持ち込んでほしかった」という「のびしろ」があることが分かりました。外からの視点でチームを見ることは重要なので、積極的に行うとお互いに目的が達成できます。

画像：レンタル移籍ふりかえり

体験2. 普段は関われない沖縄のチームと仕事をする

技術を学ぶほかに、コミュニケーションのためにレンタル移籍先のチームを選ぶというパターンもあります。

Product Teamには、沖縄に拠点を置く株式会社プロトソリューションのメンバーで構成されるチームがいくつかあります。ここはチームシャッフルの異動先候補として選ぶことができないため、チームがあることは知っていますが、どんな人がいるのかは知りません。そこで普段あまり関われない人と仕事をしてみたいと思い、沖縄メンバーが働くチームへのレンタル移籍を選びました。

リモートの短い期間ではありましたが、沖縄のメンバーと一緒に仕事をして、気軽に話せるようになりました。一度コミュニケーションが取れていれば、相談したいことがあるときに気軽に相談できます。

体験3. 知らないプロダクトを扱うチームで仕事をする

直近では、開発に携わったことのないプロダクトについて「どんなサービスなのか」「どんな技術が使われているのか」「どんな関係者がいるのか」を知りたいという理由でチームを選びました。Product Teamで開発している代表的なサービスのうち、それまで唯一関わることのなかったサービスでした。

1週間働くだけでサービスについて理解できるのも、レンタル移籍のよいところです。レンタル先で好きなプロダクトを見つけられれば、チームシャッフルを活用してチームを異動することで、よりやりがいのある仕事ができるようになるはずです。

体験4. レンタル移籍を受け入れてチームが救われた

レンタル移籍は、受け入れるチームにとっても価値のある制度です。ここまで私がレンタル移籍した話をしてきましたが、今度はレンタル移籍を計画的に受け入れた体験を紹介します。

私は半年前に「スピーダスタートアップ情報リサーチ」の開発チームにいました。このチームには、スタートアップに特化したデータを別プロダクトである「スピーダ経済情報リサーチ」で表示できるよう、マイクロフロントエンドで開発するミッションがありました。マイクロフロントエンド化するには、経済情報リサーチにも手を入れる必要があります。メンバーにはマイクロフロントエンドの開発経験がほぼなく、経済情報リサーチの開発経験もありませんでした。

そんな開発の先がぼやけている状況を打開するため、レンタル移籍を活用することにしました。開発の序盤でレンタルさせてもらうメンバーを相談し、開発のフェーズ（経済情報リサーチの開発、マイクロフロントエンドの開発など）に合わせて詳しいメンバーに来てもらいました。この作戦は大成功しました。

経済情報リサーチに手を入れるときに詳しい人が来てくれたので、開発がスムーズに進みました。本格的にマイクロフロントエンドの開発に入るタイミングで、直近までマイクロフロントエンドで開発していた人が来てくれて、設計を固めることもできました。後半ではテストエンジニアにも来てもらい、それまでに書いたE2Eテストが仕様書通りになっているかを改めてペアプロしながら見てもらい、表現を修正しました。

このようにチームとして経験したことのない問題に立ち向かうときや、テストのような専門性の高い開発で詳しいメンバーに1週間来てもらうのは、とてもよいレンタル移籍の活用方法です。

レンタル移籍のメリットとデメリット

レンタル移籍の目的や体験談を話してきましたが、ここで改めてレンタル移籍のメリットをまとめてみます。

個人の成長: 気になる技術に触れるきっかけになることや、SREチームや機械学習チームなど別の領域の知見が得られることがあります。そして話したことのない人と仕事ができるなど、人脈の拡大も実現できます。
組織の知識共有: チーム内外で知識を共有でき、キーパーソンが抜けたときのチームの問題が明らかになります。また、社内で関わったことがないプロダクトを知ることができ、誰が何に詳しいのかを把握できます。
組織文化の改善: 自分のチームのよい取り組みを広められるだけでなく、他チームのよい取り組みを持ち帰ることもできます。さらに、チームで経験不足な部分を詳しい人にサポートしてもらえます。好きなチームで働けて純粋に楽しいという副次的な効果もあります。

デメリットには長期的な視点で考える

ここまで「レンタル移籍はよい」という話ばかりなので「デメリットもあるよね？」と思った方もいるはずです。もちろんデメリットもあります。

短期的な生産性: メンバーが1週間抜けるので、1人分の開発スピードが落ちることは避けられません。レンタル移籍して来た人にとっては、メンバーと同じペースで成果を出せるとは限りませんし、開発の終盤で小さな作業しか残っておらず学びが少ないこともあります。
マネジメント面での課題: 関係者への説明が難しいという点が挙げられます。例えば進捗が悪い中でキーパーソンが抜けることを関係者に説明するのは容易ではありません。

説明が難しいと感じるのは「短期的な利益」を求めているからです。Product Teamでは「長期的な利益」を考えてレンタル移籍を取り入れています。短期的にはキーパーソンが抜けることはデメリットに感じるかもしれませんが、この取り組みを長期的に行うことで将来的な価値を生み出すことができます。

このようにデメリットもありますが、それを上回るメリットがあるというのが私の考えです。最初は小さくでもいいので、レンタル移籍を導入してみると自己組織化につながります。ぜひ挑戦してみてください。

レンタル移籍に挑戦する ─ 導入のヒントと活用のコツ

レンタル移籍を最大限活用するには、いくつかコツがあります。開発組織にうまく導入するヒントとあわせて紹介します。

レンタル移籍を導入して成功させるヒント

組織にレンタル移籍を導入したいという際に「どう始めればよいのか？」「どう説得すればよいのか？」という疑問を持つ方も多いでしょう。私たちの経験から、以下の3点がアドバイスできます。

ステークホルダーへの説明方法: 短期的なコストよりも長期的なメリットを強調しましょう。「知識の共有によるリスク低減」「チーム間コラボレーションの向上」「人材育成の加速」など、経営視点でのメリットを伝えることが効果的です。また、最初は小規模な試験的導入から始めることで、抵抗感を減らすことができます。
最初のレンタル移籍参加者選び: 初回は積極的に学びたい意欲が高く、コミュニケーション能力の高いメンバーから始めるとスムーズです。彼らのポジティブな体験が組織内に共有されることで、次第に参加希望者が増えていくはずです。
フィードバックループの構築: 初期段階から「ふりかえり」の仕組みを整え、メリットと課題を可視化することが重要です。これにより継続的な改善が可能になり、組織全体への浸透がスムーズになります。

活用のコツ1. チームを選んだ目的をヒアリングする

レンタル移籍の希望調査が終わり、自分のチームにレンタル移籍して来るメンバーが決まったタイミングで、「なぜ私たちのチームをレンタル先として選んでくれたのか？」という目的を聞くことが大切です。多くの場合、何かしらの目的をもってレンタル移籍先を選択しています。例えば、私の最初のレンタル移籍では「F#がやりたい」ということが第一目的でした。

しかし、開発にはフェーズがあり、バックエンド開発が多い週もあれば、フロントエンド開発が多い週もあります。タイミングを間違えてレンタル移籍に来てしまうと「F#がやりたい」という目的は叶えられません。そのため最初の段階でしっかりと目的をヒアリングして、レンタル移籍の時期を調整することが大切です。

活用のコツ2. 受け入れてくれたチームに与える意識

レンタル移籍は、レンタルで来た人と受け入れるチームのどちらにとってもメリットがある制度です。そのためレンタル移籍している期間中は、自分からもチームに何か気づきを与えられるかと考えることが大切です。

「私のチームではこういうときに○○をしているよ」
「こういう障害で過去に困ったことあるから□□をやっておいたほうがいいですよ」
「過去の経験から▽▽はうまくいかない気がするので△△にしてみてはどうですか？」
「このチームに来て◇◇だなと感じています」

このように過去の経験や他チームからの視点を与えることができれば、チームの成長にもつながります。

活用のコツ3. レンタル先で行われるイベントに積極的に参加する

開発チームでは、ビジネスサイドを含めたプランニングや、チーム内での設計に関する議論など、さまざまな話し合いが行われます。レンタル移籍して来ると「前提知識がない」「知らない人が多い」という状況から、言動が控えめになってしまうことがあります。

しかし、レンタル移籍の目的である「知識共有」のためにも、積極的に「分からないことを質問する」「自分のチームでの取り組みを提案する」「問題提起をする」ことを行いましょう。議論の流れを止めてしまうのが怖い気持ちもありますが、外からの視点で参加することは、チームが気づけなかった新たな観点を提供し、議論を大きく進める可能性があります。

あなたの組織に合わせてカスタマイズしよう

レンタル移籍を紹介してきましたが「興味はあるけど、うちの組織では難しそう……」と思われた方もいるかもしれません。実はレンタル移籍は、組織の規模や状況に合わせて柔軟に形を変えることができます。

小規模な実践方法: 3ヶ月に1度たった1日だけ異なるプロダクトラインや役割を体験する「お試しデー」から始めることもできます。完全に別チームでなくても、普段とは異なる業務に触れることで視野を広げる効果が期待できます。
プロジェクト進行中の対応: 重要なマイルストーンやリリース直前には一時的に休止するなど、柔軟な運用も可能です。大切なのは「継続すること」であり、頻度や期間は組織の状況に応じて調整できます。

私たちの開発組織でも、レンタル移籍を始めた頃はたった1日だけのイベントでした。その頃（2021年10月）に収録されたポッドキャストもあります。ぜひ聞いてみてください👇