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

2013年6月5日

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

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

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

James Grenning氏。

fig

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

fig

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

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

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

fig

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

fig

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

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

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

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

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

fig

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

fig

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

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

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

fig

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

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

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

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

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

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

fig

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

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

fig

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

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

fig

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

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

fig

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

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

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

fig

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

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

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

fig

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

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : XP , アジャイル開発 , スクラム



≫次の記事
アジャイル開発において、技術と品質の重要性は不可欠だ(後編)。Agile Japan 2013
≪前の記事
グローバルなクラウド市場でAmazonクラウドは突出したリーダー。シナジーリサーチの調査

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus