バルス×プラハ対談インタビュー【前編】スクラム開発の魅力とプラハとのシナジー
※この記事は2022年7月に作成したものです。
こんにちは、バルス採用ブログ編集部です！
バルスはライブ配信やグッズ販売などの機能と、アーティストとファンのデータベース機能を統合した、エンタメDXツールSPWN Portal（以下、Portal）を展開しています。 Portalの開発では、協力会社として株式会社プラハ（以下、プラハ）の皆さんにも協力していただいています。
今回は、バルスのPortalプロダクトチームのプロダクトマネージャーの味野さん、エンジニアリングマネージャーをしている丸山さん、そして、プラハから代表取締役の松原さん、エンジニアの石原さんに参加いただき対談インタビューを行いました。
バルスにおけるスクラム開発の魅力や、開発におけるリモートワークを支えるツールとコミュニケーションについて前後編に分けてご紹介します。
自己紹介
───まずは自己紹介をお願いします。
丸山（バルス・エンジニアリングマネージャー）： Portalエンジニアチームでエンジニアリングマネージャーをしている丸山です。
味野（バルス・プロダクトマネージャー）： Portalのプロダクトマネジメントをしている味野です。 toB顧客とtoC顧客に対して提供する機能のバランスを取りながら、プロダクト全体の方向性を決定しています。
石原（プラハ・エンジニア）： プラハの石原です。 Portalエンジニアチームにエンジニアとして参加しています。
松原（プラハ・代表取締役）： 株式会社プラハの代表取締役、松原と申します。 Portalプロジェクトの開発に直接関わることはないのですが、プラハの採用や社内制度を策定したり、オンラインプログラミングブートキャンプ「プラハチャレンジ」のメンターでもあります。
───ありがとうございます。まずはプラハさんの会社についてのご紹介と、バルスとの関わり方についてを教えて下さい。
松原： プラハは、主に新規事業スタートアップに特化した開発とデザインの受託をしています。バルスさんには2名がプラハから参加しています。 プラハの特徴はお客さんとの距離が近い事です。
人の縁がきっかけになることが多く、過去にお仕事でご一緒させていただいた方から再度お仕事を依頼してくださったり、他の会社さんをご紹介いただいたりして、結果的に関係が強いお客さんが多いんです。
また、「プラハチャレンジ」という中級エンジニアを育成するブートキャンプもやっています。このブートキャンプでは「変えやすいコードを書こう」という点に重視したカリキュラムになっていて、DDD（ドメイン駆動設計）、データベース設計、自動テスト容易なコードの書き方やテスト関連ツールの使い方（Storybookやmsw）など、現場で応用の効く開発手法を習得します。
バルスさんに参加している石原さんも、プラハチャレンジ卒業生の一人なんです。
Portalにおけるスクラム開発
───ありがとうございます！それでは早速ですが、Portalプロダクトチームで行っているスクラム開発について教えてください。
丸山（EM）： Portalエンジニアチームにはエンジニア5名とデザイナー2名の合計7名がいて、プラハさんからは石原さんを含む2名が開発メンバーとして参加しています。 Portalプロダクトチームがどのようにスクラム開発のセレモニーを行なっているか紹介します。
スプリント
Portalプロダクトチームではスプリントを1週間という単位に区切って開発しています。 月曜日に2時間程度、スプリントプランニングで決めたスプリントバックログアイテムをもとに開発をすすめます。火曜から金曜日まで毎朝15分前後デイリースクラムをしながらスクラムを完了させ、金曜日にはスプリントに対して振り返る、スプリントレビューとスプリントレトロスペクティブを行っています。
スプリントプランニング
スプリントプランニングでは、スプリントで何を開発するのかをチームで合意を取ります。
プロダクトバックログに並ぶWhyとWhatの定義されたストーリーから、Howに落とし込んだスプリントバックログアイテムを作成します。 スプリントバックログアイテムは、エンジニアとデザイナーが協力して作成しています。タスクの難易度はプランニングポーカーによって策定していきます。
エンジニアとデザイナーがそれぞれの責務の中で合意して、誰が何をどのように開発するのかを全員が理解した状態でスプリントが始まるようにしています。
デイリースクラム
一日の始まりに15分という時間を区切って行われるデイリースクラムでは、スプリントバックログアイテムを実装するにあたって課題や疑問点がないかを確認します。 デイリースクラムで話し足りないことはSlackやMeetで別途コミュニケーションして解決します。 スプリントバックログアイテムにアサインされた人だけが問題に取り組むのではなく、チーム全体で協力して進めることを重視しています。
スプリントレビュー
スプリントの終わりに、実装した機能について共有するスプリントレビューを行います。 開発以外にもカスタマーサクセスやセールスなど、プロダクトの関係者に広く参加してもらいます。
週一回のスプリントの単位で、小さな成果物に対して小さくレビューしています。 このスプリントのスピード感で、大きな失敗を防ぎ、素早い改善につなげています。
スプリントレトロスペクティブ
スプリントレトロスペクティブでは、プロダクトの関係者全員でそのスプリントで起きたことを振り返り、Good/BadとFact/Emotionの4象限に分けて羅列します。
特にインシデントが起きた場合には、どのように一次対応を実施したかをナレッジとして共有します。二次対応としてチーム全体でインシデントの再発防止策を考え、必要に応じてそのインシデントからプロダクトバックログアイテムとして次のスプリントに繰り越すこともあります。 当然インシデントだけでなく、良いこともチーム全体で賞賛し合っています！
この一連のプロセスにおいて、バルス開発チームのメンバーとしてプラハさんも会社の垣根なく参加いただいており、今の開発チームができています。
───スクラム開発のご説明、ありがとうございます！ プラハさんも、バルスの開発チームのメンバーとして社員と変わらない働き方なんですね。プラハさんからみたバルスの開発チームは他社と比べてどういうところが魅力でしょうか？
バルスの開発チームの魅力①技術選定が新しい
松原： 僕が外から見てて感じた印象ですが、技術選定がすごく新しいと感じました。 例えばReactのSuspenseやデータ取得ライブラリのSWR、フォームバリデーションライブラリのReact Hook Formなどの新しい技術を取り入れることに積極的だと思ってます。
特にフロントエンドでは新しいライブラリを積極的に導入しているように見受けられますが、どのように導入していますか。
丸山： 確かに現在取り組んでいる新規のプロダクト開発では、新しい技術を積極的に取り入れています。プロダクトマネージャーの味野さんや自分を含めた開発メンバーのSlack投稿をきっかけに議論が始まることが多いです。
味野： 新しい技術選定に関しては、業務外の個人プロジェクトで「これとか使えそうだよね」「今後の技術トレンドこうなりそうだよね」って思ったことをSlackにシェアしてます。
丸山： そういった雑談ベースの発言をきっかけに、開発メンバーが自主的に議論に参加し、結果的に新しい技術選定につながっているんだと思います。
味野： この議論は別にバルス社員だけでするとかではなく、プラハのメンバーのお二人にも同様に参加いただいてます。お二人とも積極的に参加していただき、すごく助かっています。
松原： もう一人のプラハのメンバーからも、仕事でそういった新しい技術が学べるのが嬉しいと聞いています。決められたことだけをやるのではなく、新しい技術の選定のための調査や比較検討の業務も任せてもらえて、仕事と新しい技術の勉強を両立できて充実しています。
味野： 新しい技術の勉強をすること自体がエンジニアの業務の一つなので、新しい技術を試せる部分では積極的に取り入れて開発を進めています。
開発メンバーには、「勉強していただいてありがとうございます」という思いでいます。今日はドキュメントを読み込む日にしますとかも全然よくて、そういう時間の使い方もPortal開発チームとしてはウェルカムです。
丸山： こちらとしてもプラハさんと開発する中で、自分が詳しくない知識を得る機会がたくさんあり、凄く勉強になってます。
バルスの開発チームの好きなところ②スプリントが見積もりどおりに完了する
松原： プラハ社内では、Portalの開発チームのスクラムはチケットを細かく管理して1週間でスプリントを完了できる事がすごい、と話してます。
僕自身の過去の経験では、スプリントが1週間だとリリースするものが作れないので、大体2週間単位が多かったと思います。スプリントを短く回すための秘訣を教えてもらえますか。
味野： 1週間でスプリントを完了する秘訣はチケットの細かさでしょうか。
例えば、CRUDでいうと「書き込み（C）」、「読み取り（R）」、「更新（U）」、「削除（D）」の4パターンに分類して、まずは書き込みしかできないようにします。また、「設計フェーズ」と「仕様検討フェーズ」、「調査と実装」と、タスクのポイントが3つぐらいに分かれています。
このチケットの作り方は、プロダクトマネージャーが決めるのではなく、エンジニアチーム主導で進めています。もうちょっと細かくしましょうとか、決めるところまでを責務にしましょうとか、チーム全員でチケットやタスクを細分化することを意識してます。
僕も過去にスプリントが2週間のチームにいたことがあるんですけど、1週目と2週目の間でだれちゃうことがあったんです。
暦が1週間の区切りになってるから、スプリントも暦に合わせるのがリーズナブルなことだと考えています。
石原： 最近の課題としては…一人でも進められるくらいチケットが細分化されているがゆえに、チーム内で知識が分散してしまっているなと感じるので、チームですり合わせる場を今以上にこまめに設定したいなと思っています。
丸山： 実際チケットの粒度設定は難しくて、どういう粒度や手順がチームのパフォーマンスをより出せるのか考えるのに苦労しています。でもそういった問題提起も嬉しくて、仕組みはこれからも改善していきたいですね。 ーーーまさに、プラハさんがプロジェクトを自分ごと化して考えてくださっている姿勢を感じますね。プラハさんが入って変わったことや、導入したことはありますか？
オンボーディングをきっかけに始めたモブプログラミング
丸山： プラハさんが今年4月に開発メンバーとして参加する時に、モブプログラミング（以下、モブプロ）を導入してみました。
僕と石原さんたちの3人で一緒に実施し、オンボーディングとしても開発体験としても良い結果になったこともあり、モブプロは現在も開発に導入してます。
※モブプログラミング（モブプロ）とは
複数人でコミュニケーションを取りながら実装を進める手法のこと。
モブ（開発の議論や実装を考える人）とタイピスト（モブの指示でコードを書く人）に分かれて行います。 モブプログラミングは対面での開発手法として行われることもありますが、バルスでは開発ツールであるVisual Studio Codeと、リモート会議ツールのGoogleMeet等を組み合わせ、非対面でのモブプログラミングを実践しています。
───プラハさんでも普段からモブプロは行っているんですか？
松原： 僕が参加するプロジェクトでは、ほぼ必ずやっています。特に1番最初の設計をすり合わせるタイミングで一通り書いてからコードレビューして、そこで全然違うと物凄くタイムロスになってしまいますよね。そうならないようできるだけ最初のうちにモブプロをしてすり合わせを行います。
「僕はこういう書き方をしたい」とか、「チームとしてはこれに気を付けてるんです」などの細かな書き方の癖などを共有するのにモブプロは向いていると考えています。 モブプロを通じてお互いの理解が一致してから、非同期で各々分業して、プルリクを使っていく方が手戻りが減ると思っているんです。 あと、とにかく技術的に難易度の高い場合は1人だとやり方にも詰まっちゃうので、そういう場合にも複数人でモブプロをしています。 でもモブプロって集中するので、2時間で8時間働いた分ぐらい疲れますよね。
丸山： わかります、モブプロってこんなに疲れるんだなって思いますよね。でも他の人と開発することで刺激になる場面がたくさんありました。 そのときにオンボーディングで参加していた石原さんに聞きたいんですが、モブプロのおかげでチームに入りやすかったりしましたか。
石原： すごく入りやすかったです！やっぱりモブプロって画面を共有して喋りながらコードも一緒に書くので、ちょっとしたコードの書き方を知れたり雑談ベースで考え方を共有できて楽しいんです。 設計のすり合わせだけでなく、お互いの人となりも分かってきますよね。最初の1週間のオンボーディングでみなさんと仲良くなれた気がします。 もう1名も心の距離が縮まったと言ってました。
終わりに
今回はスクラム開発の魅力とプラハさんとのシナジーについてお届けしました。 バルスのスクラム開発がイメージできるような、生の声をお伝えできたかと思います！
後半では、開発におけるリモートワークを支えるツールとコミュニケーションについてもお伝えする予定です。
バルスでは新しい技術を学ぶことが好きで、一緒にバルスを盛り上げてくれるエンジニアを募集しています。更にバルスを知りたい方、後編もぜひ読んでください！
▼後編はこちら「北海道から福岡まで、リモートワークを支えるツールとコミュニケーション」
▼株式会社プラハ
バルスHPからエントリー
Wantedlyからエントリー
事業説明資料