CTOとエンジニアが語るBYARD開発チームのいま。
こんにちは、BYARD(バイアード)です。
2022年度末を迎え、『BYARD』も正式ローンチからはや半年が経とうとしています。この「MESSAGE FOR ENGINEER」シリーズの第1回をお届けした2022年5月とは、エンジニアチームの体制も大きく変わってきました。ということで、今回のテーマはズバリ、「BYARDチームの開発体制」です。
ベトナムのエンジニアとのオフショア開発を行うチームの編成や、スクラムプロセスの現状について、CTOと開発メンバーであるエンジニアが語ります。
今回の登場メンバー
BYARDのCTO。アーキテクチャの選定担当者。
開発チームメンバーで、フリーランスのエンジニア。 『BYARD』に携わること約1年。
オフショアメンバー7名を含むチーム体制
ーーまず、現在の開発チームの全体像について教えていただけますか？
辰本：現在BYARDの開発チームは、日本人4名とベトナムのオフショアメンバー7名で構成されています。オフショア自体は今やありふれていますが、その中で珍しいのはブリッジSEもスクラムイベントに参加していることでしょうか。
通常、開発を進める際、私たちはブリッジSEの二人にもPBIをアサインしていきます。ただ、彼らは実際にはコーディングを行うことはほとんどなく、日本メンバーと要件を確認した上で各オフショアエンジニアに担当を振り分け、プレレビューを行う役割を担っています。
鈴木：通常、ブリッジSEにはある程度仕様を固めた機能群の開発をお願いして、リリースまでプロダクトマネージャーがブリッジSEとやり取りをするというのが一般的ですよね。スクラムイベントに彼らが参加しているというケースを体験するのは僕も初めてでした。
ーーなぜブリッジSEの方にスクラムイベントにまで参加してもらう体制にしたのですか？
辰本：オフショア開発を始めたのがまだサービスを正式ローンチするかしないかの頃で、仕様がドラスティックに変わっているタイミングだったからです。
それに、丸ごとお任せして後でチェックするよりも、スプリントに参加してもらう中で細かくチェックするサイクルにした方が巻き戻りが少なく、お互いにとって良いのではないかと考えたんです。
鈴木：チケット単位の開発にしても、「なぜそれが必要なのか」という背景やディティールの共有は重要ですよね。スクラム開発の中でそれらが共有できれば、全体のコミュニケーションコストが下がるので、良いやり方だなと僕は思っています。
ーー反対に、現在のチーム体制の難しさや課題はありますか？
鈴木：やはり仕様をある程度噛み砕く必要があることでしょうか。オフショアチームのみなさんに効率的に開発してもらうためには、曖昧な情報を理解しやすい日本語に落とし込んでブリッジSEの方に伝える必要があります。でないとかえってコミュニケーションに時間がかかり、リソースをうまく活用できなくなってしまいます。そこには言語の違いによる難しさもややあるかもしれません。
辰本：レビュー後の改善依頼をブリッジSEの方に伝えても、その開発メンバー以外にはあまり伝わっておらず、何度も同じ指摘をすることになるということも起こっています。これはブリッジSEの方の配下に複数名のメンバーがいるという構造の難しさでしょうね。
ただ、これらはオフショアやチーム体制に起因する特別な問題というわけではないとも感じていて、ある程度の改善が可能だと思っています。
例えばPBIからSBIに詳細見積もりをして、改めてSBIレビューする時間として「これって何でしたっけタイム」を設けています。これは、自分の認識とやるべきことの認識をチーム内で揃えるために、誰もが質問できるという時間です。その場で疑問点を解消し、足りない部分は都度Slackハドルで話すことで、後々大きな修正が発生するのを防ごうとしてます。
ーー言語の壁や、やや複雑な構造によってトラブルが発生したことはないのですか？
辰本：覚えている中では一度だけありますね。直接開発の方が英語でコメントしてくれたものがすごく失礼な文面に見えて、日本側のメンバーが憤慨しかけたことがありました（笑）。
鈴木：ありましたね（笑）。ただ、あれはその方が文面と関係ない絵文字を多用するタイプの方だったのと、お互い英語がネイティブじゃなかったから起こったことで、他意はないとすぐわかりました。
辰本：そのあたりも通常のチームのコミュニケーションと大きくは変わらないですね。国籍・言語・立場・世代・個人の価値観や個性は、チームとしてコミュニケーションを交わし続けることで徐々に認識され、気持ちの良い関係ができていくものですから。
鈴木：そうですね、「意図しない伝わり方をしないように少しコメントを見てあげてほしい」とブリッジSEの方に伝えて以後は、同じようなケースはなくなりましたし。そうした一つひとつのやり取りを重ねることが大事なんでしょうね。
BYARDスプリント開発と課題
ーー現在のチームでのスプリント開発をどのようなプロセスで行っているのか教えてください。
辰本：上の画像にまとめたものが、現在の開発プロセスと意図するところですね。鈴木さんは今のスプリントについて率直にどう感じていますか？
鈴木：オフショアチームが1つ増えたので、1週間1スプリントというのがかなり時間的にタイトになってきたなと感じています。プルリクエストが承認されるまでかなり時間がかかっていて、次のスプリントに回るものが多くなってきてしまってますよね。
ただ、2週間では長すぎて、定期リリースとは別に早めのリリースをするものが常態的に発生しそうで、難しいところですね。
辰本：その辺りはまだまだレビューをしなくてはならないものが多いからで、メンバーの習熟度によるものという気もしますね。
鈴木：確かに。1週間のスプリントというと、スタートの火曜はイベントが集中しているので、作業できるのが実質4日なんですよね。それでレビューに上がってくるのが木曜になると、一回返すと次に上がってくるのが月・火のギリギリのタイミングになってしまうことも多い。まだまだこのサイクルがうまく回っていくには時間がかかりそうではあります。
辰本：障害が起きたときの対応もあったりするから、なおさらコントロールが難しいですね。今の私たちにはスクラムの運用とスクラムチームの弱さがやっぱりあって、ここはレベルアップしなくてはいけないところだと日々痛感しています。
ーースプリント中のステータスやPBIで運用しているラベルなど、何か特徴的なものはありますか？
辰本：PBIのラベル管理やバックエンドにも関係するプルリクエストは上の画像のようになっています。おそらくそんなに目新しいことはしていないんじゃないかな。
鈴木：お客様用のロードマップと紐付けているものもありますね。漏れがないようにしていますが、この辺りもまだまだ絶賛改善中です。
辰本：今朝も変えたばかりですね。バグのラベルもこの間消したけど、やっぱり追加し直しましたし。今抜けやすいのはビジネスサイドがお客様とやり取りを交わして起こるロードマップの変更で、これをどうスプリントのライフサイクルに埋め込んでいくか悩んでます。
鈴木：見落としているとかなり焦るし、なんとかしないといけないですよね。
新たなエンジニアを迎える状況
ーー2023年3月現在、新しい仲間にお願いしたいこと、伝えておきたいことはありますか？
辰本：『BYARD』は現在多数の機能追加が必要ですので、特にその部分を担ってほしいですね。外部サービス（ScaleBase,Box,Slack,teams）とのAPI連携やユニットテスト・E2Eテストの拡充もお願いしたいところです。
それだけではなく、UX向上のためのパフォーマンス・チューニングや、品質を担保するためのコードレビューも……お願いしたいことはとにかくたくさんあります。
ただ、当社はスタートアップの中ではかなり特殊で、SmartHRからの手厚いバックオフィス支援を受けられているおかげでプロダクト開発に集中できる環境が整っています。エンジニアとして新しい経験を積んで吸収・成長したいと思っている方には、きっといい環境ですよ。
また、伝えておきたいのは待遇面ですね。現在BYARDでは報酬の制度設計を以下のようにしています。
BYARDのエンジニアは給与査定を設けていません。
正社員として開発に参画頂くメンバーには全員同じ給与を提示しています。(2023/03現在では年俸700万円/最新情報はコチラ)
辰本：「給与査定がない」と聞くと驚かれるかもしれませんが、私たちは強い思いを持ってこのような制度を導入しています。
まず、事業が成長するためには数え切れないほどの要因があり、誰がどれだけ成長に貢献したかを正確に定量的に評価することはほぼ不可能だと考えています。
その上でも給与査定を行うためには、メンバーやマネージャーが多大なコストを払って、「それらしき」目標や実績を積み上げ、合意をしていくプロセスが必要になります。結果として評価基準が曖昧になることが多く、不満が生じることが想像出来ます。実際、人事評価に満足している社員は2割程度しかいないという調査結果もあるようです。
また、ハーズバーグの二要因理論によると、給与はあくまでも衛生要因であり、どんなによい条件でも仕事に対する不満を０に近づける要因でしかないとされています。メンバーやマネージャーが多大なコストを払って評価制度を運用した結果が、8割の不満を生み出し、満足してもマイナスが０に近づくだけなのであれば、もっと重要で価値あるところに力を使いたいと考えました。
そこで、私たちは給与査定を廃止し、その全てのコストをメンバーの成長の支援に当てることで、仕事の満足度を向上させ、ハイパフォーマンスを発揮してもらいたいと考えています。
こうした点にも共感いただける方に、是非来ていただきたいです。
また、事業が成長した際の追加のインセンティブについては業績に応じて都度分配することを計画中です。
ーー今回がエンジニアチームの対談最後になりますが、鈴木さんからはどうですか？
鈴木：3回に渡りアーキテクチャや開発チームの現状について、メンバーの視点でお伝えしてきましたが、やはりBYARDはまだ始まったばかりで、次々変化が起こるフェーズにあると改めて思いました。
おそらくこの文章をリリースした1ヶ月後にはまたいろんなものが変わっているでしょうね。そうした日々起こる変化を楽しいと思うタイプの方には、BYARDはピッタリの場所です。僕らのプロダクト開発に興味がある方、エントリー待ってます！
辰本：ぜひお気軽にカジュアル面談、お声がけくださいね〜！
▼CEO・CTOのカジュアル面談ただいま受付中です。
▼『BYARD』のコミュニケーションについて語った記事もどうぞ。
▼CEO武内の連載記事『BYARD開発記』（全13回）もご覧ください。
▼現在さまざまな職種のメンバーを募集中です！
この記事が気に入ったらサポートをしてみませんか？