Slide 1
Slide 1 text
スクラム研修
パーソルキャリア株式会社 テクノロジー本部 エンジニアリング統括部 サービス開発部
※本資料は2023年3月時点の情報であり、2023年新卒の研修教材です。
Slide 2
Slide 2 text
目次
◉ 研修の目的とゴール
◉ スクラムを知る前に
◉ 主な開発手法について
◉ アジャイル開発手法について
◉ スクラム開発について
◉ まとめ
Slide 3
Slide 3 text
研修の目的とゴール
0
Slide 4
Slide 4 text
研修の目的とゴール
皆さんが今後配属されるプロジェクトでは、基本的にスクラム開発の
手法を採用して開発を行っています。(※)
本研修を通して、スクラム開発の手法ならびにそれ以外の開発手法に
関して学び、様々な開発手法を理解した状態を目指しましょう。
※ プロジェクトによって、導入時期や実施形態に違いがあります
Slide 5
Slide 5 text
スクラムを知る前に
1
Slide 6
Slide 6 text
チーム開発の難しさ
個人開発であれば、仕様や設計などは自分が全て理解しているのでひたすら手を動
かせます。
ですが、チーム開発では複数人での開発になるためこんなケースが生じます。
● Aさんにタスクをアサインしたのに実装された内容が要件と異なる
● BさんとCさんの目的意識がずれていて議論がまとまらない
● AさんのコードをBさんとCさんがレビューしたが、実装ルールが定まっていないた
め、レビューの観点が異なる
● どのタスクの優先順位が高いかを把握しておらず、緊急性かつ重要度が高いタスク
が後回しになってしまった
Slide 7
Slide 7 text
チーム開発する上で最も重要なこと
コミュニケーションを大事にしましょう！
先程の例は、コミュニケーションをとっていれば大体防げていたはずです。
● タスクが締め切りまでに間に合わなさそうだからリーダーに相談する
● 今日は○○のタスクを着手します。と報告する。
● 仕様に不明点があった場合は誰かに聞いて不明部分を解消する
● 自分の認識が合っているか不安だったら先輩に認識合わせをお願いする
コミュニケーションで解決できることはたくさんあります。報連相を怠ってしまう
と様々な問題が発生するリスクが高くなるため、必要に応じてコミュニケーション
を取るように心がけてください。
Slide 8
Slide 8 text
主な開発手法について
2
Slide 9
Slide 9 text
主な開発手法
◉ ウォーターフォール型開発
◉ プロトタイプ型開発
◉ アジャイル型開発
Slide 10
Slide 10 text
ウォーターフォール型開発
一つ一つの工程を順番に進めていくことを
ウォーターフォール型開発と言います。
V字モデルを用いて説明されることが多
く、昔からある開発手法の一つです。
開発の前に厳密な仕様設計を行い、段階ご
とに工程を進めていくので後戻りができな
いことが特徴です。
ITトレンド.「ウォーターフォールモデルとは？メリット、アジャイルとの違いを解説」.
https://it-trend.jp/process_management/article/464-0012,（参照2023-04-10）
Slide 11
Slide 11 text
デメリット
● 柔軟性に欠ける
● ドキュメントが多い
● ドキュメントの整備の時間が多い
● ユーザーの意見を取り入れにくい
メリット
● 大規模な開発に向いている
● PJ全体の計画が立てやすい
● 進捗管理がしやすい
ウォーターフォール型開発
Slide 12
Slide 12 text
プロトタイプ型開発
開発に入る前・開発の早い段階で試作品を作成し、依頼者・発注者が
レビューをして認識齟齬がないかを確認します。
その上でシステムの仕様を決めていくという開発手法になります。
メリット
● 早い段階で完成品のイメージ共有ができる
● 認識のズレが回避できる
● 不具合やバグの早期発見ができる
● 品質が高いプロダクトにつながる
デメリット
● プロトタイプの開発のための工数が
増える
● 大規模な開発には向かない
Slide 13
Slide 13 text
アジャイル型開発
アジャイル型開発は小さなサイクル（スプリント or イテレーション）で計画・開発・テ
ストを繰り返して開発を進めていく手法になります。
ウォーターフォール型開発とは違い、最初に厳密な仕様設計を行わずおおよその仕様や
要求を取りまとめて開発を進めていきます。
つまり、「あらかじめ厳密な仕様設計を行ったうえで全行程の計画を立て、実行してい
く」のではなく「開発の方向性・方針は定めた上で開発中に発生するあらゆる状況に対
応できるよう柔軟に開発を進め、仕様変更に強くリスクを最小化していく」手法になり
ます。
Slide 14
Slide 14 text
デメリット
● PJ全体のスケジュールが読みづらく
なる
● しっかりコントロールしないと開発
の方向性を見失いがち
メリット
● ユーザーとコミュニケーションを取
りながら開発が可能なので、
ユーザーの要求に最大限応えられる
● 仕様変更や追加に柔軟に対応可能（※）
● 開発者のモチベーションが高まる
※あくまで仕様変更など柔軟に対応できるとい
う事で、ゴールそのものを変えるという事では
ありません
アジャイル型開発
Slide 15
Slide 15 text
アジャイル型開発
アジャイルソフトウェア開発宣言
(2001年に当時ソフトウェア開発手法分野で活躍していた
17名の専門家によってまとめられた文書
)
◉ 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
◉ 要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
◉ 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
◉ ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
◉ 意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
◉ 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
Slide 16
Slide 16 text
アジャイル型開発
アジャイルソフトウェア開発宣言 .「アジャイルソフトウェア開発宣言」 . https://agilemanifesto.org/iso/ja/manifesto.html,（参照2023-04-10）
◉ 動くソフトウェアこそが進捗の最も重要な尺度です。
◉ アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
◉ 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
◉ シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
◉ 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
◉ チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり
方を最適に調整します。
Slide 17
Slide 17 text
まとめ
開発手法を 3つ挙げましたが、今後皆さんが携わるほとんどのプロ
ジェクトでは、アジャイル開発であるスクラム開発を採用していま
す。
次の章ではスクラム開発を含めた 3つのアジャイル開発の手法を
説明します。
Slide 18
Slide 18 text
アジャイル開発手法について
3
Slide 19
Slide 19 text
“
アジャイル型開発では多くの手法がありますが、
ここでは 3種類の手法を簡単に紹介します。
Slide 20
Slide 20 text
アジャイル型開発手法
スクラム
昨今で一番流行っている手
法かと思われます。
プロジェクトの管理に重き
を置いた開発手法。
チームワークを重視する特
徴があります。
詳しい説明は後述。
エクストリーミング・
プログラミング（XP）
プログラマーに重きを置いた
開発手法。
ペアプログラミングやテスト
駆動開発（TDD）、リファク
タリングなどを必ず用いる手
法になります。
リーンソフトウェア開発
（LSD）
トヨタ生産方式をソフトウェア開
発に適用したものになります。
とにかくムダを省くということに
焦点を絞っています。
前者の2つと違い、固有のプロセ
スやプラクティスはありません。
Slide 21
Slide 21 text
スクラム開発について
4
Slide 22
Slide 22 text
“
なぜスクラム開発？
Slide 23
Slide 23 text
なぜスクラム開発？
サービス開発部の行動指針
ユーザーと最速で対話し続ける
Slide 24
Slide 24 text
なぜスクラム開発？
エンジニアに重きを置いたXPやLSDではなく、チームに重きを置いたスクラム開発を
採用することで強固なチームができ、ユーザーと最速で対話しつづけるための
● 高速かつイテレーティブな開発
● より良いサービス作り
が実現可能となるため、スクラム開発を採用しています。
Slide 25
Slide 25 text
なぜスクラム開発？
新規サービスの開発というのはエンジニアのみでは成り立ちません。
● Business（営業や企画）
● Technology（エンジニア）
● Creative（デザイナー、リサーチャー）
のBTCの3職種がチームとなり力を合わせて新規サービスを開発していくことで、より
良いサービスを作ることができます。
Slide 26
Slide 26 text
“
具体的な手法
Slide 27
Slide 27 text
具体的な手法
Odd-e Japan.「アニメ版 スクラム概要図」 . https://www.odd-e.jp/scrum_primer/,（参照2023-04-10）
Slide 28
Slide 28 text
スプリント
4週間以内で定められた繰り返しの期間のことを
スプリントといいます。
スクラム開発のメインとも言える概念です。
期間内に、
● 開発
● スプリントプランニング
● レトロスペクティブ
など様々なイベントを行います。
スプリントの期間: 1〜2週間が多い印象
Slide 29
Slide 29 text
“
各役割に関して
Slide 30
Slide 30 text
各役割に関して
プロダクトオーナー（サービスオーナーとも）
● プロダクトの責任者（1プロジェクトに1人）
● 開発の方向性を定め、プロダクトの価値を最大化することに責任を持つ
● 要件をまとめ、プロダクトバックログを管理する
○ 何を、優先順位は、いつまでにの観点を持つ
● スプリント毎のフィードバックを行う
● 開発チームに”相談”はできるが”指示”はできない
○ オーナーが開発者にタスクを割り振るのではなく、相談や交渉によって定められます
Slide 31
Slide 31 text
スクラムマスター
● スクラムの理論をチーム全員に理解、実践してもらうことに責任を持つ
● スタンドアップミーティング（デイリースクラム）の実施を行う
● スプリント計画ミーティングに参加し、次のスプリントで取り組むものを決定する
● チーム内外の問題解消
● スプリントレビューミーティング
○ スプリントの振り返りを行い修正点や改善点の洗い出しを行う
● プロダクトバックログのサポート
各役割に関して
Slide 32
Slide 32 text
ステークホルダー
● プロダクトの利用者やスポンサーなど、プロダクトに対して利害関係を持つ
スクラムチーム以外の人
● スクラム開発ではプロダクトオーナーに対してのみ要件の変更などを伝えることができる
○ 開発者に直接の指示は出せない
● スプリントレビューに参加してフィードバックをすることもある
各役割に関して
Slide 33
Slide 33 text
開発者
● 開発プロジェクトで実際に開発を行う人たち
● エンジニアのみならず、デザイナー、ライターなど様々な種類の人で構成される
● チーム内での上下関係はなく、フラットな関係が望ましい
● 特定のタスクだけというような事はなく、横断的なスキルが求められる
○ 設計〜コーディング〜テスト〜運用・保守など
各役割に関して
Slide 34
Slide 34 text
“
スクラム開発の流れ
Slide 35
Slide 35 text
スクラム開発の流れ
Odd-e Japan.「アニメ版 スクラム概要図」 . https://www.odd-e.jp/scrum_primer/,（参照2023-04-10）
Slide 36
Slide 36 text
プロダクトバックログ
要件に沿った機能開発や改善要素など
の作業を記述したもの。
関係者全員が参照し、現在のプロダク
トの状況を把握することができます。
優先順位が明確で何から着手するべき
か一目でわかるようになっています。
サービス開発部ではBacklogを使った
り、Zenhubを使ったりすることが多い
です。
Slide 37
Slide 37 text
スプリントプランニング
出席者：PO、SM、DEV
Part 1
スプリントでどのアイテムに着手する
のか検討を行います。
開発チームが選択し、POと認識を合わ
せて本スプリントで行うという合意を
とります。
Part 2
選ばれたアイテムをどのように実装す
るのかという観点から分解し、透明化
を図ります。
≒ 工数などを見積もったりします。
分析・透明化を図ったアイテムを
スプリントバックログ として積み上げ
ていきます。
Slide 38
Slide 38 text
スプリントバックログ
スプリントプランニングで選ばれたア
イテム一覧。
スプリントの対象です。
この一覧をもとにスプリントがはじま
り、開発チームが作業を行います。
スプリントが始まったら新しくアイテ
ムが追加されたり、変更される事はあ
りません。
Slide 39
Slide 39 text
デイリースクラム
毎日決まった時間に行われる15〜30分
程度のミーティング。
チーム全体の状況や問題点の報告、各
人のタスクの進捗状況などに関してを
確認する場。
プロジェクトによって時間は異なりま
すが、午前中に行うことが多いです。
Slide 40
Slide 40 text
プロダクトバックログ
リファインメント
プロダクトバックログのアイテムに対
し、詳細の追加・見積もり・並び替え
を行うこと。
プロダクトオーナーと開発チームが協
力して行います。
実施するタイミングは決まっておら
ず、スプリント内のどこかで相談して
行います。
大体スプリントの5~10%の時間を割く
と推奨されています。
Slide 41
Slide 41 text
スプリントレビュー
チーム全体で行われるスプリント終わ
りに必ず行うレビュー会。
スプリントで作成したリリース可能な
機能のデモを行いFBをもらいます。
スプリントレビューの結果によってプ
ロダクトバックログの修正なども行わ
れます。
Slide 42
Slide 42 text
スプリントレトロスペクティブ
スプリントの最後に行われる振り返り
会。
機能やバックログではなく、チームや
コミュニケーションの改善のために行
われます。
サービス開発部ではKPT法を用いてレ
トロスペクティブを行っているプロ
ジェクトが多いです。
KPT法でないといけないという事はな
く、効率が良ければどんな方法でも問
題ありません。
Slide 43
Slide 43 text
おわりに
5
Slide 44
Slide 44 text
おわりに
サービス開発部が関わっているほとんどのプロジェクトでスクラム開発の手法
を採用しています。
是非、ご自身でもスクラム開発に関して調べてみてください。
また、スクラム開発が絶対一番！ではないです。
組織やプロダクトによって最適な開発手法は異なります。
本研修ではスクラム開発を重点的に説明しましたが、他の手法に関して調べて
みると勉強になるかもしれないです。
Slide 45
Slide 45 text
“
お疲れ様でした！