03-5835-2820
平日9:00~18:00
Zoom等オンラインでのご相談も可能です
ご相談はオンライン対応可能

最終更新日:2021年7月13日

システム開発を外注するとき、不明点が多く不安に感じることが多いかと思います。この記事ではそのような不明点や不安を解消すべく、システム開発の外注の仕方を紹介します。

外注する際に知っておきたいシステム開発の流れや、実際にアクシアに発注をしたお客様を見てきて感じた気をつけるべきポイント、より良いシステムを作るために、お客様に協力していただきたいポイントをまとめました。この記事がお役に立ちましたら幸いです。

システム開発外注の流れ

最初に、システム開発を外注するときの流れを把握しておきましょう。

  1. 発注側の事前準備
  2. 見積もり
  3. 契約(発注)
  4. 設計・開発
  5. 導入・納品
  6. 運用

1.発注側の事前準備

システムを発注したいと決まったら、依頼するシステム会社を検討しましょう。依頼〜システムの完成までには数ヶ月かかかるため、決まったら早めに検討を行うのが吉です。そして、どんなシステムを作りたいのかをシステム会社に伝える必要があります。

  • なぜシステムを作ろうと思ったのか
  • システム開発の目的(システムを作ることでどのような効果を得たいのか)
  • 解決したい課題
  • 納期
  • 予算

など、要件を明確にしておきましょう。事前準備の段階で要件が具体的に定まっているほど、見積もりの精度が高くなります。

提案依頼書を作成するのも一案です。提案依頼書作成については、以下の記事で紹介しています。

2.見積もり

相見積もりなどをして、依頼するシステム会社を決定します。見積もりの見方についてはこちらの記事にまとめています。

3.契約(発注)

依頼する会社を決めたら契約書を取り交わし、契約成立となります。

4.設計・開発

システム会社が仕様を具体的に決めて、設計・開発に着手し完成を目指します。

要件定義
外部設計
内部設計
プログラミング
単体テスト
結合テスト
システムテスト
運用テスト

のように進んでいきます。要件定義と外部設計のフェーズは、顧客側の協力が不可欠です。詳しい流れは以下の記事で説明しています。

5.導入・納品

数々のテストを行い品質を確かめた後、納品を行います。

6.運用・保守

完成したシステムを実務で使っていきます。運用とセットであるのが保守業務で、システムの環境に異常がないかを日々監視し、万が一障害が発生した場合に対応します。

また、システムを使用していて要望や改善点が見つかったらフィードバックをいただき、改善してより使いやすいシステムを構築することも保守業務に入っています。

保守についてはこちらの記事で詳しく説明しています。

システム開発を外注するときに気をつけるポイント

システム開発の成功率はたったの3割といわれていますが、きちんと抑えるべきところを抑えておけばそれほど恐れることはありません。システム開発に成功する会社と失敗する会社には、ある程度パターンがあります。今までアクシアで見てきた顧客のパターンから、システム開発を発注する時に注意しておくべきポイントを抽出しましたので紹介します。

本気で取り組む覚悟を決める

いきなり精神論のようで申し訳ないですが、これが一番大事です。顧客側のやる気がないと、ほぼ間違いなくシステム開発は失敗します。よくあるパターンとしては、上司からシステム開発を外注するように指示されて担当になった部下のやる気が全くないというパターンです。

システム開発というのは顧客側と開発会社側で一緒にプロジェクトとして進めていく必要のある仕事です。顧客側もやるべきことをしっかりやってくれないと、システム開発のプロジェクトは進んでいきません。システム開発を担当する責任者となる人にやる気がないようであれば、すぐに担当者は変えるべきです。

顧客側にやる気がないことほど開発会社側として仕事を進めにくいことはありませんから、システム開発を行うと決めたのであれば、絶対にやり抜く覚悟を決めてからご発注いただければと思います。

ITの素人であることを言い訳にしない

システム開発を行うと決めた以上は、ITの素人であることを言い訳にしないでください。当たり前ですが、システム開発に成功している企業のほとんどはITの専門企業ではありません。

何もプログラミングをしてくれとかデータベースの設計をしてくれとか、そういう専門知識を要するようなことを顧客にやってもらうようなことは一切ありません。ただし普段からシステム開発を行っているわけではないでしょうから、見慣れない資料を読み込まなければならないこともありますし、聞いたこともないような話題を打ち合わせで行わなければならないこともあります。

その時に「私はITについては素人なのでそっちでやってくれ」みたいなことを言わないでください。普段慣れないことをやるのは辛いかもしれませんが、必死でついてきてください。

人売り企業には絶対に発注しない

この業界のざっくりと8割くらいは人売りとか人月ビジネスと呼ばれるようなことをやっている、実質派遣なのに請負契約や準委任契約のように見せかける偽装請負の企業です。私のブログでは人売り企業については色々と詳しく書いてますが、下記のブログがよくまとまっています。

スラムダンクで安西先生が「あきらめたらそこで試合終了」という名言を残されていますが、IT業界では「人売り企業に発注したらそこで試合終了」という有名な言葉があります。嘘です。私が今勝手に作りました。

とにかく人売り企業と取引して良いことなど何もありませんので、発注先はまともなシステム開発会社を選んでください。※念のため、人売り企業とは偽装請負をやっている違法な会社のことを指しており、まっとうな派遣企業様とは異なります。

見積内容は正確に把握する

システム開発と名乗る会社の中には、見積書に「システム開発費用 一式」とだけ書いて出してくる会社がたくさんあります。こういうのははっきり言って論外です。後でトラブルの元になります。

「一式」だと、何がどこまでその費用の中に含まれているかわかりません。そうすると、どこまでが見積もりの費用内で対応できて、どこからが追加見積もりとなるのかの線引もできません。こういう見積もりを出してくる会社はおそらく人売りをやっている会社であって、請負契約の見積もりなどまともにできないためにこんな感じで適当な見積書しか作れないのだと思います。

当たり前ですが、曖昧なままにしておいた方が後でシステム会社側に仕様変更を無料で押し付けることができる、などと変なことは考えないでくださいね。

初期開発では最小の機能構成で開発する

システム開発の時に機能を大きく3つに分類するとこうなります。

  • 絶対に必要不可欠な機能
  • あった方が良さそうな機能
  • なくても困らない機能

このうち「絶対に必要不可欠な機能」は開発するのはもちろんですし、「なくても困らない機能」は開発しなくて良いでしょう。問題は「あった方が良さそうな機能」です。

よくあることですが、システム開発を行う時に顧客はいろいろな夢に胸を膨らませてしまいます。あんなこといいな、できたらいいな。みたいな感じで。でもシステム開発会社は残念ながら、ドラえもんの不思議なポッケではないんです。なんでもみんな叶えてくれるわけではありません。

システムが完成して運用が開始されると、「作ったけど使われない機能」というのが出てくることがあります。こういうのはたいてい「あった方が良さそうな機能」を作ったことによって生じます。作ってはみたものの実際には別に無くてよかった、となってしまうわけです。

逆に散々検討を重ねてシステムをオープンさせたけど「作ってないけど必要な機能」というのが出てくることもあります。これはどれだけ検討を重ねたところで発生しうることですし、別に悪いことではありません。成功しているシステムであるほど運用後の仕様変更の必要性はたくさん出てくる傾向にあります。

いずれにしても、本当に必要な機能を把握するためには「実際に運用すること」が何よりも重要です。最小の構成で費用と時間を最小に抑えて、システムカットオーバーまでのサイクルを最短にすることがベストです。

あれもこれもと色々と機能を盛り込んでしまい、不要な機能をふんだんに盛り込んだ挙句、システムの運用開始が遅れてしまうようなことのないようにしましょう。

発注時期には余裕を持つ

システム開発を思い立ったら、早めに開発会社に相談してください。システム開発には数ヶ月単位で開発期間を要することがほとんどです。いきなり相談してきて「今月中にシステムの利用を開始したい」と言われても無理なんです。

無茶なスケジュールを開発会社に強要しても、良いことは何一つありません。無茶なスケジュールを要求された開発会社は、それに対応するために残業や徹夜で対応することになります。そうするとどうしたって品質は低下しますし、最悪の場合はデスマーチに突入していつ納品されてくるのかもわからない状態になってしまいます。

開発期間がどれだけ必要であるかはシステムの規模等によっても変わってくるので一概には言えませんが、アクシアで開発するシステムは平均してだいたい2~6ヶ月くらいの開発期間がかかっています。発注前の検討期間も含めるとさらに長くなると思いますので、できるだけ早めに開発会社に相談してください。

開発会社に丸投げは厳禁

「システム開発外注の流れ」の項で紹介したように、システム開発はプログラミングだけではありません。システムに必要となることを要件定義したり、システムの具体的な形を決めていくための設計もあります。システムが納品されてくれば検証作業も行っていく必要があります。

システム開発全体の工程の中には、要件定義や設計など、顧客と開発会社で協力して行っていかなければならない作業も少なくありません。そうした作業を開発会社側に「後はよろしく」と丸投げしてうまくいくほど、システム開発のプロジェクトは簡単ではありません。

システム開発は顧客の業務を見直したり、新しく顧客の事業を作っていくようなことも含まれていますので、どうしたって顧客側の協力も必要不可欠となります。発注先の会社に投げっぱなしとならないようにしてください。

担当者の窓口は一本化する

システム開発のプロジェクトを進めていく上で、ああでもない、こうでもないと何度もシステムの仕様について検討していくことになります。検討過程の中で仕様は二転三転していきますし、機能間や会社の部署間で矛盾したような仕様が出てくることも珍しくありません。

その時に最新の仕様、正しい仕様を整理するためにも、顧客側の担当窓口(責任者)は一本化した方がスムーズです。そうしないと収集がつかないようなことにもなりかねません。

最悪なのは、顧客側の各従業員に好き勝手に希望する機能の仕様を開発会社側に話をさせることです。各従業員は会社全体で最適化されるように考えるようなことはしませんから、それぞれが自分勝手な要望を出してきて全体として無駄だらけ、矛盾だらけの状態に陥ってしまいます。

情報の交通整理するために顧客側の担当者が責任者となって窓口となることは、各従業員の話を取りまとめたりする必要があるのでかなり大変です。大変なので各従業員に開発会社側と直接連絡を取るようにしてしまう担当者がたまにいるのですが、それでうまくいくようなことは絶対にないのでそういうことはやめてください。

仕様書には穴が空くほど目を通す

システムの仕様について検討を重ねていく中で、開発会社側が仕様書(設計書)を作成して顧客側と共有します。もしドキュメントを一切残さない開発会社だった場合には、やばいと思ってください。

仕様書はそれなりのボリュームになることが多いのですが、この仕様書は絶対に内容のチェックをしてください。この仕様書通りにシステムは構築されてきますし、後で「言っていた内容と違うから直してくれ」と言ったとしても、仕様書に書かれていた通りであれば仕様変更となって追加の費用が発生します。

後から騒いだところでどうにもなりません。仕様書の確認を怠った顧客側の責任となります。厳しいように思われるかもしれませんが、別に厳しくもなんでもありません。仕事なんですから仕様書を確認することは当たり前のことです。

システム開発というのは、形のないものを構築していく作業なわけですから、注意しないと仕様に対する認識違いということが発生しやすいと言えます。だからこそドキュメントに取りまとめて顧客側と開発会社側で認識齟齬が発生しないようなステップが必要となります。

普段見慣れないドキュメントですし量もそれなりですし読むのは大変かもしれませんが、大変だからといってサボらずに、必ず仕様書は確認するようにしてください。やるべき仕事をさぼって確認を怠ったのに、そのツケを後で開発会社側に負わせようとするのは筋が通りませんよ。

システムを利用する現場の人達の理解が必要

これはシステム開発に限った話ではありませんが、新しいやり方を導入するときというのは、現場の人達の理解や協力が必要不可欠となります。

新しいシステムを導入する時というのは、会社によっては抵抗勢力のような人達が出てくるようなこともあります。そうした時に一部の人達が抵抗することによってシステムが正しく使われないようになってしまうと、共有されるべき情報が共有されなかったりしてシステムが形骸化してしまいかねません。

例えば新しく顧客管理システムを導入しようとした時に、各従業員が顧客の情報を正しくシステムに登録してもらわないとどんなに素晴らしいシステムを作ったところで機能しなくなってしまいます。意地でも顧客情報をシステムに入れずに、自分の手帳で管理しようとするような人がいると厄介です。(実話)

そんなことにならないように、現場の人達にシステムを利用する会社全体としてのメリットや意義を理解してもらったり、会社そのものの仕組みを変えることによってシステムを正しく利用しないと評価が上がらないようにしたりするなど、システムが有効活用されるように工夫してもらうことは顧客側のやるべきことです。

システムはあくまでもツールであり道具ですので、どんなに素晴らしいツールであったとしてもそれが有効活用されるかどうかはそれを使う側の問題となってきます。

よりよいシステムを作るために、お客様に協力してもらいたいこと

前項では耳が痛い話もいくつかしましたが、すべてはお客様が使いやすい、「導入してよかった」と言っていただけるような良いシステムを作りたいという思いから来ています。

この項では、より良いシステムを作るためにお客様側にも積極的に関わってもらいたい事項をまとめました。

開発会社に丸投げしない

繰り返しになりますが、開発会社に丸投げするのは厳禁です。開発会社はシステムの専門家ですが、お客様の業務に関しては誰よりもお客様ご自身が熟知しているはずです。お客様が抱えている問題を解決するためには、業務に関して一番熟知しているお客様のご協力が不可欠なのです。

より使いやすいシステムを作るために、情報提供やどんな機能が欲しいかなど、一緒に作りたいシステムについて考えていただくことが必要となります。お客様と開発会社でワンチームとなってシステム開発のプロジェクトを進めていくのが理想だとアクシアでは考えています。

基本的なIT知識をわかろうとする姿勢を

開発会社側で知識がなくともわかりやすい表現をするように努めていますが、システム開発では、どうしても専門用語や横文字が多く使用されがちです。

基本的なIT知識を持っていただけることで、システム開発で実現できること、できないことが理解できるようになり、共通認識ができあがりやすくなります。理解が深まるとコミュニケーションが取りやすくなり、円滑に開発を進めることができます。

ITに苦手意識を持つ方の気持ちもよくわかりますが、知識を持つことでより使いやすいシステムが構築できるため、少しでも歩み寄っていただけると幸いです。

綿密なコミュニケーションを取る

綿密なコミュニケーションを取ることで具体性が増し、開発が円滑に進みやすくなります。コミュニケーションが不十分だと、例えば「ここの機能はこうしよう」と言った・言わないの議論が起きるなど、進行の妨げが発生することがあります。

このような事態を防ぐために、文章ベースのメールやチャットツールを活用し、こまめにコミュニケーションを取ることをおすすめしています。また、定期的なミーティングを開催し、進捗や気付いた問題、気になったことの共有を行うと、お互いの不明点がクリアになり進行がスムーズになります。

システム開発は作ったら終わりではない

システム開発は完成したらゴールではありません。システムを本稼働させてからが本番です。実際に完成したシステムを運用していくと、問題点や気づくことがどうしても出てきます。発生した問題点や気づいたことを開発会社に問い合わせしていただき、改善をすることでより良いシステムへと変わります。

システム保守は障害対応の他に、このように改善を行う意味でも重要な役割を果たしています。

作って終わりでほったらかしでは、お客様の業務を深く理解したうえでの本当に有効な提案はできないとアクシアは考えています。運用開始してから改善したいことや要望を問い合わせ対応で汲み取り、より使いやすいシステムに改善していくことを日々心がけています。

積極的に関わっていただきたいポイントとは少し違いますが、より良いシステムを作るためにとても大事なポイントなのでご紹介しました。

失敗しないシステム開発の外注の仕方・まとめ

システム開発の外注の仕方やポイントについて長きにわたってご説明しましたが、いかがでしたでしょうか。おそらく、多くの方が「思っていたよりも覚悟を決めて、本気で取り組まなくてはならない」と感じたことと思います。実際にシステム開発成功のキーポイントは、「本気で取り組む覚悟を決めて、やり抜くことができるかどうか」だと私は考えます。

システム開発のプロジェクトは簡単ではありませんが、やるべきことをきちんとやっているのであれば、それほど恐れるものでもありません。逆に顧客と開発会社の両社が本気になって取り組んだプロジェクトが失敗する確率は、極めて低いです。ぜひ本気でシステム開発のプロジェクトをやり抜く覚悟を持っていただき、プロジェクトを成功させていただければと思います。