Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スクラム研修
Search
techtekt
August 25, 2023
Programming
0
4.6k
スクラム研修
パーソルキャリア株式会社 テクノロジー本部 エンジニアリング統括部 サービス開発部
※本資料は2023年3月時点の情報であり、当該部門における2023年新卒の研修教材です。
techtekt
August 25, 2023
Tweet
Share
More Decks by techtekt
See All by techtekt
大規模サイトリビルドの現場から:成功と失敗のリアルな教訓 / Site Rebuild,Real Lessons Learned from Successes and Failures_JJUG Fall 2024
techtekt
0
240
VSMを活用したFindy Team+の運用促進 / promoting-operation-of-findy-team-plus-using-vsm
techtekt
0
250
ハッピーになる機械学習モデル開発 〜なるべく手間をかけずにコードの品質向上を目指す 〜
techtekt
0
110
Power BI 活用推進の歩み
techtekt
0
74
_microCMS_を使ってNext.jsアプリ開発しよう_.pdf
techtekt
0
1.5k
データベース研修
techtekt
7
6k
良いコードとは 研修
techtekt
2
4.8k
Git研修1
techtekt
0
4.7k
React & Next.js研修
techtekt
0
4.6k
Other Decks in Programming
See All in Programming
KubeCon + CloudNativeCon NA 2024 Overviewat Kubernetes Meetup Tokyo #68 / amsy810_k8sjp68
masayaaoyama
0
260
php-conference-japan-2024
tasuku43
0
320
バグを見つけた?それAppleに直してもらおう!
uetyo
0
180
採用事例の少ないSvelteを選んだ理由と それを正解にするためにやっていること
oekazuma
2
1k
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
940
競技プログラミングへのお誘い@阪大BOOSTセミナー
kotamanegi
0
360
Kaigi on Railsに初参加したら、その日にLT登壇が決定した件について
tama50505
0
100
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
3
480
return文におけるstd::moveについて
onihusube
1
1.1k
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
190
17年周年のWebアプリケーションにTanStack Queryを導入する / Implementing TanStack Query in a 17th Anniversary Web Application
saitolume
0
250
103 Early Hints
sugi_0000
1
230
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Building an army of robots
kneath
302
44k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Facilitating Awesome Meetings
lara
50
6.1k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
2
170
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
A designer walks into a library…
pauljervisheath
204
24k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.5k
Transcript
スクラム研修 パーソルキャリア株式会社 テクノロジー本部 エンジニアリング統括部 サービス開発部 ※本資料は2023年3月時点の情報であり、2023年新卒の研修教材です。
目次 ◉ 研修の目的とゴール ◉ スクラムを知る前に ◉ 主な開発手法について ◉ アジャイル開発手法について ◉
スクラム開発について ◉ まとめ
研修の目的とゴール 0
研修の目的とゴール 皆さんが今後配属されるプロジェクトでは、基本的にスクラム開発の 手法を採用して開発を行っています。(※) 本研修を通して、スクラム開発の手法ならびにそれ以外の開発手法に 関して学び、様々な開発手法を理解した状態を目指しましょう。 ※ プロジェクトによって、導入時期や実施形態に違いがあります
スクラムを知る前に 1
チーム開発の難しさ 個人開発であれば、仕様や設計などは自分が全て理解しているのでひたすら手を動 かせます。 ですが、チーム開発では複数人での開発になるためこんなケースが生じます。 • Aさんにタスクをアサインしたのに実装された内容が要件と異なる • BさんとCさんの目的意識がずれていて議論がまとまらない • AさんのコードをBさんとCさんがレビューしたが、実装ルールが定まっていないた
め、レビューの観点が異なる • どのタスクの優先順位が高いかを把握しておらず、緊急性かつ重要度が高いタスク が後回しになってしまった
チーム開発する上で最も重要なこと コミュニケーションを大事にしましょう! 先程の例は、コミュニケーションをとっていれば大体防げていたはずです。 • タスクが締め切りまでに間に合わなさそうだからリーダーに相談する • 今日は◦◦のタスクを着手します。と報告する。 • 仕様に不明点があった場合は誰かに聞いて不明部分を解消する •
自分の認識が合っているか不安だったら先輩に認識合わせをお願いする コミュニケーションで解決できることはたくさんあります。報連相を怠ってしまう と様々な問題が発生するリスクが高くなるため、必要に応じてコミュニケーション を取るように心がけてください。
主な開発手法について 2
主な開発手法 ◉ ウォーターフォール型開発 ◉ プロトタイプ型開発 ◉ アジャイル型開発
ウォーターフォール型開発 一つ一つの工程を順番に進めていくことを ウォーターフォール型開発と言います。 V字モデルを用いて説明されることが多 く、昔からある開発手法の一つです。 開発の前に厳密な仕様設計を行い、段階ご とに工程を進めていくので後戻りができな いことが特徴です。 ITトレンド.「ウォーターフォールモデルとは?メリット、アジャイルとの違いを解説」. https://it-trend.jp/process_management/article/464-0012,(参照2023-04-10)
デメリット • 柔軟性に欠ける • ドキュメントが多い • ドキュメントの整備の時間が多い • ユーザーの意見を取り入れにくい メリット
• 大規模な開発に向いている • PJ全体の計画が立てやすい • 進捗管理がしやすい ウォーターフォール型開発
プロトタイプ型開発 開発に入る前・開発の早い段階で試作品を作成し、依頼者・発注者が レビューをして認識齟齬がないかを確認します。 その上でシステムの仕様を決めていくという開発手法になります。 メリット • 早い段階で完成品のイメージ共有ができる • 認識のズレが回避できる •
不具合やバグの早期発見ができる • 品質が高いプロダクトにつながる デメリット • プロトタイプの開発のための工数が 増える • 大規模な開発には向かない
アジャイル型開発 アジャイル型開発は小さなサイクル(スプリント or イテレーション)で計画・開発・テ ストを繰り返して開発を進めていく手法になります。 ウォーターフォール型開発とは違い、最初に厳密な仕様設計を行わずおおよその仕様や 要求を取りまとめて開発を進めていきます。 つまり、「あらかじめ厳密な仕様設計を行ったうえで全行程の計画を立て、実行してい く」のではなく「開発の方向性・方針は定めた上で開発中に発生するあらゆる状況に対 応できるよう柔軟に開発を進め、仕様変更に強くリスクを最小化していく」手法になり
ます。
デメリット • PJ全体のスケジュールが読みづらく なる • しっかりコントロールしないと開発 の方向性を見失いがち メリット • ユーザーとコミュニケーションを取
りながら開発が可能なので、 ユーザーの要求に最大限応えられる • 仕様変更や追加に柔軟に対応可能(※) • 開発者のモチベーションが高まる ※あくまで仕様変更など柔軟に対応できるとい う事で、ゴールそのものを変えるという事では ありません アジャイル型開発
アジャイル型開発 アジャイルソフトウェア開発宣言 (2001年に当時ソフトウェア開発手法分野で活躍していた 17名の専門家によってまとめられた文書 ) ◉ 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 ◉ 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。
◉ 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 ◉ ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 ◉ 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 ◉ 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
アジャイル型開発 アジャイルソフトウェア開発宣言 .「アジャイルソフトウェア開発宣言」 . https://agilemanifesto.org/iso/ja/manifesto.html,(参照2023-04-10) ◉ 動くソフトウェアこそが進捗の最も重要な尺度です。 ◉ アジャイル・プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。
◉ 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 ◉ シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 ◉ 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 ◉ チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり 方を最適に調整します。
まとめ 開発手法を 3つ挙げましたが、今後皆さんが携わるほとんどのプロ ジェクトでは、アジャイル開発であるスクラム開発を採用していま す。 次の章ではスクラム開発を含めた 3つのアジャイル開発の手法を 説明します。
アジャイル開発手法について 3
“ アジャイル型開発では多くの手法がありますが、 ここでは 3種類の手法を簡単に紹介します。
アジャイル型開発手法 スクラム 昨今で一番流行っている手 法かと思われます。 プロジェクトの管理に重き を置いた開発手法。 チームワークを重視する特 徴があります。 詳しい説明は後述。 エクストリーミング・
プログラミング(XP) プログラマーに重きを置いた 開発手法。 ペアプログラミングやテスト 駆動開発(TDD)、リファク タリングなどを必ず用いる手 法になります。 リーンソフトウェア開発 (LSD) トヨタ生産方式をソフトウェア開 発に適用したものになります。 とにかくムダを省くということに 焦点を絞っています。 前者の2つと違い、固有のプロセ スやプラクティスはありません。
スクラム開発について 4
“ なぜスクラム開発?
なぜスクラム開発? サービス開発部の行動指針 ユーザーと最速で対話し続ける
なぜスクラム開発? エンジニアに重きを置いたXPやLSDではなく、チームに重きを置いたスクラム開発を 採用することで強固なチームができ、ユーザーと最速で対話しつづけるための • 高速かつイテレーティブな開発 • より良いサービス作り が実現可能となるため、スクラム開発を採用しています。
なぜスクラム開発? 新規サービスの開発というのはエンジニアのみでは成り立ちません。 • Business(営業や企画) • Technology(エンジニア) • Creative(デザイナー、リサーチャー) のBTCの3職種がチームとなり力を合わせて新規サービスを開発していくことで、より 良いサービスを作ることができます。
“ 具体的な手法
具体的な手法 Odd-e Japan.「アニメ版 スクラム概要図」 . https://www.odd-e.jp/scrum_primer/,(参照2023-04-10)
スプリント 4週間以内で定められた繰り返しの期間のことを スプリントといいます。 スクラム開発のメインとも言える概念です。 期間内に、 • 開発 • スプリントプランニング •
レトロスペクティブ など様々なイベントを行います。 スプリントの期間: 1〜2週間が多い印象
“ 各役割に関して
各役割に関して プロダクトオーナー(サービスオーナーとも) • プロダクトの責任者(1プロジェクトに1人) • 開発の方向性を定め、プロダクトの価値を最大化することに責任を持つ • 要件をまとめ、プロダクトバックログを管理する ◦ 何を、優先順位は、いつまでにの観点を持つ
• スプリント毎のフィードバックを行う • 開発チームに”相談”はできるが”指示”はできない ◦ オーナーが開発者にタスクを割り振るのではなく、相談や交渉によって定められます
スクラムマスター • スクラムの理論をチーム全員に理解、実践してもらうことに責任を持つ • スタンドアップミーティング(デイリースクラム)の実施を行う • スプリント計画ミーティングに参加し、次のスプリントで取り組むものを決定する • チーム内外の問題解消 •
スプリントレビューミーティング ◦ スプリントの振り返りを行い修正点や改善点の洗い出しを行う • プロダクトバックログのサポート 各役割に関して
ステークホルダー • プロダクトの利用者やスポンサーなど、プロダクトに対して利害関係を持つ スクラムチーム以外の人 • スクラム開発ではプロダクトオーナーに対してのみ要件の変更などを伝えることができる ◦ 開発者に直接の指示は出せない • スプリントレビューに参加してフィードバックをすることもある
各役割に関して
開発者 • 開発プロジェクトで実際に開発を行う人たち • エンジニアのみならず、デザイナー、ライターなど様々な種類の人で構成される • チーム内での上下関係はなく、フラットな関係が望ましい • 特定のタスクだけというような事はなく、横断的なスキルが求められる ◦
設計〜コーディング〜テスト〜運用・保守など 各役割に関して
“ スクラム開発の流れ
スクラム開発の流れ Odd-e Japan.「アニメ版 スクラム概要図」 . https://www.odd-e.jp/scrum_primer/,(参照2023-04-10)
プロダクトバックログ 要件に沿った機能開発や改善要素など の作業を記述したもの。 関係者全員が参照し、現在のプロダク トの状況を把握することができます。 優先順位が明確で何から着手するべき か一目でわかるようになっています。 サービス開発部ではBacklogを使った り、Zenhubを使ったりすることが多い です。
スプリントプランニング 出席者:PO、SM、DEV Part 1 スプリントでどのアイテムに着手する のか検討を行います。 開発チームが選択し、POと認識を合わ せて本スプリントで行うという合意を とります。 Part
2 選ばれたアイテムをどのように実装す るのかという観点から分解し、透明化 を図ります。 ≒ 工数などを見積もったりします。 分析・透明化を図ったアイテムを スプリントバックログ として積み上げ ていきます。
スプリントバックログ スプリントプランニングで選ばれたア イテム一覧。 スプリントの対象です。 この一覧をもとにスプリントがはじま り、開発チームが作業を行います。 スプリントが始まったら新しくアイテ ムが追加されたり、変更される事はあ りません。
デイリースクラム 毎日決まった時間に行われる15〜30分 程度のミーティング。 チーム全体の状況や問題点の報告、各 人のタスクの進捗状況などに関してを 確認する場。 プロジェクトによって時間は異なりま すが、午前中に行うことが多いです。
プロダクトバックログ リファインメント プロダクトバックログのアイテムに対 し、詳細の追加・見積もり・並び替え を行うこと。 プロダクトオーナーと開発チームが協 力して行います。 実施するタイミングは決まっておら ず、スプリント内のどこかで相談して 行います。
大体スプリントの5~10%の時間を割く と推奨されています。
スプリントレビュー チーム全体で行われるスプリント終わ りに必ず行うレビュー会。 スプリントで作成したリリース可能な 機能のデモを行いFBをもらいます。 スプリントレビューの結果によってプ ロダクトバックログの修正なども行わ れます。
スプリントレトロスペクティブ スプリントの最後に行われる振り返り 会。 機能やバックログではなく、チームや コミュニケーションの改善のために行 われます。 サービス開発部ではKPT法を用いてレ トロスペクティブを行っているプロ ジェクトが多いです。 KPT法でないといけないという事はな
く、効率が良ければどんな方法でも問 題ありません。
おわりに 5
おわりに サービス開発部が関わっているほとんどのプロジェクトでスクラム開発の手法 を採用しています。 是非、ご自身でもスクラム開発に関して調べてみてください。 また、スクラム開発が絶対一番!ではないです。 組織やプロダクトによって最適な開発手法は異なります。 本研修ではスクラム開発を重点的に説明しましたが、他の手法に関して調べて みると勉強になるかもしれないです。
“ お疲れ様でした!