情報システム開発で発注者が最も注意すべき点とは何か？【2024年最新版】

ITシステムの開発は、「基幹系システム」と「情報系システム」とに分かれます。
基幹系システムとは、財務データなどの企業活動の根幹を担うシステムや、その会社のメインの業務に直接関わるシステムを指します。
したがって何を基幹系とするかは業種によって異なります。
流通・物販などの業種では、仕入れや在庫の管理、顧客データベースの管理などが基幹系システムになりますし、製造業では工場での生産管理、金融業では勘定系などが基幹系システムになります。

これに対して情報系システムは、企業の情報システムのうち、顧客管理や営業支援、社内外のコミュニケーション円滑化や事務処理の効率化、意思決定の支援など、主に情報の伝達、共有、活用、管理などを目的として構築されます。

具体的には、CRM=Customer Relationship Management（顧客管理マネジメントシステム）やMA＝Marketing Automation Tool（マーケティングオートメーションツール）などの顧客管理、SFA＝Sales Force Automation（営業支援システム）、電子メールやwebサイト（ホームページ）、グループウェアや社内SNS、社内チャットなどの社内外コミュニケーションツールなどが情報系システムに相当します。

以前はこれらの情報系システムは「会社の主力業務に関わる基幹系システムほど重要でない」とみなされることもありました。

しかし、現在の企業活動は会社のメイン業務を淡々とこなすだけでは存続できません。
積極的に情報系システムを導入して顧客関係の深化・拡大を図ったり、トップ営業マンの属人化されたノウハウに頼ることなく全社的に営業活動を標準化したり、社内外のコミュニケーションを充実させたりすることで、同業他社と差別化を図っていく時代に突入しています。

会社のメイン業務にコンピュータを使うのは当たり前になっており、どの会社も基幹系業務に関するIT投資は一巡しているというのが現状です。
こうした状況のなか、自社のコアコンピタンス（企業の中核となる独自の強み）を確立するには、他社と比較して競争力のある独自の「情報系システム」の構築が不可欠であると考えられています。

この記事では、企業の競争力を確立するにあたって、今や基幹系システム構築よりも重視されてきている情報系システム開発で、発注者が最も注意すべき点である「他社と比較して競争力のある独自の情報系システムの構築をどのように実現するか」について解説します。

基幹系システム構築の目的は、既存の業務をIT投資によって効率化することです。
それに対して情報系システム構築では、同業他社と比較して競争優位に立てる「自社独自の業務の仕組みを確立する」ことにあります。
そのために必要なことを確認しておきましょう。

「自社独自の業務の仕組みを確立する」ためには、まず現状の情報系の業務フローがどうなっているのかを、現場から徹底的にヒアリングします。
このときヒアリングすることを開発会社に丸投げすることは厳禁です。
開発会社が同席することはもちろんかまいませんが、自社の業務フローの課題は、自社社員が一番よく認識していることなので、発注担当者がリーダーシップを発揮して、進んで現場の意見を吸い上げましょう。

情報系システム構築のポイントは実際にシステムを使うことになる現場の意見を十分に取り入れることです。

情報系システム構築が失敗する典型的なパターンとして、役員会での報告は非常に良好だったのに、現場が新しいシステムを使ってくれないということが挙げられます。

現場をうまく巻き込んで情報系システムを構築するためには、プロジェクトの初期段階で現場の意見を反映させた要求定義をまとめていくことが大切です。

具体的には、下記の点に注意しながら現状の業務を把握し、問題点をヒアリングします。

■ 業務の開始ポイントをはっきりさせる
「営業マンが経理担当者に伝票を持ってくる」「営業マンが発注書を発行する」「稟議書を直属の上司に提出する」など、必ず業務フローの開始ポイントとなるアクションがあります。

日常的には、こうした作業の開始ポイントは意識しませんが、業務の流れを客観的に把握するためには、まずこの開始ポイントを見抜くこところから始めます。

■ 終点を明らかにして業務の流れを整理する
終点を明らかにすることによって、起点から終点までの業務の流れが見えてくるだけでなく、業務の目的そのものを再確認することができます。

■ 条件分岐を分かりやすくケースごとに整理する
現実の業務は、起点と終点の間を一直線に流れていくだけでなく、条件によって通り道が分岐していくのが普通です。
この条件によって業務プロセスが変化するというパターンをきちんと拾い出すことで、現場の作業に役立つ情報システムが構築できます。

なお、ここで挙げた３点のヒアリングポイントについてさらに詳しく知りたい方は、こちらの記事もぜひご参照ください。

次に、現場のヒアリングで見えてきた業務改善の方向性を、トップマネジメント層に確認します。
トップマネジメント層に確認する前に、現場のヒアリングだけでなく、なぜトップマネジメント層の確認が必要なのかを担当者の方はしっかり理解しておきましょう。

現場レベルのヒアリングでは、「この業務フローはここが非効率的なのでITシステムによって解決したい」という、現状の業務フローの改善点を拾うことができます。
しかし、同業他社と差別化された情報システムを構築するためには、現状の業務フローを多少整理して情報システムに落とし込むだけでは不十分です。

売上、収益率などの企業活動の目標を達成するために、既存の業務内容や業務フロー、組織構造、ビジネスルールを徹底的に見直し、業務プロセスそのものを再構築するBPR（ビジネスプロセス・リエンジニアリング）が求められます。
こうした既存の業務の流れを抜本的に改革するプロジェクトは、現場の責任者だけでは手に負えません。

業務改革の権限を持ち、会社の大局的な目標達成に責任を持っているトップマネジメント層を早めに巻き込んで、既存の業務を反映するだけではない、競争力のある情報系システム構築を目指していきましょう。

情報システムの発注に慣れていない担当者が陥りがちなミスとして、情報システムの完成形を中途半端に伝えてしまうことがあります。
まだ完成していないシステムを伝えるのは困難なので、ついつい大手の情報システムのパンフレットカタログなどを取り出して「こういうマーケティングオートメーションツールを作りたい」というところから話を始めてしまうケースがありますが、これはやってはいけません。

なぜなら、そうすると開発会社の担当者の頭のなかに、そのマーケティングオートメーションシステムのイメージが強固に植え付けられてしまうからです。
同時に、目の前で商談中のクライアントが抱えている問題を、自社がこれから構築するシステムで解決しよう、という部分が薄れてしまいます。

情報システムの構築を外部の業者に委託して開発してもらう目的の第一は、自社の情報システムが抱える問題の解決です。
その問題がパンフレットに載っている有名なツールで解決できるのならば、最初からパッケージとして販売されているその製品を購入すれば済む話で、わざわざ自社用にオリジナルのマーケティングオートメーションツールを構築してもらう意味がありません。
おそらく、開発会社の担当者にイメージを伝えるのが難しいからという理由で、製品展示会など手に入れたカタログを片手に説明を始めてしまうようなケースでは、そのマーケティングオートメーションツールが本当に自社の問題解決に役立つのかどうかも実はまだきちんと検証していないというケースがほとんどでしょう。

こうした場合は、開発会社にとって有利なように、話を進められてしまいがちです。
例えば、パッケージにある開発難易度の高い機能を省き、自社が過去に開発して社内にプログラムのソースコードが資産として蓄積されているものを寄せ集めて、新規開発の原価をほとんどかけずに似たようなシステムを納品されてしまうこともあるでしょう。
結果的に、自社の問題解決にぴったりのシステムができ上がるという場合もあり得ますが、それはたまたま運が良かったということに過ぎません。

情報システムの開発で最初に行うべきは、完成形のイメージを作ることではなく、「情報システム開発の目的」や「自社の抱える情報システム上の問題」を正しく開発会社の担当者に伝えることなのです。

ここまでで、情報システムを構築する上で必ず注意しておくべき重要な点を整理しました。
次に、具体的に開発が進んでいき、最終納品に至るまでに注意しておく点について、これまでの解説と重なる部分もありますが時系列に沿ってまとめます。

情報システムを構築するときに「顧客管理システムを作りたい」「営業支援システムを作りたい」といった完成形のイメージだけを開発会社に伝えることはやめましょう。
ついついこのような話をしてしまいがちですが、ここにはシステム開発の「目的」が欠けているのです。

目的を伝えるために必要なのは「見込み客が成約に結び付かない失注率をなんとかしたいので、顧客管理システムを作りたい」「営業マンのノウハウが属人化してしまって社内資産となっていないので、営業支援システムを作りたい」といった問題解決に踏み込んだシステムのイメージです。

このような形で説明すれば、開発会社も自社で扱った類似案件などを思い浮かべて、最適な提案をしてくれるでしょう。

ここでいう問題点とは、既存の使い勝手の良くないITシステムの問題点でもよいですし、手作業でやっている作業をシステム化しないと時間がかかってしょうがないという、業務プロセスの問題点でもかまいません。
問題点を明らかにしたあと、システムを改善したい、あるいはシステム化したい理由や背景を記述し、なぜ新しいシステムが必要なのかを明確に伝えましょう。

例えば「見込み客が成約に結び付かない失注率をなんとかしたいので、顧客管理システムを作りたい」という問題点を伝えたときに、「失注率を改善したいのならば、既存の顧客を含む顧客管理システムというよりは、新規開拓した顧客を半自動で成約に結び付けていく、マーケティングオートメーションツールなどのようなリードナーチャリングツールを作ったほうが良いのではないか？」という提案が出てくるかもしれません。

また、「営業マンのノウハウが属人化してしまって社内資産となっていないので、営業支援システムを作りたい」という問題に対しては、「SFAのような営業支援システムは、案件管理に向いているので、営業マンのノウハウを社内で共有したいのなら、日報管理システムを構築したほうが良いのではないのか？」という提案が出てくるかもしれません。

問題点を正しく伝えることから、業者との生産的なコミュニケーションがスタートするのだということを押さえておきましょう。

発注担当者の方のなかには、問題の解決方法まで発注側で考えて開発業者に伝えなければならない、と思っている方もいます。
しかし、最終的には発注者側でオーソライズするにせよ、解決方法についてのアイデアはどんどん開発会社から提案してもらうべきです。

「リードナーチャリングツールを作ったほうが良いのではないか？」という提案が出てくれば、「リードナーチャリングシステムを構築すると、どんなふうに失注率が改善できるのですか？」という、発注者側からの問いかけができます。業者との関係がこうなってくれば、システム構築はかなりの確率で成功します。

業者からは、リードナーチャリングシステムを実現するにあたって、例えば下記のようなメニューが出てくることでしょう。

■ リード情報管理
■ メール配信
■ フォーム作成
■ スコアリング
■ ホットリード
■ リードナーチャリング
■ セグメンテーション
■ オフラインチャネル対応
■ マーケティング分析
■ シナリオ作成支援
■ オプション
■ SFA（営業支援システム）へのデータ引き渡し

こうしたメニューをインターネットや紙のカタログなどを参照して、いちいち確認する必要はありません。
そのような時間があるのなら、複数の業者から提案を募るためにRFP=Request For Proposal（提案依頼書）を作ってたくさんの業者から意見を出してもらいましょう。

冒頭に指摘したように、情報系システム構築は、システムを導入することによって同業他社よりも競争優位なポジションを獲得することが目的です。

そのためには、「今ある業務フローを自動化する＝情報系システム構築」ととらえずに、「今ある業務システムをより優れたものに改善する＝情報系システム構築」と考えることが大切です。

だからこそ、現場レベルの要求定義をきちんとヒアリングする上流工程だけでなく、BPRに踏み込んだ新しい業務システムの構築を考える超上流工程が必要になってきます。
この段階では、トップマネジメント層に積極的に情報システム開発プロジェクトに関わってもらうことが大切です。

要件定義まででき上がったら、あとは詳細な設計を開発会社が開始する開発段階に移っていきますが、このとき大切なのは、開発方法について発注側からきちんと希望を伝えることです。

システム開発の方法には大きく分けて、「ウォーターフォール型開発モデル」「プロトタイピング型開発モデル」「アジャイル型開発モデル」がありますが、それぞれまったく違う特色を持っています。

情報システム開発では、発注者側がどんなシステムにしたいのかについて、開発が始まってからも積極的に関与していくことが求められます。決して開発方法を業者任せにせず、自社の案件に適した開発をしてくれる業者をピックアップしていきましょう。

簡単にまとめると、「ウォーターフォール型開発モデル」はプロジェクトを進める段階でどのようなシステムを組みたいかが明確になっている場合に適しています。
「プロトタイピング型開発モデル」はプロジェクト途中で完成形のプロトタイプを確認しながら進めたい場合に適しており、「アジャイル型開発モデル」は開発の優先順位そのものを途中で見直していくプロジェクトに適しています。

伝統的な開発手法であるウォーターフォール型開発は、仕様決定の工程までは発注側も積極的にプロジェクトに関わっていきますが、いざ開発が進んでしまうと、最後の納品まではノータッチということが一般的です。

この間、本当に希望通りの情報システムができ上がるのか非常に不安である、という場合には、開発フェーズごとに完成品のプロトタイプを作って発注者に確認してもらうスタイルのプロトタイピング型開発を指定したほうが良いかもしれません。

また、市場の反応や同業他社の情報などをにらみながら、常に新しいシステムを模索していきたい、という場合には、最終的な納品を前提としないアジャイル型開発が向いています。
アジャイル型開発では、最初にプロジェクトチームを結成しますが、このときのプロジェクトチームのメンバーは開発会社からだけではなく、発注側企業からも人選します。
発注担当者が加わるのは当然として、あとは現場の業務の責任者、さらにトップマネジメント層からBPR推進に関して権限のある役員などに参加してもらうとよいでしょう。

アジャイル型開発では、1つの開発が終わるたびにその小さな完成品をチームで評価し、その評価をもとに、新しい開発の優先順位を決めていきます。
したがって、現場のユーザー代表者と、BPRについての意思決定の権限がある役員が参加していれば、情報システム開発のスピードが非常に素早くなります。

＊それぞれのモデルの詳しい説明は、こちらの記事にて詳しく解説していますので、ぜひご参照ください。

せっかく納品してもらった新しいシステムを、現場が有効活用するようになるまで支援してもらうことも必要です。
具体的には下記のような運用・保守メニューを検討して、新しい情報システムが現場に根付くまでサポートしてもらいましょう。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、情報系システム開発は基幹系システム構築と違い、同業他社よりも競争優位のポジションを獲得するための仕組みであることを整理してきました。
また、新しい業務の仕組みを確立するために必要な、システムを導入したあとそのシステムが現場のスタッフに受け入れられることの大切さ、トップマネジメント層を早めに巻き込んで、現場の意見を会社全体の問題解決に引き上げることの重要性などにつき解説しました。

実際に開発がスタートしてからは、開発会社に丸投げにせず、自社にとって最適な開発方法を指定していく積極的な姿勢が求められますが、このためには業者選びが重要な意味を持ちます。

「よし、現場の責任者とBPR推進に権限のある役員に参加してもらい、アジャイル型開発でいこう！」と決めたとしても、発注先候補として考えていた開発会社が「ウォーターフォール型開発」しか経験がなく「アジャイル型開発」には対応できないこともあり得ます。実際のところ、候補に見合った業者をていねいに探していく手間はかなりかかるのが普通です。

また、BPRなどまで視野に入れた情報システムの開発プロジェクトで、全社的な問題解決まで見据えた上で最適な提案をしてくれるシステム開発会社を見つけることも容易ではありません。
開発会社との間にコンサルティング会社を入れるという方法も考えられますが、その場合でも最初の開発会社のピックアップにはそれなりのノウハウと時間が必要です。

情報システム構築に強い会社の候補選びに困ったら、ぜひシステム開発業界の情報を豊富に持っている「アイミツ」にぜひご相談ください。

御社のプロジェクトにぴったりの開発スタイルを得意とする会社選びはもちろん、ITコンサル会社、コンサルも手がける開発業者、さらに新しい情報システムが社内に定着しするまでのサポート対応してくれる業者など、さまざまなタイプのパートナー候補をご紹介いたします。