【システム開発の外注ポイント】事前準備と受け入れのポイントまとめ

多くの企業が、システム開発を外部の開発会社へ依頼しています。その依頼したシステム開発のリリースが成功しているかどうかと言うと、必ずしもそうではありません。
もちろん、開発会社のマネジメント不足、ディレクション不足、技術不足などあらゆる理由はありますが、それと同様に発注者側にも不足している部分があります。多くの理由は、要件定義を決めるための要件整理の部分です。どのようなシステムを実現したいかの目的が不明瞭なまま進めてしまうことに上手くいかない原因があることが多いのです。
そこで、今回はシステム開発に発注者が知っておくべきノウハウについて説明します。

システム開発をお考えならリカイゼンにご相談ください！
リカイゼンでは、100社以上のシステム開発会社の中から、作りたいシステムや予算、体制、納期などの希望条件を踏まえて適した開発会社を選定して無料紹介いたします。
WEB上で受発注が決まるのではなく、一度対面などで面談をしてから発注するかしないかの判断を行うことができますので、まずはお気軽にご相談ください。
サービス利用料や手数料などの費用は一切かかりません。

１． 失敗しないシステム開発とは？

システム開発にはいくつかの工程があり、それぞれの工程でうまくマネジメントが働くことで、失敗しないシステムを完成させることができます。ただし、それは「どのようなシステムを作りたいか」と言う目的が明確になっていることが前提になります。 その前提を決めるのが、「要件定義」になります。システム開発が成功するかどうかは、要件定義の工程部分で決まってくると言っても過言ではありません。

そして、要件定義に先立って、システムで何を実現したいのか、現状の業務の中で何が課題になっているのか、などを抽出し要件定義を行うために明確にしていく部分を「要求定義」としています。この要求定義は、発注者が主体となって内容を出してまとめていきます。

２． 発注者による要求定義の作り方

発注者としてシステム開発を成功させたい場合は、この要求定義を明確化する作業を行う必要があります。 発注者としてやりたいことが明確でないまま、開発会社へ丸投げしてしまうと、ほぼ失敗する開発プロジェクトになってしまうでしょう。このようなシステムは、途中で大幅な仕様変更やリリース直前になって仕様追加が発生してリリースを後ろ倒しにせざるを得ないような状況に陥ったりします。

このようなことに陥らないためには、要求定義のフェーズで発注者が主体となって実現したい項目を固めていくことが重要です。
ここでは、「要求定義」のまとめ方に関する具体的な説明をします。要求定義書は、基本的には５W１Hで文書としてまとめるのが望ましいです。その記載方針は下記の通りになります。

WHY（目的）

まず、実現したいシステムの目的です。「何のためのシステムか」、システムで達成したいことをできる限り具体的に記述します。開発期間が長期に渡ってくると、発注者も開発会社も「開発することが目的」になってしまいがちです。これは、手段が目的化して、当初の目的を見失いがちになああります。そう言った際に軌道修正するためにも、目的を明文化したものが必要なのです。

HOW（予算）

どれくらいの予算が用意できるかを記述します。よく、発注者では見積もりが先にないと予算を出せないと言うようなケースもあります。本来は、詳細機能を詰める前に予算化し、実現したい要件と予算をすり合わせしていくと言うステップを踏めるのが理想的です。
予算を0として考えるのではなく、システムを導入することによって改善できる業務内容や人件費などを考えておおよその予算を考えたり、自社の部門の持つ予算や過去実現してきたシステム開発の中で、大体このくらいの予算であれば動かすことができそうというような目安を持っておくことが重要です。

WHEN（納期）

システムをいつリリースしたいのかを決めます。また、システムの分割納品などが希望の場合は、機能等ごとに希望完成日等を記述するのが良いでしょう。また、リリース後の不具合対応など、瑕疵担保期間の希望なども入れておくことが望ましいです。

WHERE、WHAT、WHO（運用）

完成したシステムは、誰がどこでどのように使うのかを想定して記述します。システムは誰かに使われることになりますから、そのあたりを明確にしておかないと、受け入れテストを含めて誰が最終確認できるのかが曖昧になり、運用開始後のトラブルのもとになります。また、運用開始後の不具合やシステムエラーなどが起きた場合、どのようにエスカレーションするかを記述しておくと、スムーズな運用を行うことができます。
あと運用で大事なこととして、既存システムとハードウェアとの兼ね合いです。新しいシステムを実装するインフラをどうするのか、新しいものを用意するかしないのかを決めておく必要があります。これは大きくコストにも関わってきますし、既存システムがある場合に移行等が発生する場合は、移行計画も取りまとめる必要があります。

３． 受け入れテストをスムーズに行うためのノウハウ

システム開発と開発者テストが一通り完了したら、発注者側ではリリース前の検収として「受け入れテスト」を実施します。ここで確認するポイントは、最終的な納品物が発注者の本来の目的や意図通りに動作しているかどうかを確認することです。
下記に受け入れテストを行う際の評価ポイントを紹介します。

全体スルーテストを行い、不具合がないこと

そもそもこの受け入れテストの段階で、不具合が出ることはテスト不足が否めません。不具合が出た場合は、エクセル等で一覧表を作り、不具合対応がいつ完了しているかなどのスケジュールを確認できるようにしておきましょう。

システム操作をする上で操作手順に違和感がないこと

例えば、画面上の入力項目チェックやタブ遷移など、ユーザビリティ面で違和感があると使いにくいシステムになってしまいますので、その辺りの確認が必要です。

イレギュラーテストを問題なく通過できること

負荷テストや、普段は入力しないデータ入力を試して、イレギュラーなテストを行うことは大事です。その際に回避ができていれば問題ありません。

セキュリティや権限設定で気になるところや問題がないこと

普通はあり得ませんが、ログインパスワードがなくてもログインできてしまうなどが起きないかの一般的なテストも行います。また、セキュリティ面に関してはJavaScriptなどからデータ改ざんされて侵入されるウィルスなどもありますので、全体通してセキュリティ対策がどうなっているかは確認が必要です。

ユーザー操作マニュアルがわかりやすいこと

システムを利用する際のマニュアルはわかりやすいものでなければ、システムを使おうとなりません。あらゆる部署でシステムを使う予定でしたら、例えば部署ごとにマニュアルの構成が分かれているなど、目次の作り方も大事です。そのあたりまでしっかり検証しましょう。

４． まとめ

システム開発を失敗しないために、発注者がまとめる「要求定義」の作り方、そして最終確認となる受け入れテストで確認するポイントについて説明してきました。
発注者が外注先を選定するように、外注先からも発注者も見られています。あまり、システムリテラシーの低い対応や、発注者だからと言うことでわがままをやりすぎると、開発会社側から優先度を下げられ、上手くいくプロジェクトも上手くいかないと言う結果を招いてしまいます。

一方、開発会社から見て評価の高い発注者は、やらなければいけないことが明確で、決めなければいけないことをスケジュール通りに決めてくれると言うことです。また、関わる関係部署の調整も上手くこなし、大きなトラブルを招くことなくプロジェクトをスムーズに遂行しようと気を配れる発注者になります。これらは、「発注ノウハウを抑えた発注者」という認識になりますので、プロジェクトは当然上手く進みます。
開発会社と良好な関係を築くためにも、発注ノウハウのポイントを押さえて開発を進められるようにしましょう。