こんにちは、エンジニアの濱崎です。

クラシコムのエンジニアチームでは、2015年からスクラムでチームを運営してきました。

最近ではスクラムを取り入れている会社も増えてきましたが、やり方は会社やチームによってまちまちで、ベストプラクティス的なものは無いんじゃないかと思います。

クラシコムでも、最初はゆるくスクラムを始めて、いろいろと試行錯誤しながら今のやり方にたどり着きました。

このエントリでは、僕らなりに2年間スクラムを実践してきた中で、うまくいったことや失敗したこと、それらを通して学んだことをお伝えします。

これからスクラムをやろうとしている方や、すでにスクラムを実践しているチームにとって、少しでも参考になれば嬉しいです。

「スクラムって何？」という方は、以下のスライドを読んでいただけると概要をつかめると思います。

ゆるいスクラムから始まった

エンジニアが1人しかいないときはスクラムはやっていませんでしたが（チームじゃないので当然）、僕が2人目のエンジニアとして入社してエンジニアチームができたときに、スクラムによる運営がスタートしました。

当時は、ECシステムのリニューアルという大きなプロジェクトが始まるタイミングでもあり、「優先順位の高い機能から開発していく」というスクラムのコンセプトが必要だと感じていました。そうしないと、大して重要でない機能にリソースを使いすぎて、プロジェクトが肥大化してしまうからです。

また、クラシコムでは職種に関係なく、全員が残業をせず18時に退社するのですが、これを可能にしている要因の1つに、「本当に必要な仕事に集中し、やらなくても良いことにリソースを使わない」という点があります。
スクラムのコンセプトは、こういったポイントにもすごくフィットしていると感じました。

はじめはスクラムのルールをガチガチに守ることはせず、"スクラムのような" やり方から始まりました。
最初のフェーズでは、以下のルールくらいは守っていましたが、それ以外はゆるくやっていました。

• スプリントプランニングとモーニングスクラムはやる
• プランニングでは、エンジニアがユーザーストーリーの重さをストーリーポイントで見積もり、優先度を考えて次のスプリントでやるストーリーを決める
• ストーリーごとにGitHubのブランチを作って作業

これをやるだけでも、まずはタスクの見える化ができ、2週間ごとに計画を立ててリリースするというフローができたのは良かったと思います。

また、DevOpsやCIのフローができていたので、小さなサイクルでリリースするアジャイルなやり方にスムーズに対応することができました。

もっとちゃんとスクラムやろう

最初の1年くらいは1つのプロジェクトに集中して突き進んでいたので、ゆるいスクラムでもなんとか回っていましたが、ECシステムのリニューアルプロジェクトが終わってからは、いくつか課題が出てきました。

• 社内の管理システムをリリースして以降、他チームからの要望が多く出てくるようになり、管理や対応が追いつかない
• ユーザーストーリーの受け入れ基準がないため、メンバー間で認識の齟齬が生まれる
• スプリントの振り返りをしていなかったので、チームの問題点に気づかないし、改善もできない

こういった課題に対応するために、それまでのやり方を見直し、"ちゃんとした" スクラムをやるようになりました。
何度かの見直しを経て、クラシコム流のスクラムのやり方が確立されてきたので、ここでご紹介します。

モーニングスクラム

毎朝チーム全員でカンバンを見ながら、昨日やったこと・今日やること・困っていることを共有します。
15分以内に終わるようにして、詳しく話す必要があるときは、モーニングスクラムが終わってから個別で話します。

バックロググルーミング

毎週金曜日に1時間使って、プロジェクトの機能要件や他チームからの要望などをユーザーストーリー化し、詳細を詰めていきます。

優先順位、受け入れ基準（ストーリーを完了にする基準）、大まかな実装方法、ストーリーポイントの設定まで落とし込みます。

以前はスプリントプランニングの中でこれをやっていたので、プランニングの時間が足りなくなり、受け入れ基準も曖昧になっていました。

事前にユーザーストーリーを詳細化した状態でプランニングに入ることで、スムーズに計画を立てることができ、受け入れ基準の見落としやメンバー間での認識の齟齬も減りました。

レトロスペクティブ

2週間のスプリントの最終日に、1時間使って全員で振り返りをします。
司会進行役は交代制にすることで、メンバーが傍観者にならず、全員が当事者意識をもって参加できるようにしています。

振り返りのやり方としては、スクラムでスタンダードになっているKPT（Keep / Problem / Try）を使っています。

• Keep → 良かったこと・今後も続けたいこと
• Problem → 問題になっていること・課題
• Try → 今後試したいこと

KPTのそれぞれについて数分ずつ考える時間をとって、Trelloのボードに全員で一斉に書き込んでから内容を共有します。

Tryのなかで実作業が発生するものは、ユーザーストーリー化してリソースを確保した上で実行します。

立ち止まる機会を強制的につくらないと、人間はなかなか振り返ることをせずに進み続けてしまうものですが、振り返る機会が定期的にあることで、早い段階でチームの課題を発見し、継続的にチームを改善することができています。

プランニング

レトロスペクティブの後に、1時間使って次のスプリントの計画を立てます。

ユーザーストーリーの詳細化はバックロググルーミングでやっているので、どのプロジェクトにどれだけのリソース（ストーリーポイント）を割いて、どのストーリーをやるのかを決めるだけで済みます。

カンバンボード

ユーザーストーリーの管理には、ZenHubをカンバンとして使っています。

ZenHubはChromeのエクステンションで、GitHubのissueにカンバンの機能を追加することができます。

UIが直感的で使いやすく、ストーリーポイントの設定、Epic、バーンダウンチャートなどの機能があります。

他チームからの要望管理

他チームからのシステムに関する要望は、Trelloで管理しています。

以前はGoogleスプレッドシートを使っていましたが、データが増えると動作が重くなり、要望の並び替えやステータス管理などが大変でした。

Trelloは直感的なUIで、順番の並び替えやステータスの移動がとても簡単です。
要望が追加されたらSlackに通知できるし、添付ファイル、ラベル、期限の設定などもできてすごく便利ですね。

混在するユーザーストーリー

もともと、数ヶ月単位の大きなプロジェクトや、既存システムの小さな改修、開発以外のタスクなど、あらゆる種類のユーザーストーリーを1つのカンバンで管理していたのですが、そのような管理方法にはやがて限界が訪れました。

• 優先順位を決めづらい
• どの種類のタスクにどれだけのリソースを割いているのかが分からない
• いろんな種類のストーリーが入り混じっていて見づらい

上記のような問題点が出てきたため、ユーザーストーリーの種類によってカンバンを分けることにしました。
現状、以下の3つのカンバンに分けてユーザーストーリーを管理しています。

• 発注システムリニューアル
  → 数ヶ月以上かかる規模のプロジェクト。
• 定常開発
  → 既存システムの小さな改修や、1ヶ月以内に終わる機能追加など。
• 非開発タスク
  → 開発作業を伴わないユーザーストーリー。
  例）エンジニアブログ、ドキュメンテーション、採用関連のタスクなど

非開発タスクは、直接的にビジネス価値を生み出すような成果物があるわけではないので、ストーリーポイントを付与すべきか迷いましたが、会社やチームにとっての価値を生み出すことなので、ポイントを付与しています。

ツールの限界を感じる

プロジェクトごとにカンバンを分けることで、優先順位が決めやすくなったり、カンバンの見通しが良くなるなど、いくつかの問題が解消されました。

一方で、全プロジェクトを跨いだ総合的なチームのベロシティを把握しづらく、各プロジェクトに対して全体の何パーセントのリソースを割き、何ポイントのストーリーを消化できるのかといったことが分からないなど、新たな問題点も出てきました。

1チーム = 1プロジェクトであれば、このようなことを気にする必要はあまりないと思うのですが、クラシコムはエンジニアの人数が少ないため、1チームであらゆる種類のプロジェクトをやる必要があるのです。

ZenHubには、プロジェクトを跨いでリソースの管理をする機能はないため、Googleスプレッドシートを使って以下のような数値を管理することにしました。

• 各プロジェクトで消化したストーリーポイントの実績
• 各プロジェクトのベロシティ
• プロジェクトを跨いだチーム全体としてのベロシティ
• 休日を考慮し、各メンバーが次のスプリントで何パーセントのリソースを使えるか
• 各プロジェクトに対して、次のスプリントで全体の何パーセントのリソースを使うか
• 各プロジェクトが、次のスプリントで何ポイントのストーリーを計画できるか

スプレッドシートなので、そんなに使い勝手が良いわけではありませんが、これのお陰で実績の把握と次のスプリントの計画が格段にやりやすくなりました。

いつかこれをアプリ化して、リソース管理とカンバンの管理を1つのアプリで完結させ、社外にも公開したいというのが僕の野望です。

見えてきた課題・今後の展望

2年間いろいろと試行錯誤しながら、自分たちのチームにフィットしたスクラムのやり方が見えてきましたが、新しい課題もいくつかあります。

• 次のスプリントに引き継ぐストーリーのポイントをどう扱うか
• Trelloに登録された他チームからの要望を、ストーリーとしてZenHubに登録するのが面倒
• 1ポイントの定義が難しい
• デザイナーなど他チームとの共同プロジェクトをどう扱うか
• リモートの外部リソースをどう扱うか
• エンジニア以外のチームでもやれるか

これらの課題について考えつつ、これからチームが大きくなったり役割が変化していくのに合わせて、今のスクラムのやり方もフレキシブルに変えていく必要があると思っています。

クラシコムでは、これからのECを一緒に作っていってくれるエンジニアの仲間を随時募集していますので、興味がある方はぜひ一度オフィスに遊びに来てください！