Waterfall vs Agile （リーンソフトウエア開発第二版）

もうすぐ、「リーンソフトウェア開発」の第二版がでます。もうすぐです。本当にいい本なので、内容のセミナーなどを、今年はやっていきたいと思います。今年はこれを煽っていくつもりです。業界のマネジメントを変えることが、開発現場を変えるには必要だから、マネジメントを納得させるボキャブラリで語っていきます。

中で、ウォーターフォール（本当に一方通行のものをさしています）が、ソフトウエア開発でなぜうまく機能しないか、という点をずぱっと言っている部分がありますので、引用します。（２章、原則３：知識を作り出すより。）

「ウォーターフォール」開発で不可解な点のひとつは、知識は「要求」という形式で、コーディングに先立ち、独立して存在している、という考え方である。ソフトウエア開発は、知識創造のプロセスである。全体のアーキテクチャ上のコンセプトは、コーディングに先立って大まかにまとめられているだろうが、そのアーキテクチャの検証は、コードを書きながら行うものである。実際の開発現場では、詳細な設計ドキュメントが前もって書かれている場合でも、ソフトウエアの詳細な設計はコーディングの最中に行われるものである。早期に行う設計では、実装の最中に出くわす複雑性を完全には予見できないし、実際のソフトウエア構築中に得られるフィードバックも考慮に入れられない。さらに悪いことに、早期に詳細設計を固めてしまうと、ステークホルダー（利害関係者）や顧客からのフィードバックに対応できなくなる。知識の創造に重点を置く開発プロセスでは、コーディングの間に設計が発展していく。

「知識創造のプロセス」では、詳細の具体性に入っていかないとよりよい形が見えてこないこと。そしてフィードバックを得ながら進んでいくこと。これが必要なのは、「要求開発」でも同じ。そして、同じく製造業からヒントをかりた「フロントローディング」という手法を要求開発でも模索しています。

ぼくらは、ソフトウエア開発という「知識創造活動」を仕事にしているのです。誇りをもって、この業界を変えていこう。