アジャイルを知りたければカイゼン・ジャーニーがオススメ

November 17, 2022

概要

今回の記事では、「カイゼン・ジャーニー」を読んで、気になったアジャイル（スクラム）のプラクティスについてまとめました。

また、私がこれまでの経験を踏まえて感じたたことなども記載しています。

気になった（実践で使えそうな）スクラムのプラクティスを記載しているので、キーワードで検索し詳細を調べてみるとより知識が深まると思います。

k69

内容を振り返るための読書メモでもあります

1,2週間で忘れてしまうからね😁

くるみ

前提条件

今までウォーターフォール開発しかしたことない人やこれからアジャイル開発を始める人

目的

今回の記事は、今までウォーターフォール開発しかしたことない人やこれからアジャイル開発を始める人に少しでもアジャイル（特にプラクティス）について知ってもらう。また「カイゼン・ジャーニー」を読むきっかけにつながればうれしいです。

内容

はじめに

本書は実際にありそうなストーリーで主人公の成長を描きながら、アジャイル(スクラム)のプラクティスとその効果について説明されいました。

ストーリー 内容がとてもリアルな内容（私も似たような経験が多かった） であるため、読んでいたとても共感できる。また、テンポよくストーリーが展開されていくため、読み物としても非常におもしろかったです。

使えそうなプラクティスは読書メモとしてまとめたので、アジャイルをはじめる人は是非参考にしていただきたい。

第1部一人から始める

「常にプロジェクトが炎上して、毎日終電まで残業する」といった話からはじまっていた。”どうにかならないのか？”と思いつつ何もできない日々は過去に経験していたので、とても共感しすぐに本書に引き込まれた。

ここでは、「一人でできることから始める」ということで、いくつかのプラクティスが紹介されていた。

プラクティス

ここで紹介されていたプラクティスをメモしておく。

自分がいつもいる場所から外に出てみる。

情報収集のためにいつもいる場所から外に出てみる。

社外セミナー
講習会
勉強会やイベント
他の組織（部門）との交流

k69

外で情報収集はあまりしないので、個人的に改善しなければ行けないポイントだと感じた

タスクマネジメントとタスクボード

ウォーターフォール開発でもGithub/GitLabなどを使って、タスクマネジメントやタスクボードによる課題管理はやってきたので違和感はない。

タスクマネジメントで大きなタスクを大きなまま扱わない （＝1日で終わる作業タスクに細分化）することは大切！

マルチタスクは作業効率を著しく効率を落とすため、タスクボードに Doing が原則一人1つであることも大切！

くるみ

朝会

朝会についても普段から経験していた。スクラムでは下記の3つを伝えるのが基本

昨日やったこと
今日やること
困っていること

k69

スクラムでは朝会でなくても昼会でも夕会でもOKらしい

朝が苦手の人は多いからね。チームで話し合ってきめることが大切な気がする

くるみ

ふりかえり

アジャイルでの振り返りは KPT や YWT を使うことが多い。

KPT

Keep：「よかったこと、つづけること」, Problem：「問題、課題」, Try：「トライ（次に行うこと）」を振り返る。

YWT

Y:「やったこと」W:「わかったこと」T:「つぎやること」を振り返る。

k69

ウォーターフォール開発でふりかえりすることはほとんどなかったなー
チームでの反省や改善ポイントなどの分析をしなかったことは今考えるともったいなかったかもしれない・・・

心理的安全性が低いチーム場合は、メンバーが発言しにくいと、ふりかえりの意味が無くなるので気をつけないと

くるみ

第2部チームで強くなる

ここからスクラムの説明がメインになる。
スクラムの基本とプラクティスのキーワードを列挙する。

k69

大まかな流れやいつプラクティスを使うかなど、
ここを読めばスクラムの基本がわかってきた。

キーワード検索すれば細かいところは調べることができるし
ひとまず概要がわかればOKだね。

くるみ

アジャイルの手法の1つがスクラム（他にはXPなどがある）

スクラムチーム（役割）

プロダクトオーナー（責任者）
開発チーム
スクラムマスター（チームリーダー？）

スクラムの成果物

プロダクトバックログ
スプリントバックログ
インクリメント

インセプションデッキ（プロジェクト方針）

プロダクトオーナーとスクラムチームの共通認識をドキュメント化したの。意見のぶつかり合いなど問題が生じたときに立ち返る場所でもある。

Whyを明らかにする問い
- われわれは何故っここにいるのか？(★)
- エレベーターピッチ
- パッケージデザイン
- やらないことリスト(★)
- 「ご近所さん」を探せ
Howを明らかにする問い
- 技術的な解決策
- 夜も眠れない問題(★)
- 期間を見極める
- トレードオフスライダー(★)
- 何がどれだけ必要か

k69

インセプションデッキはトップダウンではなく、チーム全員の頭で考えることが必須。

(★)は優先順位が高いもの。時間がない場合はこれらだけでもやると効果的

スプリント（繰り返される開発期間 2w～4w）の流れ

スプリントプランニング（作業計画）
デイリースクラム（朝会 15m）※必ず朝やる必要はないらしい
スプリントレビュー（成果物レビュー）
スプリントレトロスペクティブ（ふりかえり）

スプリントのプラクティス

Working Agreement（チーム内ルール）
チーム運営が円滑なるようにチーム（自分たち）のために作成するルール
ドラッカー風エクササイズ
個人ごとに付箋に回答を記入し、*チーム内外で腹を割って話をする**プラクティス
- 自分は何が得意なのか？
- 自分はどうやって貢献するつもりか？
- 自分が大切に思う価値は何か？
- チームメンバーは自分にどんな成果を期待していると思うか？
むきなおり
進むべき先を捉えて現在を正す（ふりかえりは過去を顧みて現在を正す）
合宿
メンバーと共に過ごし、密にコミュニケーションをとり集中的に作業する。

k69

合宿ができるチームはとても良いチーム（全員が意識が高く前向き）だと思う。
全員の理解を得られないまま合宿をしても意味がないと思う
バリューストリームマップ
プロダクトの価値がお客さまの手に渡るまでの仕事の流れを見える化する
星取表（スキルマップ）
誰がどんなスキルを持っているか表にする
モブプログラミング
ペアプログラミングの複数人版。

ポストモーテム

プロジェクト解散時の振り返りと合わせてみんなへの感謝を伝える。

第3部みんなを巻き込む

ここでは外部チームとのやり取りを中心にストーリーが展開されている。
ここでもプラクティスを羅列する。

ユーザーストーリー
対象者にとっての価値をあらわすものであり、方法論(How)については記載しない。ユーザーストーリーは下記の3部構成で表現する。
```
1. ＜ユーザー／顧客＞として ： Who
2. ＜XXXを達成＞をしたい：What
3. なぜなら＜理由＞だからだ：why
```
ユーザーストーリーマッピング
時間の流れに沿ってユーザの行動を洗い出し左から右にその変遷を可視化していくもの。MVPや初期プロダクトバックログの抽出が目的。

スライム作り変え
出典：https://www.slideshare.net/papanda/ss-41638116

まとめ

アジャイル（スクラム）について興味を持っていただけたでしょうか？本書カイゼン・ジャーニーを読んで一番感じたことはアジャイル開発は魔法の開発手法ではない ということです。

すなわち

開発メンバが楽になるわけではない（生産性をあげるノウハウは少ない）
作ることが目的ではなくなり、ユーザーに提供した価値の最大化を目指すために、意見のぶつかり合いが頻出する（価値あるモノを作るためには必要なこと）
プロダクトオーナーがちゃの要素が強く、プロダクトオーナー次第でプロジェクトが成功する可能性が変動する。
といった大変さや運も必要と思いました。

わからないところなどがあれば、マシュマロを投げていただきたいです。
（できるだけ回答します）

本記事を読んでいただきありがとうございまいた。
少しでもみなさまのお役に立てばうれしいです。

概要