オフショア開発では、プロジェクト内の開発工程が上流工程と下流工程の2つのフェーズに分割されることが多いとのことです。その中に、上流工程がプロジェクトの開発工程全体における重要な工程とみなされています。では、上流工程と下流工程とは何でしょうか？上流工程と下流工程の違いはなんでしょうか？なぜ上流工程がより重要になると言われますでしょうか？

上流工程は、オフショア開発において、非常に重要な段階で、お客様との相談、要件定義、システムの設計などの実装作業を着手する前にすべての実施すべき作業を含むとのことです。あるいは、システムの企画から詳細設計にあたる工程を指します。

上流工程の流れは以下となります。

• 要件定義：システムに搭載する機能、性能や使用性、メンテナンス性などを決めることです。要件定義では、お客様とのヒアリングを行い、お客様が希望しているシステムは何か、そのシステムがどの課題を解決するべきかを明確に決めるフェーズです。お客様との意見が一致してから、「要件定義書」が作成されます。
• 基本設計：基本設計ではシステムの土台となる基本的仕様をまとめます。例えば、業務フローや前工程で作成した要求の一覧に基づき、システム化を行う部分の必要機能の一覧化や、入出力についての項目です。
• 詳細設計：基本設計の内容に基づいて、ユーザーから見えないシステム内部の動作や機能を決めることです。詳細設計では、要件定義段階で収集した要件をさらに詳細化し、具体的な機能や機能間の関係を明確にします。

つまり、上流工程とはシステム開発における前半の段階です。一方、下流工程とは上流工程に続く段階となります。下流工程には実装・テストなど実際にプログラミング、コーディングを行うことを含むとのことです。上流工程がしっかりできていないと、下流工程でトラブルが多発する原因になりかねません。特にウォーターフォール・モデルでは、下流から上流へと戻りにくい仕組みになっているため、上流工程できちんと品質や方向性を定めておく必要があるのです。

そのため、日本企業がシステム開発を委託する場合、開発（コーデイング）やテストなど下流工程の作業のみを海外会社に優先されています。要件定義やシステムの設計など上流工程内に作業は、自国で行われることがよくあります。目的は、次のようなリスクを最小限に抑えるようにすることです。

1. 顧客からの要望を受け切れていない

言語の違いにより、顧客要望をヒアリングする工程において、顧客の伝達したいことを誤解したり、不十分に理解したりして、要件定義書に顧客が求めるシステムが反映されないことがよくあります。

また、最初は顧客の要件を正しく把握していたものの、実装中に要件に変更が生じた場合、オフショア開発側では要件に変更が加わったものの、コントロールができていないというケースもあります。

上記の欠点により、要件定義書が不正確になり、設計書も不正確になり、不正確な開発およびテスト工程につながります。最後の成果物は受け入れられず、双方にとって手間やコストが無駄になってしまいます。

2. 工期が遅れる

オフショア開発会社のエンジニアの能力や経験によっては、設計書や要件定義の完成が予想よりも遅れる場合があります。上流工程の作業が遅れると、下流工程に割ける時間が短くなってしまいます。そのため、上流工程のスケジュールが遅れた場合、その分工期が伸びてしまう可能性があります。

なお、下流工程の時間を確保できなかったにもかかわらず納期を延長できなかったと、テストに使える時間が短くなり、バグ量多くのシステムを納品せざるを得なくなってしまうケースもあります。この場合、実際にシステムを運用後に多問題が発生してしまうかもしれません。

また、下流工程で上流工程のミスに気づいて、上流工程に戻ってやり直す必要となるという場合があります。その時点、実装時間が伸びてしまって、初期企画に間に合わないことの大きな原因のひとつとなりえます。

3. 運用後にトラブルが発生する

システムのリリース後、トラブルが発生するケースも少なくありません。理由としてはクライアントが仕様にない動作を行ったためミスが生じるケースもあり、また間違った処理状態で成果物を納品したことが原因で起こるトラブルも多いです。

もし上段工程で実際にシステムの運用を慎重に検討すれば、運用後のトラブル発生のリスクが軽減され、防止されということです。

上記のようなリスクがあるこそ、これまでオフショア開発を実施する度、主に下流工程の作業をオフショア開発企業に委託し、上流工程の作業は自国で行われることが多かったです。しかし、近年、オフショアエンジニアの資格が向上され、業務経験が増え、日本人クライアントの要望を理解することにより、上流工程の業務が徐々に外国にオフショア開発会社に遷移されている傾向にあります。

PiraGoでは、大手企業での長年経験を積んだ経営陣により、要件定義段階からシステム運用保守段階にかけてプロジェクトを開発することができると自身があります。

上流工程から生じる可能性のあるリスクを最小限に抑えるために、弊社は以下のように原則を確保します。

• クライアントとの綿密なすり結合

ソフトウェア開発プロジェクトを成功に導くために、まずクライアントがどんなシステムを求めているのかをきちんと聞き出すことが重要です。クライアントはシステム開発に関して専門家ではないことを考慮し、クライアントの要望を具体的に「どんなことに不満があるのか」「どんなことを実現したいのか」「既存システムではどんなことを行っているのか」などを聞き出す必要があります。

お客様の要望を聞きながら、双方の認識に齟齬がないように要件内容を確認しています。これにより、開発段階で要件が変更されたり、顧客の期待を満たさないシステムが作成されたりするリスクが最小限に抑えられる考えております。

• システムの実現可能性を精査

クライアントとやり取りを行う際に、要求されているシステムが実現可能かどうかも精査する必要があります。実現性が低い、適合性が少ないと判断した場合には、安易に受注せずに、クライアントにその旨をはっきりと伝えることも必要です。

案件を多く受注するより、システムのクオリティを保ち、プロジェクトの成功率を高めることも、クライアントの信頼を得る最優先事項となります。

• ドキュメントを具体化、標準化

要件が明確になり、クライアントよりご確認をいただいた後、システムの基本設計・詳細設計の作成段階に進みます。この時点で、基本的な設計を決めるため、プログラミングやコーディングなど開発方法やプロジェクトの管理方法に関する具体的な指示も必要です。これにより、上流工程から後戻りが発生してしまうリスクも制限されます。

詳細なドキュメントの必要性に加えて、設計書をできる限り標準化することが重要な役割を果たします。システムエンジニアによって設計書の作成方法や表記、仕様がバラバラであると、流工程と下流工程で担当する企業が異なる場合、プロジェクト全体の統一性が取れなくなります。そのより、共通のツールと規約を同意して導入すると、設計ドキュメントのフォームと品質を可能な限り均一にすることができます。

オフショア開発なら、PiraGo

日本レベルのクオリティ：若くて、ダイナミックで熱心の我々は高い技術能力を持ち、日本語が流暢で、仕事上の日本人の要求を理解しています。従ってPiragoは高品質な製品・サービスを提供できると確信しております。

コストの最適化：日本よりベトナムの物価が安くて、ベトナムでオフショアを実施すると、お客様は日本での開発することに比べて開発コストの３分の２も削減することが出来ます。そして、ソフトウェア開発プロセスを柔軟かつ徹底的に適用することによって、開発時間も短縮されます。

最先端技術：大きなシステム、クラウド利用、ビッグデータ、ERPなどについての経験を持ち、厳しい技術要求に応えらると確信しております。