アジャイルにTDDしようとしてペアプロして失敗した話

これはTDD Advent Calendarの18日目。
記事としては @mao_instantlife さんの TDDやってみてコメントが減った話 のあと、@cubeon さんの きっと方眼の理から逃れられないお前たちにも告げる!テストコードを手に入れるのだ! の前となります。

最近、新しい開発手法の一貫としてTDDを採用しようとするプロジェクトが出始めている印象があります。

ただし、とりあえず取り入れてみたけれどもうまくいかなくて結局ウォーターフォール方式に逆戻りという例も多いのではないでしょうか。

以前、アジャイルにTDDをしようとしてペアプロして失敗したプロジェクトの話を聞いたことがあるので書こうと思います。

その時のプロジェクトでは数百人月前後の工数をかけてそれまであったレガシーシステムJavaでリプレイスしようとしていたようです。

それなりの規模のプロジェクトに多いように、さらに幾つかのサブプロジェクトに分けて開発をしていました。

どう考えても失敗するだろうという兆候は幾つもあったみたいですけれども、見逃されてきたようです。
伺った中でこれは〜と思った兆候を7つほど。

そのプロジェクトでは経験者が不足していたようです。ペアの組み換えは定期的に行われていたようですが、初学者のペアになってしまうことも多かったようです。その結果、途中で開発が止まってしまうことも多かったようです。ペアプログラミング以前にある程度集まっての座学、定期的な問題共有、質問会等を行うべきだったのではないかと思っています。

昔ながらの評価基準ですが、どれだけ仕事をしたのかが書いたコードの量によって評価されていました。そのため、リファクタリングが後回しにされ、大量のスパゲティーが生み出される結果になっていたようです。数万行のクラスもあったそうで。ちなみにJavaコンパイルは相互依存が増えると時間がかかるようになるようで、そのプロジェクトではJavaなのに数時間のコンパイルが必要だったそうです。コードの記載量を評価対象とするのは明らかに間違いだと思っています。コードの量に代わる評価をしてあげるべきではなかったのかと思います。ただ何をもって評価をしたほうがいいかというと定量的には難しいです。特にこれだという意見は出せず。

  • コードのコピー&ペーストが氾濫

一つ上と同じですが、自分が書いたコードの量を水増しするために同じコードのコピー&ペーストがたくさんあったようです。物によってはオープンソースなライブラリのコードをそのまま移植しただけのものもあったとか。しかも、理解できる範囲でコードの取捨選択が行われていたのか劣化コピーとなっていたようで。車輪の再発明にかかった時間がそのままコーディング期間の長期化につながっていたようです。同上ですね。

  • 自分のコードしか直さない担当者

幾つかのサブプロジェクトに別れて開発をしていましたが、他のプロジェクトにまたがる必要がある修正が必要であった場合はそれぞれのプロジェクト内で担当者を割り当てて、他のプロジェクトの修正は原則させなかったようです。そういうことを繰り返すうちにテストの大多数が壊れていくことになりました。

  • 定期的に動かなくなるテストコード

テストの大多数が壊れた結果ですね。その時点で問題だと思えればよかったのですが、参画者の一人がとりあえず動けばいいよねということで、逐次グリーンにするだけのテストの修正を行なってしまっていたようです。(つまり、仕様の妥当性を考えず、アサーションの値の書き換えでテストが通ったことにする)そのような形でテストの品質が保てるわけがなく、徐々に動かなくなっていったようです。きちんとした機能分割が行われていなかったのと、そもそもの意識として動けばいいというようになってしまっていたのが残念だなと思います。こういう状態になってしまっていたら新規機能追加を止めてリファクタリングに専念すべきであったと思います。納期は伸ばせないため決断は難しいですが。

次のイテレーションで挽回するから大丈夫!(でも挽回できない)個人的には2回続けて遅れるようだったら一度計画を見なおしたほうが良いと思うのですが、一度決めた計画は変更できず、ズルズルといってしまったようです。見なおすだけで不信を買う、計画立案がまずかったという評価になる組織だったようで仕方が無いと思いますが。見直しが行われず、さらにうまく回っているように見せかける事だけはしていたようで、気がついたときには致命的だったようです。

  • 決まらない仕様

仕様を最初に決めなくても良いウォーターフォール方式になっていたというありがちな形でした。ある程度の修正であればTDDは効果を発揮しますが、そもそもレベルでの修正となると結局一からの作り直しになってしまうのでせっかく作成したテストを生かせなくなってしまいます。あくまで小さくイテレーションするだけであり、きちんと要件を詰めていく必要があります。

ここまで7つの兆候。でも一番の問題は
  • その兆候を見逃すプロジェクト参加者

見逃したというのは違いますね。見ていたけれども、誰も意見しなかった。ありがちですが上の意見には従う、自分の意見は上の人の意見の範囲内のみで言うのが良いという人が大多数だったようです。完全に組織として死んでしまっているのですが、事実として。数十人は参加者がいたようですが、全員が兆候を見逃す、問題ないと思うなんてことはありえないと思っています。その兆候をきちんと拾い上げられる開かれた組織運営が必要なのではないでしょうか。

TDDを初めとして新しいシステム構築手法が取り入れられる場合も多いですが、以前と同様に細心の注意を払ったプロジェクト運営が必要になると思っています。高々一手法が銀の弾丸になり得るわけはないのですが、過剰な期待を持って取り入られる場合があるみたいなので、ご注意をというまとめで。

ほとんどの組織は見積方法を含めてウォーターフォール方式に併せてある程度最適化されているはずなので、TDDも含めて新しい開発手法を取り入れないというのも英断だと思います。テストフェーズが短くて済むとは言ってもコーディングフェーズは長くなるし、そもそもテストフェーズで想定数のバグが出ないというのは不信を持たれるきっかけになるかもしれませんので。システム開発が人間関係の悪化で失敗したら元も子もないです。

TDDからネタ考えたのにあまり関係なくなってしまったかなー・・・・・・