【意見招請】教務情報システム設計・開発・導入 一式

【意見招請】教務情報システム設計・開発・導入 一式 意見招請に関する公示次のとおり調達物品の仕様書案の作成が完了したので、仕様書案に対する意見を招請します。 令和8年5月18日放送大学学園事務局長 福本 浩一 ◎調達機関番号 235 ◎所在地番号 12○第１号１ 調達内容(1) 品目分類番号 71、27(2) 購入等件名及び数量教務情報システム設計・開発・導入 一式２ 意見の提出方法(1) 意見の提出期限 令和8年6月8日17時00分(2) 提出先 〒261－8586 千葉県千葉市美浜区若葉２－11 放送大学学園財務部経理課用度第一係 山本 菜乃子 電話043-298-4228３ 仕様書案の交付(1) 交付期間 令和8年5月18日から令和8年6月8日まで。 (2) 交付場所 上記２(2)に同じ。 ４ 仕様書案の説明会本件について、仕様書案の説明会は実施しない。 ５ Summary(1) Classification of the services to be procured: 71, 27(2) Nature and quantity of the services to bemanufactured: Design, Development andImplementation, of the Academic InformationSystem 1 Set(3) Time limit for the submission of comme-nts : 17:00 8 June, 2026(4) Contact point for the notice : YAMAMOTONanoko, Procurement Section 1, The OpenUniversity of Japan Foundation, 2-11Wakaba Mihama-ku Chiba-shi Chiba-ken261－8586 Japan, TEL 043－298－42281 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 教務情報システム要件定義書2 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 放送大学学園第2.0.0版3 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 目次1 背景と目的 71.1 背景 71.2 目的 81.3 次期システムに期待すること 91.4 将来構想について 132 対象範囲(スコープ) 152.1 業務の範囲 152.2 システムの範囲 162.3 前提条件・制約条件 172.4 対象外の範囲(除外スコープ) 203 現状の業務・システムと問題・課題 213.1 業務の概要 223.2 システムの概要 233.3 問題・課題 244 業務要件 254.1 業務の流れ 264.2 業務要件 275 システム機能要件 285.1 共通の要件 284 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 5.2 業務別の機能要件 296 非機能要件 306.1 性能及び拡張性要件 316.1.1 応答時間・処理時間 326.1.2 同時アクセス数・処理量 326.1.3 データ量増加予想と拡張性 336.1.4 信頼性：可用性要件 336.1.5 目標稼働率 346.1.6 障害発生時の復旧目標時間 346.1.7 バックアップ・リカバリ要件 346.1.8 移行要件 356.1.9 移行対象データ 356.1.10 移行手順 366.1.11 移行期間及び検証方針 366.1.12 業務マニュアルの整備 366.2 運用・保守要件 376.2.1 監視対象と監視方法 376.2.2 障害発生時の対応フロー 376.2.3 保守性・変更容易性 396.3 セキュリティ要件 406.3.1 認証(アクセス制御) 426.3.2 ログ監視・監査証跡 436.3.3 機密データ保護(暗号化) 446.3.4 個人情報の保持及び自動削除(GDPR対応) 455 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 6.3.5 セキュリティリスク分析・評価 466.3.6 セキュリティ診断・脆弱性管理 466.3.7 技術的セキュリティ対策 476.3.8 セキュリティ運用・インシデント対応 486.4 設計に関する要件 486.4.1 基本的な要件 486.4.2 基本設計及び詳細設計の実施(アプリケーションプログラム) 506.4.3 基本設計及び詳細設計の実施(運用・保守) 516.4.4 基本設計及び詳細設計の実施(システム方式) 536.4.5 移行計画 566.5 開発・テストに関する要件 566.6 受入テストに関する要件 596.7 引継ぎに関する要件 606.8 教育に関する要件 627 データ要件 667.1 データ定義 677.1.1 現行コード体系 677.1.2 新コード体系 677.1.3 新データ定義 687.2 データ連携 717.2.1 現行データ連携要件 717.2.2 新データ連携要件 718 体制と役割 736 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 8.1 体制の全体像 738.2 提案者側の移行における体制及び役割 748.3 プロジェクト体制(プロジェクト管理) 748.4 体制分離の原則 748.5 プロジェクトマネージャの役割 758.6 プロジェクトリーダー(業務責任者)の役割 758.7 設計・構築担当技術者の役割 768.8 会議体の開催及び報告 769 スケジュール 7810 補足資料 7910.1 添付資料一覧 7910.2 業務概念及び共通定義書 807 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 1 背景と目的1.1 背景放送大学学園(以下「本学園」という。)においては、学生の年齢層や学修目的の多様化、学修形態のオンライン化・高度化、並びに教育・事務運営全体におけるデジタルトランスフォーメーション(DX)の進展を背景として、教務情報を取り巻く業務環境が大きく変化している。 特に、履修登録、成績管理、学籍管理等の基幹的な教務業務については、正確性・迅速性・透明性を確保しつつ、学生・教職員双方の利便性を一層向上させることが求められている。 一方、現行の教務情報システム(以下「現行システム」という。)は、制度改正や業務要件の変化への対応、LMS等の周辺システムとの連携、情報セキュリティ及び個人情報保護への対応、将来的な拡張性・保守性の確保といった観点において、対応に限界が生じつつある。 加えて、改修や運用・保守に係るコストが高止まりしていることから、現行システムに本来取り込むべき機能やデータについても十分な改修や機能拡張を行うことが困難な状況が続いてきた。 その結果、やむを得ず一部の業務機能やデータを周辺システムや個別システムに分散して管理・保管する運用が定着し、業務や組織単位ごとに情報や機能が分断される、いわゆる「サイロ化」が進行している。 このような状況は、業務効率の低下にとどまらず、学内全体としてのデータ活用や業務連携、さらには学生一人ひとりに応じた学修支援の高度化を阻害する要因となっている。 また、今後においては、教務データは日常的な業務処理を支える情報にとどまらず、教育の質保証、IR(Institutional Research)、教学マネジメントの高度化等に8 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. おいても重要な基盤情報としての役割を担うことが期待されている。 このため、教務情報システムには、安定的な業務運用を支える基幹システムとしての機能に加え、将来的な制度変更や新たな教育サービスへの柔軟な対応、データ活用を見据えた拡張性を備えることが求められる。 以上の背景を踏まえ、本学園の教育・事務運営を中長期的に支える基盤として、現行システムの在り方を抜本的に見直し、将来を見据えた教務情報システムの再構築を行う必要がある。 1.2 目的本調達の目的は、次期システムが本学園の教務業務全体を安定的かつ効率的に支えるとともに、授業形態の多様化・学修形態の変化等、今後の教育・学修環境の変化に対して大規模な再構築を要することなく柔軟に対応可能な教務情報システムを構築することである。 具体的には、次期システムが学籍・履修・成績等の教務情報を一元的に管理し、本学園の教職員が情報を迅速に参照・活用しながら業務を遂行できる状態を実現することで業務負担軽減及び学生サービスの向上を図るとともに、関連システムとの連携を前提とした情報基盤を整備することを目的とする。 なお、本教務情報システムにおける将来構想について特に以下に示す。 ・ 卒業率の向上や学修継続の支援といった観点から、本学園の教職員が学修状況を次期システム上で横断的に把握し、適切な支援につなげるための基盤整備を行う。 ・ 次期システムは、AI技術を活用し、パーソナルな学修サポート機能を備えるもの9 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. とする✧ 本学園では障がいのある学生に対して修学支援をおこなっており、学生のそれぞれの特性に合わせた合理的配慮を行っていることから、次期システムにおいても、最新のICT技術の導入検討を前提とし、それぞれの障がいに配慮する仕組みを備えることとする。 ・ 次期システムでは、基幹システムを必要最小限のコア機能に集約しつつ、周辺システムや外部サービスと疎結合な構成で連携を前提とした構成とすることで、これまでコスト面等の制約により分散管理されてきた機能やデータを適切に統合し、情報・機能のサイロ化を解消するものとする。 最後に、情報セキュリティ及び個人情報保護に十分配慮しつつ、制度変更や業務見直し、将来的な機能拡張にも対応可能な構成とすることで、長期にわたり持続的に利用可能なシステムの実現を目指す。 あわせて、本学園における教学マネジメントやデータ利活用の高度化に資する基盤として、教務データの信頼性及び利活用性を高めることも本調達の重要な目的とする。 1.3 次期システムに期待すること本学園が導入を検討する次期システムは、現行業務の単なる継続やシステム更改にとどまらず、教育・学修形態の多様化や社会環境の変化に柔軟に適応できる基盤であることを求める。 具体的には、幅広い年齢層・多様な職業・学修目的を持つ全国の学生が、スマートフォンをはじめとする多様なデバイスから、履修登録・成績確認・各種手続きを場所・時間を問わず完結できる環境「あなたの放送大学が手のひら(スマ10 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ホ)に」及び学位取得・教養学修・学び直し等、多様な目的に応じてシステムを支障なく利用できる状態を実現するとともに、本学園が中長期にわたり教育機能を維持・発展させるための情報基盤として機能するものとする。 以下に、次期システムに対して本学園が期待する主な考え方及び方向性を示す。 (1) 次期システムの基本的な位置づけ・目的次期システムは、入学・卒業時期の弾力化、カリキュラム改正、授業形態の多様化、学生属性の多様化といった、本学園を取り巻く環境変化や業務の変容に対して、システム全体の大規模な再構築を要することなく対応可能な基盤構成とする。 なお、具体的な制度変更・業務見直しの詳細及びシステム上の可変範囲については、開発着手後の要件定義において本学園と受注者が協議の上確定するものとする。 また、提案にあたっては、必ずしも特定の機能分類や構成に依る必要はなく、本学園の方針を踏まえた最適な全体構成について、自由な発想による提案を求める。 (2) 全体アーキテクチャの方向性次期システムにおいては、基幹システムを業務処理の根幹となるコア機能に集約し、周辺システムや外部サービスとは疎結合で連携ができる構成とすることで周辺システムの追加・変更・入替が基幹システムの改修を要することなく実施可能な構造を実現するものとする。 また、データ抽出や分析については、基幹システム内に内包するのではなく、統合DB等を介して外部アプリケーションや可視化ツールと連携する構成とし、将来的なAI活用やIR等に対して基幹システムを改修することなく対応可能な拡張性を担保するものとする。 加えて、スマートフォンの普及をはじめとするICT技術の急速な進展を踏まえ、多様なデバイスや利用環境に対応できるアーキテク11 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. チャとすること。 なお、具体的な対応範囲及び設計方針については、開発着手後の要件定義において本学園と受注者が協議の上確定するものとする。 (3) 運用・コストを見据えた持続可能性次期システムは、初期導入コストのみならず、運用・保守・改修を含めた中長期的なランニングコストが、本学園の全システム管理費用の合理的な範囲内に収まる構成とする。 具体的なコスト上限の目標値については、提案者が試算根拠を明示した上で本学園と協議の上確定するものとする。 次期システムに採用する技術・製品は、国際標準規格に基づくものとし、特定データベースやクラウド製品等ベンダーの特定技術に依存することなく、運用・保守コストの増大を防ぐ構成とするとともに、学内での設定変更や軽微な業務変更については、本学園の職員でも対応できる仕組みを有するものとする。 (4) 制度変更・業務変化への柔軟な対応次期システムにおいては、キャップ制の導入、入学時期・卒業時期の弾力化、集団入学や連携校への対応、海外在住学生への対応等、多様な制度・運用形態に対して柔軟に対応可能であることを求める。 また、これらの制度変更や業務ルールの見直しについては、可能な限り本学園側の設定変更により対応できることを重視し、迅速かつ低コストでの業務対応を可能とする仕組みを期待する。 (5) 教育・学修プロセスを支える機能の充実次期システムは、教育・学修活動を支える基盤として、オンライン授業や対面・ハイブリッド型授業等への柔軟な対応を可能とすることを期待する。 また、マイクロクレデンシャルへの対応、学習センター等の拠点間における情報共有の促進、出願手続12 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. きや教材配布等の電子化・ペーパーレス化を含む各種業務の電子化を推進できることを求める。 なお、改修費を抑制するため、既存機能での工夫した対応方法の提案など、業務プロセスの抜本的な見直し (BPR)の提案を積極的に提案するなど、最善の方法の提案を期待する。 (6) データ活用・可視化による付加価値の創出次期システムにおいては、業務効率化にとどまらず、教育の質向上や学修支援の高度化に資するデータ活用基盤としての役割を重視する。 そのため、必要なデータを柔軟かつ迅速に抽出できる仕組みを備えるとともに、学修履歴や成績等を可視化する「学生カルテ」機能の充実など、学修状況の把握や支援につながる活用を可能とすることを期待する。 (7) 高品質かつ信頼性の高いシステムの実現次期システムは、学内業務及び教育活動の根幹を支えるものであることから、高い信頼性、可用性、セキュリティを備えた高品質なシステムであることを前提とする。 障害発生時の影響を最小限に抑える設計や、将来的な拡張・環境変化を見据えたアーキテクチャを含め、総合的な品質確保に関する提案を求める。 (8) 補足(提案に際して)本書は、具体的な機能要件を限定するものではなく、本学園が次期システムに対して期待する基本的な考え方及び方向性を示すものである。 画面項目や検索条件の項目は、現時点で学園が求める項目であり、提案時に拘束されるものではない。 提案者においては、本書の趣旨を踏まえた上で、最適なシステム構成・機能・実現方式について積極的な提案を行うこと。 13 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 1.4 将来構想について本書は、背景にあるとおり、長期にわたり持続的に利用可能なシステムの実現を目指し、将来を見据えた教務情報システムを含む次期システムを再構築することにある。 次期システムは、以下に示す将来構想の実現を阻害しない設計とするものとし、提案者は各項目の実現可能性及び対応方針を提案書に明示すること。 なお、将来構想の具体的な実現時期・範囲は本学園が別途決定するものであり、次期システムはその変化に対応できる拡張性を備えることを求める。 (1) 幅広い年齢層・多様な職業・学修目的を持つ学生に応じた学修サービスを展開する・ 多様な授業形態(ラジオ授業をPodcastのように受けられる授業やオンデマンド併用型・アジャイル型などのメディアを利用した授業)に対応できること(2) 居住地や在学・卒業の別を問わず、大学の学修・支援サービスを継続的に利用できる環境を構築する・ 在学中から卒業後までを見据えた一貫したサービス設計を行うこと(3) 在学者・卒業生を通じて利用可能な「生涯ID」を整備する・ 卒業後も本人確認を前提に一部大学サービスの利用を可能とし、再入学や継続学修につなげる・ 利用可能なサービス範囲や情報管理ルールを明確に定めること(4) 学修成果を段階的・柔軟に評価できる仕組みとして、マイクロクレデンシャル制度に対応する・ マイクロクレデンシャルの成果提示手段として、オープンバッジ(デジタルバッ14 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ジ)を活用すること・ 学位取得に限らない学修成果の認定・蓄積を可能とすること・ 正規授業、リスキリング等を横断的に位置づけること・ 学修成果や到達度を、本人が選択して外部に提示できる仕組みとすること・ 成果の信頼性を担保するため、根拠(Evidence)と検証可能性を重視すること(5) 授業コンテンツを再利用可能な形に再構成し、柔軟な学修体験を提供する・ 倍速再生や分割視聴を前提に、要点整理や学修確認と組み合わせること(6) 多様な年齢層・目的に応じた学修サービスを段階的に展開する・ 学位取得、リスキリング、教養学修など目的別にサービスを整理すること・ デジタルリテラシーや学修スタイルの違いに配慮した設計とすること(7) AI機能を活用し、学生・教員双方の学修・授業を補助する・ 利用範囲、責任分界、個人情報の取扱いを明確にした上で活用すること・ 学生の学修計画に役立つような次期以降の履修しやすいサジェスチョン機能を持つこと(8) 学生と教員のコミュニケーションを円滑にするため、原則非同期型を中心とした連絡手段を整備する・ 必要に応じてリアルタイムでの相談・支援も可能とするが、運用負荷を考慮した設計とすること・ 問い合わせ対応や学修支援との役割分担を明確にすること(9) 外部認証サービス等との連携を見据えたシステム拡張性の確保・ 将来的なオンライン本人確認等の外部認証サービスの活用を見据え、外部サービ15 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. スとの連携が可能なシステム構成とすること2 対象範囲(スコープ)本調達における調達範囲は、別紙添付「調達範囲(業務とシステムの関係)」、「教務情報システム調達範囲」を参照すること。 提案者においては、必ずしも自社製品のみで本学園が要求するすべての範囲を網羅することを前提とせず、自社製品及び他社製品、外部サービス等を含め、本学園が要求する調達範囲全体をどのように実現するかについて、具体的かつ実現性のある提案を行うこと。 参照添付資料：調達範囲(業務とシステムの関係)、教務情報システム調達範囲2.1 業務の範囲本調達において対象とする業務の範囲については、別紙添付「調達範囲(業務とシステムの関係)」及び「教務情報システム調達範囲」、「要件一覧(業務・システム業務別機能)」、「要件一覧(システム共通機能)」に示すとおりとする。 提案者は、当該別紙に記載された業務内容を十分に理解したうえで、次期システムにおいてこれらの業務をどのように支援・実現するかについて提案すること。 なお、別紙に記載のない業務であっても、関連性が高く、より効果的な業務運用を実現するために有用と考えられるものについては、必要に応じて提案に含めること。 16 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 参照添付資料：調達範囲(業務とシステムの関係)、教務情報システム調達範囲、要件一覧(業務・システム業務別機能)、要件一覧(システム共通機能)2.2 システムの範囲本調達において対象とするシステムの範囲については、別紙添付「調達範囲(業務とシステムの関係)」及び「教務情報システム調達範囲」、「要件一覧(業務・システム業務別機能)」、「要件一覧(システム共通機能)」に示すとおりとする。 提案者は、当該別紙に示す対象範囲を前提としつつ、現状の課題及び将来的に想定される制度変更・業務変化を見据えたうえで、次期システムとして適切と考えられるシステム全体構成、機能配置、システム間連携の考え方、データ構造(データベース構造を含む)等について、総合的な提案をすること。 なお、次期システムの稼働期間中においては、以下のような変化や要請が継続的に発生することを前提とする。 ・ オンライン授業、面接授業、ハイブリッド型授業の併存及び拡張(授業種類の柔軟な追加が可能)・ キャッシュレス決済を含む決済手段の多様化・ カリキュラム改正や教育課程の継続的な見直し・ 入学・卒業時期の弾力化や随時処理への対応・ 学生属性・学修形態・資格体系(マイクロクレデンシャル等)の多様化・ 各種申請・手続きの電子化及びペーパーレス化の進展・ 2029 年度本格受け入れを検討している海外学生受け入れに伴う次期システムの17 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 柔軟な各種設定変更や機能追加 ※ただし、学生証発行(国内・海外)は本調達対象外・ 科目登録機能における柔軟な各種設定変更や機能追加これらの変化に対し、システム全体の大規模な再構築を伴うことなく、設定変更や機能追加、外部サービスとの連携等により柔軟に対応可能な構成であることを重視する。 特に、特定の機能や業務を単一システムに過度に集中させるのではなく、疎結合な構成や標準的なインターフェースを前提とした連携により、将来的なシステム追加・入替・拡張を阻害しない設計とすることを期待する。 なお、別紙に示す「調達範囲(業務とシステムの関係)」及び「教務情報システム調達範囲」は、次期システムとして求める最低限の対象範囲を示すものであり、本学園が目指す将来像の実現や業務・教育の高度化に資すると考えられる。 追加的な構成、機能、連携方式等については、提案者の判断により積極的に提案すること。 参照添付資料：調達範囲(業務とシステムの関係)、教務情報システム調達範囲、要件一覧(業務・システム業務別機能)、要件一覧(システム共通機能)2.3 前提条件・制約条件(1) 導入形態・ソフトウェア方針次期システムとして導入する教務情報ソフトウェアについては、一定規模以上の大学における導入実績を有する、製品化されたパッケージソフトウェアまたはそれに準18 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ずる成熟したソリューションの活用を基本方針とする。 なお、必ずしも単一のパッケージ製品による構成に限定するものではなく、複数のパッケージ製品、SaaS、外部サービス等を組み合わせた構成でもかまわない。 製品化されたパッケージソフトウェアに依らない提案(スクラッチ開発を含む)を行う場合には、本調達の趣旨を踏まえ、運用性、保守性、拡張性、将来的な人材確保等を含むTCO(総保有コスト)の観点から、パッケージ製品を活用する場合と比較して優位性があることを明確に示すこと。 また、導入対象となるパッケージ製品、SaaS、外部サービス等はAPI連携を基本とし、シームレスなサービス利活用を可能とすることが望ましい。 (2) 稼働環境・技術基盤に関する要件次期システムの稼働環境については、継続的な運用・保守及び将来的な拡張性を考慮し、特定ベンダーや特定技術への過度な依存を避けた、汎用性・継続性の高い技術基盤で構成されることを求める。 クラウド環境(パブリッククラウドを含む)の利用可否については限定しないが、いずれの場合においても、将来にわたり技術者や代替製品が市場において比較的容易に確保可能であることを前提とする。 (3) 運用性・トレーサビリティに関する要件学生等から次期システムの操作や処理内容に関する問い合わせが発生した際に、権限を付与された職員が、職員向け機能を通じて操作履歴や処理ログを検索・閲覧できる仕組みを有すること。 また、必要に応じて、問い合わせ対象となった学生等と同等の操作状況を確認できるなど、問い合わせ対応や業務確認を円滑に行うためのトレーサビリティが確保されていることを求める。 (4) セキュリティ・認証に関する要件19 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 次期システムは、本学園の基幹業務及び個人情報を取り扱うシステムであることを踏まえ、適切なセキュリティ対策を講じた構成とすること。 なお、本学園では将来的なセキュリティ強化の方向性として、ゼロトラストの考え方を踏まえたシステム構成への移行を視野に入れており、次期システムにおいては、その実現を阻害しない柔軟な構成であることを期待する。 (5) テスト・検証環境に関する要件次期システムにおいては、本番環境とは別にテスト・検証環境を用意すること。 テスト環境においては、職員または教員が実在するアカウント情報を用いてログインし、本番環境と同様の操作性・権限制御のもとで、機能確認や業務検証を行えることを求める。 (6) 文字情報(外字)に関する要件次期システムにおいて利用する外字については、利用者、利用拠点、利用端末等によって文字体系が異なることのないよう、学園として統一的に管理可能な文字情報基盤を導入することを求める。 また、将来的なシステム連携や帳票出力、外部サービスとのデータ連携等を考慮し、外字を含む文字情報が一貫して取り扱える仕組みであることが望ましい。 (7) Webアクセシビリティについて本学園では、幅広い年齢層や多様な学生(視覚、聴覚、身体機能などに障がいを持つ方)がシステムを利用する。 このことから、利用者にとって情報へのアクセスや操作が容易であることが求められるので、以下のアクセシビリティ要件を参考にシステム導入を進めること。 また、学生が利用する画面については、スマートフォンを含む20 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 多様な端末からの利用を前提とし、画面サイズや入力方法の違いを考慮した設計とすること。 ・ 「JIS X 8341-3 高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第３部：ウェブコンテンツ」に準拠すること・ デジタル庁が定めるウェブアクセシビリティ導入ガイドブックなどの国内法令・ガイドラインを遵守し、システムの開発・運用を行うこと(8) GDPREU/EEA(欧州経済領域)在住の海外学生の個人データ処理は、GDPR(GeneralData Protection Regulation：一般データ保護規則)の適用範囲となる。 よって、EU/EEA(欧州経済領域)域内から日本国内のデータセンターへ個人データを転送する場合、標準契約条項(SCC：Standard Contractual Clause)などの法的根拠に基づき、適法かつ安全に実行することが求められる。 2.4 対象外の範囲(除外スコープ)本調達において原則として調達対象外とする範囲(以下「対象外の範囲」という)を明確にすることを目的とする。 本調達は、次期システムとして必要な業務・機能・基盤を一体的に整備することを目的としているが、すべての業務、システム、作業を無制限に本調達の対象とするものではない。 そのため、あらかじめ対象外とする範囲を明示し、提案者と本学園との間で調達範囲に関する認識の齟齬が生じることを防ぐものとする。 以下に示す対象外の範囲は、本調達において提案、見積、構築、移行等の対象には21 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 含めないことを原則とする。 ただし、対象外の範囲に該当する事項であっても、次期システムの円滑な稼働や本学園が目指す将来像の実現に資すると提案者が判断する場合には、対象外であることを明示したうえで、参考情報または任意提案として提示すること。 なお、本章において対象外と定義する範囲は、本学園が将来的に当該事項の導入や対応を行わないことを示すものではなく、本調達のスコープを明確化するために設定するものである。 ・ 組織・人事に関する事項・ 他システムの全面刷新・ 学内規程・制度そのものの変更・ 利用者教育の恒常的実施・ 本調達後に新たに発生した制度対応・ 統合DB及び認証基盤に関する事項なお、統合 DB 及び認証基盤にかかる要件等詳細事項については別途設計時に追記するものとする。 参照添付資料：調達範囲(業務とシステムの関係)、教務情報システム調達範囲3 現状の業務・システムと問題・課題本章では、本学園における現行の業務及びシステムの概要を整理するとともに、それらを取り巻く問題・課題について、業務面・システム面の両側面から明らかにす22 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. る。 本章の内容は、次期システムの検討にあたっての前提条件を共有することを目的とするものであり、現行業務や現行システムを単に踏襲することを前提とするものではない。 提案者においては、本章に示す内容を十分に理解したうえで、次期システムにおける業務・システムの在り方について提案すること。 3.1 業務の概要本学園における業務は、教育・学修活動を中心として、入学から在学、修了・卒業に至るまでの学生に関わる一連の業務に加え、これらを支える教職員の業務によって構成されている。 次期システムの検討にあたっては、現行業務の全体像及び業務間の関係性を正しく把握することが重要であることから、本学園の現行業務については、別紙「現行機能一覧」及び別紙「現行業務フロー」において整理している。 提案者は、これらの別紙資料に記載された現行業務の内容及び業務フローを十分に理解したうえで、次期システムにおいて当該業務をどのように支援・実現するかについて検討・提案すること。 なお、次期システムは、現行業務を単に踏襲することを目的とするものではなく、業務の効率化、標準化、電子化、並びに教育・学修形態の多様化への対応等を見据え、業務プロセスそのものの見直しや改善を含めて検討することを前提とする。 また、オンライン授業や対面・ハイブリッド型授業の併存、多様な学修形態や学生属性への対応、各種申請・手続きの電子化・ペーパーレス化等、業務内容及び業務運用が継続的に変化していくことを踏まえ、将来的な制度変更や業務変容にも柔軟に対応可能な仕組みとして、次期システムを構築することを求める。 23 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 参照添付資料：現行機能一覧、現行業務フロー(フォルダ)3.2 システムの概要本学園の現行システムは、「システムWAKABA(教務情報システム)」を中心として、これまでに業務要件や制度対応に応じて追加構築された複数の外部システムと連携しながら運用されている。 これらの外部システムの中には、特定の業務課題に対応するため、教職員自らが設計・開発を行い構築されたものも含まれており、全体としては複数のシステムが相互に連携する構成となっている。 現行システムの構成及び各システム間の関係については、別紙「現行システム構成図」に示すとおりである。 次期システムの検討にあたっては、現行システムの構成や連携関係を踏まえつつ、業務の変化や制度改正、ICT環境の進展に柔軟に対応可能な持続性・拡張性の高いシステム基盤への刷新を目的とする。 次期システムとして想定する全体構成の考え方については、別紙「新システム構成図案」において整理しているが、これはあくまで現時点での想定案であり、提案者は当該構成に必ずしも拘束されることなく、本学園の要求事項や将来像を踏まえた最適なシステム構成について提案すること。 提案にあたっては、次期システム全体の構成、各システムの役割分担、システム間の連携方式、並びにデータの管理・活用の考え方等を含め、システム全体としての整合性・合理性が確保された構成を示すことを求める。 なお、次期システムは、現行システムを単に置き換えることを目的とするものでは24 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. なく、将来的なシステム追加や入替、外部サービスとの連携強化等にも柔軟に対応可能な疎結合かつ拡張性の高い構成とすることを前提とする。 参照添付資料：現行システム構成図、現行システム関連図、現行システム一覧3.3 問題・課題本学園の現行業務及び現行システムにおいては、これまでの制度対応や業務拡張により一定の機能充足は図られてきたものの、教育・学修形態の多様化や外部連携の拡大、ICT環境の進展に伴い、様々な問題・課題が顕在化している。 これらの問題・課題は、個別業務や特定機能に限定されるものではなく、業務プロセス、システム構成、データ管理、外部連携等にまたがるものであり、次期システムの検討においては、個別対応ではなく全体最適の観点からの解決が求められる。 現時点において、主な問題・課題として認識している事項は以下のとおりである。 (※)がある事項については本調達対象外・ 科目の履修登録におけるキャップ制の導入や、新たな学生種の創設・ 連携校や各種相手先に関するコード管理及びその運用の整理・ 海外在住学生への対応を含む、学生属性の多様化への対応・ 証明書発行業務における外部システム活用を見据えた対応(※)・ ライブWeb授業に関する要件整理及び運用面を含めた対応・ 電子学生証の導入を見据えたシステム対応(※)・ 大学院におけるシラバスの認証評価対応25 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ・ 単位認定試験に係る機能及び業務運用の精査(※)・ 出願(学部)・履修登録業務における業務負荷やシステム対応の見直し・ 入試(大学院)業務における業務負荷やシステム対応の見直し上記は、現時点で把握している主な問題・課題の一部であり、その他の問題・課題については、別紙「問題・要望一覧」において整理している。 提案者は、本章及び別紙「問題・要望一覧」に示す内容を十分に理解したうえで、次期システムにおいてこれらの問題・課題をどのように解決・緩和するかについて、システム構成、機能、運用の観点を含めて総合的に提案すること。 なお、本章に記載した問題・課題は、必ずしも現行業務や現行システムを全面的に否定するものではなく、次期システムにおける検討・改善の方向性を示すためのものである。 参照添付資料：問題・要望一覧4 業務要件本章では、次期システムにおいて実現すべき業務要件について、その基本的な考え方及び要求水準を示すものである。 次期システムは、別紙「現行機能一覧」及び別紙「現行業務フロー」に示す現行業務を前提としつつ、単に現行業務をそのまま再現することを目的とするものではなく、業務の効率化、標準化、電子化、並びに将来的な制度変更や業務運用の見直しに柔軟に対応可能な仕組みとして構築されることを求める。 また、本章に示す業務要件26 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. は、次期システムにおいて最低限満たすべき要求事項を示すものであり、これに加えて、業務の高度化や利用者利便性の向上に資する提案については、提案者の判断により積極的に提案すること。 参照添付資料：現行機能一覧、現行業務フロー(フォルダ)4.1 業務の流れ次期システム導入に伴い、現行業務フローから変更が生じる業務フロー(以下「新業務フロー」という)について示す。 新業務フローは、別紙「現行業務フロー」に記載された業務フローのうち、次期システムにおける業務改善、業務効率化、制度対応等により、業務手順や役割分担、処理方法等に変更が生じる部分のみを対象とするものであり、現行業務フローをそのまま再掲するものではない。 提案者は、現行業務フロー及び本章に示す業務要件、問題・課題を踏まえ、次期システムにおいて想定される新業務フローの考え方や業務の流れについて提案すること。 なお、新業務フローは、次期システム導入時点で確定するものではなく、業務運用の見直しや段階的な導入、制度変更等に応じて、柔軟に見直し・調整されることを前提とする。 そのため、提案にあたっては、特定の業務手順や運用方法に過度に固定されたものではなく、将来的な変更にも対応可能な業務フローの考え方を示すこと。 参照添付資料：新業務フロー(フォルダ)27 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 4.2 業務要件本節では、次期システムにおいて実現すべき業務要件のうち、業務を遂行するうえで必要となる主な業務要件について示す。 業務機能の詳細については、別紙「要件一覧(業務・システム業務別機能)」の業務要件欄に示すとおりとする。 提案者は、当該別紙に記載された各業務要件の内容を十分に理解したうえで、次期システムの導入により、これらの業務要件がどのように実現・支援されるかについて提案すること。 なお、別紙に記載された業務要件は、現時点における問題・課題を整理し抽出したものであり、現行業務や現行システムにおける機能をそのまま踏襲することを目的としたものではない。 業務の効率化、標準化、電子化等の観点から、より適切な業務の進め方や業務支援の在り方が考えられる場合には、別紙記載内容に限定することなく提案すること。 また、提案にあたっては、各業務要件について、業務上の処理内容や関係者(学生、教職員等)、業務の流れや留意点を踏まえたうえで、業務運用の観点から分かりやすく整理して示すことが望ましい。 別紙記載内容に限定することなく、適宜提案に含めること。 添付資料：要件一覧(業務・システム業務別機能)28 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 5 システム機能要件次期システムにおけるシステム機能は、別紙「要件一覧(業務・システム業務別機能)」の機能要件欄及び現行システムにおける問題・課題を踏まえ、教職員及び学生が日常的に利用することを前提として、操作性・効率性・信頼性の向上を図るものである。 具体的には、入力作業の適正化や重複作業の削減、直感的で分かりやすいユーザインターフェースの実現、職員による資料作成や各種判定業務における負荷の軽減、登録情報の公開・非公開に関する制御の柔軟性、検索性及びアクセシビリティの向上、並びに長期的な運用を見据えたデータの保持性・継続性の確保といった観点を重視する。 また、次期システムの機能は、特定の業務や制度に過度に依存することなく、将来的な制度変更や業務運用の見直しにも柔軟に対応可能な構成とすることが望ましい。 そのため、機能の追加・変更が全体に与える影響を最小限に抑えられるよう、機能間の役割分担や連携を考慮した提案であること。 参照添付資料：要件一覧(業務・システム業務別機能)5.1 共通の要件共通システム機能要件は、特定の業務や個別機能に依存しない、次期システム全体の基盤として必要となる機能・仕様を整理したものであり、すべての業務機能の前提となる共通的な仕組みを定義することを目的とする。 具体的には、利用者の権限・アクセス制御、共通マスタ管理、ログ及び実行履歴の29 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 管理、UI/UX やマルチデバイス対応といった操作性・利便性に関わる仕様、並びに業務処理や運用管理を横断的に支える機能群を対象とする。 これらの共通システム機能を体系的に整備することで、システム全体としての統一性・安全性・保守性・拡張性・完全性・機密性・可用性を確保するとともに、業務や組織単位での個別最適に起因する情報・機能の分断(サイロ化)を防止し、持続可能なシステム基盤を実現することを目指す。 また、共通システム機能要件は、今後の業務追加や制度変更、新技術の導入に際しても、影響範囲を局所化し、柔軟かつ効率的に対応できる構造を実現するための重要な前提条件として位置づける。 本章に示す分類ごとの要件は、次期システムにおいて共通的に満たすべき要求事項を整理したものであり、提案者はこれらの要件を踏まえたうえで、最適な実装方法や構成について提案すること。 参照添付資料：要件一覧(システム共通機能)5.2 業務別の機能要件業務別システム機能要件は、出願(学部)、入試(大学院)、履修・成績、授業運営、学修支援、修了・卒業判定等、本学園における各種業務の特性や業務フローを踏まえ、当該業務を適切かつ効率的に支援するために必要となる機能要件を整理したものである。 本節に記載する業務別要件とは、別紙「要件一覧(業務・システム業務別機能)」30 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. の機能要件のことであり、現行システムにおける業務運用や機能構成を単に踏襲することを目的とするものではなく、業務の効率化、標準化、電子化、並びに将来的な制度変更や運用見直しへの対応を前提として整理している。 また、業務別機能要件は、前節で定義した「要件一覧(システム共通機能)」を前提として構成されるものであり、共通機能と業務固有機能との役割分担を明確にすることで、システム全体としての整合性及び保守性を確保することを目的とする。 提案者は、本章に示す各業務別機能要件を踏まえ、当該業務をどのようなシステム構成・機能により実現するかについて提案すること。 なお、業務の特性や将来の拡張性を考慮し、より効果的な機能構成や実現方法がある場合には、その内容を含めて提案すること。 さらに、次期システムにおけるシステム間の関連性については、別紙「現行システム関連図」から「新システム関連図」として整理してほしい。 当該関連図は、各システムの役割分担や情報の流れを俯瞰的に示すことを目的としたものであり、特定の製品構成や実装方式を固定するものではない。 提案者は、「現行システム関連図」を参考にしつつ、より効果的または合理的な連携の在り方がある場合には、その内容を含めて提案すること。 参照添付資料：要件一覧(業務・システム業務別機能)、現行システム関連図6 非機能要件本節では、次期システムに求める非機能要件(性能、拡張性、信頼性、完全性、機31 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 密性、可用性、移行、運用・保守、セキュリティ等)を定義する。 非機能要件の詳細な要求事項、適用範囲、指標、目標値、測定条件、優先度及び判定基準は、添付資料「非機能要件一覧」の「非機能要件」シートに記載された内容を正式要件とする。 本節は、非機能要件の趣旨・要点・調達時の必須対応事項を記載するものであり、本文と添付資料に差異がある場合は添付資料を優先する。 提案者は添付資料の全項目について、実現方式・設計根拠・測定／検証方法・運用前提・コスト影響・リスク及び代替案を提案書に明示し、発注者の確認・承認を得ること。 添付資料のうち横断カテゴリ(例：クラウド依存性・ガバナンス)を含む項目は、本節の該当節(性能／運用／セキュリティ等)に読み替え、同等の拘束力を持つものとして適用する。 また、添付資料「非機能要件一覧」の「非機能要件」シートに記載された内容のうち、ベンダー提案を要望する旨の記載があるものや、各節に記載の提案要望について提案すること。 参照添付資料：非機能要件一覧6.1 性能及び拡張性要件次期システムは、各機能について、通常時及びピーク時の利用においても支障なく業務・学習が遂行できる性能を確保すること。 32 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 将来的な利用者数・同時アクセス数・データ量・処理量・連携システム数・機能数の増加に対し、サービスレベルを維持できる拡張性を備えること。 性能及び拡張性に関する詳細要件は、添付資料「非機能要件一覧」の「非機能要件」シートの「性能・拡張性」カテゴリ行を参照すること。 参照添付資料：非機能要件一覧6.1.1 応答時間・処理時間(1) 提案者は、オンライン処理及びバッチ処理の応答時間／処理時間の指標、目標値、測定条件、統計的な判定方法(特異値除外、パーセンタイル(例として、P95の場合はレスポンスを5秒以内とした場合にはオンライン処理の95%のレスポンスが5秒以内に返ってくることを言う)等)を提案すること。 (2) 提案者は、添付資料に示す性能目標を満たすアーキテクチャ、ミドルウェア構成、アプリケーション設計を提案すること。 (3) 性能試験は添付資料に定義された測定条件・判定基準に従い実施し、結果報告により要件達成を証明すること。 ステム正常稼働に必須のバッチは、障害時の再実行時間が確保できる設計・運用とする。 6.1.2 同時アクセス数・処理量通常時・ピーク時の想定利用者数、同時アクセス数、セッション数、オンラインスループット等の前提条件は、添付資料の想定負荷に従う。 33 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 提案者は、想定負荷を前提とした負荷試験条件及び性能確保策(負荷分散、キャッシュ、非同期化、スケールアウト等)を提案すること。 負荷試験の実施と評価は添付資料の定義に従い、結果を発注者へ報告する。 6.1.3 データ量増加予想と拡張性データ保持方針、年間増加率、保存期間、削除／アーカイブ方針、将来容量上限、拡張時の許容停止条件等は、添付資料の定義に従う。 提案者は、データ増加に応じた拡張方式、拡張手順、停止影響、所要時間及び費用を提案すること。 拡張後も添付資料で定義された性能水準を維持できることを設計で担保すること。 6.1.4 信頼性：可用性要件次期システムは、授業・学習・教務／管理業務を安定して継続できる可用性、回復性及び耐障害性を備えること。 稼働時間帯、計画停止の扱い、稼働率目標、障害時復旧目標、バックアップ／リカバリ、災害対策等の詳細は、添付資料「非機能要件一覧」の「非機能要件」シートの「可用性」カテゴリ行を参照すること。 参照添付資料：非機能要件一覧34 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 6.1.5 目標稼働率(1) 稼働率の目標値、算定方法、対象業務範囲、計画停止の扱いは、添付資料の定義に従う。 (2) 提案者は、稼働率達成のための冗長化方式、監視設計、運用体制を提案すること。 (3) 稼働率に関する報告・レビューの実施タイミング及び内容を提案すること。 6.1.6 障害発生時の復旧目標時間(1) 障害区分ごとの復旧目標、復旧優先順位は、添付資料の定義に従う。 なお、切戻し条件は提案者が提案すること。 (2) 提案者は、障害検知から復旧・報告・恒久対策までの標準フローと運用手順を提案すること。 (3) 大規模災害時の再開水準・再開目標は添付資料に従う。 6.1.7 バックアップ・リカバリ要件(1) バックアップ対象、取得方式、取得頻度、保持期間、保管方式、リストア要件は、添付資料の定義に従う。 (2) 提案者は、バックアップ／リストア手順書、復旧試験方法、復旧訓練計画を提示し、発注者承認を得る。 (3) バックアップは通常運用へ影響を最小化する設計とする。 35 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 6.1.8 移行要件次期システムへの移行にあたり、現行システム事業者と十分な協議を行うこと。 現行システム及び周辺システムのデータ・設定・コンテンツ、業務マニュアル等についても、整合性・完全性及び利用継続性を維持した状態で移行・整備するものとする。 また、次期システム移行後の円滑な業務遂行を目的として、業務マニュアルを整備すること。 移行の詳細要件(対象範囲、方式、停止許容、品質基準、リハーサル、切替／切戻し条件等)は、提案者が提案すること。 参照添付資料：非機能要件一覧6.1.9 移行対象データ(1) 移行対象範囲、移行除外範囲、移行品質要件、機密区分別の取扱いは、提案者が提案すること。 (2) 提案者は、変換ルール、品質担保方法、移行後検証観点を移行設計書として提示すること。 (3) 個人情報を含むデータは、6.3のセキュリティ要件及びGDPR準拠要件に従い適切に取り扱うこと。 (4) 移行対象データについては、移行前に発注者に確認すること。 36 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 6.1.10 移行手順(1) 移行方式、移行リハーサル回数は、添付資料の定義に従う。 (2) 提案者は、切替手順、切戻し条件を提案すること。 (3) 提案者は、移行作業の責任分界、工程、成果物、スケジュール、開始条件を具体化し提示する。 (4) 移行に伴うサービス停止が必要な場合、停止時間・周知方法・回避策を提案すること。 6.1.11 移行期間及び検証方針(1) 提案者は、移行期間、整合性検証方針、合否判定基準を提案すること。 (2) 提案者は、試験移行・本移行の検証結果を整理し、発注者の承認を得る。 (3) 移行不具合発生時の再移行・リカバリ手順を用意する。 6.1.12 業務マニュアルの整備(1) 提案者は、次期システムへの移行に伴い、業務手順の変更点を反映した業務マニュアルを整備し、旧版との混在を防止するためのバージョン管理を行うこと。 (2) 業務マニュアルは、担当者による更新及び最新版としての公開を可能として、更新時には関係者へ適切に周知できる仕組み(通知、メール等)を備えること。 (3) 業務マニュアルは、業務カテゴリまたはシステム単位で体系的に整理され、利用者が必要な情報に容易かつ迅速にアクセスできるように検索が可能であること。 37 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 6.2 運用・保守要件次期システムは、安定運用と迅速な障害対応を実現するため、監視、運用体制、インシデント管理、変更管理及び継続的改善の仕組みを備える。 また、ベンダーロックインを回避するため、軽微な変更は管理者操作で対応可能とし、変更影響や改修コストを抑制できる保守・運用構造を備えるものとする。 提案者は、以下6.2.1から6.2.3の内容を運用・保守の受託事業者が実施できるよう、詳細要件(監視、インシデント管理、変更管理、継続的改善等)を定義すること。 参照添付資料：非機能要件一覧6.2.1 監視対象と監視方法(1) 監視対象、監視方式、通知ルール、ログ保管期間は、添付資料の定義に従う。 (2) 提案者は、監視設計書、一次対応手順、監視レポート仕様を整備し、発注者承認を得る。 (3) セキュリティインシデント検知に係る監視は 6.3 のセキュリティ要件と整合性を取る。 6.2.2 障害発生時の対応フロー(1) 障害発生時の対応は、「検知／受付」 → 「一次切り分け」 → 「影響評価・重要38 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 度判定」 → 「暫定復旧」 → 「恒久復旧」 → 「再発防止」 → 「クローズ」の標準フローに従う。 提案者は当該フローを運用手順として整備し、発注者の承認を得る。 (2) 上記フローにおける主な作業内容は以下とする。 ・ 検知／受付：監視アラート、ユーザ通報、定期点検結果等により障害を検知・受付し、インシデントチケットを起票する。 ・ 一次切り分け：現象の再現確認、ログ・監視値確認、影響範囲の概略把握を行い、暫定対応の可否を判断する。 ・ 影響評価・重要度判定：外部連携／決済等への影響、利用者数、業務停止の有無、代替手段の可否に基づき重要度(優先度)を判定する。 RTO等の数値目標は添付資料に従う。 ・ 暫定復旧(回避策)：サービス継続を優先し、設定変更・リトライ・部分停止・手動運用等により影響を最小化する。 必要に応じて利用者アナウンスを実施する。 ・ 恒久復旧：原因を特定し、プログラム修正、構成変更、パッチ適用、データ補正等により恒久対策を実施する。 ・ 再発防止：原因分析(根本原因分析：RCA)、再発防止策の立案・実施、運用手順や監視閾値の見直しを行う。 ・ クローズ：復旧確認・影響範囲確定・再発防止策完了をもってインシデントチケットをクローズし、障害記録を保管する。 (3) 障害対応における情報共有・エスカレーション・対外周知は以下とする。 39 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ・ 重要度に応じ、提案者内の二次対応者／専門チーム／製品ベンダーへ速やかにエスカレーションする。 ・ 発注者への初報・経過報告・復旧報告のタイミング、連絡手段、報告フォーマットは提案者提案で明確化し、発注者承認を得る。 ・ 学生・教職員への周知(障害発生、影響範囲、回避策、復旧見込み等)は、発注者の指示または合意したルールに従い、提案者が支援する。 (4) 提案者は、障害対応に関する成果物として、少なくとも以下を整備・提出する。 ・ 障害対応手順書(一次切り分け観点、暫定復旧手順、切戻し基準を含む)・ 重要度判定基準表(サービス影響の尺度と判定例を含む)・ 障害報告書テンプレート(原因、影響、時系列、対応、再発防止、教訓を含む)・ 定例の障害レビュー資料(トレンド分析、SLA達成状況、改善提案を含む)(5) 障害対応の目標対応時間(初動、暫定復旧、恒久復旧、報告期限等)は、添付資料「非機能要件」シートの可用性／運用・保守性に関する定義に従う。 添付資料に数値が存在しない場合は、提案者提案により妥当値と根拠を提示させ、発注者が承認する。 6.2.3 保守性・変更容易性(1) 画面表示や項目設定等の軽微な変更については、ベンダーによる個別改修に依存せず、設定変更または管理者操作により対応可能であること。 (2) 機能追加や仕様変更に伴う影響範囲を限定できるよう、モジュール化等により機能の独立性を確保し、改修コストが過度に増加しない構造とすること。 40 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (3) 業務側(職員)が改善要望を行える管理・設定機能を備えること。 (4) 市町村合併等により住所情報や市町村名等に変更が生じた場合など、外部環境の変化に起因するデータの不整合や本学園が必要と判断した場合は、本学園の確認後、データの補正・統合・更新等のクレンジング対応を行うこと。 6.3 セキュリティ要件次期システムでは情報資産の機密性・完全性・可用性を確保し、大学が管理するデータを安全に運用することを目的とする。 そのため学生情報のような機微情報を保護するため、認証・アクセス制御、ログ監査、暗号化、脆弱性対策などの総合的なセキュリティ対策を実施する。 また、商用クラウドを基盤とし、冗長構成及びデータの安全性と継続運用を確保する。 (1) 次期システムは、放送大学学園情報セキュリティポリシー及び関連法令(個人情報保護法、必要に応じ GDPR 等)に準拠し、情報資産の機密性・完全性・可用性を確保する。 (2) セキュリティ要件の対象となる次期システム範囲は以下とする。 ・ 国内クラウドリージョンに構築される本番環境(マルチAZ相当の構成を含む)・ バックアップ環境(DR、アーカイブ含む)・ 仮想ネットワーク、サブネット、ファイアウォール、アクセス制御リスト等のネットワーク設定・ クラウド事業者が提供するログ・監査・暗号化・ 次期システムのアプリケーション、ミドルウェア及び運用に必要なサービス全般41 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ・ 外部接続(学園本部・学習センター・関連外部システム等)(3) 対象利用者は以下とする。 ・ 受験生(入学希望者)・ 学生・ 教職員・ システム運用者(放送大学学園)・ システム管理者(アプリ／インフラ保守事業者)・ クラウド事業者(基盤管理の責任範囲として)(4) 次期システムにおいて、外部サービスまたはクラウドサービスを利用する場合には、政府情報システムのためのセキュリティ評価制度(ISMAP)への登録、またはこれと同等のセキュリティ水準を満たすサービスを提案すること(5) 次期システムは商用クラウド環境を基盤とし、国内クラウドリージョンを主運用拠点とする複数アベイラビリティゾーン(AZ)相当の冗長構成を採用する。 また、国内主要拠点とは別のクラウドリージョンにはバックアップデータを保存し、災害対策(DR)拠点として利用する。 (6) クラウド事業者の責任共有モデルに基づき、物理的セキュリティ及びクラウド基盤の耐障害性確保はクラウド事業者の責務とし、アプリケーション、OS、ネットワーク構成、セキュリティ設定、データ保護等は次期システムの構築・運用事業者の責務とする。 42 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 6.3.1 認証(アクセス制御)多要素認証、権限管理、セッション管理などを通じて、適切なアクセス制御を実現する。 また、利用者を識別し、役割に応じた権限を付与することで、不正アクセスを防止し安全にシステムを利用できる状態を確保する。 (1) 管理者権限を有するユーザについては多要素認証(MFA)等の強固な認証方式を用いる。 (2) SAML2.0／OIDC に準拠したシングルサインオン(SSO)を実現する。 学術認証フェデレーション(学認)に対応し、SAML 2.0 等の標準的な認証プロトコルを用いた認証連携が可能であること。 (3) なお、Shibboleth 等、学認において一般的に利用されている認証基盤との連携が可能であること。 (4) 外部に公開するAPIの認証方式は、OAuth 2.0またはOIDCと同等以上の セキュアな認証方式を採用すること。 (5) APIキーを使用する場合は、有効期限の設定・失効・ローテーションの 仕組みを備えること。 (6) 認証権限に応じて機能・メニューの制限を行う(グループ／個人単位の RBAC／ABAC に対応)。 (7) データアクセス権限はユーザレベルで管理する。 (8) 次期システムへのログインはユーザID・パスワードによる認証を基本とし、パスワード入力は非表示とする。 (9) 一定時間操作がない場合、自動的にログオフ(セッションタイムアウト)する。 43 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (10) ID／認証情報管理(追加・更新・削除等)は、学園で策定する管理ルールにしたがって運用する。 (11) アクセス権限は業務上必要最小限とする。 (12) 利用者(学生・教職員等)がパスワードを失念した場合に、管理者を介さず、本人確認を前提として自ら再設定できる仕組みを有すること。 なお、再設定にあたっては、不正利用防止の観点から適切な認証手段を講じること。 6.3.2 ログ監視・監査証跡システム上の操作履歴を正確かつ改ざんできない形式で記録し、不正行為や障害生時の追跡を可能にする。 また、長期保存や自動通知などの監査機能を活用し、利用状況の安全性を図る。 (1) 以下の監査ログを取得し、安全に保管する。 ・ 認証ログ(ログイン／ログアウト)・ 操作ログ(参照／登録／更新／削除／エクスポート等)・ 管理者操作ログ(権限・設定変更等)・ 個人情報・成績情報等のセンシティブデータ閲覧ログ・ API アクセスログ(呼び出し元・エンドポイント・パラメータ・レスポンスコード・処理時間(2) ログはクラウド事業者が提供する監査ログ機能(例：クラウド監査証跡サービス)を用い、改ざん防止措置を施した上で保管する。 (3) ログ保管期間は原則 30 年間 とし、オンライン／アーカイブの保存階層は本学園44 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. と協議して定める。 (4) 不正アクセス等のインシデントを検知した場合、自動通知機能により速やかに管理者に通知する。 (5) ログは CSV／JSON／API 等でエクスポート可能とする。 (6) 取得したログに対して、日時・ユーザID・操作種別・IPアドレス等の 条件による検索(全文検索を含む)が可能な仕組みを備えること。 (7) 複数種別のログ(認証・操作・APIアクセス・システム)を統合的に 参照・分析できる監視基盤(SIEM等)を提案すること。 (8) ログに含まれる個人データは利用目的を明確化し、必要最小限に取得・保存する。 6.3.3 機密データ保護(暗号化)機微情報や重要データを通信・保存の両面で暗号化し、不正アクセスや漏えいを防止する。 また、バックアップ暗号化を含む適切な保護措置により、長期にわたってデータの安全性を確保する。 (1) システム間及びユーザ端末との通信は TLS 1.3 を標準とし、安全な通信経路を確保する。 ただし、外部システムとの連携等やむを得ない事情がある場合は TLS1.2 を最低ラインとして許容するが、その場合は設計時に学園と合意すること。 (2) データベース及びストレージに保持される重要情報は、クラウド事業者が提供する暗号化機能(例：ブロック／オブジェクトストレージ暗号化)を利用し、AES-256 相当の暗号強度を確保する。 45 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (3) バックアップデータを含め、長期保存対象データ(学生・成績・入試情報等)は本番データと同等の暗号化とアクセス制御を適用する。 (4) 長期保存(原則 30 年間)の期間中においても暗号強度が確保されるよう、暗号方式の更新等により情報の機密性を維持する。 (5) バックアップデータを含め、長期保存対象データは、必要に応じて仮名化やデータ分離を適用し再識別リスクを低減する。 (6) Web アプリケーションはセキュアコーディングを行い、クラウド事業者が提供する WAF 等により外部攻撃から保護する。 6.3.4 個人情報の保持及び自動削除(GDPR対応)次期システムにおいて取り扱う個人情報については、GDPR(General DataProtection Regulation：一般データ保護規則)をはじめとする関連法令及び学園規程を考慮し、あらかじめ定義された保持期間を経過した個人データを、自動的に削除する仕組みを備えること。 自動削除の対象となるデータ種別、保持期間及び削除タイミングについては、別紙業務概念及び共通定義書「個人情報等一覧」シートに定める内容に基づくものとする。 なお、当該仕組みは以下の要件を満たすこと。 ・ 手動作業に依存せず、システム的に自動実行されること。 ・ 削除または匿名化の実行履歴(対象データ、実行日時等)を記録・確認可能であること。 ・ 保持期間及び削除条件は、運用上の必要に応じて設定変更可能であること。 46 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 6.3.5 セキュリティリスク分析・評価クラウド基盤を含むシステム全体のリスクを体系的に洗い出し、影響度に応じて対策方針を決定する。 また、ガイドライン改訂や環境変化に応じて定期的な見直しを行い、最新の脅威に備える。 (1) 商用クラウドの責任共有モデルを踏まえ、アプリケーション層・設定層・ネットワーク層を中心にセキュリティリスク分析を実施する。 (2) 分析対象は、本番環境、バックアップ環境、ネットワーク構成、IAM設計、アプリケーション設定等とする。 (3) リスクは「影響度 大・中・小」で評価し、回避・低減・受容・転嫁のいずれかの対応を定める。 (4) ガイドライン(NISC・IPA・クラウド事業者のベストプラクティス)が改訂された場合は、適宜再評価し、必要な対策を更新する。 (5) 高リスク処理については DPIA(影響評価)を参考に評価し、個人情報保護法(APPI)ガイドラインに基づいて対策を講じる。 6.3.6 セキュリティ診断・脆弱性管理第三者診断や自動診断を通じてシステムの脆弱性を継続的に発見し、迅速な修正を行う。 また、クラウド固有設定を含む診断範囲を明確化し、適切なパッチ適用により安全性を確保する。 (1) Web アプリケーション、ネットワーク(サーバ・機器・クラウド環境含む)、API及びペネトレーションテストについて、第三者の専門技術者による手動を含47 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. む脆弱性診断を実施する。 診断の実施タイミング・頻度等の詳細は添付資料「非機能要件一覧 5-2-1」に従う。 (2) 商用クラウド環境においては、IAM 設定、ネットワークアクセス制御、ストレージ設定等も診断対象に含める。 (3) 緊急性の高い脆弱性が発見された場合には、本学園と協議の上、速やかに対応を行う。 (4) パッチ適用は OS・ミドルウェア・アプリケーションレイヤーを対象とし、クラウド基盤部分はクラウド事業者が責任を負う。 (5) 診断には「過剰な個人データ取得の有無」「目的外利用がないか」を含める。 6.3.7 技術的セキュリティ対策ネットワーク制御、DDoS対策、マルウェア対策などの多層防御により外部攻撃や不正侵入を防止する。 また、クラウドの監視・検知機能を活用し、異常挙動を早期に把握して被害を最小化する。 以下の対策は技術的安全管理措置に該当し、漏えい・滅失・改ざん防止のため必須とする。 (1) 仮想ネットワーク上で不要な通信は遮断し、ファイアウォール機能やセキュリティグループ等を用いて最小権限ネットワークを実現する。 (2) サービス不能攻撃(DoS／DDoS)対策として、クラウド事業者が提供するDDoS 防御機能を利用する。 (3) クラウド事業者が提供する不正検知サービス(例：行動分析型検知)を活用し、不審な挙動を検出する。 48 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (4) マルウェア対策は、サーバにおいてエージェント型対策を実施し、定期スキャン及び最新パターンの維持を行う。 (5) 物理セキュリティはクラウド事業者の責任範囲とし、利用者はクラウド事業者の公開するセキュリティ認証・監査レポートを確認する。 6.3.8 セキュリティ運用・インシデント対応運用中の安全確保のため、インシデント発生時の初動対応・原因分析・再発防止策を迅速に実施する。 また、ログ調査や設定管理を通じて運用の信頼性を高め、継続的にセキュリティ水準を向上させる。 (1) セキュリティインシデント発生時には、検知後速やかに本学園へ第一報を行う。 (2) クラウド監査ログを利用し、原因分析・影響範囲調査を行い、本学園と連携して対応する。 (3) 運用・保守の認証情報、暗号鍵、設定等は厳格に管理し、漏えい防止を図る。 (4) 脅威状況やクラウド事業者のアップデートに応じて、セキュリティ対策を定期的に見直す。 (5) 個人データ漏えい時は法令に基づき速やかに通知・報告を行う。 (6) 権利行使(開示・訂正・削除等)への対応手順を整備する。 6.4 設計に関する要件6.4.1 基本的な要件(1) 基本設計及び詳細設計49 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 提案者は、本書の要件を満たすための基本設計及び詳細設計(運用設計及び保守設計を含む。)を行い、成果物について本学園からの承認を得ること。 利用者数の増加やデータ量の増大等に対応したサービスのライセンス拡大、リソース増強等が柔軟に実施できるような拡張性要件を満たすこと。 本学園及び第三者が理解可能となるよう、特に用語の定義や表記ゆれに注意した上で、各種資料及び成果物を分かりやすく作成すること。 用語の定義については、別添17「業務概念及び共通定義書」を参考にすること。 (2) 提案者が次期システムにて利用する環境提案者は、設計・開発に用いる環境として、提案者自らで「開発環境」及び「検証環境」を準備すること。 設計・開発に用いる環境は、原則として「開発環境」「検証環境」とし、システム稼働に当たってのアプリケーションプログラムリリースは「本番環境」で行うこと。 システム稼働後にインシデントが発生し、「本番環境」と同等の環境で動作確認が必要な場合は、「検証環境」で行うこと。 (3) ライフサイクルコストの考慮提案者は、次期システムの設計・開発から運用終了に至るまでの効率的な保守業務を考慮して、基本設計及び詳細設計を実施すること。 (4) モニタリングが容易に行える構成添付資料13「非機能要件一覧」に記載したプロジェクトの目標となる指標、システム運用に必要な情報等に対して、システムで適時に状況を取得できる構成とすること。 また、集計処理等によって二次的に加工した情報だけでなく、その50 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 根拠となる一次情報(ローデータ)も確認できる構成とすること。 6.4.2 基本設計及び詳細設計の実施(アプリケーションプログラム)(1) アプリケーションプログラムの基本設計アプリケーションプログラムについて、システム全体図、データの流れと機能構成、機能・画面・帳票一覧、画面遷移、データ一覧等の基本設計を行い、基本設計書(アプリケーションプログラム)を取りまとめること。 (2) 要件との網羅性基本設計書(アプリケーションプログラム)には、要件と設計項目の対応表等、要件が網羅されていることを確認できる情報を含めること。 (3) アプリケーションプログラムの詳細設計アプリケーションプログラムについて、基本設計書(アプリケーションプログラム)に基づき、機能設計(機能定義、データチェック定義、アクセス制御方式等)、スキーマ定義、コード定義、ジョブネット定義等の詳細設計を行い、詳細設計書(アプリケーションプログラム)を取りまとめること。 (4) 基本設計との網羅性詳細設計書(アプリケーションプログラム)には、基本設計書(アプリケーションプログラム)の項目との対応表等、基本設計の内容が網羅されていることを確認できる情報を含めること。 (5) パラメータ設計提案者は、アプリケーションの動作の前提となるソフトウェア(パッケージ製品)を選定し、パラメータ等の必要な設計を実施すること。 51 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 6.4.3 基本設計及び詳細設計の実施(運用・保守)(1) 既存システムの運用・保守作業の内容の棚卸し提案者は、既存システムの運用・保守作業内容をベースラインとして、作業内容の棚卸しを行い、次期システムを運用するに当たって不要となる作業、作業内容の変更を要する作業、新たに追加する作業を整理すること。 (2) 運用・保守計画提案者は、本書の「6.2 運用・保守要件」に示す内容を基に運用・保守計画書及び運用・保守実施要領の案を作成し、本学園の承認を得ること。 なお、運用・保守計画書の案には、以下の内容を含めること。 ⮚ 情報システムの次期更改までの間に計画的に発生する作業内容⮚ 上記作業の発生が想定される時期等⮚ 作業実施に必要な資料⮚ モニタリングすべきデータ・リソース⮚ 使用する運用管理機能・ツール⮚ 各作業の完了条件⮚ 運用・保守実績を記録する成果物等(3) 運用・保守設計提案者は、前項番の「既存システムの運用・保守作業内容の棚卸し」、「運用・保守計画」に記載された事項及び本書の「6.2 運用・保守要件」に記載の要件を踏まえ、運用・保守設計を行い、本学園の承認を得ること。 運用・保守設計52 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. に当たっては、本学園作業の軽減等、効率的なシステム運用・保守に資する内容を検討すること。 また、システム稼働後にインシデント数が削減される等、効率的なシステム運用・保守に資する改善案があれば提案すること。 以下を取りまとめた運用計画及び保守作業計画の案を作成し、本学園の確認を受けること。 ⮚ 定常時における定型的な作業内容、その想定スケジュール⮚ 障害発生時における作業内容(初動対応、障害切り分け、暫定対応、恒久対応など)⮚ 情報セキュリティインシデントを認知した際の報告手順、対応手順⮚ 障害発生等により設計書、ソースコード等の修正が発生した場合の報告手順、対応手順(4) 必要経費(ランニングコストの算出)運用・保守設計を行う際には以下の内容を取りまとめたランニングコスト試算表を作成し、本学園の承認を得ること。 ⮚ 運用・保守段階において発生する各種コストに係る予実管理のための管理様式⮚ 運用・保守設計実施時点で判明している所要見込額⮚ 必要となるソフトウェアライセンス所要額及びサービス利用額(5) 運用業務効率化の方策自動化、セルフサービス化等による効率的なシステム運用・保守に資するシステム改修案があれば提案すること。 (6) 運用・保守手順書53 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 提案者は運用・保守計画書を踏まえ、以下を取りまとめた運用・保守手順書(当該運用・保守手順書には運用・保守作業員が実作業レベルで利用するマニュアル等も含めること。)を作成し、本学園の承認を得ること。 また、本学園が提示する運用規程の要件に基づき運用規程の案を作成し、本学園の承認を得ること。 なお、運用・保守手順書は提案者が作成するが、別途調達する運用・保守の受託事業者が運用・保守の実際の対応を検討し、適宜改訂を行うものとする。 ⮚ 定常時及び障害時において想定される運用体制⮚ 保守体制⮚ 実施手順書等(7) 運用・保守の引継ぎ提案者は、運用・保守の業務を受注した事業者に対して、運用・保守業務の契約が開始される前までに、引継ぎを完了させること。 運用開始後に新たな問題が見つかった場合には、本学園に報告を行い、運用・保守を受託した事業者に対して対応策等の引継ぎを行うこと。 6.4.4 基本設計及び詳細設計の実施(システム方式)(1) 基本設計本書の内容より、システム方式に関する基本設計結果を記載したものとして基本設計書(システム方式)を作成し、本学園の承認を得ること。 基本設計書(システム方式)には以下の内容を含むこと。 ⮚ 非機能要件(信頼性、性能、拡張性、セキュリティ等)を実現するための設54 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 計⮚ システム設計(システム環境、ネットワーク、設備・運用)⮚ 業務継続設計(システムバックアップ、データバックアップ、障害発生時の縮退運転や自動継続運転、大規模災害対策拠点・環境)等(2) 詳細設計基本設計書(システム方式)を踏まえ、システム方式に関する詳細設計結果を記載したものとして詳細設計書(システム方式)を作成し、本学園の承認を得ること。 詳細設計書(システム方式)には以下の内容を含むこと。 ⮚ 非機能要件(信頼性、性能、拡張性、セキュリティ等)を実現するための設計⮚ システム設計(システム環境、ネットワーク、設備・運用)⮚ 業務継続設計(システムバックアップ、データバックアップ、障害発生時の縮退運転や自動継続運転、大規模災害対策拠点・環境)等(3) 環境定義以下の環境定義に係る作業を行うこと。 ・ 構築作業全般のスケジュール、手順、要領等も必要に応じて記載すること。 また、クラウドサービスを利用する場合はクラウドサービスプロバイダー(以下、「CSP」という。)が提供する稼働環境(本番環境、検証環境等)のセットアップ後に稼働環境が想定どおりに構築できていることを確認するためのテスト・確認項目を記載したものとして、動作確認テスト項目表及び持込み機器疎通確認項目表を作成すること。 55 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ・ 詳細設計書等を基に、CSPが提供する資源(ＯＳ，ミドルウェア)や次期システムが個別に配置し、独自に設計・実装して利用するソフトウェアの環境パラメータを取りまとめたものとして環境定義書を作成すること。 ・ 提案者は、基盤構築の結果、環境定義書の内容に修正が発生した場合は、環境定義書も修正すること。 ・ ソフトウェアのセットアップを行うための手順を記載したものとして環境構築手順書を作成すること。 ・ 構築するシステム稼働環境について、サービス、機器、ソフトウェア等を一覧表で取りまとめたものとして機器、ソフトウェア等の一覧表を作成すること。 ・ クラウドサービスを利用する場合のクラウド設計は以下の点に留意すること。 ⮚ クラウドネイティブのシステムとすること⮚ クラウドの機能を活用しマネージドサービスを活用すること⮚ CSPが提供するリファレンスアーキテクチャに準拠すること⮚ クラウド利用費用の透明化(本学園への公開)と継続的な最適化を行うこと⮚ ログの記録や保管を適切に実施すること6.4.5 移行計画提案者は、次期システムの環境、ツール、手順等を記載した移行計画書を作成し、本学園の承認を得ること。 56 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 6.5 開発・テストに関する要件(1) ルールの規定提案者は、開発に当たり、アプリケーションプログラムの開発または保守を効率的に実施するため、プログラミング等のルールを定めた標準(標準コーディング規約、セキュアコーディング規約等)を定め、本学園の承認を得ること。 (2) ルール順守や成果物の確認方法提案者は、開発に当たり、情報セキュリティ確保のためのルール遵守や成果物の確認方法(例えば、標準コーディング規約遵守の確認、ソースコードの検査、現場での抜き打ち調査等についての実施主体、手順、方法等)を定め、本学園の承認を得ること。 (3) 開発手法提案者は、開発に当たり、従来のウォーターフォールに限定せず、スパイラル／アジャイル等柔軟な対応を可能とする手法をプロジェクトの特性を踏まえ検討すること。 また、継続的インテグレーション・継続的デリバリー(CI/CD)を可能とし、開発作業だけでなく運用・保守作業も含めて効率的な手法を取り入れること。 (4) 開発ツール提案者は、プログラム設計・製造に当たり開発フレームワーク等のツールを用いる場合、ベンダーロックインを防ぐため、原則として特定の事業者しか使用できない技術、製品、サービス等に依存しないツールを用いること。 57 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (5) 開発の実施提案者は、本学園の承認を得た基本設計書及び詳細設計書に基づき、次期システムのプログラム設計、開発を実施すること。 開発環境については提案者側で用意した環境で作業を行うこと。 開発に必要となる環境設定やテストデータ、テストプログラム等の作成は、提案者が行うこと。 なお、設計・開発業務を推進する上で必要となる機器、ソフトウェア等がある場合は、提案者の負担にて用意すること。 利用するクラウドサービスのデータセンター内での作業については、CSPとの調整により、提案者の負担と責任において実施すること。 (6) 開発の実施提案者は、設計開発方針に基づく全体の工程の品質・テスト方針を策定し、その上で、全体テスト計画を策定し、主管課の承認を受けること。 又、単体テスト、結合テスト及び総合テストの各工程について、以下の内容を記載したテスト計画書を作成し、本学園の承認を受けた上で提出すること。 なお、各テスト項目のうち、反復的にテストを実施するものについては、自動化することを原則とする。 ⮚ テスト方針⮚ テスト観点⮚ テスト体制⮚ テスト環境⮚ 作業内容⮚ 作業スケジュール58 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ⮚ テストシナリオ⮚ テストデータ⮚ テストで使用するツール⮚ テスト結果に係る定性・定量評価の方法(テスト密度、バグ検出密度等)⮚ 合否判定基準等提案者は、テスト計画書の内容を踏まえてテスト仕様書を作成の上、テストを実施すること。 提案者は、テスト計画書に基づき、各テストの実施状況をテスト結果報告書として作成し、本学園に提出すること。 なお、テスト(次に掲げるとおり。)の実施に当たり必要な関係機関との調整、テスト実施環境の準備や費用は全て本提案における業務及び契約金額に含まれる。 ・ 単体テストアプリケーションを構成する最小単位で実施するテストであり、主に機能単位で設計どおりに動作するかを提案者が確認する。 ・ 結合テスト複数の機能を連携させて動作を確認するテストであり、主にユースケース単位で設計とおりに動作するかを提案者が確認する。 また、システム間のインターフェースを結合したテストを行い、外部インターフェース設計のとおりに作成されていることを提案者が確認する。 ・ 総合テストシステム全体が設計とおりに動作することを確認するテストであり、ユースケースを組み合わせた一連のシステム利用ができることを、機能面、非機能59 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 面の観点から提案者が確認する。 総合テストには、システム間連携のテストも含む。 テスト内容は、負荷テスト(パフォーマンステスト、ラッシュテスト、大容量テスト、ストレステスト等)、セキュリティテスト(ペネトレーションテスト、インシデントレスポンス、縮退確認、災害対策訓練等)、データテスト(実データテスト、イレギュラーデータ等)、運用テスト(連続無停止テスト、定期メンテテスト等)に分けて実施する。 確認においては、内容に応じて担当部署(管理者ユーザ、一般ユーザ)や本学園の関係機関等、利用者のそれぞれの観点で実施する。 6.6 受入テストに関する要件受入テストは、要件に対するアプリケーションの充足性確認を目的として行い、本学園の担当部署は構築された次期システムが本書に記載した事項を適切に実現しているか、構築された次期システムを用いて実際の業務・サービスを正しく実施できるかといった観点でテストを実施する。 受入テストに用いるテストデータには、可能な限り本番環境に近い複製データを使用するが、複製データは個人が特定できる情報をマスクすること。 ただし、受入テストの目的を担保可能であることを条件に、疑似データを使用することも可能とする。 提案者は、以下の支援を行うこと。 (1) 提案者は、本学園が実施する受入テスト計画書作成作業を支援するために、受入テスト計画書(案)を作成すること。 本学園は受入テスト計画書(案)を基にして受入テスト計画書を作成する。 なお、受入テストの実施期間は十分に確保したスケジュールとすること。 60 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (2) 提案者は、本学園が実施する受入テスト仕様書作成作業を支援するために、テスト項目、使用するテストデータ、合格判定基準等を示した受入テスト仕様書(案)を作成すること。 本学園は受入テスト仕様書(案)を基にして受入テスト仕様書を作成する。 (3) 提案者は、本学園及びプロジェクト関係者が受入テスト計画書及び受入テスト仕様書に基づき実施する受入テストの実施支援を行う。 (4) 受入テストは、原則として検証環境又は本番環境において実施すること。 受入テスト実施に当たり、必要に応じて次期システムの運転スケジュール、環境設定、テストデータ等の変更を行うこと。 (5) 受入テストの実施に当たり、本学園からの質問に対する問い合わせ対応を行うこと。 (6) 受入テストで発生したすべての障害が解消されている、または問題を特定した上で対応策について本学園の承認を得ていること。 6.7 引継ぎに関する要件次期システムの運用・保守については、運用・保守を受注した事業者が実施するため、現時点で想定する引継ぎ要件を以下に示す。 (1) 引継ぎ計画書の作成運用・保守を行う事業者に対する引継ぎの開始前に、次期システムの引継ぎに係る引継ぎ対象、引継ぎ体制、引継ぎ内容、引継ぎ方法、引継ぎスケジュール、理解度確認方法、完了条件等を記載した「引継ぎ計画書」を作成し、本学園の承認61 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. を得ること。 (2) 引継ぎ方法・ 提案者は、「引継ぎ計画書」に従い、十分な時間的余裕を持って、必要な運用引継ぎを行うこと。 その際は、引継ぎ対象者の理解度を確認し、必要な場合には、「引継ぎ計画書」に記載したスケジュール等の変更を行うこと。 ・ 次期システムは、その保守や将来の拡張等の業務を他事業者に引き継ぐことが可能であること(引き継ぎのために必要となる各種ドキュメントを整備する等)。 第三者による保守性を向上させるため、成果物等は標準的に利用されているドキュメント作成ソフトウェアを用い、編集可能な形式で納品すること。 ・ ドキュメントには設計結果のみを記載するのではなく、設計根拠等も明示し、検討経緯を可視化すること。 ・ 別途定める引継ぎ期間中における引継ぎ後の運用・保守事業者からの問合わせにも対応すること。 ・ 引継ぎ期間内で引継ぎ完了しない場合は、原則として提案者の責任と負担において引継ぎを完了すること。 ・ 連携システムの保守事業者に対しては、必要となる情報がある場合には、適切に引き継ぎを行うこと。 ・ 引継ぎに際しては、本学園の指示に基づき、必要なデータ、手順等は書面62 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. または電子媒体で行うこと。 (3) 引継ぎ結果報告書の作成引継ぎ作業の完了時に、次期システムの、他事業者等への引継ぎ作業の実施結果について記載した「引継ぎ結果報告書」を作成し、本学園へ報告を行うこと。 6.8 教育に関する要件(1) 教育計画の策定教育訓練の対象者、スケジュール、実施内容、実施方法(集合研修、テキスト配布等)、教材等に関する教育訓練実施計画書を作成し、本学園の承認を得ること。 (2) 教育対象者・ システム管理部門(部門名は要件一覧を参照)次期システム全体概要、操作手順、FAQ、運用・保守手順等・ システム利用部門(部門名は要件一覧を参照)次期システム全体概要、操作手順、FAQ等(3) 教育の実施時期教育訓練の実施スケジュールについては、システム管理部門を介した調整により、受講対象者と事前に調整した上で確定すること。 ただし、遅くとも次期システムの本番稼働の 4 週間前までに教育を完了し、次期システムの利用開始前までに十分な習熟期間を確保できるようにすること。 (4) 教育の方法63 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 教育訓練の実施方法は、主に講義形式またはマニュアル配布を想定しており、以下に各教育訓練方法についての要件を示す。 ・ 講義における講師は、提案者が実施すること。 ・ 講義に必要な教材については、提案者が準備すること、必要な機材(プロジェクター等)は、本学園と協議の上、必要に応じて提案者が準備すること。 ・ 教材については、操作マニュアルだけでなく、研修以外でも参照できるよう、動画教材(YouTube等)を作成すること。 ・ 講義会場及びWeb会議環境は、本学園で準備するものとするが、詳細については本学園と協議の上、決定とすること。 ・ 講義は録画を行い、必要に応じて、掲載等を行うこと。 また、録画データは納品の上、本学園が再利用することを妨げないこと。 ・ 講義開催回数と時間は、2回を想定しており、開催時間は、概ね２時間とすること。 ・ 講義参加予定人数分の教育教材を用意すること。 なお、必ずしも紙媒体で教材を準備する必要はなく、受講者が確認しやすい形態であれば電子データを配布する形でも構わない。 ・ 講義終了後、15 分程度の質疑応答の時間を設けること。 ・ 講義では受講者がシステム操作を実体験できるようにすること。 ただし、本番環境以外に研修用の環境を構築するなどし、本番稼働に影響を与えずに研修を実施できるよう本学園と調整すること。 64 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ・ 講義、マニュアルに関するアンケート用紙を作成の上、講義後に受講者に回答を依頼すること。 なお、アンケート内容は事前に本学園と調整すること。 (5) 教材の作成項番(2)の教育対象に対して、操作マニュアル、運用・保守手順書、教育資料(システムの概要資料、操作動画、FAQ 等を想定)を作成すること。 詳細は教育実施計画書の策定時に、本学園と協議の上決定する。 教育資料の概要を下表に示す。 項番 資材名 資材の概要 対象者1 システムの概要資料次期システムや連携システムの概要を取りまとめた資料管理部門の職員利用部門の教職員2 操作動画 次期システムの操作方法について動画に取りまとめたもの利用部門の職員3 FAQ よくある質問やその回答を取りまとめた資料管理部門の職員利用部門の教職員・ 教育資料の作成に当たっては、情報システムやスマートフォンの操作に不慣れな者でも分かりやすいような構成、内容とすること。 ・ 利用者向けの操作マニュアル等については、サービスデザイン思考、65 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. UI/UX等の観点から、スマートフォンアプリ等の経験を有する専門のUI/UXデザイナーを体制に組み入れること。 ・ 教育資料については、本学園のレビューを経て承認を得ること。 (6) 教育訓練実施結果報告教育訓練の実施結果を教育訓練実施結果報告書にて本学園に報告し、承認を得ること。 66 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 7 データ要件本章では、次期システムにおいて取り扱うデータに関する要件について定義する。 本学園における業務及びシステムは、学生・教員・科目・履修・成績等の多様なデータを基盤として成り立っており、データの定義や管理方法は、業務の正確性、効率性、将来的な拡張性に大きな影響を与える。 現行システムにおいては、長年の制度改正や業務拡張への対応を通じて、コード体系やデータ定義が業務単位・システム単位で個別に整備されてきた(いわゆる情報・機能のサイロ化)結果、全体としての体系性や一貫性が十分に確保されていない状況が見られる。 また、基幹システムの改修コスト等の制約により、本来は基幹側で一元管理すべきデータが周辺システムに分散して管理されているケースも存在している。 次期システムにおいては、こうした課題を踏まえ、単に現行データを移行・再現するのではなく、業務要件・システム機能要件・将来構想を踏まえたデータの再整理・再定義を行うことを重視する。 特に、コード体系やマスタ定義については、長期的な利用、組織横断的な運用、将来の制度変更やデータ量増加を見据えた設計とすることを前提とする。 また、本学園では、基幹システムを中心とした閉じたデータ管理ではなく、統合DB構想を前提としたデータ連携・データ活用を進めていく方針である。 そのため、データのマスターを明確にしたうえで、他システムとの連携や将来的な分析・可視化、AI活用等にも耐えうる整合性・拡張性を備えたデータ設計が求められる。 本章では、これらの考え方を踏まえ、データ定義、コード体系、並びにデータ連携に関する要件を整理する。 提案者は、本章に示すデータ要件を十分に理解したうえで、次期システムにおけるデータ設計及びデータ連携の在り方について提案するこ67 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. と。 7.1 データ定義7.1.1 現行コード体系現行のコード体系を参考に、業務要件、システム機能要件を考慮し、設計時に決定する。 現行の資料体系にコード体系をまとめたものはないが、添付資料「現行コード定義書」に科目コードや学籍番号のコードについての説明があるので、これらの資料を参考にすること。 参照添付資料：現行コード定義書7.1.2 新コード体系現行のコード体系に加え、次期システムにおいては以下の要件を満たすこと。 各要件の末尾の[]で括られた番号は、添付資料「問題・要望一覧」の問題番号である。 (1) 科目コード体系は、長期・複数組織(複数係)利用を前提とし、体系ポリシー(桁構成・意味・採番規則)をデータとして管理できること。 ［152］(2) 将来の科目数増加に対応するため、科目コードは桁数増加や体系見直しに対応可能な拡張性を持つこと。 ［152］(3) 科目コード及び教員コード等について、異なる体系間での相互変換・マッピングが可能なコード管理方式を備えること。 ［146］68 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (4) 番組単位でのコード管理に対応し、放送システムと整合した番組コード体系を保持できること。 ［957］(5) 相手先(他大学等)について、同一相手先に対して複数の相手先コードを保持し、コード統合(同一学校単位での集約出力)が可能であること。 ［211,668,857］参照添付資料：問題・要望一覧7.1.3 新データ定義現行のコード定義に加え、次期システムでは以下の要件を満たすこと。 各要件の末尾の[]で括られた番号は、添付資料「問題・要望一覧」の問題番号である。 (1) 科目・授業・シラバス・ 科目マスタ・時間割マスタにおいて、同一として扱う科目の紐づけ及び履修制限を 設 定 ・ 保 持 で き る こ と 。 ［ 649,650 ］科目マスタ・時間割マスタは、科目コード・科目名・主任講師名等の基本情報に加え、Web/郵送区分、出題形式等の属性を保持できること［603］・ 科目(授業)に対して、字幕有無等のアクセシビリティ属性を保持できること［149］・ 時限マスタ・面接授業時間割と科目マスタ・時間割マスタ／シラバス間で、講師名・授業日程・単位数等について、どの機能・データを基準として管理するかを69 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 明確にし、相互に不整合が生じないデータ構造とすること［873,916,355］(2) 学籍・履修・成績・ 学生属性として、新入生／在学生の識別区分を保持し、発送データ等に出力可能であること［189］・ 学生属性として、学位取得志向／生涯教育志向等を判別する区分を保持できること［806］・ 前半学期の履修状況を正式データとして確定・保持するための状態区分を持つこと［30］・ 再入学者について、学生番号の再利用及び過去在籍時の成績・履修履歴を適切に引き継げるデータモデルを備えること［663,664］・ 在学生情報と卒業生情報を区分管理し、必要に応じてアーカイブ等で保管できること［904］・ 在籍・履修・成績等について、過去時点参照や証明書発行に対応できるよう、基準 日 指 定 で 参 照 可 能 な 履 歴 デ ー タ を 長 期 保 管 す る こ と［924,921,235,585,895,664,809］※ただし、証明書発行は本調達対象外(3) 人(学生・教員・職員)・ 人(学生・教員・職員)に関する氏名情報について、姓・名・ミドルネームをそれぞれ独立した項目として保持できること［800］・ 人(学生・教員・職員)に関する氏名情報について、漢字表記に加え、アルファベット表記・カタカナ表記を保持できること［750］70 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (4) センシティブ情報・学生対応・ 合理的配慮対象者情報を一元管理し、担当者限定・項目単位で参照制御可能なデータ構造を持つこと［3,7,15,21,22,118,119,425,391,8,14］・ 救済措置に関する判断内容を、判断主体・内容とともに記録・参照できるデータを保持すること［130］・ 入学前の学生(入学希望者等)を対象とした学生対応記録を登録・管理できること［138］(5) 団体・相手先・財務関連マスタ・ 団体情報をマスタ化し、団体単位での成績管理や統計に活用できること［110］・ 相手先マスタに、大学名・学部名、集団区分等の分類項目を保持できること［212,857］・ 相手先マスタに、連絡先情報(メールアドレス、担当者変更履歴等)を保持できること［455］・ 口座情報について、目的・種別等を整理した分類マスタを保持できること［162］(6) その他業務データ・文書・ 卒業研究に係る申請・履修・成績・教員情報等を次期システム内データとして一元管理できること［726］・ 教室利用予定(面接授業、委員会、サークル等)をシステム上で起票・管理できること［763］・ 著作権委員会決定事項を科目等に紐づけ、反映状態・反映日・変更履歴・時系列71 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 参照が可能なデータとして保持すること［63,444］・ 稟議書等の電子文書及び大容量コンテンツを、長期保存可能な形で保管できること［662,452］参照添付資料：問題・要望一覧7.2 データ連携7.2.1 現行データ連携要件統合DB構想を前提とし、それらを通じて他システムとデータ連携する。 ETL連携が定めるデータ形式、データ連携のタイミング、トランザクションのルールに従うものとする。 現行の他システムとの連携は、添付資料「現行外部インターフェース一覧」及び「現行外部インターフェース詳細」を参照すること。 参照添付資料：現行外部インターフェース一覧、現行外部インターフェース詳細(フォルダ)7.2.2 新データ連携要件現行データ連携要件に加え、以下の要件を満たすこと。 各要件の末尾の[]で括られた番号は、添付資料「問題・要望一覧」の問題番号である。 72 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (1) 連携方式(共通)・ 対象システム間のデータ連携を日次またはリアルタイムで実行し、連携先データを最新化できること［50］・ 異なるデータ形式・プロトコルを吸収し、データ変換及び整合性確認を自動化できる連携方式を備えること［167,601］・ 項目単位で正データ源(上流システム)を定義し、それに基づく整合的なデータ連携を実現できること［503］(2) システム別連携・ 放送システム／番組制作管理システムと、科目・番組関連データを相互連携し、自動反映できること［60,957,932］・ LMSと連携し、学生の学修状況データ(利用時期・媒体・回数等)を取得できること［934］・ LMSを搭載しているクラウドサービスと次期システム間で、オンプレミスを介さないクラウド間直接連携が可能であること［520］※ただし、LMS は本調達対象外・ シラバス修正内容を情報管理系システムと自動連携し、関連項目を双方に反映できること［485,486］・ 入試システムと次期システム間で、出願(学部)・修正・採点等のデータを手作業なしで連携できること［287,246,288,689,691,690,855］・ 外部収納業者システムと直接連携し、消込情報の自動取込・自動消込が可能であること［833］73 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ・ 授業料入金から財務会計システム連携までを一連のデータ連携として実現できること［167,163］・ 図書館システムと随時／高頻度でデータ連携し、最新情報を相互参照できること［39］・ 他大学と成績情報を連携できること［714］8 体制と役割本プロジェクトは、基幹システム刷新に加え、旧基幹システムから新基幹システムへのシステム移行及びデータ移行を含む、大規模かつ高リスクなプロジェクトである。 このため、本プロジェクトでは、設計・開発・テスト・移行・導入・運用準備を含む全工程を一体として統制し、プロジェクトマネジメント、品質管理及び運用を見据えた体制のもとで推進する。 プロジェクトにおいては、プロジェクト管理、品質管理、会議体運営、教育・運用設計及びシステム・データ移行をコスト削減の対象とせず、プロジェクト成功のための必須役務と位置付ける。 提案者は、上記方針を十分に理解したうえで、実現性・安全性を重視した体制及び役割分担を提案すること。 8.1 体制の全体像本プロジェクトにおいては、以下の考え方に基づき体制を構築する。 発注者・提案者間の責任分界点を明確化すること。 マネジメント、実行、品質管理、移行、運用準備の体制を分離すること。 74 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 会議体及び報告を通じ、進捗・課題・品質・リスクを常に可視化すること。 8.2 提案者側の移行における体制及び役割提案者は、基幹システム刷新及びシステム・データ移行を確実に遂行するため、役割・責任・意思決定経路が明確な体制を構築すること。 8.3 プロジェクト体制(プロジェクト管理)提案者は、開発・構築・移行・導入を円滑に進めるため、適切なプロジェクト管理体制を確立すること。 また、学内関係部門及び他システムとの連携調整に際しては、技術的観点を踏まえた説明・調整・支援が可能な要員体制を設けること。 8.4 体制分離の原則以下の体制は明確に分離すること。 プロジェクトマネジメント(PM／PMO)開発・構築体制品質管理体制システム移行・データ移行体制※ PMO、品質管理、移行管理担当は実作業との兼務を不可とする。 75 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 8.5 プロジェクトマネージャの役割プロジェクトマネージャは、提案者側の責任者として、全工程を統括する。 主な業務は以下のとおりとする。 (1) プロジェクト計画策定(2) 進捗・品質・リスク・課題・変更管理(3) 本学園への報告及び調整プロジェクトマネージャの要員要件は以下とする。 (1) 在籍学生数 1 万人以上の教育機関または同等規模の基幹システム更改のプロジェクト管理経験5年以上とする。 プロジェクト管理経験が10年以上の場合は(2) 保有資格(いずれか必須)・ 情報処理技術者試験(プロジェクトマネージャ)・ PMP®(PMI)(3) 望ましい要件・ プロジェクト管理経験10年以上8.6 プロジェクトリーダー(業務責任者)の役割プロジェクトリーダーは、PMのもとで複数業務領域を分担し、担当領域の実行責任を負う。 プロジェクトリーダーの要員要件は以下のとおりとする。 (1) 本プロジェクトと同規模以上の情報システムにおける設計・開発・運用・保守を含む実務経験5年以上とする。 76 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. (2) 保有資格(いずれか、または同等能力)・ 情報処理技術者試験(応用情報技術者)・ 情報処理技術者試験(プロジェクトマネージャ)・ PMP®(PMI)・ PRINCE2® Practitioner8.7 設計・構築担当技術者の役割設計・構築担当技術者は、システムの設計・構築・テスト・移行に関する技術作業を担当する。 設計・構築担当技術者の要員要件は以下のとおりとする。 (1) システムアーキテクチャ設計経験3年以上とする。 (2) 資格要件(1名以上)・ 情報処理技術者試験(システムアーキテクト)・ 情報処理技術者試験(ネットワークスペシャリスト／データベーススペシャリスト)・ AWS Solutions Architect – Professional・ Azure Solutions Architect Expert8.8 会議体の開催及び報告会議体の開催及び報告は以下のとおりとする。 ・ 定例進捗会議、工程会議、試験計画・結果判定会議を主催すること。 ・ 課題は一覧表等で管理し、検討・決定経緯を可視化すること。 77 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. ・ 重要課題・計画変更時は対策会議を開催し、承認を得ること。 ・ すべての会議について議事録を作成し、本学園の承認を得ること。 78 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 9 スケジュール(1) 導入スケジュール次期システムは、2029年4月1日からの稼働を予定しており、着手から稼働までに係る期間は契約締結後(2026年度Q4予定)よりの約27か月間を想定している。 ただし、一部の周辺システムについては、2027年1月稼働を予定している。 以下、マスタスケジュールを参照のこと。 マスタスケジュール80 / 8001_要件定義書.docx © The Open University of Japan, All rights reserved. 14 現行コード定義書15 現行外部インターフェース一覧16 現行外部インターフェース詳細(フォルダ)17 業務概念及び共通定義書18 生成AI活用に関する要求事項10.2 業務概念及び共通定義書本資料は本書の理解を補足することを目的とした参考資料である。 対象業務に関する前提条件や業務概念、用語を含む各種定義を整理したものであり、提案内容検討にあたっての業務の前提として参照すること。 参照添付資料：業務概念及び共通定義書目 次第1章 調達案件の概要.. 41.1 調達件名.. 41.2 調達の背景・目的.. 41.3 期待する効果.. 41.4 業務・情報システムの概要.. 41.5 契約期間.. 61.6 作業スケジュール.. 6第2章 調達の方式等.. 72.1 調達単位.. 72.2 関連調達案件との関係.. 72.3 調達の方式.. 7第3章 次期システムに求める要件.. 83.1 要件定義書(別紙)に基づく要件.. 83.2 業務要件.. 83.3 機能要件.. 83.4 非機能要件.. 83.4.1 移行要件.. 93.4.2 セキュリティ要件.. 93.4.3 バックアップ・リカバリ要件.. 93.5 データ要件.. 93.6 運用・保守要件.. 9第4章 作業の実施内容.. 104.1 作業内容(設計・開発フェーズ).. 104.2 成果物の範囲.. 114.3 納品期日・検収条件等.. 11第5章 提案事業者の企業情報、構築実績等.. 125.1 提案事業者の企業情報.. 125.2 提案事業者の構築実績等.. 125.3 提案事業者の保有資格.. 12第6章 作業の実施体制・方法.. 136.1 作業実施体制.. 136.2 要員の資格要件.. 136.3 作業場所.. 136.4 プロジェクト管理要領.. 146.5 システム品質保証基準.. 15第7章 遵守事項.. 167.1 機密保持.. 167.2 資料・情報の取扱い.. 167.3 遵守すべき法令・規程.. 167.4 標準ガイドライン遵守.. 16第8章 成果物の取扱い.. 188.1 知的財産権の帰属.. 188.2 著作者人格権の取扱い.. 188.3 契約不適合責任.. 18第9章 入札参加資格.. 199.1 入札参加要件.. 199.2 入札制限(利益相反等).. 199.3 再委託に関する事項.. 19第10章 特記事項.. 2010.1 前提条件・制約条件.. 20別紙一覧.. 21ステムの関係)」及び別紙3「教務情報システム調達範囲」を参照すること。 (2) 現行システムの概要現行システムは「システムWAKABA(教務情報システム)」を中心に、複数の外部システムと連携して運用されている。 各システムの詳細については別紙8「現行システム構成図」、別紙4「現行システム関連図」、別紙5「現行システム一覧」を参照すること。 (3) 次期システムの基本方針及びシステム構成の想定次期システムの基本方針は、別紙1「要件定義書 1.3 次期システムに期待すること」を参照すること。 次期システム及び周辺システムとして想定する全体構成の考え方については、現行のシステム構成に必ずしも拘束されることなく、本学園の要求事項や将来像を踏まえた最適なシステム構成について提案すること。 提案にあたっては、次期システム及び周辺システムを含めた全体の構成、各システムの役割分担、システム間の連携方式、並びにデータの管理・活用の考え方等を含め、システム全体としての整合性・合理性が確保された構成を示すことを求める。 なお、次期システムは、現行システムを単に置き換えることを目的とするものではなく、将来的なシステム追加や入替、外部サービスとの連携強化等にも柔軟に対応可能な疎結合かつ拡張性の高い構成とすることを前提とする。 次期システム及び周辺システムを含めたシステム全体構成の実現イメージは以下のとおり。 システム全体概要図第4章 作業の実施内容4.1 作業内容(設計・開発フェーズ)・ 現行システムの詳細調査・引継ぎ資料(各種設計ドキュメント、データ・マスタ資料、運用・保守資料等)の受領と確認・ 要件定義書に基づく基本設計・詳細設計・ アプリケーション開発・単体テスト・結合テスト・ 総合テスト、受入テスト(本学園を受注者が支援)・ 現行システムからのデータ移行(移行リハーサルを含む)・ ユーザ教育・操作マニュアル・運用手順書の整備・ 本番環境構築・切替作業(2029年3月)(1) 要件確認受注者は、設計・開発の実施に先立ち、別紙1「要件定義書」の内容を確認すること。 また、本学園は他の大学とは異なり、全国約8万人という多数の在学生へ遠隔教育を提供する特別な大学であることに起因し、出願処理、卒業判定処理等の同様の処理が多数発生する業務があるため、大量データを効率的に処理できる一括処理機能を設計する等、運用における業務負担へ配慮した上で設計及び開発を行うこと。 その際、内容について調整すべき事項があれば、本学園と調整の上、要件の確定及び要件定義書の修正を行うこと。 なお、軽微な誤字脱字を除く変更が生じた場合は、変更履歴に記録した上で本学園の承認を得ること。 (2) 設計受注者は、要件定義書の要件を満たすための基本設計及び詳細設計(運用設計及び保守設計を含む)を行い、成果物について本学園からの承認を得ること。 別紙1「要件定義書 6.4設計に関する要件」記載の要件を満たし、設計に係る作業を適切に行うこと。 (3) 開発・テスト受注者は、別紙1「要件定義書 6.5 開発・テストに関する要件」記載の要件を満たし、開発・テストに係る作業を適切に行うこと。 (4) 受入テスト受入テストは、本学園が受注者と共同で行うテストであり、受注者は、別紙1「要件定義書6.6 受入テストに関する要件」記載の要件を満たし、受入テストに係る作業を適切に行うこと。 (5) 移行受注者は、本調達仕様書の項番3.4.1 移行要件の要件を満たし、移行に係る作業を適切に行うこと。 (6) 引継ぎ受注者は、運用・保守を受注した事業者に対して、別紙1「要件定義書 6.7 引継ぎに関する要件」記載の要件を満たし、引継ぎに係る作業を適切に行うこと。 (7) 教育受注者は、別紙1「要件定義書 6.8 教育に関する要件」記載の要件を満たし、教育に係る作業を適切に行うこと。 第5章 提案事業者の企業情報、構築実績等5.1 提案事業者の企業情報提案事業者について、以下の情報を示すこと。 ・企業概要・企業の財務健全性・システム構築におけるパートナー企業・企業のサポート拠点5.2 提案事業者の構築実績等(1) 大規模ネットワークシステム構築実績次期システムはインターネットを介して、地理的な制約によらず学生が利用し、また面接授業等に向け学習センター等の固定的な拠点から利用されるシステムである。 このため、提案事業者は、インターネットを介した大規模システムを構築し、運用した実績が複数件あること、及び全国拠点での導入作業を並行して実施した実績があること。 (2) 教務情報システム構築実績学生数1万人以上の大学において教務システムを導入し、現在も該当システムが稼働している実績を有する事業者を選定する。 提案時に実績を証明する書類を提出すること。 ※更に、その導入実績が複数ある場合には加点とする。 (3) 教務情報システム導入稼働実績次期システムの納入にあたり、教職課程を有する国立大学法人または学校法人等に、提案する製品の納入実績があり、大学内の全学生・教職員を対象として稼働実績があること。 5.3 提案事業者の保有資格(1) セキュリティ管理情報セキュリティマネジメントシステム(ISMS)の認証(JIS Q 27001 / ISO/IEC 27001)を取得しており、情報セキュリティ管理体制が整備されていることを証明できること。 (2) 品質マネジメント資格品質マネジメント資格(ISO9001)を取得していること。 また、品質保証に向けて本作業に従事する部門以外に品質保証部門を有し、全社組織として品質確保に向けた体制を構築していること。 ※更に、品質保証を的確に行う方法論や手段・ツール等が整備されている場合は、加点する。 6.4 プロジェクト管理要領本プロジェクト開始に先立ち、プロジェクト実施計画を策定、プロジェクト実施計画書を作成し、本学園に承認を得た上で、作業を実施すること。 なお、フェーズの区切り等で、本プロジェクト実施計画書にそって進捗状況や、計画変更が生じた場合の変更内容・変更理由について、報告の上、本学園の承認を得ること。 以下に主要な管理項目の管理方法については、管理対象、管理方法等の一例として定めたが、記載のない事項等については提案すること。 ・ 進捗管理実施すべき全ての作業は具体的に進捗状況を把握できる単位まで詳細化し、階層構造で表したもの(WBS)及び定量的に状況が把握できる手法にて進捗管理を行うこと。 進捗状況は進捗会議等で定期的に報告すること。 具体的な進捗管理方法は、プロジェクト実施計画書の策定時点で、プロジェクトの特性に合わせて本学園と協議の上、決定すること。 受注者と本学園、担当部署間でプロジェクト管理ツール等を共有する提案についても、妨げない。 費用は原則として受注者の負担とするが、当該ツールのライセンス等を本学園が保有する場合はその限りではない。 利用する各種管理ツールの詳細は契約後協議の上、決定する。 ・ 課題管理解決するべき課題・問題は、再発防止に生かすことも含めて、項目ごとに進捗等を管理し、適切に解決していくこと。 ・ リスク管理リスクの洗い出しを行い、リスク内容を判別した上で、各リスクの発生頻度、影響度、対応策(低減、受容、転換、回避等)、責任等を、監視・管理すること。 ・ 情報セキュリティ対策「第7章 遵守事項」の要件を満たすように実施すること。 ・ 品質管理品質管理について、次の事項を明確にし、実施すること。 ➢ 品質管理方針事前に各工程において品質目標及び工程完了基準を設定すること。 成果物に対して適切な検証活動を実施の上、結果について分析を行うこと。 分析結果から抽出した対策の立案と実施を行うこと。 ➢ 品質管理方法各工程の完了に伴いレビューを実施し、品質基準との差を把握すること。 品質の自己評価を実施し、本学園の承認を得ること。 ・ 構成管理/変更管理構成管理/変更管理について、管理手順を明確に記載すること。 本学園と合意した最新の状況を適時に各種ドキュメントへ反映すること。 設計書等のドキュメントとソースコード等の実装結果に差分が発生しないよう管理を行うこと。 ・ 問合せ管理業務を遂行する中で、本学園から受注者に対する指摘や確認事項等について、適切に管理し、着実に対応すること。 ※作業進捗の報告等作業の推進方法、方針の確認、修正及び進捗状況確認等、作業進捗の報告で必要な書類を作成し、週1回程度の報告を行うこと。 報告は原則としてオンライン会議での実施とするが、本学園から要請があった場合、または、受注者が必要と判断した場合は、本学園と受注者で協議の上、対面で開催すること。 また、別途本学園が報告を求める場合においては、本学園が指示する必要な書類を加えること。 詳細はプロジェクト実施計画書の作成時に本学園と協議の上、決定すること。 なお、報告にはプロジェクトマネージャが出席すること。 また、本学園が求める場合は、必要に応じて、参画しているメンバー(品質管理責任者や業務担当等)を参加させること。 6.5 システム品質保証基準プロジェクト実施計画書で品質保証基準と品質評価方法を定め、システム品質を担保する必要がある。 次期システムにおける品質保証基準を検討し、構築実績に基づき、確実で高品質なシステムを構築するための評価方法を提案すること。 ・ 設計工程：設計書作成要領、レビュー実施方法、品質データの取得法、品質評価方法等・ 開発工程：開発標準(コーディングルール、ソース管理方法)、レビュー実施方法等・ テスト工程：各テスト設計書作成要領、品質メトリクスの収集方法、品質評価方法等各工程における品質評価方法については、以下に評価方法概要を定める。 (1) 各工程に共通の品質評価・ 定量評価の基準値や定性評価の評価方法等は、本学園と協議し承認を得ること・ 各工程の完了報告書に品質評価を含め、別途プロジェクト実施計画書で定めた完了報告の様式やルール等に従い、各工程で完了報告を行うこと(2) 設計工程の品質評価基本設計工程では基本設計書に要件定義書の機能要件、非機能要件が反映されているかを確認し、また基本設計書作成に関わるレビュー時間や設計内容の間違いの指摘数等を数値化し定量評価を行うこと。 設計内容の間違い原因を分類(仕様理解不足、記載漏れ等)しその傾向を定性評価すること。 詳細設計工程では基本設計書が定義した機能要件、非機能要件が詳細設計書に反映されているか、詳細設計書を基にモジュール作成が可能か、設計書の記載粒度や精度を満たしているかを確認し、基本設計と同様に定量評価と定性評価を行うこと。 (3) 開発(製造・単体テスト)工程の品質評価製造・単体テスト工程においては、製造されるモジュール(自動作成されるモジュールを含め)が開発標準に沿って製造されているかを確認すること。 詳細設計書で定義した機能が、抜け漏れや間違いなく製造されているかを確認すること。 単体テストの結果より、単体テストで検出されたバグの原因を分類しその傾向を分析し定量評価と定性評価を行うこと。 開発標準違反については、横並び確認で同種の違反が他モジュールに存在しないか水平展開で確認し、是正すること。 (4) テスト工程の品質評価テスト工程においては、各テスト工程(結合テスト、総合テスト、受入テスト)開始前に品質評価計画を含めテスト計画書を作成、各工程完了時に、定量評価と定性評価を工程完了報告書に含め報告を行い、別途定めて各工程の完了基準が満たされていることを確認する。 テストフェーズの品質評価において、欠陥の混入工程とすり抜け工程を特定する原因分析は重要な分析項目となるため、品質メトリクス(バグ密度、テスト密度等)の選定とその収集方法(ツール導入等)の検討も十分に行うこと。 第7章 遵守事項7.1 機密保持受注者は、本業務の遂行により知り得た本学園の情報(学生個人情報を含む)について、厳重に秘密を保持し、本業務の目的以外に使用または第三者に開示・漏洩してはならない。 契約期間終了後も同様とする。 7.2 資料・情報の取扱い・ 本学園から提供される資料・データは、本業務の目的のみに使用すること・ 業務終了時には、提供資料・複製物をすべて返却または廃棄し、書面で報告すること・ 個人情報の取扱いは個人情報保護法及び本学園の個人情報保護規程に従うこと・ システム開発に使用するデータは、本番データを使用せず原則として匿名化・マスキングしたテストデータを使用すること7.3 遵守すべき法令・規程・ 放送大学学園法・ 個人情報保護法・放送大学学園個人情報保護規程・ 情報セキュリティ基本方針(本学園規程)・ 著作権法・産業技術力強化法・ その他適用される関連法令・規程7.4 標準ガイドライン遵守受注者は、作業実施に当たり、「デジタル・ガバメント推進標準ガイドライン」(2024年5月31日デジタル社会推進会議幹事会決定。以下「標準ガイドライン」という。)の内容を遵守すること。 契約期間中に標準ガイドラインが改定された場合は最新の版を参照し、本学園と協議の上、対応について決定すること。 受注者が作成する「プロジェクト実施計画書」には、標準ガイドライン「第 3 編第 7 章 1. 1)設計・開発実施計画書の記載内容」に基づき、次に掲げる事項を含めること。 ・ 作業概要・ 作業体制・ スケジュール・ 成果物・ 開発形態、開発手法、開発環境、開発ツール等・ その他(前提条件・制約条件)受注者が作成する「プロジェクト実施計画書」には、標準ガイドライン「第 3 編第 7 章 1. 2)設計・開発実施要領」の記載内容に基づき、次に掲げる事項を含めること。 ・ コミュニケーション管理・ 体制管理・ 工程管理・ 品質管理・ リスク管理・ 課題管理・ システム構成管理・ 変更管理・ 情報セキュリティ対策本業務において作成する成果物、提出物は、成果物に係る納品期限によらず、作業進捗に応じた適切なタイミングで本学園に提出すること。 提出した内容に変更があった場合は、変更の事由が生じた都度、再度提出し、本学園の承認を得ること。 第8章 成果物の取扱い8.1 知的財産権の帰属本調達において、本学園に特化して新規開発したモジュール及び継続的な機能改修が見込まれるものについては、原則として知的財産権を本学園に帰属させる。 ただし、受注者が従前から保有するコンポーネント・ツール等については、この限りではない。 受注者は、本学園に帰属する成果物について、本学園が不利にならない条件のもとで受注者による利活用を認める。 8.2 著作者人格権の取扱い受注者は、本業務により作成した成果物について、著作者人格権を行使しないものとする。 これは、本学園が成果物の機密確保や改変の自由を担保するために必要な措置である。 8.3 契約不適合責任受注者は、納品・検収した成果物が本仕様書・要件定義書に適合しないことが検収後に発覚した場合、本学園の請求に基づき無償で修補を行う義務を負う。 責任期間・範囲・分界点については契約書に別途定める。 第9章 入札参加資格9.1 入札参加要件入札参加者は以下の要件を満たすこと。 入札参加機会の拡大のため、下位等級者の参入や複数事業者による共同提案も認める。 ・ 日本国内に主たる事務所を有する法人であること・ 「5.2 提案事業者の構築実績等」の条件を満たすこと・ 「5.3 提案事業者の保有資格」の条件を満たすこと・ 入札公告日時点において、本学園から取引停止処分を受けていないこと9.2 入札制限(利益相反等)以下に該当する者は本調達の入札に参加できない。 ・ 本調達仕様書の作成に直接関与した事業者(調達支援事業者を含む)・ 本調達のプロジェクト管理支援(PMO支援)業務の受注者・ 現行システムのシステム監査業務の受注者※ ただし、本学園が競争上有利とならないことを確認した場合はこの限りでない。 確認を求める場合は、事前に本学園に申し出ること。 9.3 再委託に関する事項業務の再委託は原則として禁止する。 やむを得ない事情により再委託が必要な場合は、以下の条件のもとで本学園の事前承認を得ること。 ・ 再委託する合理的理由が明確であること・ 再委託先が当該業務を履行する技術的能力を有すること・ 再委託先も受注者と同等の守秘義務・個人情報保護義務を負うこと・ 基幹的な作業の大半を再委託しないこと第10章 特記事項10.1 前提条件・制約条件・ 次期システムは2029年(令和11年)4月1日の運用開始を厳守すること・ 現行システムの運用を停止することなく並行稼働期間を設けること(期間は受注者と別途協議)・ 本学園の要求事項や将来像を踏まえ、システム構成に最適なインフラを提案すること。 その際、現行システムからの移行が容易である理由についても明記し、書面にて説明すること。 ・ 特定の事業者のみに開発・運用保守が限定される構成としない提案にすること・ 市場の標準仕様・流通製品を最大限活用し、カスタム開発を最小化することこれ以降、非公表とさせていただきます。 仕様書は、学園にて配布しております。 ※別紙の配布にあたっては、事前に本学園と別紙取得希望業者とで NDA(秘密保持契約書)の締結が必要となりますので、早めにご準備をお願いします。 問い合わせ先：youdo1@ouj.ac.jp(経理課用度第一係)