今年の誕生日に自分で買っていたのを発見したので読むことにした。
内容としてはアジャイルとは、などの話ではなく現場でアジャイル開発を行うためのプロくティスが45個紹介されている。それぞれが関係があるものだったり、それ単体でやるべきことなどが紹介されている。その中でも気になったものをいくつか書き出してみる。
人ではなくアイデアを批判する
これはちょっと前に読んだ本でもあって誰が出したかではなくそのアイデアで問題が解決できるのかに注目することが大事。ベストなアイデアを出す前にメンバで何を持ってベストとするか認識合わせしておくのが良いというのはそうかもと思った。
時が来たら習慣を捨てる
今までができていたからと言ってそれが本当に良いことなのか、他に楽になることがないのかを探さないことがままある。現状のやり方を踏襲するのが楽なことは多いけど、現状に合わせて考え直すことも大事だなと思う。
技術の採用根拠を明確にする
今動いているシステムがなぜこのアーキテクチャで組まれているのかがわからないことが多い。他にも同じことができるもので簡単にできそうなものがあった時に変更してよいのかどうかの判定が難しくなってしまう。そういうことがないように何故選んだのか、何を大事だと判断したのか、何を選ばなかったのかなどが分かる資料があると良さそう。
Architectural Decision Records (ADRs) などを見かけることも増えてきたので書いてみたい。
役に立つエラーメッセージを提供する
エラーがログに出ていることはだいたいだが、役に立つかどうかというとまた別の話となる。エラーが起きただけではなく、どこでどんなエラーが起きているかなど必要と思えることは分かっているのにそれをログにだせてないことがたまにある。開発をする際にはエラーが起きた時のことも大事だなと思った。
まとめ
- 悪魔のささやきに耳をかさないようにしよう
- 他のメンバーに迷惑がかからないように下準備などはしっかりしよう
- 当たり前のことをサボることなくやるべきことをやろう
