ウォーターフォールは今のビジネス速度に適さないし、開発が失敗しやすい。そのように僕はブログに書いていたし、実際そう思っていた。世の中でもXPとかスクラムとかが流行りだした頃だ。
しかし、実際にやってみるとこの難しさがよく分かった。今日はその事を技術者視点で書いて行こうと思う。
ちなみに、比較対象はウォーターフォールだ。
簡単にウォーターフォール開発とアジャイル開発の事を書いておく。（後で話がしやすいように、この記事に合わせた説明を書いておく。）
ウォーターフォールは始めに要件を固めてから開発に入る手法だ。この方法は始めに要件を固めているため、開発者に優しいと言う利点があるが後で仕様齟齬がおこりやすい。なのでプロジェクトの最後にデスマーチと言う忙しい日々が待っている場合が多い。
アジャイル開発は要件を聞いてそれをあるローテーョンで仕様策定者（使い手）に見せて行くものである。作ったものを見て舵を取れるので使い手に優しいと言う利点がある。しかしどこまでも要求が出来るため、開発も使い手もかなり忙しい。
ウォーターフォールはお客様の要求に応え難いと言う理由から、アジャイル開発が流行りはじめた。
実際、アジャイルはのれば相当気持ちの良い仕事ができる。プロジェクト期間が半年未満のものならかなり良い開発プロセスである。しかし、半年以上続くプロジェクトとなるとなかなか難しくなる。
先ほどウォーターフォールが開発者に優しいと書いたが、その最たる理由は作るものが決まっている事である。そのため、多少無茶をしても動けば良いコードが優先される。なぜなら、仕事の目的は仕様にそった動きをするものを作る事であって奇麗なコードを書く事ではないからだ。
しかし、アジャイル開発は違う。要件を聞いて動くものを作ってから、それがイメージ通りかを合わせて行く必要がある。すなわち、仕様が変わった時に即座に対応出来る汎用性が高いコードが優先される。
僕が半年未満の場合は良い開発プロセスと書いたのは、ここにある。
いつまで汎用性の高いコードを書くべきか？
これが開発者泣かせなのだ。動けば良いコードを書ける人はそこそこ居るが、汎用性に富んだコードを書ける技術者は非常に少ない。ある程度の期間を耐えれば良いのならフレームワークに頼る事で切り抜けれる。（それこそRuby on Railsはかなり汎用性に高いWebサービスが作れる）
しかし、半年位した後に「あ、その仕様ってどうなってたっけ？そこの部分ってやっぱり変えれない？」とか言われるととてもフレームワークの汎用性だけでは耐えれない。かといって、動けば良いコードを量産しているとプロジェクトが進めば進むほど開発速度が落ちてしまう。（これは、ウォーターフォールで開発して納品後や二時開発時に泣かされるので必ずしもアジャイルだけとは限らないが・・・。）
アジャイル開発で一番難しいと感じたのがこの部分だ。もう少し分かりやすく言うとリファクタリングがとても難しいのだ。
動くプログラムを作っといてと言って出来る技術者は多いが、奇麗なコードを書いてと言うと主観が入るためどれが正しいコードなのか分からなくなる。また、汎用性が高いと言う言葉もとても曖昧になってしまう。これが、アジャイル開発を行う上で一番難しい事なのだ。
動くコードは目に見えるが、汎用性が高いと言う事は目に見えずに計測もしにくいためバランスをとるのがとても難しいのだ。
僕のブログを読んでくれている人なら、これが何を示すかが分かるはずだ。
アジャイル開発はウォーターフォール以上に属人性にかかっていると言う事であり、それはマネジャーを育てる事が難しいと言う事なのだ。すなわち、プロジェクトの量産が出来ないのだ。
これを考えずにアジャイルは良いから
やり方を教えるからやってみなよ！
とは行かないのだ。
※ちなみに僕が携わっているプロジェクトはASPサービスなので、提供と開発が同時に走る為少し特殊かもしれない。しかも、プロジェクト期間はとても長い・・・。（ってか、終わりがあるのか？）
しかし、実際にやってみるとこの難しさがよく分かった。今日はその事を技術者視点で書いて行こうと思う。
ちなみに、比較対象はウォーターフォールだ。
簡単にウォーターフォール開発とアジャイル開発の事を書いておく。（後で話がしやすいように、この記事に合わせた説明を書いておく。）
ウォーターフォールは始めに要件を固めてから開発に入る手法だ。この方法は始めに要件を固めているため、開発者に優しいと言う利点があるが後で仕様齟齬がおこりやすい。なのでプロジェクトの最後にデスマーチと言う忙しい日々が待っている場合が多い。
アジャイル開発は要件を聞いてそれをあるローテーョンで仕様策定者（使い手）に見せて行くものである。作ったものを見て舵を取れるので使い手に優しいと言う利点がある。しかしどこまでも要求が出来るため、開発も使い手もかなり忙しい。
ウォーターフォールはお客様の要求に応え難いと言う理由から、アジャイル開発が流行りはじめた。
実際、アジャイルはのれば相当気持ちの良い仕事ができる。プロジェクト期間が半年未満のものならかなり良い開発プロセスである。しかし、半年以上続くプロジェクトとなるとなかなか難しくなる。
先ほどウォーターフォールが開発者に優しいと書いたが、その最たる理由は作るものが決まっている事である。そのため、多少無茶をしても動けば良いコードが優先される。なぜなら、仕事の目的は仕様にそった動きをするものを作る事であって奇麗なコードを書く事ではないからだ。
しかし、アジャイル開発は違う。要件を聞いて動くものを作ってから、それがイメージ通りかを合わせて行く必要がある。すなわち、仕様が変わった時に即座に対応出来る汎用性が高いコードが優先される。
僕が半年未満の場合は良い開発プロセスと書いたのは、ここにある。
いつまで汎用性の高いコードを書くべきか？
これが開発者泣かせなのだ。動けば良いコードを書ける人はそこそこ居るが、汎用性に富んだコードを書ける技術者は非常に少ない。ある程度の期間を耐えれば良いのならフレームワークに頼る事で切り抜けれる。（それこそRuby on Railsはかなり汎用性に高いWebサービスが作れる）
しかし、半年位した後に「あ、その仕様ってどうなってたっけ？そこの部分ってやっぱり変えれない？」とか言われるととてもフレームワークの汎用性だけでは耐えれない。かといって、動けば良いコードを量産しているとプロジェクトが進めば進むほど開発速度が落ちてしまう。（これは、ウォーターフォールで開発して納品後や二時開発時に泣かされるので必ずしもアジャイルだけとは限らないが・・・。）
アジャイル開発で一番難しいと感じたのがこの部分だ。もう少し分かりやすく言うとリファクタリングがとても難しいのだ。
動くプログラムを作っといてと言って出来る技術者は多いが、奇麗なコードを書いてと言うと主観が入るためどれが正しいコードなのか分からなくなる。また、汎用性が高いと言う言葉もとても曖昧になってしまう。これが、アジャイル開発を行う上で一番難しい事なのだ。
動くコードは目に見えるが、汎用性が高いと言う事は目に見えずに計測もしにくいためバランスをとるのがとても難しいのだ。
僕のブログを読んでくれている人なら、これが何を示すかが分かるはずだ。
アジャイル開発はウォーターフォール以上に属人性にかかっていると言う事であり、それはマネジャーを育てる事が難しいと言う事なのだ。すなわち、プロジェクトの量産が出来ないのだ。
これを考えずにアジャイルは良いから
やり方を教えるからやってみなよ！
とは行かないのだ。
※ちなみに僕が携わっているプロジェクトはASPサービスなので、提供と開発が同時に走る為少し特殊かもしれない。しかも、プロジェクト期間はとても長い・・・。（ってか、終わりがあるのか？）