実際のアジャイル開発

　今回はアジャイル開発の誤解で書ききれなかった事を書きます。アジャイル開発の経験者は知っていると思いますが、アジャイル開発で作られていない既存システムを、アジャイル開発でやり直すのは困難です。アジャイル開発をよく知らない人は、新規開発や受託開発はアジャイルに向かないと考えているようですが、事実はその逆です。
　ウォーターフォール開発モデルで作られたシステムの大半は、過剰装飾された文章が大量にあるだけで、肝心なユニットテストのコードがありません。この状態は、アジャイル開発の実践者にとって、最悪だと感じる状況です。レガシーコードと開発の役に立たない文章の山は、アジャイル開発の障害とすら言えるかもしれません。
　何故、テストコードがないレガシーコードが駄目なのかと言いますと、リファクタリングが出来ず、コードを把握するのに時間がかかるからです。この状態でアジャイル開発を行うのであれば、全てを捨て去り新規開発をした方がましだと考える人も多い事でしょう。かくいう私も、一度は新規からやり直す事を勧めます。しかし、大半の会社は捨てるのを惜しむので、その願いはかないません。ですから、アジャイル開発の実践者にとって嫌な状況なのです。
　特にC言語のレガシーコードは扱いにくい。Cのレガシーコードは絡み合っている事が多く、ユニットテストが行い難い厄介な代物です。この時点で、開発スピードが落ちる事が確定しています。アジャイル開発を知らない人は、普通の開発だと思うでしょうが、アジャイル開発で迅速に開発をしてきた者にとっては、苦痛以外のなにものでもありません。アジャイル開発は速いリズムが大事なのですが、それが崩されるので、作業進行が非常に鈍く感じて苦痛になるのです。
　では、アジャイル開発が既存のシステムの更新に向いていないのかと言いますと、そうではありません。レガシーコードは保守が高く付きます。レガシーコードを保持する会社は、知らないうちにコストとリスクを抱えている事になります。そのコストを、アジャイル開発をする事により軽減するのは、ビジネス的な観点から言っても合理的な行動です。全てのレガシーな生産物を、アジャイルなものに変える事は不可能ですが、徐々に変える事が出来ます。
　次に受託開発について言及します。結論から言いますと、アジャイル開発は受託開発に向いています。その理由は、アジャイル開発はコミュニケーションとフィードバックを重要視するからです。受託開発ではそれが可能なので非常に向いているのです。
　長くなったのでこれで終えますが、これからもアジャイル開発の本当の姿をお伝えしたいと考えております。