ウォーターフォールとアジャイルの共存
今回は、自分の主務について書いてみようと思います。
主務では、主にネイティブアプリや、CRMシステム開発のPMをしています。
サイバーエージェントでの開発は、基本的には「アジャイル」を得意としています。世の中の風潮的にもアジャイルが求められているのは、書くまでもないと思います。
しかしながら、ふとなんでアジャイルが大事なんだっけと考えた時に、実はウォーターフォールも大事で、役割違うだけで共存できるのではないかと思ったので、今回は開発手法であり、普段は排他的に扱われる、ウォーターフォールとアジャイルの共存の可能性を深掘り、新たな開発手法を提言できたらいいなと思っています。
そもそもウォーターフォールって何？
この疑問から始まる人も多いと思います。改めてウォーターフォールを説明すると、開発工程（下記図参照）が上流から下流へ滝のように一方通行で進む開発手法です。
この開発手法では、ユーザーやクライアントの要求を実現するために実装する機能あ性能などを定めて具体的にどう進めるかを決定し、設計、製造、テストと工程を進めていきます。すべての工程が完了すると、ようやくシステムがリリースできる仕組みです。大きな特徴として前工程が完了しないと次の工程に進めないことがあります。
メリットとしては、何を作るかが明確で、タスクも明確なので完成物の品質を確保できます。また、コストやスケジュール管理も比較的容易です。
デメリットは、出戻りが発生した際のコストが大きいことです。また、リリースまで長期化しやすく市場の変化に合わせた柔軟な機能を開発できないです。
そもそもアジャイルって何？
アジャイルの誕生背景は、ウォーターフォールのデメリットを克服するために開発された手法です。
アジャイルでは、まずチームを組んで、そのチームで開発工程を一つの小さな機能単位で繰り返し行い、素早くユーザーのニーズにあった機能をブラッシュアップしていく手法です。全機能を横断的に進めるウォーターフォールとは異なり、軽量な開発手法です。
メリットは、段階的に機能をリリースすることができる。また、開発途中でユーザとコミュニケーションを取りながらフィードバックを行うことができるため、顧客ニーズを反映したシステム開発ができます。
デメリットとしては、最初の方針を定期的に確認しないと、メリットであるはずの柔軟性が災いして開発の方向性がブレやすくなります。
その結果、プロジェクトの長期化やコストの増加、最悪の場合はプロジェクトが中止になる可能性もあります。
方針を変更するたびにスケジュールや進捗を修正しなければならないので高い管理スキルも求められます。
さて、二つの開発手法の概要が掴めたところで本題です。
これって、そもそも補完的な手法と気づいた方もいるのではないでしょうか。
つまり、共存すべくして開発された開発手法であるということです。
ただ、実務の現場の声を聞くと、これらは決して共存せず、あくまでも排他的に扱われます。
ここから、共存するシミュレーションをします。あるべき論的になりますので、ご容赦ください。
まずは、開発するものを決めます。また、それはクライアントからの要件とします。
今回は、自分の主務でもあるCRMシステムとネイティブアプリとしたいと思います。
つまり、要件としては、顧客のIDを管理し、顧客の潜在的なニーズを行動ログから分析し、それをネイティブアプリでの適切なコミュニケーションに繋げ、最終的なゴールとしてLTVの向上とします。
この開発は、全体で考えると、大規模な開発になります。なので、全てをアジャイルで開発するのは不可能です。つまり、前提はウォーターフォールで進みます。そして、ウォーターフォールの欠点が浮き彫りになったときに、アジャイルに切り替え、共存を目指します。
前提ウォーターフォールで進む理由は他にもあります。それは、前提が受託だからです。内製ではないので、品質担保をしなければいけません。それをするのにウォーターフォールは適してます。理由は、完成物の期待値が揃うからです。クライアントが何に対して、お金を払っているのかが明確になりやすいです。もっというと、スケジュールやコストが見えるので、クライアントの社内稟議も通りやすいです。
ということで、Step1は要件定義（ウォーターフォール）です。
ここで決めた要件に対して仕様変更等で後戻りすることはできません。
続いて設計です。要件定義で決まったものを、どのように実現するのかを考えていきます。ここに関しても要件がぶれることがないので、ウォーターフォールでいいと思います。ただ、ここで機能同士の依存関係を極力最小限にし、独立的に実装するための設計にする方が無難だと思います。
なぜなら、今回の要件には、「顧客の潜在的なニーズを行動ログから分析し、それをネイティブアプリでの適切なコミュニケーションに繋げる」とう文言があるからです。これって完全にアジャイルが向いてる開発ですよね。顧客のニーズは時代の流れと共に変化します。つまりアジャイルが求められます。そして、アジャイルの適した開発は、小さな機能の実装の繰り返しです。なので、機能同士の依存が多い場合は改修がこんなになります。
なので、設計の段階で、アジャイルを見越した設計が求められるのです。
ということでStep2は設計（ウォーターフォールとアジャイルの共存）です。
Step3は実装なので、ここはあまり考えることはないと思います。
アジャイルでも、ウォーターフォールでもこの工程に際はなく、定義されたものをつくからです。
テストとリリースもこれと同様です。
さて、ここまで来ると一旦アプリとCRMが完成しています。
ただ、それがLTV向上に繋がることの要件は満たしていません。（証明できていません）
ここからは、アジャイルに改善活動をしていきます。ここにアジャイルの強みが行きます。そして、プロジェクト全体で言うと、これはアプリの開発ではなく、運用のフェーズです。
余談ですが、基本的に開発とは、作って終わりではありません。作った後がむしろ始まりで、そこからどのようにそのプロダクトをいいものにできるのかが大事だと思っています。それが運用です。
開発工程をまとめると、
ウォータフォールの要件定義
ウォーターフォールとアジャイルの共存した詳細設計
実装
テスト・リリース
その後アジャイルに運用
このような形になります。
簡単に書きましたが、実はこの開発ができるの企業はあまり多くありません。
そもそもアジャイルを実施するのは難しいと言われています。なぜなら、チームに、ビジネス、エンジニア、デザイナーの三つの職種が求められ、かつそれぞれがチームとしてワークしていなければいけません。ワークとは、それぞれのジョブを理解し、チームワークが生まれ、生産性が高い状態です。
つまり、メンバーには高いスキルが要求されます。
ウォーターフォールは出戻りがないため完全に役割を分けることができるので、決められたタスクをこなすことができる人がいればいいのです。
抽象化すると、この工程は入り口に一番大きな要件をウォーターフォールで実装し、それを生かしてアジャイルに切り替える感じになります。
なので、最初はゆっくり戻ることがなく、ある閾値に達したら、素早く開発を繰り返します。
名付けて、「ジェットコースター」開発！w
最初の「ガタンゴトン」で上に上がっていくの後戻りできない、ウォーターフォールで、その後は、360°回ったり、急上昇急降下をアジャイルに繰り返すイメージです。我ながらいい名前だと思います。ぜひ使ってくださいw
ちなみにみなさんが好きなジェットコースターはなんですか？
自分はFUJIYAMAか高飛車が好きです。
以上、既存の開発手法について模索し、それらの共存の可能性について語ってみました。何かを考えるきっかけになったら幸いです。