今日の午後は、こんな研修を受けていました。テクノロジー企業の代表として、今さら「アジャイル開発 はじめの一歩」とはいかがなものかと思いますが、諸般の事情により受ける機会があり、なおかつ自分自身が、アジャイルとウォータフォールの使い分けについて色々と考えているところもあり、講師には迷惑だったかもしれませんが(笑)、仲間に入れて頂きました。
そもそもアジャイルとウォーターフォールって、何?、と思われる方がいらっしゃるかもしれませんが、いずれもシステムを開発する際の手法になります。昔から一般的なのがウォーターフォール。一方で2000年前後から提唱されるようになり、特に2010年代に入ってウェブサービスの開発などで広まってきたのが、アジャイル。ウォーターフォールは、システム全体の開発を、要件定義-外部設計-内部設計-コーディング…のように工程にわけ、これら工程を段階的に進めます(工程図が滝のように見えるためウォーターフォールと呼びます)。特に大規模/複雑なシステムについては、全体の整合性をとりやすいといったメリットがありますが、一方で、実際の成果(動くソフトウェア)が出来上がるのがかなり後工程になる(さらにその際に、これは希望したものと違うとなるとやり直し)という課題も存在します。
一方でアジャイルは、動くソフトウェアを早期に生み出すことを重視しています。そのために、システムを複数の小さな機能に分割し、短期間で開発することを繰り返すことにより、動くソフトウェアを早くリリースし、それを継続的に改善するアプローチを取ります。
弥生のグループ会社であるMisocaは、アジャイルでの開発を行ってきています。一方で、弥生自身はどちらかと言えばウォーターフォールより。とはいえ、弥生も、イテレーションでの開発(機能を分割し開発することを繰り返す)、TDD(テスト駆動開発、設計の段階からテストコードを作成)、CI(Continuous Integration、ビルドとテストを随時自動実行)など、アジャイルの手法の多くを取り入れています。
私がモヤモヤとした違和感を持っていたのが、アジャイルに対するウォーターフォールという対立構造。確かにアジャイルは、ウォーターフォールに対する問題意識からスタートした歴史がありますので、こういった対立構造と捉えられがちです。また、アジャイル派もウォーターフォール派も、自分たちこそ正義という極端な主張をするケースがあり、これが対立構造に油を注ぐことがあります。しかし私は、これらは実際は二項対立ではないと考えています。アジャイルにはアジャイルの良さがあるし、ウォーターフォールにはウォーターフォールの良さがある。さらに、アジャイルとウォーターフォールを組み合わせることによって、それぞれの良さを組み合わせることも可能(ただし、注意しないと、それぞれの課題を組み合わせることになりかねません)。
今日の研修でも直接的にこういった質問もしたのですが、講師の方も同様な見解でした。
アジャイルでは、一般的にコストや納期を固定して、スコープ(開発対象)を可変にします。逆に言えば、スコープが可変にできるプロジェクトにこそ、アジャイルの良さが活きてきます。弥生の場合は、開発対象の多くを必達である法令対応が占める、つまりスコープを可変にできないため、アジャイルの良さを活かしにくいという現実があります。ただだからといって、アジャイルを否定することもありませんし、アジャイルと相容れない訳ではありません。実際問題として、管理を容易にし、開発リスクを下げるというメリットがあるからこそイテレーション開発を行っている訳ですし、品質を作りこむためにTDDを採用しています。
まだまだ試行錯誤ではありますが、今後さらに経験を積むことで、プロジェクトの性格にあわせ、アジャイルとウォーターフォールそれぞれの良さを引き出すように、うまく組み合わせていければいいと考えています。
