リーン ソフトウェア開発(その2)

| | コメント(0)

第2章 学習効果を高める

どういうわけか、可変性は悪であるという考えがソフトウェア開発に入り込んでしまった。ソフトウェア開発では、可変性をおさえ、毎回繰り返し可能な成果を得るために、標準化されたプロセスを作りだそうとしてきた。しかし、開発は繰り返し可能な成果を生み出そうとはしていない。開発とは、それぞれの顧客の問題に適した解決を作りだすものなのだ。

今日では、設計は、調査、実験、結果確認を短いサイクルで繰り返すことを通じて解を発見するという、問題解決のプロセスであることが広く受け入れられている。ソフトウェア開発は、あらゆる設計と同じように、そのような学習サイクルを通して行われるのが一般的である。

ソフトウェア開発の思考には二つの流派がある。一つは、開発者に、最初から確実に設計やコードを一つひとつ完璧にするように、と奨励する流派である。もう一つは、最初から設計やコードを確実に完璧にするよりも、小さく、迅速に試し、テストをし、失敗すれば正しくするというサイクルで進めた方がいい、という流派だ。前者の流派では、経験によって知識を得るのではなく、知識は熟考とレビューによって得られるものと信じている。最初から正しく進める前者の手法は、良構造問題に関してはうまく機能するだろう。しかし、試し、テストをし、直すという後者の手法が、悪構造問題には適している。

リファクタリングをともなったイテレーション、つまり、システムを発展させながらの設計改善は、知識を獲得し、早く答えを見つけだし、統一性のあるシステムを作り出すための、最も効果的な方法の一つであるとわかっている。

仕事をするのなら、それは、「直接顧客」のための仕事でなくてはならない。すなわち、だれかがどこかで、その仕事の成果を待ち望んでいる、という状況でなくてはならない。開発者は、直接顧客を知っているべきだし、その顧客が定期的なフィードバックを返せる方法を用意すべきである。問題が起きたら、最初にすべきことはフィードバックループがすべてうまくいっているかどうかを確認することだ。つまり、各自が自分の直接顧客がだれなのかを知っていることを確認する、ということだ。次にすべきことは、問題領域のフィードバックループを短くすることだ。

あらゆるアジャイルソフトウェア開発手法にも、あらゆる場面で適用するスタート地点がある。それは「イテレーション」だ。イテレーションは、ソフトウェアを設計し、プログラムし、テストし、統合し、提供するための、長さを固定した短いサイクルだ。製品開発でのプロトタイプと非常によく似ているが、イテレーションは最終的な製品の一部を、きちんと動作するように作りだすという点が違う。そのソフトウェアは、後のイテレーションで改善されることになるだろうが、最初からきちんと動作し、テストもされ、統合されてもいるのだ。イテレーションによって、シークエンシャルソフトウェア開発に比べてフィードバックの量が劇的に増加する。そして同時に、顧客やユーザーと開発者の間の、また、そのシステムに関心を持ついろいろな人たちの間のコミュニケーションが大幅に増加する。テスターは最初のイテレーションからプロジェクトの参加し、ハードウエアやソフトウエアの環境も早期に考慮される。設計の問題点は早期に見つかり。変更が入るごとに、変更に対する耐性がシステムに組み込まれていく。

ビジネス価値が最も高い機能を先に提供するため、最優先の機能から先に開発するべきだ。リスクの高いものは、後になってからではなく、早いうちから注意を向けておくべきだ。

スタンディッシュ・グループの研究によれば、典型的なシステムの機能のうち、45パーセントは一度も使われることがなく、19パーセントはほとんど使われることがないそうだ。プロジェクトが始まる時点で、顧客が自分の欲しいものを正確に知っていることはめったにない。そのため、彼らは必要かもしれない機能をすべて求める傾向にある。要求を出すチャンスが一度しかないと思えばなおさらだ。この方法をとると、私たちの経験上、プロジェクトの全体的なミッション以上にスコープを広げてしまう可能性が非常に高い。顧客にプライオリティが最も高い機能だけを要求させ、それをすばやく提供し、それから次にプライオリティの高い機能を要求させれば、重要機能のリストは短くなるはずだ。また、変化していく顧客の事情に対応することもできる。そのため、機能をプライオリティの高い順に並べ、上から順に手をつけていくのがいい。一般的に、この戦略を使えば、確保されたリソースがなくなるまでに、全体的なミッションを達成できるはずだ。

イテレーションは、実現可能な解決の一実証例としてとらえるべきであり、唯一の解決としてとらえるべきではない。早期のイテレーションでは、システムの残りの部分を、実現可能性のある多くの方法で実装できるように、幅広い余裕を残しておくべきだ。イテレーションが進み、さらに選択されていくにつれ、設計の余地は徐々にせばめられていくべきなのだ。

カテゴリ

コメントする

このブログ記事について

このページは、Hiroshiが2007年10月23日 09:10に書いたブログ記事です。

ひとつ前のブログ記事は「リーン ソフトウェア開発(その1)」です。

次のブログ記事は「リーン ソフトウェア開発(その3)」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 4.0