SCRUM BOOT CAMP THE BOOK の商品レビュー

西村直人,永瀬美穂,吉羽龍太郎【著】

2025/07/20

アジャイル開発ってどんなことをしてプロジェクトを進めていくんだろうと気になり読みました。

マンガもあり読みやすいかと思いましたが、カタカナ語のオンパレードで意識高い系の人には、良いかと思いますが初めて読む人には、あまりお勧めしません。

中身も言葉を置き換えているだけで、それらしく聞こえますが、どこの会社でもやっているスケジュール管理でした。

2025/05/31

魔法生物とは契約はしていないが、「弊社はこれからアジャイル開発を取り入れたシステム開発をしようとしているので君がプロダクトオーナーになってよ!」と言われ、(まじでござるか?)と思いつつ当該発言をしたITの人に借りていた本。申し訳なくも他業務に追われ数ヶ月寝かせていましたが、どうも様子を見るにマジで私がPOになるしかないようなので読みました。良いシステム(プログラム?)であるのはわかるが、回し方(特にPOのあり方)は正直わかったかと言われると自信がない。実際にスクラムが始まったらわかるようになるのだろうか。

2025/02/08

スクラム開発の基本を漫画形式で学べる

メモ

1. プロダクトバックログ: 実現したい要求をリストにして並び揃え、常にメンテナンスして最新に保つ。価値、リスク、必要性が具備。ユーザーストーリー形式で書くことが多い。
2. スプリント: 1〜4週で期間は固定、計画設計開発テストとリリースに必要なすべてのことを行う。
3. スプリント計画ミーティング: スプリントの目標を簡潔にまとめスプリントゴールを決める。タスク一覧(スプリントバックログ)を計画する。タスクは1日以下の単位とする。開発は合意内容を完了させることに全力は尽くすが約束してるわけではない。
4. リリース判断可能なプロダクトとは、完了の定義
* コードレビュー
* チェックイン
* ユニットテスト
* カバレージ
* ドキュメント
* セキュリティ
* 性能
* デプロイ
5. スプリントレビュー: 動作するプロダクトをオーナーがレビューする

見積もり
- バックログの工数はわかりやすいものを基準としておき、感覚で置いていく。フィボナッチ数列の値を使うとやりやすい。
- 実際にスプリントでいくつ分消費できたかがわかるとベロシティがわかる。そこから全体のバックログを消化するのに必要なスプリント数が割り出せる

2024/04/06

めっちゃ作者の親切が伝わる良本
スクラムがどんなものか、どのあたりが難しいのかイメージがしやすい。
どのフレームワークで開発できるかも重要だけどまずこの開発枠組みを知ることが大事だと思う。

2023/10/05

チームで開発するときに「アジャイル」について聞くことがありました。プロジェクトで「アジャイル」という看板を掲げることがありました。その看板が正しいものなのかが答えを持っていませんでした。その不安や回答をもつためにこの書籍を手に取りました。

漫画形式でストーリーが展開しそのアクセス事に説明のページが掲載している形で論は進んでいきます。

プロジェクトで言語化できていないことを提示していて理解が捗りました。

この書籍で全体像を掴みながら他の書籍を読んで理解を深めたいと思いました。

2022/04/03

なぜか購入したまま放置していたのか、どこかから出てきた。
実践的という意味では非常によくまとまっている。もう少し早く読めば良かったか。

2021/12/12

漫画でアジャイル活動の説明がされており、初めてアジャイルに取り組む人が一般的な流れを理解するにはとても良い。

2021/08/02

会社のメンバーにSCRUMの本質的な部分を、自分なりに解釈して伝えたいなという思いで読了。独断ですが、私が感じるポイントは以下の点なのかと。
①目標設定
インセプションデッキという方法論は、簡単にいうとプロジェクトが向かうゴールを設定して、メンバーで共有しようということかと思います。硬い言葉でいうとミッションとかいう話になりますが、要は全員の共通認識となるゴール設定の必要性の手段としてインセプションデッキが定義されているのかと思いました。

②タスク分割と優先順位付け
プロダクトバックログは、ざっくりとした理解では、タスク分割して、どのタスクから優先的に実施するかを見える化したもの。ただし、このタスク分割が実はめちゃめちゃ難しい。この方法論として、ストーリーベースで考えたり、見積もりをカードで実施したりする工夫がなされている。いきなり詳細と正確性を求めるとより難しくなるが、まずはざっくりベースで考えて、徐々に詳細かするプロセスを取ることで、心理的なハードルも下げている。

③時間の意識を持つ
スプリントとかは、本質的には、有限の時間を最も効率的かつ効果的に使うための仕組みではないかと思いました。あとは、期間を短く設定することで、未来を見通しやすくする効果もありますかね。時間の設定は、「ここまでに出来る事を規定する」ことにもなり、理想と現実のギャップが生まれる場面で、実はここが1番難しさがあるのかなと。

④判断基準の明確化
目標未達成＝悪ではなく、現状把握。そのためにも、設定した目標を達成できたのか達成できなかったのかをしる必要があり、明確な判断基準が必要になります。我々は、できなかったと言いにくい心理があるので、なかなか判断基準を明確に設定することができないことが多い印象です。うまくいかなかったらそこから学ぶ。このマインドセットが必要です。

上記①から④は、最低限の規定として、それを実行する上で、チーム内での役割明確化、責任の明確化、マインドセット（全員で協力してやりきろう）、誠実さ（お互いに対するリスペクト）が必要で、その方法論が、まさにSCRUMでしょうか。

2021/03/06

仕事での実践にそのまま活用できる。

業務自身が難しく、また一人、一企業などだけでは解決できないような業際的な課題も多く出てくる中、仕事をしていくための良いフレームワーク。

こういったやり方をすれば、リスクを少しでも減らし、前向きに取り組むことができるようになるはず。わからないことにコミットさせられて進めることほど、ストレスフルな環境はない。

こういったチームを複数抱えている企業、そうでない企業は、たとえ一人のカリスマで引っ張られていても、そうでなくなった際にも非常に強い組織であることが容易に想定できる。

うまく業務に活用していきたい

2020/12/30

5年ぶりに読み返したが、忘れていた大事な要素を再確認できた。
プロジェクトが長く続いていくとscrumの本来の目的から徐々に解離していっている部分があるなと（特にカイゼンのアプローチなど。。）
関係者にも本書は改めておすすめしたい。