• twitter
  • このエントリーをはてなブックマークに追加

現場で見つけた144のヒント アジャイルに困った時に読む本

  • 紙版
  • 電子版

現場で見つけた144のヒント アジャイルに困った時に読む本

書籍情報

  • 紙版
  • 電子版
  • 渡会 健 著
  • 定価:1980円(本体1800円+税10%)
  • 発行年月:2023年08月
  • 判型/造本:A5並
  • 頁数:244
  • ISBN:9784478116708

内容紹介

ソフトウェア開発から始まった「アジャイル」は、いまやプロダクト開発にとどまらず、ビジネス全般のアプローチとして定着しつつある。「理屈」や「理想」だけではない、多くの開発現場で実践してきたからこそ見えてきた「現実」に役立つアジャイルのヒントを紹介する。

目次・著者紹介詳細を見る▼

目次

▶はじめに

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

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

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

CHAPTER1 アジャイルのこと、誤解していませんか?

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

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

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

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

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

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

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

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

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

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

CHAPTER4 アジャイルの進め方

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

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

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

4-4 デイリーミーティングで変化を察知する
ヒント 088 「進捗が予定よりも遅れている」という言葉が関係者から出てきたら危険信号
ヒント 089 タスクはPush型ではなくPull型で引き受ける
ヒント 090 「異常なし」が続くことの「異常」を見逃すな。背景に潜む心理的安全性の低下
ヒント 091 デイリーミーティングにおける3つの質問の功罪
ヒント 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の負債に気をつけよう。1つで良いので確実に次のイテレーションで実行して初めて完結する
ヒント 118 最初は個人レベルでOK。ふりかえりに慣れながらチーム全体レベルへ
ヒント 119 KPTによる心理的安全性(Keep<<<Problemとなったら危険信号)
ヒント 120 日本ではなぜ、ふりかえりはKPTが流行っているのか(他に方法はないのか)
ヒント ​121 やめてしまったふりかえりを復活させた例

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

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

5-1複数チームで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案件以上のアジャイルプロジェクト実践経験を持つ。

プリント版書籍は下記のストアでご購入いただけます。
  • Amazon で購入
  • e-hon で購入
  • HMV&BOOKS online で購入
  • 紀伊国屋BookWeb で購入
  • セブンネットショッピング で購入
  • TSUTAYAオンラインショッピング で購入
  • BOOKFAN で購入
  • Honya Club で購入
  • ヨドバシカメラ で購入
  • 楽天ブックス で購入

(ストアによって販売開始のタイミングが異なるためお取り扱いがない場合がございます。)

電子書籍は下記のサイトでご購入いただけます。

(デジタル版では、プリント版と内容が一部異なる場合があります。また、著作権等の問題で一部ページが掲載されない場合があることを、あらかじめご了承ください。)

  • twitter
  • このエントリーをはてなブックマークに追加