１．なぜアジャイルか？

アジャイル開発が現れた背景

従来の日本の受託開発から見ていきます（図1）。

まず、「ビジネス」（事業・サービスを行う部門）が、「市場」を分析し、企画を作ります。企画を基に、開発したい要求をリストにします。それを「IT」（開発側）に発注します。要求リストを受け取った「IT」は、見積もりをして、納期までに開発、テストをし、納品します。「ビジネス」が、できあがった製品·サービスを使い「市場」でサービスを展開します。

ここには、2つの大きな問題があります。

一つ目は、「市場」「ビジネス」「IT」間を往復する時間です。市場分析をしてから、ユーザーが使うまでの時間が半年以上と非常に長いことです。サービスが「市場」に出るタイミングが遅くなることは、サービスにとって致命的です。「市場」に出た時には、市場分析時よりユーザーの受けが悪くなっている、もっと進んだサービスが世に出ているといったことが起こります。「市場」は、将棋のように一手指したら、相手が一手指す、といったルールでは動いていません。10人が一挙に、駒を突っ込む年ような戦いが行われています。「一年間がんばって、やっとできました」では、「市場」のユーザーを逃してしまいます。それが一つ目の問題です。

二つ目の問題は、「ビジネス」と「IT」に、発注、納品、という契約の壁があることです。
「ビジネス」は、最初にできるだけたくさんの開発要求を詰め込もうとします。後から要求を追加すると、最初に開発工数として見込まれていないため、「IT」から「それは別途お見積もりですね」と言われることがあります。一方、「IT」は開発要求が動かないように固定します。要求が変わると、後になればなるほど、開発上の制約が増え、納期までに要求を組み込むことが難しくなるためです。「IT」が、最終ユーザーや「市場」のことを考えずに要求（仕様書）に向かって、仕事をしていることも問題です。結果、「ビジネス」と「IT」が敵対関係になってしまうこともあります。

仕様書通りにシステムを作ることが成功ではありません。「IT」は「ビジネス」の一部であり、「ビジネス」と一体です。アジャイル開発では、「ビジネス」の成功が「IT」の成功であると定義して、その外側に「市場」があるという構造を考えます（図2）。

正しい要求は「市場」が持っています。サービスが使いやすい、使ってみて嬉しい、サービスに価値があるといったことは「市場」が決めます。「ビジネス」がいくらサービスのことを考えても正解がわからないということが起きます。

Webサービスを考えるとよくわかると思います。サービスを開発して、「市場」にリリースして、人気があれば、その機能を充実させます。人気が無ければ、その機能の開発をやめてしまいます。動くものを作って、「市場」に見ていただき、そのフィードバックを得て、次の作戦を考え、開発を行うというループを短期間に回します。

アジャイル開発の普及

2011年、起業家のエリック・リースが書いた「リーンスタートアップ」という本が出版されました。本書に書かれている方法論に、サービス開発のループの話が出ています。最初にアイデアがあって、それを素早くサービスのプログラム（コード）にします。サービスができたら、すぐに使っていただき、データを取ります。取ったデータを分析して、次のアイデアを決め、開発を行うというループです。この本が爆発的に売れたことで、「ビジネス」と「IT」という関係を一つのループの中に入れる考えが普及しました。これをきっかけに、価値の高いものから開発し、順次、リリースをするというアジャイル開発が一気に主流の開発手法になりました。2011年のアメリカの話です。

日本ではどうでしょうか？現在、日本のアジャイル開発のブームは第三の波が来ています（図3）。

最初の波は、アジャイル開発の本がたくさん出版され、エンジニアが盛り上がった2000年当初です。この時のブームは、ほとんどエンジニアの世界の出来事で、マネジメント層には受け入れられなかった時代です。例えば、アジャイル開発で実践されているテスト駆動開発について、マネジメント層からは、「テストコードを書くことで、工数が2倍になるじゃないか」と言われることもありました。実際には、すでにリリースした要求に影響が出ないように開発するには、開発中のシステムに影響が出ないことを確認しながら進めるためのテストコードが欠かせないものになります。

日本でアジャイル開発がはやり出したのは、Webのサービス企業からです。楽天、リクルート、ヤフー、クックパッドといった企業が社内にエンジニアを雇用し始めました。2010年ごろ、第二の波です。自社の外に開発を発注するのではなく内部のエンジニアと一緒にシステムを作っていきました。会社として最も重要なWebシステムですから、他人任せにせず、自社で開発を行います。

そうすることで、発注、納品といった契約の壁も無くなります。日本にアジャイル開発が増えていきました。

そして、第三の波は、2016年、2017年、最近の話です。ITの開発リソースを持っていないユーザー企業、例えば、デパートや製薬企業も積極的にアジャイル開発を取り入れ始めています。デジタルの力を使った新しいサービスを作りたいけれど、これまでの外部にシステム開発を発注するやり方では、市場に出すスピードが遅くなります。少し作って、すぐに使ってみるということが必要です。小さな開発チームにアイデアを与えて、うまくビジネスが作れるか、という実験が行われています。

例えばデパートの例です。モバイルアプリの会員となっていただいた方にどういう通知を送って、店舗に来ていただくのか、来店いただいたら、画像認識を使って年齢層と性別を判断して、その人にどういう通知を送り、どのお店に誘導するか。こういうサービスを考えるとき、きっちりした要求仕様書を書いて、システム開発を外注して、一年かけて開発するでしょうか？ベータユーザーに試してもらいながら要求を考え、使いやすいものに仕上げていくというやり方が必要です。

２．アジャイルとは何か？

従来の開発手法とアジャイル開発

それでは、要求を素早く反映させるアジャイル開発の進め方について見ていきます（図4）。

従来の開発では、開発期間の最後に動くサービスができます。例えば、一年後までにリリースしたい要求が365個あったとします。これまでの開発手法では、全体を設計して、開発、最後にテストして、サービスをリリースしていました。これでは一年後までサービスがうまく稼働するかどうかわかりません。従来の開発手法をケーキ作りに例えると、ホールケーキを作るイメージです（図5）。一層作って、クリームを塗って、また一層作って、・・最後に全体にクリームを塗って、苺を乗せます。

アジャイル開発では、まず365個の優先順を決めます。そして、例えば一週間という期間で、優先順のトップ、7個なら7個の要求をまとめて開発をします。一週間で7個の要求を実際に使えるところまで開発して、ユーザーに見ていただきます。すぐに食べられるショートケーキを一つ一つ作るイメージです。

ユーザーからフィードバックをいただぎ追加要求があれば全体の要求リストに加え、再度、要求を並べ替え、優先順の高い要求を次の一週間で開発します。従来の開発手法では、開発フェーズの後ろの方で「新たな要求を追加したい」という話が出た場合、開発側にとって悪いニュースでした。すでに全体の設計が終わっていますし、追加された要求がシステムにどう影響するかわからないためです。アジャイル開発では、いま一番フレッシュな情報に基づく要求なら、その要求を入れるべきだと考えます。しかし、これは簡単はでありません。ショートケーキに例えると、一つのショートケーキの隣に、もう一つショートケーキを作って、2つがうまく合わせられるでしょうか。アジャイル開発では、ショートケーキがうまく合わせられるよう、まずはショートケーキの足場（テストコード）をケーキの周りに作ります。テストコードにより、動作が変わらないことを確認しつつ、共通の処理となる内部構造を変えながら、次の要求を開発します。

実際に、私が社内のプロジェクトを調べてみたところ、ショートケーキ（製品のコード）に対し、足場（テストコード）が1.5倍ありました。フレッシュな要求を受け入れながら、変化に強い構造にしていくには、それだけテストが重要になります。

アジャイル開発手法のスクラム

アジャイル開発には、さまざまな手法がありますが、これからアジャイル開発に取り組むには、軽量で最も普及している「スクラム」（世界のアジャイル開発の7割で取り入れられている）からやってみるのがいいでしょう（図6）。

例えば、サービスに対する365個の要求（プロダクトバックログ）があったとします。リリース日と次のリリース日までの間隔（スプリント）を決めます。仮にここでは一週間とします。スプリント内で開発可能で、重要と思う機能を取り出します（スプリントバックログ）。7個取り出したら、7個を一週間で作ります。一週間のスプリントが終わったら、動くソフトウェア（インクリメント）ができます。日々の開発に関わる作業、問題点は朝会（デイリースクラム）で共有し、一週間の終わりにふりかえりをします。うまくいったこと、できなかったこと、次にトライすることなどを洗い出して、開発プロセスを自分たちで改善しながら進めます。ただし、スクラムのガイドブックである「スクラムガイド（日本語版）」は、わずか18ページ、チームメンバーの役割、プログラムなどの作成物、会議体などのイベントが決められているだけです。これだけでうまく開発できるかとういうと、そんなことはありません。スクラムガイドには、テストのやり方も、レビューの仕方も書いてありません。他にもアジャイル開発手法は、たくさんあるので、その中で必要と思われるプラクティスをスクラムに盛り込んで実践するとよいでしょう。

３．アジャイル開発の現場

アジャイル開発のことが少し理解できたら、次にアジャイル開発の現場について見てみましょう。

私はプロジェクトが始まる時、「プロジェクトに一つ、野球のスコアボードを作ってください」という話をします。関係者全員が同じ情報（点数、審判、ストライク・ボール・アウトカウント）を共有するということです。

お客様、上司、品証部門、どのような立場の方でも、全員が同じ状況を把握できることが重要です。これまでの開発プロジェクトでは、「今回の報告はここまでに止めておこう」「ちょっと言いにくいから、こういう言い方にしよう」といったことをやりがちですが、これではいけません。必ず透明性を保ちます。

例えば、下の写真は、タスクカンバンと言います（写真1)。

開発メンバー全員で、今週のやること（要求）を洗い出します。直近の要求を作業項目に分解して付箋に書き出します。作業項目が書かれた付箋を左端の「ToDo（やること）」に貼ります。朝会で、「やります」と言った人が作業項目の付箋を「Doing（仕掛かり中）」に動かします。作業が終わったら右端の「Done（完了）」に付箋を動かすということを一週間やります。左端にあったものが、一週間で全部右端に行けば、めでたく終了となります。非常にわかりやすいですね。

もう一つの例を見てみましょう。こちらの例には、真ん中に並ぶ付箋に小さなオレンジ色の付箋が貼ってあります（写真2)。このチームには、在宅勤務の方がいて、在宅勤務の方には連絡が取りづらいそうです。オレンジ色の付箋には、社内にバディという作業を共有している方がいて、作業が止まらないようにその方の名前が書いてあるそうです。この付箋は、この現場の工夫です。

私は大きな会社に行った時、「アジャイル開発の全社標準を作りたいので、協力してください」と相談を受けることがありますが「そういうことはやめてください」と言うようにしています。例にあるオレンジ色の付箋は全社標準からは出てきません。実際に手を動かして困っている人が、何かを発見して、自分たちで自らの開発プロセスの中に組み入れていく。これがアジャイル開発にとって大事なことです。どんどん工夫が起こっていることが、アジャイル開発がうまくいっているかどうかの指標になります。

４．品質保証

最後に、アジャイル開発における品質保証の話をします。
従来の開発では、開発したサービス品質の担保はリリース直前に行われます。アジャイル開発では、日々、要件や発生した問題の確認を当事者同士で行います。確認の過程を知らずに途中からプロジェクトに参加しても、何が起きているのかわかりません。日々の開発の中で、品質保証の話をしていく必要があります。品質保証の担当者は、サービス開発の最初からプロジェクトに入るべきです。アジャイル開発では、開発するシステムを要求変更に強くするため、テストコードの割合が大きくなります。品質保証の立場で、どういう観点でテストし、どういうテストの仕組みを構築していくか、テストしやすい構造をどう作るのか、最初から話し合っておかなければいけません。サービス品質向上の視点からのシナリオテストにどのようにテスト観点を入れるのか考えなければいけませんし、システム発注者側の受け入れテストだけでなく、開発のループにテストの仕組みを入れていく活動も必要です。アジャイル開発では、継続的にテストをし続けないと要求を受け入れにくくなり、素早くリリースできなくなります。

アーキテクチャ側のリスク、後から入ってきて困る要件は他にもあります。セキュリティの話を後にしても全体に対してのインパクトが大きすぎて取り扱えません。セキュリティが重要になるのであれば、そういう要求項目は、なるべく最初に話す必要があります。

そして、大事なことは、「私はQA（品質保証担当）／テスターだから関係ない」といった消極的な関わり方はではいけないということです。役割を超えて、関係者全員で品質に対して一緒に考える姿勢が重要です。バグの収束曲線を見て、リリース判定を行うのではなく、最初から品質保証の観点をどのように設計に入れ込むか考えることが、今のアジャイル開発の考え方です。

おわりに

アジャイル開発手法の一つ「スクラム」は実は日本から1986年に出された論文（※）が元になっています。そこには、いろんな知見を持った人たちと一緒になって開発を進めていきましょうということが書かれています。バトンリレーではなく、ラグビーのように全員で押し進めていくことから、開発手法を「スクラム」と名付けたそうです。本稿をお読みの方の皆さまは、さまざまなお立場でお仕事をされていると思います。この講演内容が、関係者一丸となって、開発を進めるということを考えるきっかけになれば幸いです。

※「The new new product development game」
https://www.agilepractice.eu/wp-content/uploads/2016/09/Product-Development-Scrum-1986.pdf

この記事をシェアする