見出し画像

スクラム開発の良いところ　～こんなチームだったらスクラム開発は上手くいかない～

コジマタイガ

ぼくは広告・マーケティング職出身で開発職でもなく開発PJに関わったこともありませんでした。そういった立場の人はアジャイル開発、スクラム開発、言葉だけは聞いたことあるが実際どんなものかわからないという方が多いと思います。ぼくもそうでした。（現在はscrum incの認定資格を持っています）
ただ、開発のPMをやっていたのは2年ほど、スクラム歴も同じくなので、ここまでやってわかったことをいくつか書きたいと思います。

ちなみにアジャイル開発の中にスクラム開発や他のスタイルがあるそうで、スクラムはアジャイルに内包されている概念です。ぼくはスクラムのみの経験なので、ここではアジャイル≒スクラムでお話します。

いきなり結論

まずは結論からですが、スクラム開発はぼくにとっては非常に合っていたと思います。理由は2つ。
・元来、飽きっぽい（報酬サイクルが長いのが苦手※）
・開発及びサービス領域に詳しくない
という背景とスクラム開発の良いところがマッチして、非常に良いサイクルでプロジェクトが回せています。それはなぜか…

※報酬サイクル：ゲーミフィケーションの考え方では選択したアクションに対しての反応を報酬と呼ぶのですが、ここではその選択と報酬の繰り返しを報酬サイクルと呼んでいます。なので、報酬サイクルが長いというのは「選択したあとに成果物が出てくるまでに時間がかかり、次の選択ができるまでも時間がかかる」という意味です。

アジャイル開発vsウォーターフォール開発

そもそもスクラム開発の対極にはウォーターフォール開発というスタイルがあります。そのウォーターフォール開発と比較した方がとわかりやすいのですが、そのスタイルの詳しい比較はbacklogさんのサイトで良い感じにまとめられてるので割愛します笑

参考：アジャイル開発とウォーターフォール開発の違いは何？アジャイル開発の手法や意味も要チェック
https://backlog.com/ja/blog/what-is-agile-and-waterfall/

ここではぼくの感じたことを簡潔に書きます。

ウォーターフォール開発
・最終的な成果物がプロジェクトが終わるまで出てこない
　→報酬サイクルが長い要因
・企画を完成させてから開発に着手する
　≒基本的には要件定義に立ち戻ることは悪である
　→要件定義の時点でプロダクトのビジョンがはっきりしている必要がある
　　そのため、作るサービスに精通している必要がある
　→プロダクトの軌道修正がしづらい

スクラム開発
・短い期間で開発スパンを区切るので、成果物の出てくるスパンが短い
　→報酬サイクルが短く、飽きにくい笑
・ウォーターフォールに比べて事前の要件定義で見据える先が短い
　→軌道修正がしやすくフィードバックが反映しやすい

プロダクトの軌道修正がしやすく成果物(MVP:Minimum Valuable Product)も早期に出せることから業界動向の早い業界やプロダクトの試行錯誤を前提としたスタートアップに向いているということのがよく言われていることですが、ぼくはモチベーション維持の観点からもスクラム開発は非常に良いものだと思っています。

画像1

ざっくりこんなイメージです。

スクラムイベント

これがスクラム開発の肝だと思っているのですがスクラム開発にはスクラムイベントという概念があります。
それぞれ役割をもたせた定例ミーティングです。定例ミーティングはどこの企業やプロジェクトでも当然のようにやっていると思いますが、フレームワークとしてそれぞれ行うべきイベントが定義されていると実行力も変わってくるなと思います。
ここではスクラムイベントの詳細についても割愛します笑

スクラムでも中長期計画は必要

すごく当たり前ですが、短期サイクルで開発を回すスクラムでも事業やサービスの中長期計画、いわゆる事業戦略は必要です笑
要件定義まできっちりとされている必要はないですが、1~3年のスパンでどのようなプロダクトを目指すのかといったビジョンやグランドデザインと、それに必要なフィーチャーチケットの見立てぐらいは必要でしょう。
これがないとスプリントプランニングの際にいきあたりばったりなプランニングになってしまい、スクラム開発で開発スピードは担保できても事業戦略
そういった意味ではプロダクトオーナーは事業戦略視点を持った中長期的なプロダクトデザインが求められます。

こんなチームだったらスクラム開発は上手くいかない

最後に実際にスクラム開発を回してこんなチームだったら上手く回ってなかっただろうなと思う点がいくつかあります。
・エンジニア間のコミュニケーションが円滑でない
・プロダクトオーナーもしくはスクラムマスターがスクラムイベントを欠席しがち
・中長期的プロダクトビジョンがない

スクラムチームでよってたかって要件定義と開発計画(スプリントプランニング)を作っていくのでエンジニア間での円滑なコミュニケーションが必須でしょう。
2週間単位で要件定義の変更やプロダクトの軌道修正が入るので意思決定者がなかなか捕まらないと途端に開発スピードが落ちてしまいます。他プロジェクトと兼任などしている場合は要注意です。ただのミーティングと侮るなかれ、プロダクトオーナーにとってスクラムイベントは最優先すべき仕事の一つです。
プロダクトの軌道修正がしやすいが故に中長期的なプロダクトビジョンを持っていないと開発の向かうべき方向を見失ってしまいスプリントプランニングのときにプランニング迷子になってしまいます。

Webマーケティングお手伝いします

このようにマンガを活用した広告など、Webマーケティング全般をお手伝いする会社を経営しています。
Webマーケティングのコンサルティング、広告代行、教育支援など行っておりますのでお困りでしたら是非ご相談ください。

会社ホームページ
https://joshuatree.jp/

個人Twitter
@tg_989

一緒に働ける人募集

弊社では事業拡大に向けて一緒に働ける人を募集しています！
契約形態は問いません。気になりましたら連絡ください！
・新規事業立ち上げ
・Webマーケティングコンサルタント
・Web広告プランナー
・Webデザイナー
・エンジニア
https://www.wantedly.com/companies/company_1988802

いいなと思ったら応援しよう！