わかりやすいアジャイル開発の教科書 の商品レビュー

前川直也,西河誠,細谷泰夫【著】

2019/05/20

　感想として一番思ったことは，丁寧に書かれた本だなぁということです．アジャイルなソフトウェア開発の初学者向けの導入を構成しながら，中盤から後半にかけて多くのノウハウを披露している点は，初学者だけでなく実際にアジャイルな開発をおこなっている人々も多くのことを学べると思います．
　また，「アジャイルを現場に定着させよう」のように，特定技法ではなく考え方を，開発現場で展開・定着させることにフォーカスを当てて話を述べているのは，他ではあまりなく，珍しく貴重ではないかと思います．
　展開・定着に向けたワークショップも8つが具体的な方法まで紹介されており，素振りなどをやっていこうと思います．
　ということで，この本は，アジャイルなソフトウェア開発の初学者および開発現場で展開・定着を考えている人におすすめしたいと思います．

2019/01/20

レビュアーとしてお手伝いさせていただき、献本頂きました。2013年の正月休みはドラフト稿を読んで過ごしたのは良い思い出:-)
もちろん、レビュー時にひと通り読んでいるのですが、出版から1年以上経ってようやくあらためて通読したので記録のため。

これまで、訳書が多かったこの分野の本ですが、前川さん、西河さん、細谷さん、という日本の実践者たちが自分たちの言葉で書いたというところにも価値があると思います。現場に一冊、携行をオススメ。

2021/08/08

引き続き、アジャイル開発のお勉強。改めて共感。

・ソフトウェアの価値を高めるには
　１．変化を受け入れる
　２．変化に対応する
　３．人にフォーカスする

・アジャイルソフトウェア開発宣言
　私たちは、ソフトウェア開発の実践
　あるいは実践を手助けをする活動を通じて、
　よりよい開発方法を見つけだそうとしている。
　この活動を通して、私たちは以下の価値に至った。

　プロセスやツールよりも個人と対話を、
　包括的なドキュメントよりも動くソフトウェアを、
　契約交渉よりも顧客との協調を、
　計画に従うことよりも変化への対応を、

　価値とする。すなわち、左記のことがらに価値があることを
　認めながらも、私たちは右記のことがらにより価値をおく。

・いま必要なものだけを実装する
　「YAGNI」とは「You Aren't Going to Need It.」の頭文字をとったものです。
　直訳すれば「いま、いらないでしょ？という感じです。

・一定の固定された期間を「タイムボックス」とし、プロジェクトの基本リズムとする。
・タイムボックスでは毎回リリースを行い、動くソフトウェアを通してお客様と一緒に価値を確認する。

・「合意形成」よりも「承認」を目標にしてすり合わせていくと、どうしても対立構造や無駄な指摘も多くなってしまう傾向があり、手続きも煩雑化されてしまう可能性がある。このような煩雑さから、コミュニケーションロスが増えることになる。

・アジャイル開発では、なぜドキュメントをなるべく作りたくないのか？
　その理由の一つは、ドキュメントの維持コストです。ドキュメントを作成すると、設計が変わるたびにドキュメントへの反映を行う必要が出てきます。アジャイル開発のような周期の短い反復開発では、ドキュメントを反復のたびに変更することは、開発のスピードを損なう原因になります。

2017/09/17

「アジャイル開発の教科書」の名前の通り、既存の開発と比較してアジャイル開発のメリットを挙げている点や、アジャイルという概念だけで理解するのが難しいことを前提として、どのような形で組織やチームに浸透させるか、ワークショップや日々の心がけなどにも書かれており、わかりやすいものだった。

反面本質を説明する前にわかりやすさを示すために卑近な例を挙げて説明している箇所が、個人的には回りくどく蛇足に感じた。
人によってはそれがあるのでわかりやすいという見解もあるかもしれないが、ただ読む分量が増えているだけという印象を持ってしまったため、☆3つと思いました。

2017/02/02

ブログに記載
http://u1r-red.hatenablog.com/entry/2013/04/04/112855

2015/06/12

日本のソフトウェア開発現場に向けてアジャイル開発を解説されている本です。
この本の特徴としては、アジャイルな場を活性化させるためのワークショップが紹介されているところだと思います。ただ一方で、この本自体は堅苦しい感じで少し読みにくかったのが残念です。
書かれている対象が同じでも「アジャイルサムライ」の方がノリがよくて読んでいてやってみようという気になりました。

2014/09/07

コンサルに行って返答に困る質問の一つに「うちの開発は今V字モデルです。あきやまさんはウォーターフォールの人と聞いていますが、そろそろうちの開発もアジャイルに移るべきでしょうか？」というのがあります。

ちょっと質問してみると、V字モデルではないことがすぐに分かるので、“ああ、アジャイルを導入したら魔法のようにコストが抑えられ、納期が短縮したうえで品質の高いソフトウェアが開発されると夢見ているんだな”と思います（心の中だけで口には出しません）。

ま、そんなことは、ないわけで、これまで経験したことを話します。

「開発者の技術力とモチベーションが大切です」とか「アジャイル憲章はいいですね」とかそういう話です。

さて、本書はアジャイル開発を実践されている人が平易に書いた本です。読みやすいし、グッとくる記述もおおいです。

でも、本ではなく講演で耳から聞いた方が良いと思いました。

2014/08/19

タイトルのとおり、アジャイル開発の入門書。

悪くはない。が、同じ分野に「アジャイルサムライ―達人開発者への道」というぶっちぎりの名著があるので、相対的に高い評価を与えられない。よって☆３つ。

2014/05/19

Wikipediaでアジャイル開発を調べたら、その次ぐらいには是非読んでおいた方がよい本。XPやSCRUMなどの本を読む前に本書を読んでおいたら、何のためにやるのかがよく理解できると思う。
タイトルは教科書となっているが、実施例なども掲載されていて、テストによく出るところをまとめてくれた良い参考書のような感じで、分かりやすく楽しく勉強させてもらいました。

最近アジャイル(スクラム)の勉強をしているが、分かってくれば分かってくるだけ、知らないこと(知りたいこと)が増えてくる気がする。この辺がアジャイルが人を惹き付ける部分でもあるし、本書でアジャイルと禅の考え方が近いとということかなと勝手に解釈してみました。勉強会が開催されるらしいので、本人に会えたら聞いてみよう。

2014/04/05

その名の通り、アジャイル開発の教科書である。著者の方々は実際に、アジャイル開発を行っており、そのノウハウについても記載されており、非常に参考になる。

私自身は、プログラマからマネージャーへの移行中という状況で、かつ、いわゆるウォーターフォールしかやった事がなかったため、とても新鮮に写った。

アジャイル開発は、ソフトウェア工学が否定してきたプロセスやツール重視の考えから、人間重視への方向転換、いわゆるルネサンス的な動きだと思う。結局、ソフトウェアが自動生成されない＝人間が関わる、ことからコミュニケーションを密にとり、フィードバックを密にすることで、人間を成長させていかないと、生産性も品質も上げにくいという、現実があると思う。PMPなども、その辺を考え、個人を高めるPSPなどの活動を行ってきたが、他人からのフィードバックプロセスが不十分であったのではないか？その辺りをアジャイル開発は、プロセス内に上手く取り込んでいる気がした。
また、人重視の考えから、ファシリテーションとの関連が、書かれていたことも興味深かった。そう言った意味でも、様々なヒントが載っているので、オススメです。