7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

事業会社R&Dにおける「自律型チーム」の作り方 ~リーダー3ヵ月育休でも進化を続けた、好奇心とオーナーシップが駆動する組織~

7
Last updated at Posted at 2025-12-21

この記事はHTアドベントカレンダー22日目の記事です。

はじめまして、博報堂テクノロジーズでNLP(自然言語処理)のR&Dチームリーダーをしている森川です。

私を含め5人で構成されるNLPチームでは、博報堂DYグループの社内プロダクト向けに、主に以下の開発・運用を行っています。

  • リスティング広告文(検索エンジンのスポンサー欄)を生成するLLM
  • 広告文評価モデル
  • 入稿する広告文セットの最適化モデルの学習と評価
  • 広告運用実績に基づく自動レポーティングシステム開発

研究開発(R&D)とソフトウェア開発の両方の側面を持つ私たちのチームですが、今回は技術の話ではありません。「事業会社内部のR&Dチームならではのマネジメント」 について書きたいと思います。
特に、「トップダウンでタスクを落とすのではなく、メンバーがプロダクトに興味を持ち、自律的にタスクを作り出し動くチーム」 をどうやって作ったかがこの記事の主な内容になります。

その結果として、チームリーダーの私が今年6月〜9月の3ヶ月間の育休を取得しても、チームは問題なく(むしろ元気に)機能しました。
育休前に予定したタスク全てを完了させただけでなく、下期のリリースを目指した新しいタスクまで設定して開発を進めていた事例を共有します。

私たちの会社はフルリモートなので、東京の会社に勤めながら、私は愛知から、ひとりは京都から仕事をしています。フルリモートだからこそのマネジメントの難しさとその対策も絡めて話そうと思います。

1枚でまとめると

時間の無い方向けに1枚でまとめました(Nano Banana Proは優秀ですね)。
本文では具体的な事例なども取り上げていますので、そちらも読んでいただけると幸いです。

Abstract.png

「好奇心」こそが仕事を楽しくする

私は、仕事を楽しむための最大のエッセンスは「好奇心」 だと考えています。「興味」と言い換えても構いません。

言われたものをただ作るだけのトップダウンの仕事では、モチベーションは上がりませんし、効率も悪く、何よりまったく楽しくありません。

私を含めたエンジニアが仕事に対して自分ごととして向き合い、楽しみながら効率的に成果を出すための鍵。
それは、技術だけでなく「プロダクトの未来」や「会社の今後」に興味を持ち、自分たち自身で「誰にどんな価値を提供するために何を開発するか」を決めることだと考えています。

事業会社であるからこそ、自身の事業(プロダクト)の行く末が自分たちの待遇にもクリティカルに影響します。
そのため、自分たちがモデルを提供しているプロダクトや、それを使ったビジネスを行う会社自体に興味を持つことが大切になってきます。

とはいえ、プロダクトや会社に興味を持ち好奇心駆動でチームが走り出すためには、「自分の意見を言ってもいい」「エンジニアがプロダクトの未来に口を出してもいい」と本気で思える環境が欠かせません。
好奇心があるだけでは行動につながらず、安心して探求できる土壌があってはじめて形になります。

少し話がそれますが、Googleが「効果的なチームを可能とする条件は何か」を見つけるために行なった「プロジェクト・アリストテレス」をご存知でしょうか。

このプロジェクトの中で、成果の出るチームとは「チームがどのように協力しているか」が重要であり、成果につながる要素として以下を挙げています。

  • 心理的安全性: 「無知、​無能、​ネガティブ、​邪魔だと​思われる​可能性の​ある​行動を​しても、​この​チームなら​大丈夫だ」と​信じられるか​
  • 相互信頼: チームメンバーが、時間内に​クオリティの​高い​仕事を行うと信頼できるか
  • 構造と​明確さ: 職務上で​要求されている​こと、​その​要求を​満た​すための​プロセス、​そして​メンバーの​行動が​もたらす成果に​ついて、​個々の​メンバーが​理解している​か
  • 仕事の​意味: ​仕事その​もの、​または​その​成果に​対して​目的意識を​感じられるか
  • インパクト: 自分の​仕事には​意義が​あると​メンバーが​主観的に​思えるか​

この記事で述べる内容は、この中の 「心理的安全性」「相互信頼」「インパクト」 の3つに対応しています。
次章で紹介する"心理的安全性づくり"と"未来を議論する場"は、メンバーの好奇心と自律性(オーナーシップ)を引き出すことで、「心理的安全性」「相互信頼」「インパクト」 を高めるための取り組みになります。

まずは土台作り:建設的な議論のための「心理的安全性」

Googleのプロジェクト・アリストテレスでも述べられているように、自律的に駆動し効果を出すチームの土台になるのは「高い心理的安全性」です。
「心理的安全性」は「対人リスクを取れる状態」であり、簡単に言えば、失敗したりわからないと発言してもダメなやつと思われないと信じられる状態です。

そのために、私たちのチームでは以下の取り組みを行なっています。

  • 相互尊重/信頼の構築: 朝会や1on1での自己開示を通じてお互いを知る
  • コミュニケーションの質の向上: カメラONで非言語的な反応を得る

自己開示による相互尊重

色々な本でも述べられていますが、自己開示こそがお互いの関係を良くしていく上での基本だと考えています。
特にリモートワーク中心だと、自然発生的な雑談や飲み会がない分、その重要性は高まります。

私の場合は、チーム全体の信頼関係を構築するために、まず毎日15分の朝会の中で雑談を積極的に振っていきました。

「麻雀大好きで横浜まで遠征した」「今度イタリアに新婚旅行に行く」「うちの猫は世界一かわいいよ」といったプライベートな話を、まずは私(リーダー)から積極的に話しました。自分が最初に自己開示することで、メンバーも話しやすい雰囲気を作ります。
毎朝数分程度のちょっとしたことですが、少しするとメンバー自身からも雑談を振ってくれるようになります。

全体で話しにくいような内容は1on1の場を使って話します。
1on1はその名の通り1対1の場なので、リーダーとメンバーの間の信頼関係の構築に有効です。
前回の1on1でなんとなく話した話題を覚えておいて、「前回話した⚪︎⚪︎について調べてみたよ、面白いね!」など話すことで関係性を構築できます。
関係構築ができてきたら1on1の場は「構造と​明確さ」や「仕事の​意味」に対応する「目標設定・キャリアパス相談」や「メンバーの持つエゴ(成長したい、外部発信したい、稼ぎたい、家族と過ごしたい、などの欲求)と業務の紐付け」などに使いますが、記事の内容から外れるので割愛します。

コミュニケーションの質の向上

フルリモート環境では、カメラOFFの会議が続くと相手の反応が見えず不安が蓄積します
特に心理的安全性が低い状態だと、カメラOFFで不安が煽られ、さらに心理的安全性が下がるという悪循環に陥ります。

そのため、表情・うなずきなどの非言語的な要素を確認できる「カメラON」でコミュニケーションの質をオフラインに近づけることが理想ですが、強制すると「なんでカメラONにしなきゃいけないんだ!」と反発が生まれてしまいます。
その理由は様々ですが「監視されている気がする」と感じる方もいます。
本人は言葉にしなくても心の中にしこりが残り、そのうちカメラOFFに戻ってしまいます。

なので強制はせず、以下のステップで進めました。

  • まずは「私は反応がみえる方が嬉しいのでカメラONで参加します」と宣言して自分はONにする
  • スクラムイベントだけ、他の会議も、と徐々にONの時間を増やす
  • 「顔を見て話すと安心する」という体験を積み重ねてもらう

そうする中で、考えに同意してくれる人から順にカメラONで参加してくれる人が増え、今では全員がカメラONがデフォルトになり、フルリモートでもオフラインに近いコミュニケーションの質を確保できています。

全員で「未来」を議論する場の設計

心理的安全性という土台ができたら、次はメンバーにプロダクトに興味を持ってもらうフェーズです。プロジェクト・アリストテレスにおける「インパクト」と「相互信頼」に対応する取り組みです。

私たちはそのために、PO(プロダクトオーナー)を巻き込んだ「方針検討会」をオフラインで隔週開催し、全員東京の会社に集まって議論しています。

会議は2時間〜3時間程度。長い時は4時間以上。

スクラム開発としてはとんでもなく長い会議ですが、遠方から出社したうえでそれだけの時間をかけるだけの価値があると考えていますし、実際に結果が出ている実感があります。

目的は「オーナーシップ」

この会の目的は、あえて時間をかけてチーム全員で上流のロードマップから議論することで、議論し決定した内容に対して全員が納得感と責任感(オーナーシップ)を持てる状態を作ることです。

そうすることで、プロダクトそのものの狙いやタスクの背景を深く理解できるだけでなく、自分の仕事の成果が会社へ与える影響を理解できるため、プロダクトの行く末に興味を持つ土台ができていきます。
また、全員参加で長時間議論することでお互いの考え方や嗜好などが見えてきて、メンバー間のリレーションの構築にも役立ちます。

バックログの裏側にある「方針」を話す

この会はスプリントセレモニーの 「リファインメント」 の位置付けにしています。
バックログの内容だけでなく、その背景となる方針(ロードマップ)についても議論していきます。

  • プロダクト自体の今後のロードマップはどうなっているか
  • プロダクトをもっと良くするためにできることはないか
  • 競合の動向はどうか

タスクそのものだけでなく、「そのタスクが生まれた背景」や「プロダクトの未来」 について議論することがこの会議のキモであり、メンバー全員がプロダクトに興味を持つための重要なポイントです。

全員で意見を戦わせる

会自体にはあえて事前に議題を提示せず、各々が話したいことを持ち寄って話します。

  • リーダーやPO:「来年度こんなことやろうと思っているんだけどどうかな」
  • PO:「新しくXXXを効率化するためにこんなシミュレータ作りたいんだけど」
  • メンバー:「広告運用プロセスのXXが本当に効果あるのか調査したい」

大小様々な議題を持ち込み、POもリーダーも新人も立場に関係なく意見を出し合い、議論を戦わせ、結論を出していきます。

理想論に聞こえるかもしれませんが、先述した心理的安全性さえ高ければ実現します。
私たちのチームでは、若手社員がテックリードに対して「それは違うと思う」と素直に言って議論を戦わせています。

フルリモート下でのオフライン会議

「フルリモート環境でオフライン会議」はハードルが高いと思うかもしれませんが、実はそれほど難しくありません。
心理的安全性さえ高ければ、リーダーから「オフライン会議で方針検討会やってみたいんだけど」と提案すれば1,2回お試し開催することは可能です。
あとはメンバーにその会が有益だと感じて貰えれば自然に継続開催できるので、最初だけはリーダーが議題を提示&ファシリテートして意味のある会議にします。
その後、毎回「話したい内容ある方いますか?」と聞いて議題を提案させるように意識付けし、少しずつメンバー主導の会議に方向転換していきます。

結果:マネジメントのスタンスと自律性

心理的安全性を高めたうえで、タスクだけでなくその背後の方針(ロードマップ)自体も議論する仕組み を作ることで、単に仲が良いだけでなく、メンバー全員が会社やプロダクトの半年・一年先を見据えて開発を行える、自律的に動くチーム になっていきます。

これらの取り組みを通じて私が意識していたのは 「リーダーはざっくりした方針は示すし決断するが、メンバーをリスペクトしてやり方は任せる」 というスタンスです。

私はリーダーは「メンバーを管理し動かす人」ではなく 「素晴らしい実力を持ったメンバーたちが動きやすい環境を整える人」 だと考えています。
メンバーへのリスペクトを持ち(実際、私より高い技術力を持った優秀なメンバーばかりです)、メンバーを信頼してやり方は任せ、リーダーは要所要所で方向修正をするだけの、縁の下の力持ち的な存在であれば良いと思っています。

最近読んだ本でこれらが 「サーバントマネジメント」 と呼ばれることを知りましたが、まさにこの考え方が私にはピッタリとハマりました。

おわりに

「サーバントマネジメント」を土台にしつつ、メンバー全員が安心して議論を戦わせられる心理的安全性を確保し、未来のプロダクトを議論する仕組みを作る。こうすることで私たちのチームは高い自律性を持って行動できるチームになりました。

その結果、私が3ヶ月の育休を取得した際も大きな混乱なく開発が進んだことは、チームメンバー全員のオーナーシップの賜物です。

こんなに素晴らしいチームメンバーたちと一緒に働けることと、最後まで読んでくださったみなさまに感謝を伝え、この記事を終わりにしたいと思います。

余談

記事の大仰なタイトルは、記事の内容と「Qiitaに投稿するよ」というコンテキストを与えてLLMに考えさせたら出てきました。

確かに技術記事で見かける表現だなぁと思いつつ、LLM開発に携わる人間としてはその進化に目を見張るばかりで、どうやって事業に活かしていくかに日々頭を悩ませています。

(おしまい)

7
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?