「Quipper開発チームに入って欲しい人」Rawquipper-cto-2.md前回、現在のQuipperの状況みたいのを書いたが、今回は、普段CTOとして、どういうことを意識して開発チームを作っているか、どういう開発チームになって欲しいと思っているか、というのを書いてみたいと思う。この辺り、自分自身の経験からくる「好み」とか「美学」みたいなものが強めな部分でもあるので、表に出すのはなかなか勇気がいるが、co-founder/CTOである自分のそういうところが、開発チームのカルチャーに当然影響しているし、一緒に働くことになる人ととはカルチャーのマッチがとても大事だと思っているので出してみる。以前、社内でなんとなく書いた文章があるのでそのまま出してみる。書いてある部分は、Web開発者/iOS開発者/Android開発者/デザイナー/インフラ等の人達を指している。欲しいタイプ最近色々な採用記事とか本とか読んでいても、自分の前職やQuipperでの実感からも、QuipperのようなWeb/アプリでサービスを作るような会社は、人間性/チームワーク/ビジネス理解みたいのが本当に大事で、(狭い意味での)技術力はその次かなと思うようになってきている。人間性/チームワーク/ビジネス理解みたいのがしっかりした人であれば、必要な技術力は入ってからでもなんとかなる、と思うところもある。(どうにもならない人がいるのも知っているので、そこはもちろん頑張って弾く)ただ、「技術力が低くてもいい会社」みたいに思っているわけでも全くないし、外からそう見られたくもないんだけど、伝わるかなあ。そもそも、Web/アプリ制作の場合、「技術力」というのが、コーディングだったり技術的な設計だったりの範囲を超え、技術者以外とのコミュニケーションや、ある程度のビジネス的な感覚まで含めたものだと思っている。別にそういうハードル(人間性/チームワーク/ビジネス理解)を設けたとしても、来る人の(狭い意味での)技術力が下がるような気は実はあんまりしていない。高くなることを期待すらしている。多少、分かる人には分かるでしょ、みたいな募集になってしまうかもしれないんだけど。今までも人間性/チームワーク/ビジネス理解みたいなハードルは自分の中ではあったつもりなので、それを表に出しちゃおうかなという感じなだけなんだけども。なんていうか、どのスタートアップぽい企業も同じような募集をしていているんだけど(XXXな言語使える/GitHubある/slackです/環境自分で選べます/椅子がいいです/企画に参加できます、みたいな)、Quipperはもう一歩先の採用ができるんじゃないかなーと思っているんですよね。descriptionとかに落とすのかよくわかってないですが、なんとなくそういう面を出せたらなあと思っています。的確ではない気がしてきたが。「QuipperのようなWeb/アプリでサービスを作るような会社」というのは、自社でサービスを作りそのサービスの対価を得るような会社であり、かつまだまだビジネスとして成長過程にあり、技術に特化したR&D部門のようなものを置くような規模ではないフェーズ、のようなニュアンスで書いた。してこう考えるかになったかだが、Quipperでは、開発者だけがQuipperサービスの価値を作っているわけではなく、そこに乗るコンテンツを作ったり、それを広めてくれるマーケティングや営業を行い、カスタマーサポートや学校への導入サポート等の人がいて始めて成立するものとなっている。教育(EdTech)、いいサービス/アプリだけで自動的に広まってくれるようなものではないというのが最近痛感していることだ。いった人や、お客さんであるエンドユーザーももちろん、直接、開発者自らが課題や要望を汲み取るべきだと思っている。いうことが得意なプロデューサーやディレクター/プロダクトオーナー/プロダクトマネージャー等と呼ばれる人達もいるのだが、開発者もそういう人達と同じ土俵でしっかりコミュニケーションするべきだと思っている。そんな中で、ビジネスやユーザー、開発チーム以外のことに全く興味もなくコードだけ書いていたい、みたいな人は厳しい。今のところそういうことができる人が結果的にQuipperに集まっている気がするし、これから人が増えていく中で、そういうところは変わらないようにしたいと思っている。技術力がいらないわけではなくて、高いレベルでサービスやアプリの開発、運用をする技術を持っていることは大前提ではある。別の角度からになるが、もう一つ、自分の好みとして、基本的に「伝言ゲーム」や「ハブになる人」みたいなのが好きではないというのがある。開発組織で起きがちなのは、エンドユーザーや社内の他チームからの問い合わせや要望を、開発者が目にするまでにフィルターし編集し開発者から直接見えないようにしたり、忙しい開発チームを邪魔しないように、非開発者は開発者に相談があるときでもプロダクトオーナーであるAさんを経由するべき、とかである。これ、開発者を守って生産性を上げるため、という一見前向きな理由で採用されがちなアイデアだし、実際、そういうのは開発者としては嬉しかったりもするのだけど、自社サービスを作るような会社では良くないし非効率だと考えている。間に置く人が多ければ多いほど、いろいろ情報(エンドユーザーの声だったり)は間違って伝わるし、自分の問題としてとらえづらい。そもそも、間に人を置くと、情報をどこかで間引かないかぎり、社内全体での必要なコミュニケーション総量が倍々になってくる。これが「ミーティングだらけ」の原因にもなったりするしとても非効率だ。コミュニケーションは基本的に面と面で、多対多のメッシュ状の組織であるべきだと考えている。同時になるべくオープンに行うべきだとも思っている。(これと指揮系統という意味での組織の形、たとえばフラットな組織がいいのかどうかみたいなのはちょっと別の話だと思っていて、どういう組織がいいと思っているのかは改めて別の回に書きたいと思っている)ただ、こういう組織であるためには、当然、開発者には非開発者としっかり話せることが要求されるし、ちゃんと非開発者とコミュニケーションできることが重要になってくる。いうこともあって、社内で効率的なコミュニケーションをするためにも、開発者のコミュニケーション力を期待している。非開発者にも、開発者とちゃんと話せるような、Web/アプリなどの基本的なところや、システム開発の難しいところ等を理解してもらうようにしている(例えば、「開発前に正確な見積もりは基本的に不可能!」とか)。そんな感じで、開発もしっかりでき、社内コミュニケーションもしっかりできる、そんな開発者をQuipperは求めている。あたりから、今すぐの転職を考えていなくても、まずオフィスに遊びに来るとかでも是非!次回Quipper、現在何人くらいの開発体制で、今後どのくらいの規模のチームを計画しているのか、どういう体制を目指しているみたいなところを書いてみたいと思う。