アプリ開発における開発手法の話。アジャイルやウォーターフォール開発という二大開発手法があるが、どのように選定したら良いだろう。
仕事だけしてても楽しくない。自分が作りたいものを自分で作る。それってすごく楽しそうではないか。
今回は一般論を交えつつ、開発手法を決めていこう。
前提
開発手法として「ウォーターフォール開発」「アジャイル開発」が存在している。それぞれメリットとデメリットがあり、どちらが優れているとかはあまりない。また両方取り入れたりといったものも存在する。
今回はそれぞれのメリットデメリットをまとめつつ、自分の開発手法を選んでいく。
ちなみに私は会社では両方経験済みである。
ウォーターフォール
概要
ウォーターフォールとは、昔からあるソフトウェア開発手法の代表といってもいい手法である。
「要件定義」「外部設計」「内部設計」「プログラミング」「テスト」「リリース」といった工程を順番におこなっていく手法である。
メリット
大きくあげると以下の3点くらいかなと思います。
- 計画が立てやすい
- 担当者の入れ替えがしやすい
- 品質評価しやすい
計画が立てやすい
ウォーターフォール開発では、全体を掴んでからそれぞれの工程を分けます。そしてそれぞれの工程にこの期間かかるなどの工程を設計します。そのため最終納品がいつで、ここまでに試験を終わらせて、などの計画が立てやすいです。
担当者の入れ替えがしやすい
ウォーターフォールは工程ごとにしっかりとアウトプットがあり、それが次の工程のインプットとなります。工程ごとに担当者が変わっても前工程のアウトプットがあれば、作業を行えるというわけです。
設計はこのチームがやって、実際にプログラミングは別チームで実施などができるわけです。
品質評価がわかりやすい。
これは工程ごとに成果物のドキュメントがあるため、この工程でどれだけの文書を残したか。どれだけレビューを行なったかなどの評価を工程の間に挟むことができます。
デメリット
デメリットは以下のような点があげられます。
- 要件の変更がやりづらい
- 成果物の作成に時間がかかる
- 計画の変更に時間がかかる
- ユーザーに届くまでが遅い
要件の変更がやりづらい
当たり前ですが、要件定義は最初のフェーズです。設計やプログラミングを行う上で検討漏れ等があったり、やっぱりこうしようという途中の変更が入れづらいです。
もちろん途中で入れ込む場合もありますが、再度設計して、プログラミングして試験してと、上流からの手戻りも発生し、計画も立て直さないといけません。
成果物の作成に時間がかかる
各工程でドキュメント化したものを出さなくてはいけないので、作成するものが多くなります。
次の担当者にわかるように書いたり、実際には不要なものまで作らなくてはいけないかもしれません。
計画の変更に時間がかかる
基本的にプロジェクトは問題があったりすると遅れます。もちろん問題が起こることを想定してある程度マージをとったスケジュールでも、遅れるものは遅れます。
その度に計画の線を引きなおさなくてはなりません。計画の線を引きなおす時間も勿体無いし、一旦引きなおしたからといってそれがうまくいくかもわかりません。
ユーザーに届くまでが遅い
要件定義をしてから動くものが出来上がるまでに、全工程を通過しなくてはいけません。
要件定義の時にユーザーのことを想定してあれこれ考えるのですが、実際に動くものをみたらユーザーはまあ不便だとかこうしてほしいがいっぱい出てきます。
頑張って長い時間かけて作ったのに、ユーザー目線で価値があるものとならない可能性があります。
アジャイル（スクラム）
概要
アジャイル開発とはウォーターフォールと違い、短い期間で、機能ごとに分けたものをリリースしていきます。どんどん後から機能をつけてアップデートしていくようなイメージです。
試験も設計もプログラムも、短い期間で
アジャイルにもいくつか手法がありますが、今回は私がやったことのある、スクラムという方式を中心に語ります。
メリット
メリットは以下のような点があげられます。
- 変更に強い
- 不具合対応が早い
- 優先順位の高いものからリリースできる
- 改善が回しやすい
- 不要な成果物を極力作らなくて良い
変更に強い
アジャイルでは短い期間で、リリースを行います。ウォーターフォールに比べると、変更があった場合は次のリリースで入れよう。などと簡単に行えます。また開発途中で要件が変わったら、優先順位の高い要求から開発するので、変更に対して、正しく優先順位付けすれば、変更もこわくありません。
優先順位の高いものからリリースできる
アジャイルでは優先順位の高いものからリリースしていく方針です。機能を洗い出して、必要な機能からどんどん実装してリリースをしていきます。
つまり優先順位の低い機能に関しては、どんどん後回しにされるのです。ヲーターフォールは作ったけどいらない機能が出てしまうのに対して、アジャイルでは、必要な機能しかリリースされません。
不具合対応が早い
ウォーターフォール開発では、不具合が出た際に、今は別のフェーズだから工程が遅れてしまう、、、などがあります。それに比べてアジャイルでは毎回機能ごとのリリースです。今回のリリースは不具合対応についてリリースしよう！と決めてしまえば、いつでも不具合対策に入れます。
改善が回しやすい
短い期間で開発が一巡します。一巡したら振り返りと次回への改善などを話し合えるので、どんどん改善を回せます。ウォーターフォールでは長いきかんで一巡するので、改善の機会がかなり少なくなります。
不要な成果物を極力作らなくて良い
アジャイルでは動くコードというのが一番重要です。リリースできる形に毎回持っていくので、動くものか一番重要というわけです。
もちろん設計のドキュメントも必要ですが、誰かが使うかもしれないから念のため書いておこうなどのものは後回しにされます。ドキュメントを多く作っても、結局誰も読まないなどはよくあるはなしですが、それがかなり防ぐことができます。
デメリット
- 全体像が見えない
もちろん基本方針は決めたり、最終リリーすなどは決定しますが、ウォーターフォールほどかっちりしたものではありません。そのため、全体像が見えにくくなります。
- コンセプトがブレる
よくも悪くも想定からかなり変化します。作ってリリースを繰り返していると、動くものに対してさまざまな意見が出ます。そのためコンセプトがぶれたり、その度に価値が揺らぎます。これはメリットでもありデメリットでもありますね。
今回の開発では
基本ながながと解説しましたが、上記はチームでやることを前提とした手法です。しかしこじんかいはつでも、そのエッセンスは十分に取り入れることができると思います。
私はアジャイルで今回は実施をしようと思います。
理由は以下の通りです。
ミニマムでリリースしたい！
まだ一切のアプリをリリースしたことがありません。まずリリースを知るという一巡を回したいです。
改善を多く回したい。頭でっかちに考える時間をながくもつよりは、やって失敗してを繰り返して成長したいからです。
まとめ
今回は開発手法の紹介と自分の開発について触れました。個人開発やアプリはかなりアジャイルが向いている分野だと思います。
ユーザーに触れる形を早く作り、そこからアップデートで良いからです。
また、個人開発では、やりとりが自分のみです。将来の自分が忘れた時用に思い出せる程度の設計書があれば十分なので、その辺もうまくできるかと思います。
皆さんも是非参考にしてみてください。
今回はアプリの開発のフレームワークを選定したので、次は開発環境の選定について述べようと思います。