「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え

日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。

このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。

意志決定を先延ばしすること

質問　日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海外のアジャイル開発手法では、どのように設計書や仕様書を作成しているでしょうか。

Guo氏　アジャイルの中にデザイン（設計）はありません。設計があるとしても、それはアプリケーションのすべてを決定するのではなく、アーキテクチャレベル、つまり作ろうとしているものがクライアント／サーバ型なのか、リッチクライアントなのか、非機能要件をどのようにして満たすのか、といったものになるでしょう。

開発の中で必要な決定というのは、できるだけ先延ばしにした方がいいと考えます。初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。

質問　 画面のデザインはどうでしょう？ 最初はスケッチのように簡単に書いておくのでしょうか？

Guo氏　画面デザインについては、アジャイルの新しいトレンドがあります。それは、ほとんどのユーザーインターフェイス設計は前倒しにしなければいけないと、多くの企業が気がついたことです。ユーザーインターフェイスの決定は先延ばしにするのは難しいと気がつきました。

ユーザーインタラクションは重要視されていて、これは開発の初期に行われるものです。利用者からはやくフィードバックを得られるように、ユーザーインタラクションが実際に機能しはじめるように開発を行います。ユーザーインターフェイスよりも、ユーザーインタラクションはさらに複雑です。いかにユーザーがアプリケーションを使うのか、どのくらいメニューの階層を掘り下げていかなければならないかといったこと、開発者はこうした決定に長けていません。ユーザーインタラクションデザイナーといった人たちの方が優れているでしょう。

質問　お答えをまとめると、アーキテクチャ設計を作ったら細かい仕様を決めていくのはできるだけ後ろにもっていくと。そうすると2つ質問があって、細かいUIの仕様は先に決めてしまうのでしょうか。それから、開発をした人がシステムをメンテナンスするわけではないので開発に関するドキュメントも残しておきたい、という要望があります。

Guo氏　アジャイルは、アンチドキュメンテーションというわけではありません。ドキュメントがないわけではないのです。大きな違いは、デザインが進化する、ということです。ハイレベルのアーキテクチャを説明する図が（ドキュメントとして）必要なときもありますが、その知識がドキュメントによって伝わるわけではありません。

画面のデザインに関して言えば、デザインを作成したデザイナーが最後まで付き合って開発するというのが大事です。コードを書き始めた人は、なぜこのユーザーインターフェイスがそのようになっているのか分かりません。そして途中で機能が追加されるときも、なぜそのようなユーザーインターフェイスになるのか、元のユーザーインターフェイスを設計した人がいないと分からないでしょう。だから、最後まで（ドキュメントが残るのではなく）デザイナーが人として開発に残っていることが大事です。

最終的にドキュメントも最初と最後ではかなり変わると思いますが、デザイナーはそこにいる。そして開発には運用のサポートチームも一緒にいて、その工程を一緒に見ていることで、それ（ドキュメント）を再活用できる、ということになると思います。

有能な人がコードを書くべき

質問　アジャイルチームの技術者の評価はどうやっていますか？

Guo氏　多くの組織、企業文化の中ではコードを書くの仕事はいちばん底辺で、そこからマネージャになっていくことがキャリアを上っていくことになっています。しかし、これは間違いだと思います。

コードを書くというのは、例えて言えば地面にタイヤが接地するようなもので、有能な人がコードを書くべきです。賢い人がマネージャでそうではない人がコードを書く、というのは企業文化における課題だと思います。

技術者の評価というのも文化的な課題の1つです。東洋の文化は集合体としての評価が重要だと聞いています。つまり、チームの評価が（個人の評価より）優先されている。しかし西洋文化では個人の実績や評価が優先されています。過去3カ月、6カ月で評価される能力主義には、トラップがあります。

そのトラップとは、すべてを測定することはできないし、測定しやすいものだけを測定してしまうということです。例えば、書いたコードの行数が開発の評価になる。重複してたりするかもしれませんが、とにかくそれが能力を計るメジャーになる。実際には行数が少ない方が速く動くしメンテナンスもしやすいのに。しかしいまの企業文化の中ではそうやって評価されてしまいます。

そして評価されるもの以外の行動が個人にとって重視されなくなってしまいます。会議への参加やナレッジベースへの情報追加や協調性、こうしたものは数値化できません。すると、協調的なものがなくなってしまいます。

こうした文化を変えるのは大変です。チームとしての貢献度を重視する、そうすることが大事だと思います。

どれだけ変化に対応しましょうか？ と顧客に聞いてみる

質問　日本はウォーターフォールが盛んな状況ですが、それは顧客が昔からそうした契約の発注を続けていることにも一因があると思っています。自分の顧客にもウォーターフォール型の開発を望んでいるところが多くあります。こうした顧客にアジャイルを理解してもらうためのアドバイスをいただきたい。

Guo氏　これはアジャイルに関してよくある課題です。顧客からすれば、これだけ払うのでその対価としてこれだけやってもらいたい、この料金を支払えばこの機能が手に入る、という契約は、なかなか変えにくいものがあります。

可能性があるのは、顧客にビジネスのプレッシャーがかかっているときです。マーケティングや事業開発部門の人たちは要件が変わりやすいものです。「開発中にどれだけ要件の変化に対応しましょうか？」といった質問から始めるのがいいのではないでしょうか。

つまり「『これだけ払うからこの機能を作ってくれ』という契約とは違う形でお金を支払っていただければ、要件の変化に柔軟に対応できると思います」と伝えるのです。それを了解してもらったら「では、要件のなかからいま重要なものを選んでください。そこから作っていきましょう。そして出来たものを使っているうちに要件が変わってくれば、また次の段階で要件を変えていただいて構いません」としていくのです。

契約というのは、問題が発生したときにお互いを守るためのものです。失敗した場合にはこれだけのペナルティがあります、といった。こうした契約をベースにしてビジネスは動いているので、これを変えるのは簡単ではありません。

できることがあるとすれば、仕事をする人との信頼関係を築くことです。そして顧客がこの方法（アジャイル）でなら高品質なものが早くできると理解してくれれば、アジャイルを使うことができるようになるでしょう。

ベンダーと顧客のコラボレーションのあり方は変わってきているとは思います。しかし、すべてを明日違うやり方に変える、ということはできません。それは後にまわして、いくつかのプラクティスを試して、そこからのメリットを受けてみるところからはじめる、というのがいいのではないでしょうか。