SharePoint Onlineのシステム開発の発注/外注/依頼/委託方法について

SharePoint Onlineのシステム開発を発注・外注するなら、先に業務目的、情報の正本、権限、移行範囲を整理し、標準機能・Power Platform・個別開発の境界を決めてから委託先を比較することが重要です。

「ローコードだからすぐ作れる」「クラウドだから移行は簡単」と考えて発注すると、サイトの乱立、最新版が分からない文書、過剰な権限、担当者しか直せない申請フローが残る可能性があります。この記事では、SharePoint Onlineのシステムを発注する際の形態選び、RFPと要件整理、契約、費用相場、見積比較、委託先選定、稼働後の保守までを、2026年時点の情報を踏まえて解説します。

▼全体ガイドの記事
・SharePoint Onlineのシステム開発の完全ガイド

SharePoint Onlineのシステムを発注する前に知っておきたい全体像

SharePoint Onlineは、Microsoft 365上で文書、社内ポータル、リスト、検索、権限、承認を組み合わせる業務基盤です。単なるファイル置き場として導入するか、部門ポータルや申請アプリまで構築するかで、必要な発注体制と予算が大きく変わります。最初に「何を作るか」ではなく「どの業務成果を出すか」を定義すると、不要なカスタマイズを抑えやすくなります。

たとえば、目的が「ファイルサーバーを移すこと」だけなら、移行前の重複ファイルや古い文書を整理しない限り、検索しにくい新しいファイルサーバーができるだけです。「規程を探す時間を短縮する」「申請状況を可視化する」「営業案件の最新版を一元化する」など、利用者の行動や業務指標に置き換えてください。検索時間、申請処理時間、移行対象容量、利用部門数、ポータル閲覧率などをKPIにすると、委託先の提案を比較しやすくなります。

対象範囲には、SharePointのサイトとページだけでなく、Teamsのファイル領域、OneDrive、Microsoft Lists、Power Apps、Power Automate、既存のファイルサーバーや基幹システムを含めます。正本を複数の場所に残すと、利用者が別々のファイルを更新してしまうため、どの情報をどこで管理するかを発注要件に明記します。

SharePointは、部門や全社で共有する文書、ポータル、ニュース、軽量な台帳の基盤に向いています。OneDriveは個人の作業中ファイル、Teamsは会話とチーム単位の共同作業に向いており、Teamsのチャネルに置かれたファイルもSharePoint側で管理されます。Power Automateは承認や通知、Power Appsは入力画面、DataverseやSQLは複雑な関係データの保管というように役割を分けると、SharePointに何でも詰め込む設計を避けられます。

SharePointリストは申請台帳、問い合わせ、設備、案件などに使えますが、大量データや複雑なリレーション、厳密なトランザクションが必要な業務には別のデータ基盤が適しています。新規発注では、標準Webパーツ、Power Platform、SPFx、Microsoft Graph、Azure Functionsのどこまでを採用するかを決め、コードを増やす理由と将来の保守担当を説明できる状態にします。

SharePoint Onlineの発注形態と契約形態はどう選びますか？

発注形態は、ライセンス購入、導入支援、要件定義、データ移行、追加開発、保守を一括で依頼するか、工程ごとに分けるかで考えます。初めて導入する企業は一括窓口が便利ですが、作業費とライセンス費が混ざると、何にいくら支払うのか分かりにくくなります。見積書と契約書では、少なくともライセンス、初期構築、移行、追加開発、教育、運用保守を分けて提示してもらいます。

一括発注は、Microsoft 365のライセンス相談からサイト設計、移行、Power Automateの構築、利用者教育までを一社にまとめる方式です。社内にSharePointの管理者がいない場合や、移行元が複数で責任分界を整理しにくい場合に向いています。ただし、提案会社が得意な製品を過剰に採用することもあるため、標準機能で済む範囲、追加ライセンスの有無、ソースや設定の引き渡し条件を確認します。

分離発注は、要件定義や現状分析を独立した会社に依頼し、その成果物をもとに構築会社を選ぶ方式です。複数社の技術や価格を比較しやすく、社内にプロジェクト管理の経験者がいる場合は有効です。一方で、要件定義会社と開発会社の間で解釈がずれることがあるため、RFP、画面一覧、権限一覧、受入基準を共通の成果物として引き継ぎます。

要件と完成形が明確なサイト構築や定型的な移行作業は、成果物と検収条件を定めた請負契約と相性があります。納期、納品物、検収期間、瑕疵への対応、移行失敗時の再実施条件まで書面にします。ただし、利用部門との対話で要件が変わりやすいPoCや、稼働後の改善を続ける作業は、請負だけで縛ると変更見積もりが増えやすくなります。

要件定義、伴走支援、運用改善、利用部門との定例会のように、作業時間や専門家の稼働に対して委託する業務は準委任契約を検討します。準委任でも、担当者、稼働時間、定例成果物、報告内容、課題管理、情報セキュリティ、再委託の条件を明確にします。実際には、要件定義を準委任、確定した構築部分を請負、稼働後の改善を準委任とする組み合わせが扱いやすい場合があります。

契約には、Power PlatformのSolution、SPFxのソースコード、移行スクリプト、設定一覧、権限設計書、テスト結果、運用手順書を誰が保有するかも記載します。担当者が退職した後も社内で運用できるよう、著作権・利用権、第三者コンポーネント、Microsoftのライセンス、管理者アカウント、秘密情報の取り扱いを確認します。

SharePoint Onlineのシステム発注・外注はどの順番で進めますか？

発注を急いでサイトを作り始めるのではなく、現状把握、要件定義、PoC、構築、移行、受入テスト、教育、運用設計の順に進めます。工程を省くと、後から権限や検索、データの正本を作り直すことになり、初期費用より高い追加費用が発生する可能性があります。

最初に、ファイルサーバー、SharePoint Server、Notes、Excel、Teams、OneDrive、既存データベースを一覧化します。各データについて、所有部門、更新者、利用者、容量、ファイル数、保存期限、個人情報の有無、現行権限、重複、正本を記録します。移行対象を全件と決めるのではなく、保管が必要な文書、廃棄できる文書、利用部門が確認できない文書に分類します。

業務フローも、申請者、承認者、差し戻し、期限、代理承認、通知、完了後の保管まで書き出します。現行Excelをそのままリストに置き換えるだけでは、入力ミスや重複登録は解消しません。成果指標と業務ルールを先に決め、SharePointリスト、Power Apps、Power Automate、Dataverseのどれが適切かを委託先と検討します。

委託先を比較するときは、会社名だけでなく同じRFPを渡します。RFPには、目的、対象ユーザー数、サイト構成、移行元、容量、外部共有、権限、個人情報、保存期間、連携先、希望時期、利用者教育、保守時間、成果物、見積条件を記載します。要件が未確定な部分は「提案してほしい事項」として明示し、各社の判断力も比較できるようにします。

PoCは、代表的な一部門、一つの申請フロー、一つの移行フォルダーで行います。検索、版管理、承認、スマートフォン閲覧、外部共有、権限エラー、復旧、通知の遅延を実際に確認します。PoCの成功条件を「画面が表示された」ではなく、「利用者が迷わず登録できる」「管理者が権限を変更できる」「失敗時に復旧できる」などの行動で定義します。

移行では、ファイルのコピーだけでなく、フォルダー構造、メタデータ、作成者、更新日、版履歴、権限、共有リンク、保持期間をどこまで引き継ぐかを決めます。ファイルサーバーから移す場合は、長すぎるパスや禁止文字、重複名、破損ファイルを事前に検出します。SharePoint Onlineでは個々のファイルのアップロード上限が250GB、ファイルパス全体が400文字以内とMicrosoft Learnに記載されているため、移行前のチェック項目に入れます（出典: Microsoft Learn「SharePointの制限」、2026年確認）。

本番切替の前に、テスト環境で全件または代表サンプルを移し、利用部門が検索、閲覧、編集、承認、共有、復旧を確認します。差分移行、切替中の更新停止、旧環境の参照期間、ロールバック条件を合意します。受入テストの結果、未解決の不具合、残課題、保守への引き継ぎを記録し、検収を口頭で終わらせないことが大切です。

RFPと要件整理には何を書けばよいですか？

RFPは、委託先に「良い提案をしてください」と伝える資料ではなく、各社が同じ前提で見積もり、違いを説明できるようにする資料です。分からない項目を無理に確定する必要はありませんが、未確定の理由と、提案側に確認したい判断材料を分けて記載します。

業務要件には、誰が、いつ、どの情報を登録し、誰が確認し、どの状態になれば完了するかを書きます。「申請をデジタル化する」ではなく、「営業担当がスマートフォンから申請し、部長が承認または差し戻しを行い、完了後は5年間参照できる」のように具体化します。画面数やサイト数だけでは、実装範囲と業務価値を判断できません。

ポータルでは、掲載するニュース、規程、FAQ、問い合わせ窓口、検索対象、更新責任者を明確にします。文書管理では、文書種別、必須メタデータ、版管理、承認、保存期間、廃棄、外部共有の可否を決めます。案件台帳では、列、入力規則、重複判定、担当者変更、終了後のアーカイブを定義します。

権限は、サイト、ライブラリ、フォルダー、ファイルのどこで分けるかを決め、所有者、メンバー、閲覧者、ゲストの役割を整理します。個別ファイルへの例外権限を増やすと棚卸しが難しくなるため、原則はグループで付与し、例外の承認者と期限を管理します。退職者や異動者のアカウント、共有リンク、代理承認者を定期的に見直す運用まで要件に含めます。

外部共有では、許可するドメイン、ゲスト招待の手順、匿名リンクの禁止または例外、アクセス期限、退職・契約終了時の削除を定義します。Microsoft Purviewの共有監査では、共有先の種類や名前を示す項目に加え、SharingInvitationCreated、SharingInvitationAccepted、AnonymousLinkCreatedなどのイベントを確認できます（出典: Microsoft Learn「監査ログで共有監査を使用する」、2026年6月更新）。「クラウドなので安全」とせず、監査ログの確認者、保存期間、インシデント時の調査手順を発注範囲に入れます。

成果物には、サイト構成図、情報設計、画面一覧、権限一覧、ライブラリとリストの定義、Power Automateのフロー一覧、データ移行計画、移行結果、テスト仕様書、操作マニュアル、管理者マニュアル、運用手順書を含めます。SPFxやAPIを使う場合は、ソースコード、ビルド手順、接続先、シークレットの管理方法も指定します。

検収条件は、作業が完了したかではなく、要件を満たしたかで定義します。たとえば、指定したユーザーが指定した文書を検索できること、承認者以外は承認操作できないこと、差し戻し時に申請者へ通知されること、移行対象の件数とエラーが報告されること、管理者がサイト所有者を交代できることなどです。検収後に発見された不具合の無償対応期間と、仕様変更の扱いも契約に合わせます。

SharePoint Onlineのシステム開発費用相場はいくらですか？

SharePoint Online専用の開発費平均統計は公表されていないため、次の金額は、リサーチノートに整理した公開支援価格と一般的な業務システムの相場をもとにした予算仮説です。ライセンス、初期構築、データ移行、追加開発、教育、保守を含む範囲が会社ごとに違うため、金額だけで優劣を決めず、作業項目と前提条件を揃えて比較します。

Microsoftの価格ページでは、2026年8月確認時点でMicrosoft 365 Business Basicが年払いでユーザー1人あたり月額1,049円相当、Microsoft 365 Business Standardが月額3,523円相当と表示されています。いずれも税や契約条件、キャンペーンの影響があるため、契約時点の公式価格を確認してください。既にMicrosoft 365を契約している場合は、SharePointが含まれているプランか、追加ストレージやPower Platformの有料コネクタが必要かを確認します（出典: Microsoft「Microsoft 365 SharePoint: プランと価格を比較」、2026年8月確認）。

2026年1月のMicrosoft Partner Center発表では、スタンドアロンのSharePoint Onlineプラン1・2は2026年6月に新規販売終了、2027年1月以降は更新なし、2029年12月にサービス終了とされています。新規発注で単体プランだけを前提にせず、Microsoft 365スイート、追加容量、従量課金のストレージを含めて将来の契約構成を比較します（出典: Microsoft Learn「2026年1月のお知らせ」、2026年1月28日）。

設定中心で1〜2サイト、基本権限、標準ページ、管理者説明までなら、初期費用は20万〜60万円程度が一つの目安です。部門ポータル、SharePointリスト、Power Automateの申請・通知、簡単なPower Apps、テストまで含む部門業務アプリは、100万〜500万円程度のレンジを予算仮説に置きます。いずれも公開平均価格ではなく、対象範囲を限定した推定レンジです。

ファイルサーバー、SharePoint Server、Notesなどからのデータ移行、メタデータ設計、権限マッピング、差分移行、全社ポータル、利用者教育まで含めると、300万〜1,000万円程度のレンジが想定されます。複数拠点、基幹API、DataverseやAzure、厳格な監査、段階展開まで必要な大規模案件では、1,000万〜3,000万円以上になる可能性があります。移行対象の容量だけでなく、ファイル数、権限の複雑さ、重複除去、利用部門数で工数が変わります。

リサーチノートに記載した公開例では、株式会社コムデックがSharePoint Onlineサポートのライトプランを月額5,000円、Microsoft 365サポートのスタンダードプランを月額20,000円として案内しています。また、有限会社アイリスサービスはMicrosoft 365導入サポート全体を50万〜200万円、SharePoint／Teams導入支援を20万円程度などと公開しています。これらは運用支援や導入支援の参考値であり、個別開発や大規模移行の価格ではありません（出典: 各社公式サイト、2026年確認）。

保守費には、ユーザー問い合わせ、権限変更、サイトやライブラリの追加、Power Automateの失敗監視、容量管理、共有リンクの棚卸し、Microsoftの仕様変更への対応、障害時の復旧、定例会、改善提案などが含まれます。単に「月額保守」と書かれた見積もりは、対応時間、受付時間、緊急時の連絡先、月次報告、作業の繰り越し、追加開発との境界を確認します。

一般的な業務システムの目安として、保守費を初期開発費の年15〜25％程度、または月額15万〜80万円程度とする考え方がありますが、SharePoint Onlineでは利用者数と運用範囲で大きく変わります。小規模環境の問い合わせ中心と、全社環境の権限棚卸し・監査・移行・改善を含む運用は分けて見積もります。開発費を安く見せるために保守や教育を別契約へ隠していないか確認してください。

SharePoint Onlineの委託先選定と見積比較のポイント

委託先は、Microsoft 365を扱えるかだけでなく、SharePointの情報設計、移行、Power Platform、権限・セキュリティ、業務定着まで対応できるかで選びます。大規模移行が得意な会社、導入から運用まで一括支援する会社、Power AppsやPower Automateの業務アプリに強い会社、小規模運用を支援する会社では、提案の向き不向きが違います。

実績を確認するときは、「SharePointの実績があります」という説明だけで終わらせず、移行元、データ量、ユーザー数、サイト数、権限設計、外部共有、Power Platform、API連携、利用者教育、稼働後の保守を質問します。ファイルサーバーからの移行経験があっても、Notesからの移行や複雑な個別権限の整理は別の難しさがあります。自社と近い業界規制、拠点構成、データの機密度を持つ事例があるか確認します。

提案担当者だけでなく、実際に要件定義、設計、移行、テスト、保守を担当する人の経験も見ます。Microsoft認定資格の有無だけでなく、権限継承の例外をどう減らすか、失敗したフローを誰が監視するか、担当者交代時にどう引き継ぐかを説明できる会社が望ましいです。公開事例では、SCSK、テクバン、アンク、コムデック、ウェブシステムテクノロジー、アイリスサービスなどがSharePointやMicrosoft 365関連の支援情報を案内していますが、最新の対応範囲と担当体制は個別に確認してください。

見積比較では、合計金額の安さより、作業の抜けを探します。要件定義の回数、サイト設計、権限設計、ライブラリとリストの設定、Power Automateの本数、画面開発、移行前クレンジング、移行リハーサル、差分移行、テスト、教育、マニュアル、保守を行単位で確認します。ライセンス費、追加容量、Power Appsや有料コネクタ、Azure、バックアップ、監査機能の費用が含まれているかも分けます。

極端に安い見積もりでは、要件定義、移行テスト、権限棚卸し、教育、設計書、障害対応が除外されている可能性があります。逆に高い見積もりでも、不要なSPFx開発や過剰な個別権限が含まれている場合があります。「標準機能で対応する範囲」「追加開発が必要な理由」「将来の変更費用」「利用者側に必要な作業」を提案書に書いてもらい、金額と設計判断を一緒に比較します。

候補会社には、サイトが増え続けた場合の統制、所有者が退職した場合の引き継ぎ、個別権限の棚卸し、外部ゲストの削除、共有リンクの監査、Power Automateの失敗通知、容量超過、誤削除からの復旧を質問します。回答が機能一覧だけで、担当者、頻度、記録方法、費用の説明に進まない場合は注意が必要です。

SharePoint Onlineでは、リストやライブラリに最大3,000万件を格納できる一方、10万件を超えるとリストやライブラリ、フォルダーの権限継承を解除できない制限があります。また、Microsoftはサイトコレクションあたりのリストとライブラリを合計2,000個、固有権限の推奨一般上限を5,000件として案内しています（出典: Microsoft Learn「SharePointの制限」、2026年確認）。上限まで使えることだけでなく、検索性と権限管理を保てる設計かを評価します。

発注後の定着と運用設計まで委託範囲に含めます

システムを納品しても、利用者がTeamsや個人フォルダーにファイルを戻したり、サイト所有者が不在になったりすると、導入効果は続きません。発注時点で、管理者、サイト所有者、データ所有者、問い合わせ窓口、セキュリティ責任者を決め、誰が何をいつ確認するかを運用手順に落とし込みます。

サイトの作成申請、命名規則、所有者の最低人数、レビュー頻度、廃止条件、ハブサイトへの登録基準を決めます。文書には、保存期間、版管理、承認、保持、廃棄、メタデータの入力ルールを設定します。外部共有は、許可する相手、期限、ゲストの棚卸し、匿名リンクの扱い、契約終了時の削除を定期的に確認します。

運用ルールは、管理者だけが読める文書にせず、利用者が迷ったときに見つけられるFAQや短いガイドにします。現場からの改善要望を受け付ける窓口と、仕様変更を承認する会議体を設けると、各部門が独自にサイトやフローを増やす状態を抑えやすくなります。

全社の要望を一度に満たそうとせず、最初は代表部門のポータル、重要文書のライブラリ、一つの申請フローなどに絞ります。初期導入後に、検索語、閲覧数、申請の滞留、フローの失敗、問い合わせ内容、共有リンク、権限変更を確認し、次の部門や業務へ展開します。段階導入なら、要件の不確実さを抑えながら投資判断を更新できます。

ロードマップは、最初の1〜2か月で現状分析とPoC、次の1〜3か月で部門構築と小規模移行、その後2〜6か月で全社移行や教育を行うように、業務の複雑さに応じて設定します。期間は固定の正解ではなく、移行件数、部門数、承認ルール、外部連携、受入テストの量を根拠にします。委託先には、短縮できる工程と短縮してはいけない工程を説明してもらいます。

よくある質問

SharePoint Onlineの発注では、製品の機能よりも、業務要件、データ移行、権限、契約、運用体制の整理が成否を左右します。ここでは、発注前に特に質問されやすい点をまとめます。

外注できます。1〜2サイトの設定、基本権限、標準ページ、管理者説明のような小規模案件なら、20万〜60万円程度を初期費用の推定レンジとしてRFPを作成できます。ただし、対象ユーザー数、移行容量、申請フロー数、教育、保守の有無によって変わるため、公開価格ではなく作業範囲を明記して見積もりを取ります。

別に考えます。ライセンスはユーザー数、契約プラン、追加容量、Power PlatformやAzureなどの追加サービスで決まり、開発費は要件定義、サイト設計、移行、設定、個別開発、テスト、教育で決まります。見積書で両者を分け、Microsoft 365スイートに既にSharePointが含まれていないか、2026年の単体プラン廃止方針が自社契約に影響しないかを確認してください。

要件とRFPを揃えられるなら、特徴の異なる2〜4社程度に同じ条件で依頼すると比較しやすいです。大規模移行、Power Platform、運用保守など、自社が重視する領域の実績が異なる会社を候補にします。見積金額だけでなく、成果物、前提条件、除外条件、担当体制、契約形態、保守、ソースコードと設定の引き渡しを並べて判断します。

全件移行が正解とは限りません。利用状況、保存期限、重複、個人情報、権限、正本、業務上の必要性を確認し、移行、アーカイブ、廃棄、保留に分類します。移行する場合も、代表データでリハーサルを行い、メタデータ、版、権限、検索、差分移行、切替後の参照期間を受入テストで確認します。

まとめ

SharePoint Onlineのシステムを発注・外注する際は、製品の機能説明から始めるのではなく、業務目的、現行データ、正本、権限、外部共有、保存・廃棄、運用責任者を整理することが出発点です。そのうえで、標準機能、Power Apps・Power Automate、Dataverse、SPFx・APIの役割を分け、必要な範囲だけを開発します。

RFPには、対象ユーザー、サイトとライブラリ、移行元と容量、データクレンジング、権限、外部共有、監査、連携、受入テスト、教育、保守、成果物、契約形態を記載します。見積もりは、ライセンス、初期構築、移行、追加開発、教育、保守を分け、作業の前提と除外条件まで比較します。安さだけでなく、稼働後に社内で運用できるかを判断してください。

全社導入の前に、代表部門のポータル、重要文書の移行、一つの申請フローでPoCを行うと、検索、権限、承認、復旧、利用者教育の課題が見えます。成果物と契約条件を残し、段階的に対象を広げれば、SharePoint Onlineを長く使える業務基盤へ育てやすくなります。

▼全体ガイドの記事
・SharePoint Onlineのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。