理想のアジャイル開発から流行りのアジャイル論争に参入してみる

f:id:nigohiroki:20130328230252j:plain

最近アジャイル開発に関するブログを数多く見るので便乗して考察してみます。

アジャイルがダメだと思う7つの理由 - arclamp
ことの発端はこちらのブログ。
ここから様々な人が論争を繰り広げられています。
(エントリーは3/21　確実に乗り遅れていますが…笑)

アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
こちらの人がまず最初に反論のようなブログを書いたみたいです。

というわけで自分の意見なのですが、
結論からいうと
「WEBサービス・アプリケーションにはアジャイル開発が向いていると思う!!」
っていうのが自分の意見
というわけでその理由をいくつかに分けて書いていこうと思います。

そもそもアジャイルとは?
アジャイル参考書
理想のアジャイル開発
まとめ

こんな感じで書いていきます。

そもそもアジャイルとは?

元々は
agility -敏捷性・機敏さ
という語源から。
何を思って敏捷性なのか。
それは「変更に対して敏捷性がある」
というのが本質と考えます。

つまり
!!突然の仕様変更!!
みたいなのに強いわけですね。

一方比較されがちなウォーターフォールモデル
これはかなり
!!突然の仕様変更!!
に弱いモデルです。

いきなり特徴から伝えてしまいましたが、
もう少し詳しい開発プロセスを見ていくと、

アジャイル

機能ごとに要件定義
機能ごとに設計
機能ごとに開発
機能ごとにテスト
1に戻る

を繰り返して開発。(もちろん大まかな要件定義は初めに決まっているという前提で)

ウォーターフォールモデル

ガッツリ要件定義
ガッツリ設計
ガッツリ開発
ガッツリテスト

という開発。
なので開発中に要件定義をやり直すということはありません。(実際はわからないけど)

なんで自分なりの解釈としては
「ウォーターフォールモデルの各項目を細かくして、繰り返すことで開発していく手法」
と一言でいう感じです。

アジャイル参考書

参考図書としては

アジャイルサムライ−達人開発者への道−

作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
出版社/メーカー: オーム社
発売日: 2011/07/16
メディア: 単行本（ソフトカバー）
購入: 42人クリック: 1,991回
この商品を含むブログ (231件) を見る

こちらが有名ですね
以前記事書いてました(アジャイルサムライから色々学ぶ - nigoblog)

というわけで最初の説明でわからない人がいればこちらを参考に

理想のアジャイル開発

というわけで本題といきます。
完璧に開発を任せてくれるのならばこうしたいなという理想です。
まずはその条件から

ビジネスモデルまたは解決する問題が決まっている
MVP(Minimum Viable Product)が決まっている
ディレクションに専念するエンジニアがいる
チームメンバーは全員エンジニアリングが出来る

というわけでこれが理想なのですが、この時点ですでに夢物語に近いですね。

では1の説明の前に2から先に説明します。

MVP(Minimun Viable Product)が決まっている

そもそもMVPってなんだろうって話しなのですが、
簡単にいうと
「最低限公開出来て、かつユーザーが使ってそのフィードバックが得られるレベルのプロダクト」
って感じ。
もっと短くいうと
「最低限公開出来るレベルのプロダクト」
だと思っております。

つまりいきなり完璧を目指して開発を始めるなってこと。
完璧ではないにせよ、人の目に出して恥ずかしくないレベル
そういうプロダクトを目指しましょう!
っていうのがアジャイル開発の第一弾。

何回目かのループでここまで行くっていうのでも良いかと思うのだけど、
とにかくこれが決まらなければリリース日はどんどん後に行っていきます。確実に。

ビジネスモデルまたは解決する問題が決まっている

そもそもWEBサービスって稼いだり、困ってる人を助けたり。楽しんだり、そういうためにあります。
その稼ぎ方や助け方、楽しみ方がわかっていなければMVPを作った後に止まってしまいます。
ここで出てくるのがKPI(Key Performance Value)という指標。
仮に目的が稼ぐためなら
KPIは売上とか利益とかになります。
このKPIこそがアジャイル開発の鍵となります。

さらにこのKPI、時期によって変わってきます。
最終的にKPIが売上、利益だとしてもいきなり作ったばかりのプロダクトではイメージがつかないと思います。なのでその一歩手前、仮に売上が

売上 = ARPU x UU

だとしたらARPU、もしくはUUを上げる。
などのようにKPIの構成要素を考えていきます。
そして細かに分解したその先を上げるために、次のアジャイルのループが始まります。
具体例を出すと、
UUを上げるために新規ユーザーが必要

UU = 総登録者数 x アクティブ率
総登録者数 = 新規ユーザー + 既存ユーザー - 退会ユーザー

という感じになるでしょう。
ここで「UU」を上げるためには「総登録者数」もしくは「アクティブ率」を上げる。
とりあえずここは「総登録者数」を上げましょう。
次に「総登録者数」を上げるためには「新規ユーザー」を上げるか、「退会ユーザー」を下げるか。
ここでは「新規ユーザー」を上げるという選択をします。
そこでアジャイル

新規ユーザーを上げる機能の要件定義
新規ユーザーを上げる機能の設計
新規ユーザーを上げる機能の開発
新規ユーザーを上げる機能のテスト

というプロセスが入ります。
ここで無事「新規ユーザー」を上げることが出来れば次の機能を開発します。
ポイントは、KPIがうまく上がらない時は別の方法を考えるなど、すぐに転換が必要です。

ディレクションに専念するエンジニアがいる

上記を見ても分かる通り、KPIの分析は開発者以外のリソースが必要です。かなりしんどいので。
なので出来ればそこに専念するエンジニアがいるべきだと考えます。

もしくは代替案として

チームメンバーは全員エンジニアリングが出来る

仮に専念出来る人がいなければアジャイル開発の各プロセスをみんなでやっていけばいいじゃない。
という考え方。

なぜ全員エンジニアリングが出来るのが理想かといいますと、
非エンジニアは夢物語を語る上にその工数(どれだけかかるか)がまるでわからないからです。
エンジニアならばブレストの段階である程度「これは出来そうだな」と考えながら議論します(そのせいでスケールしないこともしばしば、ここは良くない所でもある)
なので明らかにそれは出来ないでしょうよ。とかめちゃくちゃ時間がかかるぜそれというような案がなくスッキリ決まります。まためちゃくちゃ時間がかかるものもそれをわかりつつ話すので、後に工数算出が楽になります。

そして何より、共通言語が多い!

プログラミング言語の話しではなく技術用語でいちいち止まらないから楽ですねすごく。

というわけで以上が自分の考える理想のアジャイル開発でした。