開発チームの規模

第一回で紹介したように、Quipperは、ロンドン、東京、マニラ、ジャカルタ、メキシコシティにオフィスがあり、そのうちロンドン、東京、マニラが開発拠点になっている。

内訳としては、以下の様な状況だ。

	Web	iOS/Android	Engineering	Design	Total
London	3	0	0	1	4
Tokyo	5	4	3	1	13
Manila	7	1	0	2	10
Total	15	5	3	4	27

30人弱。この規模から、今年中に3拠点合計で10人くらいの増強を考えている。拠点毎、職種毎の大まかな計画はあるが、いい人がいたら拠点/職種毎の採用の増減はある感じで、3拠点全職種トータルで考えて一番強いチームにしたい。

Engineeringは、Quipperでの呼び方で、インフラとか運用とかそういう感じのチームだ。最近だとDevOpsと呼ばれているものも近いだろう。

これらの直接開発を行うメンバーに加え、プロダクトマネージャー的なロールとして4人いる。

フラットな組織

開発組織は基本的にはフラットな形にしている。フラットと言っても、経験/技術力に差がないわけではないので、自然と各自が時と場合に応じてリーダシップを取るという感じだ。

フラットな組織はいつも魅力的に見えるし、なんか自由な感じがかっこいいし、自分自身も好きだし、とてもいいとは思っているのだけど、現実を見ると難しいこともあったりする。たとえば、明示的な開発リーダーみたいな人がいれば、その人が義務感や責任感を持って色々なことを主導していきやすいが、フラットだとそういうものに期待しづらい。そんなとき中間管理職的なポジションを置きたくなってしまう。

しかし、前回書いたように、自分の中の理想として、全員がしっかりユーザーや社内の非開発者と向き合い自分で課題を見つけ前面に立っていく、というのとフラットな組織は相性がいいと思っているので、しばらくはこの形で行きたい。また、上にも書いたように、特に会社として指名しなくても、時と場合に応じてリーダ的な存在は出てくるもので、それはそれでいい。

ただ、これができるのは、そこまで大きくなく強いメンバー/強いチームであるというのが大前提なので、そういうチームを維持できるようにCTOとして頑張りたい。

DevSupportという仕組み

Quipperの開発チームは、新規開発と保守運用と言った感じで役割を分けていない。全員で新規開発し、全員で保守運用をするというのが基本方針だ。

ただ、開発者にとって、新規開発の方が楽しいことが多いし、新規開発にはある程度のデッドラインみたいなものがあったりするので、保守運用に力が入らなかったりする。また一部の頼まれやすい人にそういうタスクが偏ってしまうのも程度を超えると問題だ。そこで、Quipperでは、DevSupportと呼ばれるちょっとしたゲーミフィケーション/見える化の仕組みを導入して、その辺を解決しようとしている。

これは、各メンバーに月ごとに達成すべきポイントが課せられ(通常10ポイント。新人やポジションにより例外あり。)、バグや、何かビジネス側のサポートが必要な案件(ちょっとデータを出して欲しいとか)が発生したら、まずGitHubにissue登録し、重要度/緊急度/難易度に応じて、ポイントが割り振られる(1/3/5ポイントとか)。各自が自分ができそうなのを選び対応しポイントを消化するという感じにしている。

ただ、いくつかこの方法に問題があって、ポイントが高くても、あまり人気の出ないタスクというのが一定数あるので、そういうのはこの仕組を回す責任者が、ある程度の強制力を持って開発者を指名して振ることができるようにしている。また、緊急事態が起きた場合には、これとは全く別に開発者全員で当たるなど柔軟な感じでやっている。

この制度を始めて6ヶ月が経つが、最初の頃はいまいち盛り上がらなかったが、最近はうまい感じで回ってきている。

これは、先月の様子だ。ポイントの管理はこんな感じでGoogle Sheetsで管理している。

1月のDevSupport

一番左端がオフィスを表しているのだが、T(東京)の人達が軒並み0ポイントなのは、今東京メインで行っているプロジェクトが佳境だからで、彼らが非協力的と言うわけではない！この辺のプロジェクトの波みたいのも全体的に柔軟にやっている。

開発者間のコミュニケーション

開発者のいるオフィスが3拠点に散らばっていて、かつロンドンは他の2ヶ所と比べ時差も大きいので開発者間のコミュニケーションは結構大変だ。密なコミュニケーションが必要な新規開発はオフィス毎にチームを作って行うことが多い。

余談になるが、以前、完全にオフィスを跨いでチームを作るということを試したのだが、さすがにちょっと厳しかったので今の形に落ち着いている。ただ、新しい仕組みや体制を失敗を恐れず導入し、失敗だと思ったらあっさりやめる、ということができているのはQuipperのいいところだと自負している。

ただ、オフィス毎にプロジェクトは別とは言え、どの拠点でも同じコードベースを触るし、上のDevSupportでは協力して行うこともよくある。また、GitHubでのpull-requestのreview/mergeみたいなものは国をまたぐのは全く問題なく、むしろ推奨している感じなので、そういうときには国をまたぐコミュニケーションもよく発生する。

また、SlackやGitHub issues上でも随時コミュニケーションをしているが、二週間に一度、開発者全員がSlackのあるチャンネルに集まり、文字チャットでのミーティングをしている。ここでの議題は誰もが提案することができ、日常のGitHubやSlackでは収拾のつかなかったものなどを中心に集中的に議論している。文字ベースのチャットにしているのは、20-30人での音声でのリモート会議かつ英語が得意ではない人もいる、というのは辛いというのがある。

日々のリリースとテスト

release early / release often ということで、月曜から木曜の間で毎日リリースを行っている。休み前リリースは怖いので金曜日はしていない。

半年くらい前までは、pull-requestのmasterへのmergeと同時に自動でリリースしていたのだが、いくつか連続してリリースでの問題が起きてしまい、対策として手動でのテストとセットでの一日一回のリリースに変更した。

もちろんテストコードでのテスト自動化も行っているが、それに加えて、テストケースに沿って人間がするテストを日々のリリース前に行っている。このテストは非開発者と開発者両方が参加することになっている。つまり、BizDevだったり営業だったりする人にもテストに参加してもらっている。

非開発者にも参加してもらっているのは、毎日のことなので、開発側の負担軽減のためという面もあるのだが、会社全体でプロダクトのことをしっかり意識するとか、開発者と非開発者の積極的な交流、細かい仕様の理解を非開発者にもしてもらうとか、どの辺が開発で大変なのかみたいなところもなんとなく感じてみて欲しいという意味がある。非開発者側も日々忙しいので、なかなか心苦しいことでもあるのだが、結果としてはなかなかいい取り組みになっている。

これは、前回書いた開発側も非開発側にどっぷり入って欲しい、ということの逆側で、非開発者も開発側に寄ってきて欲しいという考えから始めたことの一つでもある。

また、開発者/非開発者問わず、新しく入った人のプロダクト理解という意味でも、テストをして貰うというのはなかなかいいアイデアなのでお勧め。

2016年の開発

2015年の後半から後もう少しの間、受験サプリの移行というのが開発全体に占める割合が大きいのだが、これが一段落したら、Quipper開発が次のフェーズに入ることができると考えている。というのは、これが終わると日本でも大きくQuipperシステムが展開されることになり、今後の開発は日本を含む展開国(インドネシア、フィリピン、メキシコ)に向けた機能拡張と、さらなる新規国展開という2つの軸に整理されるからだ。ある意味でスタート地点に立ったとも言える。ちょうど今、機能拡張部分のプロダクトロードマップを作っているのだが、とてもおもしろい感じになりそうでワクワクしている。