システム開発を主導するのはIT技術者ではなく発注者【2024年最新版】

システム開発を外注する場合、外注先は発注者にどんなことを求めているのでしょうか。
IT系の発注担当者として社内で責任を持つ立場の人のなかには、IT技術の最新情報や詳細について非常によく知っている方もたくさんいます。
しかし、システム開発会社側で発注者にまず求めたいのは、そうした技術的なトレンドやプログラミング方法などに関することではありません。

システム開発会社では、「このシステム開発プロジェクトの目的」や「開発費としてどのくらい、運用費としてどのくらいの金額がかけられるか」などの、発注者しか知り得ない情報こそ知りたいのです。
システム開発会社はプロジェクトの初期段階で「要求定義」「要件定義」と呼ばれる、発注者が何をしたいのかを確定する作業を行います。
このときに「ユーザー部門同士の意見がまとまらず、システムに落とし込む方向性が見えない」「目的がはっきりしないので、一度決まったことが打ち合わせのたびにくつがえる」などの状態であると困ってしまいます。

専門の情報システム部門を持たない中小企業では、システム開発のプロジェクトリーダーとして、「ITに詳しい○○さんが担当する」というケースが多いのですが、このとき担当者の方に求められるのは、得意のIT知識で開発会社のエンジニアと対等に渡り合うことではありません。

むしろ、IT技術にさほど詳しくなくても、「現状の業務プロセスの問題点」を取りまとめたり、「新しいシステム開発で目指すべき業務システム改善の方向性」を明確化したりといったことが、発注側担当者には求められるのです。

では、「現状の業務プロセスの問題点」を取りまとめたり、「新しいシステム開発で目指すべき業務システム改善の方向性」を明確化したりするというのは、具体的にどのようなことなのでしょうか。

発注者にとって「システム開発」とはどのようにイメージしておくべきかについて、最初に確認しておきましょう。
ITシステムは目に見えないので、ここでは「オフィスビル」の比喩で考えてみます。

「新しいオフィスビルに移転しよう」という話は大体次のようなプロセスを踏みます。

この「引っ越し会社」に相当するのが、ITシステムの「開発会社」です。
オフィスビルの移転を考える場合には、１から６のプロセスを飛ばして、いきなり引っ越し会社に連絡を取る会社はまずありません。
しかし、ITシステム開発の場合には、いきなり７の引っ越し会社＝「IT開発会社」に連絡を取ってしまうというケースが多々あります。
それでは、発注側のやりたいことがうまく伝わらないのももっともだと言えるでしょう。

ITシステムの開発においても、発注に至るきちんとしたプロセスを踏むことで「ユーザー部門同士の意見がまとまらず、システムに落とし込む方向性が見えない」「目的がはっきりしないので、一度決まったことが打ち合わせのたびにくつがえる」などの問題をなくすことができます。

先程のオフィスビル移転の例で理由となったのは手狭になったスペースを確保することです。
これはITシステムで言うと、スペックの足りなくなったハードウェアを上位機種に変更することに相当します。
オフィスであれば広いオフィスに引っ越すことでたいていの問題は解決しますが、ITシステムでは、ハードウェアのスペックを上げることだけでは問題は解決しません。
ITシステムの場合には、むしろ現在の業務フローに問題があり、その業務フローの改善のためにシステム構築が解決方法（ソリューション）として求められるのが一般的です。

そのため、現状の「業務プロセス」を効率よく創造的に「ソリューション」に落とし込むことが開発会社には求められます。

ではこの、「現状の業務プロセスを効率よく創造的にソリューションに落とし込むために必要なこと」とは何でしょうか。
それがこの記事冒頭あたりで書いた発注者側責任者に求められる役割で指摘した、「現状の業務プロセスの問題点」を取りまとめたり、「新しいシステム開発で目指すべき業務システム改善の方向性」を明確化したりしておくことです。

ITシステム構築において発注者が最初に考えるべきことは、「システム構築」ではなく、現状の「業務システム」です。
現状の業務がどのように流れており、そのフローにどんな問題点があるのかを確認する、アナログ的な意味での「システム」を最初に整理することが大切です。
そのアナログ的な業務システムをデジタルのITシステムに落とし込むのが、開発会社の「システム構築」になります。
このソリューションとしてのシステム構築のイメージをいきなり発注者が考えてしまうと、システム構築において何をやっていいのかがかえってぼやけてきますので、注意しましょう。

では、具体的にどうやって「業務システム」の現状を把握したらよいかポイントを３つ挙げます。

例えば経理システムにおいては、「営業マンが経理担当者に伝票を持ってくる」などの業務の開始を知らせる明確なポイントがあります。
発注システムにおいても「営業マンが発注書を発行する」、社内稟議プロセスにおいても「稟議書を直属の上司に提出する」など、必ず業務フローの開始ポイントとなるアクションがあります。

普段の業務のなかでは、この開始ポイントをいちいち意識することなく、業務は文字通り「回っている」状態になっています。
決まりきったルーチンワークを行う場合には、この回っている感覚はむしろ大切です。
しかし業務システムを客観視して改善ポイントを割り出し、最終的にその流れをシステム構築会社に見せるには、普段意識していない開始ポイントを明らかにすることが大切です。

起点が明らかになったところで次に、業務の終点を明らかにしましょう。
これも普段は終点を迎えた時点で次の業務に引き渡していたり、同時並行で業務が流れていたりするのであまり意識されていません。
しかし終点を明らかにすることによって、起点から終点までの業務の流れが見えてくるだけでなく、業務の目的そのものを再確認することができます。

例えば、経理システムは、営業マンが経理担当者に持ってきた伝票を月末に締めて、最終的には年度の終わりに決算書を作成するという終点を迎えます。
発注システムは営業マンが発注書を発行したあと、最終的に運送業者に納品書付きの品物を引き渡すところで終わります。
稟議書は実際に予算が下りるところで終了です。
流れをユニットごとに明確にすれば、そもそもなぜこの業務が必要なのか、その目的は何なのか（財務活動の報告、商品の引き渡し、予算確保など）が見えてきます。

起点と終点が明らかになることで、現状の業務が非常にスッキリ浮かび上がりますが、これだけでシステム構築をしてしまうと、いわゆる「現場で使えないシステム」ができあがってしまいます。
なぜなら現実の業務は、起点と終点の間を一直線に流れていくだけでなく、条件によって通り道が分岐していくのが普通だからです。
例えば、営業マンが書いた伝票に不備があった場合の書き直しや、倉庫に確認をして在庫がなかったときのお客様への連絡、直属の上司に提出した稟議書類がさらに上席の役員から却下されて戻ってきたときの対応など、業務フローには条件分岐が必ずあります。
この条件分岐は会社の企業文化によっても違いますし、そうした違いがその会社の競争力の源泉であることも多いので、単純化し過ぎると業務フローの本質そのものを見逃してしまうことになりますので、注意しましょう。

こうして明らかになった「業務システム」を基にして開発会社とのやり取りを開始すれば、ソリューションとしての「システム構築」がスムーズに行きます。
システムには２つの意味合いがありますが、発注者がまず思う浮かべる必要があるのは「業務システム」であることを肝に銘じてください。

ここまで発注者側が主導して、システム構築のための準備をしていくことの大切さを解説してきました。
基本的にはこの流れに沿って発注者側が主導権を握ってシステム構築をマネージメントしていくことが必要ですが、ある程度まで現状の業務システムが把握できたところで、複数の開発業者からシステム構築の提案を募って検討するという方法があります。

現状の業務システムに関して一番よく知っているのはもちろん発注者ですが、その業務システムをどう改善したらよいか、類似した事例をたくさん知っているのはシステム開発案件を多数こなしてきた開発会社だと言えます。
もちろん、社内から上がってきている現行業務システムへの不満点、現場の改善アイデアも重要ですが、類似したケースでどうやって業務システムを改善したかの事例を知っている開発会社のノウハウはとても貴重です。

こうしたノウハウを提供してもらうのに一番いいのがRFP＝Request For Proposal（提案依頼書）です。
RFPは発注側企業が現状の業務システムを洗い出したあと、どんな解決方法があるか提案してほしいという依頼をするものです。

業者からの回答は１つではありませんので、業界で評判の良い複数の会社に提案をしてもらうのが一般的です。
例えば、ある会社は「現在の業務フローを改善するためにはオリジナルのシステム開発が必要である」という提案をしてくるかもしれませんし、他の会社は「予算を考えると○○社のパッケージを改良することで実現すべきである」という提案をしてくるかもしれません。

RFPは発注側の要求がはっきりしていないと曖昧な提案しか集まってこないので、提案書を要望する段階までにある程度きちんとした現状の業務システムの洗い出しが必要です。
また予算に合わせた提案もしてもらえますが、あまりに早い段階で予算を決めてしまうと、発注側、受注側、双方にとってリスクとなりますので注意しましょう。

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

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

いかがでしたでしょうか。
「システム」という言葉には現状行われている「業務システム」と、ソリューションとしての「システム開発」と２つの意味があることをお分かりいただけたと思います。
そして発注側は、ITシステムのバラ色のソリューションを理想形として思い描いてしまいがちですが、大切なのは「業務システム」をしっかり把握してその改善ポイントを「システム開発」に落とし込んでいくことです。

そのためには、IT技術者や開発会社ではなく、発注者が主導してITシステムの開発を進めなければいけません。
「こうした現状があります。これが改善してほしい点です。どのような改善方法がありますか？」
と主体的に開発会社の技術者とコミュニケーションを取れることこそ、発注側担当者に期待される役割だと言えるでしょう。

システム開発は自社の５年後、10年後までを託す重要な投資案件です。
導入してすぐに陳腐化してしまうとしたら、それは現行の「業務システム」をしっかりと把握せず、改善点も明確にせず、目先のIT技術の新しさに目を奪われて、バラ色のソリューションをイメージさせる提案をしてきた業者主導で開発が実行されてしまったからだと言えるでしょう。

IT技術そのものは日進月歩で進歩しますが、言い換えれば技術的な部分はすぐに陳腐化するということです。
導入した最新技術がいずれ陳腐化してしまうことは避けられませんが、本当の意味で競争力のある業務ソリューションは５年や10年では陳腐化しません。

したがって、発注段階では、主導する発注側が何をしたいのかを十分に理解した上で、長期的な視点で業務システムをシステム開発に落とし込んでくれる優良業者を選ぶことが最大のポイントとなります。

「アイミツ」にご相談いただければ、発注者の要望をとことん吸い上げてくれる経験豊富なITシステム会社をご紹介します。
ぜひお気軽にご相談ください。