フクロウラボの開発チームのキーワードはチームワーク
これまでフクロウラボの開発チームのメンバーのインタビューで共通して語られてきた、仲間と開発する喜びや安心感、勉強できる環境。これらを俯瞰してみると、ひとつのキーワードが浮かび上がってくるようです。CTOの若杉さんにお話を伺いました。
一定のパフォーマンスを出すためのチームワーク
──今日は、フクロウラボの開発チームについてお話を聞きたいと思います。もしも開発チームで大切にしていることをひとつ挙げるとしたら、何でしょうか？
キーワードとして挙げるとすれば、「チームワーク」です。
──確かに、オフィスにいくとみなさん仲良く話したりしている姿が印象的ですね。
そうですね。けれど、僕らが考えるチームワークの定義は、仲が良いといったものとは違います。バグや障害などのトラブルがあった際、または、成し遂げるべき共通の目標がある時に、チームの各メンバーそれぞれの役割を明確化し、その役割を各々が全うしつつ他のメンバーとの連携を図る。結果として、チーム全体でパフォーマンスをあげるということを意図しています。
──なるほど。
極端な話ですが、仮に仲が悪くても、能力やスキルレベルが揃っていなくても一定のパフォーマンスが出せることをチームワークと定義して、そのための取り組みをいくつかやっているんですよ。
辛い仕事ほど分担する
──ぜひ、聞きたいです。どのような取り組みなのでしょうか？
まず、ペアプロやモブプロです。
──以前インタビューでもペアプロの話がでてきました。複数人でコードを書くこと、ですよね。
そうです。常に複数人でコードを書くのではなく、何か壁に当たってしまったり、開発が滞った時、いわゆる"ハマってしまった"時にこそ、ペアプロやモブプロをやると効果的だと考えています。そこで、一緒にコーディングをしてもらって解決するのがペアプロやモブプロです。楽しく順調に開発を進められている時はひとりでやったほうが効率が良いですが、やはり開発の進捗が遅れ気味なタスクや他のメンバーもあまり取りたがらない面倒なタスクをペアプロ/モブプロで分担すると良いと感じています。
また、自分の想定では問題ないはずだけど、どうしてもうまく動かない、といったシーンはカジュアルにメンバーに相談した方が良いですね。
──そうなんですか？
「どうしてこんなことに気づかなかったんだ？」とあとから思うようなケアレスミスが割と多いです。また、他のメンバーの自分とは違う発想で、あっという間に解決するというようなことも多いですね。自分でひたすら調べて苦しい思いをするよりも、誰かに指摘してもらえた方がチーム全体としてのパフォーマンスは上がっていくと考えています。
中には、そういったスタイルだと優秀なエンジニアが足を引っ張られ、優秀なエンジニアがフルでパフォーマンスを出せないことの方がチームへ悪影響があると考える方もいるかもしれませんが、僕らは、優秀なエンジニアがフォローやメンバーとの連携を強めることで、長期的にはチーム全体のパフォーマンスが上がっていくという考えをベースにしています。このあたりがフクロウラボのエンジニアチームのカルチャーになります。
──他にも取り組みがあれば教えてください。
もうひとつ似たようなものだと、コードレビューがあります。何かを開発した後にGitHubにあげて、コードをレビューしてもらうことをコードレビューと呼びます。間違いがないかなどを自分以外の人にチェックしてもらうんですね。コードレビューそのものは珍しいことではないのですが、フクロウラボらしいのはレビュアーを2名以上巻き込めることです。
──2名以上でコードレビューをするとどんなメリットがあるのでしょう？
ひとつは、レビュアーの負荷を軽減できることです。開発者が一名、レビュアーが一名だと自ずと一対一の関係になってしまい、意見を言いづらかったり、レビュアーの責任が重くなりがちだったんです。あと、稀にですが、開発の方向性で意見が割れてしまうこともありました。そういった際には、チーム全体に意見を求める事もできるような体制にしました。その体制になる前は、意見が割れた時はどちらかが妥協してモヤモヤを抱えたまま、コードがデプロイされることもありました。モヤモヤやストレスを抱えたままにするのではなく、割れた意見の双方の考え方をメンバーに晒してディスカッションする。そうすると、多様な価値観で揉まれてからの決定になります。「その側面で考えると、確かにそっちの実装の方が理にかなっているかも」など、自分とは違った価値観も知る機会にもなりますし、決定に対する納得感が違います。モヤモヤも発生しにくいと感じています。
──ペアプロ、モブプロでも気になったのですが、それでは工数が多くかかってしまいませんか？
すべてのタスクをそうやっているわけではないのですが、確かに余計に時間がかかることもあります。このあたりの考え方は、会社の規模やステージ、状況によって柔軟に変えていくべきところであるとも思います。現状のフクロウラボの状況では、余計にかかった時間よりも、得ているものが多いという実感はあります。このあたりは数値化が難しいのですが、単純に開発スピードが速いかどうかだけでなく、業務における不公平感やストレス低減も考慮に入れ、長期的な視野でチームとしての効率化を計りたいと考えています。
──チームワークを大切にした働き方をすることで、結果効率的に働くこともできているんですね。
自分がやっていて楽しいこと、ためになったことを共有する
──ここまではどちらかというと辛い仕事や、難易度の高いタスクを分散するためのチームワークについて聞かせていただきました。もうひとつ、フクロウラボの開発の方から聞くのが「勉強しやすい環境でありがたい」という声です。
楽しいことや、ためになったことを共有するという意味でのチームワークですね。定期的に、勉強会やLTを行っています。
──具体的には、いつやっているのでしょう？
勉強会は、朝練のようなイメージで朝の9時から10時にやっています。例えば、「木曜日はReactの勉強をしよう」とか主催者がテーマを決め、興味があって参加したい人のみで集まって一緒に進める感じです
──ちょっと意地悪な質問ですが、勉強自体は各々でやってきてもいいものですよね？
そうですね。もちろん個々で能力開発は自由ですし、1人で進めたい人は、それでも良いです。ただ、「これ勉強したいのだけど、興味ある人いる？」と投げかけて賛同してくれる人がいるのであれば、一緒にやった方が、教えたり教えられたりで理解が深まりますし、1人よりも継続もしやすいですよね。
──なるほど。LTはどのようにして行っているのですか？
LTは個人で学習したことや、仕事をしていて気づいたことなどを共有する場です。負担にならないように、発表したい人が発表するスタイルをとっています。最近読んだ書籍を紹介してくれる人もいるし、流行っている言語を使ってみた感想をシェアしてくれる人もいます。
──みんなで学んだほうがいいことはみんなで学び、そうでないものは共有できる場があるということなんですね。
フクロウラボの開発チームにおけるチームワークとは
──ここまでお話を聞いてきて、辛いことはみんなに分散して、いいことは共有しあうというチームワークが業務の質や効率をあげていることがわかってきました。若杉さんが感じていらっしゃる効果はどのようなことですか？
まだ会社がマンションの1室であった時は、チームワークという概念は存在しておらず、”属人化上等”でただひたすら最速でプロダクトをリリースすることのみを考えていました。そういった環境下で求められるエンジニア像は、ロールプレイングゲーム(RPG)で言うところの勇者や賢者のようなあらゆる業務や課題を解決できるフルスタックなエンジニアでした。そこから、事業が軌道に乗り、開発チームの人数も増えてきてから、「これからのフクロウラボのステージでは、それぞれの個性やユニークなスキルを組み合わせて、ちょうどRPGのパーティ編成をするように、メンバー間の連携を重視して開発を進めていくべきでは？」と考えるようになりました。それから、チームワークを意識するようになり、会社組織全体が成長していっている環境でも、なんとか不協和音を生み出さずにチームを運営できているのではないかと考えています。これからは、正社員だけではなく、手伝ってくださる業務委託の方も含め、共に成長ができるような環境が作れたら面白そうだなと考えています。社内外含め、いろいろな人たちとチームワークを築ける環境を整えて行きたいと思います。