アジャイルプラクティス：読後の感想

2月入る前に読み終わっていたのですが、遅ればせながら感想を。

小難しいことが書いてあるわけではなくて非常に平易な言葉で、けれど大事な事が書かれています。読んでいて、気になったトピックをいくつか。

1. 成果をあげるのが仕事: 『「自分のせいじゃない」というのが正しいことはない』←の言葉にグサリっ！今までよく言ってたことですが、今後改めます…

11. 設計は指針であって、指図ではない: これは、非常に実感しています。現プロジェクトが真逆で、コーディングに入る前にメソッドのパラメータを含む全てのことを詳細設計書という形で記しておかなければならないという方針です。そのため、詳細設計書を作るためにいったんローカルでコーディングした後に設計書を書いて、その設計書を受けてコーディング担当がほぼ同じプログラムを作成するといった、本末転倒なこともやってましたorz
このトピックに関連して、開発するためのドキュメントと保守・運用するためのドキュメントは別個のものだという意見をどこかで見た気がするのですが、どこだったっけな…

13. いつでもリリースできるようにしておく: このトピック全般。バージョン管理に絡んでくる話ですが、この辺弱い所。こういうのって「習うより慣れろ」だとは思うのですが、R/3だと移送という概念が絡んだりして気軽にバージョン管理を試すことができないんですよね。
とりあえず個人ではSubversionを導入してるのですが、チームでやるのとはまた違ったものでしょうから、早いうちに組織的なやり方を体験しておきたいです。

18. 定額契約は守れない約束: ものすごく弱い＆実感できないところ。ただの一担当者の立場からは、あまり伺いしれないところなので。書いてあることはすごく理解できたのですが、これが実践できるかどうかは知識不足のためにコメントできません…

26. コードで伝える: 『各メソッドには「目的・必要条件・結果・例外」を書こう』とあるけど、今までは必要条件（引数に何が必要か etc）ぐらいしか書いていなかったなぁ。この辺意識してやってみよう。

39. アーキテクトもコードを書くべき: 悲しいかな、まだアーキテクトを名乗る人に仕事上出会っていないけど、コードを書けないアーキテクトは嫌だなぁ。それこそ中島氏のエントリの通り。

40. 共同所有を実践する: メリットは分かるけど、ここにたどり着くまでにはいろいろ壁があるなぁ。実行可能なユニットテストを用意する⇒リファクタリングでコードの改善ができる環境を整える⇒共同所有で誰でもコードの改善が図れる、といった感じ？今まで携わってきたプロジェクトは、基本的に「動いているものには触るな」が方針ですから。

41. メンターになる: 『分からないものを自力で解決しようとすることの制限時間は、1時間くらいが適切』だって。感覚的にも、大体そのくらいですね。

終章の「アジャイルな開発のはじめ方」も、マネージャ向けガイドとプログラマ向けガイドがあるけど両方とも参考になりました。

で、何で今更この本のことを思い出したかというと、↓の小野氏のエントリを見て思うことがあったから。

だが、エンジニアの中には、今日も昨日と同じように「普通に」開発をしていきたいから、自分にとってはウォーターフォール型の開発は実はとても快適で性格にも合ったやり方だという意見を持っている人もおり、メンバーの多くがそういう考え方を持っているチームではアジャイルな方法は苦痛の種になりかねない。
小野和俊のブログ:アジャイルプラクティス - 達人プログラマに学ぶ現場開発者の習慣

「ウォーターフォール型の開発が快適」って思う人がいるのは確かだろうけど、だからといっていつまでも同じように普通に開発していていいかというと、疑問が。それでプロジェクト的にも結果が出ているならばいいけれど、そうならば残業が多いとか3Kとかは言われないですよね。ウォーターフォール型では現在のシステム開発に対応できないから、アジャイルなやり方が出てきたのだと思っていたのですが。

と思ったのが正直な感想。まぁ、嫌な人に無理やり押し付けてもモチベーションが上がらずに逆効果になるというのは確かで、そこはウォーターフォールもアジャイルも関係ないのでしょうけど。