バイセル Tech Blog

バイセル Tech Blogは株式会社BuySellTechnologiesのエンジニア達が知見・発見を共有する技術ブログです。

スクラムを始める時にやっていること

こちらは バイセルテクノロジーズ Advent Calendar 2021 の4日目の記事です。

前日の記事は松榮さんの BtoBオンラインオークションの紹介 でした。

こんにちは。CTO室のなおとです。

CTO室ではエンジニアリング組織に関する様々な活動をしていますが、その中でスクラムマスターとしてプロダクトチームを支援することがあります。

今回はスクラムの導入や立て直しをする際に自分がやっていることについて紹介しようと思います。

重要なことはチームの共通認識を作ること

これまで様々なチームを支援する活動を通じて、スクラムという明確な正解がない取り組みを成功させるために重要なことはチームの共通認識を作ることだという考えに至りました。

スクラムマスターとしてスクラムに関するレクチャーや活動のファシリテーションをすることもわかりやすい役割ですが、現状のチームの課題やあるべき姿について共通認識を持つことができれば、メンバーが自律的、創造的に振る舞っていく場面を多く見てきました。

今回は自分がスクラムを始める際に、共通認識を作るためにやっていることに絞って紹介をします。

スクラムガイドの読み合わせをする

スクラムガイドにはスクラムの定義が含まれている。

フレームワークの各要素には特定の⽬的があり、
スクラムで実現される全体的な価値や結果に⽋かせないものとなっている。

スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、
スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。

場合によっては、スクラムが役に⽴たなくなることさえある。

- スクラムガイド

まずは スクラムガイド の読み合わせです。

上記の通り、スクラムガイドにはスクラムの定義が書かれています。読み合わせをすることでスクラムというゲームのルールについて共通認識を作ります。

スクラムガイド自体は17ページと短いので、やり方としては事前に個人で読んでもらった上で感想をシェアする会を開催することが多いです。

Miroなどオンラインの付箋ツールを用いてスクラムガイドを読んで理解したことやわからなかったことと合わせて、チームで既にできていることや課題に感じていること、これからスクラムに取り組む目的もメンバーの言葉で言語化をしてもらいます。

アジャイルソフトウェア開発宣言 や、フロー効率に関するレクチャーもこのタイミングですることで、どのようなアプローチが正解とされているのかチームで認識を合わせます。

スプリントの期間を1週間にする

スクラムはスプリント期間が短いほど簡単です。

自分が支援する場合はスプリントの期間を1週間に設定することが多いです。

2週間スプリントと比較をすると、1週間のスプリントは以下のようなメリットがあります。

  • 見積もりをする対象が半分なので認知的な負荷が少ない
  • スプリントプランニングの時間が半分になる
  • 振り返りをする時にスプリント期間に起こった出来事を覚えている
  • 振り返りによる試行回数が倍に増えるので課題の改善サイクルが早い
  • 計画と実績の差が少なくなる

1週間で開発をして成果を出すことが難しい、そういうサイズにチケットを切ることができないという相談を受けることもありますが、ユーザに価値を提供するプロダクト開発でそのような場合は適切なチケット分割ができていないケースが多いです。その場合は別途プロダクトオーナーを支援することに時間をかけてプロダクトバックログを整備します。

また、Tipsとしてはスプリントの開始と終了を火曜日から木曜日の間で設定をすると、祝日との重なりが少ないので調整コストが減ったり、スプリントの区切りが平日で繋がっているので振り返りのコンテキストを忘れずに次スプリントでTryを実行しやすいなどの利点があります。

このようにスプリント期間を短く設定することでタスクや出来事に関する認識がズレることを防ぎます。

モブプロを導入する

仕事の進め方としてタスクをアサインする方式のままだと、形だけスクラムを導入しても実態としてスプリントプランニングの時点で人に対してチケットをアサインし、スプリントレビューで未完了の理由を説明をする状態になっていることもあると思います。

また、フロー効率の観点から考えてみると、タスクに取り組んでから手が止まったり質問が発生した時点でリードタイムが長くなることでフロー効率は低下してしまいます。それによる想定外の差し込みは他のメンバーにとってもマルチタスクにつながるためチーム全体での作業効率も低下します。

そこでスプリントのチケットの中で最も優先順位が高いものや不確実性が高いものを選択して、開発者全員でモブプロで取り組んでいきます。

モブプロについても XPにおけるペアプロ を説明してから実際にやってみることで、チケットのリードタイムが短くなるフロー効率の体験や、他のメンバーから学ぶスキルトランスファーを体験してもらいます。

チーム全員で同じチケットに取り組むことでコンテキストのギャップや必要なキャッチアップも減り、コードレビューもスムーズになります。

お試し期間を区切って実践し、振り返りをする

スクラムを導入または立て直しをする際、開始の時点ではチームのメンバー全員が100%スクラムに期待をしているわけではありません。

しかし、100%成功する気やる!そんな気概がなければうまくいくものも失敗してしまいます。

10スプリントをお試し期間と位置づけてあらかじめ振り返り会も計画しておき、結果的にスクラムが合わないと感じたら止めるという選択肢をチームが持っておくことで、逆に10スプリントはスクラムに集中して取り組んでもらいます。

また、振り返り会の中でスクラムを導入する目的が達成できたかどうか、どの点がチームや個人にフィットしたか、今後のチームの方向性なども話し合うことで共通認識を持ってもらいます。

スクラムをはじめると大体いい感じになる

自分もまだまだスクラムを勉強中の身ですが、人や環境に恵まれてきたこともあり、これらの取り組みをする中でスプリントを中止したりメンバーから反発を受けることはありませんでした。感謝しかありません。

前提として成功のためにはプロダクトやメンバーが重要な要素ですが、スクラムをやってみることで大体いい感じになることが多かったように思います。

「いい感じ」の一例です

  • コミュニケーションの量が増える
  • チームのタスク量を把握できる
  • 作業の手戻りが減る
  • プロジェクトの進捗を可視化できる
  • ジュニアなメンバーがリーダーシップを発揮するようになる
  • シニアなメンバーが経験や知識を共有するようになる
  • マネージャーの負担が減る

一方、このある種の「スクラムの踊り場」からいかに早く次のフェーズに移ることができるのかも非常に大切です。それについてはまた別の記事で書こうと思います。

まとめ

今回は自分がスクラムを始める時にやっていることを紹介しました。

スクラムガイドの読み合わせから始め、お試し期間の中で1週間スプリントとモブプロによって成功体験を重ねて最後に取り組みを振り返ることで、スクラムやチームに対する共通認識を作ってきました。

バイセルではスクラムをはじめエンジニアリング組織の課題の取り組む仲間を募集しています。 hrmos.co

明日の バイセルテクノロジーズ Advent Calendar 2021 は尾沼さんによる「CircleCIで構築されたCI/CD環境をGitHub Actionsに移行した際のポイント」です。お楽しみに。

BtoBオンラインオークションの紹介

こちらは バイセルテクノロジーズ Advent Calendar 2021 の 3日目の記事です。
前日の記事は 藤澤さんの 「GoでRubyみたいに単体テストを書きたくてやったこと」でした。

こんにちは。開発部の松榮です。
ブラックフライデーセールではルンバとブラーバのセット購入しました。
うまく掃除できない時がある古いルンバとブラーバはこれにて引退です。
これで安心して掃除を任せられそうです。

関係ない共有はここまでにして、採用面接や面談の中でプロダクトの話をするのでPdMを志望されている学生や中途エンジニアに向けてバイセルで運用しているプロダクトの一例を紹介したいと思います。

プロダクトの成り立ち

2020年11月バイセルが株式会社タイムレス(旧:株式会社ダイヤコーポレーション)を子会社化しました。
PMIのプロセスにおいて基幹システムの統合などと平行してオンラインによる自社のBtoBオークションを開発を行い、
2021年1月タイムレス社によるオンラインオークションが開始されました。

プロダクト紹介

タイムレスオークション
このオークションは古物の免許をもった事業者のみが参加できます。 現在の取り扱いとしては年間200,000点を扱う日本最大級のBtoBオークションです。
商材としてはブランドジュエリー、時計、ルース(宝石の石)、ブランドバッグを取り扱っています。
タイムレスはこのオークションの市場主(主催者)という立場です。
このオークションに対して売り主と買い主という立場の方々もいてオークションが成り立っています。

バイセルではタイムレスのオンラインオークションを開発・運用を行っています。
最近では多言語の対応やライブオークション、 新たな商材としてのブランドバッグの取り扱いなどが大きなアップデートです。

続きを読む

GoでRubyみたいに単体テストを書きたくてやったこと

はじめに

こちらは バイセルテクノロジーズ Advent Calendar 2021 の 2日目の記事です。 前日の記事は早瀬さんの「Apollo Clientを採用した際のフロントエンドの構成について考えてみた」でした。

はじめまして、開発1部の藤澤です。 今回は私が所属しているプロジェクトでの取り組みを紹介したいと思います。

バイセルではRuby on Railsを採用したプロダクトが多くありますが、 最近ではGoの採用事例が増えています。 私が所属するプロジェクトでもバックエンドにGoを採用しています。

Goでバックエンドを書いていく上で、 「Railsの時あったあれは、一体どうやれば実現できるんだろう?」 と悩んで取り組んだことがいろいろありました。 今回はそんな中でも単体テストに絞った事例をいくつか紹介したいと思います。

※この記事の前提となるGoバージョンは以下の通りです

  • version go1.17.1 linux/amd64
  • はじめに
  • 共通処理を行いたい
  • DBのテストをしたい
  • テストデータを準備したい
  • 外部連携をテストしたい
  • まとめ

f:id:bst-tech:20211124125223p:plain

続きを読む

Apollo Clientを採用した際のフロントエンドの構成について考えてみた

はじめに

こちらは バイセルテクノロジーズ Advent Calendar 2021 の 1日目の記事になります!

今年度新卒で入社した開発1部の早瀬です。

ここ最近は新規プロジェクトのPLとして、要件定義から開発まで携わっています。

新規で立ち上がったプロジェクトというのもありBE・FEともにアーキテクチャの検討から携わらせていただいているのですが、特にFEに関してはかなり悩んだ末に自分なりに納得がいく構成になったので今回はその内容を紹介しようと思います!

  • はじめに
  • 前提
  • アーキテクチャ
    • View
    • Presenter
    • Model
  • フォルダ構成
    • components/pages
    • components/domain
    • components/uiParts
    • pages
    • interaction
    • graphql
    • hooks
    • services
  • その他・検討事項
    • 依存関係
    • Atomic Designの不採用
    • domain配下のコンポーネントでのGraphQLクエリの実行を許可するか?
  • まとめ
続きを読む