チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

著者 : 池田尚史 藤倉和明 井上史彰

• 技術評論社 (2014年4月16日発売)

作品紹介・あらすじ

継続的改善を実現するモダンな開発フロー。効率的なプロジェクトを支えるノウハウ。チーム開発に必要なツールの導入方法や使い方にフォーカスを当てながら、チーム開発の全体像を俯瞰的に説明。なぜそのツールを使うのか、なぜそのような使い方をするのかについて、現場でよく起きる問題を例示しながら解説した。

感想・レビュー・書評

[横さんの感想 · 2022年7月4日]

良書　いろいろ腑に落ちました。

Ｏｐｅｎ系の開発は、大規模なアジャイルの形態等をとるようになり、ますます複雑になってきています。
リブ管とよばれた、バージョン管理とその管理ツール群、加えてＣＩ（継続的インテグレーション）、デプロイの自動化、テストの自動化など、チーム開発の効率化、高品質化のために、その環境、仕組み、ツールを理解しなければなりません。近年、各プロジェクトにて、体系化されてその内容も固まりつつあると感じています。

それらを知る辞書として本書をお勧めします。

巻末には次のステップとしての参考書がいろいろ紹介されています。

ウォータフォールでも、アジャイル・スクラムでもどちらにも必要となる、チーム開発の全体像を俯瞰する書として、参考になられると思います。

目次（章単位で）

はじめに
第１章　チーム開発とは
第２章　チーム開発で起きる問題
第３章　バージョン管理
第４章　チケット管理
第５章　ＣＩ（継続的インテグレーション）
第６章　デプロイの自動化（継続的デリバリー）
第７章　リグレッションテスト
参考文献・参考ＵＲＬ

[fujixさんの感想 · 2022年3月19日]

▪︎感想
開発に携わった経験が少なく、リテラシーを付けたくて読書。
アプリ開発において、認識すべき工程と関連ツールが体系的にまとめられてる本はあまりない気がする。（他に良い本あれば教えて欲しい）
なのでこの本はとても有意義な本に感じた。
2014年初版なのでもちろん各ツールの現状は色々変わってると思うが、頭の中に枠組みができただけでは十分すぎる。

▪︎メモ
・分散型バージョン管理システム
　→ローカルにリポジトリごとクローンする

・チケット管理システムとバージョン管理システムの連携

・ビルドはコンパイルの前段階

・プログラミングだけではなくインテグレーションの理解が必要

・kickstartはサーバのセットアップ
　→EC2なら不要？
・chefはサーバ自動構成ツール
　→つまりOSより上のレイヤーのセットアップ
　→Opsworksの役割あらためて理解した

・serverspecはサーバ構成のユニットテスト
　→ミドルウェアプロセスが動いてるか
　→特定ファイル、ディレクトリのパーミッション

[batchiさんの感想 · 2021年10月3日]

インフラ、クラウドが自分の主戦場のなので、馴染みがない開発の領域の雰囲気が知れてよかった。2014年初版なので流石に情報が古くなっている部分はある。クラウド黎明期からちょっと過ぎたくらいの雰囲気が窺い知れる。

1. チーム開発とは
1. 1人だけでも開発はできる
2. チーム開発で直面する課題
3. どのように課題に立ち向かうか
4. 本書の構成
5. 本書を読む前の注意点
2. チーム開発で起きる問題
1. ケーススタディの前提
2. ケーススタディ（1日目）
3. ケーススタディ（1日目）における問題点
4. ケーススタディ（2日目）
5. ケーススタディ（2日目）における問題点
6. 理想的なプロジェクトとは
7. 本章のまとめ
3. バージョン管理
1. バージョン管理システム
2. バージョン管理システムの移り変わり
3. 分散バージョン管理システム
4. バージョン管理システムをどう使うべきか
5. Gitを使ったスムーズな並行開発
6. Gitを使った開発フロー
7. データベーススキーマとデータの管理
8. 設定ファイルの管理
9. 依存関係の管理
10. 本章のまとめ
4. チケット管理
1. チケット管理システム
2. 主なチケット管理システム
3. チケット管理システムとバージョン管理システムの連携
4. 新機能の開発、バグの修正時のワークフロー
5. 「あのバグいつ直ったの」という問い合わせに答える
6. 「なぜこんな変更が入ったんだろう」という疑問を解決する
7. 本章のまとめ
5. CI（継続的インテグレーション）
1. CI（継続的インテグレーション）
2. ビルドツールの使い方
3. テストコードの書き方
4. Jenkinsを使ったCIの実行
5. CIの運用
6. 本章のまとめ
6. デプロイの自動化（継続的デリバリー）
1. デプロイとはどうあるべきか
2. デプロイの自動化
3. ブートストラッピング（Bootstrapping）
4. コンフィグレーション（Configuration）
5. オーケストレーション（Orchestration）
6. 運用について考慮する
7. 本章のまとめ
7. リグレッションテスト
1. リグレッションテスト
2. Selenium
3. JenkinsとSeleniumの連携
4. Seleniumテストの高速化
5. 複数のアプリケーションバージョンでのテスト
6. 本章のまとめ

[fleefloatingplanetさんの感想 · 2017年8月4日]

svnをsvnとして使えてなくて恥ずかしくなった。チーム開発のためのインフラ、全然使えてないなぁ…もっとこういうツールを整備して快適に開発できるようにしたい。

[なみかわさんの感想 · 2023年1月19日]

n回目だけどブクログに入れてなかったので。2022年でも感想があってうれしい。ロングセラー。
もちろんいまだともっといろんなツールがあるけど、この本が出た意味は大きかった。

[別府さんの感想 · 2022年3月9日]

・4.3節にBooklogが登場したかと思いきや、Backlogだった。

【書誌情報】
『チーム開発実践入門──共同作業を円滑に行うツール・メソッド』
著者：池田 尚史
著者：藤倉 和明
著者：井上 史彰
シリーズ：WEB+DB PRESS plus
2014年4月16日　紙版発売
版型：A5判／336ページ
定価：2,948円（本体2,680円＋税10%）
ISBN：978-4-7741-6428-1

本書はサービスやアプリケーションを開発する企業において，複数の人たちでチームを組んで開発を進めていく際に必要な考え方や使用するツール，またそれらをうまく使いこなすためのノウハウをまとめています。本書の最初でうまく物事が進んでいない開発現場の一例を示し，その理由と対策についてまとめています。次にその対策に必要なツールである，バージョン管理，チケット管理，CI（継続的インテグレーション），デプロイ，リグレッションテストの章を設け，その使い方と上手な運用ノウハウなどについて現場での経験が豊富な著者が解説しています。
〈https://gihyo.jp/book/2014/978-4-7741-6428-1〉

【目次】
はじめに（著者を代表して　2014年3月　池田尚史）　[iii-iv]
目次　[v-xvi]


第1章　チーム開発とは
1.1　1人だけでも開発はできる　002
1.2　チーム開発で直面する課題　003
1.3　どのように課題に立ち向かうか　004
1.4　本書の構成　005
　　第2章：ケーススタディ
　　第3～5章：基礎的なプラクティス
　　第6～7章：継続的デリバリーとリグレッションテスト
1.5　本書を読む前の注意点　007
　　最適なプラクティスはケースバイケース
　　どのツールを使うかに正解はない

第2章　チーム開発で起きる問題
2.1　ケーススタディの前提　010
　　プロジェクトの前提条件
2.2　ケーススタディ（1日目）　011
　　問題1：重要なメールが多すぎて優先順位を決められない
　　問題2：検証用環境がない
　　問題3：別名フォルダでブランチを管理している
　　問題4：データベースの再作成が困難
2.3　ケーススタディ（1日目）における問題点　016
　　問題1：重要なメールが多すぎて優先順位を決められない
　　　　メールの件数が多いために重要なメールが埋もれてしまう
　　　　ステータス管理ができない
　　　　一覧性，検索性が弱い
　　　　メールでプロジェクトを管理することの課題
　　問題2：検証用環境がない
　　問題3：別名フォルダでブランチを管理する
　　問題4：データベースの再作成が困難
2.4　ケーススタディ（2日目）　022
　　問題5：起動するまで壊れていることに気づかない
　　問題6：他メンバーの修正を上書きして消してしまう
　　問題7：自信を持ってリファクタリングできない
　　問題8：バグの修正時期がわからず，デグレードも追跡できない
　　問題9：ブランチ・タグを活用できていない
　　問題10：テスト環境や本番環境では動かない
　　問題11：リリースが複雑で手順書が必要となる
2.5　ケーススタディ（2日目）における問題点　031
　　問題5：起動するまで壊れていることに気づかない
　　問題6：他メンバーの修正を上書きして消してしまう
　　問題7：自信を持ってリファクタリングできない
　　問題8：バグの修正時期がわからず，デグレードも追跡できない
　　問題9：ブランチ・タグを活用できていない
　　問題10：テスト環境や本番環境では動かない
　　問題11：リリースが複雑で手順書が必要となる
2.6　理想的なプロジェクトとは　039
　　チケット管理システムに課題などが集約されている
　　できる限りバージョン管理システムを利用する
　　繰り返し再検証可能なCIシステムを用意する
　　環境の影響を最小限にとどめ，常にリリース可能にしておく
　　すべてを記録して追跡可能にする
2.7　本章のまとめ　042

第3章　バージョン管理
3.1　バージョン管理システム　044
　　バージョン管理システムとは
　　バージョン管理システムを使うとなぜ便利なのか
　　　　変更内容という最も基本的な記録が残る
　　　　バージョン間の差分を簡単に確認できる
　　　　間違って他人の変更を上書きしないで済むしくみがある
Column　ロックモデルとマージモデル
　　　　任意の時点まで巻き戻すことができる
　　ファイルベースとチェンジセットベース
Column　複数の派生を作ることができる，ある時点での断面を保存できる
3.2　バージョン管理システムの移り変わり　053
　　バージョン管理システムがない時代（1970年代以前）
　　RCSの時代（1980年代）
　　CVSの登場（1990年代）
　　VSS，Perforceなど商用ツールの登場（1990年代）
　　Subversionの登場（2000年代）
　　分散バージョン管理システムの登場（2005年以降）
　　番外編：GitHubの登場
　　バージョン管理システムの導入状況
3.3　分散バージョン管理システム　062
　　　　分散バージョン管理システムを使うべき5つの理由
　　　　リポジトリの完全なコピーをローカルマシンに持つことができる
　　　　動作が速い
　　　　一時的な作業の履歴管理が容易である
　　　　ブランチ，マージが手軽にできる
　　　　場所を選ばないコラボレーションが可能
　　分散バージョン管理システムのデメリット
　　　　真の意味では最新バージョンはシステム上存在しない
　　　　真の意味ではリビジョン番号はない
　　　　ワークフローが柔軟に設定でき過ぎるため混乱しやすい
　　　　考え方に慣れるのに時間がかかる
3.4　バージョン管理システムをどう使うべきか　065
　　前提
　　バージョン管理システムで管理すべきもの
　　　　ソースコード
　　　　要件書，設計書などのドキュメント
　　　　データベーススキーマ・データ
　　　　設定ファイル
　　　　ライブラリなど依存関係定義
3.5　Gitを使ったスムーズな並行開発　069
　　ブランチの使い方
　　　　ブランチとは
　　　　リリースブランチとは
　　　　クローンとブランチの作成
　　　　コミットとコミットログ
　　　　ブランチの切り替え
　　　　バグ修正後のコミット
　　　　masterへのマージ
　　　　masterへのPush
　　　　ブランチの使い方のまとめ
　　タグの使い方
　　　　タグとは
　　　　タグの作成
　　　　タグの確認
　　　　タグの取得
Column　タグ名とブランチ名を同一にするのを避ける
　　　　タグの使い方のまとめ
Column　Detached HEADとは

3.6　Gitを使った開発フロー　081
　　Gitを使ったワークフローのパターン
　　　　中央集権型ワークフロー
　　　　GitHub型ワークフロー
　　ブランチ戦略のパターン
　　　　git-flow
　　　　github-flow
　　　　筆者の事例（折衷案）
　　最適なフローとブランチ戦略は現場によって異なる
3.7　データベーススキーマとデータの管理　090
　　データベーススキーマを管理する必要がある理由
　　　　データベース管理者の変更管理を任せた場合
　　　　共有データベースでスキーマを変更する場合
　　データベーススキーマをどのように管理すればよいか
　　　　バージョン管理に必要な要件
　　　　データベースマイグレーションとは
　　　　データベースマイグレーションの機能
　　データベースマイグレーションツール
　　　　Migration（Ruby on Rails）
south（Django）
　　　　Migrations Plugin（CakePHP）
　　　　Evolution（Play Framework）
　　具体的な使い方（Evolution）
　　　　規約
　　　　SQLファイルの適用
　　　　開発者間でのスキーマの同期
　　　　不整合の管理
　　データベースマイグレーションの注意点
3.8　設定ファイルの管理　102
3.9　依存関係の管理　103
　　依存関係解決システム
　　　　JVM系言語
　　　　スクリプト系言語
　　　　依存関係を管理するメリット
3.10　本章のまとめ　106

第4章　チケット管理
4.1　チケット管理システム　108
　　プロジェクトがうまく回らない理由
　　紙やメール，Excelでタスク管理をすることの問題点
　　チケット管理システムの導入メリット
　　　　タスク管理をするための基本機能がある
　　　　一覧性，検索性が高い
　　　　情報の一元管理と共有が可能である
　　　　レポーティングに利用できる
　　　　他システムとの連携が可能，拡張性がある
　　チケット駆動開発とは
　　　　チケット駆動開発の具体的手順
Column　チケット駆動開発を徹底する場合
4.2　主なチケット管理システム　114
　　OSS製品
　　　　Trac
　　　　Redmine
　　　　Bugzilla
　　　　Mantis
　　商用製品
　　　　JIRA
　　　　YouTRACK
　　　　Pivotal Tracker
　　　　Backlog
　　　　GitHub
　　ツール選定のポイント
Column　チケット管理システムの応用事例
4.3　チケット管理システムとバージョン管理システムの連携　124
　　連携によって実現する機能
　　　　コミットからチケットへのリンク
　　　　チケットからコミットへのリンク
　　　　コミットと同時にチケットのステータスを変更する
　　連携の設定方法
　　GitHub
　　　　GitHubのissue
　　　　Service Hooks
　　　　GitHubとPivotal Trackerの連携
　　　　GitHubとJIRAとの連携
　　Trac/Redmine
　　Backlog
　　　　BacklogのGitとの連携
　　　　BacklogとGitHubの連携
　　Git自身の用意するHookを使う方法
4.4　新機能の開発，バグの修正時のワークフロー　134
　　ワークフロー
　　　　①チケットの起票
　　　　②担当者のアサイン
　　　　③開発
　　　　④コミット
　　　　⑤リポジトリにプッシュ
4.5　「あのバグいつ直ったの」という問い合わせに答える　137
　　Pivotal Trackerの例
　　　　記憶に残っている文字列で検索
　　　　検索
　　　　チケットからソースコードの変更を探す
　　Backlogの例
　　　　検索
4.6　「なぜこんな変更が入ったんだろう」という疑問を解決する　142
4.7　本章のまとめ　143
　　チケット管理とバグ管理，要求管理について

第5章　CI（継続的インテグレーション）
5.1　CI（継続的インテグレーション）　148
　　CI（継続的インテグレーション）とは
　　　　インテグレーション
　　　　インテグレーションを継続的に行うのがCI
　　開発をアジャイル化する
　　　　ウォーターフォール開発の開発フェーズ
　　　　アジャイル開発の開発フェーズ
　　なぜCIのようなプラクティスが求められるか
　　　　コストメリット
　　　　市場の変化のスピード
　　　　スピードと品質を両立させるには
　　CIに必要なもの
　　　　バージョン管理システム
　　　　ビルドツール
　　　　テストコード
　　　　CIツール
　　テストを書くためのフレームワーク
　　　　テスト駆動開発（TDD）系フレームワーク
　　　　振る舞い駆動開発（BDD）系フレームワーク
　　主なCIツール
　　　　Jenkins
　　　　TravisCI
5.2　ビルドツールの使い方　164
　　新規にプロジェクトを始める場合
　　　　プロジェクトのひな型作成
　　　　依存関係の定義
　　　　テストの実行
　　　　Eclipseへのインポート
　　既存プロジェクトを自動ビルド可能にする場合
　　ビルドツールのまとめ
5.3　テストコードの書き方　172
　　CIの対象となるテストの種類
　　　　テストをいつ書くのか
　　　　新規にプロジェクトを始める場合
　　　　既存プロジェクトにテストがない場合
　　　　バグ修正または新機能を追加した場合
　　厄介なテストをどう書くか
　　　　外部とのやりとりがあるテスト
　　　　モッキングフレームワークを使ってテストする
　　　　インメモリデータベースを使ってテストする
　　　　データベース変更管理や設定ファイル管理のテスト
　　　　UIを伴うテスト
　　　　厄介なテストは工数とのトレードオフ
5.4　Jenkinsを使ったCIの実行　180
　　Jenkinsのセットアップ
　　　　ネイティブパッケージを使ったセットアップ
　　Jenkinsで何ができるのか
　　ジョブの新規作成
　　ソースコードをチェックアウトする
　　自動でビルドおよびテストを実行する
　　　　定期実行
　　　　バージョン管理システムをポーリング
　　　　バージョン管理システムからプッシュする
　　　　ビルドの記述
　　結果を集計してレポーティング
　　カバレッジを計測する
　　　　JUnitXML形式でレポートを出力するのが効率的
　　　　カバレッジ計測ツール
　　　　Maven Coberturaプラグインのインストール
　　　　Java系ライブラリの探し方
　　　　Jenkinsプラグインの設定
　　静的解析をする
　　通知の設定をする
5.5　CIの運用　197
　　ビルドが壊れたらどうするか
　　　　Subversionなど中央集権型バージョン管理システムの場合
　　　　Gitなど分散バージョン管理システムの場合
　　　　ビルドを壊したときの罰ゲーム
　　　　テストしてからマージする
　　トレーサビリティの担保
　　　　ビルドとコミットを関連づける
　　　　チケット管理と連携する
5.6　本章のまとめ―― CIによって得られるもの　208

第6章　デプロイの自動化（継続的デリバリー）
6.1　デプロイとはどうあるべきか　210
　　デプロイの自動化における恩恵
　　　　細かくたくさんリリースできればリスクをコントロールしやすくなる
　　　　フィードバックを早く得られるようになる
　　　　組織がスケールする
6.2　デプロイの自動化　212
　　デプロイの自動化における共通認識
　　デプロイメントパイプライン
　　　　自動化によりデプロイの速度を加速させる
　　　　誰でもデプロイが行えるようにすることが重要
　　プロビジョニングツールチェーン
6.3　ブートストラッピング（Bootstrapping）　216
　　Kickstart
　　　　Kickstartの利用方法
　　　　利用する際の注意点
　　　　Kickstartの設定例
　　Vagrant
　　　　開発者ごとに実機を用意することは難しい
　　　　仮想環境を利用する際の懸念点
　　　　Vagrantとは
　　　　Vagrantのインストールと実行方法
6.4　コンフィグレーション（Configuration）　222
　　自動化を行わない場合の問題点
　　Chef
　　　　Chefの構成
　　　　ディレクトリ構成とファイル配置
　　　　node.json
　　　　setup.json
　　　　solo.rb
　　　　default.rb
　　　　virtualhost.conf.erb
　　　　Chefの実行方法と実行結果
　　　　Chefを利用するメリット
　　　　Chefを利用する際の注意点
　　　　Chefを利用するタイミング
　　serverspec
　　　　serverspecとは
　　　　serverspecのインストール
　　　　テストファイルの記述方法
　　　　httpd_spec.rb
　　　　git_spec.rb
　　　　serverspecの実行方法と実行結果
　　　　serverspecのメリット
　　ベストプラクティス（その1）
　　　　Vagrantfile
　　　　default.rb
　　ベストプラクティス（その2）
　　物理サーバがサービス投入可能になるまでの流れを自動化する例
　　リリース作業についてのアンチパターン
6.5　オーケストレーション（Orchestration）　239
　　Capistrano
　　　　Capistranoのシステム構成
　　　　Capistranoのインストール
　　　　deploy.rb
　　　　Capistranoの実行方法
　　Fabric
　　　　Fabric（直列実行）の場合
　　　　Capistrano（並列実行）の場合
　　　　ローカルサーバとリモートサーバの操作の違いを理解する
　　　　Fabricの実行方法
　　Jenkins
　　　　マスタノードとスレーブノードの連携
　　　　スレーブノードの追加
　　　　ジョブの追加
　　　　ジョブの実行
　　ベストプラクティス
　　　　JenkinsとFabricを組み合わせる
　　セキュリティについて考慮する
Column　手作業でデプロイするケース
6.6　運用について考慮する　256
　　サービスを止めないデプロイ方法
　　ブルーグリーンデプロイメント
　　クラウド時代のブルーグリーンデプロイメント
　　ロールバックについての考察
　　　　退路は常に用意する
　　　　データベーススキーマのバージョン管理
　　　　ロールバックの検証
　　　　ソース更新のみのリリース時のロールバック
　　　　データベーススキーマ更新時のロールバック
6.7　本章のまとめ　265
　　PaaSを利用する手段

第7章　リグレッションテスト
7.1　リグレッションテスト　270
　　リグレッションテストとは
　　テスト種別の整理
　　　　チームを支援する技術面のテスト（第1象限）
　　　　チームを支援するビジネス面のテスト（第2象限）
　　　　製品を批評するビジネス面のテスト（第3象限）
　　　　技術面のテストを使った製品の批評（第4象限）
　　リグレッションテストの必要性
　　　　デグレードの発生
　　　　テストを自動化すべき理由
　　リグレッションテストの自動化で目指すこと
7.2　Selenium　277
　　Seleniumとは
　　Seleniumの利点
　　　　自動化テストケース作成が簡単
　　　　多くのブラウザやOSをサポート
　　Seleniumコンポーネント
　　　　Selenium IDE
　　　　Selenium Remote Control（Selenium RC）
　　　　Selenium WebDriver
　　テストケースの作成と実行
　　　　Selenium IDEのインストールと実行
　　　　Seleniumのテストケース
　　　　良いテストケースとは
　　　　Selenium Serverを使ったテスト実行
　　Seleniumの実践活用
　　　　画面が変更されていないかをテストする
　　　　Seleniumテストを安定させるためには
7.3　JenkinsとSeleniumの連携　294
　　JenkinsとSeleniumの連携手順
7.4　Seleniumテストの高速化　299
　　Jenkinsの分散ビルドでテストの並列実行
　　　　Jenkinsの分散ビルドの構成
　　　　分散ビルドの設定
　　Seleniumテスト並列化の難しさ
7.5　複数のアプリケーションバージョンでのテスト　306
　　アプリケーションのデプロイ
　　テストケースをバージョン管理システムからチェックアウト
　　Seleniumでのテスト
7.6　本章のまとめ　309

参考文献・参考URL　[310-311]
索引　[312-318]
著者プロフィール　[319]

[yutahasegawaさんの感想 · 2020年6月12日]

チーム開発を行う上で有用になりそうな開発プロセス、ツール等の紹介書。実際のインシデントのケーススタディに即して紹介されてるので導入イメージがしやすい。何かソリューションに困ったときのインデックスとして手元置いておいても良いかも。

[onesword0618さんの感想 · 2020年5月6日]

開発のプロセスについての視座を高める書籍でした。

ビジネスのプロセスが加速度的になる昨今。
常にサービスとしてリリースできる状態を維持しながら開発をしなければいけない。

また、ビジネスの変化に耐えうるまたは、受け止めることが必要。

そういうことは意識はしていたけど、言語化できる状態ではなかった。

この書籍は、その示唆を与えてくれました。
CIと継続的デリバリーについて図示を交えて解説をして理解が深まりました。プロダクトオーナーでなかったとしても、プロジェクトを成功に導こうとする一員として学習することは損ではないです。

ただ、この書籍を盾に、論を叩きつけるべきではありません。今を改善するために必要なことは何かを対話するために利用したほうが望ましい結果を得られると思います。

記載されているサービスにはいくつか変更があったりするので、利用するには類似サービスの比較を踏まえて行うべきだと思います。

[isopさんの感想 · 2018年10月7日]

ある程度の人数でソフト開発を行うための手法やツールの紹介をしている本。 個々のツールや手法の説明をしている本はあっても、ワークフローを含めて包括的にまとまった本はめずらしいので、結構貴重だと思う。 新人さんとかに、とりあえず読んどけ、という感じの一冊と思います。 2章のケーススタディで「あるある」と思った人は読むべきと思います。 後は、経営者の人にも読んで欲しい。初期投資は少なからずかかるけど、開発プロセス上のムダを削ることで、開発終盤のトラブルを大きく減らし、バグ潰しにかかるコスト・期間を削減できるので、継続的に投資回収できるということを知っておくべき。

[tottu22さんの感想 · 2017年10月21日]

実際にこの書籍に載っているプロセスを踏んで開発に臨み、
成功することができました。
これまでウォーターフォール開発しかしてこなかったので、
まずは本書籍を読もうと思って、読んだところ、
内容もわかりやすく書いてあり、実践もしやすかったです。
これからアジャイルに取り組みたいと考えている方、
この書籍の中の一部分からでも使えると思うので、
参考にしてみてはいかがでしょうか。