LoginSignup
27
19

More than 5 years have passed since last update.

開発プロセスについて

Last updated at Posted at 2016-07-13

齢四十を超えて、ようやくチームリーダーとして一つのプロダクトをチームで開発する機会に恵まれています。それにあたって、開発プロセスをどうするかについて考えなおしてみたので、それで自分なりに出した結論について書いてみます。

開発プロセスの種類

いわゆる開発プロセスは、つまるところ次の3つに大きく分類されます。

  • ウォーターフォール型
  • 反復型
  • アジャイル型

ウォーターフォール型開発プロセス

ウォーターフォール型開発プロセスは、開発成果物が事前に把握できていて、かつ開発を阻害するリスク(技術的なもの、組織的なものなど)がないという前提で使うことのできる開発プロセスです。
ウォーターフォール型開発プロセスの最大の利点は、いつまでに何ができるのかを確実に定義できることです。あと異論はあるかもしれませんが、前提が満たされている場合、最終的な成果物の出来上がる期間は最も短くなるはずです(他の開発プロセスは、まとまった作業が終わった時点でその作業の評価をしなければならないため)。欠点は、仕様変更や技術的課題の発生による手戻りが大きいことです。あと、「とりあえず動作するアプリ」が出来上がる期間は最も長くなります。

反復型開発プロセス

アジャイルとウォーターフォールの間に挟まれて影が薄いですが、反復型開発プロセスというものも存在します。反復型開発プロセスは、開発成果物は事前に把握できているが、開発を阻害するリスク(技術的なもの、組織的なもの)などがあるという前提で使うことのできる開発プロセスです。
反復型開発プロセスでは、アジャイルと同じく一つの開発期間の中で複数のイテレーション(反復)を回すことが特徴になります。しかしイテレーションの目的は異なります。アジャイルのイテレーションは、完全に動作する機能を作成してユーザーからのフィードバックを得るのが目的です。しかし反復型開発のイテレーションは、開発にあたってリスクとなっている技術を使ったプロトタイプを作成してリスクを削減することを目的としています。そのため、反復型開発プロセスのイテレーションは、必ずしも動作するアプリを生み出さないこともあります。
反復型開発プロセスの利点は、ウォーターフォール型に比べて未知の技術を採用しても手戻りが少なくなります。リリースする成果物のスコープやリリース日の変更が管理されている状態で少し変動することになります。欠点としては、作ったものが実は役に立たなかったということが、アジャイルに比べると発生しやすいです。

アジャイル開発

アジャイル開発では、そもそも開発成果物が最終的に何になるのかがわからない前提で使うことのできる開発プロセスです。
1〜2週間(あるいは数日)という短い期間で完全に動作する機能をリリースして、利用者のフィードバックを得ながら順次開発をしていくのが特徴になります。
アジャイル開発の利点は、無駄なものは作らないので手戻りがほとんど発生しないということです。しかし欠点としては、プロジェクトを始めるときにはいつまでに何ができるのか、誰もわかりません。本当に優秀なアジャイルチームであっても「期間はお約束できませんが、必ずや役に立つ物が出来上がります。トラストミー!」というのが精一杯でしょう。

どの開発プロセスを選ぶべきか

これらの3つの開発プロセスには、それぞれメリット・デメリットがありますが優劣はありません。プロジェクトの特性に合わせて選ぶべきです。

例えば、新規のゲームエンジンを使った新しいゲーム開発では、反復型開発プロセスが適しているでしょう。とにかく会社を作ってしまったベンチャー企業は、アジャイル開発以外の開発手法には無理があります。すでに作成されたゲームの運営をしている場合は、ウォーターフォールが合うかもしれません。

自分たちの場合、iOS(Swift), Android(Java), サーバー(Ruby on Rails)の組み合わせでアプリ開発を継続して行っています。iOSには1週間位かかる申請が存在するため、アジャイル開発は向かないなーと感じています(最近は1〜2日に短縮されたようですが、それでも向かない)。ちなみに今はプロジェクトメンバー4人で、ウォーターフォール型開発を行っています。つまりリリース機能をスコープとして定義して、WBSで工数を見積もり、ガントチャートを使って予実管理を行っています。プロジェクトの期間は2ヶ月と短いので、いわゆるマイクロウォーターフォールの部類に入るかもしれません。

IT技術にも通じるところはありますが、「○○なんて使っているようでは時代に遅れている」と頭ごなしに非難するのではなく、どれでも使えるようにしておいたうえで状況に応じて適切なものを使い分けられる技術者になるのが、吉かなと思います。開発プロセスに関するフレーム合戦は、端から見ているのは面白いかもしれませんが、当事者になったら得るものはほぼ何もなさそうです。

27
19
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
27
19