目次

▶はじめに

▶10分で読むアジャイルの概要

▶アジャイルの背景にある考え方～アジャイルマニフェスト

　Column　スクラムだけがアジャイルではない

CHAPTER１　アジャイルのこと、誤解していませんか？

ヒント 001　その「アジャイル」本当に必要ですか？
ヒント 002　アジャイルであることが最大の目的になった瞬間、そのアジャイルは失敗する
ヒント 003　欧米で「アジャイルが主流」は事実ではありません
ヒント 004　欧米発祥のアジャイルは日本人に合っていないというまことしやかな嘘
ヒント 005　ここまで進んだアジャイル適用事例、食わず嫌いは損をする
ヒント 006　アジャイルは万能ではない（「今のやり方以外を採用すれば成功する」は幻想）
ヒント 007　臨機応変＝アジャイルじゃない
ヒント 008　アジャイルを始めるときに必要なのは標準ではなくガイドライン
ヒント 009　変更を受け入れる＝仕事が積まれ放題となってしまわないために合意すべきこととは
ヒント 010　アジャイルの導入をウォーターフォール的に行う悲劇
ヒント 011　安易に混ぜるな。ウォーターフォールとアジャイルのハイブリッドが難しい理由
ヒント 012　一度決めてしまったことは「簡単に変えられない」という呪縛から解き放たれよう
ヒント 013　たいていの場合、最初のイテレーションから予定通りの成果が出ないという事実を受け入れないと、最初でつまずく
ヒント 014　アジャイルで「失敗を許容する」が可能なのはそのための「からくり」があるからです
ヒント 015　丸投げ体質の発注者ではアジャイルは確実に失敗する
ヒント 016　やらせてもらえないアジャイルとやらされアジャイル
ヒント 017　意外と知らないアジャイルマニフェスト。知らないと何が起こるのか
ヒント 018　アジャイルならば開発経験者不在でも成功できると思い込む不思議
ヒント 019　アジャイルに不慣れなうちは、慣れている人に頼るのが一番の近道
ヒント 020　不確実性が低い案件にアジャイルを適用してしまったことによる失敗

CHAPTER２　チームコミュニケーションと役割分担

2-1　チームコミュニケーションを円滑にする
ヒント 021　コミュニケーションは正論のぶつかり合いよりも言葉のキャッチボールで
ヒント 022　チーム内のコミュニケーションが停滞しているときには、「イイと思うよ～」という同意から始めよう
ヒント 023　雑談タイムを意識的に作る
ヒント 024　「意識すれば見られる場所にある」と「無意識でも目に入る」に見る情報共有の大きな隔たり
ヒント 025　目に見えない「情報」を物理的な「モノ」に置き換える本当の意味
ヒント 026　ファシリテーターをスクラムマスターに固定化してはいけない
ヒント 027　細かいチームルール（ワーキングアグリーメント）を作って守ることから始めよう
ヒント 028　協力会社も混合で
ヒント 029　情報を顧客にもフルオープンして、隠しごとはゼロに
ヒント 030　チケット管理システムは何でもよいので導入しよう
ヒント 031　開発チーム内にサブチームを作らない本当の理由
ヒント 032　持続可能な開発を促進する＝残業しない、という意味ではない
ヒント 033　会議のリズム、守れてますか？
ヒント 034　リモートワークで「一緒に働く」を実現する工夫

2-2　アジャイルチームにおけるそれぞれの役割
▶2-2-1 プロダクトオーナー
ヒント 035　プロダクトオーナーは本当に１人でないといけないのか。チーム制も選択肢の１つ
ヒント 036　プロダクトオーナーは「お客さま」ではなく、協働する仲間
ヒント 037　お勧めしたいプロキシ（代理）プロダクトオーナー。成功の秘訣は自分の意思ではなく、プロダクトオーナー本人の意思決定思考になりきること

▶2-2-2 開発チーム
ヒント 038　アジャイルの開発チームはやることがいっぱい
ヒント 039　開発チームは初めから多能工である必要はない。チームの成熟とともに多能工となっていくもの
ヒント 040　開発チームの人数制限の罠

▶2-2-3 スクラムマスター
ヒント 041　アジャイルチームの主役は「スクラムマスター」ではない
ヒント 042　スクラムマスターの真の役割は、自分がいなくても成長し続けるチームを築くこと
ヒント 043　スクラムマスターとプロダクトオーナーの兼任はなぜ良くないのか
ヒント 044　スクラムマスターはプロダクトオーナー側と開発チーム側どちらの会社が出す方が良いか

▶2-2-4 従来型開発のプロジェクトマネージャーの役割は誰が果たすのか
ヒント 045　そのままの役割でアジャイルチーム内に入り込んではNG
ヒント 046　なぜプロジェクトマネージャーの役割をアジャイル型アプローチでは分割するのか

CHAPTER３　アジャイルチームの作成物

3-1　プロジェクトの背骨を作るユーザーストーリーリスト（プロダクトバックログ）
ヒント 047　要件定義書とユーザーストーリーリストの決定的な違いとは
ヒント 048　優先度ではなく優先順位
ヒント 049　ユーザーストーリーの粒度の極意
ヒント 050　ユーザーストーリーに書かなくてはいけないこと、書いてはいけないこと
ヒント 051　ユーザーストーリーとINVESTの罠
ヒント 052　MECE（抜け漏れなくダブりなく）の呪縛から抜け出そう
ヒント 053　ユーザーストーリーの分割の方法
ヒント 054　イテレーションごとの動く成果物は縦割りではなく横割りで考える
ヒント 055　イテレーション内に予定通りにユーザーストーリーが終わらなかった場合はどうするべきか

3-2　ToDoリスト（スプリントバックログ）はイテレーションごとに作って、捨てる
ヒント 056　ToDoリストとWBSの違い
ヒント 057　ToDoリストの作成にプロダクトオーナーを参加させる具体的なアイデア
ヒント 058　ToDoリストに載せるタスクの作り方
ヒント 059　進捗管理と適切なタスクの粒度
ヒント 060　突発タスクの取り扱い方

3-3　動く成果物（インクリメント）と品質
ヒント 061　「動く成果物」は常に最新で１つ
ヒント 062　プロダクト品質を担保する
ヒント 063　アジャイルにおける「共通化」のコツとは
ヒント 064　不具合（バグ）が出たらその内容にかかわらず「聖域」として修正を最優先するのは本当に価値につながるのか
ヒント 065　アジャイルの品質の守り方とウォーターフォールの品質の守り方
ヒント 066　テスト駆動開発という理想と自分たちのチームの実力のギャップをどう埋めるのか

3-4　計画の根拠を作る見積
ヒント 067　アジャイル型アプローチにおける見積の役割
ヒント 068　見積は誰が行うかが一番重要
ヒント 069　なぜ見積は開発チーム全員で行う必要があるのか
ヒント 070　見積の基準は「過去の自分たち」
ヒント 071　アジャイルでプランニングポーカーが重用される本当の意味

CHAPTER４　アジャイルの進め方

4-1　コミュニケーションとタイムマネジメントでチームを動かす
ヒント 072　生産性の高いチームほどコミュニケーションコストを惜しまないようになるのはなぜか
ヒント 073　自分たちのチームに最適なイテレーション期間とは（短い場合と長い場合のメリット・デメリットから考える）
ヒント 074　「アジャイルだから間に合わなくても良い」ではない。間に合わなかったことを反省し改善できないのであれば、単なる先延ばし
ヒント 075　イテレーション計画とカレンダーとの適切な関係

4-2　イテレーションを始める前にやること
ヒント 076　「イテレーション０」をやらないアジャイルは出だしでつまずく
ヒント 077　インセプションデッキは成果物ではなくメンバーの意識共有のためのツール
ヒント 078　インセプションデッキとプロジェクト計画書は≒だけど≠。全部作れば良いというものではない
ヒント 079　インセプションデッキは作りっぱなしで放置してはいけない

4-3　アジャイルでも計画は大事。イテレーション計画と全体計画
ヒント 080　イテレーション計画会議のプランニング
ヒント 081　イテレーション計画はモブ設計の場と等しい
ヒント 082　アジャイルでは設計を行うタイミングとやり方が従来型とは決定的に違うことを理解しよう
ヒント 083　イテレーション計画会議は２部制廃止で
ヒント 084　他チームとベロシティの値を比べるのはなぜ無意味なのか
ヒント 085　開発効率＜価値実現効率。作り手の都合は後回し
ヒント 086　イテレーション計画だけがアジャイルにおける計画ではない。もう１つの計画の重要性
ヒント 087　このまま「変化が起きなければ」、いつ頃どこまでたどり着けるかを示し続けることの重要性

4-4　デイリーミーティングで変化を察知する
ヒント 088　「進捗が予定よりも遅れている」という言葉が関係者から出てきたら危険信号
ヒント 089　タスクはPush型ではなくPull型で引き受ける
ヒント 090　「異常なし」が続くことの「異常」を見逃すな。背景に潜む心理的安全性の低下
ヒント 091　デイリーミーティングにおける３つの質問の功罪
ヒント 092　デイリーミーティングで変化を見逃さないために必要なこととは
ヒント 093　イテレーション実施中にタスクが増えてしまうのは本当にいけないことなのか？

4-5　タスクボードの使いこなし
ヒント 094　タスクボードは優先順位に着目すべし
ヒント 095　タスクボードがいつも同じ形で終わっている場合は疑え
ヒント 096　タスクボード上に担当者を明記するのは実施中のステータスのみに限るべき
ヒント 097　実施中のタスク状況を見ればメンバーの負荷の偏りが見えてくるバーンダウンチャートの具体的な工夫
ヒント 098　バーンダウンチャートから読み取れる異変の例
ヒント 099　バーンダウンチャートでは何を見ているのか（進捗だけを見るものではない）
ヒント 100　バーンダウンチャートの功罪とバーンアップチャートの活用
ヒント 101　バーンダウンチャートの縦軸はタスク数かポイント数か
ヒント 102　ニコニコカレンダーから読み取れること

4-7　着実に動く成果物に近づくための、タスク実施の工夫
ヒント 103　10分ルール（わからないことはわかっている人にすぐに聞く文化を作る）
ヒント 104　アジャイル開発でリファクタリングを行わないとどうなるのか
ヒント 105　開発チームのパフォーマンス向上はプロダクトオーナーの即断即決にかかっている（たとえ間違っていても、次のイテレーションで軌道修正できる）
ヒント 106　ペアワークやモブワークは本当に効果的なのか。義務化して選択肢を奪うのは危険
ヒント 107　ツールやプラクティスやイベントを導入するだけではアジャイルにはならない
ヒント 108　構成管理はアジャイルの基本

4-8　「動く成果物」をより良くする成果物フィードバックとは
ヒント 109　成果物フィードバックは進捗会議ではない（テスト済みの完成したもののみを提示する）
ヒント 110　成果物フィードバックがプロダクトオーナーやステークホルダーによる審査会になり下がってしまったときの脱出法
ヒント 111　成果物フィードバックは公開試験の場ではない。真の目的はフィードバックを得ること
ヒント 112　成果物フィードバックで犯人探しをしてしまうと皆沈黙するようになる。むしろ感謝を伝えよう
ヒント 113　成果物フィードバックのファシリテーションをプロダクトオーナーがやることの意味
ヒント 114　成果物フィードバックは全員で

4-9　ふりかえりの工夫でチームはより成長する
ヒント 115　ふりかえりをやめてしまうとチームの成長も止まる
ヒント 116　小さな声にこそチームに役立つ意見が隠れている場合が多い
ヒント 117　ふりかえりはTryの負債に気をつけよう。１つで良いので確実に次のイテレーションで実行して初めて完結する
ヒント 118　最初は個人レベルでOK。ふりかえりに慣れながらチーム全体レベルへ
ヒント 119　KPTによる心理的安全性（Keep＜＜＜Problemとなったら危険信号）
ヒント 120　日本ではなぜ、ふりかえりはKPTが流行っているのか（他に方法はないのか）
ヒント ​121　やめてしまったふりかえりを復活させた例

4-10　プロダクトの価値をさらに高めるリファインメント
ヒント 122　リファインメントにこそ開発チームの参加が必須
ヒント 123　リファインメントの役割はチームの成熟度によって変わる
ヒント 124　スパイクの上手な使い方
ヒント 125　リファインメントの結果はチーム内だけでなく、都度ステークホルダーにも共有しないと失敗する

CHAPTER５　Advance編 アジャイルを今よりもっと良くするために

5-1複数チームで１つのプロダクトを作る
ヒント 126　やってはいけないチーム分けの具体例
ヒント 127　成果物フィードバックとふりかえりは合同で
ヒント 128　専門家も開発チームと一緒にイベント参加
ヒント 129　小さなプロダクトは「まとめてワンチーム」で

5-2　開発と保守運用を同じチームで行う（DevOps）
ヒント 130　プロダクトマネジメントを実現するためのDevOps
ヒント 131　開発と保守運用のバランスの取り方
ヒント 132　従来型保守運用チームにアジャイルを導入して働き方改革を実現

5-3アジャイルと契約
ヒント 133　なぜアジャイルの契約は「準委任が基本」と言われているのか
ヒント 134　アジャイルにおける契約の工夫。日本でも個別契約が優先されることを活用しよう
ヒント 135　受発注の関係が対等であれば、アジャイルは偽装請負にはならない（厚労省が見解を発表）

5-4　アジャイルの理想と現実解
ヒント 136　リリースイテレーションの功罪
ヒント 137　ベロシティは安定を目指すのか増加を目指すのか
ヒント 138　アジャイルとKPI。スクラムマスターの腕の見せ所
ヒント 139　何に焦点を当てて効率良く進めるのか（リソース効率とフロー効率）
ヒント 140　守破離の誤用。型破りではなく形なしになってしまわないためにはどうすれば良いか

5-5　外部の専門家の力を借りる
ヒント 141　アジャイルコーチは何をしてくれるのか
ヒント 142　ACoEの導入と活用
ヒント 143　アジャイルスタートアップガイドラインという考え方
ヒント 144　アジャイル研修の上手な活用術

▶さいごにアジャイルは実は大変。なのになぜ続けているのか

著者

渡会 健（わたらい たけし）
株式会社マネジメントソリューションズ Digital事業部 アソシエイト・ディレクター
PMI日本支部 アジャイル研究会 元代表
IPA アジャイルWG メンバー
三菱スペース・ソフトウエア株式会社と株式会社アイ・ティ・イノベーションにて、ウォーターフォール＆PMに約20年従事。2008年にアジャイルに出会い、中堅SIerである株式会社アドヴァンスト・ソフト・エンジニアリングにて約10年間アジャイルを実践。その後アジャイルコーチに転身し、株式会社豆蔵を経て現職に至る。アジャイル歴約15年で50案件以上のアジャイルプロジェクト実践経験を持つ。