スクラム認定試験受けて来ました！Part1

2022.07.25

dcWORKSシステムエンジニアの3%です！

人物紹介・3%
システムエンジニア。社内飲みで残った食べ物は彼のお腹へ還る。9%アルコール缶が好きだったが3%へ方向転換。

突然ですが、、
スクラムマスター認定講座というものを受けてきました！

スクラム開発、アジャイル開発という名称を多く聞くようになってきていますが、ウォーターフォール開発となにが違うのか。
アジャイル開発のように進行している現場は多いもののやり方があっているのか。

一度体系的に学びたいと思い本講座を受講しました！
（ついでに認定スクラムマスター試験も合格し、3%は無事認定スクラムマスターとなりました。）

では早速、スクラム開発とはなんぞやという話からはじめていきます。

スクラム開発とは、「スクラムガイド」によって定義されているアジャイルの開発手法のフレームワークです。ラグビーの「Scrum」が語源とされています。
スクラム開発は、サービス/プロダクト開発スピードを高め、変化に強い柔軟さが特徴の手法で、近年各企業で取り入れられ始めています。

スクラムガイドどは

スクラム公式ガイド：ゲームのルール
「【ゲームのルール】とあるようにスクラム開発はゲームを進行するように楽しいものだ！」と
今回の講座の講師を勤めてくださったジョーさんがしきりにおっしゃっていました。

以下引用ーー

スクラムチームとは：
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完了するための⼗分な⼤きさがあり、通常は10⼈以下である。⼀般的に⼩さなチームのほうがコミュニケーションがうまく、⽣産性が⾼いことがわかっている。

ーー引用ここまで

スクラム開発とウォーターフォール開発で異なる点は「1.機能横断型」、「2.⾃⼰管理型」、「3.通常は10⼈以下である」という3点になります。
以下でそれぞれについて詳しくお伝えします。

1.機能横断型

ウォーターフォール開発では、デザイナー・ディレクター等の職種分けはもちろん、エンジニア内でも設計・フロントエンド・バックエンド・インフラなど、各分野を得意とするメンバーが自身の役割のもと価値を発揮するのに対し、スクラム開発では明確にそれらを定義しません。
つまり、各メンバーが職種関係なく、タスクを消化していくことになります。
これにより、設計フェーズでプログラマーの作業が枯れてしまい、製造フェーズでデザイナーの作業が枯れてしまうというような状況が発生しないというメリットの反面、各メンバーがゼネラリストであることが求められます。
（最初からそうでなくともそれを目指していくというチームを形成することが大事なのだそうです。）
ただ、日本のリソース状況であったりとかエンジニアのスキルセット的なところとはまだまだマッチしきれていない印象はあり、そこが導入のハードルとなり得そうですね。

2.⾃⼰管理型

従来の開発では、タスクは「振られるもの」という意識が強かったと思います。
スクラム開発ではタスクは「自分で選ぶもの」と定義されます。
たとえば、タスクやイシューのチケット一覧の中から、「今日はこれをやる！」と各メンバーがタスクを決定していきます。
その中で全体の進行をデイリースクラムと呼ばれる会議体で確認していくという進行です。
先の「機能横断型」とつながる話でもありそうですね。
振られたタスクよりも自分で選んだタスクのほうが、積極性や責任感が増し、結果としてモチベーションも上がる！というのが理由です。

3.通常は10⼈以下である

開発チームの人数は規模により大小様々だと思いますが、スクラム開発では4〜5人が望ましく、多くとも10人以下と定義されています。
これ以上となる場合は、チームを分割し再編成します。
マイクロサービスな開発現場なら親和性は高そうですが、いわゆる従来の設計だと、どこを分割するのか悩ましいシーンもありそうです。

各メンバーの役割について

こちらのジョーさんが書いている記事を見るとわかりやすいかと思います。
端的にまとめると以下となります。

開発者：
ゴールに向けて開発を計画し、品質よく作る。

スクラムマスター：
スクラム開発のフレームワークを開発者、プロダクトオーナーに適用させる。
開発者に降りかかる障害をすべて取り除く。

プロダクトオーナー
プロダクトとして何をつくるか、優先順位を明確にする。（最終決定）

受託開発の場合はプロダクトオーナーをクライアントにお願いするケースが多いので、その場合、上記のような役割の明確化とコミュニケーション頻度を高めることが重要ですね。

次はスクラム開発進行方向について書いていきたいところですが、長くなりすぎてしまうので次回のブログで書こうと思います！

第二回乞うご期待！

以下、余談です。
機能横断型って言うのは簡単だけど、実際そんな上手くいかないよねーと思う方も多いと思います。
自分もそう思い、スクラムマスター認定講座の講師に質問しました。
すると
「そんなときに最高の解決策を教えよう！それはMOBだ！」
と言われました。

おそらくこんなイメージでしょうか。
みんなで同じ画面を見て、「ここはもっとこうだよー」など意見出しながら、プログラム書いたり設計したり作業進行するのだそうです。
なんか楽しそう！でもみんなで一つの作業してたら進行悪くなってしまうのでは？と思いましたが、結果としてこのほうが成果が上がるケースが多いそうです。
すべての作業をこれで！とするのはまだまだ難しそうですが、開発初期の方針合わせだったり、経験浅いメンバーの教育も兼ねてなどであれば使えるシーンは多そう！と思いました。

とはいえ、スケジュールが切迫してたりすると中々採用に勇気がいりそうです。