SharePointのシステム開発は、要件整理と方式選定から始まる6フェーズで進めます。その後は、設計・開発、テストを経て、段階稼働と90日間の定着支援に移ります。この順で進めると、業務改善につながります。
全体像は、SharePointのシステム開発の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・SharePointのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SharePointのシステム開発の全体像
SharePointは、オンラインのファイル置き場にとどまらず、業務情報を扱う基盤です。ポータル、ライブラリ、リスト、ワークフローに加え、Teamsからのアクセスや検索、監査を組み合わせて使います。
開発の成否は、画面の見た目よりも、誰がどの情報をどの権限で使うかに左右されます。さらに、利用する業務のタイミングも先に決めておきます。
SharePoint・Teams・OneDriveの役割の分担
3つのサービスは、共有情報、共同作業、個人作業の用途で分けて考えます。
- SharePoint：組織やチームの情報基盤。Teamsのチャネルファイルも保存
- Teams：会話と共同作業の入口
- OneDrive：個人が作業中のファイルを保存する場所
権限はTeamsの画面だけで決めず、背後にあるSharePointサイト、Microsoft 365グループ、Entra IDグループの関係も見て確認します。
個人用ファイルの保管だけならOneDriveで足りる場合があります。一方で、社内規程、製品資料、申請履歴、部門ナレッジを継続して管理するなら、SharePointのサイト設計が必要です。
構成要素とガバナンスの一体設計
構成要素の設計と同時に、権限と運用の原則も決めておきます。
- 構成：テナント、サイト、ページ、ライブラリ、リスト、列、メタデータ
- 運用：検索、権限、外部共有、ワークフロー、移行、バックアップ、体制
- 管理原則：所有者を置き、部門・プロジェクト単位でグループを管理
ファイル単位の例外権限を増やさない原則を決めておくと、後の権限レビューで迷いが減ります。
Microsoft Learnは、指定グループ以外のユーザーのサイトアクセスを制限する機能を案内しています。ただし、利用には対象プランとテナント設定の確認が要ります。
機能を使えることと、社内のデータ分類や権限運用が整っていることは別の話です。そのため、機能設定と運用ルールの両方を用意します。
SharePointのシステム開発の進め方（6フェーズ）
開発は、要件整理と製品・方式選定から始めます。その後は設計開発、テスト、稼働と進み、最後に定着へ移ります。小規模な案件でも6段階は省かず、作業の中身を簡略にするほうが安全です。
各段階で成果物と承認者を決め、次工程へ進む条件をはっきりさせておきます。そうすると、「そこまで作るとは思わなかった」「移行後に検索できない」といった手戻りを抑えられます。
1. 要件整理：解決したい業務とKPIの決定
改善したい業務を決めます。そのうえで、利用者と承認者が具体的に答えられる要件にまとめます。
- 業務KPI：探す時間、申請の滞留日数、最新版への到達割合、問い合わせ件数
- 現状把握：サイト・共有フォルダ、所有者、利用頻度、期限、機密区分、外部共有
- 要件：改善する業務とKPIを決める
旧システムの版履歴や、移行しなくてよいデータも確認します。全社ポータルの場合は、ニュースの投稿者、承認にかける営業日数、掲載期限の管理方法まで決めます。要件ごとに、利用者と承認者が答えられるかも確かめます。
文書移行では、対象の容量、ファイル数、拡張子を確認します。さらに、重複、権限、更新日を見たうえで、保持年限と検索項目も決めておきます。不要なデータをこの段階で除いておけば、移行と権限確認の両方の手間を減らせます。
2. 選定：標準機能から始める実装方式の比較
要件に合う方式は、標準機能から順に比べます。独自開発は、必要最小限にとどめます。
- 標準機能：ページ、ライブラリ、リスト、検索、Teams連携
- Power Platform：Power Apps・Power Automate
- 拡張・独自開発：SPFx、Graph/API連携、外部サービス、スクラッチ開発
Power Automateで通知や承認を組み、Power Appsで入力画面を補う方法があります。業務アプリに近い使い勝手を、比較的短い期間で作れる場合があります。
独自Webパーツには、Microsoft公式が推奨するSharePoint Framework（SPFx）を候補にします。SPFxは、SharePointやTeamsにも拡張でき、TypeScriptやJavaScriptを使えます。Microsoft GraphやREST APIも使えます。
また、Viva Connectionsにも拡張できます（出典: Microsoft Learn「SharePoint Frameworkの概要」、2025年12月更新）。
技術的に作れることと、長期運用できることは別です。そのため、更新対応や開発者の交代、権限同意を選定時に確認します。テスト環境と障害時の切り戻しも、選定の時点で確かめます。
候補方式は、同じ表で比べます。比べる観点は、要件適合性、初期費用、変更費用です。担当者の扱いやすさとMicrosoft 365の更新への耐性も、同じ表に入れます。
SharePoint Onlineとオンプレミスを比べる場合は、ネットワーク分離や既存資産など、明確な理由があるかを確かめます。
通常の社内ポータルでは、クラウドの利点も含めてTCO（総所有コスト）で判断します。クラウドでは、サーバーやパッチ、バックアップを自社で持たなくてよい点も比較材料になります。さらに、可用性を自社で持たなくてよい点も比較材料です。
3. 設計・開発：情報構造と権限の先行整備
情報構造と権限の分け方を先に決めておくと、運用時の例外が減ります。
- 情報構造：サイト階層、ハブ、用途、ライブラリ、リスト、列、命名、検索範囲
- 分類：文書種別、製品、年度、機密区分のメタデータ
- 権限：グループ付与を基本にし、機密文書の扱いを分ける
部門サイトとプロジェクトサイトが混在すると、所有者や保存期限があいまいになりがちです。そこで、メタデータを使い、深いフォルダ構造への依存を抑えます。メタデータには、たとえば文書種別、製品、年度があり、機密区分なども含まれます。
コンテンツタイプと命名規則も決めます。あわせて、サイトを作る条件と廃止する条件をルール化します。
権限を分ける単位をはっきりさせます。サイトかライブラリか、それともフォルダかファイルかを決めておきます。
基本は、Microsoft 365グループやEntra IDグループで付与します。個人への直接付与は減らします。
機密文書は、閲覧や編集、共有の扱いを分けます。ダウンロードと外部共有も分けて設計します。退職・異動時に自動で見直せる運用も、あわせて組み込みます。
アクセス制御の機能は、過剰共有の対策に役立ちます。ただし、古い共有リンクや、継承を切った例外権限を放置すると、リスクは残ります。
権限台帳と定期レビューも、設計の成果物に含めます。機能設定をしただけで、アクセス管理が終わったと扱わないことが大切です。
4. テスト：機能だけでなく業務と権限の検証
画面の表示だけでなく、役割ごとの業務を検証します。移行と検索、受入条件も確かめます。
- 役割別：一般利用者、部門管理者、サイト所有者、外部ユーザー
- 機能：閲覧、編集、共有、承認、検索、通知、版管理、復元
- 移行・検索：移行前後の突合と、実際の検索語による結果評価
見えてはいけない文書が検索に出ないか、Teamsから同じファイルにアクセスできるかを確かめます。退職者のアカウントでアクセスできないことも確認します。実際の権限グループを使い、シナリオテストを行います。
移行テストでは、ファイル数と容量に加え、ファイル名や文字化けを移行前後で突き合わせます。さらに、版履歴や作成者、更新日を比べ、メタデータやリンク、アクセス権も確認します。
検索テストは、利用者が実際に入力する言葉で行います。そのうえで、上位の結果が役立つかを評価します。
受入条件は、判定できる形で文書にします。条件には、主要業務のシナリオ完了、重大な権限不備がないこと、未解決課題の責任者と期限が決まっていることを含めます。
5. 稼働：段階移行と問い合わせ導線の準備
全社を一斉に切り替えるより、1部門か1業務で先行する段階移行のほうが安全です。
- 先行部門で検索語、権限申請、投稿ルール、通知量、問い合わせを確認する
- テンプレートとマニュアルを改良し、見つかった課題を反映する
- 読み取り専用化の時刻、最終差分、切り戻し期限を決める
- 利用者への告知と障害時の連絡先を用意する
導入事例では、従業員約300名の企業が社内専用サイトを構築しています。設計・構築・教育・運用保守まで、約3か月で支援を受けています（出典: コニカミノルタ「Microsoft 365・SharePoint 社内専用サイト構築事例」、確認日2026年8月）。
ただし、すべての案件が3か月で終わるわけではありません。期間は、既存データ量や移行対象、権限の複雑さで変わります。部門数や独自開発の有無も影響します。
自社の工程表では、この事例を参考値として扱います。期間は、個別の条件を確かめたうえで見積もります。
6. 定着：稼働後90日の運用設計
稼働した日が完成ではありません。利用者と管理者が安全に使える状態を目指して、90日間の活動を計画します。
- 最初の30日：操作説明と問い合わせ対応
- 31〜60日：検索・権限・投稿ルールの改善
- 61〜90日：利用状況とKPIの評価
- 運用ガイド：ページ公開、ライブラリ整理、権限申請、外部共有、期限切れ情報の削除
- 指標：月次のアクティブ利用者数、検索ゼロ件率、目的情報への到達時間、申請の平均処理時間、未回答の問い合わせ件数、期限切れページの割合
2026年に公開された旭有機材株式会社の事例では、SharePoint Onlineへのポータル移行と情報集約を進めました。
現場説明会や部門展開を行い、生成AIで社内規程を検索する活用にもつなげています（出典: ソフトバンク「旭有機材株式会社 導入事例」、2026年3月）。
AI活用を急ぐ場合ほど、先に権限とデータ分類を整えておく必要があります。
SharePointのシステム開発費用相場とコストの内訳
費用は、ライセンス費と作業費に分けて考えます。作業費には、要件整理・設計、開発、移行が入ります。テストや教育、運用支援も作業費に含まれます。
SharePoint Onlineの利用料を契約済みでも、情報設計や移行が別途必要な場合があります。権限整理や定着支援も、別に必要になることがあります。
一方で、既存のMicrosoft 365プランに必要な機能が含まれている場合もあります。ライセンスを買い足す前に、契約内容を確認します。
ライセンス費の変動要因（契約プランと利用者数）
ライセンス費は、Business Basicの1ユーザー単価に利用者数を掛けて求めます。単価と100ユーザーの試算は、次の2項目です。
- 表示価格：2026年8月9日時点、年払い・税抜で1ユーザーあたり月額1,049円相当
- 100ユーザー試算：月額104,900円相当、年額1,258,800円相当
SharePointは同プランのサービス一覧に含まれます。適切なプランは、Teamsやデスクトップ版Officeの要否、セキュリティや管理機能の必要性で変わります（出典: Microsoft公式「Microsoft 365 SharePoint: プランと価格を比較」、2026年8月確認）。
価格改定や契約期間、販売地域によって条件が変わります。既存契約、追加ストレージ、ゲスト利用の条件も関係します。そのため、記事の金額は契約前の参考値として扱ってください。
この試算に含まれるのはライセンスだけで、導入支援や移行は含みません。バックアップやPower Platformの追加利用料、運用代行も含みません。
利用者数は、閲覧者や投稿者、承認者に分けて数えます。外部ユーザーも、別に整理して算出します。
使っていないアカウントも、定期的に見直します。全社員数をそのまま課金対象にせず、役割ごとに確認します。
導入・開発費の幅（100万〜3,000万円以上）
ここで示すのは、SharePoint Onlineの公開一律料金ではありません。業務システムの一般的な人月単価、作業範囲、公開事例をもとにした推定の目安です。
- 小規模：100万〜300万円、1〜3か月程度
- 中規模：300万〜1,000万円、3〜6か月程度
- 大規模：1,000万〜3,000万円以上、6〜12か月以上
小規模案件に含まれるのは、標準サイト1〜3個と基本権限です。簡単なポータルや利用者教育も含みます。
中規模案件は、複数部門のサイトやファイルサーバーの移行を含みます。メタデータ・検索設計やPower Automateも、作業範囲に入ります。
大規模案件では、数千ユーザーや、オンプレミス・旧ポータルからの大規模移行を扱います。多数のサイトや複雑な権限が加わる場合もあります。基幹連携や監査、教育、段階展開を含むこともあります。
SPFxの独自Webパーツや、Graph/API連携は、要件によって1機能あたり100万〜500万円程度を追加で見込むことがあります。これは公開定価ではなく、作業量から置いた推定の幅です。
追加開発を決める前に、標準機能やPower Platformで代替できないかを検討します。費用は、実装範囲と運用条件によって変わります。
運用費の内訳と、問い合わせ・権限・改善の範囲
運用費は、委託する範囲によって変わります。主な対象を整理したうえで、契約内容を確認します。
- 管理：サイト、ユーザー・グループ変更、権限レビュー
- 支援：問い合わせ一次対応、障害調査、バックアップ・復元確認
- 改善：Microsoft 365の変更確認、軽微な改修、利用状況レポート
一般的な業務システムの目安は、初期費用の年15〜25％程度、または月15万〜80万円程度です。
この金額は、利用者数やサイト数、対応時間によって大きく変わります。オンサイト対応や開発者の有無も影響します。契約では、対応範囲と条件を確かめます。
サンベンドの公開事例では、SharePoint Onlineのサイトを内製し、必要なときだけチケット制の支援を使って、社内ノウハウを蓄積しています（出典: SCSK「株式会社サンベンド SharePoint Onlineで情報共有サイトを内製」、確認日2026年8月）。
全面委託だけでなく、内製、定額支援、チケット支援も比べます。自社に残す業務と外部に任せる難所を分けておくと、継続費用を説明しやすくなります。
SharePointの見積もりを取る際のポイント
相見積もりでは、合計金額だけでなく、成果物と作業範囲を比べます。見るべきは、要件定義に現状の洗い出しが含まれるかどうかです。権限設計や移行、テストが含まれるかも確認します。教育や運用設計も確かめます。
提案依頼書には、対象ユーザーやサイト数、データ量を書きます。移行元と連携先、必要な権限を記載し、外部共有の扱いも書きます。希望時期と社内で担う作業も加えて、各社が同じ前提で見積もれるようにします。
要件と成果物の見積書への対応づけ
見積書では、工程ごとの成果物と、対象件数や除外条件が対応しているかを確認します。
- 要件・設計：ヒアリング回数、現状分析範囲、要件定義書、構成図、権限マトリクス、メタデータ一覧、移行設計書
- 開発：ページ、ライブラリ、リスト、ワークフロー、Webパーツの数と外部連携方式
- テスト：ケース数、役割別の権限テスト、移行リハーサル、受入支援の範囲
- 納品・整理：「一式」の対象件数、除外条件、データ整理の担当
移行後のデータ整理を利用企業とベンダーのどちらが担うかで、工数と責任範囲が変わります。
納品後も、テンプレートや運用マニュアル、権限台帳を自社で更新できる形で残るかを確かめます。テスト結果と未解決課題の一覧も、受け取れるかを見ておきます。
開発会社の選び方：Microsoft 365の実績と移行・運用体制
発注先は、Microsoft製品の販売実績だけでなく、移行と運用の体制を見て選びます。
- 実績・設計：近い規模・業種の事例、情報・権限設計の担当者
- 開発・保守：Power PlatformやSPFxの体制、Microsoft 365更新への対応
- 支援：教育・定着支援、障害時の一次対応
提案では、標準機能でできること、追加開発が必要なこと、将来の保守対象を分けて説明してもらいます。
既存ポータルの機能をすべて再現する提案には、注意が必要です。2026年に公開された旭有機材の事例では、SharePoint Onlineの標準機能に外部ポータルサービスを組み合わせています。
既存機能を再現する方法と、利用実態を見直して標準機能に寄せる方法を比べます。追加コストと将来の変更のしやすさを含めて判断します。
見積もりのリスクと対策の言語化
費用が膨らむ要因を洗い出し、未確定の条件と追加費用の扱いを見積もりに残します。
- データ・権限：移行対象、例外権限、ファイル名やメタデータの乱れ
- 開発・連携：独自画面の増加、連携先仕様の未確定
- 進行：社内レビューの遅れ
- 契約条件：仮定条件、上限・下限、追加費用が発生する条件
見積もりの段階で、対象データのサンプルや権限の現状を共有します。連携仕様や承認者、社内作業の工数も、あわせて伝えます。
追加費用が発生する条件は、契約書や注文書に残します。法令やセキュリティ要件も、見積もりの前提に含めます。
個人情報を扱う場合は、安全管理措置と委託先の監督を確認します。電子取引データを保存する場合は、電子帳簿保存法の検索性、改ざん防止、保存期間などの要件を、法務・税務・情報セキュリティの担当と確かめます。
SharePointの版管理だけで法令要件を満たせるとは限りません。必要な設定と運用、証跡、定期点検を明確にします。
SharePointのシステム開発でよくある質問
導入時によくある質問について、判断のポイントとあわせて答えます。
答えは、契約プラン、データの機密性、移行元の状態によって変わります。そのため、自社の前提条件に置き換えて確かめてください。
SharePointのシステム開発は中小企業でもできますか？
できます。社内ポータル、文書管理、申請のいずれか1つに絞り、標準機能を中心に小さく始めると進めやすいです。
サイト所有者は2名以上置き、権限と投稿ルールを決めます。使い勝手は先行部門で検証してから、全社に広げます。
ファイルサーバーや旧グループウェアから移行できますか？
移行はできますが、すべてのファイルをそのまま移すとは限りません。移行対象と移行後の使い方を確かめます。
- ファイル数、容量、名前、権限、版履歴、メタデータ、リンク、保存期限を洗い出す
- 不要・重複・期限切れのデータを除き、少量で移行リハーサルと突き合わせを行う
- 旧機能の再現より、検索・権限・運用を基準に移行後の構造を見直す
SharePointはどこまでカスタマイズすべきですか？
業務目的を満たせる範囲は、標準機能に寄せます。入力や承認の不足は、Power Apps・Power Automateで補います。
Microsoft 365の中で再利用する独自Webパーツは、SPFxで作ることを検討します。外部データとの連携や複雑な処理は、Graph/APIや外部サービスが候補になります。
独自機能を採用する場合は、保守を担う人と、更新の検証方法を決めておきます。障害時の代替手段や、将来の廃止費用まで含めて判断します。
機密情報や生成AI利用に対応できますか？
対応はできますが、SharePointの機能を有効にするだけでは足りません。MFAや条件付きアクセス、最小権限の設定が必要です。外部共有の制御、監査ログ、DLPも、データ分類と業務ルールに結びつけます。
保持ラベルや秘密度ラベル、アクセスレビューも組み合わせます。生成AIや検索を使う前に、過剰に共有された文書が検索結果に現れる可能性を点検します。
機密サイトのアクセスを制限し、権限を定期的に見直します。設定と運用の両方で、情報を守ります。
SharePointのシステム開発の進め方まとめ
SharePoint開発は、情報の持ち主や保存場所、権限を決めて、業務基盤を設計するプロジェクトです。検索と申請、移行、運用も、その設計に含まれます。
要件整理でKPIと対象範囲を決め、標準機能から方式を選びます。情報構造と権限を固めてから開発すれば、費用とリスクを抑えやすくなります。
6フェーズの成果物と承認条件による管理
要件整理では、目的やKPIを決め、データと権限を洗い出します。選定では、標準機能から外部連携まで、順に比べます。
設計開発では、サイト構造やメタデータ、グループ権限を決めます。テストでは、役割別のアクセスと、検索や移行、承認を検証します。
稼働では、段階移行と問い合わせ導線を用意します。定着では、90日間かけて利用状況を見ながら、検索・権限・運用ルールを改善します。
最初に作る資料：現状・権限・移行の一覧
現行のサイトや共有フォルダを一覧にし、文書種別と所有者、権限を書き出します。保存期限や外部共有、利用頻度も、同じ一覧に加えます。改善したい業務KPIと先行部門も決めます。
移行しないデータ、標準機能で実現する範囲、追加開発を検討する範囲を、1枚にまとめます。その資料をもとに開発会社へ相談し、相見積もりで前提を揃えます。価格だけでなく、成果物と運用体制も比べられます。
▼全体ガイドの記事
・SharePointのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。