システム開発の上流工程とは？起こりうるリスクや管理の重要性を解説
システム開発は、クライアントにヒアリングを行ってから実際に開発を行うまで、さまざまな手順があります。手順のうち最初の方に位置するものを「上流工程」と呼びますが、上流工程に不備や認識の相違が多いと手順の後の方「下流工程」でトラブルが多発してしまいます。本記事では、システム開発の上流工程で起こりうるリスクと管理の重要性について解説します。
システム開発の上流工程とは
システム開発では、一般的にウォーターフォール・モデルと呼ばれる開発モデルが用いられています。ウォーターフォールとは「滝」を意味し、決められた工程を一つひとつ順番に完了させながら進めていく点が上流から下流へと滝が流れていく様子に似ていることから名付けられました。そのため、ウォーターフォール・モデルでは最初の方の過程を上流工程、最後の方の過程を下流工程と呼んでいます。
ウォーターフォール・モデルでは、大まかに以下のような工程で開発が進みます。
要件定義…システムに搭載する機能、性能や使用性、メンテナンス性などを決める
基本設計…要件定義の内容に基づいて、UIを中心にシステムの全体像を決める
詳細設計…基本設計の内容に基づいて、ユーザーからは見えないシステム内部の動作や機能を決める
開発・製造…実際にプログラミング、コーディングを行う
システム実装・テスト…開発したシステムが実際に機能要件を満たしているか、正しく動作するかを確認する
上流工程とは、概ね「詳細設計」までの部分のことを指します。要件定義から詳細設計までの部分は、これから開発しようとするシステムの構想を具体的な設計に落とし込む工程であり、この部分がしっかりできていないと、下流工程でトラブルが多発する原因になりかねません。特にウォーターフォール・モデルでは、下流から上流へと戻りにくい仕組みになっているため、上流工程できちんと品質や方向性を定めておく必要があるのです。
他の開発モデルである「スクラム開発」については、「スクラム開発とは？メリットをアジャイルやウォーターフォールとの違いを交えて解説」をご覧ください。
上流工程の不備で起こりうるリスク
上流工程に不備があったり、設計が曖昧だったりすると、主に下流工程において、以下の3つのリスクが発生する可能性があります。
工期が遅れる
上流工程の作業が遅れると、下流工程に割ける時間が短くなってしまいます。しかし、上流工程で設計した内容を実際に開発し、実装するためには、一定の期間が必要です。そのため、上流工程のスケジュールが遅れた場合、その分工期が伸びてしまう可能性があります。
また、下流工程の時間を確保できなかったにもかかわらず納期を延長できなかった場合、テストに使える時間が短くなり、バグが大量に残ったシステムを納品せざるを得なくなってしまうケースもあります。この場合、実際にシステムを運用する際に問題が多発してしまいます。
他にも、下流工程で上流工程のミスに気づいた場合、上流工程に戻ってやり直す必要が生じてしまいます。これも、工期が伸びてしまうことの大きな原因のひとつとなりえます。工期をいたずらに伸ばさないためにも、上流工程で不備が起こらないようしっかり品質や方向性を定めておきましょう。
運用後にトラブルが発生する
システムは開発して終わりではなく、実際に運用が始まってからがスタートとよく言われます。当然ながら、上流工程の時点で実際に運用するときのことをしっかり考えていないと、運用が始まってからトラブルが発生するリスクが高まります。また、トラブル発生後の対応が遅れたり、エラーを引き起こしたりするリスクも、上流工程での不備が原因となることがあります。
開発コストがかかりすぎる
上流工程で設計を行う際には、予算との兼ね合いを考慮しながら行います。このとき、見積りが甘く想定していない機能開発や不可能な仕様が下流工程で見つかると、追加で開発するなど予算を超えたコストがかかることになります。最悪の場合は、開発コストがクライアント側で用意できなくなり、開発プロジェクトそのものを中止せざるを得なくなってしまうかもしれません。
上流工程起因のリスクを防ぐ管理方法とは？
上流工程で起こりうるリスクを防ぐためには、以下の3つの管理が重要です。
1. クライアントとの綿密なすり合わせ
そもそも、もっとも重要なこととして、クライアントがどんなシステムを求めているのかをきちんと聞き出すことが重要です。クライアントはシステム開発に関して専門家ではないことを考慮し、クライアントの要望を具体的に「どんなことに不満があるのか」「どんなことを実現したいのか」「既存システムではどんなことを行っているのか」などを聞き出す必要があります。
クライアントの要望をまず詳細にヒアリングし、実現できることを提示してお互いの認識に齟齬がないことをしっかり確認しましょう。これにより、下流工程で後戻りしたり、意図していない仕様変更を行ったりするリスクはもちろん、納期が遅れたりコストがかかりすぎたりするトラブルも避けられます。
なお、アプリ開発を外注する際のポイントについては、「アプリ開発を外注するといくらかかる？外注の際に気をつけるポイントは？」もご覧ください。
2. システムが実現可能かどうか精査する
クライアントと綿密なすり合わせを行う際に、要求されているシステムが実現可能かどうかも精査する必要があります。詳細なすり合わせや実現性の精査を行わず安易に受注してしまうと、大きなトラブルやプロジェクト失敗につながる可能性があるため、注意が必要です。
上流工程では、受注を決める前にクライアントの要求を慎重に精査し、実現性が低い、適合性が少ないと判断した場合には、クライアントにその旨をはっきりと伝えることも必要です。案件を多く受注するだけでなく、システムのクオリティを保ち、プロジェクトの成功率を高めることも、開発を手掛ける企業の実績や信頼関係のためには重要なことではないでしょうか。
3. 設計を具体化、標準化する
ヒアリングと精査が終わったら、いよいよ設計書に起こしていきます。どのようなシステムを作っていくか、基本的な設計を決めていきます。この時点でプログラミングやコーディングに関する具体的な指示も必要で、逆にこの点までしっかり決めておかないと、下流工程から後戻りが発生してしまうリスクがあります。
そのため、設計書をできる限り標準化することが重要です。作成するシステムエンジニアによって設計書の作成方法や表記、仕様がバラバラであると、上流工程と下流工程で担当する企業が分かれている場合、特に問題となります。作成する設計書はできる限り統一されたフォームと品質を保つため、ツールなどを導入するのもよいでしょう。
WEBアプリケーションの開発手順や仕組みについては「WEBアプリケーションの開発手順とは？仕組みや開発言語を紹介」で紹介しておりますので、こちらもぜひご参照ください。
まとめ：システム開発の上流工程で起こりうるリスクを知り、綿密かつ堅実に設計を行おう
システム開発のウォーターフォール・モデルにおける上流工程では、これから開発しようとするシステムの構想を具体的な設計に落とし込み、下流工程へと橋渡しを行います。そのため、上流工程でクライアントとの綿密なすり合わせができていなかったり、実現可能かどうか精査されていなかったり、設計が曖昧だったりすると、下流工程でトラブルが多発してしまいます。上流工程で起こりうるリスクを知り、下流工程に引き継いでも問題のない設計を行いましょう。
2022年5月より、NTQでは上流工程フレームワークサービスの提供を始めました。このサービスでは、要件定義や外部設計などの打ち合わせを国内にいるエンジニア、または日本人のプロジェクトマネージャーと行います。これによって、従来のオフショア開発における言語や文化の違いによるコミュニケーションの困難、品質や納期などプロジェクト管理の課題を解消可能です。ぜひ一度ご相談ください。
お問い合わせページ
