ツールの導入から始めるか、ツールの導入から始めないかそれは問題
ではない。
事の発端は以下の blog の
アジャイルサムライ読書会(横浜道場) 第1回に参加してきた #agilesamurai #横浜道場 - Shinya’s Daily Report
のこの部分
アジャイルを導入するには“ツール（Redmineとか）を用意する”
これへの私の所感は
ツールの導入から始めることについて、私のツイートを切欠に色々ツイートされていたりするが、一行目に書いてある通り、本質的な問題はそこではない。
確かにアジャイル開発の度合い、割合を高めていくと、ツールによる負荷の軽減がなければ、回らなくなる。これは事実だ。しかし、それとアジャイル開発を始める際に最初にツールを導入することは全く異なる。まず自分たちの状況にアジャイルのメソッドがどの様に作用するかを知る必要がある。Redmine が例として出ていたが、Redmine を使うならば、どの部分の負荷を軽減したいのか？＝どんなプラクティスを導入したいのか？を考えることが最初にすることだ。
これはツールから入ることが悪いと言っているわけではない。ツールを入れる・入れないの判断の前に自分たちのプロジェクト、コンテキストとしてどんなメソッド・プラクティスをどういう風に使うのか？ それはどうしてなのか？をまず考えなければならないということだ。
例えば、リリース直前に問題点や改善点が沢山見つかって、リリースが遅れてしまう。だから継続的インテグレーションを行って、早期に問題点や改善点を見つけられる様にしよう。継続的インテグレーションは Hudson, Jenkins なら無料で、簡単に導入出来るからこれを使おう、といったものや、ユーザがキャッシュを生み出す機能から先にリリースして欲しいという要望があった。今までの Excel の WBS だと、後から作業項目を追加すると厳しいので、ホワイトボードと付箋紙を使って、 Todo 管理をしよう。いやいや、付箋紙だと記載ミスした時に修正するのが難しいし、コピーするのも手間がかかるから、そういった管理が出来る Team Foundation Server, Redmine, Trac, …等のツールを入れよう、という具合だ。
どんなメソッド・プラクティスをどういう風に使うのか？ それはどうしてなのか？を考えずに、とりあえずツールを導入して、アジャイルもどきをやっても、失敗する確率が非常に高い。そしてそんな経験をした人たちは自分たちのやり方が悪かったと思わずに、ツール or/and アジャイル開発が悪いからだと思いがちだ。というかそういう話は勉強会やセミナーに参加していてもしばしば耳にする。
ツールの導入から始めるか、ツールの導入から始めないかそれは問題ではなく、『アジャイル開発のどんなメソッド・プラクティスをどういう風に自分たちのプロジェクト、コンテキストに活用するのか？』『それはどうしてなのか？』を考えているのか、考えていないかが問題だ。
考えていれば、ツールが導入出来ない(Team Foundation Serverの様な有料のツールは使わせてもらえず、フリーの RedmineやTracを入れることが許されない)場合でも創意工夫でアジャイル開発をすることが出来る。逆に考えていなければ『ツールの導入を許可されなかったので、アジャイル開発をすることが出来ません』といった様な思考停止に陥るだけだ。思考停止に陥るか、それとも創意工夫で難局を乗り切れるか、その差はあなた自身が、考えているか、考えていないかたったそれだけの差でしかない。
