Scrum Incが提供する認定スクラムマスター（LSM）研修を受講し、無事に試験も合格となり、認定スクラムマスターとなりました。今回はスクラムで開発を進行するにあたり、自分の中で疑問だった内容を纏めておきます。
（綺麗に纏めておらず、殴り書きの状態ですが、忘れないうちに！と記載したものです。都度、アップデートして整理していきたいと思いますので、見辛い文章はご了承ください。）

認定スクラムマスター（LSM）研修
https://scruminc.jp/

スクラムの事前知識

スクラムの経験はほぼ０です。
私はプログラマーとして社会インフラの監視制御システム開発で、ガッチガチのウォーターフォールを約８年間ほど、その後、自社サービスの開発で約３年間ほどウォーターフォールとカンバン管理を混ぜ合わせたような名も無い管理でプロジェクトマネージャーを行なっておりました。
各フェーズでかなり厳しいチェックが入る開発を行なっていたので、「アジャイル？スクラム？　そんな進行の仕方で、うまくいくの？」など、自分の過去の管理方法を美化しているところがあり、少しアジャイルの考え方に否定的でした・・・
そのため、スクラムの勉強を行うにごとに様々な疑問点（疑いの目）が浮かんでいたので研修ではその疑問を解消しようと思い、受講しました。

研修内容について
Day-1

　まずテーブル毎にチームを組み、研修の２日間を過ごすことになります。その中でプロダクトオーナー役を１名、スクラムマスター役を１名、その他メンバーは開発チームとして進めて行きます。１日目は、「スクラムとは？」の入門的な話から、紙飛行機をとある条件と制約のもと飛行させ、スプリントを３回実施して効果を見るなどのワークショップを体験しました。

Day-2

　２日目は、昨日の「振り返り」から始まり、見積の方法や、スクラムオブスクラムについてなど、スクラムについて深掘りした内容が中心でした。研修は、Day1同様にコーチからの説明を受け、実際に試してみて体感する進行の仕方で頭と体で覚えることができるので、理解が深まりました。

研修で解消されたスクラムの疑問点

スクラムに向かないPJや案件は？

こちらは研修に参加した多くの生徒の方も気になっていたようで、似たような質問が多くありました。コーチの回答としては以下の内容の場合は、スクラムには向かないとのことでした。

・都度、同じ作業が発生するルーチンワーク
・請負での受託開発
・発注者側がウォーターフォール慣れしていて、スクラムを知らない

スクラムの場合、実際に動くソフトウェアを見せて、フィードバックをもらい、改善していく流れを取るため、要件が定まっていない場合に効果があります。逆に要件がはっきりとしており、ある程度プロダクトのイメージも明確になっている場合は、ウォーターフォールでの開発進行が発注者側もやりやすいのでは？と理解しました。

スクラムでの失敗事例は？

こちらも多くの生徒の方から質問が挙がっておりました。スクラムを実際に利用して開発を行なっているチームメンバーの方の実例としては、以下の内容でした。

チームの崩壊
・とあるメンバーが、ワガママで個人プレーに走ってしまい、メンバー同士が協力する意識が薄れて崩壊した

決めないプロダクトオーナー
・決めないプロダクトオーナーだったため、POに頼ったり、確認するといったことがなくなってしまい、フィードバックでのタスク過多が発生。故にプロダクトバックログが整理できない状態となった。

何を基準に失敗と判断するかですが、スクラム開発でも上記のような失敗事例があり、スクラムだから成功するというはないとのことです。

ウォーターフォールはもうだめなの？

今回の研修を受けての私の結論は、「お客様と案件次第では、ウォーターフォールの方が良い場合もある」です。

ウォーターフォールで開発を行うとWBSガントチャートという納期までの工程表があります。これは、いつまでに何を終わらせる必要があるかがパッと見分かりやすく書かれているので、発注者側も俯瞰で確認することが可能で、事前に未来の計画が立てやすいものだと思います。

スクラムではバーンダウンチャートというもので、この調子でいけば、いつくらい終わるかかが分かります。自チームのタスク消化量をもとに、作業予定タスクのボリュームを見て、今の作業は大体いつ頃終わるかを判断します。

上記の観点から、私の中で開発を進める管理方法の選択基準は、以下の理解となりました。

スクラムの判断基準
・自社サービスなどで、外部要因で仕様がちょくちょく変わったり、市場の状況の変化が大きく、先日決まった内容がコロコロ変わってしまうことが多いサービスの場合。また「やってみないとわからない」ことが多いサービスの場合。

ウォーターフォールの判断基準
・要件が明確に決まっており、大きく仕様変更も発生する恐れがない場合、業務システムやインフラなどの監視制御システムなど。

開発以外の案件でも実績あるの？

あるそうです。営業などWEBマーケ、バックオフィスなどの業務でも適用されているそうです。

その他、注意点などのまとめ

今回の研修により、コーチの方から教えて頂いたスクラムで注意すべき内容です。

・スクラムの場合は、一括請負ではなく、準委任で契約した方がよい。
・スクラムの場合は、発注者側もスクラムの理解が必要。
・発注者側がスクラムを希望した場合、なぜスクラムなのかを問うこと。
・発注者側のプロダクトオーナーがスクラムを理解していても、発注者側のエクゼクティブ層が理解していないと危険。
・スクラムマスターは開発メンバーと兼任でもよいが、プロダクトオーナーとスクラムマスターは分けること。

スクラムもいいところがあるし、ウォーターフォールでもいいところがあり、どちらもメリット・デメリットを理解した上でより良い選択を行えれば良いかなと思いました。ただ今の時代の様々な変化の速さを考えると、経営層の理解が得られるのであれば、私は今後のPJを迷わずスクラムで進行すると思いました。

スクラムマスターの仕事には、ステークホルダーにスクラムの価値やフレームワークを理解してもらうことも大事だと思うので、今後はスクラムの理解を様々な業種、決定権がある人に広めていきたいとも思います。