こんにちは。プロダクト開発部介護キャリア開発グループの髙木です。
直近で新しいチームに移ったのですが、新しいチームで仕事をしやすくするために仕事の雑談というものを主導してやってみました。2か月ほどやってみたところ思っていたよりも感触が良かったので紹介させてください。
前提として、今のチームのプロダクト開発はリモートワークで進められており、同期的なコミュニケーションを取る頻度は朝会のみとなっています。それ以外は必要に応じて会を設定するような形になっています。
どういう課題を感じていたか
新しいチームに移った際、基本的にわからないことを埋める作業から始まると思います。
- このプロダクトで解決したいことはなにか
- どういうビジネスモデルなのか
- どういうアーキテクチャなのか
- どういうチームの体制なのか
これらのプロダクト周辺のことを解消しつつ、少しずつ開発に入っていくと思います。そして理解度が高まる中でいろいろな疑問が出てくると思います。
- そもそもこのプロダクトって〇〇と同じでは？
- 将来的にこういうビジネスモデルは保たなさそう？
- 先に解決するべき課題ってないんだっけ？
などなど。
加えてそれらの疑問は、新しく入ってきたメンバーだけでなく既存のメンバーの中にも自分なりに蓄積されています。それらの疑問や不安、アイディアを発散させる場として「仕事の雑談」という場を作ろうと思いました。
どういう場を作ろうとして何をしたか
1. 特定の人だけが話す場にしない
基本的にどういう会議でも話す人と話さない人に分かれ、話す人が偏りがちな問題はよく起こると思います。そのような偏りを許容するかどうかはさておき、この場においては偏りは極力減らしたいと思っていました。話す人が偏るとどうしても結論やテーマなど含めて偏りが出てきて、新しい観点や課題を持つことが難しくなると思っていました。あとはみんながどういう課題や考え方をしているかを知りたいという側面もありました。
そのために、話す人は場において2人としました。最初は3人で運用してみたんですが、3人にしてもひとりは話すタイミングが難しくなったので2人に減らしました。話す人はルーレットで決めて、ランダムにします。テーマ的に話してもらったほうがいい人がいればその人を指名しています。
2. 他の参加者が同じ情報を得られるようにする
話す人を固定すると、それ以外の人は話すことができません。それだと参加しないという選択肢もあるのですが、どう考えているかを聞いてもらったほうがいいと思っていました。録画があっても多分見ないし、そうなるなら1on1で良くなってしまいます。なので終わったあとに情報共有を受けるのではなく、ポッドキャスト的に聞いてもらうことを目指しました。
会議に参加しているのに何も発信しないことは良くないとされることがありますが、明示的に話さないことを良しとすることで会話を聞くことのみに集中できます。ポッドキャストやオーディオブックなどを聞いていると、頭の中でその話題について別途考えてしまうと思います。話せないがゆえに自分の中でテーマに対して別の考えを持てるようにもなるので、話す人・話さない人を決めるというのは有意義だと思いました。また話す人は決めるものの、差し込みたい話題が出てくることもあります。その場に参加しているがゆえに話題を深ぼる事もできるので、その場に参加している意味が出てくると思いました。
やってみてわかったこと
この取り組みの情報を整理します。
- 実施頻度：週1回
- 実施時間：30分
- 参加者：だいたい6人ぐらい
- 参加者のロール：開発者、プロダクトマネージャ、マーケティング担当
- 話す人：テーマを決めた人 + ルーレットでもう一人
正解を出さなくてもよい
自分の考えていることを双方ともに話していくことで、考え方の広がりや自分が持っている偏りを認識することができました。自分の考えの正しさを話すというわけではなく、正解のないものに対して考えを深掘るきっかけになりました。
想定していたよりもみんな話せる
話す人が2人しかいないので会が成立するか少し不安ではありましたが、実際にやってみると指名された人はそれぞれ自分なりの考えを持っていて、思っていた以上に話がはずみました。特定のテーマについて話す場合でも、それぞれの業務的な視点が違うと出てくる着眼点も変わるように感じました。
テーマを出すのが難しい
これらの取り組みにおいて毎回話題になるのがテーマ選びだと思います。ちなみにこの取り組みにおいてもテーマを出すことには苦戦しています。今のところだいたいは僕がなんとか工面しています。普段の業務からこのテーマがいいなーというものをピックしています。
実際に話したテーマを列挙してみます。ちょっと具体的すぎるものはぼかしています。
- このプロダクトでつくる価値と今の課題
- 競合プロダクトと弊社プロダクトの差
- 弊社プロダクトのターゲットとその理由
- ATSとは何？
- プロダクト開発部総会の深堀り
- 求職者がLLMを軸に活動する未来について
たぶん早々にテーマ切れが起こるので、業務の中での疑問を溜め込むための工夫などをしないと破綻しそうです。
テーマを出した人は話したほうがいい
テーマを出す人は、そのテーマについて何かしら思うところがあって出しているはずです。その人が感じている話題を掘り下げることで、他の人がその話題に対して発信しやすくなると思いました。事前に話題が決まっているケース以外では基本的にテーマを出した人ともうひとりを無作為に選出というのが良さそうでした。
続ける？ or やめる？
確実にやる価値があると思ったので続ける予定です。
プロダクトを開発していると視野が狭まっていく感覚があります。その視野を狭めずにプロダクトの方向性を決めていくのがプロダクトマネージャの役割だと思いますが、開発メンバーはどうしても目先の機能やプロダクトに対してのみ目線がいきがちになります。開発メンバーの視野を改めて広げつつ、今やるべきものにフォーカスを揃えるということは、なぜ今やるのかを見直すきっかけになり開発の質を上げることにもつながると思います。
またプロダクトを主導する側の視点に立つと、開発メンバーの持っているプロダクトへの解像度や将来性について考えていることをインプットできる機会はそう多くありません（もちろん1on1などを実施することで解消することもできるとは思います）。各々がどう考えているかを聞くこともできますし、自分が足らない知識を得ることもできます。
加えて職種を越境して会話を行えるため、マーケティングの観点や開発者の双方の課題感を1つのテーマについて話し合えるので、課題に対して一方向からの議論にならないのも良いと思いました。これは当初想定していた効果でしたが想定通りよかったです。
いろいろ書きましたが、僕が想定していたよりもかなり価値の高い取り組みになりそうだと思いました。
最後に
チームで開発をしているといろいろと課題が出てくると思います。課題を直接的に解決するのか間接的に解決するのかによって、とれるアクションは変わってくると思います。今回の施策は間接的な施策によってチーム全体の練度を高めていく施策だと思います。こういう施策を考えられるか・実践できるかによってチームでのプロダクト開発のしやすさは変わっていくと思うので、今後ともこういうことは試していきたいと思います。
