🍳

経験則で考える、スクラム導入前チェックリスト

2025/01/16に公開

こんにちは!アルダグラムでレポートチームのエンジニアをしている志茂です。

レポートチームでは、お客様が利用されているExcelファイルをKANNA上にアップロードし、
Webから編集できるような機能を開発しております。

今回の記事のスコープ

スクラムの話をする際に、取り組んでるかそうでないかの話をよく聞くのですが、
実際に導入した上で、今のチームには効果的だったが、前のチームにはあまり効果出来でなかったような、具体的なケースを前提とした話はあまり聞かないような気がするので、自分が過去に所属した開発チーム(現職も含め)の体制を振り返って、帰納的にこんなケースだとスクラム効くんじゃないかという話をしたいと思います。

なのでアジャイルサムライのような教本に載っているような話ではなく、あくまで個人の体験として、具体でこんなケースだと結構良かったなという体験談をまとめたものになります。

スクラム開発とは(さらっと)

スクラム開発 (Scrum) とはアジャイル手法のひとつで、少人数のチームに分かれ短期間(1~4週間)の開発サイクルをくり返し行うフレームワークです。
開発からフィードバックまでのPDCAサイクルを短期間で行うことにより、
リードタイムを減らし、成果を最大化する手法です。
アジャイルサムライ――達人開発者への道

スクラムと直接関係はないですが、MVP(Minimum Viable Product)を理解できる、こちらのブログおすすめです。
Making sense of MVP

チェックシートのモチベーション

なぜこんな検証をするかというと、スクラムは試すだでもコストがかかるからです。
スクラムをしっかりやった場合、各イベントをメンバー全員で実施するため、mtgコストがかかるし、チームがスクラムに慣れるまで、おそらく5~6スプリントぐらいはかかるので、やってダメだったどうか検証するのにも時間もかかる。

以下どれだけかかるかざっくり計算したものです。

(タイムボックスが2週間の場合)
**合計**
5.5~10.5時間×人数

**内訳**
プランニング(1~4時間)
デイリースクラム(15分×10営業日)
スプリントレビュー(1〜2時間)
レトロスペクティブ(1~2時間)

**仮に5人チーム、時給4000円で5スプリント検証する場合**
5.5~10.5 * 5 * 4000 * 5
= 55万〜105万ぐらい(MTGだけで結構なコスト)

やってから結局コストかかるし、開発速度そんなに上がらないから、もとのやり方がよかったね。。とならないように自身の経験を振り返ってみて、帰納的にチェックシートを作りました。

過去の所属チーム 5チーム(自社開発)

ポータルサイト(BtoBtoC)

開発マネージャー1名、企画3名、デザイナー1名 開発メンバー7名
全体に占める売上比率の高い事業部でもあっため、リソースは潤沢で、タスクボードはあるがマネージャーが全てアサインを管理して、各メンバーに振り分けを行い、そのメンバーが完了まで進めていく。ウォーターフォール風味なカンバン。ガバナンスがしっかりしてる分、機能関連の仕様調整などは自チームだけでは、完結しないことが多い。

良かった点

  • メンバーは自身のタスクに集中できる
  • 各プロセス(設計~リリース)通りに進めるので、リリースがいつか読みやすい

改善したかった点

  • となりの席の同僚が何をやってるか把握辛い
  • 仕様の詳細を把握してないので、メンバー間でのhelpなど横方向の連携に弱い
  • 作業者とレビュワーも分割されていたので、複数人のフィードバックを受けづらい
  • 体調不良者が出るとPJを把握している人が少ないので、開発が止まる

キュレーションサイト(toC)

プレイング開発マネージャー1名、企画1名、デザイナー1名、PMO1名
開発メンバー4名
新規事業チームでtoCサービス。意思決定もほとんどの内容を自チームで完結できる
教科書通りのスクラムをタイムボックスを2W,プランニングも3~4時間ほどしっかり行う
サイクルごとにタスクを組み替えて、進める。メンバーが着手しているタスクは全員が仕様の詳細まで把握している。

良かった点

  • プランニングを時間をかけて行うことで、ジュニアメンバーのスキル向上に繋がった
  • 実装中の仕様の手戻り、変更はほとんどなかった
  • 誰かが詰まったり、休んだりしてもすぐにhelpに入りチームのパフォーマンスを維持できる

改善したかった点

  • 圧倒的にmtgが多い、10営業日のうち1営業日は確実に潰れている
  • 1年ぐらいやった後は、関係性もドメイン理解が出来上がっていたので、カンバン方式でもよかったのでは?という疑問が残る

小人数の既存サービスの保守、運用チーム(BtoBtoC)

開発メンバー3名
phpが5系か4系とかでimageがなくて、コンテナイメージが提供されておらず実装がつらめ。
初め開発部全体でスクラムを進めていました。途中から以前からのメンバーとの関係性もあり、人数も少ないので必要があれば、声掛ければよくない?となり、Jiraでタスクボード作成して、定期的なコミュニケーションは朝会で問題があれば報告する程度の変更

良かった点

  • 意識して連携をとる必要がないので、作業に集中できる。人数が少ないなりのメリットを活かせた気がする

改善したかった点

  • よくも悪くも個人に依存する。掛け算ではなく足し算。お互いのタスクの詳細があまりわからない。

金融系サービス(toB)

マネージャー(採用中:不在)、企画2名、デザイナー1名 エンジニア3名→5名

オフショアで依頼したもの自社開発に切り替えたため、コードも初期設計から見直したいような、アンチパターンを詰め込んだようなサービスになっていました。クライアントの要望により、タスク優先度が1週間単位で変わる。メンバーも歴が浅くドメイン知識も薄い状態。スクラムマスターとして、カンバン方式からスクラム開発に変更しました。

良かった点

  • チームで意思決定をするように変更したことにより、保守性が向上した
  • 外的な状況に変化があっても、スプリントバックログを調整するだけで対応できた
  • プランニングでタスク内容を共有するので、ドメイン知識のキャッチアップを効率的にできた

改善したかった点

  • 1次的(3スプリント分ぐらい)パフォーマンスが下がる
  • 当たり前ではあるが、mtgにコストがかかる

Iotサービス(BtoBtoC & toB)

マネージャー(1)、デザイナー(1) エンジニア(7)
対象サービスのアプリと管理会社向けのSaaSがあり、githubのprojectsで進捗管理を行い、タスクアサインはリードエンジニアが担当。業務委託の方もいるので全員がフルコミットではない。
カンバン方式で連携が薄くなってしまうことの補完として、朝夕のmeetを繋いで作業を実施、毎週金曜日にRetrospectiveを実施

良かった点

  • リードエンジニアにコミュニケーションラインが統一されているので、物事がスピーディーに決まり、進んでいく
  • 作業の独立性が高く、各自個人の作業に集中することができる
  • 連携不足をスクラム風味にすることで、コミュニケーション量をカバーできている。

改善したかった点

  • チームのタスクについて情報が集約、属人化される

アルダグラムの場合

タイムボックスが1週間のスクラムで開発を進めており、プロジェクト管理にはJIRAとNotionを使用しています。

各スクラムイベントに関しては、開発全体で行うものと各チームで行うものの2つに分かれており、開発部全体ではデイリースクラムとスプリントレビューのみを行い、チームごとでは各チームの状況に合わせて実施しています。

レポートチームでは、プランニングとデイリースクラムを行い、隔週に1度レトロスペクティブを実施しております。実装の詳細はチケットの担当者がDesign Docという設計ドキュメントを作成し、各メンバーがレビューすることで把握しています。プランニングでは、タスク内容の共有については実施内容の共有のみに留め、ミーティングにかかるコストを最小限にするよう工夫しております。

全体と各チームで別途ミーティングを設けるのはコストがかかりますが、KANNAではマイクロサービスを採用しておらず、各モジュールがGraphQL経由で通信していることもあり、各チームで具体的にどのような施策が進行しているかによって自チームの機能開発に影響が出る可能性もあるため、情報共有を行うことで開発の安定性を高めております。

結論

過去に経験した上記プロジェクト体制を振り返ってみて、経験則で重要な要素になっていそうなものをリストアップしてみました。
当てはまるものが少なければ、カンバン等々など別の手法を検討した方が良いかもしれないです。

  • チームに意思決定権が委ねられているか
    ガバナンスが効きすぎていないか、仕様、開発の設計、実装詳細などの意思決定権がチームに委ねられているか。

  • チームが少人数すぎないか
    開発チームは少なくとも4〜5人以上いるか。
    小人数でも回せないわけではないが、スクラム特有の会議コスト・役割分担のバランスを考えると、ある程度の人数がいた方がより効果的な気がしています。

  • 不確実性・変化に対応する必要性があるか
    プロジェクト進行する上で、不透明性、予測不可能性が高くないかや仕様変更が起こりやすいか。
    (例:toC向け、コード負債を抱えるプロダクト、ドメイン知識が乏しい領域、新規サービス、1〜2週間程度で要求変更が発生するような場合など。)

  • コミット時間の均一性か
    メンバー間で、ある程度均一なコミット時間が確保できるか。
    (業務委託や一部メンバーが部分的な稼働のみの場合は、スクラムイベントのコミットが難しくなる。)

  • 特定のメンバーへの依存度高くないか
    メンバーが横断的にタスクをこなせる、あるいは少なくとも進行中のタスク詳細をチーム全員が共有・理解できるような。特定の領域への個人依存度が高い場合、アサインするメンバーが固定化するため、全体感をメンバーで共有するメリットが薄れる(あのモジュールはあの人しかいじれない等々)
    ただ属人性を解消するために導入していくのは良い気はしています。

  • チームメンバー自走できる人が多いか
    タスクを自身で取ったり、仕様の詳細を詰める必要があったりと、タスクが決まるまであまり動かないスタイルのメンバーが多いと難しい気がしています。

最後に

以上、経験則で考える、スクラムの導入検討チェックチートでした。
正直自社開発チーム経験したことがないので、幅広く有益なものになっていなかったら申し訳ないのですが、お役に立てば幸いです!

もっとアルダグラムエンジニア組織を知りたい人、ぜひ下記の情報をチェックしてみてください!

アルダグラム Tech Blog

Discussion