コミュニケーションと品質保証

ウォーターフォールという昔ながらのソフト開発手法も、アジャイルという最新のそれも、コミュニケーションと品質保証の為の決めごとであることは共通している。

品質保証とは「このプログラムにはバグがありません」という嘘をなぜつき通せるかという理由であり、コミュニケーションとは開発者の頭の中で何が一致しているべきかという指標である。

両者の相違点は、この二つを瞬間的に濃密にやるか継続的にやるかだ。ウォーターフォールは、設計の区切りとテストの時、瞬間的に濃密な最高レベルのコミュニケーションと品質保証をしようとする。アジャイルは、コミュニケーションと品質保証を継続的にやろうとする。

もうひとつの違いは、ウォーターフォールがコミュニケーションと品質保証を主としてドキュメントでやろうとするのに対し、アジャイルはプログラムのコード自体でやろうとすることだ。

コミュニケーションをコードでやるのは、正しく書かれたコードは、自然言語や図より表現力が高いからである。コードの言語としての表現力が部分的にでも自然言語や図を上回ったのは、オブジェクト指向言語以降のことであり、だから、アジャイルとオブジェクト指向言語は密接なつながりがあるが、本質的なつながりはそこだけである。

そして、プログラミング言語の歴史の中で、そこに大きな断絶がある。これを認識しないとアジャイルは理解できないのではないか。

オブジェクト指向言語の表現力は自然言語を上回っていて、コミュニケーションのツールとして、ドキュメントより優れている。例えば、CVSのコンフリクトをコミュニケーションのひとつと考えることができる。リポジトリを通じて、プログラマーはソースでコミュニケーションをしている。コンフリクトが起きたら、その二人は話をする必要がある。CVSサーバは一種の出会い系サイトだ。話をすべき二人が出会うようにできている。コードの表現力が高いのでそういうことが可能となる。

このように、アジャイルを「コードを通じたコミュニケーション」ととらえると、それなりに首尾一貫したものに見えてくる。

とは言ってももちろん、「コードを通じたコミュニケーション」も万能ではないので、それを補う為に、モデリングがある。eXtreme Programming = XPの次が、Agile Modeling = AMであるのはそういうわけだ。AMにおいて、ドキュメントの体系が決定的でないのは、中心にソースがあって、どうしてもそれにおさまらない所を、モデルが引き受けているからではないだろうか。

品質保証を重視するのはどちらも同じだが、その為にプログラマの個性、自律性を抑制する必要があると考えるのがウォーターフォールで、ユニットテストさえあれば、プログラマの個性、自律性が最大限に発揮できるというと考えるのがアジャイルだ。