システム開発プロセスの目的や課題、対応策とは？

システム開発に携わり、開発プロセスの目的について詳しく知りたい方もいるでしょう。ここではシステム開発のプロセスはどのようなものか、どのような課題があるのか、また対応策などについて解説します。過去のシステム開発で課題も対応策もいろいろ出てきているので、ぜひ参考にしてください。

開発プロセスとは

システム開発における開発プロセスの「プロセス」とは、直訳すると「工程」という意味になります。一般的には、要件定義に近いと「上流工程」、運用・保守に近い工程は「下流工程」と呼ばれます。

システムの開発プロセスは、要件定義に始まり、設計・開発を経て、テストへ進んでいきます。上流工程の方が役職としても上位に当たり、下流工程の方が下位という考え方もありますが、エンジニアの単価やプロジェクトでの立ち位置としてはその通りになる場合も多々あります。

上流工程を担う人の方が、現場では偉い人という位置づけになる場合が多いでしょう。ただし下流工程でスキルが高い人もいて、実際に上流工程の人よりも単価が高いというケースもあります。そのため工程の上下で平均的な報酬や立場の差はありますが、あくまでも「工程の上下を指して上流工程、下流工程と呼ぶ」と理解しておきましょう。

開発プロセスの目的

動くシステムを作るだけなら、開発プロセスを考えずにプログラミングだけ行えばよいと考える方もいるでしょう。実際プログラムさえ書けばシステムは動きます。それではなぜ、わざわざプロセスを踏んでシステム開発を進めるのでしょうか。

その理由としては、品質の確保、リソースの削減などがあります。

品質の確保は、各工程から品質を確認することで担保されます。設計の段階、プログラミングの段階、テストの段階でそれぞれ仕様についても検討し、品質に問題がないかを確認します。

リソースの削減は、過去のプロジェクトで得た経験や、既存のデータで使えるものは活用するという発想です。過去のリソースを考慮せずに1から開発を進めると、後から無駄が多かったことに気づく可能性が高いです。そのため、プロセスを踏んでリソースを削減します。

開発プロセスの主な手法

次に、開発プロセスの主な手法について解説します。具体的な開発プロセスとしては、主にウォーターフォールモデルとアジャイル開発があります。

ウォーターフォールモデル

ウォーターフォールモデルとは、滝のように上流から下流に向かって進めていく開発プロセスのことです。1つの工程を順番に行っていくので、進捗状況の把握が容易で品質も担保しやすいというメリットがあります。

ウォーターフォールモデルには手戻りがないという特徴があり、例えば要件定義の後に設計をして、その後再度要件定義に戻るということが基本的にありません。例外的にどうしても戻らなければならない場合もありますが、基本は手戻りがない前提で各手順を正確に遂行し、プロセスを進めていきます。

アジャイル開発

アジャイル型とは、とにかくスピード重視でプロジェクトを進めていく開発プロセスのことです。文字通り開発スピードが速く、全体を作りながら随時修正を行っていく方法になります。アジャイル型では、工程を戻る前提でプロセスを進めていけるので、見切り発車しやすいというメリットがあります。

従来主流とされてきたウォーターフォールモデルも、問題点が明らかになったことで、現代においては徐々にアジャイル開発への移行が始まっています。例えばウォーターフォールモデルでは、工程を進めてみなければどうしてもわからないことも出てきます。しかし、それでも工程を戻れないことから各工程を徹底する分、開発に時間がかかるのです。

一方でアジャイル型なら不都合があった場合には戻ればよいだけなので、素早く次の工程に移ることができます。実際、工程を進めてみた方が早く問題に気づくといったことも少なくありません。

近年は特にシステム開発にスピード感が求められ、アジャイル型の割合が増えています。今後はよりアジャイル型が一般的になっていくでしょう。

ただし、ウォーターフォールモデルが一概によくないというわけではなく、あくまでも、現在の状況に鑑みるとアジャイル型の方が採用されやすい、ということです。

プロジェクトによってはウォーターフォールモデルでしっかりと進めていく方がよい場合もあります。

システム開発プロセスの課題

システム開発プロセスの主な課題としては、標準化や目的の共有、新しい技術への準備などが挙げられます。

システム開発の標準化は、複数人で開発を進める際に必要になるものです。各々が独自に開発を進めていくと、ドキュメントもソースコードもバラバラになってしまいます。結果的に後から改修するのも管理も難しくなるので、開発を標準化してなるべく属人性を排除することが重要です。

次に、システム開発の目的を共有する必要があります。特に問題になるのは、システム開発を外注する場合です。クライアント企業（自社）と、システム開発を請け負う業者の意識の差が生じるからです。

システム開発を依頼する側として、自社からはとにかくほしい機能を自由に提案してしまうことも多いでしょう。この提案に対してシステム開発業者は、非効率性や矛盾を感じるケースが少なくありません。こうした際に開発業者は、「顧客ニーズを満たすこと」を最優先と考え、あえて非効率性や矛盾を指摘しない場合も多いのです。「要望を素直に聞いてもらえない」という悪い印象をクライアントに与えてしまい、別の開発業者へ依頼されてしまう恐れを避けるためです。

このような事情も重なり、開発業者との間での認識がズレたまま開発を進めた場合は、途中で仕様変更が必要になる可能性も高くなるでしょう。こうした事態が起これば、最初の段階で仕様の矛盾を指摘してくれなかった開発業者に対して、自社内でも不満や不信感が募ってしまう恐れも生じます。どうしても譲れない理由がある場合を除き、開発業者側には、「仕様に矛盾点や不都合などがあれば最初に指摘してほしい」と伝え、開発の目的をきちんと共有しておくことが重要です。

またそうした過程で、開発業者から提案される新しい技術などに関しても、自社へ導入する心構えをしておきましょう。ただしその導入リスクは認識しなくてはなりません。特に自社が、セキュリティ事故などを絶対に避けなければならない業種であれば、そのリスクについてはよく開発業者側から説明を受けましょう。

そのうえで、既存の技術を使用するか・新しい技術を導入するか慎重に検討してください。新しい技術の導入が絶対正解ではありませんが、新しい技術に目を向けることは大切です。実際の導入シーンをイメージしながら、開発業者側も交えて話し合えればベストです。

課題解決に向けた対応策

これらの課題解決に向けた主な対応策としては、「フレームワークの導入」や「外注先の開発業者も含めた、開発者間での連携」、そしてDevOpsの実践などが挙げられます。

共通のフレームワークを導入することで、「開発者間の認識がそろい、一部開発ルールを強制的に守らせることができる」といったメリットがあります。フレームワークの導入に関しては多くのプロジェクトですでに行われているでしょう。加えて、きちんとした開発業者ではこうしたフレームワークを用意していますので、外注する際にはよく確認してみましょう。

次に、開発現場や、開発業者との連携も重要です。基本的には、現場から一定間隔で状況を必ず報告してもらいましょう。加えて、もし現場で問題に気づいた場合は、早めに連絡してもらうような関係を築いておくことが大切です。これら連携を密にすることで、手戻りをなるべく防いでいくのです。

DevOpsはここ数年で注目度が高まっている概念で、開発と運用が一体になるという考え方です。システム開発では運用よりも開発が重要視される傾向にありますが、運用にも目を向けることで、運用時のトラブルを防げます。これについても、上記の連携関係の構築が重要と言えるでしょう。

まとめ

システム開発には課題が付きまといますが、対応策についてもある程度用意されています。特にDevOpsの概念は昨今注目されています。もし外注を検討する際は、こうした開発・運用環境についてどの程度カバーしてもらえるかを含め、よくプランを確認しましょう。