Help us understand the problem. What is going on with this article?

少人数チームでスクラムをやってみた気づき

はじめに

  • 自分の経験として、初めて開発チームにスクラムを導入し、運用してきたことの個人的な感想をまとめます。
  • 題の通り、スタンダードなスクラムの運用とはちょっと違う部分もあったので、その状態でどう運用したかについて話せる範囲で残したいと思います。
    • ちょっと昔の経験を思い出しながら記述しているので、執筆不十分なところもあると思いますが、よろしければ最後までどうぞ

スクラムとは?

  • ざくざくっとまとめると以下のようなイメージ

    • アジャイル開発手法の一つ
    • 一定期間(スプリント/Sprintと呼ばれる)ごとにタスク消化/リリースを計画し、実行する
    • 基本的には5~6人以上のチームで行う
  • 場面によってはこんなことを言われていたりします。

開発チームのメンバーが3人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もある。

こちらより引用させていただきました→ The Scrum Guide

導入した背景

  • エンジニア個人のタスクを可視化したかった
  • 導入した当時、ガントチャートを使った進捗管理をしていたが、流動的に変わる計画に対応できなかったのでやり方を変えたかった
  • よそのチームが導入しているのを見て、自分がやってみたくなった

参考にした書籍

ちなみに、上記書籍は(スクラム初学者の方は特に)SCRUM BOOT CAMP→アジャイルサムライの順に読むのをオススメしたいです。
SCRUM BOOT CAMPで感覚ベースで掴み、アジャイルサムライでよりアジャイルの本質に踏み込んだ内容に触れていくという手順でインプットできました。

チーム構成

  • プロダクトオーナー(兼プランナー) ... 1名
  • エンジニア ... 2~3名(自分含む)

どのような運用だったか

  • 本来、スクラムを遂行するチームにはスクラムマスターという仙人のプロジェクトマネージャ的なロールの人がいるのですが、3〜4人しかいないのでそれがいません
  • 各スプリントの計画はプロダクトオーナーの要望に沿ってエンジニア側がブレークダウン・ポイントをつけていました
  • それ以外の点(デイリースクラムなど)は通常通りです。

少人数で良かったこと

  • 基本的には問題なく運用できていたこと
    • メンバー全員で履修含め導入前の準備ができていたという要因もありますが、私がチームを離れるまで基本的に大きな問題なく運用を継続できました。
  • デベロッパーとしてスクラムに参加する以上に自分の業務範囲が広くなる
    • 自分でタスクプランニングをしたりするという機会が得られたのは良い経験だったかなと思います。

同じくイマイチだったこと

  • タスク消化業務とタスクのプランニング業務の兼務が必然になる
    • これに尽きます。業務の範囲が広くなった分、エンジニアの開発タスクの時間がプランニングにも割かれてしまう状態でした。
      • 実際、私がチームを離れることが決まったあと、一歩引いた立場でスクラムの遂行をオブザーブすることがありましたが、自分が前線にいた時に見えなかったメンバーの負荷度合いなどが見えるようになったので、スクラムマスターの必要性をそのタイミングで改めて実感しました。
    • また、私のいたチームの場合、ある程度成熟しきったプロダクトの開発だったので、余裕があったから遂行できたというのはあるかもしれません。

さいごに

  • 少人数でスクラムを回すのは不可能ではないですが、可能ならやはり専任のスクラムマスターがいるのがベストなのかなとは思います。
    • 私の場合決して大きくないプロジェクト&開発プロダクトも成熟した状態だったからこそ、小規模でも導入でき、なんとか運用できているところはありました。
  • 総じて、少人数でスクラムを回す場合は自分の職務が増えることがどうメリットに働くか、どういったものを犠牲にするかを考えて導入することは大事かなと感じました。
    • 個人的に思うのは、マネジメントキャリアを目指すエンジニアは一度経験してみることはあえて少人数でスクラムをやってみるのは悪くないのではないかと思います。

おまけに

実際に運用していた時に使っていたサービスについて簡単に触れたいと思います。
綿密に比較検討をした上で決定したわけではないので、より良いものがあればぜひ教えて欲しいです!(他力本願)

  • Trello
    • 厳密に言うと、スクラム導入前に無計画にタスクを可視化するためだけに導入していました。無計画にというところがよくないですね。
    • シンプルかつ自由度が高いのでスクラム以前にTODOリストという軽い目的から手軽に使えるのがいいところかなと思いました。当時は後述するZubeに乗り換えましたが、今改めて考えたらTrelloでも全然運用できたな・・・
    • Chrome経由でプラグインを導入できるので、カスタマイズ性も○
  • Zube.io
    • 使用経験のあるメンバーにオススメしてもらったものです。
    • Sprintごとにカンバンを区切ったり、タスク(カード)ごとにポイントを割り振ったりなど、スクラム運用向けに色々な機能が盛りだくさんです。
    • GitHub Issueと連携しているので、ソースコードをGitHubで管理していると色々と恩恵あります。
    • まともな人数で運用しようとすると有料プランになってしまう点がややハードル?
juhn
Webエンジニアとして頑張りたいです。頑張ります。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした