多様なバックグラウンドを活かした開発チームを紹介します。

こんにちは、atama plusでスクラムマスターをしている松村@Aloeoooです。先日、「開発1週間に密着～Slackもミーティングもバックログも全部見せ～」という、主に”Oyakataチーム”と呼ばれる開発チームでの開発の様子について紹介する記事を書きました。

多くの方に見ていただき、ありがとうございました。

今回は、同じくOyakataチームのメンバーが、それぞれの強みを活かしながら開発を進めていく様子について紹介したいと思います。

開発体制

まずはじめに、atama plusの開発体制についてご説明します。atama plusでは、以下のような開発体制をとっています。

今回のnoteでご紹介するOyakataチームは、atama＋（生徒さん向けプロダクト）を開発する「アプリチーム」に属しています。

アプリチームはLeSS Hugeをベースとした大規模アジャイルで開発を行っており、現在はatama＋をはじめとするプロダクトを開発する5チームと、開発効率向上などの技術中心で解ける課題に専念する開発基盤チームの合計6チームで構成されています。

Oyakataチームは、エンジニア3名、UX/UIデザイナー2名、QA(Quality Assurance)1名の6人から成るチームです。

エンジニアはITコンサルやスタートアップ出身であったり、OSSコントリビューターがいたり、UX/UIデザイナーは元々Webエンジニアを経験していたりと、バックグラウンドは様々です。メンバーのnoteはこちらになりますので、よければご覧ください。

Oyakataチームの開発活動を支援するスクラムマスターとしてチームを観察していると、それぞれのバックグラウンドや強みを活かし、チームとしてうまく作用していると思う場面が多々あります。

今回はそんなOyakataチームのメンバーが、どのように互いの強みを活かして活動をしているかを紹介したいと思います。

補足：意外に思われるかもしれませんが、atama plusでは開発チーム内で職種ごとの明確な役割分担は行っていません。それぞれの得意を活かしながら、開発を行っているという前提でこの先読み進めていただければ幸いです。（詳しくは以下のnoteをご参照ください）

OSSコントリビューターが技術力でチームを引っ張る

はじめに、エンジニアが強みを活かして活動している例をご紹介します。

atama plusでは、スプリントプランニングにてチームで選択したPBIは、個々人のタスクとして割り当てはしていません。日々のデイリーミーティングでそれぞれのPBIの消化状況を確認して、全員で完了できるように取り組みます。

そのため、技術力が高くタスクの消化スピードが早いエンジニアは、率先して様々なPBIの開発を進めたり、他の人のフォローに入ったりしてチームを引っ張ります。

このようなエンジニアは、PBIタスクをこなす他にもチーム内でワークショップを行ったり、開発リソースの一部を環境整備に充てています。最近では、テストコードを書く活動を広めていき、チームとしての開発のレベルアップに大きく寄与しています。

そのような活動を行った際には、チームメンバーからもレトロスペクティブ（毎スプリント後に行われる振り返りのミーティング）で、以下のようなフィードバックが出ていました。

また、テストコードをチームで書くようになってから、QAから「大きな機能なのにバグがなくて驚いた」というコメントも出ていました。

環境整備を進めている様子

ITコンサル・SIer出身者がプロマネ的な視点でチームの動きを支える

atama plusではスクラムで開発を行っているため、スプリントと呼ばれる期間毎に開発するPBIを決め、チームに分かれて活動します。PBIの中にはステークホルダーが多く関わる機能や大きめの機能を開発するものもあるため、その際は先を見通し、他のチームと協力しながら開発を進める必要があります。

atama plusの開発チームにはプロジェクトマネージャーやプログラムマネージャーのような役割がないため、このような場合チームで自律的に開発を推進する必要があります。その際に、ITコンサルやSIerにて業務経験のあるエンジニアが、これまでの経験を活かしながら、開発計画の策定をリードすることが多いです。

具体的には、1スプリントで開発できる大きさにPBIを分割し、スプリントごとに不確実性の高い、もしくは優先度の高いPBIから開発していきます。最終的なスコープと着地見込みをスプリントごとに確認しながら開発を進めるため、ITコンサル・SIer出身者の堅実さを活かしつつ、開発をアジャイルに推進するイメージです。

この強みを活かすエンジニアは、プロジェクトマネージャーのように開発をコントロールするだけでなく、自らもコードを書き、いちエンジニアとして開発に携わります。

エンジニア経験のあるデザイナーが効果的なDiscoverをリードする

Oyakataチームのデザイナーは、二人ともフロントエンドエンジニアの経験があり、開発活動・開発プロセスにも知見が深いため、チームで連携する際にもこれまでの経験が活かされています。

最近だと、ミニウォーターフォール化しそうな部分に対して懸念をデザイナーが表明することで、よりよいチーム連携の動きをしていたのが印象的でした。

この表明のあと、新たなテーマについてDiscoverを行う際には、エンジニアがどの時点でどういった動き方をしていくべきかが、より深く議論されるようになりました。

様々なバックグラウンドを持った個々人によるチーム内連携

ここまでで、「もしかしたらチームメンバーの役割が固定化するのではないか？」と疑問を持ちながら読まれた方もいらっしゃるかもしれません。

私達も同様に過度の役割分担に陥らないように気を払っています。
少し分担されすぎたかな？というスプリントのレトロでは、以下のような議論がされました。

Oyakataチームがいまのメンバーになってから、上記のような観点が数スプリントごとに議論され、また大きな機能開発が終わったタイミングでも見直しがされるようになりました。

そのおかげで、現在はエンジニア間だけでなく職種を跨いだメンバー間でも、どのようなバランスで開発を行っていくべきかがチーム内でシャープに議論できています。

チームを構成する要素は、職能の専門スキル以外にも様々あります。今回紹介したOyakataチームでは、それぞれが強みを活かしつつ、お互いに質の高い学習機会を得ることで補完しあえるチームとなっていると思います。

おわりに

今回は各人のバックグラウンドや強みが、チームでどのように発揮されているかを書いてみました。

もちろん、他のチームでは今回書いていないようなバックグラウンドや強みを持った人たちが、また違った観点でチームに貢献し、そのチームならではの良い連携を生み出しています。

この記事を読んで、少しでもatama plusの開発体制に興味を持たれた方がいましたら、多様なバックグラウンドを持ちながらも同じミッションに向かうため、一緒に働きませんか？

新しい風を吹かせてくれて、一緒に学んで、開発をしていける仲間を募集しています。