システム開発手順について押さえるべきポイント

 2023.02.10  株式会社システムインテグレータ

何らかの業務課題を解決するためにシステム開発を依頼することは今や当たり前の光景です。しかし、依頼を担当する従業員がシステム開発のプロとは限りません。

そのため、システム開発会社が提案する内容に対して「お任せします」と言いたくなる気持ちは分かりますが、依頼側もシステム開発について最低限の知識が無ければ業務課題を解決できるようなシステムは構築されないでしょう。

プログラミングなど技術的な話は別として、システム開発がどういった手順で行われてくかとい部分については明確に知っておくべきです。そこで本稿ではシステム開発手順について依頼側の視点からご紹介します。

システム開発の手順(顧客視点)

システム開発を外部に委託することは、プロジェクトを成功裏に進めるために大きな決断となります。開発する内容のみならず、発注先の選定からプロジェクトの推進、システムの安定稼働まで、様々な手順を踏むことになります。

RFPを作成する

RFP(Request For Proposal)とは依頼提案書のことで、システム開発におけるRFPでは業務課題を解決するために求めるシステムの概要や目的、予算や希望納期等を記載してものです。システム開発ではゼロから開発するか、ある程度パッケージを使用するしカスタマイズや不足分を追加開発するかなど、要件を整理してRFPにまとめます。

発注先候補とのオリエンテーション

オリエンテーションとは作成したRFPについて説明することを指します。RFPをただ提出するだけでは細かな意図を伝えきれない場合が多く、発注先候補ごとに解釈が違うと適切なシステム会社選びができません。オリエンテーションでは発注先候補に関わらず同じRFPで行うことで、選定先の技量や理解度を図ることも可能となります。

各社回答を参考に発注先を選ぶ

RFPに対する回答が返ってきますので、こちらが提示した要件を実現する方法や費用、スケジュール等を参考に発注先を選択します。技術力や使用するツールばかりに目を向けず、プロジェクトをきちんと管理できる能力も含めて、総合的に判断する必要があります。

基本契約締結

基本契約とはざっくりとした開発費用は保守要件等を記載した契約書を取り交わすことです。さらに具体的な開発費用や開発プロセスごとの契約に関しては個別契約締結にて行います。

システム要件定義

このプロセスは業務課題を解決するためにどういった機能が必要で、それを実現するためにはどんなシステムリソースや環境を構築すべきかなど、要件を細部まで定義します。重要な点として、関連部門の関係者にも参加してもらうことで、正しく要望事項を網羅した上で要件を整理することです。

システム開発依頼担当者や経営者の独断でシステムを構築するのではなく、社内で実際のそれを使用するエンドユーザーを巻き込んでシステム要件を定義します。そうすることで企業にとって最適なシステム開発が行えます。

システム概要設計

システム要件が定義できたらシステムの概要を設計していきます。UI(ユーザーインターフェース)はどういったデザインにするか?データベースの構造はどうするか?入出力できる帳票の種類は何にするか?など、システムの基本となる部分を設計することです。

システム要件を定義しただけでは、各機能がどう連携するかまで定かではないためそのままで開発を進めることはできません。要件定義の工程で整理された要件をもとに、システムの大枠を組み立てていくことが主な作業です。

システム詳細設計

システム概要設計でシステムの大枠が決まったら各設計を詳細なフローにまで落とし込みます。各プログラムで実現すべき機能=仕様を定義し、大まかなタスク振り分けをすることも作業の一つです。大規模なシステム開発になると複数のシステム会社が関わることも多いため、ここで決まったタスクが各社に振り分けられるということも少なくありません。

個別契約締結

個別契約のタイミングはケースバイケースとなりますが、作業分担内容や共同作業内容等を明らかにして、最終的な開発費用を明記する契約書を締結します。この際に、作業内容に基づき、委託型か準委任型にするかも規定し、納品物についても細目を確定すること異なります。最近では、様々な開発手法が用いられるため、契約内容と実際の作業が乖離することも多くあり、後からトラブルが生じないように、適切に明文化しておく必要があります。

プログラム設計

システム詳細設計で決定した事項は、開発者向けの作業指示ができるように、さらに細かい処理手順や一つ一つの構造などを細かく設計していきます。ここまで段階的な設計を行うことで、初めて業務課題にマッチしたプログラムが作成できます。想定したフローがいざ開発する段階で矛盾が生じないよう、プログラム設計は開発に着手する際に重要なドキュメントとなります。

テスト計画

これは、開発したプログラムが適正かどうかの判定や、品質の確認、引き渡し(システム納品)の検証項目等をこの計画書で規定します。テストには様々な種類がありますが、最終的には自身で想定した機能が正しく動作することは当然として、スケジュール面も意識して納品を受ける必要があるため、テスト計画は顧客にとってうやむやにできない重要な項目の一つと言えます。

プログラムコーディング

設計に基づいてプログラムコードを記述していくことでコーディングといいます。プログラムコーディングを効率的に進めるポイントは、最初から完璧さを目指さず、一定の品質を確保できた段階で次の工程に進むことです。そこで生じる問題への改善案を打ち出し、徐々に完成形へと近づけていくことが大切です。

スケジュールと品質のバランスをうまく保ちながら、工程を進めることで効率的なプログラムコーディングが行えます。

単体テスト

コーディングしたプログラムを単体で動作させて問題を検出するテストです。この時点でより多くの問題を検出することで、バグや仕様との違いなど、すぐに開発メンバーへフィードバックすることで、手戻りを最小限に止めることができます。

結合テスト

各プログラムを連携させて機能レベルで行うテストです。プログラムを連携したときに機能が正しく動作するかが重要になります。単体テストで見つかった不具合なども考慮しながら進める場合もありますが、結合テストを通過する段階で、一連の改修を潰しておくことで、システム全体の品質に目処が見えてきます。

システムテスト

各機能を連携したシステム全体をテストします。このフェーズではすでに単体テストや結合テストを終えているため、気になる不具合に目が行きがちですが、あくまでシステムとしての動作をテストすることが大切です。

システムとして通しで処理が滞りなく行えることを確認することで、細部の調整についても優先順位をつけることが可能となります。

運用テスト

エンドユーザーの実証データに基づきシステムの可用性などを評価するものです。社内受け入れに必要となるテスト項目など予め規定されている点も踏まえつつ、定常運転が行えることを確認する工程となります。

納品

以上のテストがすべて完了すればシステムの納品にいたります。多くの場合、瑕疵担保として引き渡し後も保守する義務を負いますし、事実事前に発見できなかった不具合が発見されることも多いため、納品できたからと言って、委託会社の体制をリリースしてしまうようなことがないよう注意します。

本稼働・システム運用保守

納品を過ぎるとシステム運用保守というプロセスへと移行します。厳密に言えばこの段階で運用プロセスに移行します。ただし、システム改修などが入れば都度開発する必要があるため、再度開発プロセスを繰り返します。当初想定していた仕様が実は機能していないなど、不具合と言っても仕様に関わる点も露見するため、システム運用が開始された段階でどこまで内部で対応し、委託会社に依頼する範囲なども定め、追加契約を締結する必要があるかも判断します。

良いシステム開発会社の条件とは?

いかがでしょうか?システム開発には多数のプロセスがあり、依頼側も各プロセスを理解することで都度どういった対応を取ればよいかがわかります。そうすればシステム開発会社と一丸になって課題解決に有効なシステムが構築できるでしょう。

ただしどんなシステム開発会社も同じというわけではないので、システム開発会社の選定がプロジェクトの成否を決めると言っても過言ではありません。では、どう言った点で選定すれば良いのでしょうか。いくつかポイントをご紹介します。

プロセスの標準化が出来ている

標準化とは特定の従業員に依存するのではなく、部門全体がすべての作業をできるよう環境を整えることを言います。システム開発プロジェクトでは人材の入れ替わりが激しいため、プロセスの平準化が出来ていないと従業員によって品質のばらつきが発生してしまいます。そのためプロセスの標準化が出来ているシステム開発会社を選ぶのは大切なポイントです。

同様なプロジェクトの実績があると言っても、開発プロジェクトとしては全く異なることも多くあります。

開発プロセスが標準化されていることは、システム開発の生産性とも関連するため、重要な指標と言えます。

生産性指標と品質検査が徹底されている

生産性指標とはシステム開発においてどれほどの生産性を発揮しているかという指標です。これを算出している企業は少ないですが、生産性へ意識を向けているシステム開発会社の多くはシステム開発に対して妥協をせず、良いシステムを構築することを意識しいています。可能ならシステム開発会社が持つ生産性指標や考え方を提示してもらうと良いでしょう。また、プログラムの製造物ですので、きちんとした品質管理や検査が行われていることが大切です。こちらも手法やルールなどを規定している場合が多く、どう言った手順で品質を担保しているか、情報開示を依頼することで確認が可能です。

細部に目が行き届いている

システム開発において契約内容を確認し、ソースコードについて11行確認することは面倒な作業です。しかしこの面倒を避けず、さらにはシステム開発に詳しくない依頼担当者に対して丁寧に説明してくれるようなシステム開発会社は優良と言えます。

また、プロジェクト管理が徹底できていて、問題を未然に防ぐことも大切ですが、発生した問題に対処するスピードも重要になります。常に細部まで目が行き届いている状況とは、プロジェクトの体制や管理手法がきちんと確立されていることを意味します。

まとめ

いかがでしょうか?今回はシステム開発手順について、顧客目線で各工程を整理してみました。システム開発で重要なポイントは、やはり上流工程で顧客と開発会社の意思疎通が図られ、具体的なイメージが共有されていることです。


RELATED POST関連記事


RECENT POST「コラム」の最新記事


コラム

システム開発の手法とは?ウォーターフォールとアジャイル開発との違い

コラム

理想の設計書フォーマットを考える

コラム

これからのソフトウェア設計書に求められる書き方とは?

コラム

設計工程って本当に必要なの?

システム開発手順について押さえるべきポイント
新規CTA