アジャイルソフトウェア開発の奥義

著者 : ロバート・C・マーチン 瀬谷啓介

• ソフトバンククリエイティブ (2004年6月30日発売)

作品紹介・あらすじ

アジャイル開発は、めまぐるしく変化する仕様要求にさらされながらも、迅速にソフトウェアを開発する能力を与えてくれる。こうしたアジャイル性(俊敏性)を達成するためには、規律とフィードバックを与えてくれるプラクティス(実践法)が必要だ。また、柔軟性と保守性を兼ね備えた設計を実現するための基本原則や、そうした原則をバランスよく利用するためのデザインパターンを理解している必要がある。本書は、この3つのコンセプト(原則・デザインパターン・プラクティス)をすべて縫い合わせ、1つにまとめようという試みである。Software Development誌Jolt Award受賞。

感想・レビュー・書評

[masaさんの感想 · 2022年6月30日]

冒頭がアジャイルとはからプロセスの進め方の説明。後半はデザインパターンなどの紹介を含めた設計の話で構成されている。
結論としては、
デザインパターンは銀の弾丸でなんでも倒せる最強の武器ではない、必要悪である。
むしろ常によすがとすべきはSOLIDのS(とKISS)である
デザインパターンは複雑性を持ち込むため、そんなデメリットを補って余りあるほどのメリットが設計に対してもたらされるなら導入してもよいというくらいの認識でいること
の3つが挙げられる
デザインパターン本としても優秀
サンプルコードはjavaとc++
この版以降はjavaに統一されていると聞いているのでc++使う人注意

[beakmarkさんの感想 · 2019年1月20日]

コウイチさんが「大事なことは全部Bobおじさんに教わった」と言っていたのがよくわかった。

しかし、、、借り物だしぶったぎるわけにはいかないので、この厚い本はかばんに入れて電車で読むことも出来ず、会社で空き時間にちまちま読んでいたら、、、、読了までにすっごい時間がかかってしまった^^;

[ichiro.marinersさんの感想 · 2018年10月23日]

例がJavaで書かれていることを除けば（私がC++プログラマーであるという理由）、オブジェクト指向＆アジャイルの開発スタイルの解説本として、最高の出来。翻訳もよく、当に”奥義”といえるレベル。言語以外のソフトウエアエンジニアリングの本を人に勧めるときには、必ずこの一冊を含める。

[takehiko102982さんの感想 · 2017年8月28日]

分厚いが、少しずつでも読みたい。章が細かく分かれているので、予想よりも読みやすい。途中で止めれるので、短い時間でも読む気になるし、いいかも。


ツールより人、は当然よね。チームとして機能するようにする方が先。

ドキュメントよりもコード、というのもわかるが、不足する分は先輩が後輩に教えて行くもの、というのは、違う気が。特にSIでは人が変わるのが当たり前なので、そのままやるのは違うだろう。じゃぁどれは作るべきなのだろう。

プロジェクトのコストや納期を前もって決めるなど無理…まさしく…

12の原則で、賛同できないのは、ドキュメントの点かな。プロセスも変えればいい、とあるが、簡単に変えられないプロセスもあるのでは…

受入テストさえも自動化するのか、そりゃ驚き。ただ、これをできる顧客って少ないだろうなぁ。これをプロジェクトメンバーが作ったら受入テストじゃないし。ここで言っている受入テストは、いわゆる結合テストに近い気がするな。

XPではリリース週を除いて残業は不可ってすごいな。そこまで言う？

プランニングやテストファーストの考え方は今まで理解していたものとほぼ同じかな。でも、受け入れテストの自動化は…結構大変そうだなぁ、と。短期間でイテレーションを回すので必要なんだろうけど、違和感あり。ただ、書いてる内容は、guiと繋がないなど、ビジネスロジックの受け入れテストに着目しているので、ITの自動化って感じかなぁ。

テストコードが一番の仕様書、というのはよくわかる。綺麗にテストコードが書かれていると、概ねメソット設計やクラス設計はわかる。


ソフトウェアモジュールの３つの機能って何？ 処理を実行する機能、変化を許容する機能、読み手にモジュールの意図を伝える機能、らしい。後半２つが初耳であり、ある意味、アジャイルの根底の考え方なように思える。そして、必ず全てのモジュールをリファクタリングするべし、というのもなかなかだな。でも、確かにそれくらいやるべき、かもな。リファクタリングを食後のキッチンの片付け、とい表現も面白い。

設計の悪臭っていいな、表現。硬さ(変更のし辛さ)、もろさ、移植性の低さ、扱いにくさ、不必要な複雑さ、不要な繰り返し、不透明さ、が悪臭らしいが、確かに、という感じ。実例も乗っててわかりやすい。ただ、硬さと複雑さは、似ていてどう違うのやら。不必要な複雑さ、は、将来を見越した拡張性を確保した設計、らしい。良さげに見えるけど、先がどうなるかわからないのに、やっておくのは、よろしくないらしい。まぁ次のフェーズで直すって決まっているなら意味はあるだろうから、全部が全部無駄ってことはないだろうけど。

単一責任の原則は、責任とは変更理由、と言っている。これ、よく分かるのだが、則るのは意外と難しい… 初めから全ての変更理由を見通すのは不可能。なので、その必要性が出たら、やる、のが適切かな。

オープンクローズドの原則。拡張にオープン、修正に対して閉じる必要がある。難しいが抽象クラスやインターフェースをきちんと定義すること、かなぁ。それは、既存コードを変更するのではなく、コードを追加するだけで、新しい機能を追加したり変更することができること。

とはいえ、単一責任と同様、あんまり抽象化し過ぎると、難しくなる。やっぱりとりあえず作って、必要性が出たら、直す、のがいいのだろう。そのためにもテストファーストやらをちゃんとやって、直しやすくしておく必要がある。

[mokemokechickenさんの感想 · 2012年7月18日]

全体的なアジャイル開発の進め方、という意味では割とあっさりとした、でもポイントは抑えた内容かな、と思いました。
素晴らしい点は、
開発の重要なポイントは「コードを書くこと」という観点で、
OOPの原則、デザインパターンの説明をしつつ、
アジャイル開発らしく、
「実際に動く」「変更を受け入れる」「簡潔なコード」を

重視した実装をどのように進めていくかが、
とてもよく解説されています。

「基本」と「応用」を一体化させたような印象で、
まさに「奥義」とはこういうことを言うのかもしれない、と感じました。

[akiyama924さんの感想 · 2012年4月30日]

アジャイルソフトウェア開発を正しく理解したい人にお勧めの一冊です。
TDDについてもかなり触れられています。「HAYST入門」ではテストファーストの概念を参考にさせていただきました。
後半になると、プログラミング知識が必要となるのですが、前半の「第1部　アジャイル開発」、「第2部　アジャイル設計」はプログラミングができなくてもOKです。特に第8章から第12章に示された以下の原則は重要です。
　・ 単一責任の原則（SRP）
　・ オープン・クローズドの原則（OCP）
　・ リスコフの置換原則（LSP）
　・ 依存関係逆転の原則（DIP）
　・ インターフェース分離の原則（ISP）

[craftsmanshipさんの感想 · 2012年3月10日]

オブジェクト指向設計の原則など、ソフトウェア開発の基盤となる重要な知識がまとめられています。
また、実際の開発の流れに沿って、デザインパターン適用の実例をまじえつつ、アジャイル開発の実際が説明されています。
タイトルは「アジャイルソフトウェア開発の奥義」となっていますが、「アジャイル」はただのアイキャッチではないでしょうか。
ほんとは「ソフトウェア開発の奥義」。
アジャイルな開発をする人はモチロンのこと、そうでない開発をする人にとっても、必須の知識が満載です。

[masabochiさんの感想 · 2012年2月28日]

巷で話題なアジャイル開発。
ちなみにアジャイル開発というのは、
「ソフトウェア要求仕様の変更などの変化に対して機敏な対応ができ、顧客に価値あるソフトウェアを迅速に提供することを目的とするソフトウェア開発方法論の総称のこと」。

僕も技術者の端くれ。さぁ読んでみよう。

要は、顧客に対して要求変更されたら、迅速に開発します。直しますってこと。
本書では、アジャイル開発のなかでも「エクストリーム・プログラミング」
で、これまた今までの開発の常識を覆す。

顧客に未完成で納品。そのあとバグがあればなおします。
ペアで開発（ペアプログラミング）。一人はプログラミング、一人はレビュー要員。
コミュニケーション重視、迅速なコミュニケーションをすることでスピーディに開発。

実際できるかどうかは別として、こういう開発手法もあるという勉強になったし、
掲載されたソースを読むだけでも、JAVAのコーディング勉強になる。

始終、ソースを眺めた本だったなぁ。

[kaizenさんの感想 · 2011年12月13日]

この本を読むまで、はずかしながらSingletonってなんのことか知りませんでした。

16章の「singletonパターンとMonostateパターン」を読んで、はじめてああ、そうだったのかと知りました。
実際に、わかるようになったのは、TOPPERSプロジェクトのコンポーネントWGで、シングルトンという単語を耳にするようになり、内容、振舞などを検討するようになってからです。

Singletonは単一生成、monostateは単一状態なのですね。なぜ、みんな日本語で言わないのでしょうか。たしかにプログラムで書く用語は、プログラムの用語のままの方がよいことはわかります。でも、翻訳するのなら、日本語に翻訳すれば、意味がわかって、説明が同じ量でわかります。そのため、singleton(単一生成)、monostate（単一状態）でよいでしょうか。single, monoの語幹の意味の違いがまだよくわかっていません。

翻訳しない単語は、意味をわかるために、説明を訳注として追加してくださると幸いです。
単語の意味がわかれば、もうすこし理解が進むと感じました。

実際には開発しながら理解しないとだめだということ納得しました。

[こじーさんの感想 · 2011年4月21日]

タイトルには“アジャイルソフトウェア開発“と書かれているが、アジャイルソフトウェア開発については簡単に説明しているだけで、本書の主な内容はオブジェクト指向についてだと思う。
この本には、「貧弱な設計の兆候」、「オブジェクト指向設計の原則」、「デザインパターン」という、オブジェクト指向で開発するための基本的だが、非常に重要なことが書かれている。

特に「オブジェクト指向設計の原則」については、詳しく纏められている本が少ないので、非常に参考になると思う。
この原則は、良い設計を作る上での参考になるだろう。

オブジェクト指向設計の原則
　１．単一責任の原則 (SRP : Single Responsibility Principle)
　２．オープン・クローズドの原則 (OCP : Open-Closed Principle)
　３．リスコフの置換原則 (LSP : Liskov Substitution Principle)
　４．依存関係逆転の原則 (DIP : Dependency Inversion Principle)
　５．インタフェース分離の原則 (ISP : Interface Segregation Principle)