https://www.publickey1.jp/blog/09/post_77.html
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。
このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。
質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海外のアジャイル開発手法では、どのように設計書や仕様書を作成しているでしょうか。
Guo氏 アジャイルの中にデザイン（設計）はありません。設計があるとしても、それはアプリケーションのすべてを決定するのではなく、アーキテクチャレベル、つまり作ろうとしているものがクライアント／サーバ型なのか、リッチクライアントなのか、非機能要件をどのようにして満たすのか、といったものになるでしょう。
開発の中で必要な決定というのは、できるだけ先延ばしにした方がいいと考えます。初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。
質問 画面のデザインはどうでしょう？ 最初はスケッチのように簡単に書いておくのでしょうか？
Guo氏 画面デザインについては、アジャイルの新しいトレンドがあります。それは、ほとんどのユーザーインターフェイス設計は前倒しにしなければいけないと、多くの企業が気がついたことです。ユーザーインターフェイスの決定は先延ばしにするのは難しいと気がつきました。
ユーザーインタラクションは重要視されていて、これは開発の初期に行われるものです。利用者からはやくフィードバックを得られるように、ユーザーインタラクションが実際に機能しはじめるように開発を行います。ユーザーインターフェイスよりも、ユーザーインタラクションはさらに複雑です。いかにユーザーがアプリケーションを使うのか、どのくらいメニューの階層を掘り下げていかなければならないかといったこと、開発者はこうした決定に長けていません。ユーザーインタラクションデザイナーといった人たちの方が優れているでしょう。
質問 お答えをまとめると、アーキテクチャ設計を作ったら細かい仕様を決めていくのはできるだけ後ろにもっていくと。そうすると2つ質問があって、細かいUIの仕様は先に決めてしまうのでしょうか。それから、開発をした人がシステムをメンテナンスするわけではないので開発に関するドキュメントも残しておきたい、という要望があります。
Guo氏 アジャイルは、アンチドキュメンテーションというわけではありません。ドキュメントがないわけではないのです。大きな違いは、デザインが進化する、ということです。ハイレベルのアーキテクチャを説明する図が（ドキュメントとして）必要なときもありますが、その知識がドキュメントによって伝わるわけではありません。
画面のデザインに関して言えば、デザインを作成したデザイナーが最後まで付き合って開発するというのが大事です。コードを書き始めた人は、なぜこのユーザーインターフェイスがそのようになっているのか分かりません。そして途中で機能が追加されるときも、なぜそのようなユーザーインターフェイスになるのか、元のユーザーインターフェイスを設計した人がいないと分からないでしょう。だから、最後まで（ドキュメントが残るのではなく）デザイナーが人として開発に残っていることが大事です。
最終的にドキュメントも最初と最後ではかなり変わると思いますが、デザイナーはそこにいる。そして開発には運用のサポートチームも一緒にいて、その工程を一緒に見ていることで、それ（ドキュメント）を再活用できる、ということになると思います。
質問 アジャイルチームの技術者の評価はどうやっていますか？
Guo氏 多くの組織、企業文化の中ではコードを書くの仕事はいちばん底辺で、そこからマネージャになっていくことがキャリアを上っていくことになっています。しかし、これは間違いだと思います。
コードを書くというのは、例えて言えば地面にタイヤが接地するようなもので、有能な人がコードを書くべきです。賢い人がマネージャでそうではない人がコードを書く、というのは企業文化における課題だと思います。