アジャイル開発において、技術と品質の重要性は不可欠だ（前編）。Agile Japan 2013

年に一度行われるアジャイル開発のイベント「Agile Japan」が今年も開催されました。今年の基調講演は、アジャイル開発の中で品質の重要性をあらためて位置づける目的で、James Gernning氏が「“Demand Technical Excellence”アジャイルにおける技術と品質の重要性」という題で行っています。

アジャイル開発とは、単にすばやく柔軟に開発する手法なのではなく、そこに品質を作り込んでいくことが欠かせないのだ、というメッセージでした。非常に多くの内容が詰め込まれた講演でしたが、その概要を記事として紹介しましょう。

“Demand Technical Excellence”アジャイルにおける技術と品質の重要性

James Grenning氏。

今日お話ししようとしているのは「技術的卓越性を求めて」（Demand Technical Excellence）です。

その前に、私がアジャイル開発に関わった経緯について触れておきましょう。

1999年当時、私はRobert Martin（著名なソフトウェアコンサルタント）の会社で働いていて、彼からSnowbirdで「Lightweight Methods Summit」があるから来ないか？ と誘われました。

Snowbirdといえば有名なスキーリゾート地で、そこでスキーができるぞ！ と思って行くことにしました。

そこで行われたのが「アジャイルソフトウェア開発宣言（Manifesto for Agile Software Development）」です。

ソフトウェア開発の中心とはコードであり人である

このアジャイルソフトウェア開発宣言以前に有名だった本が「Managing the Software Process」です。当時、プロセスがしっかりしていればそこで働く人が誰だろうと関係ない、と考えられていました。この本の著者はそんなことは書いていないのですが。

それはつまり、ソフトウェアの開発では、UMLがしっかり書ければ、あとはそれを中国やインドに送り、安いプログラマを使って開発できると考えられていたのです。

そこに登場したのが「アジャイルソフトウェア開発宣言」です。この宣言では、いちばん最初に「人」のことが書いてあります。「人が」がいちばん大事な点だと。

ソフトウェア開発の中心とはプロセスとドキュメントではなく、コードであり、人が一緒に働くことであり、プロダクトにフォーカスすることなんだと。

アリスタ・コバーン氏曰く、プロセスは人の重要さと比べると大したことはない。いい人さえ集まれば、彼ら自身がプロセスを作ることだってできるんだと。

私は、エンジニアとしてはプロセスは重要だと思っています。XPのプラクティスをみると、すごくいい、ロジカルだと思う。でも、XPはそれほど多くの人に採用されたわけではありませんでした。

スクラムは継続的改善を行うためのメカニズム

スクラムはとてもポピュラーになりました。スクラムとはなんでしょう？ スクラムを作ったKen Schwaber氏によると、スクラムは新製品開発のゲームのルールとしての、シンプルなフレームワークだと。

そしてスクラムは、システムや製品の開発における組織の能力不足をあらわに、見えるようにします。スクラムの意図とは、それを見えるようにすることで組織自身がそれを改善することにあるのです。

スクラムを作ったもう一人のJeff Sutherland氏は、スクラムを使うことで平均の5倍から10倍の生産性になることもあると言っています。

しかし残念なことに多くの組織が、スクラムで組織を改善するのではなく、スクラムのやり方を悪いところに合わせて調整してしまいます。それではうまく行きません。

そうではなく、スクラムは継続的改善を行うためのメカニズムなのです。

技術的卓越性はバグをつぶすことではない

アジャイルソフトウェア開発宣言から10年後、Snowbirdで10周年のお祝いをしようとメールが来ました。

そこで話し合われたことのうち、この2つが、今日の大事なテーマです。

1つは技術的卓越性を重要視すること。もう1つは個人の（変化の）重要性を尊重しながら、組織変革をリードすることです。

技術的卓越性を重視し、求めるだけでなく、それをどう実現するか。自分が代わらなければいけないし、組織も変わるように自分が活動しなければいけません。

例えば、スクラムの最後のスプリントをを品質向上に当ててバグをつぶすことにする。どうなるか。問題が起こってプロジェクトが炎上しますよね。そしてずっとデバッグをし続けることになります。

技術的卓越性を追求することは、バグをつぶすことではありませんよね。

そこで私は、スクラムとXP（eXtreme Programming）の結婚を提案します。これは私が最初に言い出したことではないけれど。

大事な時間をデバッグに使われないようにする

私は仕事でたくさんのデベロッパーをトレーニングしていますが、トレーニングの前にデベロッパーに質問することがあります。それは、コーディングとデバッグにかける時間の割合です。デベロッパーにとって価値を作り出しているのはコーディングであり、デバッグはオーバーヘッドです。

しかしこの図を見ると、いちばん上の人は90％もデバッグとテストに時間を使っています。価値を作り込む時間がわずか10％しかないのです。

彼らはデバッグをどうやっているかというと、例えばプリント文を入れる、シングルステップの実行をしてみる、とか。こんな技術は私がプログラミングを始めた1979年からあって、それをまだ2013年になってもやっています。

最後にデバッグするのを「デバッグレイタープログラミング」と呼ぶとすると、このデバッグにどれだけ時間がかかるのかは誰も分からない。しかもバグを直すと別のバグがでることさえあります。

これは最初に開発をして、あとからデバッグしようというプロセスに問題があるのです。だから、スクラムとXPの結婚を提案するのです。

≫後編に続く。後編ではテスト自動化はなぜ必要なのか。デベロッパー、マネージャ、スクラムマスターが考えなければならないことなどが語られます。