コロナなどの影響もあり、業務のオンライン化や業務システムの見直し等、システム開発が必要な機会が増えています。
今や、企業業務にシステムプログラムは切っても切れない存在になっています。

そんなシステムですが、今までシステムを導入する際にうまくいかなかったことや、システムを導入したは良いが、その機能に満足できていないというような経験をされたシステム担当者は多いのではないでしょうか?

今回は、システム開発を失敗しないようにするために、まずはシステム開発の進め方にはどの様なものがあるのかをご紹介します。

システム開発の進め方の種類

システム開発の進め方は大きく4種類あります。

  • ウォーターフォール型開発
  • アジャイル型開発
  • プロトタイピング型開発
  • スパイラル型開発

それぞれについて、説明していきます。

ウォーターフォール型開発

ウォーターフォール型開発は1970年代に提唱された開発方法です。

全体の工程を

「要件定義(計画)」
「外部設計」
「内部設計」
「プログラム設計」
「プログラミング」
「テスト」

といったの工程に分け、工程の一つ一つを終わらせてから次の工程へ…という流れで、開発を進めていく方法です。
一つの工程を確実に終わらせてから次の工程に進むため、前工程には原則として戻りません。

ウォーターフォール型開発は容易に後戻りができないような大規模なプロジェクトに適していると言われています。
コミュニケーションをとりつつ、各部署の合意を得てから先に進む手法は、日本企業の慣習になじみやいため広く支持されてきました。

メリット

  • 全体的な計画を立てやすい
  • 成果物のチェックがしやすい
  • 手戻りを最小限にできる

ウォーターフォール型開発は、まず要件定義をしっかりと行うことが前提ですので、事前に全体的な計画を立てやすく、
各工程での成果物も明確ですので、成果物のチェックもしやすくなります。
そして、各工程が確実に終わらせてから次の工程に進んでいるはずですので、手戻りも最小限になるはずです。

メリットとして挙げたこの3点は、

要件定義が確実なものである
工程を確実に終了させる

ということが実行できることが大前提となっています。
実際のシステム開発では、これらの実行がとても難しいため、次に挙げるデメリットが顕在化してしまいます。

デメリット

  • 変更が生じた際の改修作業が膨大に
  • 前工程のミスが後工程に直接的に影響してしまう
  • 工程のミスが発見しずらい
  •     

  • 発注者(クライアント)の意見を取り入れるタイミングが乏しい

例えば、
「プログラミング」まで工程が進みこの時点で、要件の変更が必要になった場合、要件定義まで戻り再度システムを構成しなおす必要があります。
つまり、前工程のミスが後工程に多大な影響を与えてしまいます。
この様なことから、変更が生じた場合の改修作業が膨大になってしまう危険性があります。
工程自体のミスを発見するには、工程全体の確認が必要なため発見自体に時間がかかります。
また、発注者がシステム全体を把握できるタイミングが、テスト段階となることが多く、この時点で意見を取り入れるということは、要件定義までの手戻りと同義となってしまいます。
そのため、追加の要件を実現するには、開発期間の延長や開発費の追加が必要となることが多く、発注者の意見を取り入れにくくなっています。

まとめ

ウォーターフォール型開発は、長らく様々な規模の開発で導入されてきましたが、
手戻り負担の大きさなどから別の開発方法を取り入れるプロジェクトが増えてきています。

個人的には、
現在ではすでに稼働しているシステムを新たに作り直すなど、
要件定義や機能要件がはっきりしているものを開発する際にはまだまだ有用な開発方法と思っています。

アジャイル型開発

ウォーターフォール型開発は要件定義や各工程の確実性が担保できれば、とても有用な開発ですが、
実際の開発現場では要件の途中変更や追加の要望へ対応する必要が多くあるため途中変更に対する負担の大きいウォーターフォール型開発ではなく、
途中変更の負担が少ない開発方法を選択することも増えています。
その代表格が、アジャイル型開発です。

アジャイルとは「迅速な」という意味が表す通り、システム開発にスピードを与える開発方法です。

アジャイル型開発では、システム開発には「要件の途中変更や追加の要望は当たり前だ」という前提で開発を進めます。
そのため、最初の要件定義は最小限にし、反復(イテレーション)と呼ばれる小さい工程を一単位として
計画→設計→実装→テストを細かく繰り返し、開発を進めていきます。

計画、設計、実装、テストを細かく繰り返すことで、ミスの発見が容易になります。また発注者からの変更要望があっても柔軟に対応可能です。
業務の自動化をゼロから行うような、要件定義が難しく、変更が多いと考えられる開発などにはよく合う開発手法と考えます。

メリット

  • 開発途中のミスにもすぐに対応できる
  • 仕様変更や発注者からの要望にも柔軟に対応できる。

アジャイル型開発は、小さな反復単位で計画、設計、実装、テストを繰り返すため、
ミスや問題の発見や対処がしやすいのが大きなメリットです。
また、仕様変更や追加の要望に対しても柔軟に対応ができます。

デメリット

  • 開発の方向性が定まりにくい
  • 進捗管理が難しい

要件定義や追加の要望への対応がしやすいということは、ともすればいつまでたっても完成しないということにつながることにもなりかねません。
一つ一つの要望は小さくても、システム全体としてみたとき本当に必要かどうかなどの判断をしっかりとしていかなければ、何のための誰のためのシステムかが大きくぶれてしまうこともあります。

まとめ

アジャイル型開発は、ウォーターフォール型開発の問題点を解決できるとても良い方法ですが、その運用方法を間違えば永遠に完成しないシステムとなり、発注者にとっては「未完成のまま納品されたシステム」と認識されかねません。そのためにも、何のためのシステムなのかを発注者側もシステムを開発する側もしっかりと把握しておく必要があります。

プロトタイピング型開発

プロトタイピング型開発は開発の早い段階から簡易版の試作品を作り、最初にシステム全体や機能を発注者がイメージできるようにする開発手法です。

簡易版とは言え、発注者は先に実際に動くものが見れるので、発注者はより具体的に実際の作業がイメージしやすくなり、要件確認の段階では分からなかった要望も明確化にすることが可能になります。
逆に、当初は必要だとしていた機能も不要だと判断できれば削除することも可能になります。

メリット

  • 柔軟に対応できる
  • 発注者がイメージしやすい
  • 開発後の大きな修正を防げる

プロトタイプ型開発は、早い段階で試作品を発注者に提供します。
システム開発の経験がなく完成品のイメージが明確にできない発注者でも、
実際にシステムを操作できるので完成品を正確にイメージすることができます。

完成後のシステムを納品された場合と比べると、試作品段階での変更は柔軟に対応が可能です。

デメリット

  • 大規模なシステム開発には向かない
  • 開発側の負担が大きくなる

大規模なシステムの場合は、簡易版の試作品を作ること自体が工数を必要とするため、開発側の負担が大きくなります。
また、試作品のチェック自体も時間がかかり、その上大規模になればなるほど発注者側の関係者の数も増えてしまいます。
試作品のチェックも1回ではないため、作業効率が大幅に悪化することがあります。

まとめ

プロトタイプ型開発に向いているプロジェクトは、仕様が明確に定まっていない場合や新しいサービスを立ち上げる場合のシステム開発や発注者側がシステム開発に慣れていない場合などに向いていると言われます。

スパイラル型開発

スパイラル型開発は小さな単位で設計、実装、テスト、プロトタイプ(試作)を繰り返していくことでゴールを目指す開発手法です。

小単位の反復で設計からテストまで行うのはアジャイル型に近いですが、まだ品質が保証されていない段階で試作をユーザーに提供するやり方はプロトタイプ型を踏襲しており、その両方のメリットを取り入れ、最終的に質の高いシステムを作ることを可能とします。

スパイラル型開発は早い段階から発注者に機能項目をプロトタイプという形でを提供するので、顕在化していない顧客の要望の発見も可能になることからも発注者側からも支持されています。

メリット

  • 前工程が後工程に影響を与えない
  • 仕様変更があっても柔軟に対応できる
  • 質の高いシステムを作り上げることが可能

スパイラル型開発は一通りの工程を繰り返して開発を進めるため、前工程が後工程に与える影響を少なくできます。
また、テスト後に仕様変更に関わる問題が見つかっても臨機応変に対応できるのがメリットです。

また、問題の修正を繰り返しながら開発を進めていくので、質の高いシステムを作り上げることを可能とします。

デメリット

  • 開発期間が長期化しやすい
  • 初期想定よりもシステムが強大化しやすい

修正を繰り返すという特性上、開発期間が長期化しやすく、スケジュールが読みにくくなりがちです。
アジャイル型開発でも陥りがちですが、システムの追加の要望や要件の変更を受けやすいということは、システム全体の方向性がぶれる可能性が高いとも言え、初期よりもシステムが膨大になりがちです。

まとめ

スパイラル型開発はアジャイルとプロトタイプの良いとこどりではありますが、その運用方法次第では、長期化、費用の増加を招きかねません。
優れた開発方法であっても、発注者側がシステムに対する要望を明確化できていなければいつまでたっても満足のいくシステムにはなりません。
まずは、要望を明確化することを目指しましょう。

発注者側の心得

発注時点では、どの開発方法が向いているかが分からないということがほとんどだと思います。

システム開発業者にも、開発方法の得手不得手があります。
自分たちの特異な開発方法を優先し、そのシステムに適したものを選択しない場合もあります。
難しいのは、この選択が一概に間違いとは言えないところです。

極論を言うと、どの様な開発方法でも、システムは開発できます。
逆に、会派方法が優れていても、システムの完成に至らないこともあります。

発注者としては、まず要望を明確にしておくこと、そしてその要望に優先順位をつけておくことが大事と考えます。
要件の明確化が難しい場合は、その時点から外部業者に相談することも良いかもしれません。

株式会社フォーサイトクリエイション
大阪・本町にある株式会社フォーサイトクリエイションは、パンフレットなどのグラフィックデザイン制作からコーポレートサイトなどのホームページ制作・ブランディングまで集客・売上・採用強化などお客様のご希望にALL in ONEで、すべてお応えします。
お客様のご希望やお悩みをしっかりヒアリングすることから始め、明るい未来へとご案内いたします。
まずは、お気軽にご相談ください。

TEL:06-6556-7519
https://f-creation.co.jp/



コーポレートサイトはこちら
お問い合わせ
お名前 *
会社名
電話番号 ハイフンなしでご記入ください。
メールアドレス *
メールアドレス(確認)
お問い合わせ内容
プライバシーポリシー *

株式会社フォーサイトクリエイションでは、当WEBサイトから送信いただく個人情報について、当サイトの「プライバシーポリシー」に基づいて管理させていただきますので、同意いただいた上で、情報の入力をお願いいたします。
※送信内容はSSL暗号化通信により高度なセキュリティで保護されます。