＜＃１＞なぜスクラム開発を採用したのか

１．スクラム開発は「アジャイル開発」の手法の一つ

スクラム開発とは、「アジャイル開発」という考え方に基づいたソフトウェア開発手法の１つです。

「アジャイル開発」について簡単にまとめると以下のようになります。

・アジャイルという言葉は「機敏な、素早い、敏しょうな」という意味を持つ

・アジャイル開発は「価値のあるものをスピーディにアウトプットする」ことに重点が置かれている

・アジャイル開発における基本的な考え方が「アジャイルソフトウェア開発宣言」として定義されている

２．なぜスクラム開発を採用したのか？

株式会社インサイトでは、OH!KIMOCHI開発までスクラム開発を採用したことはほとんどありませんでした。

OH!KIMOCHIもベースの開発はウォーターフォール開発で行っています。

本格的な自社サービスに初めてトライする中、サービス提供初期にはモニター企業様にご試用いただいており、

そのモニター企業様からの様々なご意見にいかにスピーディに応えていくのかが課題となりました。

常々「アジャイル開発」の優位性を感じていたこともあり、セミナーに参加させていただいたり、書籍を読んだりして、

アジャイル開発の手法の一つである「スクラム開発」にトライすることを決めました。

３．最初は「なんちゃって」スクラム開発になってしまった

スクラム開発では、以下のようなロール（役割）が定義されています。

◆プロダクトオーナー

◆スクラムマスター

◆エンジニア

スクラム開発の概念や基礎的な知識は学習していたものの、本質的な理解や準備ができてなかったため、

・「プロダクトオーナー」はウォーターフォールで言う「ＰＭ」に当たる？

・「スクラムマスター」はウォーターフォールで言う「リーダー」に当たる？

・「エンジニア」は設計、実装、検証を実行する技術者を指している？

程度の理解にとどまっていました。

上記のような（今思えば）誤った理解の下、スクラム開発で定義されている以下の「イベント」をこなしていました。

◆デイリースクラム

◆スプリントプランニング

◆スプリントレビュー

◆スプリントレトロスペクティブ

◆プロダクトバックログリファインメント

上記イベントはスクラム開発を進める上でそれぞれ重要な意味、機能を持っていますが、こちらの理解も曖昧なまま、

「まずはやってみよう！」という意気込みのみで突き進んだ結果、「なんちゃって」スクラム開発となってしまいました。

４．「なんちゃってスクラム開発」の実態

そもそも、各ロールの理解が誤っていた時点で上手くいくわけがないのですが、各イベントは以下のような様子となりました。

・デイリースクラム

これまでやってきた朝会と同じ感覚でやってました。司会進行はプロダクトオーナーがやってましたが、デイリースクラムは

エンジニアのための時間であり、プロダクトオーナーはその出席も任意であることが多いです。

結果、エンジニアはプロダクトオーナーに聞かれたこと（進捗はどう？課題はある？）に応えるだけでした。

・スプリントプランニング

「スプリント」という短い開発期間で何を開発するのかと、その担当/スケジュールを決めてました。

プロダクトオーナーがやって欲しいことを伝え、それをいかにスケジュールにはめていくのかが主たる議題となっていました。

「上意下達」的な会議になっていたため、スケジュールのパズルに終始していました。

・スプリントレビュー

スプリントプランニングで決めた内容を実行した結果をデモンストレーションし、ステークホルダーからのＯＫを貰う場だと考えていました。

実際にはデモが主目的ではなく、スプリントの結果に対するフィードバックをもらい、それを次のスプリントへのインプットとすることが狙いです。

・スプリントレトロスペクティブ

レトロスペクティブという言葉の意味は、「振り返り」です。

当初は、スプリントレビューとのすみ分けが出来ておらず、スプリントで何が出来たのか、何が出来なかったのか、今後何を改善していくのか、

というテーマはあったものの、予定していた機能のうちこの機能はここまで出来た、この機能は出来なかった、今後はスケジュールに収まるように

見積精度を上げていく、といった内容に終始していました。

次回は「なんちゃってスクラム開発」の成れの果て、についてご紹介します