はじめに
こんにちは、Forkwell 開発チームの tbaba です。最近は暑くなってきたのでドラムを叩くと汗が吹き出てむぎ茶を飲む手が止まりません。
今日は今年の2月くらいからずっと取り組んでいる、「デザイナーとの輪読会」についてお話しようと思います。
弊社には「デザイン戦略室」というチームがありまして、社内のプロダクトやビジュアル、広告のデザインからブランドエクスペリエンスの向上など、様々な制作を横断的に受け持っています。もちろん Forkwell や Crowd Agent などのウェブアプリケーション開発にも関わっております。
そんな彼らが行っている輪読会に、エンジニアである自分が入って何をやっているのか、どんな効果があるのか、をご紹介します。
どうして輪読会をやろうと思ったのか
元々は、デザイナーやカスタマーサクセスチームのみなさんが始めました。
「プロダクトを作っていく上で、エンジニアと会話する際に単語の説明をされてから会話が始まる（「Pumaが・・・あっ、Railsアプリケーションを動かしてるWebアプリサーバーなんですけど・・・」みたいな）、という無駄が発生する」ようなケースも多く、本質的な会話に至るまでに時間がかかることがあったようです。
そこで、エンジニアとの共通言語を増やして、コミュニケーションを取りやすくしたい！という気持ちから、サーバーやWebアプリケーションなどの知識を得るための輪読会を開始した、とのことです。
どうして絡みに行こうと思ったのか
最初はすっごく軽い気持ちで入っていきました。
というのも、元々自分が2020年秋頃から、ゆるゆるとLinuxそのものの再学習を進めておりまして、得た知識を復習したいという気持ちがありました。その目的に対して、輪読会で発言をするというのはとても効率の良い復習方法だと考えたのです。
また、自分の中で今期のテーマとして、「そうやって学習した知識を周りに広めていく」というものがありました。
やっぱり知識は得たなら広めていったほうが自分にとっても周りにとっても良い事だらけです。自分以外に出来る人が増えればそれだけ、チームが成長しますし、周りにとっても出来ることが増えるのはメリットです。
そんなわけで知識を広めていくのに良い機会だと感じたので、「俺も入る〜」とカジュアルに手を上げてみたところ、何やら歓迎されたので、するっと入っていきました。
どんな感じで進行しているの？
基本は事前に対象となる箇所を読んで来て、気になったところについて議論をする、というよくある輪読会の形式です。
少し通常のものと違うのが、「 tbaba がオブザーバーとして参加している」という点です。
何をやっているかというと、
- 読んできてよく分からなかった点をオブザーバーに聞く
- オブザーバーはこれに対し、「自社ではこうなっている」という風に回答する
ということをやっています。
なぜこの形式を採用しているかというと、元々の目的が「開発者との共通言語を得て、コミュニケーションを取りやすくするため」だからです。
例えば単にサーバーと言っても、「Web サーバー」「アプリケーションサーバー」「メールサーバー」などなど、多岐にわたります。また、「IP アドレスとは」「IPv4 と IPv6 って何が違うの？」という疑問もあるでしょう。
このあたりを、「Forkwell ではこう言う構成になっていて」「Crowd Agent はこういう風になっていて」という説明をはさみつつ説明していっています。自社プロダクトがどうなっているのかを伝えることで、より具体的な理解につながるのです。
何が変わったのか
単なる輪読会に開発者のオブザーバーを入れることでどうなったのか？これが気になるところだと思います。
というわけでアンケートを取ってみました。
まずは「輪読会の理解度」についてです。
参加者が少ないのと、社内のアンケートのため、公正とは言いづらいかも知れませんが、概ね高評価でした。以下のようなコメントも寄せられており、デザイナーが独自に輪読会を行うよりも効率良く学習を進められたのではないかと思います。
- 具体例を交えて説明していただいているので、イメージしやすくなった。
- Crowd Agent や Forkwell では実際どのようにサーバーが構築されているのか、実例を聞くことができたので、自分ごと化しやすかったです。
- 実務につなげていただいたり、実際の開発エンジニアが理解・関わる範囲を教えていただけるので、理解度が上がりました！
一方で、「開発者とのやり取りがやりやすくなったか」という質問も投げかけてみました。結果はこちら。
真ん中（よくわからない）から、右側（やりやすくなった）のあたりに留まっています。
これについては、まだサーバーのお話、つまりアプリケーション開発そのものよりも低レイヤーの話に終始しているためと思われます。今後アプリケーション開発についての輪読会が開催されれば、こちらも数値が変わってくるのではないかと思います。
個別のコメントとしては、好意的なものを頂いています。
- 「エンジニアのみなさんの意見や質問内容を理解した上でやりとりができ、進めやすかった」
- 「リファインメント（バックログを整えるミーティング）でのエンジニア同士の会話などに壁を感じにくくなった」
また、今後何を勉強したいかという話についてもアンケートを取ってみたところ、「ウェブアプリケーション」と「データベース」という2つが票を集めていました。やはり、ウェブアプリケーションのプロトタイプを作っていたり、データ集計・分析をしたりする際のことを考えると、この2つの優先度は高くなるのでしょう。
また、変わった点としてとても大きなものがありました。それは、「質問できる」という点です。
自分が加わるまではデザイナーやカスタマーサクセスと言った、普段エンジニアリングそのものには関わらないメンバーのみで輪読会をしていました。そのため、少し込み入った話が出てくると、誰も答えることができず、疑問解消しにくかったのです。
そこにエンジニアが入ってくることで、疑問を疑問のまま残さないで、輪読会の時間内にしっかりと解消することができるようになりました。これが、デザイナーがエンジニアリングを学ぶ輪読会を行う際に、エンジニアが同席する最大のメリットと言えると思います。
もちろん、エンジニアにとっても悪い話ではありません。人に説明するということは、自分がちゃんと理解していなくてはいけません。つまり、復習の機会になります。それに、デザイナーと一緒に学ぶということはそれだけコミュニケーションを多く取るということでもあります。そうやって一緒に学んだ時間は、きっとその後のコミュニケーションにプラスに働くことでしょう。
最後に少し別の話ですが、前半でも書いたように、今年の自分の中のテーマとして「学習した知識を周りに広めていく」というのがありました。これが少しでも広まっていくのがアンケート結果からも実感できたのが、かなり嬉しかったです。
まとめ
世の中のデザイナーの皆様の中には、エンジニアとコミュニケーションをして作る時に、「こいつ何言ってんだ」と思うときがある、という方もいらっしゃることでしょう。
しかし、それは今回の自分たちのように、一緒に学ぶ場を作ったり、歩み寄ったりすることで解消できることがとても多いと思います。
何か困ったことがあったらエンジニアに相談してほしいし、エンジニアも困りごとはデザイナーに相談するような信頼関係を持つことと、お互いがお互いの専門領域について多少なりとも知識を持つことで、円滑にお仕事を行っていけるような関係が持てると、かなり強いチームになれるのではないでしょうか。
正直そんなに深く考えないで始めた取り組みですが、今では「やってよかったし今後も続けたいなぁ」と考えております。
# そういえば、デザイナーがエンジニアに教える輪読会があっても良いかも知れませんね。
最後に
そんな grooves 社では現在、一緒に働いてくれるエンジニアを募集しています。
もし興味があれば、ぜひ一度ビデオ通話などでお話しをさせてください。
