誰のために、何のために開発するかを考える。70名規模の開発部長からスタートアップのチームビルディングに挑戦する理由【社員インタビュー】
「アッテル」を開発するエンジニアチームは、現在新たなサービスの基盤づくりをしていく成長フェーズ。チームとしてのプロダクト開発に向けて舵を切っているところです。
EdTechベンチャーの開発部長として70名規模のエンジニア組織のマネジメントを経験し、現在はアッテルのチーム開発を牽引している永田に、エンジニア組織作りに対する思いや今後の取り組みについて聞きました。
ー現在の業務内容を教えてください。
現在は開発業務そのものよりも、チームの生産性を上げるところに主に取り組んでいます。立ち位置としてはスクラムマスターに近いかもしれません。アッテルのエンジニアチームは一人一人の技術力が高いので、プロダクトがtoC向けに拡大している今のフェーズでは、誰が何をどのようにやっていくかというところがとても重要になってきています。これまで個々の力で進めていたところをチームとしてやっていくために、「誰かが開発している部分をみんなが理解して、一緒に考えながら進めていける体制づくり」をしている最中です。
プロダクトを作るにはコードを書くことはもちろんそうですが、企画であったり、チームとしての改善であったり、ユーザーの要望を取り入れることであったり、さまざまな取り組みが必要ですよね。自分ができることはすべてやってみたいと思っています。ただ全部を今すぐにやることはできないので、今のフェーズで一番必要だと感じた役割に力を入れているという感じですね。
ーエンジニアチームのカルチャーはどのような感じですか？
チームはそれぞれ自分をしっかり持っている人が多くて、落ち着いた雰囲気です。個の力はすごく高いのですが、チームとしての生産性という観点ではまだまだこれから、伸びしろがある状態だと思います。
現在（2022年10月時点）アッテルは、原則フルリモートですが、エンジニアチームでは定期的（月1回程度）にオフラインで集まる機会を設けています。私が入社したタイミングで、顔を合わせる機会を作りたいと話していたら、意外と他のメンバーも賛同してくれて実施することになったという流れです。初回はもくもく会のような雰囲気でしたが、せっかくの機会なのでディスカッションをしようということになり、普段の会話の中で【今話す緊急性はないけれど、重要なことなのでどこかで整理したい】というようなことをアジェンダに積んでおいて話す時間にしています。たとえばエラー通知のトリアージをモブ作業で一気にやりきったり、ワーキングアグリーメントをつくってチームの方向性を合わせたり、開発フローやルール、プロダクトロードマップの運用で改善したいことを話して決めたりなどですね。
ーアッテルに入社されるまでのご経歴を教えてください。
新卒で受託開発をメインとするベンチャー企業にエンジニアとして入社したのが最初のキャリアになります。そこではコードを書くほか、サーバーを自分で構築したり顧客折衝をしたり、幅広い経験をしました。そのうち受託ではなく自社サービスに携わりたいと思うようになり、クラウドソーシングサービスの企業に転職しました。そこでユーザー視点にこだわったプラットフォームづくりを考えるようになりました。
また、新卒採用や教育・育成にも携わるようになったことから教育というものに対して興味がわいてきて、何かエンジニアリングの力で解決できることがあるのではないかと考え、所謂EdTechの企業に転職しました。そこでは開発に加えてチームビルディングにも携わり、開発部の部長になった時には100％マネジメントにコミットするようになりました。
70名規模のエンジニア組織の採用、育成、評価に携わっていたのですが、エンジニア組織においてはあまりトップダウンのマネジメントをしようとしすぎず、任せる方がうまくいくと思っており、それにはメンバーを継続的に観察することが重要になります。コロナ禍になり、それまで対面で話すことで把握できていたメンバーの細かな変化等に目が行き届かなくなってしまってオンラインでのマネジメントの難しさに直面しました。私自身が苦労した経験も含め、同じような課題感を持つ人たちをプロダクトの力でサポートできる仕組みがないかと考え始め、HRTechに興味を持つようになり、その中でアッテルと出会いました。
ー前職で意識されていた「あまりマネジメントをしようとしすぎない」とはどのようなことですか？
例えばセールス組織は、実際にトップが成功した方法を下に伝えていくことでその会社のベストなやり方ができていくものだと思います。一方でエンジニア組織は、技術にも流行り廃りがあり、エンジニア一人ひとりも強み弱みがあるので、必ずしも上長の経験したことがベストプラクティスではないことが多いんです。そのような不確実性の高い状況の中で、メンバーみんなが自分たちで何がいいか考えてやっていく、マネジメント側は個々のメンバーを信頼して任せながら、障壁があれば取り除いていくというやり方がベストではないかと考えています。
ーアッテルに入社した決め手はなんですか？
前職でマネジメントに専念するようになって2年、再びプロダクトに近いところでやってみたいと思うようになったタイミングでもあり、会社の規模的にもプロダクト的にもアッテルがマッチしていそうだと思い転職を決めました。HRTechというレッドオーシャンの中で、アッテルにしかできないことをやっているのがシンプルにおもしろいと思ったんです。
また、面談・面接で会う人会う人がすごく自然体だったことも魅力でした。採用面接だと「ぜひ来てほしい」という思いが期待値の高さにつながり、逆にプレッシャーに感じてしまうこともありますが、そういった雰囲気ではなくてフラットに歓迎してくれている印象があり、自分も肩の力を抜いて新たな気持ちで働けそうだなと思いました。
実際に入ってみて感じたのは、代表との距離が近いということ。エンジニアが直接代表の塚本に声をかけていろいろ聞いたりしています。大きな企業だとなかなか社長と話したりできないので、これはスタートアップの大きな利点だなと感じます。
ー一方で、課題だと感じたこととそれに対する取り組みを教えてください。
やはりまだまだチームとしての生産性を上げられていないところです。エンジニアチームもそうですし、会社全体でもビジネスサイドと開発サイドの交流の機会がなかなかなく、ビジネス課題に対してエンジニアリングで解決していくというような交わるポイントが見つけにくい状態ですね。そこをもう少しカジュアルにできるといいのかなと思います。
取り組みとしては、まず機会や場の設定ですね。当初はエンジニアチーム全員で話す機会が週一の定例の場しかなく、話すことが多すぎて何がゴールの会議なのかわからないまま時間が来て終わってしまうという課題感がありました。現在は、しっかり議論をするときと、少しカジュアルにプライベートな話を交えるときを使い分けています。各メンバーと1on1をするときも、特に困っていることがないときは雑談をする時間にしています。接点を作りコミュニケーションを取るという基本的なことから始めていっています。
ーどんな人がアッテルに向いていると思いますか？
いくつかありますが、まず「チームとしての生産性を意識できる人」ですね。チームのパフォーマンスをどう上げていくか、自分以外の人が書いたコードの品質をチームでどう担保するか、そういったことを一緒に考えてよいチームをつくっていけると嬉しいです。
次に、働き方の裁量が大きいので、タスクを与えられてやるというよりは自分で見つけていくやり方ができる人です。触れたことのない技術にも興味をもって積極的にチャレンジしていける方だといいなと思います。
最後に、アッテルのミッション「働くすべての人が、活躍できる社会を作る。」に共感してもらえることが何より大切だと思っています。エンジニアってただ開発するだけではなく、誰のために、何のために開発するのかがすごく重要なんですよね。自社プロダクトを持つ会社として、そこを一緒に考えてつくっていける方と働きたいと思っています。
最近、エンジニアチームのワーキングアグリーメントのドラフトをみんなでつくったので、こちらを見てうなずいていただける方はマッチしているんじゃないかなと思います！(随時アップデートしています)
■ スクラムチーム内でわからないをなくす
それぞれが今やっていることを見える化する
設計レビュー、コードレビューは2人以上で行う
レビューやディスカッションに必要な最低限のドキュメントは作る
必要だと思ったら気軽に相談し合う
Slackのリアクションは活発に
コミュニケーション手段にとらわれず、目的に集中する
■ 改善し続ける
生産性を向上させるためのプロダクト運用改善
自分たちに合ったアジャイル開発を模索し続ける
既存の仕組みにとらわれず、新たなソリューションを模索する
よいと思った技術/便利ツールを積極的に活用する
振り返りを重要視する
フィードバックが受け取れる場をつくる