More than 1 year has passed since last update.

「アジャイルサムライ」をアジャイル開発ではないエンジニアが読んだ感想

Posted at 2022-07-04

書籍

ソフトウェア開発において、目をそらしがちな事実を真っ向から受け止めている
その上で「どう改善していくか」の考え方について書かれているため、
アジャイル開発ではない環境で働いている自分でも、「どう改善していくか」の考え方を取り入れることができそう
挿絵や実例が多く、また軽快なテンションの文調なので、重たい内容のはずなのに、するすると読めてしまう
ソフトウェア開発が、もっとわくわく、楽しい仕事にできるのではないか、と思わせてくれた

P13

プロジェクト開発時点に
すべての要求を集めることはできない

集めたところで、要求はそれも
必ずといっていいほど変わる

やるべきことはいつだって、
与えられた時間と資金よりも多い

これまで内心そうではないか、とぼんやり疑っていたことを、本書では序盤に認めてしまっている。
このことを事実と受け入れることで、変化に対応できる仕組みや、これまで向き合っていなかった課題へと取り組んでいけるようになる。

P86
太古の昔より、あらゆるプロジェクトは4つの固く結びついたフォースによって統治されておる。
それが荒ぶる四天王、すなわち時間、予算、品質そしてスコープだ。

時間、予算、品質。アジャイルサムライはこの三者のいずれも固定する。
するとたった1つだけ、動かすことのできるフォースが残る。
それがスコープだ。

プロジェクトとして成果をあげるというゴールを達成するために、スコープのみを柔軟に扱う。

P152
スコープを柔軟にしておくこと。
これこそがアジャイルプロジェクトで計画を誠実なものに保ち続けるための秘訣だ。

3つの真実であったように、要求は必ず変わる。
だから最初から要求が変わることを歓迎して、変更するためのルールを決めておく。
スコープに新しいストーリーを追加するときは、必ず既存のストーリーを削ってもらうこと。

やれることには限度がある。
気まずくても、顧客にその事実を共有することで、プロジェクトを健全に進めることができる。

P126
見積りをどうしても間違えてしまうことが問題なんじゃない(まあ実際、間違えてしまうわけだし)。
問題は、見積りから本来そこにありもしないものを読み取ってしまうこと
―――つまり、見積りを未来の正確な予測だと思い込んでしまうことにあるんだ。

私も見積りを行った当初は、「大体で見積もったもの」と覚えている気がするが、
時間が経つにつれて、その感覚が薄れ、見積りが正確な予測だと思いがち。

実際の開発速度を計測して、前倒しで進んでいるのか、見積りよりも遅れそうなのかを判断して、
どれくらいで完了しそうかを予測していくべき。

P218
プロジェクトの状況が芳しくないからといって、そこから目を背けてはならない。
その状況自体が素晴らしい教師となることがある。
失敗を受け入れ、その教訓をチームメンバーと分かちあい、前へ進んでいくのだ。

顧客を前にして何も成果を披露できない惨めな経験によって、チームは同じことを2度と繰り返そうとはしないはず。
その失敗を当たり前のものとして受け入れず、どうにか改善しようとすることで成長できる。

P287
いいかい、アジャイル開発とは旅そのものであって、目的地じゃないんだ。この旅に終わりはない。
肝に銘じてほしい。アジャイルで「あること」なんてどうでもいいんだ。
大切なのは素晴らしいプロダクトを作ることと、それを君のお客さんにちゃんと届けることなんだ。

成果を顧客に届けること、そして目をそらさずに改善のために努力をおしまないこと。

これらを続けるのは大変だと思うが、そんな風にきちんと顧客へ成果を届けることができたら、開発に対してストレスなく、やりがいのある仕事ができると思う。