アジャイル開発手法を使いこなす10のテクニック多くのソフトウェア製品開発チームが、現在アジャイル開発手法を試しているか、あるいは、つい最近アジャイル開発手法のどれかを導入したばかり、という状況にある。しろ、アジャイル開発手法には多くのメリットがあるのだけれど、そもそもカスタムソフトウェアの開発のために考案された手法なので、最初のうちは、製品ソフトウェアの開発に応用するにはどうするのがいちばんいいのか、と四苦八苦するチームも多い。この章では、製品ソフトウェアの開発環境でアジャイル開発手法を使いこなすためのポイントを明らかにしよう。以下のリストは、製品ソフトウェアを開発するチームのためのものであることに注意してほしい。カスタムソフトウェアの場合は、これとはかなり違った考え方が必要となる。あり、その製品の顧客を代弁する立場にある。製品開発チームに深く入り込む必要が出てくる。管理したり、特に、問題が出てきたら対応したりするのを手伝うのだ。プロダクトマネージャーの中には、アジャイルなら簡単に物事が運ぶと勘違いしている人がいるが、とんでもない間違いだ。プロダクトマーケティング」参照)。2.アジャイル開発手法を使うからといって、製品の開発計画はなくてもいい、ということにはならない。プロダクトマネージャー兼プロダクトオーナーとしては、どこに向かおうとしているのか、何を達成しようとしているのか、そして、どのように成功を測定するのかを理解していなければならない。言うものの、アジャイルを使っている場合は、1つの計画でカバーする期間はやや短くなるので、そうした計画のサイクルが繰り返されることになるだろう。(第11章「製品の市場性評価」参照)。2つ先行しているべきだ。これによって、時間に余裕をもって難しい機能の確認をして、改善につなげることができる。エンジニアリングチームのだれかに、それぞれの段階でアイデアやプロトタイプをレビューしてもらって、もっといいソリューションにするために、アイデアの実現可能性、コスト、見通しといったものをフィードバックしてもらうようにしよう。4.デザインの作業を、できるだけ小さな独立した塊に分けよう。家を設計するのに一部屋ずつ設計するようなことになってはいけないからだ。その一方で、製品の機能をできるだけそぎ落とすのが大事だということを忘れないようにしよう。アジャイル開発手法を使っている場合は、デザイナーは、自分がちょうどいいと感じるペースよりも速く仕事を進める必要があるかもしれないことも、覚えておいてほしい。よっては、アジャイルの方が他の開発手法よりも作業のペースに合っていることもあるだろう。これらは、製品開発チームが開発を進める出発点となるのだ。機能仕様書ではなくて、プロトタイプとユーザーストーリーがいいのだ。3つの理由から、必ずプロトタイプを作ろう。(1)実際のユーザーとテストができる。(2)問題点をとことんまで考えざるを得なくなる。(3)エンジニアリングチームにスプリントで作るべきものを示すための格好の手段となる。プロトタイプを実際のユーザーといっしょにテストしよう。作る価値のあるものにたどり着くまで、アイデアを試してプロトタイプで検証することを繰り返すのだ。スプリントのサイクルを無駄にしないようにしよう。6.スプリントをどのぐらいの作業レベルに分割するかは、エンジニアリングチームに任せよう。プロトタイプの機能は、1回のスプリントで作れることもあれば、いくつかのスプリントが必要となることもある。いいプロトタイプがあれば、実装に必要な作業量や時間を見積もるのに、ものすごく役に立つことがわかるだろう。いった分野で検討しなければならないことがあるので、機能は、彼らがふさわしいと考えるスプリントに分割させるのがいい。いう朝の会議は、コミュニケーションの始まりであって、終わりではない。その後、製品について、ひっきりなしに議論が交わされることになるだろう。デザイナーは、開発担当者や品質保証担当者に対して、製品の機能についての予備知識を仕込んでおかなければならない。デザイナー、プロダクトマネージャーといった人たちにも披露するべきだ。品質保証担当者と開発担当者は、プロトタイプの作成中に、落とし穴になりそうなところを特定して、製品開発チームが機能と設計と実装をよりうまく折り合うようにするのを手伝わなければならない。8.スプリント全部にむやみに取りかかればいいというものではない。あるスプリントの結果を再構築しよう。これならユーザーにリリースしても大丈夫、というレベルの機能性を確保するのがプロダクトマネージャーの仕事である。(第24章「ユーザーにやさしい緩やかなバージョン移行」参照)。9.それぞれのスプリントの最後には、必ず現状の製品と次のスプリントのためのプロトタイプのデモをやろう。チームのみんなにデモの結果を見せることで、チームの辛い作業がきちんと形になっていることを証明できるし、また、会社全体のスタンスを製品に反映させて、製品開発の熱意を途切れさせないようにすることができるのだ。10.製品開発チーム全員にアジャイル開発手法のトレーニングを受けさせよう。コンサルタントを雇って、チームがアジャイルに移行するのを手伝ってもらおう。そのコンサルタントは、製品ソフトウェアを開発するチームと仕事をした実績があって、製品ソフトウェアと企業内ITサービスやカスタムソフトウェアとの違いを理解している人でなければならない。チーム全員がアジャイルを取り巻く仕組みを理解していれば、プロダクトマネージャーはプロジェクトを進めることに集中できる。みんながアジャイルを理解していないと、言葉の解釈や、そもそもアジャイルとは何か、といった問題にはまり込んでしまうだろう。コラム1初期のスプリントはプロトタイプの代わりにならないか?アジャイル開発手法を提唱する人や実践する人たちの中には、製品開発チームは、初期段階のスプリントを作業用のプロトタイプとして流用するべきだ、と主張する人がいる。本来のプロダクトマネジメントもユーザーエクスペリエンスデザインも存在しないことがほとんどなので、それしかやりようがないだろう。製品ソフトウェアを開発する組織であるならば、別のやり方の方がもっとうまくできるし、また、そうしなければならない。第一に、スプリントは、作るのに時間がかかりすぎるので、アイデアを試すために待っていられない。アイデアというのは、だいたい間違いがあるものなのだ。数日で使い捨てにできるプロトタイプを使ってそうしたアイデアを試してみる方が、1つのスプリント、あるいは、いくつものスプリントのために何ヶ月も待つよりも、ずっと速い。第二に、たいていの場合、エンジニアリングチームにはやらなければならない重要な仕事が山ほどあるので、製品を見つけ出す作業に彼らを駆り出すのは無理だ。このプロトタイピングのような作業のために彼らに時間を使わせていると、正式版のソフトを作るという本来の仕事ができなくなってしまう。第三に、アジャイル開発手法は、製品開発チームが学習して臨機応変に対応していくことを大いに奨励してはいるけれど、いったん方向性が決まって、アーキテクチャやアプローチに時間をつぎ込んでしまうと、その後で大幅に方針を変更するのは困難で時間がかかることに変わりはない。コラム2アジャイル開発手法は製品ソフトウェアにも使えるか?スクラムのようなアジャイル開発手法を使えば、ソフトウェアチームを何十年間も悩ませ続けた主な問題のいくつかが解消される。多くのプロダクトマネージャーやユーザーエクスペリエンスデザイナーが、そして多くとまでは言わないけれど品質保証マネージャーも、最初のうちはアジャイルに戸惑い、自分の役割はこの手法の中ではどうなるのか、と頭を抱えている。させておくと、アジャイル開発手法では、こうした人たちの役割は間違いなく必要だとされているのだけれど、私は、アジャイル開発手法の由来のせいでこういう混乱が起きているのだと思う。その由来を説明すると、アジャイルがどういう問題を解決しようとしているのか、そしてどういう課題が残っているのかが明確になるようだ。アジャイル開発手法の中でもいちばんポピュラーなスクラムには、20年以上の歴史があるのだけれど、これを知って驚く人は多い。スクラムは、1986年に日本で生まれた。(新しいアイデアが生まれてから定着するまでは時間がかかる、ということを示す好例である。)でも、もっと重要なのは、アジャイル開発手法というのは、もともとカスタムソフトウェアの世界で生まれたということだ。特定の顧客のために特定の目的のソフトを作るというカスタムソフトウェアの世界では、ひどく厄介な作業を強いられてきた。IT部門に依頼を出したりするためだ。彼らはソフトを作る作業に取り掛かる。いざできあがると、注文した方は、必ずと言っていいほど、考えていたものとは違う、という反応を見せる。このサイクルが繰り返されて、イライラは募る一方である。IT系の開発者、カスタムソフトウェアを作る会社、企業向けサービスを提供する会社といったところが、確実に仕事にありつけているのだ。カスタムソフトウェアを開発する会社は、トップクラスのソフトウェア開発者を採用して抱えておくことに関しては、ずっと貧乏くじを引かされてきている。1つは、トップクラスのソフトウェア技術者の多くは、何百万人とまでは言わないまでも、千人単位のユーザーを対象にしたソフトを作っている会社で仕事をしたがるからである。製品開発チームが責任を持たされて大勢の人々を満足させる製品ソフトウェアを作る会社で働く方が、ずっと給料がよくて、そうしなければそういう会社は利益を上げられないからである。いう製品ソフトウェアの会社は、ヒットする製品を作るには優秀な人材が必要だとわかっているから、それなりの給料を払う。言っても、全体として見れば、実際に製品ソフトウェアのために働いているのは、ソフトウェア業界の人間のごく一握りで、大多数はカスタムソフトの仕事をしている。カスタムソフトウェアの開発モデルでは、顧客は何が欲しいのかを自分で理解していると思い込んでいるので、プロダクトマネージャーがやるべきことはほとんど見当たらない。同じように、ユーザーエクスペリエンスデザイナーがやることもないが、こちらの理由はもうちょっと複雑だ。(ユーザーエクスペリエンスデザイナーが何をするのか、なぜ彼らが必要なのかを理解している人は、カスタムソフトウェアの世界にはほとんどいない)、また、予算が厳しいこともある(開発担当者にデザインもやらせて予算を節約する)。公平を期すために言っておくと、業界内ではユーザーエクスペリエンスデザイナーは不足しているので、そういう人材は、その重要性に気付いた製品開発企業にあっという間にかっさらわれてしまって、カスタムソフトの開発チームのリーダーが必要だと気づいたとしても、チームがそういう人材を見つけるのはほとんど無理だ。同じように、カスタムソフトのプロジェクトでは、品質保証の役割も見当たらないことがほとんどで、ここでまた、開発担当者が必要なテストもやる羽目になる。ためのアプリケーションなど、社内の業務支援を目的としているということだ。ここでは、ユーザーの数は限定されているので、システムの拡張性や性能といった問題はあまり重要ではない。歴史的には、カスタムソフトウェアの世界ではウォーターフォールプロセスが採用されているけれど、それは、開発を委託されたアプリケーションが作られていく長いプロセスにおいて、さまざまな関係者がその進み具合を監視する方法が必要だったからである。実際、ウォーターフォール型開発手法もまた、このニーズから始まったものである。製品ソフトウェアの世界では、ソフトそのものが魅力的だからそのソフトは売れる、ということでなければならない。それで、幅広い顧客のニーズを代弁するプロダクトマネージャー、効果的なユーザーエクスペリエンスを作り上げるユーザーエクスペリエンスデザイナー、顧客のさまざまな環境でソフトが宣伝通りに動作することを保証する品質保証担当者、といった役割を導入することとなったのである。一方で、カスタムソフトウェアの世界では、顧客を満足させる何かを作るにはどうしたらいいのか、という製品ソフトウェアと同じような根本的な課題が残されたままであった。いう悩みを抱えたチームでは特に、アジャイル開発手法を使えば大幅な改善が可能である。顧客とエンジニアの間のコミュニケーションがよくなる。それに、小回りの利くプロトタイプを作って試すというのを何度も何度も繰り返すことによって、製品開発のリスクをぐんと減らすことができるので、顧客は、長い開発工程が終わるまで待たなくても、本当に気に入るものなのかどうかをずっと早いうちに知ることができる。ソフトウェアをテストするための最新の考え方を取り入れるのにも役に立つし、製品開発チームとしても、めったに読んでもらえないうえにすぐに使い物にならなくなってしまう書類を作るのに膨大な時間をつぎ込まなくてすむ。一般論として、こうしたことは、製品ソフトウェアを開発するチームにとっても有益であるのだけれど、私は、彼らがアジャイルを導入するときはちょっとした修正を加える必要があることを、必ず説明するようにしている。1つ苦労した分野がアーキテクチャデザインである。アジャイル開発手法は、エンジニアが実装に固執しないようにするもので、これは、リファクタリングやアーキテクチャのやり直しは、それほど時間をかけずに簡単にできると考えられているからである。このことは、大多数のカスタムソフトウェアに言えることだ。このアプローチは、多くの製品ソフトウェアや一般消費者向けのシステム、たとえば、何百万ではないにしろ何千人ものユーザーをサポートしなければならない大規模なインターネットサービスに対しては、かなりまずい。いうわけで、製品ソフトウェアを開発するチームの多くがアジャイルで大きな問題に直面するのは、アジャイルがカスタムソフトで始まったためだというのは驚くことでもない。ついても触れられていない。いうのは、そうした素材では、製品ソフトウェアを開発するチームを想定していないからである。アジャイル開発手法に移行しようとしているチームに私がアドバイスしたいのは、アジャイルを製品ソフトウェアに応用するためにはどこを変える必要があるのかをきちんと理解しているコンサルティング会社を雇うことだ。いうところはなかなかないけれど、ないわけではない。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。(15)顧客がワクワクする製品やサービスはどうやって作られるのか。eBayで製品企画担当VPを務めたマーティ・ケーガンは、その具体的な手法を著書「Inspired」に記した。出版に向けて翻訳を進行中。このサイトでは、その内容や補足情報等を紹介しています。エンジニアリングメール購読メールアドレスを記入して購読すれば、更新をメールで受信できます。現在51人フォロワーがいます。メールアドレスキャンセル投稿を送信できませんでした。メールアドレスを確認してください。メール送信チェックに失敗しました。このブログではメールでの投稿共有はできません。使用に同意したとみなされます。ポリシー%d人のブロガーが「いいね」をつけました。