（MYポータル）
中小企業支援システム構築・運用業務委託仕様書
平成 30 年 2 月 2 日 xxx中小企業振興公社
目次
図表目次
中小企業支援システム構築・運用業務委託
契約確定日の翌日から平成 31 年 3 月 31 日まで
※提案内容には、初期構築に加え、平成 35 年度までの運用・保守を含めること
※平成 31 年 4 月 1 日以降は、各年度の予算が確定次第、受注者と別途契約を締結するものとする。
xxxxxx区xxxxx町１－９
公益財団法人xxx中小企業振興公社（以下、公社という。）ほか、公社が承認した場所とする。 受注者は自ら業務の履行場所を確保すること。なお、業務の履行場所の選定にあたっては、緊急時に
おける対面での連絡調整も想定し、公社に速やかに来訪可能な地域内に選定すること。
既存の顧客管理システムは、企業間取引（あっせん業務）の促進や企業訪問等の履歴を蓄積・抽出する目的で 2006 年に導入し、今年度で 11 年目を迎える。事業の拡大や変化に対して柔軟にシステム変更ができないため、改修において運用・費用面から負担が重くなっている等、様々な課題が生じている。このため、今後の事業・職員数の拡大に向けた、より柔軟に対応可能な新システムの導入の必要性が高まっている。
本仕様書は中小企業支援システム（以下、新システムという。）に求められる要件および範囲等に関する仕様をまとめたものである。
システム構築に係る調達範囲は、本システム利用にあたって必要となるハードウェア、ソフトウェア等システム資産一式、システム構築および運用業務等の委託作業とする。
※なお、本仕様書はシステムを構築し、情報セキュリティ対策が強固なデータセンターにシステムを設置・運用することを想定し作成している。しかし、公社の求める要件を充足できるならば、クラウドサービスなど受注者の創意工夫による提案を妨げるものではない。
※クラウドサービス等を提案する場合は、本仕様書の中の要件を満たすよう、サービスや代替案を提案すること。
※システムの導入に際しては、公社と十分に協議の上、構築・運用・保守を実施すること。
受注者は、以下に記載する導入方針、スケジュール、工程定義、導入体制に基づき、新システムを導入すること。
中小企業の支援及び内部管理の改善を強力に行なうためのツールとして、新システムを導入する。中小企業の支援の改善では、新システムを活用し、
① 正確かつ一元化された情報をシステム分析
② 作業の効率化によって生じた時間で企業支援を強化
③ 適切な情報提供で企業支援の強化を図ることを目的とする。内部管理の改善では、新システムを導入することで、
① 入力作業の標準化、作業の自動化と省力化を図り
② 情報をxx管理し支援状況を社内で共有
③ 多様な事業や利用者に対する高拡張性システムとすることを目的とする。以下にシステムの導入目的を図として示す。
見込まれる成果 ①カルテデータから支援企業の経営課題を抽出（効率的な支援策検討）
②経営課題から効果的な支援策を検討（職員のノウハウ蓄積）
③訪問時間の増加による顧客満足度の向上
③ 適切な情報提供で企業支援を強化
・ＭｙページシステムやＥラーニングの導入
③多様な事業や利用者に対応する高拡張性システム
② 作業効率化によって生じた時間で企業支援を強化
・効率的効果的な企業訪問の実現
② 情報をxx管理し、支援状況を社内で共有
・定期的に情報を更新、情報の正確性を維持
導入後
（中小企業支援システムを活用した企業支援）
① 正確かつ一元化された情報をシステムで分析
・ヒアリングや分析の結果を元に経営課題を抽出
・抽出した経営課題から新たな支援案を立案
（中小企業支援システムの導入）
① 入力作業を標準化、作業の自動化と省力化を図る
企業支援
内部管理
・有効支援情報の抽出機能無し
状 ・事業や利用者の多様化、ＩＴ化への対応の遅れ
直接的な支援機能無し
現
（ 現 状 の 課 題 ）
・入力作業負荷過大 → 更新遅れ → データ信頼性低下
企業支援
内部管理
蓄積型の「顧客管理システム」から、発信型の「中小企業支援システム」へ
中小企業支援システムの導入について（内部管理・企業支援の改善）
図 1 システム導入の目的
また、以下に、システムの全体構成イメージを示す。
公社
メニュー
公社
機能
情報
企業
機能
企業メニュー
お知らせ
01 公社ﾄｯﾌﾟﾍﾟｰｼﾞ
（MYポータル）
お知らせ
22 企業ﾄｯﾌﾟﾍﾟｰｼﾞ (MYポータル)
お知らせ
連携
基本情報
02 事業情報管理
03 企業情報管理
支援情報に基本情 05 専門家等
基本情報
報を紐付け
04 支援情報管理
06 専門家等記録管理
07 業務日報管理
プロフィール管理
連携
案件情報
支援実績
支援情報に進捗情 連携
報を紐付け
08 ステータス管理 進捗情報
支援情報をサンプリングして統計出力
統計・分析
09 統計情報管理
連携
申請受付
10 イベント情報管理
11 電子申請管理
12 予約管理
申請情報
22 電子申請・予約
申請届出
連携
ホームページ
14 ﾎｰﾑﾍﾟｰｼﾞ情報管理
HP情報
e-ラーニング
教材情報
e-ラーニング
23 e-ラーニング管理
13 e-ラーニング管理
図 2 システムの全体構成イメージ
新システムの仮稼働日は、平成 31 年 4 月 1 日とし、この日から 2 か月は仮稼働とする。なお、受注
者は仮稼働日の前日までにシステムを構築すること。また、本稼働は 6 月 1 日とし、それまでにデータ移行を完了させること。以下に公社が想定する導入スケジュールを示す。具体的なスケジュールについては、提案すること。
なお、１次構築では別紙１「機能要件一覧」に示す「13 及び 23 e-ラーニング管理（２次構築を想定）」以外の機能の実現すること。
※サブシステムとのデータ連携（「４．１（４）その他業務要件」を参照）については、構築時に検討すること。
平成30年度 | 平成31年度 | 平成32年度 | 平成33年度 | 平成34年度 | 平成35年度 | |
全体計画 | １次 構築・移行 | 研修 | １次 運用開始 ２次 構築・移行 | 研修 | 運用・保守 | |
業務面のアクション | ・データ整備 | ・新システム利用開始 | ||||
システム面の アクション | ・１次機能構築 ・データ移行 ・１次研修 | ・年度更新 ・データ移行 ・１次運用 ・２次機能構築 ・２次研修 | ・年度更新 ・運用保守 | ・年度更新 ・運用保守 | ・年度更新 ・運用保守 | ・年度更新 ・運用保守 |
図 3 導入スケジュール
新システム導入における工程定義を以下に示す。
表 1 工程定義
№ | 工程 | 定義 | |
1 | プロジェクト管理 | ∙ 新システムの導入の目的・目標を定められた期間内に実施する作業のまとまりをプロジェクトと定義する。 ∙ プロジェクト管理は、工程管理、品質管理、課題管理等の実施要領をまとめた業務実施計画書を作成し、プロジェクト期間全体を通して、プロジェクトを適 切かつ円滑に行うための管理と定義する。 | |
2 | 要件定義 | ∙ 新システムの設計・開発、運用・保守等の業務を行うにあたって、必要な要件を明確に定める工程と定義する。 | |
3 | 設計 ・開発 | 設計 | ∙ 要件定義の成果物に基づき、新システムの設計（システム構成、パッケージ適用、カスタマイズおよびデータ移行等の設計）を行う工程と定義する。 |
開発 | ∙ 新システムの設計工程の成果物に基づき、新システムの開発（パッケージ適用、カスタマイズ開発、ツール開発等）を行う工程と定義する。 ∙ なお、開発工程には、カスタマイズ開発およびツール開発の単体・結合テスト を含むものとする。 | ||
環境構築 | ∙ システム構成設計に基づき、新システムのハードウェア、ソフトウェアの環境構築を行う工程と定義する。 | ||
4 | テスト | 機能テスト | ∙ 機能全般に関するテストを行う工程と定義する。 |
性能負荷テスト | ∙ ログイン集中時の画面表示や画面遷移に要する時間が実運用に耐えられる性能となっているか等のテストを行う工程と定義する。 ∙ なお、性能テストツール等を用いて実運用に近いアクセス数でのテストを行う こと。 | ||
異常系テスト | ∙ サーバの何台かを停止させた場合等の縮退運転やログイン不能の場合でも他システムとの連携を行う等のテストを行う工程と定義する。 | ||
システムテスト | ∙ システム全体として、要件定義にて要求された事項を満たしているかを総合的に検証する工程と定義する。 ∙ システムテスト工程までは、受注者の開発環境で行うこと。 | ||
受入テスト | ∙ 公社が、要件定義書に記載された事項が適切に実現しているかを検証するため、受注者の支援を受けながら本番稼働時に近いデータを用いてテストを行う工程と定義する。 ∙ 受入テストは公社のシステム運用担当者等の関係者が参加する。 | ||
∙ 受入テスト完了後、運用環境に本番データを移行し、一般利用者も含めて仮稼働（約 2 ヶ月間）を行う工程と定義する。 ∙ なお、運用テストは、現行システムと並行稼働を行うものとする。 | |||
№ | 工程 | 定義 | |
5 | 移行 | データ移行 | ∙ 現行システムから新システムへデータ移行を行う工程と定義する。 |
研修 | ∙ 新システムを円滑に利用できるようにするために、操作マニュアルや運用マニ ュアルを作成し、利用者・システム運用担当者向けに研修を行う工程と定義する。 | ||
6 | 運用・保守 | ∙ 運用工程は、新システムの仕様・設計および構成の変更を原則として行わずに、新システムの稼働状態を維持することを目的とした行為およびこれに付随す る行為と定義する。 ∙ 保守工程は、機能維持、品質維持等、新システムを設計された仕様どおりに動作させることを目的とした行為およびこれに付随する行為と定義する。 ∙ 保守とは、アプリケーションプログラムの保守、ハードウェアの保守、ソフト ウェア製品の保守、データの保守等を指す。 | |
公社の体制については、企画課が本システム導入の推進担当課となり、必要に応じて関係課を体制に含める。
新システムの構築および運用・保守における公社の役割と受注者の役割を以下に示す。
表 2 公社の役割
№ | 工程等 | 役割概要 |
1 | プロジェクト管理 | ∙ 工程管理、課題管理、品質管理の発注者としてプロジェクト管理を行う。 ∙ 他部門調整、会議体運営全般の管理を行う。 ∙ 業務実施計画書の承認を行う。 ∙ 工程完了判定（稼働判定を含む）、懸案事項や課題に対する決定・承認を行う。 ∙ 機器等の設置・設定に係る調整を行う。 |
2 | 要件定義 | ∙ 要件定義の進め方、成果物の承認を行う。 ∙ 要件のとりまとめおよび定義を行う。 ∙ 要件定義工程の成果物のレビュー・承認を行う。 |
3 | 設計・開発 | ∙ 設計・開発の進め方、成果物の承認を行う。 ∙ 設計・開発工程の成果物のレビュー・承認を行う。 |
4 | テスト | ∙ テスト計画、テスト方法、成果物の承認を行う。 ∙ テスト工程の成果物のレビュー・承認を行う。 ∙ 受入テストを実施し、仮稼働（運用テスト）判定の承認を行う。 ∙ 並行稼働期間に運用テストを実施し、本稼働判定の承認を行う。 |
5 | 移行 | ∙ データ移行に係る方針、計画、成果物等の承認を行う。 ∙ データ移行の検証を行う。 ∙ データ移行の成果物のレビュー・承認を行う。 |
6 | 研修 | ∙ 利用者研修に係る方針、計画、実施方法、成果物等の承認を行う。 ∙ 利用者研修実施における調整（対象者、日時・場所等）を行う。 |
7 | 運用・保守 | ∙ 運用・保守計画、運用・保守項目、実施方法、品質管理、会議体運営全般についての承認を行う。 ∙ 運用・保守工程における作業実績の承認を行う。 ∙ 運用・保守工程の成果物のレビュー・承認を行う。 |
表 3 受注者の役割
№ | 工程等 | 役割概要 |
1 | プロジェクト管理 | ∙ 業務実施計画の作成、工程管理、課題管理、品質管理、会議体運営等、受注者としてのプロジェクト管理を行う。 ∙ 機器等の設置・設定に係る調整を行う。 |
2 | 要件定義 | ∙ 要件定義の実施方法（スケジュール、体制、成果物等）を作成し、公社の承認を得る。 ∙ 要件のとりまとめおよび定義を行う。 ∙ 要件定義工程の成果物のレビュー・承認依頼を行う。 |
3 | 設計・開発 | ∙ 設計・開発の実施方法（進め方、成果物等）を作成し、公社の承認を得る。 ∙ 実施方法に基づき設計・開発を行う。 ∙ 設計・開発工程の成果物のレビュー・承認依頼を行う。 |
4 | テスト | ∙ テスト計画（実施方法、スケジュール、体制、成果物等）を作成し、公社の承認を得る。 ∙ テスト計画に基づくテストを実施し、不具合を解消する。 ∙ テスト工程の成果物のレビュー・承認依頼を行う。 ∙ 受入テストの環境準備および受入テストの実施を支援する。 |
5 | 移行 | ∙ データ移行計画（移行範囲、対象データ、移行方法、スケジュール、体制、成果物等）を作成し、公社の承認を得る。 ∙ 移行計画に基づくデータ移行を行い、移行データを検証する。 ∙ データ移行の成果物のレビュー・承認依頼を行う。 |
6 | 研修 | ∙ 利用者研修計画（対象者、実施方法、スケジュール、体制、成果物等）を作成し、公社の承認を得る。 ∙ 利用者研修計画に基づく利用者研修を実施する。 ∙ 利用者研修の成果物のレビュー・承認依頼を行う。 |
7 | 運用・保守 | ∙ 運用・保守計画（運用・保守方針、運用・保守項目、実施方法、品質管理、会議体運営等）を作成し、公社の承認を得る。 ∙ 運用・保守計画に基づく運用・保守作業を実施する。 ∙ 運用・保守作業における課題管理、品質管理、定例報告を行う。 ∙ 運用・保守工程の成果物のレビュー・承認依頼を行う。 |
また、以下に委託業務内容と役割分担の概要をまとめた表を示す。
既存システム環境導入事業者とは、公社の既存の顧客管理システム及びシンクライアント環境（データセンターを含む）を導入している事業者を指す。
表 4 委託業務内容と役割分担
【凡例】◎：主担当、○：支援
委託業務 | 内容 | 役割分担 | |||
公社 | 受注者 | 既存ｼｽﾃ ﾑ環境導入事業 者 | |||
プロジェクト管理 | 業務実施計画書の作成 | ◎ | |||
プロジェクトの工程管理、課題管理、品質管理、会 議体運営等 | ◎ | ||||
機器等の設置・設定に係る調整 | ○ | ◎ | ○ | ||
他部門調整、会議体運営全般の管理 | ◎ | ||||
要件定義 | 要件定義書等の作成 | ◎ | |||
設計・開発 | 現行システムに係る情報（設計書等）の提供 | ◎ | |||
設計・開発 | ◎ | ||||
テスト | 単体テスト、結合テスト | ◎ | |||
結合テスト | 機能、性能、障害要件等テスト | ◎ | ○ | ||
他システム連携テスト | ◎ | ||||
受入テスト | 受入テスト準備 | ◎ | ○ | ||
機能等の確認テスト | ◎ | ○ | ○ | ||
開発、テスト環境の構築 | ◎ | ||||
移行 | 移行計画の策定 | ◎ | |||
現行システムからのデータ抽出作業 | ◎ | ○ | ○ | ||
データ移行・検証 | ◎ | ||||
研修 | 研修実施計画等の策定 | ◎ | |||
関係者との調整 | ◎ | ||||
担当者ごとの研修の実施 | ◎ | ||||
運用・保守 | 運用・保守計画等の策定 | ◎ | |||
運用・保守の実施 | ◎ | ||||
会議体運営等 | ◎ | ||||
受注者は、以下に記載する構築時のプロジェクト管理および運用・保守時のプロジェクト管理を行うこと。
（１）業務実施計画書の作成
業務全体のプロジェクト管理方法、体制、計画（作業ごとの詳細スケジュール含む）等を記載した業務実施計画書について、契約締結後 2 週間以内に作成および提出し、公社の承認を得ること。
（２）進捗管理
各タスクの状況把握およびスケジュール管理を行うため、次の要件を満たす進捗管理を実施すること。
(a) WBS（Work Breakdown Structure）等により作業工程ごとに必要な成果物、作業タスクを明確にすること。
(b) プロジェクトの進捗状況を管理する進捗管理表および各作業タスクの進捗状況等を定量的に分析した報告書を定期的（月 1 回の頻度）に作成および提出し、公社の承認を得ること。
(c) 計画から遅れが生じた場合は、原因を調査し、要員追加や担当者変更等の体制見直しも考慮した改善策を提示し、公社の承認を得た上で、実施すること。
（３）課題管理
プロジェクト遂行中に発生した各種課題をxx的に管理するため、次の要件を満たす課題管理を実施すること。
(a) 課題の内容、発生日、優先度、解決予定日、担当者、対応状況、対応策、対応結果および解決日等の情報をxx的に管理すること。
(b) 課題には適宜対応し、迅速な対応および解決に取り組むこと。
(c) 定期的（月 1 回の頻度）に対応状況を確認および報告し、課題の経過状況を公社と共有すること。
（４）コミュニケーション管理
プロジェクトに係る全ての参画者が円滑かつ効率的なコミュニケーションを可能とするため、次の要件を満たすコミュニケーション管理を実施すること。
(a) 作業工程ごとにおける各種作業に関する打合せ、成果物等のレビューのほか、進捗・課題等に関する報告を定期的に行う会議を開催すること。
(b) 会議および報告会等については、会議の内容、対象者および開催頻度等を明確にすること。なお、会議の開催頻度等は、各作業工程の状況等を鑑みて、公社と協議の上、必要に応じて変更すること。
(c) 会議および報告会等が開催される都度、原則 3 営業日以内に議事録を提示し、公社の承認を得ること。
（５）体制・要員管理
プロジェクトに参画する要員の選定、変更および体制維持に関する管理を行うため、次の要件を満たす体制・要員管理を実施すること。
(a) 作業工程ごとおよび作業タスクごとに必要となるスキルに応じて、適切な知識および経験を有した要員を配置すること。
(b) 適切な履行が期待できないと公社が判断した場合や真にやむを得ない理由により要員を変更する場合は、事前に公社と協議の上、変更の可否を確認すること。なお、代替要員については、変更前の要員と同等以上の知識および経験を有する要員とすること。
（６）リスク管理
プロジェクトの円滑な進行を阻害するプロジェクト内外のリスクを特定し、対応策の検討および実施状況等を管理するため、次の要件を満たすリスク管理を実施すること。
(a) プロジェクトの遂行に影響を与えるリスクを特定し、その発生要因、発生可能性、影響度およびリスク軽減策を整理すること。また、定期的にリスクを監視および評価し、その結果を公社と共有することで、リスクによる影響の抑制に努めること。
(b) リスクの発生に備え、緊急対応時の体制および計画を整備すること。
（７）品質管理
開発するシステムおよび設計書等の成果物の品質を保証するため、次の要件を満たす品質管理を実施すること。
(a) 作業工程ごとおよび納入成果物ごとに品質評価基準等を設定し、評価結果を公社に報告すること。
(b) 検証、品質改善策の検討および実施を管理する体制を構築するとともに、品質改善のための各種取り組みが、事前に定められた手続きに則って実施されていることを的確に確認・報告すること。
（８）変更管理
開発するシステムおよび設計書等の成果物の構成および変更の履歴を管理するため、受入テスト工程以降において、次の要件を満たす構成・変更管理を実施すること。
(a) 開発するシステムのソースコードや各種設計書等、変更の履歴を管理する構成管理対象を特定し、適切に管理すること。
(b) 変更履歴を管理するだけではなく、ソースコード等の構成管理対象は、プログラム変更によるデグレード（ソフトウェアのバージョンアップに伴う品質低下）対策のため、最新版や特定時点の版（不具合発生前の版等）を、いつでも提供できる仕組みを確立すること。
(c) 仕様や構成管理対象の変更について、定期的に監査および評価し、問題があった場合には、公社に報告すること。
（９）セキュリティ管理
各作業工程におけるセキュリティに関する事故の発生を未然に防ぐため、次の要件を満たすセキュリティ管理を実施すること。
(a) 受注者の品質管理部門等の第三者、又は外部機関によるセキュリティ監査が実施される場合、セキュリティ監査結果に対する改善や対策の実施状況について、公社に報告すること。
新システム運用・保守時のプロジェクト管理の項目は以下を想定している。具体的な内容については、提案すること。運用・保守時に別途受注者と協議するものとする。
（１）業務実施計画書の作成
（２）作業実施管理
（３）成果物の提出およびサービス改善提案
新システムは、対象業務を適正、確実かつ効率的に行うシステムとして構築すること。
また、システム構築に際し、パッケージシステムによる構築を行う場合は、公社における必須機能要件がパッケージ機能に搭載されていない場合はカスタマイズについても考慮すること。
なお、各機能の具体的仕様については、設計時において受注者と公社との協議により決定するが、応札希望者は、提案書において、各機能の具体的な実現方法、実装方法についての考え方を記載すること。
（１）業務実施手順
B：講座・展示会
A：派遣・支援
現行の業務運用について、「図 4 業務パターン毎のフロー」を参考に体系的に取りまとめ、業務パターン毎に、PDCA（計画（plan）→実行（do）→評価（check）→改善（act））サイクルを効果的に実施できるようにすること。
経営会議
Plan
Do
Check Action
総合相談
業務パターン
広報活動
面談・面接
派遣
支払
請求
xxxx等
支払
募集・案内 相談・受付
調査
審査
助成
選定
紹介
抽出
巡回
システム化の範囲
報告
報告
報告
報告
報告
計画
C：助成
D：紹介・マッチング
E：巡回
図 4 業務パターン毎のフロー
（２）情報セキュリティの確保
システム構築にあたっては、公社の情報セキュリティの関連規程等を遵守すること。セキュリティに関する事項については、業務を進める中で協議、および確認を行うこととする。
（３）企業データベースの活用
構築する新システムにおいては、常に最新化している企業データベースを活用し、企業の基本情報を更新すること。受注者においては、以下の項目を常に最新化している企業データベースを準備
するとともに、構築する新システムの企業情報と連携して毎日自動で更新すること。
※企業データベースの準備・更新・連携も委託費用に含むものとする。
※企業データベースは、中小零細企業を含む都内法人 110 万社以上の企業情報を有していること。
表 5 自動更新する企業の基本情報（項目）
項目名 | 仕様 | 備考 |
企業名 | ||
企業名（フリガナ） | ||
代表者名 | ||
代表者名（xxxx） | ||
代表者役職 | ||
業種（大） | 日本標準産業分類 | 分類が改定された際に対応する |
業種（中） | 日本標準産業分類 | 分類が改定された際に対応する |
業種（小） | 日本標準産業分類 | 分類が改定された際に対応する |
資本金 | ||
設立年 | ||
従業員数 | ||
法人マイナンバー | ||
ＨＰのＵＲＬ | ※任意項目 | |
住所 | ||
電話番号 |
（４）その他業務要件
公社では、構築する新システム以外に、サブシステムが存在する。サブシステムは、構築する新システムとのデータ連携を行うこと。以下にサブシステムとの連携方針（方法）を示す。効率的な連携方法について、提案すること。※将来的には、自動で連携することを想定している。
表 6 サブシステムとの連携方針
連携先 | 連携する情報 | 情報を授受する方法 | 授受方法 | 実施頻度 | ||||
ファイル（CSV等）に出力し、新システムへインポート | 連携先と新システムにそれぞれ登録する | その他 | 時期 | 処理件数 | ||||
1 | NIコラボ | 顧客管理や訪問記録等 | ○ | － | － | 手動 | 毎日 | － |
2 | マイクロソフトダイナミクス | 顧客情報や来訪者情報 | ○ | － | － | 手動 | 毎日 | － |
3 | セールスフォース | 顧客情報や来訪者情報 | ○ | － | － | 手動 | 毎日 | － |
4 | ビジネスチャンス ナビ2020 | セミナーや展示会に参加 した企業に関する情報 | ○ | － | － | 手動 | 毎日 | － |
新システムの機能概要を以下に示す。
（１）機能要件
受注者は、別紙１「機能要件一覧」に記載する各要件と、導入するシステムの標準機能（パッケージ）との FIT&GAP 分析を実施し、システムの標準機能で実現できる要件と、システムのカスタマイズまたは追加開発等が必要になる要件の整理を行い、成果物について公社の承認を受けること。また、受注者は、現行業務フローおよび新システム導入後の新業務フロー（案）をもとに、導入 するシステムを用いたワークフローを策定し、成果物について公社の承認を受けること。なお、新
業務フロー（案）については、受注者にのみ開示する。
機能要件の実現にあたっては、以下の点に留意し、システムを提案すること。
① 別紙１「機能要件一覧」に記載する各要件の中で、項目の No.が緑色に塗った項目については、機能の実装だけでなく、運用支援による要件の実現でも可とする。
② 別紙１「機能要件一覧」の「9 統計情報管理（9-3 データ抽出機能）」については、別紙
３「集計帳票一表」に記載したものをデータとして抽出し、帳票（単なる一覧表）及びデータ（CSV）で出力することを想定している。現行システムの帳票の分析を行ない、各帳票の利用形態等に応じ、IT の専門家ではない職員が容易に抽出条件を設定できるような柔軟なシステムとすること。
③ 別紙１「機能要件一覧」の「14 ホームページ情報管理」により、公社ホームページを構築する際には、SEO 対策に配慮したホームページとすること。
（２）帳票要件
現行システムの帳票は、別紙２「帳票要件一覧」に示す。
新システムにおいても、これらの帳票を現行システムと同様に作成するものであるが、本開発にあたっては、現行システムの帳票の分析を行い、各帳票の利用形態等に応じ、IT の専門家ではない職員が容易に抽出項目を選択し、CSV 出力を行える柔軟なシステムとすること。
（１）システム化方式要件
システム化要件を実現するアーキテクチャとして、ハードウェア構成、ネットワーク、ソフトウェア構成、手作業を明確にし、これらのいずれかにシステム要求事項を割り振り、システム方式とシステム要求事項を割り振った結果を文書化すること。
また、新システムは、現在、公社に導入されているシンクライアントでの運用を前提とする仕組みとすること。
（２）環境要件
(a) 利用端末要件
新システムの構築（公社向け機能）に際しては、以下の利用端末を考慮し、構築すること。
① 端末の種類
・シンクライアント端末、物理端末
② 端末の OS
・Windows7、Windows10
(b) ネットワーク要件
公社のネットワーク構築においては、パフォーマンスや信頼性、組織の拡大やビジネスの変化に柔軟に対応できる拡張性、情報漏えいや不正アクセス等に対抗するセキュリティ、人材的な負荷を減らすための管理や運用面のしやすさを満たした、最適なネットワーク構成や機器を導入すること。
ネットワーク構築において考慮すべき事項を以下に示す。
① 冗長化
・ネットワークの機器は冗長化等により、高信頼性を確保すること。
② セキュリティ対策
・不正アクセスやウイルス・スパイウェア対策等のセキュリティ対策を施すこと。
③ 性能、拡張性
・データ量や利用者の増加に対応できる拡張性を有すること。
(c) データセンター要件
新システムの構築に際して、データセンターを利用する場合は、以下に示す事項を考慮し、データセンターを選定すること。
① 不正侵入防止
・センサーやカメラ等によりデータセンターへの不正侵入を防止すること。
② 入退室管理
・24 時間の入退室監視を行うこと。
・生体認証や非接触型 IC カード等により不正入出排除を行うこと。
③ ディザスタリカバリ（災害対策）
・災害の未然防止のため、地形、立地条件等のファシリティ条件を考慮すること。
・災害被害の軽減のため、地震、火災、水害、停電等への対策を行うこと。
・UPS 装置や自家発電設備の冗長化等により、事業継続性を高めること。
④ セキュリティ監査対応
・第三者によるセキュリティ監査があった場合は、データセンターで対応できること。
⑤ 設置環境
・国内に設置すること。
(d) テスト環境要件
受注者においてテスト環境を準備し、ソフトウェアのバージョンアップや追加改修等が生じた場合、テスト環境へリリースし、動作確認を実施した上で本番環境へリリースできること。
（３）想定規模要件
(a) 利用者数
新システムの利用者数は、システム管理者 5 名、公社利用職員 600 名（委嘱者含む）、各区利
用職員 30 名、会員・準会員 20 万件である。
※公社側（システム管理者、公社利用職員、各区利用職員）の公社向け機能の同時利用者 300名を想定している。
※企業側（会員・準会員）の企業向け機能の同時利用者は 100 名を想定している。
(b) 利用場所
新システムの利用場所は以下を想定している。
・公社の各拠点・事業所（国内）（VPN 環境あり）
・都内 23 区の区役所（VPN 環境あり）
・外出先（国内）（VPN 環境あり）
・タイ事務所（海外）（VPN 環境なし、インターネット環境あり）
(c) 業務処理件数
平成 27 年度における業務処理件数は、次のとおりである。
なお、設計・開発にあたっては、業務処理件数の将来的な増減を十分に考慮すること。
表 7 業務処理件数一覧
No | 業務パターン | 主な対象業務 | 業務数 | 年間処理件数 （件） | 年間処理時間 （時間） |
1 | 派遣・支援 | 専門家派遣、事業可能性評価、 パワーアップ作戦等 | 25 | 3,969 | 46,540 |
2 | 講座・展示会 | セミナー事業全般、 展示会出展支援事業等 | 30 | 5,529 | 13,602 |
3 | 助成 | 助成事業（設備リース・創業助成等含む）等 | 10 | 4,173 | 194,924 |
4 | 紹介・マッチング | デザイン導入、あっせん、IPF （一部）等 | 11 | 2,137 | 3,040 |
5 | 巡回 | 企業巡回等 | 7 | 6,830 | 39,865 |
6 | その他 | 総合相談、広報活動等 | 51 | 71,044 | 49,806 |
合計 | 134 | 93,682 | 347,777 | ||
(d) データ量
現行システムが保有している主要情報のデータ量について、平成 28 年 11 月時点の情報は、次のとおりである。なお、設計・開発にあたっては、データ量の将来的な増減を十分に考慮すること。
表 8 データ量一覧
No | 情報名 | 情報概要 | 保存容量 （MB） | 保有件数 （件） |
1 | 企業情報 | 企業基本情報、住所情報 | 233 | 266,448 |
2 | 企業商品情報 | 企業商品情報 | 5 | 3,615 |
3 | カルテ情報 | 企業の支援情報 | 825 | 978,055 |
4 | 専門家情報 | 専門家情報 | 2 | 1,163 |
5 | イベント情報 | イベント情報 | 3 | 2,369 |
合計 | 1,068 | 1,251,650 | ||
（４）性能要件
(a) オンライン処理性能
利用者がストレスを感じない 3 秒以内の応答時間とすること。なお、業務処理負荷の高い時間
帯等でも、最長 10 秒以内の応答時間とすること。ただし、一部の機能において、この制限を超えることを公社が認めた場合は、この限りではない。
また、同時アクセスが発生した場合においても、新システムの処理時間に影響を与えないこと。
(b) バッチ処理性能
バッチ処理は、オンライン処理・バックアップ処理に対して影響を与えないこと。なお、時間を要する処理が想定される場合については、公社と協議の上、決定する。
（５）信頼性要件
新システムにおいて障害等が発生しても、業務データの整合性を担保可能とし、影響を最小範囲に留め、復旧に係る時間を最短とする構成とすること。
(a) 稼動時間
新システムは、計画停止および定期保守時間を除き、原則 24 時間 365 日稼働とする。
(b) 冗長構成等
ハードウェア等については、SPOF（その箇所が停止すると、他の箇所が正常でもシステム全体が停止するような箇所の総称）を回避するシステム構成を取り、障害発生によるサービス停止を極力避けること。具体的には、サーバ機器の多重化、重要部位（電源、ファン、ディスク装置 等）の多重化等を実施すること。なお、サーバ機器については、ホットスタンバイ構成とすること。
また、新システムに障害が発生した場合、その原因を特定するために必要な証跡（アクセスログ、イベントログ 等）が出力可能であること。
(c) 停電・瞬断対策
導入するサーバ機器には、停電・瞬断対策として UPS（無停電電源装置）を設置すること。なお、UPS は、各機器の消費電力およびシャットダウンに必要とされる時間を考慮の上、シャットダウンするまでに必要な時間を十分確保できるだけの電源容量を保有したものとすること。
(d) バックアップ
新システムで保有するデータ（業務データのほか、サーバの設定情報、動作ログ等含む）について、日次にて差分バックアップ、週次にてフルバックアップを自動で実施すること。また、障害が発生した場合、データの復旧はバックアップデータのリストアで対応可能なこと。
なお、バックアップデータは、1 ヶ月分を保管すること。
（６）拡張性要件
新システムの拡張性に関する要件は、次のとおりである。
(a) データ量や処理負荷等の増大に備え、システムの拡張性を考慮しておくこと。拡張が必要になった場合は、サーバ筐体の増設ではなく、ハードウェア部位（CPU、メモリ、ディスク 等）の増設等により対応できること。
（７）上位互換性要件
新システムの上位互換性に関する要件は、次のとおりである。
(a) OS、ミドルウェアおよびパッケージ製品について、バージョンアップ情報が開発時において既に提供されている場合は、それにも対応できるようにシステムを構築すること。
(b) バージョンアップについて、技術的な問題等がある場合は、公社と協議の上、作業を実施すること。
（８）中立性要件
新システムの中立性（相互互換性）に関する要件は、次のとおりである。
(a) 特定の技術や製品に依存せず、継続的に安定した品質保証が受けられるオープンな標準に基づいた技術を採用すること。
(b) 新システムの運用保守は、受注者に依存することなく、他事業者でも変更および引継ぎが可能であること。
(c) システム更改時において、円滑なデータ移行が可能なシステム構成であること。
(d) 第三者による保守性を向上させるため、成果物等は公社で標準的に利用されているドキュメント作成ソフトを用いること。
（９）継続性要件
災害等発生時には事業継続のためのシステム復旧が必要となるため、速やかなデータ復旧ができることを考慮したハードウェア・ソフトウェア構成、保守体制とすること。
（１０）情報セキュリティ要件
(a) セキュリティ対策
新システム内で取り扱う情報の機密性および外部からの脅威等を踏まえリスク分析を実施し、網羅的なセキュリティ対策を行うこと。なお、対策の詳細については、公社の情報セキュリティの関連規程等を遵守すること。
(b) 個人情報保護
新システムでは、個人情報等を保有するため、取り扱いには十分に注意し、情報漏えい等を防止するための対策を講じること。
(c) アクセス管理
ユーザ認証（ユーザ ID、パスワード）機能を有すること。また、ユーザ認証によって許可された利用者の権限に応じて、新システムで利用できる機能を制限する仕組みとすること。
※新システム構築時に公社と調整すること。
表 9 アクセス権限と対応機能一覧
機能区分 | 機能名 | 公社 | 各区利用職員 | 企業 | 備考 | ||
システム管理者 | 利用職員 | 会員 | 準会員 | ||||
公社向け機能 | 1 公社トップページ | ○ | ○ | ||||
2 事業情報管理 | ○ | ○ | |||||
3 企業情報管理 | ○ | ○ | ○ | ||||
4 支援情報管理 | ○ | ○ | ○ | ||||
5 専門家等プロフィール管理 | ○ | ○ | |||||
6 専門家等記録管理 | ○ | ○ | |||||
7 業務日報管理 | ○ | ○ | |||||
8 ステータス管理 | ○ | ○ | |||||
9 統計情報管理 | ○ | ○ | |||||
10 イベント情報管理 | ○ | ○ | |||||
11 電子申請管理 | ○ | ○ | |||||
12 予約管理 | ○ | ○ | |||||
13 e-ラーニング管理 | ○ | ○ | |||||
14 ホームページ情報管理 | ○ | ○ | |||||
企業向け機能 | 21 ログインページ | ○ | ○ | ○ | |||
22 企業トップページ | ○ | ○ | ○ | ||||
23 e-ラーニング管理 | ○ | ○ | ○ | ||||
管理者向け機能 | 31 利用者管理 | ○ | |||||
32 支援情報管理 | ○ | ||||||
33 統計情報管理 | ○ | ||||||
34 データ管理 | ○ | ||||||
(d) 不正侵入防止・改ざん防止
新システムで使用する通信プロトコルおよび通信ポート以外での接続を禁止し、不正な接続等があった場合は、それを検知し、ログを取得する仕組みを構築すること。
また、ファイルやデータ等が改ざんされていないかチェックする仕組みを構築すること。改ざんがあった場合は、速やかにシステム管理者に通知することが可能なこと。
(e) ウィルス対策
マルウェア（ウイルス、ワーム、ボット等）による脅威に備えるため、新システムで導入する
機器にはウィルス対策ソフトを導入すること。なお、当該ソフトは、新たに発見されるマルウェアに対応するため、パターンファイル等の自動更新が可能であること。
(f) データの暗号化
新システムで保有する情報の漏えい等を防止するため、利用者が直接アクセスできないように制限し、個人情報や機密データ等は暗号化する機能を備えること。
また、通信回線に対する盗聴防止のため、通信回線を暗号化する機能を備えること。
(g) 監査証跡
システム利用者証跡（データ更新・参照時）、印刷監視（帳票印刷時）、および出力監査（ファイルのダウンロードや転送時）の監査機能を備えること。
（１１）ユーザビリティおよびアクセシビリティに関する要件
利用者にとって使いやすいシステムとするため、以下の要件を満たすこと。
(a) システムにおける必要性を検討の上、PC 操作の成熟度によらない操作性を考慮すること。
(b) 本システムとの整合性に配慮しつつ、フォントや色の見やすさ、入力ガイダンス、マウスやキー操作のわかりやすさを考慮すること。
(c) 表示する情報は簡潔にすること。例えば、関連する情報は、一画面内で参照できるような画面構成や、画面内での位置が近くなるように配置すること。
(d) 操作については Xxx xx等による入力ターゲットの移動を定め、誤入力等の防止に配慮すること。
(e) 視線の流れが、「左→右」方向、「上→下」方向となるように情報の配置を工夫すること。
(f) 利用者が誤入力等をした場合のエラーおよび警告のメッセージは、問題点と解決方法がわかるように配慮すること。
(g) 利用者に対し適切なデフォルト値を設定し、少しでも利用者の操作を軽減できる仕組みを考慮すること。
(h) データ登録、更新、削除を行う操作については、必ず確認画面を表示する等の誤操作がないよう考慮すること。
(i) 異なる画面上についても、名称等については利用者の誤解が生じないようにシステム内で統一すること。
(j) エラーおよび警告のメッセージは、利用者に誤解のないようシステム全体で統一すること。
(k) エラーメッセージは、エラー発生を知らせるだけではなく、xxxの原因・解決方法を明示するようにすること。（例えば、エラー項目を強調表示し、フォーカスを遷移させる等）
(l) 利用者への警告やメッセージは、画面内にメッセージを表示して伝えること。
(m) 利用者に表示するメッセージは、問題点が何かを明示し、利用者が何をすべきかを表示すること。
(n) 処理に時間のかかる操作は、利用者が端末の処理状況を把握できる表示とすること。（例えば、
「処理経過の表示」ダイアログや「処理中」メッセージ等）
受注者は、構築する新システムを構成する機器について、「４ システム化要件」を吟味し、現時点で想定する新システムの構成等における考え方を提案すること。
サーバ、端末機器等のハードウェア構成等について、開発対象システムに係る稼動環境を明記し、主要なコンポーネントについては、全体システム構成図の中でそれを示すこと。
ハードウェア構成で考慮すべき事項を以下に示す。
(a) クラウド方式での導入の場合は、ハードウェアに依存することはないが、「５．３ ネットワーク構成」を考慮し、重要事業等に影響を及ぼさない構成で導入すること。
(b) 「４．３ 非機能要件」（１０）の記述に従い、情報セキュリティ対策を踏まえた構成とすること。
サーバ、端末機器等の基本ソフトウェア構成、ミドルウェア環境等について、開発対象システムに係る稼動環境を明記し、主要なコンポーネントについては構成図を示すこと。
ソフトウェア構成で配慮すべき事項を以下に示す。
(a) 汎用的な複数の製品（サーバ、OS 等）で動作できるソフトウェアであること。
(b) ユーザ数、業務量が同等の行政機関や団体等で同規模以上のシステムに導入され、十分な活動実績を有すソフトウェアであること。
(c) ユーザの利便性に配慮したソフトウェア構成であること。
(d) 安定性及び安全性の確保のため、導入するソフトウェアは調達段階での最新のバージョンを使用すること。ただし、新システムの運用に影響を及ぼすと認められる場合は、実績のあるバージョンを使用すること。
新システムが利用するネットワーク環境およびそのコンポーネント構成を示すこと。
ネットワーク構成は、「４．３ 非機能要件（２）環境要件（a）ネットワーク要件」を満たす構成とすること。
受注者は、以下「６．１ テスト計画の策定」および「６．２ テストの実施」に基づき作業を行うこと。
実施する単体テスト、結合テスト、総合テスト、セキュリティテストについて、テスト方針、実施内容および実施理由を記載し、テスト工程毎にテスト計画書として提出すること。また、公社が主体となって実施する受入テストについては支援すること。
テスト計画書に記載すべき事項を以下に示す。
（１） 受注者のテスト実施体制と役割
（２） テストに係る詳細な作業およびスケジュール
（３） テスト環境（テストにおける回線および機器構成、テスト範囲）
（４） テストに関するツール類（開発するプログラムの概略仕様も含め）
（５） テストデータ
（６） 評価指標
（１）テスト工程共通要件
単体テスト、結合テストおよび総合テストの各テスト工程において共通する要件を以下に示す。
(a) 受注者はテストの管理主体としてテストの管理を実施するとともに、その結果と品質に責任を負い適切な対応を行うこと。
(b) 受注者は公社および関連する他システムに係る業者等との作業調整を行うこと。
(c) 公社に対し定期進捗報告および問題発生時の随時報告を行うこと。
(d) 各テストを行うため、一連のテストケース（入力、出力およびテスト基準）、テストシナリオ
（例外処理を含む。）、テストデータ、テスト評価項目およびテスト手順を各テスト実施前に作成の上、提出すること。
(e) 各テスト終了時に、実施内容、品質評価結果および次工程への申し送り事項等について、公社と協議の上、テスト実施報告書を作成すること。
(f) 他システムとの接続試験を実施する際には、公社職員、当該システム開発および保守業者と十分な調整を図り、受注者の負担と責任において実施すること。
(g) テストに必要なプログラム類の開発ないし用意を行い、進捗を報告すること。
（２）テストデータ要件
テストにおいて使用するテストデータに係る要件を以下に示す。
(a) 受入テスト以外のテストデータは、原則として受注者において用意すること。
(b) テストデータの管理は、受注者が責任を持って行うこと。なお、テスト工程毎のテスト計画書にテストデータの種類等を記載し、使用したテストデータは、テスト結果とともに媒体で納入すること。
（３）テスト環境要件
テスト環境に係る要件を以下に示す。
(a) 単体テストおよび結合テストに必要な機器等は、受注者の負担と責任において準備すること。
(b) 総合テストおよび受入テストに必要な機器等は、受注者が導入し、テストを実施するために必要な各種設定を受注者の責任において実施し、本番環境と同等の環境を準備すること。
(c) テスト環境における受注者のセキュリティ要件は「４．３ 非機能要件」（１０）の記述に従うこと。
（４）結合テスト要件
プログラムおよびモジュールが、本システム全体において、正しく機能することを確認するため、段階的に結合した状態でテストを行い、結果を報告すること。
（５）総合テスト要件
総合テストに係る要件を以下に示す。
(a) ソフトウェアが仕様に適合し、かつ本番環境で利用可能であることを確認できる評価指標を設定した上で、テストを実施すること。
(b) 性能および負荷のテストにおいては、本番環境と同様の環境で相応の負荷等をかけ、問題が発生しないことを確認すること。
(c) 総合テストでは、以下の項目について確認を行うこと。
① 機能性
・システム機能が、正常系、異常系ともに仕様書どおりに動作すること。
・他システムとの業務連携処理が正常に機能すること。
・情報セキュリティ要件を満たしていること。
② 信頼性
・信頼性要件を満たしていること。
・障害が発生した際の回復処理が適切であること。
③ 操作性
・要件および説明書どおりに動作し、利用者が利用しやすいこと。
④ 性能
・オンライン処理、バッチ処理の応答時間、スループットが適切であること。
・システムの限界条件（データ量、処理量）下で、正常に動作すること。
（６）セキュリティテスト要件
セキュリティテストに係る要件を以下に示す。
(a) 開発したソフトウェアについて、想定の範囲外の入力を拒否できない脆弱性を狙った攻撃等の既知の手法による攻撃（バッファーオーバーフロー、SQL インジェクション、コマンドインジェクション、セッションハイジャック、クロスサイトリクエストフォージェリ、クロスサイトスクリプティング等）が試みられた場合に、システムのセキュリティに影響を及ぼさないことを確認すること。
(b) システムの動作環境又は動作前提であるハードウェアおよびソフトウェアについて、既知の脆弱性が存在しないこと、および既知の攻撃手法に対して脆弱な設定が行われていないことを確認すること。
(c) (a)および(b)の確認は、適切なテストツールを選択して想定されるパターンを網羅的に行うこと。
(d) セキュリティテストにおいて発見された脆弱性および当該脆弱性に関して実施した対処について、テスト実施報告書に記載すること。
（７）受入テスト支援要件
公社が主体となって実施する受入テストに係る要件を以下に示す。
(a) 受入テストにおける具体的な手順および結果を記入するための受入テスト手順書（案）を作成すること。なお、システム操作に精通していない職員でも分かりやすいテストとなるように工夫すること。
(b) 受入テストは公社が主体となって行うが、公社の求めに応じて受入テストを支援するための要員を確保すること。
(c) 受入テストで必要となるテストデータの準備を支援すること。
(d) 受入テストで確認された障害について、対応方針を提示し公社の承認を得ること。
(e) 公社に承認された対応方針に従い、プログラムおよびドキュメント等を修正すること。
受注者は、移行に際して、適時適切なタイミングで、移行範囲、移行実施体制と役割、作業およびスケジュール、移行環境、移行対象、移行方法等について検討を実施すること。なお、移行作業の実施にあたっては、移行が必要なデータの選別、移行データによる動作テストを実施すること。
受注者は、移行計画書に従い、移行に必要な現行システムデータの取得を公社に依頼すること。現行システムデータは、公社（現行運用業者）より一般的なファイル形式（CSV 等）で提供を行うものとする。また、事前に現行のデータレイアウトを分析し、移行プログラムの設計・開発が必要と判断される場合は、公社の承認を得て実施すること。なお、移行プログラムにより移行を実施した場合は、移行後のデータ正当性確認まで行い、公社の承認を得ること。
移行計画書に記載すべき事項を以下に示す。
（１） 移行概要
（２） 移行対象
（３） 移行中の影響
（４） 移行テスト
（５） 移行スケジュール
（６） 移行体制
受注者は、移行対象テーブルについて、データ移行又はセットアップを行うこと。ただし、本開発にあたっては、移行対象とすべきか分析を実施した上で、公社の承認を得てデータ移行を実施すること。
表 10 移行対象テーブル
No | 移行対象データ | データの概要 |
1 | 企業基本情報 | 企業ＮＯ、企業名、事業区分 等 |
2 | 企業資格情報 | 企業ＮＯ、資格コード 等 |
3 | 事業所・工場情報 | 事業所ＮＯ、事業所区分、企業名 等 |
4 | 企業担当者情報 | 事業所ＮＯ、連絡先氏名 等 |
5 | 企業特性情報 | 特性ＮＯ、特性区分コード 等 |
6 | 企業設備能力情報 | 能力ＮＯ、能力区分コード 等 |
7 | 企業商品情報 | 製品ＮＯ、製品名 等 |
8 | 企業製品分野情報 | 製品ＮＯ、製品分野コード 等 |
9 | 企業受注先情報 | 受注先ＮＯ、企業名、所在地 等 |
10 | 企業外注先情報 | 外注先ＮＯ、企業名、所在地 等 |
11 | 企業関連会社情報 | 関連会社ＮＯ、関連会社 等 |
12 | グループ情報 | グループＮＯ、グループ企業コード 等 |
13 | デザイナー情報 | デザイナー区分コード 等 |
No | 移行対象データ | データの概要 |
14 | 取扱注意情報 | 取扱注意ＮＯ、発生日、担当課コード 等 |
15 | 会員情報 | 企業ＮＯ、会員ＩＤ、パスワード 等 |
16 | 事業カルテ | 事業区分コード、事業区分詳細コード 等 |
17 | メルマガ購読情報 | 事業所ＮＯ、メールマガジンコード 等 |
18 | 認定情報選択肢マスタ | 資格コード、資格名称 等 |
19 | デザイナー選択肢マスタ | デザイナー区分コード 等 |
20 | 製品分野選択肢マスタ | 製品分野コード、製品分野名称 等 |
21 | 利用区分選択肢マスタ | 利用区分コード、利用区分名称 等 |
22 | メルマガ選択肢マスタ | 参照元、メールマガジン名称 等 |
23 | 問い合わせ内容コードマスタ | 問い合わせコード、問い合わせ内容 等 |
24 | 受発注基本情報 | 受発注ＮＯ、受発注状態コード 等 |
25 | 発注案件情報 | 発注量、納期、納品場所 等 |
26 | 専門家情報 | 専門家ＮＯ、氏名、専門得意xx x |
27 | 専門家登録種別 | 専門家ＮＯ、登録種別コード 等 |
28 | 専門家各種分野 | 区分コード、各種分野コード 等 |
29 | 専門家登録種別マスタ | 登録種別コード、登録種別名称 等 |
30 | 専門家各種区分マスタ | 区分コード、区分名称 等 |
31 | 専門家各種分野マスタ | 各種分野コード、各種分野名称 等 |
32 | イベント情報 | イベントＩＤ、イベント名称 等 |
33 | イベント申込フォーム情報 | イベントＩＤ、ＳＥＱＮＯ 等 |
34 | イベント削除情報 | イベントＩＤ、削除日 等 |
35 | イベント申込情報 | イベントＩＤ、申込日時、参加フラグ 等 |
36 | イベント申込項目情報 | 申込日時、項目番号、申込内容 等 |
37 | イベントＮｏ発番テーブル | イベントＮＯ、発番年 等 |
38 | 地区コードテーブル | 地区コード、地区名称 等 |
39 | 丁目コードテーブル | 丁目コード、丁目名称 等 |
40 | 郵便番号コードテーブル | 全国地方公共団体コード、郵便番号 等 |
41 | アクセス権限マスタテーブル | 課コード、担当者区分コード 等 |
42 | コードテーブル | コード番号、コード、名称 等 |
43 | 事業区分詳細アクセス 権限テーブル | 事業区分詳細コード、課コード 等 |
44 | TSR 企業情報 | TSR 企業コード、法人格前後区分 等 |
45 | TSR 関連企業コード | TSR 企業コード、企業コード 等 |
46 | TSR 倒産状況 | TSR 企業コード、倒産状況フラグ 等 |
47 | メニューお知らせ情報マスタ | お知らせＮＯ、表示開始日時 等 |
48 | メニューキーワードマスタ | キーワードＮＯ、キーワード 等 |
49 | 専門家メールマガジン | 専門家ＮＯ、マガジンコード 等 |
No | 移行対象データ | データの概要 |
50 | 専門家採番 | 最終専門家ＮＯ 等 |
51 | 専門家会員情報 | 専門家ＮＯ、会員ＩＤ、パスワード 等 |
52 | イベント講師履歴 | 専門家ＮＯ、ＩＤ、生年月日 等 |
53 | 相談派遣履歴 | 専門家ＮＯ、相談ＮＯ、企業ＮＯ 等 |
54 | ビューアクセス権限マスタ | ビュー名、課コード、職員区分 等 |
55 | 帳票アクセス権限マスタ | 帳票コード、課コード、職員区分 等 |
56 | 統計区別実績（窓口扱） | 集計年月、窓口コード 等 |
57 | 統計区別実績 （公社扱／窓口／地区） | 集計年月、窓口コード、地区コード 等 |
58 | 統計区別実績 （公社扱／地区） | 集計年月、地区コード 等 |
59 | 統計区別実績 （公社扱／窓口） | 集計年月、窓口コード 等 |
60 | 企業商品斡旋成約情報 | 製品ＮＯ、斡旋企業ＮＯ等 |
61 | 苦情基本情報 | 苦情ＮＯ、事業区分コード 等 |
62 | 苦情企業情報 | 苦情企業種別フラグ、企業ＮＯ 等 |
63 | 苦情経過情報 | 苦情経過ＮＯ、経過状況 等 |
64 | 発注能力情報 | 受発注ＮＯ、発注能力ＮＯ 等 |
65 | 発注特性情報 | 発注特性ＮＯ、特性コード 等 |
66 | 斡旋情報 | 斡旋ＮＯ、斡旋企業ＮＯ 等 |
67 | 受発注削除情報 | 受発注ＮＯ 等 |
68 | 発注案件削除情報 | 受発注ＮＯ 等 |
69 | 助成基本情報 | 助成ＮＯ、企業ＮＯ、推薦理由 等 |
70 | 助成事業費確定詳細 | 事業費ＮＯ、総事業費、助成金確定額 等 |
71 | 助成参加企業 | 参加ＮＯ、参加企業ＮＯ 等 |
72 | 助成産業財産権 | 産業財産権ＮＯ、出願番号 等 |
73 | 助成財産処分 | 財産処分ＮＯ、財産処分年月日 等 |
74 | 助成出願国 | 助成出願国ＮＯ、国際特許コード 等 |
75 | 相談基本情報 | 相談ＮＯ、相談窓口、相談日 等 |
76 | 相談項目情報 | 相談ＮＯシーケンス、相談内容コード 等 |
77 | 景況情報 | 相談ＮＯ、設問コード、回答コード 等 |
78 | 相談専門家情報 | 相談ＮＯ、専門家登録種別コード 等 |
79 | 対応方針情報 | 対応方針ＮＯシーケンス、対応方針コード 等 |
80 | 助成完了情報 | 助成金の交付状況 等 |
81 | 企業基本情報（ネット登録チェック履 歴） | 変更履歴情報 |
82 | 企業資格情報（ネット登録チェック履 | 変更履歴情報 |
No | 移行対象データ | データの概要 |
歴） | ||
83 | 事業所・工場情報（ネット登録チェッ ク履歴） | 変更履歴情報 |
84 | 企業担当者情報（ネット登録チェック 履歴） | 変更履歴情報 |
85 | 企業特性情報（ネット登録チェック履 歴） | 変更履歴情報 |
86 | 企業設備能力情報（ネット登録チェッ ク履歴） | 変更履歴情報 |
87 | 企業商品情報（ネット登録チェック履 歴） | 変更履歴情報 |
88 | 企業製品分野情報（ネット登録チェッ ク履歴） | 変更履歴情報 |
89 | 企業受注先情報（ネット登録チェック 履歴） | 変更履歴情報 |
90 | 企業外注先情報（ネット登録チェック 履歴） | 変更履歴情報 |
91 | 企業関連会社情報（ネット登録チェッ ク履歴） | 変更履歴情報 |
92 | デザイナー情報（ネット登録チェック 履歴） | 変更履歴情報 |
93 | 会員情報（ネット登録チェック履歴） | 変更履歴情報 |
94 | メルマガ購読情報（ネット登録チェッ ク履歴） | 変更履歴情報 |
95 | 受発注基本情報（ネット登録チェック 履歴） | 変更履歴情報 |
96 | 発注案件情報（ネット登録チェック履 歴） | 変更履歴情報 |
97 | 専門家情報変更履歴 | 変更履歴情報 |
98 | 専門家情報（ネット履歴） | 変更履歴情報 |
99 | 専門家登録種別（ネット履歴） | 変更履歴情報 |
100 | 専門家各種分野（ネット履歴） | 変更履歴情報 |
101 | 専門家メールマガジン（ネット履歴） | 変更履歴情報 |
102 | 企業情報変更履歴 | 変更履歴情報 |
103 | 企業情報変更履歴詳細 | 変更履歴情報 |
受注者は、研修計画を策定し以下の作業を行うこと。
受注者は、研修を円滑に実施するために、以下に示す事項を研修計画に定義し、公社の承認を得ること。
（１） 基本方針
（２） 対象者および実施スケジュール
（３） 研修内容（カリキュラム）
（４） 研修体制、講師
（５） 研修環境
受注者は、利用者が新システムを十分に活用して効率的に業務を遂行できるよう、下記に示す研修を実施し、周知教育を行うこと。
各対象者に向けた、新システム導入時における研修を実施すること。日程および会場は公社と協議の上決定すること。
表 11 研修対象者
No | 対象者 | 対象人数 | 研修要件 |
1 | 役員・部長 | 5 人 | ・役員・部長向けの説明会を実施すること。 |
2 | システム管理者 | 5 人 | ・企画課システム管理者向けに、システム管理者として必要な機能の研修を実施すること。 |
3 | 職員（システム利用者） | 300 人 | ・公社利用職員向け（委嘱者は除く）に、必要な機能の研修を実施すること。 |
研修内容は、実際の業務に活用できる実践的なものとし、受講者の知識の定着度と理解度の向上を図るものとすること。また、現行システムとの違いや変更点等を明確にすること。
研修を効率的に進めるため、操作補助や演習等を考慮した研修体制とすること。講師は、受講者の進捗状況や操作レベルに合わせて臨機応変に対応すること。
（１）研修実施環境
研修に必要な機器（クライアント PC、周辺機器等）は公社と協議の上、準備すること。
（２）研修資料、システム操作マニュアル
研修に必要な資料（説明資料、システム操作マニュアル等）は受注者が作成すること。マニュアルの作成にあたっては、利用者の観点において読みやすく、かつ使いやすいマニュアルとなるように公社と十分協議すること。
（３）研修の教材化
研修の録画データを利用者が自由に閲覧できるようにするとともに、新規採用者や異動者等を対象とした随時教育用の教材としても利用できるようにすること。
受注者は、前提条件に基づき以下の作業を行うこと。
新システムの円滑な運用が行えるように運用支援および保守を行うこととし、以下の事項を前提条件とする。
（１）新システムに関する各種問合せや障害対応の受付を行う窓口を設けること。
（２）ハードウェア保守においては、オンサイト対応を踏まえたサポート体制とすること。
運用・保守業務の開始までに、運用・保守計画を策定し、公社の承認を得ること。
以下に示す運用支援を行うこと。
表 12 運用要件
No | 運用支援項目 | 作業概要 |
1 | システム起動・停止 | ・定期的にシステムリブートを実施すること。 |
2 | システム監視 | ・新システムの死活監視をすること。 ・外部からの攻撃や不正アクセス等の監視をすること。 |
3 | バックアップ | ・データのバックアップの管理をすること。 |
4 | ヘルプデスク（窓口） | ・新システムに関する問合せ等の受付と回答を随時行うこと。対応時間は 8:30～17:15 とする。 ・問合せについてのレポートを週１回作成し公社に提出すること。 ・問合せは、システム管理者からメールまたは電話で行う。 |
5 | 企業データの更新 | ・日々企業データを更新すること。 |
以下に示す保守を行うこと。
表 13 保守要件
No | 保守項目 | 作業概要 |
1 | ハードウェア保守 | ・製品の保守期間は、本稼働後 5 年間継続可能であること。 ・サポート体制として、各種問合せ、障害全般に対するxx的な窓口を設けること。 ・保守受付時間は、24 時間 365 日とする。 |
2 | ソフトウェア保守 | ・ソフトウェアのバージョンアップ、パッチ対応は公社との調整の上で行うこと。 ・保守対応時間は、平日の 8:30～17:15 とする。 |
No | 保守項目 | 作業概要 |
3 | 障害対応 | ・新システムに係る障害時の切り分け、対応支援を行うこと。 ・緊急時連絡体制のフロー図を作成提出し、障害対応の体制を明確にすること。 |
以下に示すサービスレベルを目標とすること。
目標値に達しない場合、達しない原因を調査分析し、公社に報告するとともに、翌月から改善策を講じること。
表 14 サービスレベル要件
No | サービスレベル項目 | 内容 | 目標値 |
1 | 稼働率 | ・基準となる 1 日の実稼働時間および予定稼働時間は 6 時 から 24 時とするが、サービス提供時間は、計画停止を除き、 24 時間 365 日とする。 ・稼働率は、［月間実稼働時間／計画停止を除いた月間予 定稼働時間×100］とする。 | 99.9％ |
2 | 計画停止予定通知 | ・定期的な保守停止に関する事前連絡確認 （事前通知のタイミングおよび方法の記述を含む） | 7 日前にメールおよびホームページ で事前通知 |
3 | 復旧時間 | ・障害発生から修理完了までの時間 | 6 時間以内 |
本業務の実施にあたっては、以下の書類を提出すること。
表 15 提出書類および提出時期
No | 提出時期 | 提出書類 | 提出日 | 部数 |
1 | 業務着手時 | 業務着手届 業務責任者届 | 契約締結後 7 日以内 | 各１部 |
以下の成果物を納入期限までに提出すること。
表 16 成果物一覧
No | 成果物 | 内容 | 納品数 | 納入形態 | 納入期限 |
No | 成果物 | 内容 | 納品数 | 納入形態 | 納入期限 |
1 | 業務実施計画書 | 本業務の目的・目標、業務の範囲、工程・課題・品質等プロジェクト管理方法、体制、会議体、スケジュー ル等をまとめた計画書 | 2 部 （正、副） | 電子・紙 | 受託後速やかに提出 |
2 | 要件定義書 | 公社との協議により確定した業務要件、機能要件、非機能要件をまと めた定義書 | 2 部 （正、副） | 電子・紙 | 要件定義工程終了後 |
3 | 基本設計書 | 要件定義書に基づき、要件を実現するための方針、システム全体構成、システム方式、機能、運用、データ 処理構造等を定義した設計書 | 2 部 （正、副） | 電子・紙 | 基本設計工程終了後 |
4 | 詳細設計書 | コード設計、ファイル設計、画面詳細設計、帳票詳細設計、プログラム機能概要設計、処理フロー設計（プログラム分割）、エラー対応（チェック方式）設計、データベース論理構造設計、データベース物理構造設計、インターフェース設計（プログラム間）、外部インターフェース設計、テスト概要設計、結合テスト仕 様設計、総合テスト仕様設計 等 | 2 部 （正、副） | 電子・紙 | 詳細設計工程終了後 |
5 | プログラム設計書 | コーディング基準、ソースプログラム、単体テスト仕様設計 | 2 部 （正、副） | 電子・紙 | 開発・単体テスト工程 終了後 |
6 | テスト計画書 | 単体テスト計画書、結合テスト計画書、総合テスト計画書、受入テスト 計画書 | 2 部 （正、副） | 電子・紙 | 各テスト工程開始前 |
7 | テスト仕様書 | 単体テスト仕様書、結合テスト仕様書、総合テスト仕様書、受入テスト 仕様書 | 2 部 （正、副） | 電子・紙 | 各テスト工程開始前 |
8 | テスト結果報告書 | 単体テスト結果報告書、結合テスト 結果報告書、総合テスト結果報告書、受入テスト結果報告書 | 2 部 （正、副） | 電子・紙 | 各テスト工程終了後 |
9 | 移行計画書 | － | 2 部 （正、副） | 電子・紙 | 移行工程x x前 |
10 | 移行手順書 | － | 2 部 （正、副） | 電子・紙 | 移行工程開始前 |
11 | 移行結果報告書 | － | 2 部 （正、副） | 電子・紙 | 移行工程終了後 |
12 | 運用マニュアル | － | 2 部 （正、副） | 電子・紙 | 受入テスト工程開始前 |
13 | 操作マニュアル | － | 2 部 （正、副） | 電子・紙 | 受入テスト工程開始前 |
14 | 障害対応マニュアル | － | 2 部 （正、副） | 電子・紙 | 受入テスト工程開始前 |
15 | 研修実施計画書 | － | 2 部 （正、副） | 電子・紙 | 研修（操作 説明会）実施前 |
16 | 研修資料（管理者用、利用者用） | － | 別途指示する | 電子・紙 | 研修（操作説明会）実 施前 |
17 | 研修実施結果報告書 | － | 2 部 （正、副） | 電子・紙 | 研修（操作 説明会）実施後 |
18 | プログラム （※パッケージを利用する場合は、公社向けに作成したもの） | － | 一式 | 電子 | 開発・単体テスト工程終了後 （修正した場合は再納 品） |
19 | プロジェクト管理資料（議事録 等） | － | 2 部 （正、副） | 電子・紙 | 随時、本業務終了後 |
∙ 紙での提出は、バージョンアップ時等の差し替えが容易なようにバインダー方式とすること。
∙ 電子媒体での提出は、Microsoft Office（開発時点の主流となるバージョン）で扱える形式にて、CD-ROM 等に格納すること。ただし、公社担当者が別に定める形式による提出を求めた場合はこの限りではない。なお、事前にウイルスチェックを行い、チェックの際に用いたソフトウェアおよび日時を記載したラベルを貼ること。
∙ 納入した成果物に修正等がある場合、紙については更新履歴と修正ページ、電子媒体については、修正後の全編を速やかに提出すること。
∙ 次期調達時において、第三者が当該成果物を閲覧し、内容を理解できるドキュメントを納入すること。
∙ 納入成果物の検査の結果、不適合の場合は適切な処置を行った上で再納入すること。
秋葉原本社
下記資料について、受注者に貸与することが可能である。なお、貸与した資料については、管理簿等
により適切に管理し、業務委託終了後に公社へ返却すること。
表 17 貸与品一覧
項番 | 貸与物件名 | 貸与 形態 | 数量 | 備考 |
1 | 現行システム設計書 （貸与する資料名を記載する） | 紙 | 1 部 | 使用、保管および返却の条件等を 記載する |
2 | 現行ソースプログラム | 電子 | 1 式 | 〃 |
3 | 公社の情報セキュリティの関連規程 | 紙 | 1 部 | 〃 |
4 | 中小企業支援システム【運用イメー ジ】 | 電子 | 1 式 | 〃 |
5 | 現状業務の調査分析結果（現状業務フ ロー） | 電子 | 1 式 | 〃 |
公益財団法人xxx中小企業振興公社は、経営の一層の透明性の向上を図っていくため、「経営情報の公表に関する要綱」に基づき、特定契約（官公庁との契約や競争入札に適さない契約等）のすべて及び契約金額が 250 万円以上の契約案件を以下のとおり公表いたします。
契約方法（競争・独占・緊急・少額または特定の区分別）、契約種別（工事・委託・物品等の区分別）、契約相手方の名称、契約金額
決算の公表に合わせて年１回取りまとめ、当公社ホームページ及び閲覧により公表いたします。
なお、公表の趣旨にご賛同いただけない場合は契約締結後 14 日以内に、文書にて同意しない旨申し出ることができます。
本仕様書の解釈について疑義が生じた場合は、その都度、公社の担当者と協議の上、定めること。
（１）受注者は、いかなる場合においても、本契約の履行中に知り得た業務に関する事項および付随する事項を第三者に漏らしてはならない。
（２）前記規定は、契約終了後も存続するものとすること。
保守業務およびその他の作業のため公社の施設に立ち入る場合は、事前に公社の承認を得ること。
公益財団法人xxx中小企業振興公社 企画管理部 企画課 xx・xx TEL：00-0000-0000