こんにちは、レンティオの神谷です。レンティオの開発チームは現在エンジニア6名の体制で運営しているのですが、開発をスムーズに行うため半年前からスクラムを導入しています。

レンティオでは実はこれまでにも2度ほどスクラムを導入しようとして断念、いわゆるカンバン方式でのタスク管理をしばらく続けていたのですが、2020年からはスクラムによる開発サイクルがいい感じに回っています。

過去にスクラム導入を失敗した身としては、現場の仕事にスクラムを当てはめるのは経験者や強い目的意識を持った人がいないと少々難しいという理解でいます。今回は、スクラム移行するに至った経緯と、実際の業務にどうスクラムを落とし込んだか、半年ほどスクラムを回してみての所感や反省について残してみたいと思います。

スクラム導入前の開発体制と課題 🤯

スクラムを導入する前までは、Github IssueとGithub Projectsでタスク管理を行い、週一のミーティングで現状の共有、手持ちのタスクを終えるとマネージャーが追加のタスクを渡すといった流れで開発を行っていました。

エンジニアが2、3名だった頃はそれでスムーズに回っていたのですが、人が増えるにつれてによって様々な課題が出てきました。

例えばコードの属人化（この機能は○○さんしかわからない）、タスクを割り振るのが大変、タスク優先順位決定の精度が下がる、などです。

そしてスクラム導入時、エンジニア6人（社員4名、業務委託2名）という体制でした。もう1、2名はなんとか受け入れできそうでしたが、上記のような課題が顕在化することで何らかの対策を打たなければならないという危機感は感じていました。

スクラムの実務への落とし込み

スクラムの基本的な方法についてはこの辺りの記事や書籍が参考になりました。

レンティオではスプリントを一週間とし、ベロシティにはフィボナッチ数列を採用しています。数スプリント回すとチームで何ポイント消化できるのかが見えてくるのでそれを目標に毎週のスプリントを回します。

毎週火曜日にミーティングを行い、そこでレトロスペクティブ（振り返り）、バックログリファインメント、プランニングを行います。レトロスペクティブにはKPT方式を採用しています。リモート参加のメンバーもいるのでSlackの音声通話を使っています。

それに加えて毎日AMにデイリースクラムを開催、Clubhouseのカンバン（後述します）を画面共有しながら順番に作業内容と状況の報告、詰まってるところがあればその場で共有＆相談するという方式を取っています。

基本的にはスクラムの原則に従っているだけですが、スクラムを始めたばかりの頃にはこういうときどうするんだっけ？みたいのがよく出るのでスクラム経験者がいると頼もしいですね。

なお、一部業務委託のエンジニアはスクラムには参加せず旧方式（カンバンでのタスク管理）を継続しました。毎週の稼働量がブレる場合、ベロシティの見積もりがブレたりデイリースクラムへの参加が難しかったりするためです。この辺りが私が感じたスクラムの理想と現実のギャップです。スクラムは徹底しようとすると難易度が高い反面、妥協しすぎるとスクラムの良さが失われてしまうのでそこの力加減が難しい印象を受けました。

ツールにはClubhouseを採用

スクラムを回すためのツールもいくつかある中から探しました。ストーリーに加えてイテレーション、ベロシティがツール内で管理でき、バーンダウンチャートの描画とかもできれば尚良しです。

まずリモート参加のメンバーもいる以上、付箋＆ホワイトボードというリアルなツールは使えませんでした。ウェブサービスだとJIRA、Zenhub、CodeTree、Github Projectsあたりが候補でしたが、レンティオでは最終的にClubhouseというツールを採用しました。

あまり日本では名前を聞かないサービスですが、2020年には2,500万ドルの大型調達をしてるイケてるサービスのようです。

サービス紹介はこのページが詳しいです。スクラムでもカンバンでもなんでもいけるよ！とのこと。

Clubhouse導入前にいくつかのサービスを触ってみたのですが、欲しい機能がなかったり使ってみたけどちょっと違う、、みたいなことも多くありました。ですがClubhouseは豊富な機能をシンプルでわかりやすいUIにまとめており、まさにかゆいところに手が届くサービスという印象でした。スクラムを管理できるツールを入れたい、けどJIRAはちょっと重いかもというチームにはClubhouseはちょうど良いサービスかもしれません。

またAPIも公開されています。うちはGithub Issue依存が脱却できなかったため、integromat経由でGithubとClubhouseを接続して使ってます（GithubにIssueを立てると連動してClubhouse側にStoryが作られる）

今はプロダクトバックログの作成、ストーリーごとのベロシティの登録、バーンダウンチャートの作成、カンバンの表示をすべてClubhouse内で完結させています。

スクラムを導入しての所感

まず、ミーティングの時間が長くなりました（以前は週次のミーティングが40分だったのが、スクラム導入後は2時間半+デイリースクラム）

これはメリット・デメリット両方ありますが、まずはコーディングに当てられる時間が短くなるというデメリットがあります。

そして良かった点としては属人性の低下を感じています。各タスクのコンテキストをリファインメントで説明、実装方針をプランニングで共有するため、コードの品質が平準化され、かつ参加して日の浅い開発者も早くキャッチアップできるという利点がありました。

さらに、プロダクトオーナー（私）の視点では、タスクの洗い出しと優先順位決定に集中できるようになりました。というのも、このタスクを誰にお願いしよう？誰の負担が大きそう、誰の手が余ってそう、みたいなことのに脳内リソースを割かずに済むようになったのが大きいと感じています。

スクラム導入時のハードル

こう書いてみるとスクラムを入れることによるメリットのほうが明らかに大きいようにも見えますが、スクラム導入の難易度は低くないと思います。なお、最初にも書いている通りレンティオでは過去に2度スクラムを導入しようとして断念しています。

スクラムでは、各タスクをストーリーという「型」にはめて行く作業が発生しますが、スクラムの原則に遵守すればするほど割り込みタスクやゴールの定義しずらい調査タスクが扱いにくくなってゆくというのが私の印象です。

そして、これくらいはいいだろうみたいな小さな妥協が積み重なるといつのまにかスクラムが崩壊します。。そこはスクラムマスターが強い意志を持って臨む必要があるように思います。レンティオでスクラムが定着したのは、スクラムマスター経験者の方に加わっていただいたことが大きいです（ありがとうございます🙏）

なお、レンティオではスクラム開発が今はしっかりハマってると感じていますが、全てのチームでスクラムにより生産性があがるわけではなさそうです。そこはメリット・デメリットを天秤にかけチームにあった開発方式を選ぶのが良いかと思いました。

今後の方針

2020年9月にエンジニアがさらに2名増えることになります。上述した通り、スクラム導入によってミーティングの時間が長くなりましたが、参加者が増えることによりさらにミーティングの時間が長くなる可能性があります。レンティオの開発チームにはスクラムが合っていると思うので、スクラムを捨てることはまずありえないのですが、ミーティングが長くなりすぎるのも考えものです。

今後は複数のチームに分かれて対応していく必要があるかもしれませんが、担当するプロダクト単位でチームを分割するか、タスクの性格ごとにチームを分割しようかは悩みどころです。いずれにしても今のチームで生産性の最大化を目指してゆきたいと思います🚀

最後になりましたが、レンティオではエンジニアはじめ幅広い職種で積極採用中です！