システム開発をする前にシステム発注ノウハウを身につけておこう

システム発注に関する知識を学ぶ

更新日:2017年09月06日 | 公開日:2017年09月06日

システム開発は、自社内で行うのではなく外部のシステム構築会社に依頼することが基本です。
では、技術力があり、実績や信頼性も十分なシステム開発会社を選べば必ず成功するのか、と言うとそうでもありません。

発注者側がシステム開発会社をランク付けして候補を絞り込むように、実はシステム開発会社の方でも発注者をランク付けしています。
もちろん、あからさまにランク付けして、ランクの低いクライアントの仕事はしない、という態度を取ることは稀です。
しかし、「このクライアントとはプロジェクトがうまくいきそうだ」とか、「このクライアントとの開発プロジェクトは開発終了まで注意が必要だ」という認識は開発会社の内部で共有されています。

「仕事は引き受けるが、要注意だ」という認識を持たれてしまった場合、追加の要求仕様をなかなか聞いてもらえなかったり、リスクを見越して見積もりを高めに出されてしまったりすることもあります。
また、発注者が最低限ここはお願いしたいということは設計図に落とし込みますが、「もっとこうしたほうが、御社のシステム開発の目的を確実に達成できます」というような、積極的な提案はリスキーなのでしないでおく、という判断をされてしまう場合もあるでしょう。

では反対に、開発会社から見て評価の高い発注者とはどんな要件を備えているのでしょうか。
それは、システム開発の発注経験がそれほどなくても、「システム開発の2大リスクを回避する発注ノウハウをきちんと押さえている会社」です。
開発会社から見て「このクライアントとは仕事がやりやすい」という評価が得られれば、追加の要求仕様などへの柔軟な対応、リスクを織り込んでいない見積金額、開発の目的を汲み取った本当の意味でクライアントの望んでいることを解決するためのシステム提案などが期待できます。

この記事では、開発会社と良好な関係を築きシステム開発を成功に導く「発注ノウハウ」について解説します。

むだな仕様変更のない発注を行うためのノウハウ

パソコンで発注のための仕様をまとめる

システム開発が成功するか否かに大きなウエートを占める重要な工程が「要件定義」です。
要件定義とはシステム開発において、実装すべき機能や満たすべき性能などを明確にしていく作業のことを指します。
実際に機能に落とし込んでいく部分はシステム開発会社が行いますが、要件定義に先立って、そのシステムを使って何がしたいのかという「目的」、何ができなければ困るのかといった「課題」をはっきりさせる「要求定義」は発注者が主体となって明確化していくことが必要です。

発注ノウハウを押さえているクライアントは、この「要求定義」の明確化作業がとてもスムーズです。
自分たちがシステム開発を通じて何をしたいのかをはっきりさせることができれば、どんなシステムの要件が必要なのかも自ずと決まってきます。
逆に、自分たちのやりたいことや課題がはっきりしないまま、システム開発会社に「要件定義」策定を丸投げしてしまうクライアントもいます。

そうしてでき上がった要件定義では、プロジェクトが始まってからに必ずと言っていいほど本来なら不要な「仕様変更」や「仕様追加」が生じます。
発注側からすると、自分たちが発注したプロジェクトなのだから、途中で「やっぱりこういうシステムにして欲しい」とか「このあいだ同業者のサイトを見たら、こんな機能もあって便利そうなので、それも加えておいて」「ちょっと追加でお願いしたい箇所が出そうなので、いったん開発を進めるの待って」などのリクエストに開発会社が対応するのは当然だ、という意識もあるかもしれません。

しかし、それは大変な認識違いです。
システム開発にとって、いったん決まった仕様をひっくり返すのは言わばご法度です。
この仕様の変更はいわゆる「手戻り」(工程をまたがるやり直し)「手直し」(工程内でのやり直し)「手待ち」(仕様の不備があって工程そのものがストップする)というシステム開発ロスの元凶となります。
こうしたことが度重なれば、システム構築会社にとって、そのプロジェクトは大きな赤字を生みかねないものになってしまいます。

開発の初期段階で発注者が注意すべきことは、「仕様変更のないプロジェクト」を目指すことであり、具体的には、発注者側で「要求定義」をきちんと明確化することです。
ではその方法を見てみましょう。

仕様変更のない要求定義はこうやって作る

「要求定義」の段階では、プロジェクトの目的に沿って目標をすべて列挙することが必要です。
言い換えれば、予算的な制約や納期の縛りなどを一切なくして、理想的にはシステム開発でここまでやりたい、というMAXの要望を列挙することが大切になってきます。

多くのシステム開発では、中途半端に予算や納期のことを考えながら要求仕様を固めていきますが、これは一見現実的で手堅い方法に見えて、途中で「手戻り」「手直し」「手待ち」を生んでしまう原因となります。

いったん、そのプロジェクトの理想形を明確にし、その後、さまざまな制約条件を加味して実現可能な機能を絞り込むという流れで、プロジェクトの「範囲」を決定するというのが、途中の仕様変更を排除するために有効です。

こうしたプロセスを経ておけば、ライバルサイトなどを見たときに「この機能も欲しい!」と思っても、「そういえば、この機能も最初に検討したのだけれど、予算的な部分で今回は断念したのだった」という結論に落ち着きます。

したがって、プロジェクトの「範囲」を決定するときには、関係各部署の責任者が共通の認識を持っている必要があります。
会議など関係者が一堂に会する席上で「範囲」を決定しておけば、別の部署から「こういう機能も欲しい」というリクエストがあったとしても、「それは最初に予算的都合で却下されています」という回答が可能です。
そうしたプロセスを共有していなければ、力関係で勝った部署の要求を強引に追加するといった事態が生じ、プロジェクトの円滑な進行に大きな支障が出てきます。

スムーズな受け入れテストを実施するための発注ノウハウ

システムの受け入れテストの準備を行う

「受け入れテスト」とはシステム開発が終了し、最終的な納品物が発注者の本来の目的や意図通りに稼働するかどうかを検証することです。
この受け入れテストを開発の終盤になって慌てて整備するというプロジェクトもありますが、そうしたプロジェクトは限りなく失敗に近い、もしくはすでに失敗していると言っても過言ではありません。

本来、どのような受け入れテストに合格すれば「発注者の本来の目的や意図通りに稼働する」ことになるのかという項目は、発注時に明確になっていなければなりません。
そのことによって、開発現場での開発途中での振れもなくなります。
迷ったときに「最後にこういうテストを行うが、パスするだろうか」という視点で開発を客観的に検証できるからです。

また、「こういう機能が欲しいと伝えたはず」「それは候補にはありましたが、予算的な都合で今回の開発範囲に入っていません」というように発注者側と開発側の主張が食い違った場合でも、テスト項目を確認することでどちらの認識違いであるかがすぐに分かります。

なお、業務請負の場合、最終的に納品物が当初の設計通りかどうかによって、その契約が有効か無効かが決まります。
したがって、客観的に双方が納得したテスト項目にパスすれば、自動的に契約が完了するという分かりやすい円満な納品完了(プロジェクト終了)が期待できます。
「こんなものは完成品と認められない」(発注側企業)「いや、仕様書通りに作ってあります」(開発業者)という泥沼の争いを避けるためにも、発注時にテスト項目を書面で明確にしておきましょう。

受け入れテストの評価ポイント

それでは、具体的に最終納品物の受け入れテストをどのように評価するかについてまとめます。

受け入れテストの評価ポイント
  • エンドユーザーの通常業務を問題なく遂行できるか
  • システムの操作性に問題はないか
  • イレギュラーな状況に対応できるか
  • ユーザー操作マニュアルは分かりやすいか
  • セキュリティや権限設定に問題はないか

それぞれの項目について見てみましょう。

エンドユーザーの通常業務を問題なく遂行できるか

要件定義、基本設計で作成した業務フローにもとづいて、エンドユーザーが滞りなく操作可能かを検証します。
機能ごとにエクセルで表を作り、そこにエンドユーザーの評価を書き込んでいきます。
動作が意図通り行われない箇所や、複数のエンドユーザーが使いにくいとしている箇所などについて検証を進めます。

システムの操作性に問題はないか

画面構成・色などが見やすいか、画面表示内容は正確か(視認性)、手間が多くないか、操作ミスをしやすくないか(操作性)、待ち時間や画面遷移スピードが妥当か(ユーザビリティ)などを確認します。
これも、項目ごとにエクセルで表を作り、複数のエンドユーザーに評価を書き込んでもらいましょう。

イレギュラーな状況に対応できるか

万が一システムに不具合があった場合に、どのように復旧できるかを検証します。
クライアント側のシステム再起動で対応できるのか、システム管理者がサーバー側で対応する必要があるのか、どのような場合に開発会社に保守の依頼をするのか、などを確認します。

ユーザー操作マニュアルは分かりやすいか

システムに習熟していないエンドユーザーでも、マニュアルを参照すれば業務を遂行することができるか、日常業務と違う業務を引き継いでも、マニュアルを参照すればシステムを使った業務が問題なく継続できるかなどを検証します。

セキュリティや権限設定に問題はないか

外部からの不正侵入に対して適切な対応が取れているか、社内からのログインで権限のない者が不必要にシステムの機能を使用することに制限が設けられているかなどをチェックします。


こうした点について発注時に明確にしておけば、間違いのない受け入れテストを実施することが可能です。

システム発注ノウハウがあれば、優良開発会社が見つかる

優れたシステム開発会社をパソコンで探す

いかがでしたでしょうか。
システム開発会社がプロジェクトのリスク回避のため、追加の要求仕様を拒んだり、リスクを見越して見積もりを高めに出したり、積極的な提案はリスキーなのでしないでおく、などの防衛手段を取っているということを知らなかった発注担当者の方は、ショックを受けたかもしれません。

しかし、システム開発会社もビジネスである以上、クライアントをランク付けして、自社のリスク管理をしながらプロジェクトを引き受けるというのは当たり前のことでもあります。
初めて会社の口座を開くときには、信用調査会社に与信調査をかけたりするのと同じように、システム開発会社もある意味でクライアントを選別しているのが現実です。

しかし、この記事で紹介した「仕様変更のない要求定義の作り方」「受け入れテストの評価ポイント」を発注者が押さえておけば、システム会社からの評価は問題のない水準をクリアできます。
システム開発会社にとって、途中の仕様変更と受け入れテストでのどんでん返しというのは、最も注意すべき2大リスクですので、この点まったく問題のないクライアントは最優良顧客です。

とはいえ、「仕様変更のない要求定義」「間違いのない受け入れテスト」の重要性は認識しながらも、それを自社のみで作り上げてシステム開発会社に提示することにはかなりのハードルがある、と感じる発注者の方も多いでしょう。

そんなときは、さまざまなシステム構築会社の情報を保有している「アイミツ」にぜひお声をおかけください。
「仕様変更のない要求定義」「間違いのない受け入れテスト」作りのノウハウを共有しつつ、プロジェクトを成功に導いてくれる優良システム構築会社をご紹介いたします。

いま知りたいこと
コンシェルジュが解決します!

コンシェルジュサービスは
5万社以上が利用している無料の相談サービスです。

コンシェルジュ