アジャイル開発で『動くソフトウェア』による開発を始めるために必要な考え方 まとめ

アジャイル開発は『動くソフトウェア』を元に改善を続けていくプロセスです。ただし『動くソフトウェア』に辿り着くまでには、ちょっとしたコツがあることが分かったので、ここでまとめたいと思います。

アジャイル開発においてもソフトウェアを作り始める以上、仕様を決める必要があります。いわゆる要件定義です。ただし、全く新しいものを作る場合と、古いものを新しく置き換える場合とで、やり方を変える必要があります。

新しいものを作る場合

ビジネスモデルはあるものの、それを実現するソフトウェア像はまだはっきりしない・・・新しいものを作る場合には、当然よくあるケースです。

ウォーターフォールとカウボーイスタイル

この場合、「全部決めないと開発できませんよ！」というのが一般的ウォーターフォール開発であり、「とりあえず作りながら考えましょうか！」というのがカウボーイスタイルのアジャイル開発です。前者は冷静に考えて不可能（最初から決められたら誰も苦労しない）ですし、後者は手戻りすぎて永遠にローンチできません。

リーンスタートアップスタイル

新しいものを作り始める場合は、リーンスタートアップのスタイルを採用すると上手くいきます。まず最初にビジネスモデルを実現するために必要最小限な要求を決めるのです。リーンスタートアップで言う、MVPです。MVPを決めるためには議論は惜しみませんし、逆にMVPを決めるまで開発に着手しません。

補足：MVPとは？

Minimum Viable Productの略で、ビジネスの仮説を検証するために最低限必要な製品のことです。新製品をアジャイル開発する際のイテレーションは、いわば仮説検証のプロセス（これをリーンスタートアップではBuild-Measure-Learnのフィードバックループと呼びます）なので、仮説を検証できる必要最小限のものをまずは開発します。

MVPを『動くソフトウェア』にする

MVPを決め、そのMVPに対して仕様を決め、それを『動くソフトウェア』にしてから、本格的な開発がはじまります（この仕様を決めるプロセスというのはいわゆる要件定義というよりも、UXデザインとも言うべきプロセスですが、それはまた別の話）。MVPというのはそのソフトウェアにおける最も本質的な要求を示すため、この要求を確実に捉えることで手戻りを極小に抑えます。あるラインに達したら簡単なユーザビリティテストを定期的に行なって、ユーザーがコンセプト通りの動きをするかテストします。

新しいものを作る場合は、MVPを『動くソフトウェア』にするところからがスタートです。

古いものを置き換える場合

既に動いているソフトウェアを新しく作り替えたいという要望もあります。いわゆるリプレース案件です。この場合は新しいものを作る場合と同様に進めることはできません。

既存のソフトウェアの抱える無数のコンテキスト

既に動いているソフトウェアは無数のコンテキストを抱えています。無数の細かい機能が、無数の要望によって実現され、現在に至っている訳です。お客様はこのソフトウェアと共にビジネスを成長させて来ました。ユーザーも、そのソフトウェアと一緒にビジネスを歩んできたのです。

「よし、じゃあその中から最も必要な一つのことを選んで下さい！　他は捨てましょう！」

・・・できますか？　いや、できませんよね。これをやったサービスをいくつか知っていますが、その顛末は凄惨たるものです。これは『ファイナルファンタジー』の続編で『ファイナルファイト』を作ろうとしているのと同じです。求めているのは、『ファイナルファンタジー2』なのです。

ユーザーもはじめて認識する、無意識に使っていた機能がある

過去に僕が主戦場にしていた業務システムの現場でも似たようなことがありました。ホストからERPパッケージを利用したシステムにリプレースするのですが、こうなるともうお客様から見て全く使い勝手が違うんですね。確かに仕事が楽になった部分もあるのだけど、今までの歴史がリセットされているため、細かいところが目につきます。

今まではっきりと『◯◯機能』と認識していなかったものが、実は凄く重要な機能であったことも分かってきます。

お客様「今までのこの機能はどう実現されるんですか？」

ベンダー「え、そんな業務、業務フローにありましたっけ？　・・・えっと、その業務に関してはパッケージに対してギャップになるので、アドオンする必要がありますね」

お客様「ええー、聞いてないよ！　うちの業務を考えたら、当たり前の機能でしょ！」

なかなか泥臭い話ですね。

継続的デリバリーの価値

ともかく既存ユーザーを無視して話を進められませんし、コンテキストも無視できません。なので、古いものを置き換える場合は、古いものを再現することがスタートになります。

え、それじゃ何も変わっていないじゃないかって？　古いソフトウェアが何故古いソフトウェアなのかを考えれば、価値が分かります。古いソフトウェアが問題なのは、もうこれ以上素早く改善していけない、新しい機能を追加できないような構造になっているから、問題にされるのです。これが1週間に一度新機能をリリースできるようなソフトウェアなら、誰もリプレースしませんよね？

とはいえ、再現するのは細かいUIなどではなく、基本的なモデル構造です。既存の動きを再現できつつ、更に新しい概念を追加していけるように基礎を補強します。リフォームの匠ですね。

古いものを置き換える場合は、この基本的なモデル構造を『動くソフトウェア』にするところからがスタートです。

まとめ

作るソフトウェアの種類によって、『動くソフトウェア』までの過程は異なります。新しいものを作る場合では暗黙にサービス開発の例を使いましたが、業務システムではスタートラインが異なるでしょう（ただし必ず達成すべき要求がMVPであることに変わりはありません）。

上手くソフトウェアの種類を捉えて、『動くソフトウェア』に持っていくことが、アジャイル開発の成功のポイントと言えるでしょう。