NPOのシステム開発外注｜予算制約下で失敗しない進め方6ステップ

会員数の増加、寄付管理の煩雑化、助成金報告の締切対応 —— NPO・非営利団体の事務局現場では、Excel と紙による運用が限界を迎える瞬間が必ずやってきます。「そろそろシステム化しないと現場が回らない」という現場の声を受け、理事会からシステム化検討を任される事務局長・副事務局長の方は少なくありません。

しかし、いざシステム開発を外注しようとすると、いくつもの壁が立ちはだかります。単年度で予算を組まなければならない、有給の IT 専任者がいない、そして原資は寄付や助成金であり、理事会や所轄庁への説明責任が伴う —— この 3 つの制約が、一般企業向けの「システム開発費用相場」や「発注ステップ」といった記事の内容をそのまま自団体に当てはめられない理由になっています。

一方で、営利企業向けの発注ノウハウを NPO の文脈に翻訳した情報はまだ多くありません。SaaS で足りるのか、受託開発が必要なのか。補助金は本当に使えるのか。段階発注でリスクを分散できるのか。どこに発注すべきか。判断軸が持てず、動き出せないまま次年度予算の策定期を迎えてしまう団体もあります。

そこで本記事では、NPO 事務局長が「まず補助金の可否を確認 → 現状業務を整理 → SaaS で埋まる範囲を切り分け → 残りを小規模受託またはノーコード委託で対応」という次に取るべきアクションを言語化できるように、NPO のシステム開発外注を 6 ステップで進める意思決定フレームを解説します。理事会・寄付者に「なぜこの発注が必要か」を説明する材料の作り方まで、通しで整理していきます。

NPOがシステム開発を外注する前に押さえる3つの前提

営利企業のシステム開発発注ノウハウをそのまま NPO に持ち込むと、途中で必ず違和感が生じます。まずは NPO 特有の 3 つの制約を言語化するところから始めましょう。この 3 制約は、後述する予算配分・補助金活用・段階発注・発注先選定のすべての意思決定に影響します。

単年度予算と多年度開発のギャップ

営利企業では 2〜3 年をかけた投資回収の議論が可能ですが、NPO の予算は原則として単年度で組み、総会・理事会での承認を経て執行します。多くの助成金・補助金も単年度で完結する使途を求めるため、「今年度中に発注・検収・支払いまで完了させる」制約が強く効きます。

システム開発は要件定義から本番稼働までに 6 ヶ月から 1 年以上かかるケースが珍しくありません。単年度予算の中で「設計 → 開発 → 本番稼働 → 保守」まで詰め込もうとすると、要件を絞りきれず失敗の原因となります。逆に「まずは最小構成で稼働させ、翌年度以降に拡張する」段階発注が構造的に向いている、というのが NPO のシステム発注の出発点です。

有給 IT 専任者不在のもとで発注をリードする難しさ

中規模 NPO では、有給スタッフの多くが事業担当（プログラム運営・ファンドレイジング等）であり、システム発注をリードできる有給の IT 専任者を置ける団体は限られています。「情シス」に相当する役割は事務局長・副事務局長が兼務し、場合によってはプロボノ・ボランティア人材の協力で補うのが実態です。

このため、要件定義・見積比較・契約交渉・受入検収といった発注プロセスの各段階で、外部委託先に「専門用語なしで判断できる情報」を求める必要があります。発注先を選ぶ際にも、単に価格や技術力だけでなく、NPO の意思決定サイクル（理事会・総会）を理解し、専門用語をかみ砕いて伴走してくれるかどうかが重要な選定軸になります。

寄付・助成金原資に対する説明責任

NPO の資金は会費・寄付・助成金・事業収入など多様な原資で構成されており、それぞれに使途への説明責任があります。特に助成金は使途が事業計画書と紐づいており、システム開発費として使う場合は「なぜその機能が必要か」「事業目的にどう貢献するか」「費用は妥当か」を、事業報告書・所轄庁提出書類の中で言語化しなければなりません。

寄付者や理事会にも同様の説明が求められます。「1,000 万円の寄付原資のうち 300 万円をシステム開発に使う」という判断を、活動報告・年次総会で納得してもらう必要があります。この説明責任は制約であると同時に、後述する「削減時間×スタッフ時給」「ミッション貢献ストーリー」といった費用対効果の言語化を最初から意識できる、という利点にもつながります。

NPOに多いシステム化ニーズと外注適合度の考え方

NPO 現場で発生するシステム化ニーズは、大きく次の 5 領域に分類できます。それぞれで「SaaS で十分」「SaaS + 軽い受託カスタマイズ」「ノーコード or スクラッチ受託が必要」のどこに寄るかの目安を整理しました。自団体の課題領域を照らし合わせて、方向性を掴む第一歩にしてください。

会員管理・寄付管理はまずSaaSを検討する

会員管理・寄付管理は、NPO 業界で長年ノウハウを蓄積した SaaS が複数存在する領域です。会費徴収の自動化・領収書の電子発行・継続寄付（マンスリーサポーター）管理といった機能は、独自開発するよりも SaaS を導入したほうが圧倒的に安く、早く、確実です。

導入判断のポイントは 3 つ。第一に、月額料金と会員数・寄付者数の関係で総コストがどう変わるか。第二に、既存の会計ソフト（freee・マネーフォワード等）や決済サービスとの連携可否。第三に、退会・データ移行の容易さ（ロックインリスクの低さ）です。この 3 点で候補が絞れた段階で、外部委託は「SaaS 導入支援」の範囲にとどめ、フルスクラッチ受託は避けるのが定石です。

助成金報告・事業報告はノーコードで内製化しやすい

助成金報告・事業報告は、団体ごとに指標や集計軸が異なるため、既製の SaaS では表現しづらい領域です。一方で、事業ごとに 1 テーブル程度の管理で足りるケースも多く、kintone・Airtable・Notion といったノーコード基盤で内製化しやすい特徴があります。

外部委託が有効なのは「初期の設計・テンプレート構築」までにとどめ、日々の入力・改善はスタッフが自分たちで行えるように引き継ぐのが理想です。初期の設計費用は 50〜150 万円程度に収まることが多く、単年度予算の中でも十分に実行可能です。ノーコード委託会社の中には NPO 向けの実績を持つ団体もあり、依頼時にはその実績を確認するとミスマッチを避けられます。

独自事業（マッチング・シェアリング等）は受託開発で作り込む

一方で、NPO のミッションそのものを担う独自事業（例: 支援者と受益者をつなぐマッチング、遊休資源のシェアリング、独自の学習プログラム）は、市場に既製 SaaS が存在しません。この領域は受託開発で作り込むしかなく、他領域と切り分けて予算配分することが重要になります。

独自事業のシステム開発は、後述する段階発注（PoC → 小規模導入 → 拡張）が最も効果を発揮する領域です。会員・寄付管理を SaaS で低コストに固めた上で、余った予算と補助金を独自事業のシステム開発に集中投下する、という予算配分の型を作れれば、限られた原資でも「NPO らしい」システム化を実現できます。

NPOがシステム開発を外注するときの費用相場と予算配分

営利企業向けの一般的なシステム開発費用相場は、業務システムで 100 万円〜1,500 万円、内容によっては数千万円という広いレンジで語られます（発注ラウンジ）。ただしこの数字をそのまま NPO の予算検討に持ち込むと、単年度予算 1,000〜5,000 万円規模の団体にとっては「いくらまでなら現実的に踏み込めるか」の判断がつきません。以下では、NPO の予算規模で現実的に選べるレンジに翻訳します。

一般的なシステム開発費用の内訳（人月単価と固定費）

受託開発の費用は、大きく「人月単価 × 開発期間」＋「PM・QA 費」＋「環境費（クラウド・ライセンス）」＋「保守費」で構成されます。人月単価は開発会社の規模やエンジニアの経験年数により幅がありますが、中小開発会社の場合、1 人月あたり 80 万〜120 万円が目安です。

「見積が高いか安いか」を判断する際は、単純な合計額ではなく人月単価と工数の内訳を確認しましょう。同じ 500 万円でも、5 人月（1 人月 100 万円換算）か、10 人月（1 人月 50 万円換算）かで、開発の密度と品質が大きく変わります。工数が多い見積が必ずしも良いわけではなく、要件に対して過剰な工数を積んでいないかを比較することが重要です。

NPOで現実的に選べる4つの予算帯

NPO のシステム開発予算は、次の 4 つのレンジで整理すると意思決定しやすくなります。

年間予算 1,000〜5,000 万円規模の中規模 NPO では、単年度で 300〜800 万円までのシステム投資が「大きな決断だが不可能ではない」レンジになります。1,000 万円以上のプロジェクトは、複数年度に分割するか、大型助成金の獲得と並行して検討するのが現実的です。

見積書で必ず確認すべき項目（対象範囲・追加費用条件・保守費）

見積書を受け取ったら、金額そのものよりも「何が含まれ、何が含まれないか」を確認しましょう。特に次の 3 点は必ず書面で明確にします。

• 対象範囲: 要件定義・デザイン・開発・テスト・データ移行・ユーザー教育のうち、どこまでが見積に含まれるか
• 追加費用条件: 要件変更が発生した場合の追加費用の算定ルール（例: 1 機能追加あたり◯万円、または人月単価 × 追加工数）
• 保守費: 本番稼働後の月額保守費・障害対応の範囲・SLA（応答時間・復旧時間の目安）

NPO の場合、事業終了・組織改編で運用が変わる可能性もあります。保守契約は自動更新型ではなく、年度単位で見直せる契約にしておくと、単年度予算主義との整合が取りやすくなります。

NPOのシステム開発で活用できる補助金・助成金と申請時の注意点

システム発注コストを実質的に圧縮する最も強力な手段が、補助金・助成金の活用です。ここでは NPO が使える主な制度を 3 系統に整理し、それぞれの適用条件と申請時の注意点を解説します。

IT導入補助金のNPO適用条件と補助率

2026 年度の「デジタル化・AI導入補助金」（旧称: IT導入補助金）は、NPO 法人も対象事業者になる場合があります。通常枠の補助額は 5 万円〜450 万円、補助率は原則 1/2 以内で、一定の賃上げ要件を満たす場合には 2/3 以内になります（中小企業基盤整備機構 公式サイト）。

NPO が申請する際の重要ポイントは 3 つあります。第一に、補助対象になる IT ツールは「IT 導入支援事業者」として登録された事業者が提供する登録済みツールに限られること。第二に、単年度事業（原則）で完結する使途であること。第三に、補助金は「後払い」のため、いったん全額を自己資金で立て替える必要があること。この立替資金を予算上どう捻出するかは、事業計画段階で必ず整理しておきます。

会員管理 SaaS・寄付管理 SaaS・グループウェアなど、NPO で使いやすい多くのツールが登録済み IT ツールに含まれています。導入したい SaaS がある場合は、まずそのベンダーが IT 導入支援事業者として登録済みか、登録されている場合はどの類型・上限額で申請できるかを確認しましょう。

小規模事業者持続化補助金と地方自治体の助成金

小規模事業者持続化補助金は、NPO 法人も一定の要件を満たす場合に対象となります。具体的には、法人税法上の収益事業を実施していること、認定 NPO 法人（税制優遇を受ける認定を受けた団体）でないことなどが条件です（中小企業庁 小規模事業者持続化補助金）。補助上限は原則 50 万円（特例で最大 250 万円）、補助率は 2/3（赤字事業者は 3/4）で、比較的規模の小さな Web サイト刷新・販路開拓の一環としてのシステム導入に向きます。

このほか、地方自治体独自の DX 補助金・IT 化助成金、民間財団の NPO 向け助成金にも、システム化に使える枠が存在します。自治体の窓口・地域のNPO 支援センター・所轄庁（都道府県・内閣府）に相談すると、地域固有の補助金情報が得られます。特に「NPO 向け」を明示した助成金は、営利企業向けの一般的な IT 導入補助金より使途の柔軟性が高いことがあり、確認価値があります。

申請前に確認しておくべき3つのポイント

補助金申請前に、事務局として整理しておきたいポイントを 3 つ挙げます。

• gBizID プライムの取得: IT導入補助金など多くの制度で必須。取得には 2 週間程度かかるため早めに申請
• IT 導入支援事業者の選定: 制度によっては、補助金申請と交付申請の実務を IT 導入支援事業者と共同で進める設計になっている。導入希望 SaaS のベンダーがこの役割を果たせるか、事前に確認
• 多年度事業の扱い: 補助金は原則単年度で完結。複数年にわたる開発・保守を計画している場合、「単年度で実施する部分」と「翌年度以降の自己資金部分」を切り分けて事業計画を作る必要がある

補助金を「使えるかもしれない」という段階で発注を止め、まず gBizID の取得・IT 導入支援事業者との対話を並行して進めることで、申請時期と発注時期を無理なく整合させられます。

予算制約下でリスクを抑える段階的なシステム開発発注の進め方

単年度予算・専任者不在・説明責任の 3 制約下で「失敗できない」不安を抱える場合、最も効果的な対策が段階発注です。開発を一括発注せず、PoC（試行）→ 小規模導入 → 拡張・保守と段階を区切ることで、投資判断を分割し、リスクを可視化・分散できます。

段階発注がNPOに向く理由（単年度予算・意思決定サイクルとの整合）

段階発注は、実は NPO の意思決定サイクルと相性が非常に良い進め方です。理由は 3 つあります。第一に、単年度予算主義との整合。1 年目に PoC で「本当に実現できるか」を検証し、2 年目に本格導入予算を組む、という流れが自然に作れます。第二に、理事会・総会での説明のしやすさ。全額を一気に投じるのではなく「まず◯万円で試して、成果が出たら本格導入する」提案は、承認が得やすくなります。第三に、要件変更への耐性。NPO は事業内容が助成金採択・社会情勢で変わりやすく、開発途中で要件が変わることが珍しくないため、区切りで見直せる進め方が向きます。

PoCフェーズで確認すべきこと（要件の実現可能性・工数見積の精度）

PoC フェーズの期間は 1〜2 ヶ月、費用は 50〜150 万円が目安です。契約形態は「準委任契約」（成果物ではなく作業時間に対して支払う契約）が向きます。準委任にすることで、要件の実現可能性を検証しながら柔軟に方向転換でき、「作り切ることを求められる請負契約」のリスクを避けられます。

PoC で確認すべきは大きく 3 点です。第一に、要件が技術的に実現可能か（既存 SaaS との連携、データ移行、性能要件など）。第二に、本格開発時の工数見積の精度（PoC で作った部分の実工数から、本開発の見積が現実的かを検証）。第三に、外注先との協働のしやすさ（コミュニケーション頻度・専門用語のかみ砕き方・提案の質）。この 3 点が確認できれば、本格導入フェーズの契約を安心して結べます。

本格導入・保守フェーズの費用予測と契約形態

PoC の結果を受けて本格導入に進む場合、期間は 3〜4 ヶ月、費用は 150〜400 万円が目安です。契約形態は「請負契約」（成果物に対して支払う契約）が向きます。PoC で工数見積の精度が確認されていれば、請負契約でも過剰な見積・追加費用リスクを抑えられます。

本番稼働後の保守フェーズは、月額 5 万〜20 万円が目安です。障害対応・軽微な機能追加・OS/ミドルウェアのアップデート対応が主な内容になります。契約は年度単位で見直す設計にし、事業拡大に伴って必要な機能が増えた場合には、翌年度の予算増額と併せて改めて発注する、という運用に整えるのが単年度予算主義との整合が取れます。

NPOのシステム開発外注 発注先の選び方

「どこに発注するか」も、NPO 特有の観点で選定する必要があります。予算・技術力だけでなく、NPO の意思決定サイクルへの理解、継続保守への姿勢、そして情報公開（プロセス透明性）への理解が重要な選定軸になります。

発注先タイプ別の費用感と得意領域

主な発注先候補を、費用感と得意領域で整理します。

中規模 NPO が単年度 300〜800 万円のシステム発注をする場合、最有力の候補は「中小開発会社」または「中小開発会社 + フリーランス」の組み合わせです。大手 SIer は予算規模的に合わないことが多く、逆にフリーランス単独では要件定義・進捗管理を任せきれないため、両者を組み合わせるハイブリッド型が予算効率と品質の両立に有効になります。

NPO案件で確認すべき発注先の観点（継続保守・低予算対応・ドキュメント）

発注先の候補が絞れたら、次の観点を打ち合わせで確認しましょう。

• 継続保守への姿勢: 開発完了後の保守を単年度契約で受けてもらえるか。年度更新時の再交渉に応じてもらえるか
• 低予算対応の姿勢: 段階発注（PoC 50〜150 万円）を受けてもらえるか。「うちは 500 万円未満の案件は受けない」という会社は NPO 案件には向きません
• ドキュメントの提供: 完成システムの技術仕様書・運用マニュアル・データ構造の説明資料を成果物として提供してもらえるか。NPO では担当スタッフが数年で交代するため、ドキュメントが後任・他社への引き継ぎ材料になります
• NPO 案件の実績: 過去に NPO・非営利団体のシステム開発を手掛けた経験があるか。実績があると、NPO 特有の意思決定サイクル・説明責任への理解が期待できます

フリーランス・複業人材の活用で費用を抑える選択肢

近年は、大企業や中堅企業に所属しながら副業・複業でシステム開発案件を請け負うエンジニアが増えています。これらの複業人材は、開発会社経由の受託よりも人月単価が抑えられ、かつ大企業の現場で実務経験を積んだ実力者が多いという特徴があります。

NPO 案件では、要件定義・PM を中小開発会社が担い、実装の一部を複業エンジニアが担う、といった役割分担が予算圧縮に有効です。複業人材のマッチングを支援するプラットフォームや、開発会社が複業エンジニアを組み込んだチーム編成を提案するケースも増えています。発注時には、複業人材が入る場合の情報セキュリティ管理体制、契約形態、稼働時間の確保方法を必ず確認しておきましょう。

理事会・寄付者への説明に耐える費用対効果の言語化

システム発注の意思決定を、理事会・主要寄付者・所轄庁に説明するとき、営利企業のように「ROI◯％」「投資回収 3 年」といった数字だけを並べても、共感は得られません。NPO では、費用対効果をミッション貢献のストーリーに翻訳する言語化が必要になります。

費用対効果を「削減時間×スタッフ時給」で試算する

まず定量的な効果として、システム化により削減される事務作業時間を試算します。試算の基本式は次の通りです。

削減効果（年間）= 月間の削減時間 × 12 ヶ月 × スタッフ 1 時間あたり時給換算

例えば、会員管理・寄付領収書発行の作業が月 40 時間かかっている団体で、システム導入により月 30 時間に短縮できる場合、年間 120 時間の削減。スタッフ時給を 2,500 円と仮定すると、年間 30 万円分の労働時間が浮きます。この浮いた時間を「別の業務に振り向ける」のではなく「本来のミッション活動（プログラム運営・ファンドレイジング・アドボカシー）に振り向けられる」と説明することで、寄付原資の使い方として納得感が高まります。

ミッション貢献ストーリーに翻訳する

定量効果の次に必要なのが、ミッション貢献ストーリーへの翻訳です。「浮いた 120 時間で年間◯回の追加プログラムを実施できる」「寄付者応対の品質が上がり、継続寄付者の解約率が◯％下がる見込み」といった、NPO らしい成果指標に言い換えます。

このストーリー化は、単なる「後付けの正当化」ではなく、システム発注の意思決定そのものに影響します。定量削減効果は大きいがミッションへの直接貢献が薄い機能より、削減額は小さくてもミッション貢献が明確な機能を優先する、という判断基準を作れるからです。理事会・寄付者への説明素材が、そのままシステム要件の優先順位付けの物差しになる、と考えると、この言語化は「発注後の説明」ではなく「発注前の意思決定」の一部として扱うべきものになります。

理事会向け提案書に入れるべき5項目

理事会・総会でシステム発注の承認を得るための提案書には、次の 5 項目を最低限入れましょう。

1. 現状の課題と定量的な悪化トレンド: 会員数・寄付額の伸び、それに対する事務作業時間の増加、現場からの不満
2. 選定した手段の概要と代替案の比較: SaaS 導入・ノーコード委託・受託開発のうち、なぜ今回の手段を選ぶかを他の代替案との比較で示す
3. 費用計画と補助金活用計画: 総費用・自己負担額・補助金充当額・単年度予算への影響
4. 段階発注のロードマップ: PoC → 本格導入 → 保守の各段階の期間・費用・意思決定ゲート（次段階に進む/進まないの判断基準）
5. 費用対効果（削減時間×時給・ミッション貢献ストーリー）: 前述の言語化を組み込む

この 5 項目が揃った提案書は、理事会での承認だけでなく、助成金申請書の事業計画書・寄付者への活動報告書にもそのまま活用できます。1 つの提案書を複数の説明シーンで再利用する設計にしておくと、事務局長の作業負担を大きく減らせます。

まとめ｜NPOがシステム開発を外注するときに大切にしたい判断軸

ここまで、NPO・非営利団体がシステム開発を外注する際の 6 ステップの意思決定フレームを解説してきました。要点を振り返りましょう。

まず、NPO 特有の 3 制約（単年度予算・有給専任者不在・説明責任）を先に言語化することが出発点です。この 3 制約が、以降の予算配分・補助金活用・段階発注・発注先選定のすべてに影響します。

次に、5 領域のシステム化ニーズ（会員管理・寄付管理・助成金/事業報告・ボランティア/イベント管理・独自事業）に対して、SaaS で埋める範囲、ノーコードで内製化する範囲、受託開発で作り込む範囲を切り分けます。この切り分けにより、限られた予算を「独自事業を作り込むところ」に集中投下できるようになります。

費用については、単年度 300〜800 万円のレンジが中規模 NPO の現実的な発注帯です。デジタル化・AI導入補助金（旧 IT導入補助金）や小規模事業者持続化補助金・地方自治体の DX 補助金を組み合わせて実質負担を圧縮しつつ、単年度で完結する事業計画に落とし込みます。

そして、段階発注（PoC → 本格導入 → 保守）で意思決定を分割し、「失敗できない一発勝負」のリスクを分散させます。発注先は中小開発会社を核に、フリーランス・複業人材を組み合わせるハイブリッド型が予算効率と品質の両立に有効です。

最後に、費用対効果を「削減時間×スタッフ時給」で定量化し、ミッション貢献ストーリーに翻訳して理事会・寄付者への説明素材に仕立てます。この提案書がそのまま助成金申請書・活動報告書にも活用でき、事務局長の作業負担を減らします。

読了後にすぐ着手できる次のアクションは 3 つあります。

• 現状業務（会員・寄付・報告）の月間作業時間を棚卸しし、システム化候補の領域を特定する
• 導入候補 SaaS が「IT 導入支援事業者」として登録済みかを確認し、補助金活用の可否を試算する
• 地域の NPO 支援センター・所轄庁・自治体窓口に相談し、地域固有の DX 補助金・助成金情報を集める

この 3 つが揃えば、次の理事会で「なぜ今、システム発注が必要か」を、単年度予算・補助金活用計画・段階発注ロードマップとセットで説明できる状態になります。動き出せなかった状態から、意思決定できる状態への転換 —— 本記事がその一歩を後押しできれば幸いです。