なぜtsumugがスクラムを取り入れたのか エンジニアだけではない組織全体でスクラムが必要な理由

f:id:manuts_y:20201229183913j:plain

「TiNK Desk」や「TiNK Office」を提供するtsumugでは、開発をさらに加速させるために、『スクラム開発』を取り入れました。今回は、tsumugという組織がスクラム開発を通して得たことや苦悩、メンバーの思いについて、tsumug広報担当のLucaさんが紹介します。コロナ禍でスタートした2021年、「リモートワークでのスクラム開発」についても考えてみてはいかがでしょうか。


2020年のtsumug

新年明けましておめでとうございます。本年もよろしくお願い申し上げます。

2020年、tsumugにとってはアップデートの年でした。自宅寄り添い型のワークスペース「TiNK Desk」の正式版がはじまり、そのTiNK Deskを一室専有できる「TiNK Office」が登場。その「TiNK Office」のように、物件オーナーの空室問題を解決してエンドユーザーに新たなオフィス空間を提供するサービス「TiNK」がスタートしました。

そんなtsumugにおいて、「TiNK」をさらに加速させるため、2020年から『スクラム開発』にも挑戦しています。

なぜtsumugがスクラムなのか

さて、新型コロナウイルスの影響で、働き方が大きく変わってしまった企業がほとんどではないでしょうか?多くの企業が出社からリモートワークに切り替わり、リモート環境という慣れない状況に苦戦したと思います。tsumugも、もちろん例外ではありません。

tsumugは、一人ひとりが心地よい空間で働いており、働き方の自由を体現している企業です。メンバーは全員フリーランスで、tsumugのオフィスに集まったり、リモートワークを取り入れながらプロジェクトを進めています。
   

  • 複業、パラレルワークが前提
  • 作業時間がまちまち
  • 休みが不定期
  • 土日も人によっては稼働


このような状況でも、以前は研究・開発などのスペシャリストが独立しており、リリースに合わせてスケジュールを組んでいたため、柔軟に動くことができていました。

しかしサービスのピボットをきっかけに、複数のメンバーでの連携が必要になり、スキルセットの違いや稼働時間が違うことが開発のボトルネックになって、今までの開発の流れでは対応できなくなってしまいました。

そこでtsumugでは、スクラム開発での事業推進を検討。しかしスクラム開発は、10年以上前から存在する開発プロセスということもあり、近代的なスタイル、特にWebアプリケーション開発に一部マッチしないことがあるため、本当にスクラムで開発ができるのか、何度も議論を重ねました。

それでも、そのデメリット以上に、複数のサービスを同時進行しながら開発を素早く進められるメリットが勝ると判断。

そうして2020年6月、東京と福岡の2拠点で、メンバーごとに異なる仕事環境、全員ほぼリモートワークの状況で、tsumug全員のスクラム開発がスタートしました。


以下は、スクラムとはなんぞや?という方のための簡単な解説です。すでにスクラム開発を知っている方は飛ばしてもらってかまいません。

【コラム】スクラムの基礎知識

スクラムとは
主にソフトウェア開発で利用されるフレームワークの一つです。
チームが作業を進める際、「スプリント」という小さな単位で区切り、「設計→実装→テスト→リリース」を繰り返していく開発スタイルです。これを繰り返して最終目標の成果物を作っていきます。またスクラム開発において、“役職”はないが“ロール(役割)”が明確に決まっているのも特徴です。

プロダクトオーナー(PO)
スケジュール管理&プロジェクト進行をするロールの人。
プロダクトの責任者で、重要な意思決定を行い、最終決定権をもちます。

スクラムマスターとは
スクラムを理解した上で、計画した進め方ができているかを管理し、もし計画通り進んでいなければ、円滑に進めて行くロールの人です。また、作業上のブロッカー(障害)を排除するのもスクラムマスターの役割です。

【スクラム5つのイベント】
スクラムは、以下の5つのイベントによって構成されています。
会話の種類(レビューの話であったり・仕様検討の話であったり)に応じて、適材適所の議論の場が用意されているので、仕分けて議論することで、効率よく開発が進みます。


1. デイリースクラム 15m (スプリントによって変動あり)
Check-in(アイスブレイクのような雑談)を経て作業上の課題の共有をします。


2. スプリントレビュー 45m(Check-in込で50〜55分)
スクラムにおいてはフィードバックが重要なので、スプリントで実現したユーザーストーリーに対するフィードバックを行います。

3. レトロスペクティブ 45m (ディスカッションを含めて50〜55分)
スプリントの進め方に対するフィードバックを行います。

4. スプリントプランニング 2h / 1week
スプリント内で実現するストーリーを、小さなタスクに分解して可視化します。

5. バックログリファインメント 2h以下
プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、優先順位付けをします。

【その他スクラムに使用する用語】

◯プロダクトバックログ
プロダクトを構成するユーザーストーリーを、優先順位付けして一覧したもの。

◯ユーザーストーリー
ソフトウェアの機能が顧客にどのように価値を提供するか、ユーザーに何をさせたいかに焦点を当て、それに対する要求事項を簡潔に表にします。



f:id:manuts_y:20201229183913j:plain
スクラム講習を受けたあとは、社内でスクラムワークショップを開催。その中ではスクラムのロールを学んだり。
f:id:manuts_y:20201229183917j:plain
自分達で新しくサービスを想像して、スクラム開発の考え方を学んだりした



tsumugでのスクラム開発スタート!でもいろいろと問題が……

そうして始まったスクラム開発ですが、もちろん、スクラムを導入したから魔法のようにうまくいくわけではありません。それに対する努力も必要で、いろいろやり方を変えながら、日々スクラム開発を進めていきました。

ここからは、この約半年スクラム開発に取り組む中で、変わったことや苦労したこと、改善策について書いていきます。

スクラム開発で変更した点
スクラム開発になり、大きく変わったのは次の2点です。

  • 不定期のリリース → ウィークリーリリース(1週間単位でスプリントを回してリリース)
  • オフィスに集まって同期的に仕事 → リモートワークで非同期にコラボレーション


イベントのタイムボックス厳正化
スクラムのスプリントを回すにあたり、1週間に5つのイベントを入れるため、リモートワークかつ業務委託でスケジュールを調整することが大変でした。

また、「各イベントに使用する時間がどうしても長くなってしまう」という課題も出て、それに対しては、タイムボックスを厳正化することで時間を短縮させました。たとえば、5つのイベントを進める中で、各イベントと無関係な内容があればスクラムマスターが止め、必要に応じて別ミーティングで実施するなど、徹底した時間管理を行いました。

その一方で、スクラムマスターが必要以上にファシリテートせず、開発者同士のコラボレーションの場にしようと心掛けたのも、オンラインで進めるうえでよかった点だと思います。

誰がなにをしている?どこに着手している?を可視化
さらに、一人ではなくみんなでやるからこその難しさに直面。以前は一つの開発に対して一人のエンジニアがスケジューリングし、ひとりで集中して取り組んでいましたが、スクラムでは他の人と一緒に開発を進めなくてはなりません。

スクラム開発当初は、まずはスクラムのイベントや開発の時間をみんなで揃えることからはじめ、そしてそれぞれの技術を把握しフォローしながら進めていたため、個人の開発と全体のスピードがかなり落ちました。

しかし、JIRAとSlackを活用することで、全体の動きを可視化することができ、チーム全体で動きながら開発するスタイルに次第に慣れていきました。また、それぞれ役割が割り振られることで、誰に何を相談すれば解決するかが明確になり、メンバー同士がカバーしながら開発速度を速めることに成功したのです。

f:id:manuts_y:20201229183922j:plain
JIRAを使ってユーザーストーリーを書く
f:id:manuts_y:20201229183926j:plain
そのユーザーストーリーを実現するのにかかる労力を見積もる
f:id:manuts_y:20201229183931j:plain
レトロスペクティブといわれるスプリントの振り返りには、「miro」というサービスを使っている


サービスチームと開発チームの連携  
スクラムは、開発チームとサービスチームの息を揃える必要があります。
以前はサービスチームが仕様の概要を決め、開発チームが細かいところを決めながら進めていく流れでしたが、「サービスチームが仕様の細かいところまで決めて開発チームが動く」スタイルに変更したため、サービスチームのやることが圧倒的に増えたり、スクラムのイベントに合わせるために、以前より前倒しでやることを決めていく必要があり、非常に大変でした。

開発の成果物については、機械的に生成したリリースノート(履歴)だけでは、サービスチームが理解することは難しく不十分だったため、改善策として、開発チームからサービスチームへはストーリーベースで説明することを実施、またテンプレートを用意して、それにそってリリースノートを書くように徹底しました。

改めてスクラム開発について考えてみる

スクラム開発にして一番よかったと思うことは、TiNKのオーナーやユーザーのことを一番に考えて動き、ユーザー価値の高い機能を短い時間で届けられるようになったことです。

スクラムは、開発メンバーがフルスタックであることが前提条件としてありますが、tsumugは各専門分野のプロフェッショナルの集まりだったので、対応していくのにはかなりのエネルギーが必要でしたし、今も努力を重ねています。また、各チームの作業工数が増えたり、ミーティングが増えたことも事実です。

短期的に見れば、開発スピードが遅くなっている部分もありますが、 ロール(役割)を設定することによって目的が明確になったこともあり、継続していけば、将来的には開発スピードも上がり、チームの変化にも対応しやすくなってくると思います。

さらに、スクラム開発を進めていくことで、しないこと・進めることを明確に分けて決めることができました。自社開発で悩んでいる企業やチームであれば、これを機にスクラムを取り入れてみてはいかがでしょうか。

【コラム】tsumugには認定スクラムマスターが6名在籍!(tsumugのスクラム自慢)

認定スクラムマスターとは?https://www.scrumalliance.org/

スクラムマスターの認定資格にはいくつか種類があります。
tsumugのメンバーが取得している「Certified ScrumMaster:CSM(CSM)」「認定スクラムプロダクトオーナー(Certified Scrum Product Owner:CSPO)」は、各研修を受講し、研修筆記、演習をこなし試験に合格した人に与えられる称号です。

tsumugにはなんと代表の牧田を含め6名の認定スクラムマスターが在籍!
認定スクラムマスター研修を受け、見事合格し認定されたtsumugメンバーはなんと6名!
開発チームだけではなく、サービスチームのメンバーや、なんと代表取締役まで認定バッチを取得しています。また認定スクラムプロダクトオーナーは、2名が資格取得しました。
なんと実は、認定試験を受けたメンバー全員が合格しています。エンジニア以外が認定スクラムマスターを取得、またメンバーの1/4が取得しているのは、珍しいそうです。


今後のtsumug

現在tsumugで開発している「TiNK Desk」「TiNK Office」などの空間サービスは、構想としてはCOVID-19感染症が拡大する前から私たちの中にあり、開発は1年以上前から取り組んできました。

「より使いやすいサービスにして、新しい働きかたを提供したい。より多くの人に利用していただきたい」と期待に溢れるなかで迎えた、2020年。気がつけば日本のみならず、世界中の人が、半ば強制的に「働き方をかえなければいけない」というターニングポイントに立っていました。

tsumugが提供する「自宅」でも「オフィス」でもない第3のリモートワーク環境は、感染症という不安のある時代でも、前向きに生きて働いていくための「空間」として、今後より必要な場所になっていくのではないかと考えています。

さまざまな人が、その人にとって最良の居心地のよい場所を選べるように。tsumugは今後もより柔軟な空間サービスを提供していこうと考えています。そんな柔軟なサービスの作り手である私たちも、「より居心地のよい仕事の進め方」をこれからも諦めず、改善し続けていきたいと思っています。

株式会社 tsumug | 〒810-0041 福岡市中央区大名 2 丁目 6-11 FUKUOKA growth next 301