あらすじ
DX時代を迎え、成長しつづけるIT市場のスピードに合わせてビジネスも変革を迫られる昨今、「アジャイル開発」が注目されています。アジャイル開発は、短期間でリリースして改善するサイクルを繰り返すことでニーズを的確にとらえ、すばやくプロダクトを送り出すための開発手法です。
本書は、ソフトウェア開発の現場でアジャイル開発を実践してきた著者陣が、その知見を丁寧にまとめたものです。どう実践してよいかわからないという人でも読んだその日から自分の現場で取り組めるように、具体的なやり方が豊富な図とともに解説されているのが特徴です。
●本書はこんな人におすすめです。
アジャイル開発を実践したいエンジニア
DXを推進したい経営者
アジャイル開発を業務に活かしたい企画担当者など非エンジニア
過去にアジャイル開発に取り組んだが挫折した人
具体的なプラクティスや実践ノウハウを知りたい人
感情タグBEST3
Posted by ブクログ
アジャイルの案件に入ることになったので。 SCRUM BOOT CAMP THE BOOKと比べると一歩引いた視点から俯瞰してる感じ。 アジャイルとはなにか、なぜアジャイル7日、何が実現できるのかなどを、ウォーターフォールと比較しながら説明されている。 ウォーターフォール経験者なら「わかるぅ?」となること請け合い。
Posted by ブクログ
コンパクトに要点が纏まっていて何回でも読み返し出来そうな内容でした。実際に体感して読み返すとより理解が深まりそうです。まだやってみてないのでサーっと読んでしまいました。
Posted by ブクログ
いちばんやさしいの名の通り、アジャイル開発とは何であって何ではないのかが網羅的にまとまっている。
理念、思想から実際のプラクティスの紹介、よくある誤解に対する解説を通して改めてアジャイル開発とはなにかを解説するといった流れで、関連書籍を読むにあたって最初に読む本として適していそう。
この本だけで具体的な実践に進むのは少し難しそうと感じたものの、これから踏み出す方向性を定める上で間違いなく道標になってくれると思う。
Posted by ブクログ
アジャイルの考え方そのものから、具体的にどうやっていくかを、細かく学べる本です。
システム開発をメインに記載されていますが、あらゆるプロジェクトで適用できる考え方が多く記載されているので、多くの方が読んでおくべき本だと思いました
Posted by ブクログ
後書きにもあったけど、アジャイルの普及と誤解の払拭に苦心の末発行されたご様子。
故に「手法」も勿論ありつつ「考え方」の伝達が中心で、確かに本ってそれ一冊で全てが理解出来て明日から全部出来るってないよな、と別の部分の思案に至ったり。
読んで終わりではなく、立ち止まった時に振り返る際にめくり直す一冊として、買ってよかったと思わされた。
Posted by ブクログ
社内でアジャイル，アジャイル言われるものの何なのそれ状態だったのでとっかかりとしてたまたま書店で見つけて購入．
※基本的には，私はウォーターフォールしか経験してないと思っています
気になった（気にとまった）ことをいくつか：
1. 顧客が必要なものにフォーカスし，素早くプロダクトを開発する手法
2. マックだって，ヘルシーな「サラダマック」の売れ行きは乏しかった（顧客インサイト）
3. 短い期間でリリースし，フィードバックを受け，改善するというサイクル（アジャイル開発の基本）
4. 要件定義はあくまでも仮説．本当に必要なものから乖離したソフトウェアを作り込んでしまうリスクがある．
5. 前工程の遅れが後工程を圧縮する（☜まさにこれなんだよなぁ）
6. 要求の変更はたとえ開発の後期であっても歓迎しますという原則（アジャイル開発の原則）
7. 小さく試して軌道修正
（8. YouTubeは元はデート相手を探すマッチングサービス）
9. 目的や目標，前提や制約，優先基準決定にはインセプションデッキ（WhyとHowを明らかに）
10. 一定の間隔で区切って開発する（スプリント，1～2週間）
11. タスクの見える化と優先順位の決定（スプリントバックログ）
12. 作るべきものの一覧で作るもの・作る順番を明確化（プロダクトバックログ）
13. TODO：やること，DOING：やっていること，DONE：やったことの状況の見える化（タスクボード）
14. タスクサイズはフィボナッチ数列を使うと見積誤差とタスク感サイズ比較がやりやすい
15. 昨日やったこと，今日やること，困っていることを把握して軌道修正（朝会，日常の見える化）
16. KPT：振り返りも1～2週間で実施
17. 繰り返し作業が3回以上あれば，断続的インテグレーション導入
Posted by ブクログ
過去読んでアジャイル開発に関して基本を学べた本。
いちばんやさしいとある通り、初心者向けで読みやすかった記憶がある。
他にも本を出版されている小田中さんが書いている。
Posted by ブクログ
伸びしろの若手エンジニアをアジャイル開発に参画させると、旧来のウォータフォール開発に比較して、何倍も大きく成長するように思えます。
「巨人の肩に乗る」とは、若手の方が、プロジェクトのエキスパートにささえられながら、全体を見渡して成長していくという意味なのでしょうか。
大規模な基幹システムの更改については、アジャイル開発はどうも向いていないように思えますが、スクラムマスターが何人もいるような、しかも請負で開発しているプロジェクトが出現し
急速に成長している分野と認識しています。本書は、アジャイル開発の基礎を解説したものですが、用語を含めてとっつきにくい内容だと思います。ブレークダウンをして具体的な作業や、ツールなどを解説していただいたら、もっと充実した内容になるとおもいました。
気になった点は以下の通りです。
・リリース時点で開発から手離れすることはまれになりました。ユーザーの反応をプロダクトに反映しながら改善し、ビジネス価値を向上させ続ける必要がでてきたのです。
・ソフトウエアの利用を通じて達成したいことを「要求」といいます。この「要求」を実現するために必要な機能や性能が定義されたものが「要件」です。
・ソフトウエアの３分の２の機能はつかわれていません。
・ウォーターフォールは、よくも悪くも、不確実性を減らすモデルです。
・想定だけで一度に多くのことを実現しようとしても、的を得たものにならない。だから、少しづつ繰り返し的に作り進めていく。
・統合：インテグレーションとは、ソフトウエアを動作させるために必要なプログラムや、設定ファイル、データ、ライブラリを全て集めて、まとめる作業のことをいいます
・常にリリース可能な状態に整備シテオクプラクティスがあります。それが「継続的インテグレーション」です。テストやビルド、配置のタスクを流れるように自動化しておく仕組みです。
・ソフトウエア開発に価値探求のためのタスク「仮説検証」を織り込む考えがあります。
・アジャイル開発は２つの見積で構成されます。１つは、全体感の見積、もう１つは、実際に開発するにあたってたいむボックスごとに行う見積もりです。
・アジャイル開発における計画づくりとは、大きな計画づくり、小さな計画づくり、その日に計画づくりの３種をさします。それぞれ、リリースプラニング、スプリントプラニング、デイリースクラムといいます。
・アジャイル開発では一度に広範の要件定義ではなく、その時点で必要な範囲と深さでの「作るべきものはなにか」を定義します。その時点は２種類あります。リリースプラニングの段階で全体を知るための整理。スプリント段階で、スプリント分を知るための整理の２種類です。
・段階ごとの青写真を描いて、見えるようにしておくことは思いのほか重要です。
・これまでアジャイル開発が失敗してきた理由は３つあります。①受託開発や、ＳＩでの同意形成が難しい ②他の現場プラクティスをそのまま適用してしまっている ③経験者不足、経験者の偏り。です。
結論は、「アジャイル開発」はいつだれが始めるのか。その答えはもう出ています。アジャイル開発の積み重ねに次の越境を重ねるのは、この本を閉じたときから、あなたが始めるのです。
目次は以下の通りです。
Chapter１ アジャイル開発の世界
０１ 本書の読み方：アジャイル開発を始める
０２ ソフトウエアを取り巻く環境①：進化するＩＴ市場
０３ ソフトウエアを取り巻く環境②：ビジネスモデルの変化
０４ さまざまなソフトウエアの形：見えるソフトウエア、見えないソフトウエア
０５ ＳｏＲ，ＳｏＥ，ＳｏＩ：ユーザーとソフトウエアの関わり
０６ アジャイル開発の基本：アジャイル開発とは何か
０７ アジャイル開発の原点：アジャイル開発の源流「カイゼン」
０８ アジャイル開発の成功率：アジャイル開発の広がり
Chapter２ なぜアジャイル開発なのか
０９ ウォーターフォール開発：従来型の開発手法「ウォーターフォール」
１０ 作ったけれど使われない：顧客が本当に欲しかったもの
１１ 不確実性コーン：ソフトウエア開発は不確かなもの
１２ ムダ：ソフトウエア開発のぜい肉
１３ ウォーターフォールの課題：手戻りできないウォーターフォール
１４ アジャイル開発の原則：アジャイルは不確かさと踊る
１５ アジャイルソフトウエア開発宣言：なぜアジャイル開発なのかを考える
Chapter３ アジャイル開発がもたらす変化
１６ アジャイル開発がもたらす変化：チームの成長とプロセスの進化
１７ アジャイルソフトウエア開発宣言の実践①：個人と対話
１８ アジャイルソフトウエア開発宣言の実践②：動くソフトウエア
１９ アジャイルソフトウエア開発宣言の実践③：顧客との協調
２０ アジャイルソフトウエア開発宣言の実践④：変化への対応
２１ タックマンモデル：職能横断型モデル
２２ チームの機能期：自己組織化チームとリーダーシップ
２３ 成長戦略：アジャイルチームの成長戦略
２４ ＹＡＧＮＩとＫＩＳＳ：筋肉質なソフトウエア
２５ トレードオフの神話：質とスピードは両立する
Chapter４ アジャイル開発の中核にあるコンセプト
２６ コアコンセプト：アジャイル開発の３つのコアコンセプト
２７ チーム①：チームのフォーメーションを定める
２８ チーム②：チームの共通理解を育む
２９ チーム③：チームの活動する場を用意する
３０ インクリメンタル①：少しづつ形づくる
３１ インクリメンタル②：構想とプロダクトを合わせる
３２ イテレーティヴ①：反復的に作る
３３ イテレーティヴ②：反復的な計画作り
３４ イテレーティヴ③：反復的な作成物レビュー
Chapter５ 小さく始めるアジャイル開発
３５ 方法論、プラクティス：アジャイルのはじめの一歩
３６ スプリントバックログ、プロダクトバックログ：タスクの見える化
３７ タスクボードの作り方：状況の見える化
３８ プラニングポーカー：タスクのサイズをチームで見積もる
３９ 朝会：日常の見える化
４０ ペアプログラミング、ペアワーク：ペアで作る
４１ ふりかえり：やったことの見える化
４２ 習慣化：プラクティスの習慣化
Chapter６ 上手にのりこなすためのカイゼン手法
４３ 方法論：より上手にレベルアップする
４４ 継続的インテグレーション、バージョン管理：流れるように自動化するには
４５ テスト駆動開発：エンジニアリングでテストのムダを解消する
４６ チーム①朝会とふりかえりのステップアップ：チームの活動が形骸化し始めたら？
４７ チーム②見える化のステップアップ：散乱した見える化を棚卸しする
４８ チーム③カンバン、モブプログラミング：成果の停滞感に直面したら
４９ 契約：契約ってどうするの？
５０ パターン：プラクティスを自ら実践し自ら作る
５１ 組織にスケール：日本の既存の組織に合わせて拡大させる
Chapter７ アジャイル開発の理解を深める
５２ アジャイル開発の誤解：なぜ、アジャイル開発は誤解を生みやすいのか
５３ 仮説検証：アジャイル開発は早く安くできる？
５４ 見積もり：アジャイル開発は見積もりしない？
５５ リリースプライニング、スプリントプラニング、デイリースクラム：アジャイル開発は計画しない
５６ ドキュメント：アジャイル開発はドキュメントを書かない？
５７ 要件定義：アジャイル開発は要件定義しないの？
５８ 不確実性：アジャイル開発は設計しない？
５９ テスト戦略：アジャイル開発はテストしない？
６０ アジャイル開発の進め方：アジャイル開発は本当にできるのか？
Chapter８ アジャイル開発はあなたから始まる
６１ 失敗の歴史：素直な声に耳を傾けよう
６２ ハンガーフライト：アジャイル開発の学びを深める、広げる
６３ 越境：アジャイル開発を始めよう
Posted by ブクログ
私の担当しているプロジェクトのアジャイル手法が手本のようにアンチパターンとして扱われてて、心が痛くなった(笑)
ウォータフォールからなんちゃってアジャイルで躓いているひとは読む価値があるとおもいます。
※アジャイルザムライ読んでる人はわかる内容かな、私は読んでるのに失敗しましたが。。
Posted by ブクログ
「アジャイル開発」という枠組みだけに留めておくことが勿体無いくらい、開発以外にも適用できる、本質的な考え方についてわかりやすく記載されている本だと思います。個人的には、HowよりもWhyやWhatにおける考え方に大いに共感させていただきました。読み終わった印象として、「顧客のインサイトを捉えて、小さく・早く・継続的にチームでアウトプットを出す。」に尽きるのかなと感じます。
顧客のインサイトを捉えるための方法論として、顧客との協働もありますし、インセプションデッキもあります。前提として、顧客は自身のインサイトを知らないので、そのインサイトを顧客自身に理解してもらうためにも、動くソフトウェアが大切。目的と方法論を整理できれば、アジャイルに物事を進める考え方って、本当に実体験からも論理性からも納得がいくもになります。
小さく・早く・継続的に物事を進めるための方法論として、「見える化」は必要ですし、チームの自己組織化も必要です。継続するためには、効率化も必要なので、様々なプロセスの自動化も必要になり、結果としてCIなども方法論として必要にもなります。これらのことを実践するためには、誰でもできるわけではないので、必然的にプロダクトオーナーやスクラムマスターというタグのついた役割の人も必要になってきます。このあたりの方法論が目的になって「アジャイル開発」が世の中に浸透？したことで、生まれた誤解についてもこの本では触れています。（設計不要？テスト不要？ドキュメント不要？要件定義不要？など。そんな訳ないですよね）
チームで出すアウトプットは、ソフトウェア開発においてはプロダクトになります。ただ、それだけではなく、チームの成長時代も大事なアウトプット。そのためには、改善が必要で、そのための方法論（KPTなど）についても触れられています。ここも、目的と方法論を履き違えなければ、本当に納得いく内容だと思います。
アジャイルは開発プロセスではないです。物事を進める上での本質的な側面を抽出した考え方だと思っています。この考え方は、ソフトウェア開発以外にも大いに役立つと思います。例えば、Whyから始めよなんかはサイモンシネックが言っていることでもありますし、マーケティング理論の基本としてWhyーWhatーHowがあり、この考えはアジャイルの考え方そのものです。方法論自体を軽視するつもりはありませんが、アジャイルの本質を理解して、その上で、自分の組織やチームにどう適用するかを考えていくことが本当に大切だと感じました。
Posted by ブクログ
vucaの時代に即した手法と理解。
開発プロセスの本としては非常にわかりやすかった。
キーワード
変化する前提での設計
コミニケーションも不確実な可能性
機能要件だけじゃなく非機能要件も
やってるうちに真の欲しいものに気づく
品質はプログラム本体で担保を取る
ドキュメントを残さないわけではない
Posted by ブクログ
カイゼン・ジャーニーを読んだ後に、こちらを読むとアジャイルについて整理されていて、わかりやすい。逆にこれだけ読んだのでは、実践する場面が分かりにくい場合もあるやで、カイゼンジャーニーを読むと理解・イメージが深まりやすい
Posted by ブクログ
# 「アジャイル開発」という言葉の説明
## 面白かったところ
* 開発者を含めたプロダクト開発に関わる人向けに書かれているため、IT業界を取り巻く状況などの背景知識もざっくり知れるとこ
* アジャイル開発のはじめ方にも種類があり、導入や初歩でつまづきそうなQ＆Aも揃っていて安心感があ
## 微妙だったところ
* 本に書かれていることは、おそらく「スクラム」というフレームワークに沿って進めていること前提に書かれている印象だが、スクラムとアジャイルは似て非なるものなのでごっちゃになりやす
## 感
仕事をすればするほど、本を読めば読むほど、ソフトウェア開発は難しいと思う
現場で開発者として働いていて思うのだから他の方々はもっと理解が困難なのだろうと思う
だからこそこの本を読んで、「アジャイル開発」という魔法のような言葉に親を殺される前に正しい知識をつけていただきたいと思った
もちろん、チームメンバーには推薦図書として紹介する
Posted by ブクログ
勉強になりました。
経験者がチームに入って、展開するものだな
って、感じました。
この書籍には、これ読んだら、部分的にでも始めましょうとは、書いてありますが。
Posted by ブクログ
アジャイルの概要、具体的な取り入れ方、注意点、など広く浅く書かれた本。
この手の本はいくつか読んだが、そのちょうど良い復習になった。
内容もわかりやすく、例えば上司やグループ全体、部への導入検討などの時に、素材として参考にするにはうってつけの本だと思う。
いきなりこれを読むよりは、何冊か読んで、実践もしてみて、こなれた頃に読むと丁度良いかも。
Posted by ブクログ
実際に開発現場でアジャイル開発の手法が取られていたがイマイチどのようなものか理解していなかったので呼んでみた。ソフトウェア開発は本書に書かれている通り不確実性が大きく、開発中の仕様変更も往々にしてある。現代のソフトウェア開発において、変化に適応するスピード感という観点から、アジャイル開発の有用性がよくわかった。
