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