アジャイル開発は、ベンチャー企業は元より、新規事業開発を手掛ける大手企業にも認知されてきました。しかし、いざ実際にチームへ導入しようとすると、アジャイル開発に対する理解にバラつきがあり、上手く進められないケースがあります。アジャイル開発が求められるようになった背景を振り返り、その価値についてもう一度考えてみましょう。
新製品を目にするまで、顧客は自分が欲しいものが分からない
何が欲しいか自分でも分からないのに発注するクライアント、理想を追求して無駄な機能まで実装してしまうエンジニア。そんな人は周りにいませんか？こういった事例はシステム開発においては珍しい話ではなく、構造的な問題を抱えているのです。
“I know that’s what I said, but it’s not what I meant!” by CNX under CC BY 4.0
システム開発を風刺した有名な漫画に「揺れるタイヤ」があります。顧客は木にぶら下がった3段のブランコが欲しいと言ったにも関わらず、プロジェクトマネージャーは一段のブランコだと理解し、さらに、プログラマーは動かないブランコを作ってしまいます。それでも営業担当者は木にぶら下がった美しいソファがあると主張します。
ドキュメントもカスタマーサポートもありませんが、請求書の金額だけはジェットコースターのように高額です。そして、顧客が本当に欲しかったのはブランコではなくタイヤだった、というオチがつきます。これは、誰かが嘘をついたわけでも、能力がなかったわけでもありません。新製品を開発する場合、顧客は自分が何を欲しているのか説明できないのです。
大衆向け自動車を開発したヘンリー・フォードは以下の言葉を残しました。「人々に何が欲しいかを尋ねたとしたら、速く走る馬が欲しいと言っていただろう」当時の一般市民にとって、移動や運送の手段は馬でした。より「速い移動手段が欲しい」というニーズは認識していても、それがどんな形態で商品として提供されるかは、新商品が開発してみなければ分からないものなのです。ここに、顧客と製品提供者の間に流れるコミュニケーションの問題が潜んでいます。そして、このコミュニケーションの断絶を防ぎ、両者を近づける手段がアジャイル開発と言えるでしょう。
タイヤではなくスケボーから作れ
“The Myth of Incremental Development” by Herding Cats under CC BY-NC-ND 3.0
アジャイル開発を説明した有名な漫画を紹介します。上段が新商品開発の悪い例、下段が良い例となっています。ヘンリー・フォードのように、一般大衆向け自動車という新商品を開発する状況を考えてみましょう。上段の例では、始めのステップで顧客にタイヤを持っていきます。「自動車という新製品で、速く自由に移動できるようになりますよ」とアピールしてみても、顧客はタイヤでは何もできないので、自動車がどういうものか理解できません。シャーシだけ見せても、ハンドルをつけてみても、やはり自動車を「運転する」という新しい概念は体感できないのです。
最終的に自動車を提供してみると、ある人は気に入ってくれるかもしれませんが、「もっと大きな車がいい」「自転車で十分だ」という声が聞こえてくるかもしれません。その場合、自動車開発にかかった時間や予算は全て無駄になります。新製品を開発するベンチャー企業であれば、資金が底をつきて倒産してしまうでしょう。より早い段階で顧客とすり合わせをする機会が必要なのです。
前述の漫画で下段にあるアジャイル開発について考えてみましょう。始めは単なるスケートボードです。自動車とは似ても似つかない簡素な商品ですが、自分の意志で好きな場所へ「運転する」という行為の体感が可能です。さらに、自動車・バイクと進化させていく過程で、顧客と開発者がニーズと商品のすり合わせができます。最終的に開発されたスポーツカーは、もともと計画された普通自動車とは異なる形態になっていますが、より顧客のニーズに近い商品を開発できたことになるのです。
最小限の機能で実証実験が行えるMVPが持つ3つの要素
アジャイル開発における”スケートボード”や”自転車”のように、最小限の機能で顧客からの感想・意見を収集できるレベルの製品をMVP（Minimally Viable Product。最小実行可能製品）と呼びます。上記の良いアジャイル開発の例から分かるように、MVPは3つの要素を備えると言われます。
- Testable（試せる）
- Usable（使える）
- Lovable（気に入る）
まず、MVPは顧客が実際に試せる状態になければなりません。悪い例にあったように、タイヤだけを提供しても自動車の価値は伝わりません。そして、自転車のように、実際に顧客が直面する状況で価値を発揮する、つまり「使える」製品が求められます。さらに、バイクのように、優れたMVPには顧客が喜んでお金を払うようになるので、開発者側は経済的に儲かる製品が作れるかどうかを確認できます。
アジャイル開発は反復的な性質を備えています。MVPを開発する過程は、徐々に機能を作りこみ、顧客からのフィードバックを受け、品質を向上していくプロセスです。初期のMVPはくだらないものに見えるかもしれませんが、反復的に開発を進め、最終的には、より多くの人を喜ばせる製品に育つ可能性が高まります。
スクラムによる効率的な反復プロセス
アジャイル開発では反復的プロセスにおける一回の試行を「スプリント」と呼びます。直訳すると、短距離走・全力疾走という意味で、短い期間で定められた機能を一気に作り上げるというニュアンスがあります。各スプリントで実行されるのは、計画・設計・実装・テスト・振り返りという一連の開発プロセスです。MVPとして”スケートボード”を開発するにしても、”動かないスケートボード”を顧客に見せてはいけません。各スプリントは機能を最小限に絞った「完成品」を構築するのです。
各スプリントを上手に回すために、「スクラム」という手法が提案されました。ラグビーの「スクラム」のように小規模チームが肩を組み、短い期間で高品質の製品開発を目指します。各スプリントは2～4週間で構成され、スプリント開始時には、そのスプリントでどの機能を構築するかを決定します。スプリント実施中は日次で10分程度の進捗報告を行い、誰が何をしているのか、どんな課題が挙がっているかを共有するのが特徴です。
スプリントの終わりには、開発された製品のデモを行い、また、スプリントがうまく回せたかどうかを振り返る時間をとります。「スクラム」のように定型化されたプロセスを辿ることで、顧客のニーズへ柔軟に対応するアジャイル開発が実現できるのです。
スクラムには様々な要素がありますが、そこに正解はありません。チームの文化や構成員のスキル・性格によって微調整する態度が重要です。また、アジャイル開発自体がその過程で顧客及びプロセスに関する理解を深めることを是としています。アジャイル開発の様々な要素を試し、効率的に顧客のニーズを叶える製品開発を行うようにしましょう。
アジャイル開発のメリット
前述した通り、顧客が何を欲しいか分からない場合でも、顧客の真のニーズを掘り起こしながら、反復的に開発を進められるのがアジャイル開発の利点です。新規事業を立ち上げるときや、顧客の要望が素早く変化する状況で、アジャイル開発の良さが発揮されます。ユーザーから頻繁にフィードバックを得ることで、より早く、ニーズに応える製品が提供できるのもメリットと言えます。また、開発の早い段階からフィードバックを集めて、品質を向上させる取り組みができることが期待されます。
アジャイル開発のデメリット
アジャイル開発は、あらゆるプロジェクトに適用できるわけではありません。例えば、既に仕様が明確になっているものであれば、要件定義から設計・開発・テストまで順に進めていくウォーターフォール開発の方が適している場合もあります。反復的に柔軟な開発を進めるアジャイル開発では、期限や予算を正確に予測するのが難しいので、正確な見積もりや計画が必要になる場面では、アジャイル開発が難しくなってしまいます。
このようなアジャイル開発の特性を、関係者全員で認識しているかどうかも、アジャイル開発プロジェクトの成否に影響します。フィードバックを収集するユーザーとの協業は欠かせません。スポンサーとなる経営層や上長も、正確な計画よりも、柔軟にニーズへ応える態度を優先するよう考え方を改める必要があります。
開発者もアジャイル開発について正確に理解しなければなりません。例えば、アジャイル開発だからといって文書化をおろそかにしてはならず、必要十分なドキュメントを残すべきです。また、ユーザーから見た機能を反復的に開発していくため、フロントエンドからバックエンドまで一気通貫で開発が進められるフルスタックエンジニアが重宝される傾向にあります。ウォーターフォール開発のような分業体制よりも、業務から実装まで理解できるエンジニアを必要な期間、確保するよう試みます。
まとめ
システム開発の世界ではまだまだ無理や無駄が多く、それは顧客にとっても開発チームにとって不幸なことです。アジャイル開発の利点と特徴を正しく理解し、自分たちに合った形で導入・学習するのが望ましいでしょう。
