日頃「システム」という言葉を良く使いますがシステムとはなんでしょうか？
システムの反対はカオス（chos）、混乱です。そこからシステムの意味を考えると整理された状態といえます。
システム開発をするということは混乱状態を整理された組織や業務にすることを指すといえます。
そのシステム開発を行う手法にはいくつかの種類があり、手順が大きく変わってきます。
自分たちが関わっているシステム開発がどの手法を採用しているか知ることでシステム開発の大きな流れがわかるかと思います。
また各々のシステム開発手法の特性を知ることで次のプロジェクトはこっちの手法がいいかもといった具合に試していただけると幸いです。
【非エンジニア向け】システム開発手法について 4つの種類を紹介
システム開発を行っていく上で大まかな流れが定められた手法があります。
そのシステム開発手法として有名なものが３つあります。
- ウォーターフォール開発
- アジャイル開発
- プロトタイプ開発
システム開発を始める場合はまずこのような手法の中から対象システムの規模や特性に応じて開発手法を選定します。
システム開発手法 ウォーターフォール開発
日本では最も採用されている開発手法です。ソフトウェア開発データ白書によると９７％が採用している開発手法になります。
SIerと呼ばれる業態で主に使用されています、インターネットサービス系の会社は後述するアジャイル開発の方が多いです。
SIerやインターネットサービス会社に関しては以下の記事に書いてますのでよければご覧ください。
ここまでの差は体感としてないように感じてますがアンケート回答者にインターネットサービス系の企業が少ないのかもしれません。
ソフトウェア開発データ白書はIPA（情報処理推進機構）が配布しているものでこちらから無料で見れます。
ウォーターフォール開発の流れ
ウォーターフォール開発手法は、システム分析・要求定義からテスト、運用までの各工程が、滝のように上から下へ流れ、逆流しないことを原則としています。
ただミスが発覚したときに戻れないでは困りますので各工程の終了後にレビューというチェックを行うことが一般的となっています。
ウォーターフォール開発の問題点
大多数に採用されているウォーターフォール開発ですが問題点としてユーザー（システムの利用者）が工程の最後の方にしか実際に動くシステムを触ることが出来ないということが挙げられます。
これの何が問題かというと前述した通りウォーターフォールでは逆流しないことが前提となっています。
逆流する（手戻りといいます）とコストが発生します。
そしてこの逆流する工程が多いほどコストが大きくなっていきます。
統計としては要求段階でミスと分かったものを対処するのを１とすると設計段階で３倍、テスト段階で１０倍、出荷後にはなんと１００倍との値が出ています。
ここで最初に書いた「工程の最後の方にしか実際に動くシステムを触ることが出来ない」ということを考えると工程の最後というとシステムテスト時以降になりますので１０倍以上のものコストがかかることになります。
今まで仕様変更をお願いすると嫌そうな顔をされたという方もいらっしゃるのではないでしょうか？
ウォーターフォールで開発している場合、上記のような背景もあり後工程での仕様変更はコストが大きくなってしまうといったことがあります。
この問題点を解消する手法として代表的なものにアジャイル開発があります。
システム開発手法 アジャイル開発
アジャイル開発では開発過程で予測できない変化が生じることは避けられないという前提があります。
つまり逆流するのはしょうがないよねと考え、変化が生じたらコミュニケーションとってより良いものを作りましょうという感じです。
アジャイル開発の考え方はAgile Allianceという団体が発表したアジャイル宣言にまとめらています。
重要なのは以下の４つの考え方です。
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
左側にあるのがウォータフォール的な考え方、右側にあるのがアジャイル的な考え方といえます。
ウォーターフォール開発と比較すると以下のような感じになります。
違いの重要なところはリリースが複数回あることです。
リリースはユーザー（システムの利用者）にさわってもらう機会を意味しています。
ウォータフォールではユーザーにさわってもらうことが最後にきていることに起因する問題がありました。
アジャイルではシステムが全部できていない状態であっても出来ているところから見てもらうことにより、早くフィードバックをもらうことを目的にしています。
上の図ではウォータフォールの期間が小さくなっただけのような感じですが実際にやっている感覚からすると各々の工程が並行しているやっている感じの方が近いです、下図の方がより近い感じです。
アジャイル開発の種類
アジャイル開発の中でもさらに種類がいくつかあります。
その中でも有名なものが以下の３つです。
- XP（エクストリームプログラミング）
- スクラム開発
- リーン開発
どれも大きな考え方は前述したアジャイル宣言がベースになっていますが人の役割の定義や開発を実施する際の決められた作業（プラクティスと呼ばれている）などに違いがあります。
詳細については別途記事を書きたいと思います。
この３つの中では昨今、スクラム開発というワードが良く聞かれるのではないかと思います。
スクラム開発を実施するにあたりコーチ的な役割を担うスクラムマスターというものがあり、そのスクラマスターに対する求人があったりするくらいです。
システム開発手法 プロトタイプ開発
要求定義や外部設計でプロトタイプ（試作品）を作成します。
このプロトタイプで機能確認や使い勝手の良さなどをユーザー（システムの利用者）に評価してもらうことができます。
前述したウォーターフォールの欠点であったシステム開発の後半にならないとユーザーが確認できない点を改善しようとしている手法となります。
プロタイプ開発には大きく２つの種類があります。
発展型（機能型プロトタイプ）
発展型プロトタイプとは作成したプロトタイプを評価してもらった後にそのプロトタイプを継続してプログラム開発をしていくことをいいます。
よって作り始めるときに設計に考慮する点が多くなるためプロトタイプを完成させるスピードが落ちることになります。
使い捨て型（モックアップ型プロトタイプ）
使い捨て型プロトタイプとはその名の通り評価に使用した後は廃棄します。よって実際に利用するシステムには発展しません。
この場合はプログラムは適当に書いても全く問題ないためプロトタイプを完成させるスピードをあげることができます。
プロトタイプ開発といっても上記のどちらかで後の作業とコストが大きく変わってきますので開始前に認識を合わせておくことが重要となります。
私は使い捨て型を利用したことがあります。
使い捨て型にした理由は発注者から開発して欲しいプログラミング言語が決まっており、そのプログラミング言語への習熟度がまだ低かったのでその時点で一番早く作れるプログラミング言語にてプロトタイプを作成しました。
システム開発手法 どの手法が一番良いの？
紹介しました３つの開発手法の全て経験がありますが私はアジャイル開発で行うのが一番良いと考えています。
私がはじめてアジャイル開発を行ったのは前述した３つのうちスクラム開発で行いました。
スクラム開発に変更する前まではウォータフォールにある典型的な悩みを抱えていました。
要件で決めたものの開発完了後に見せると「思っていたものと違う」、「ここをもっとこうして欲しい」といったことが発生します。
この場合に納期を遅らせることができるのであれば良いのですがほとんどの場合そうはいきません。
大体の場合は残業するや人を投入するなどで乗り切っていました。
このような状態を改善するためにスクラム開発を導入し、ユーザーに見せる機会（スクラムではスプリントレビューと言います）を増やしたところフィードバックを早めにもらうことができるようになり、手戻りに対するコストを少なく出来たため残業をほとんどなくすことが出来ました。
ただアジャイル開発はじゃあすぐにやってみましょうというとなかなか難易度が高く、うまくいかずに最悪やめてしまうこともあるかと思います。
アジャイル開発の難しいところとして開発陣だけの話ではなく組織全体で取り組まなければいけないところにあると思います。
アジャイル開発を成功させるためにはユーザーへの理解と協力が絶対に必要となります。
なぜアジャイル開発を導入したいのかを明確にして組織全体に浸透させることが重要だと考えています。
参考文献
がおすすめです。
