「アジャイル開発をどうやってはじめたらいいの?」みたいな質問をよく受けていて、そういう仕事なのだけれども、”アジャイル”ってよく聞くし、なんとなく流行だし(そ、そーなの?)、ちょっとかじってみた...

「アジャイル開発をどうやってはじめたらいいの?」みたいな質問をよく受けていて、そういう仕事なのだけれども、”アジャイル”ってよく聞くし、なんとなく流行だし(そ、そーなの?)、ちょっとかじってみたいんだけど、目の前真っ暗で道に灯りもついてないし、まず一歩をどこに踏み出せばいいのかわからない人が多い。 自分が”アジャイル”と出会った頃は、まだ日本ではXPくらいしかなくて、イテレーション開発とかもよくわかってなくて、ただひたすらxUnitフレームワークが有名だったんじゃないかな。それがいまや、アジャイルサムライが大ブレイクして、”アジャイル”に興味がある人ならだいたい読んでるし、それを読むと、要求リストだったり、イテレーション開発だったり、あとはカンバンみたいなものも紹介されていたりする。とっかかりの情報量が多いことで、敷居が下がったのも確かだけど、自分がいるところと違う世界の情報が、文字で一気に入ってきて、文字の情報を行動に移すところで迷いが生じたりすることはあるのかもな、と感じていたりする。それを解決してあげるのがアジャイルの先人の役目なんだと思うけど。 もし、あなたが、開発者でひとつのものを作り上げようとしているチームのメンバーだったら、”アジャイル”を始めるときに、まずはユニットテストをコードで書いてみようってことをやってみたらどうだろうか?ユニットテストを書くということと、TDDをやることは目的が違うと個人的には考えているので、いきなりTDDに取り組む必要はないと思う。ユニットテストを書いていって、テスティングフレームワークに充分慣れたらTDDを開始してみればいい。コードにとって、テスティングフレームワークを導入するのは構成管理上の問題になるけれども、TDDを開始するのは開発者個人の問題なので、TDDはいつでも始められる。 アジャイルサムライを読んで、いきなりイテレーションでの開発を始めてみよう、と思う人がいるかもしれない。それもいいとは思う。でも、新しいものを一気に始めるのはとても大変な作業だ。イテレーションでの開発とユニットテストを書いてみることは並行でできるけれども、せーの!で一緒に始めないこと。もし始めるとしたら、自分たちの生産効率がいったん落ちるかもしれないことを(でも慣れてきたら今よりよくなるかもしれないことを添えて)まわりに伝えてから始めよう。 アジャイル開発はどこからはじめても大丈夫だ。でも、大事なのは何故これをやるのか、何故これを作るのか、というのを常に考えながらあたること。アジャイル開発は、作ったモノを使ってくれる人・モノに対する価値を最大化しようとする先人たちがトライ&エラーを繰り返しながら実践してきた集大成なのだから。"アジャイル"を始めるために - CODE.qli.jp