いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 「いちばんやさしい教本」シリーズ [Kindle]

著者 : 市谷聡啓 新井剛 小田中育生

• インプレス (2020年5月1日発売)

感想・レビュー・書評

[trainyuukiさんの感想 · 2020年9月23日]

アジャイル開発はなぜ必要なのか。その理解から始まり、具体的な手順や実施方法が記述されており、ためになった。実際にスクラムを行っているが、なぜこうした手順や手法が導入されているのかという理解につながった。また、実際にアジャイル開発に取り組むにあたり直面する課題や解決策にも触れており、実践的な内容が知れて良かった。

[yoruさんの感想 · 2024年1月5日]

アジャイル開発なんもわからん、というときに読むと、どんなものかがわかる本。
アジャイル開発におけるスクラムやらイテレーションやらなにやら、用語を知ることができてよかった

[tomkimraさんの感想 · 2023年1月10日]

思想と実践がどちらもいい感じに記述されていたように思います．アジャイル開発とは不確実性ある目標に到達する手法，PDCAをより多く回す，「チーム」「イテラティブ」「インクリメンタル」..

[kuwatakaさんの感想 · 2022年10月6日]

「いちばんやさしい教本」シリーズは、経営で必要になった時にその都度、辞書のように活用している。マニュアルとして活用できるので助かります。

[yama219さんの感想 · 2022年5月29日]

アジャイル開発ってよく聞くが具体的にどうやるのかということが記載された本。
自分はガチガチにウォータフォールモデルで開発されることを求められる会社に勤めているが、プロジェクトの進め方とか、仕事の進め方については、はからずもアジャイル開発でも取り入られている方法を取り入れているのかと思った。
ただ、プログラマはほとんど外注しているし、改善・修正を繰り返すアジャイル開発に、設計やプログラムのソースがそれに耐えうるものになっていないと、私が入社した頃(30年前)によく見た汚いソースになってしまうんだろうなと思った。
会社はきれいなソースを書こうとかということに力を入れていないので、やるんだったら自分が旗を振らないとダメなんだろうなと思ったが、保守・運用フェーズでそれを考えても後の祭りである。

[梟さんの感想 · 2021年9月17日]

今まで自分が読んだアジャイル開発の本の中で一番網羅的で実践的な気がする。
* 昨今のソフトウェア開発の傾向やなぜアジャイル開発なのかという前段からの説明
* 実践するときにぶち当たる問題を扱っているということ
* 新しい本なので、過去に出版された良本に書かれていることがうまく引用されている
* しかもPrime readingだと無料！

[monokuropieroさんの感想 · 2021年6月5日]

【目的】
アジャイル開発を知る
【まとめ(1P)】
アジャイル開発とは短いサイクルでリリース→フィードバック→カイゼンを繰り返す
【ポイント(What)】
・不確実な世の中に対応するための開発手法
・現場と強調し必要なカイゼンを探索
・インクリメンタル＝少しずつ、イテレーティブ＝反復的につくる
【アウトプット(How)】
・あったほうがいい機能、将来的に必要そうな機能は省く
・継続的なカイゼンのために見える化しておく
・「フィボナッチ配列（1,2,3,5,8）」単位でタスクを見積もる

【その他】
・YouTubeはもともとマッチングアプリだったが、別の利用目的のユーザーが増加し方向転換した
・「フィボナッチ配列（1,2,3,5,8,13…）」は大きなタスクほど誤差が入る

[januswelさんの感想 · 2021年5月2日]

やさしいと嘘は違う

[gouki9999さんの感想 · 2021年4月26日]

・システム開発において、机上論だけで完成品を求めるのは難しい(機能の6割は使われない)

・アジャイル形式は上記のようなソフトウェア開発における不確かさを吸収し、変更を歓迎する手法である。プロダクトを成長させて、改善させていく思想。

・プロダクトの着地点を見失しなってしまうというリスクもある(永久に作り直しをするなんてことが・・・)

・開発単位は「価値を提供できる最小限のプロダクト」を「小さく(インクリメンタル)すばやく(イテレーティブ)作ること」(要件定義〜設計〜実装〜テスト)フローを細かく回転させる。アジャイルの開発期間をスプリントといい、１〜4週間程度が一般的。

・そのために大事なのがチーム作り、タスクの見える化(やること、やっていること、やったこと)を行う、タスクを細かく最大でも1日単位にする。

・細かい改善をしていく上でプロダクトの品質を担保していくのが、テスト自動化。細かく、頻繁なリリースを行うので、テスト自動化しておく必要がある。

・チーム内のフィードバックが最重要。日にち単位で会議を行う(細かいフィードバックする)必要があるが、会議などが形骸化し、「問題ありません」などの発言が出てくるようになったら危険。

・スプリントごとにKPTを設定する。Keepは良かったので継続すること、Problemは悪かったことで問題だと思ったこと、Tryは次に実行することをフィードバックし、チームを改善、成長させていく必要がある。

・モブプログラミング(複数の人の視点を受けながら、コードを書くこと。ペアプログラミングの多人数版)などもフィードバックを受ける手法の１つ。

・ドキュメントの不在などが言われることがあるが、あくまで手段なのでドキュメントがないわけではない。
プロダクトを成長させるという思想から準委任契約(時間)の方が親和性がある。

[amano225さんの感想 · 2021年4月24日]

『カイゼン・ジャーニー』や『チーム・ジャーニー』の著者による、アジャイル開発についての解説本(正確には、共著者だけど)。
顧客の声よりも、顧客の行動に着目して分析を行うというのは確かにそうかもなと思った。アンケートサイトでたまに「この商品をいくらだったら買いますか？」とか「いくらだったら安いと思いますか？」みたいなアンケートが届くことあって一応答えるけど、自分は買わないなと思う事も多いし。
アジャイル開発の本や記事でよく『カイゼン』という言葉を耳にするけど、"Kaizen"として世界で通じる日本語となっているということを初めて知った(調べたら英語版のWikipediaにもあった：https://en.wikipedia.org/wiki/Kaizen)。いったいどういう経緯で知られるようになったんだ。
ソフトウェアの機能のうち、6割はつかわれないというのはなかなか悲しい話だなと思った。意外とその6割に時間(工数)がかかってたりするんだろうなと思う。
後、YouTubeはもともとデート相手を探すマッチングサービスだったということも初めて知った。最初から動画が投稿できるサイトではあったようなのだけど、いったいどういう使い方を想定していたんだろう…。
YAGNIの原則は聞いたことあるけど、知らない人は多いのだろうなと思う。ようは、今必要ないけど今後必要になるかもしれないという機能は、必要になるまで追加しないほうがいいということだけど、自分の上司は先々のことまで考えて機能を追加しようとするからYAGNIの法則は知らないのだろうなと思う。まあ、気持ちは分からないでもないのだけど。
3週間に一度より、1週間に一度のリリースのほうが品質が安定するっていうのは、多分テストコードがきっちり書かれてるからなんだろうなと思う。プロジェクトによっては、1週間に1度にリリースとなると、テスト時間がとれなくてデグレが怖いとかなりそう。

著者プロフィール

株式会社レッドジャーニー 代表。サービスや事業についてのアイデア段階の構想からコンセプトを練り上げていく仮説検証とアジャイルについて経験が厚い。株式会社リコー CDIO付DXエグゼクティブ、政府CIO補佐官も務めた。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、自らの会社を立ち上げる。株式会社リコー CDIO付きDXエグゼクティブ。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。著書に『カイゼン・ジャーニー』『チーム・ジャーニー』『デジタルトランスフォーメーション・ジャーニー』（翔泳社）、『正しいものを正しくつくる』『組織を芯からアジャイルにする』（BNN新社）、『いちばんやさしいアジャイル開発の教本』（インプレス、共著）、訳書に『リーン開発の現場』（オーム社）がある。

「2023年 『これまでの仕事 これからの仕事　～たった1人から現実を変えていくアジャイルという方法』 で使われていた紹介文から引用しています。」