情報共有システム開発の発注/外注/依頼/委託方法について

情報共有システムの開発を外注・発注しようと考えているものの、「どのように進めればよいか分からない」「外注先選びで失敗したくない」と悩んでいる担当者は多いでしょう。情報共有システムは全社員が使う重要なインフラであるため、開発の失敗は業務全体に大きな影響を与えます。発注前の要件整理・開発会社の選定・契約内容の確認・発注後のプロジェクト管理まで、押さえるべきポイントが多くあります。

本記事では、情報共有システム開発を外注・発注する際のステップを順を追って解説します。外注初心者の方でも迷わないよう、準備すべきこと・注意すべきことを具体的にまとめています。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・情報共有システム開発の完全ガイド

情報共有システム開発を外注する前に知っておくべきこと

情報共有システム開発を外注する前に知っておくべきこと

外注を始める前に、自社内で整理しておくべきことがいくつかあります。これを怠ると、開発会社への要件伝達がうまくいかず、思い描いていたシステムと異なるものができてしまうリスクが高まります。

自社要件の整理:現状課題と「あるべき姿」を明確にする

外注を始める前に、まず「なぜ情報共有システムを開発したいのか」「現状のどんな課題を解決したいのか」を明確にしてください。「情報が散在していて探せない」「部署間の情報共有がなく業務が重複している」「テレワーク対応で紙の文書を電子化したい」など、具体的な課題を言語化することが最初の作業です。

次に、「システムが完成した状態でどのような業務フローが実現しているか(あるべき姿)」を描きます。この「現状(As-Is)」と「あるべき姿(To-Be)」のギャップが、システムで解決すべき課題の本質です。これが明確でないまま外注を始めると、開発会社も的確な提案ができず、要件定義フェーズで大きな手戻りが発生します。課題の整理には、各部署へのヒアリングや現状の情報フロー可視化(業務フロー図の作成)が有効です。

社内体制の整備:プロジェクトオーナーとPMの任命

情報共有システムの開発プロジェクトを成功させるには、社内に明確な推進体制を整備することが不可欠です。具体的には、プロジェクトオーナー(経営層・部門長)プロジェクトマネージャー(PM)を任命し、意思決定の権限と責任を明確にします。

プロジェクトオーナーは、プロジェクトの目的・予算・優先度に関する最終意思決定を行う役割です。経営層や事業部長レベルの方が適切です。PMは、開発会社との日常的なコミュニケーション・スケジュール管理・社内調整・要件変更の管理を担います。情報システム部門の担当者が兼任することが多いですが、プロジェクトの規模が大きい場合は専任のPMを設置することを推奨します。また、各部署の代表者からなる「ユーザー代表チーム」を組成し、要件定義・テスト・受け入れ確認に参加してもらう体制を作ると、利用者視点の品質確保につながります。

RFP(提案依頼書)の作成

複数の開発会社に比較見積もりを依頼する場合、RFP(Request for Proposal:提案依頼書)の作成が重要です。RFPには、プロジェクトの背景・目的・対象業務の概要・想定する機能一覧・利用者数・既存システムとの連携要件・セキュリティ要件・希望スケジュール・予算感・選定基準などを記載します。

RFPが整っていることで、各開発会社の提案の比較が容易になり、見積もりの精度も高まります。RFPの作成が難しい場合は、まず1社の開発会社に相談しながら要件を整理するアプローチも有効です(コンサルティング型の開発会社であれば、RFP作成を支援してもらえるケースもあります)。

外注の方法と開発会社の探し方

外注の方法と開発会社の探し方

情報共有システムの開発会社を探す方法はいくつかあります。それぞれのメリット・デメリットを理解した上で、自社の状況に合った方法を選択しましょう。

Web検索・専門メディアで探す

「情報共有システム開発 外注」「社内ポータル開発 会社」などのキーワードでWeb検索し、専門メディアやカオスマップなどを参考に候補会社を絞り込む方法です。費用はかかりませんが、自社に合う会社を見極めるためのリサーチに時間がかかります。各社のWebサイトで実績・事例・技術ブログなどを確認し、情報共有システム開発の経験が豊富かどうかを事前評価しましょう。

発注マッチングサービスを活用する

IT発注マッチングサービス(発注ナビ・システム幹事・ミツモア等)を活用すると、要件を入力するだけで適切な開発会社から提案を受けられます。複数社の見積もりを効率的に収集できるため、比較検討の手間を大幅に削減できます。ただし、マッチングサービス経由の場合、各社との個別交渉よりも定型的な提案になりやすいため、自社の特殊要件がある場合は直接コンタクトを補完的に行うことをお勧めします。

紹介・コミュニティを活用する

同業他社や取引先から「情報共有システムを開発した開発会社」を紹介してもらう方法は、実績・信頼性の確認が事前にできるため、発注後のリスクが低くなります。業界のIT系勉強会・カンファレンス・展示会(Japan IT Week等)で開発会社と直接面談する機会を作ることも有効です。知り合いからの紹介は、契約交渉でも信頼関係が構築しやすいメリットがあります。

契約形態の選び方(請負契約vs準委任契約)

契約形態の選び方

システム開発の外注では、主に「請負契約」と「準委任契約」の2つの契約形態があります。どちらを選ぶかで責任範囲・費用精算方法・発注側の関与度が大きく異なります。

請負契約:成果物に対して報酬を支払う

請負契約は、「約束した成果物(システム)を完成させることに対して報酬を支払う」契約形態です。開発会社が成果物の完成責任を負うため、仕様通りに完成しない場合は瑕疵担保責任(契約不適合責任)が発生します。発注側にとっては「何を作ってもらうか」が明確で、費用も固定されるメリットがあります。

ただし、請負契約では要件が事前に確定している前提であるため、開発中の仕様変更が追加費用として計上される場合が多く、アジャイル開発とは相性が悪い点に注意が必要です。また、要件書の曖昧さが後でトラブルの種になるため、契約前に仕様書を詳細に確認することが重要です。情報共有システムのように要件が比較的明確な場合や、規模が小さく変更リスクが低い場合に適した契約形態です。

準委任契約:工数に対して報酬を支払う

準委任契約は、「開発作業(工数)に対して報酬を支払う」契約形態です。エンジニアの稼働時間に対して報酬が発生するため(月額固定または時間単価×稼働時間)、仕様変更や追加要件に対して柔軟に対応できます。アジャイル開発との相性が良く、要件の不確実性が高いプロジェクト・継続的な機能追加が必要なプロジェクトに適しています。

一方で、準委任契約は成果物の完成責任を開発会社が負わないため、「作業は進んでいるが思ったものができていない」というリスクがあります。発注側が積極的にプロジェクト管理に関与し、定期的に進捗確認・方向性確認を行う必要があります。中規模以上の情報共有システム開発では、要件定義・基本設計フェーズは準委任契約で進め、機能が確定した後の開発フェーズは請負契約に切り替えるハイブリッドアプローチが有効です。

発注後のプロジェクト管理のポイント

発注後のプロジェクト管理のポイント

外注後も、発注側(自社)がプロジェクト管理に積極的に関与することが成功の鍵です。「全てお任せ」ではなく、定期的なコミュニケーションと進捗管理を行うことで、手戻りや品質問題を早期に防げます。

定期的な進捗確認とフェーズゲートレビューを設ける

週次または隔週での定例ミーティングを設け、進捗状況・課題・リスクを共有する機会を継続的に設けましょう。また、要件定義完了・基本設計完了・開発完了・テスト完了など、各フェーズの節目にフェーズゲートレビュー(承認判定会議)を設けることを推奨します。フェーズゲートで成果物を確認し、「次フェーズに進んでよいか」を明示的に承認することで、後工程での大幅な手戻りを防げます。

成果物の確認には、設計書・画面モック・プロトタイプ・テスト仕様書など、各フェーズで作成されるドキュメントを活用します。「口頭での説明のみ」で次フェーズに進まないよう、成果物の文書化を徹底するよう開発会社に依頼してください。

要件変更は変更管理プロセスで対応する

開発中に「やっぱりこの機能も欲しい」「仕様を変えたい」という要求は必ず発生します。これを口頭で依頼してしまうと、スコープが際限なく広がり(スコープクリープ)、スケジュール・コストが当初計画から大きく外れる原因になります。

変更管理プロセスを最初から合意しておきましょう。「変更要求は文書で提出→開発会社が影響範囲(工数・費用・スケジュール)を見積もり提出→発注側が承認→実施」というフローを明文化することで、変更に伴うコスト増とスケジュール遅延を制御できます。変更管理の手続きを面倒に感じる担当者も多いですが、このプロセスが最終的なコスト・品質・信頼関係を守る最も重要な仕組みです。

納品物の検収基準を事前に合意する

「完成とはどの状態か」を事前に明確にしておかないと、「開発会社は完成と言っているが、こちらとしては不満がある」というトラブルが発生します。検収基準として、「テスト仕様書に記載した全テストケースをパスしていること」「要件定義書に記載した全機能が実装されていること」「性能要件(同時接続数・レスポンスタイム)を満たしていること」などを契約書または別紙の検収条件として明記しておきましょう。

また、リリース後の瑕疵担保期間(通常3〜6ヶ月)における無償対応の範囲も合意しておくことが重要です。リリース直後に発覚したバグの修正費用が問題になるケースが多いため、「リリース後〇ヶ月以内に発覚した要件定義・設計起因のバグは無償で対応する」という条件を明示しましょう。

まとめ

情報共有システム開発の外注・発注方法について解説しました。重要なポイントをまとめます。

  • 外注前に現状課題とあるべき姿を明確にする——RFPを作成し、複数社に同じ条件で見積もりを依頼することが精度の高い比較につながる
  • 社内推進体制(プロジェクトオーナー・PM・ユーザー代表)を整備する——意思決定のスピードと品質確保のために、社内体制の明確化は必須
  • 契約形態は請負・準委任の特性を理解して選択する——要件の確定度・変更リスク・プロジェクト性格に応じてハイブリッドも検討する
  • 定期進捗確認・フェーズゲートレビュー・変更管理プロセスを実施する——「丸投げ」ではなく発注側も積極的に管理に関与することが成功の鍵
  • 検収基準・瑕疵担保条件を事前に明文化する——リリース後のトラブルを防ぐための事前合意が重要

情報共有システムの外注は、適切な準備と発注後の管理によって、大きな成果を生む投資となります。開発会社の選定・契約・プロジェクト管理の各フェーズで適切な対応を行い、自社の情報共有基盤の強化につなげてください。

情報共有システム開発のご相談はriplaへ

情報共有システムの開発でお困りの方は、ぜひ株式会社riplaにご相談ください。riplaは、企業内の情報共有・コミュニケーション基盤の構築に豊富な実績を持つSIerです。要件定義から設計・開発・保守運用まで一気通貫でご支援します。

記事一覧|株式会社riplaをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む