NUMO-TR-10-12

地層処分の要件管理技術

2011 年 3 月
原子力発電環境整備機構

2011 年 3 月 初版発行
本資料の全部または一部を複写・複製・転載する場合は，下記へ
お問い合わせください。
〒108-0014 東京都港区芝 4 丁目 1 番地 23 号 三田 NN ビル 2 階
原子力発電環境整備機構 技術部

2011 年 3 月
原子力発電環境整備機構

電話 03-6371-4004（技術部） FAX 03-6371-4102

Inquiries about copyright and reproduction should be addressed to:
Science and Technology Department
Nuclear Waste Management Organization of Japan
Mita NN Bldg. 1-23, Shiba 4-chome, Minato-ku, Tokyo 108-0014 Japan©原子力発電環境整備機構（Nuclear Waste Management Organization of Japan） 2011

NUMO-TR-10-12

地層処分の要件管理技術

2011 年 3 月
原子力発電環境整備機構

目 次

1 はじめに ........................................................................ 12 要件と要件管理 ................................................................. 3
2.1 一般的なプロジェクトにおける要件管理 ......................................... 3
2.1.1 ソフトウエア開発における要件管理.......................................... 3
2.2 品質マネジメントと要件管理 ................................................... 53 地層処分事業における要件管理法の調査と検討 ................................... 6
3.1 地層処分事業の特徴からみた要件管理 ........................................... 6
3.1.1 地層処分事業における要件管理の考え方...................................... 6
3.1.2 地層処分事業の要件管理が対象とする要件の種類.............................. 7
3.1.2.1 法令などの要件 ....................................................... 7
3.1.2.2 地層処分の安全確保の要件 ............................................. 7
3.1.2.3 地層処分事業のマネジメントの要件...................................... 7
3.2 各国の要件管理への取り組み ................................................... 8
3.2.1 スウェーデン ............................................................. 8
3.2.1.1 要件管理と要件管理システムの内容...................................... 8
3.2.1.2 SKB の調査結果のまとめ ............................................... 11
3.2.2 フィンランド ............................................................ 11
3.2.2.1 要件管理と要件管理システムの内容..................................... 11
3.2.2.2 POSIVA の要件管理に関する調査結果のまとめ ............................ 12
3.2.3 スイス .................................................................. 12
3.2.3.1 要件管理と要件管理システムの内容..................................... 12
3.2.3.2 Nagra の要件管理に関する調査結果のまとめ ............................. 13
3.2.4 ベルギー ................................................................ 13
3.2.4.1 要件管理と要件管理システムの内容..................................... 13
3.2.4.2 ONDRAF/NIRAS の調査結果のまとめ ...................................... 14
3.3 各国の要件管理のまとめ ...................................................... 15

4 NUMO における要件管理法の検討 ................................................. 16
4.1 要件管理の進め方 ............................................................ 16
4.1.1 要件管理業務 ............................................................ 16
4.1.2 段階的な要件の定義 ...................................................... 17
4.2 要件管理の要素 .............................................................. 18
4.2.1 意思決定・業務 .......................................................... 18
4.2.2 前提条件 ................................................................ 18
4.2.3 要件 .................................................................... 19
4.2.4 論拠 .................................................................... 19
4.3 要件の定義と階層化の方法 .................................................... 22
4.4 地層処分事業における要件管理システムの適用方法の検討......................... 23
4.4.1 要件の体系的な管理 ...................................................... 23i4.4.2 スケジュール，技術開発計画の管理......................................... 23
4.4.3 文書などの記録管理 ...................................................... 23
4.4.4 品質マネジメント ........................................................ 23
4.4.5 変更管理 ................................................................ 24

5 ソフトウエアの開発 ............................................................ 25
5.1 システム開発要件（ソフトウエア要件） ........................................ 25
5.1.1 情報の記録・管理に関するソフトウエア要件................................. 25
5.1.2 情報活用に関するソフトウエア要件......................................... 26
5.1.3 システム形態および製作に関するソフトウエア要件........................... 27
5.2 システム機能 ................................................................ 28
5.2.1 データ管理 .............................................................. 28
5.2.2 要件の登録機能 .......................................................... 29
5.2.3 要件の検索・閲覧機能 .................................................... 29
5.2.4 変更管理に関する機能 .................................................... 30
5.2.5 工程管理に関する機能 .................................................... 30
5.2.6 品質マネジメントに関する機能 ............................................ 31

6 おわりに ....................................................................... 32
参考文献 ......................................................................... 33
付録
付録-1 要件管理システムの機能について.......................................... 付－1

ii

図目次
図 3-1 要件の種類 ................................................................ 9
図 3-2 要件の階層を含む V モデル ................................................. 10
図 4-1 要件管理業務の各フェーズにおける業務内容と流れ............................ 17
図 4-2 実務システム開発における DCRA モデルの構造................................. 18
図 5-1 要件管理システムの機能構成 ............................................... 28
図 5-3 検索・閲覧用ユーザーインターフェース...................................... 30
図 5-4 意思決定手順の作成 ....................................................... 31
表目次
表 4-1 要件管理業務のフェーズの説明 .............................................. 16
表 4-2 要件に関する論拠の整理の例 ............................................... 20
表 4-3 高レベル放射性廃棄物の安全機能と構成要素の関係（NUMO，2011b） ............. 22
表 5-1 主要データ一覧 ............................................................ 29iii

1 はじめに地層処分事業では，概要調査地区や精密調査地区の選定などの最上位の意思決定から，サイト地
質環境評価，処分場設計・性能評価などの細分化された意思決定まで，さまざまな意思決定を実施する。最上位の意思決定においては，技術的事項を総合的に判断するのみならず，ステークホルダ
ーの意見や各関係組織の意見など，さらには，社会的事項も含めて総合的に行われることとなる。
サイト環境条件や工学技術・性能評価技術に関する「情報」から NUMO の意思決定を進める過程においては，さまざまな「要件」が考慮される。例えば，個別の情報を用いたサイト候補地の適合性に関する評価や，地下施設設計の具体的な意思決定（判断），あるいはこれら個別の決定要素を組み合わせたサイト特性の総合評価や処分場全体の設計といった上位の意思決定において，それぞれに関連する「要件」が考慮される。
このような「要件」と「情報」の組み合わせによる「意思決定」の構造をあらかじめ把握し，「要件」，「情報」および「意思決定事項」を同時に管理することにより，NUMO の意思決定について，一貫性や追跡性を確保することが可能となる。また，社会経済的条件の変化や技術開発の進展など
による「外的な条件」の変化にも，「要件」や「情報」の変更を確実に業務や意思決定に反映することにより，柔軟に対応する（NUMO，2007）。
地層処分の目標は，閉鎖後長期の安全確保と事業期間中の安全確保である（NUMO，2011a）。これらの目標に基づいて詳細化した要件を，実際のサイト選定や処分場の設計，安全評価に展開し，業務を実施することで，着実に地層処分の安全性を確保していく。NUMO では，第 2 次取りまとめ（JNC，1999）にまとめられた要件を出発点とし，最近の国際的な安全要件に関する報告書や安全規制の考え方も取り入れて，幅広い地質環境に対応して地層処分の安全性を確保するための要件を，
本書とは別に「処分場の安全機能と技術要件」（NUMO，2011a）に取りまとめている。また，これらの要件を処分場の設計に適用する考え方を NUMO（2011a）に記述し，安全評価への適用については，「地層処分事業のための安全評価技術の開発（I）－シナリオ構築技術の高度化－」（NUMO，
2011b）に記述している。本書で述べる要件管理技術は，安全機能や技術要件を体系的に管理することで，上記に示した処分場の設計や安全評価の業務を支援することを第一の目標としている。
NUMO では，地層処分事業における要件管理技術およびその支援システムとして要件管理システ
ムの開発を進めてきた（NUMO，2007，Suzuki et al.，2008，2010a，2010b）。要件管理では，意思決定を階層的に捉え，その階層的な構造の中で，意思決定事項，要件，要件を充足するための論拠がどのような相互関係を有しているかを分析する。要件管理システムは，これらの情報を体系的に管理し，また，必要な時に必要な情報を検索し，意思決定の場に提供することを支援するためのシステムである。
要件管理技術の開発は，海外の実施主体においても取り組みが進んでいる（OECD/NEA，2004）。
そこで，NUMO は地層処分の要件管理に取り組む実施主体を招いて，2010 年 1 月に国際情報交換会「RMS2010 Requirements Management Systems（RMS）：Status and Recent Developments」（RMS2010
要件管理システム（RMS）：現状と開発動向）をスイス Nagra 社の協力のもとで開催し，SKB，Nagra，
POSIVA，ONDRAF/NIRAS および一般産業における要件管理に対する取り組みの現状とシステムの開発動向について情報交換を実施した。また，この情報交換会では，日本原子力研究開発機構が開発した「知識管理システム」（JNC，2005）についても，要件管理システムにおける知識基盤としての利用方法について意見交換した。なお，これらの国際情報交換会の詳細な内容については，NUMO
1

（2011c）に取りまとめた。
本書では，NUMO の実施している要件管理技術の開発について取りまとめた。第 2 章では，ソフ
トウエア開発を含む一般的な産業界における要件の定義と，プロジェクトにおける要件管理について記載した。また，プロジェクトにおける品質マネジメントの内容を考慮して，要件管理と品質マ
ネジメントの関連について記載した。第 3 章では，地層処分事業の要件管理の方法について記載した。最初に地層処分事業というプロジェクトの特徴を踏まえて，処分事業における意思決定と要件の関連をまとめた。次に各国の処分事業実施主体の要件管理に関する取り組みについてまとめた。
第 4 章では，さらに，要件管理の対象となる情報を区分し，NUMO の将来の業務に関する業務分析を行った上で，ソフトウエアとしての RMS の開発要件と機能についての検討成果と構築した RMSの機能について記載した。

2

2 要件と要件管理
2.1 一般的なプロジェクトにおける要件管理
要件は，プロジェクトにおいて重要な役割を果たす。プロジェクトとは，「特定の目的（仕様）の最終成果物を，指定期間（納期）内，指定資源（予算）内にて完成させる，繰り返し性の少ない人間活動」であり，要件とは，「プロジェクトが成功するための必要な条件，欠くことができない条件」
である。
繰り返し性の多い人間活動としては，用途や構成などがすでに一般化された製品の製造がある。
例えば，「コーヒーカップ」については，すでにその形状や用途が一般に広く認識されており，これについて，改めて要件を明確にする必要性はない。これに対し，プロジェクトでは，繰り返し性が少ないために，その用途や構成について共通の認識がない。そのため，まず，プロジェクトの関係者（例えば，後述する依頼者と開発者）の間で共通の認識を構築するところから始まる。この共通の認識が要件であり，共通の認識を構築する行為を「要件定義」と呼ぶ。
要件管理は，ソフトウエア開発を始めとする製品の開発で用いられることが多い。ソフトウエアの多くは，依頼者（ユーザー）の要求に合うように，開発を進めるが，汎用ソフトウエアを除けば，その用途や機能構成は固有である。そのため，単純な繰り返し作業で開発することは難しく，先述のプロジェクトの代表例である。そのため，ソフトウエア開発では，要件管理に関する多くの専門書が出版されており，その方法論はよく検討されている。次項では，これらのソフトウエア開発を例として要件管理方法を概説する。
2.1.1 ソフトウエア開発における要件管理
ソフトウエア開発業界における要件管理は，大きく分けて，要件定義と変更管理という二つの要素から構成される。要件定義とは，ソフトウエアに要求されている要求，さらに実際にソフトウエ
アに実装する機能を明確にする作業のことである。要件定義は一般に，開発者側と依頼者側（顧客・ユーザー）の双方の協力により定義が行われる。その成果は「要件定義書」としてまとめられる。
開発を始める前に行う作業であるが，ソフトウエアの製造過程において最も重要なプロセスのひとつである。要件定義を十分に行うことにより，開発後のトラブルや開発途中での仕様変更などのリスクを低減させることができる。要件定義に対して，依頼者（顧客・ユーザー）の要求をまとめる
作業を「要求定義」と呼び，「要求定義書」が作成される。まとめられた要求を実現するために要件定義が行われ，それを元に開発の工数や費用の見積もりが行われる。
開発プロセスには，「ウォータフォール方式」と「スパイラル方式」がある。
「ウォータフォール方式」においては，「要件定義」は最初に行われる作業工程である。続いて「設計」，「プログラミン
グ」
，
「テスト」
，
「運用」という作業工程に移る。ウォータフォール方式は各作業工程に成果を検証し，承認を経て次の工程へと進むモデルであることから，前の工程に簡単に逆戻りできずフィード
バックができないという構造的な問題点がある。従って，要件定義には時間をかけ，しっかりと要件定義書を作成する必要がある。近年，スパイラル方式にてソフトウエア開発を実施する開発モデルも見られるようになった。その場合は，ウォータフォールモデルよりも要件定義に書ける時間（コスト）は比較的低減されるが，その分変更管理に係る比重が大きくなる傾向がある。
変更管理とは，変更に伴うリスクを事前に想定して対策を講じ，障害や不具合，事故，変更失敗
3

などを防止するマネジメント活動のことを指す。一般業務やプロジェクトでは，その計画・手順・設計・運用を意図的に変更する場合がある。このような変更は意図的・計画的なものであっても，一般に想定外の事象（事故や不具合）を引き起こすリスクが高い。そこで変更に伴うリスクを低減
し，影響を最小限に抑え，かつ，正確に変更が行われるようにマネジメントする活動が変更管理である。

4

2.2 品質マネジメントと要件管理
品質マネジメントシステムの国際標準である ISO9001 シリーズ（日本規格協会，2009）は，顧客の要求事項を満たすことによって顧客満足を向上させる，顧客重視の品質マネジメントシステムである。ISO では，製品に関連する要求事項を明確化し，要求事項を満たす製品を実現するための計画を立て，製品の合否判定基準を定めて監視および測定により製品に対する要求事項への適合を実証することが求められている。このことから，要件（顧客の要求事項を開発者側で定義したもの）
は品質マネジメントシステムを構成する重要な一要素であり，要件管理は品質マネジメントの活動の一部として実施していくべきものである。ここでは，ISO での要求事項の定義と，その管理に関して求めている活動を述べる。
ISO では，要求事項の定義を「明示されている，通常，暗黙のうちの了解されている若しくは義務として要求されている，ニーズまたは期待」とし，要求事項には「顧客が規定した要求事項」，「顧
客が明示してはいないが，指定された用途または意図された用途が既知である場合，それらの用途に応じた要求事項」，「製品に適用される法令・規制要求事項」，「組織が必要と判断する追加要求事
項すべて」が含まれるとしている。
「顧客が規定した要求事項」とは，文書に規定された，顧客と約束した製品の仕様である。
「用途に応じた要求事項」とは，製品の用途から考えて必須の項目，顧客があえて指定しない常識的な項目や，顧客が特定できない製品などの仕様も含まれる。
「法令・規制要求事項」は，政府や自治体などの行政が決めた法令や行政指導に加えて，政府や自治体などの行
政さらには事業団体，協会などが決めた規制などがあり，コンプライアンスの観点からも，自組織にかかわる法令・規制要求事項をしっかりと把握し，対応しておくことが必要となる。
「組織が必要と判断する追加要求事項すべて」は，必須ではないが自社の考えで必要とするものであり，具体例
として環境対策や，より安全な原材料の仕様，
アフターサービスの充実などが例として挙げられる。
以上を要約すると，要件管理の方法論は，一般産業分野ですでに実務に活用されており，顧客（ステークホルダー）の要求事項を，プロジェクトにおいて要件として，どう定義するかという課題がプロジェクトを成功させる上で重要な要素を占めている。また，品質マネジメントとの関係においては，要件（顧客の立場では要求事項）を満たし，顧客が満足する製品を作るかという点で，要件は，品質マネジメントの重要な要素である。一方，要件は必ずしも顧客から規定されたものだけでなく，顧客のニーズを踏まえて，受注者が自主的に定める要件（要求事項）などもあり，それらをすべて含めて要件としている。
次章では，ここまでに示した要件管理の考え方と関連付けながら，地層処分事業における要件管理の方法論について述べる。

5

3 地層処分事業における要件管理法の調査と検討
3.1 地層処分事業の特徴からみた要件管理
3.1.1 地層処分事業における要件管理の考え方
第 2 章に記載したように，プロジェクトの一般的な定義は，「特定の目的（仕様）の最終成果物を，指定期間（納期）内，指定資源（予算）内にて完成させる，繰り返し性の少ない人間活動」である。
この定義を考えた場合，地層処分も典型的なプロジェクトとしての特性を備えている。
地層処分は，
今後サイト候補地の調査に始まり，幅広い科学・技術の知見を活用して，さまざまな検討や活動を行う長期にわたるプロジェクトとなる。地層処分プロジェクトに携わるスタッフおよびさまざまな
ステークホルダーが共通認識を継続して事業を遂行するために要件管理は有用である。
地層処分事業は以下のような特徴を有する。
① 地層処分事業は調査から事業廃止までに約 100 年を要するものと計画されており，一般的な他のプロジェクトや大規模土木建設事業と比較しても事業期間が長い。
② 地層処分施設の建設・操業は，今後本格的に立ち上がる業務であり，プロジェクトの要件が一般化されていない。
③ 地層処分では段階的に事業を進めることが，国際的な共通認識となっている。
④ 地層処分事業では，より高い信頼性，安全性，経済性の観点から，今後の技術開発成果を取り入れて，事業を進めることとなる。
⑤ 事業の長期性とさまざまな関係者の関与にも鑑みて，種々の事業環境の変化が考えられる。
⑥ 処分事業には情報の追跡性と透明性が求められる。
⑦ 処分事業において適切な品質マネジメントの遂行が求められる。
上記のような特徴から地層処分事業に要件管理を適用する場合においては，以下の観点が重要と考える。
①，②および⑥の観点から；長い事業期間にわたって，安全確保や工学的実現の面から首尾一貫した考え方を持つために，要件を定義し一般化しておくこと。また，各要件間の横断的な関係が分かること（体系的整理）。
①，②および③の観点から；段階的に事業を進めるために，各段階で充足すべき要件や行うべき活動を明確に把握していくこと（工程計画の管理）。
③および④の観点から；技術開発の達成時期と達成レベルとしての要件の充足基準を明確にしていくこと（技術開発計画の管理）。
①，③および⑤の観点から，前提条件の変化（法令／規制機関の指針の変更ならびに地質データの取得による地下環境特性）による要件の見直しや新規要件の追加を反映して，柔軟に対応すること（変更管理）。
①，⑤および⑥の観点から，記録を体系的に長期間保管すること。
（長期記録管理）。
②，⑥および⑦の観点から，要件を設定し，さらにその要件が満たされていることの記録管理（品質マネジメント）。

6

3.1.2 地層処分事業の要件管理が対象とする要件の種類事業を推進していく上で考慮すべき要件は多岐にわたる。例えば，地域住民などからの要求や利害関係者から事業に対する理解を得るために必要な条件，
安全･確実に地層処分事業を進めるための
NUMO および処分場に求められる要求事項などがある。地層処分事業に関する要件を法令などの要件，地層処分の安全確保の要件，地層処分事業のマネジメントの要件にわけて，その特徴について述べる。
3.1.2.1法令などの要件「特定放射性廃棄物の最終処分に関する法律」（以下，最終処分法）や事業の推進において関連する法令，地域の自治体が定める規制・条例，安全確保のために法律とは別に制定される規制，安全審査指針，処分場の技術指針，最終処分に関する国の基本方針・計画（スケジュールを含む），原子力委員会や原子力安全委員会などの方針，監督官庁や規制当局からの制約条件も NUMO にとっては重要な「要件」となる（NUMO，2007）。
3.1.2.2地層処分の安全確保の要件
地層処分の安全確保の対象は，地層処分場を受け入れていただく地域住民の方の安全と処分事業に携わる作業従事者の安全である。地層処分の安全確保の目標は，放射性廃棄物が処分場閉鎖後の
遠い将来にわたって人間とその生活環境に有意な影響を及ぼさないようにすることであり，同時に閉鎖完了までの事業期間中において地域住民や作業従事者の安全を確保することである。
すなわち，
NUMO が進める地層処分事業における安全確保とは，｢閉鎖後長期の安全確保｣と｢事業期間中の安全確保」の二つの目標を達成することである（NUMO，2011b）。従ってこれらの目標は安全確保上の最上位の要件となる。これらの要件については，両立性も十分に検討する。要件を達成するための事業期間中の安全確保のために講じるさまざまな対策（例えば，建設段階での止水対策など）は，長期的な安全確保策との両立性を図ることが必要である。すなわち，事業期間中の安全確保のために講じる対策により，閉鎖後長期の安全機能を有意に損なうことがないように十分配慮する。これ
らの要件は，上記の法令などの要件とも関係がある。
3.1.2.3地層処分事業のマネジメントの要件
地層処分事業を推進する上では，事業の段階ごとのマイルストーンや処分費用なども要件の要素となる。例えば，処分費用の観点からは拠出金を有効に活用し，経済性を確保するよう事業展開を進めることも重要な要件である。また，事業が長期間にわたることから計画的な人員の確保，地層処分を支える技術の確保なども要件となる。

7

3.2 各国の要件管理への取り組み
海外の実施主体でも要件管理および要件管理システムの開発に取り組んでいる。そこで，本節では，スウェーデンの SKB，フィンランドの POSIVA，スイスの Nagra，ベルギーの ONDRAF/NIRASの協力を得て，要件管理の開発状況やシステムの利用状況について調査した結果を取りまとめる。
さらに，2010 年 1 月に上記の実施機関に呼び掛け，国際情報交換会を開催し，各国の実施機関が開発している要件管理システムの開発目的と開発状況について情報を交換し，目的に応じた要件管理システムの機能や今後の開発事項についても議論を行った。なお，その内容については NUMO
（2011c）に取りまとめた。
3.2.1 スウェーデン
スウェーデンでは，2000 年代の前半から要件管理システムの構築が始められた。特に 2005 年以
降は，サイトデータ，性能評価，および設計前提条件（Design premise）のフィードバックを考えて，要件管理を明確に処分事業に取り込んできた。現在に至るまで，要件の整備，要件管理の業務への適用範囲と適用方法および要件管理システムの改良に関して開発作業を進めている。
3.2.1.1 要件管理と要件管理システムの内容（1） 要件の定義
SKB の要件管理システムにおける要件の定義は，以下のとおりである。
・ 充足されるべき問題や必要性
・ 受容可能な機能や特性・ 解決策を立てるべき負荷や状態
これらの要件は，最も適切な解決策の選定に至るガイダンスを設けている。
（2） 要件の利用要件は，以下に示すコミュニケーション，設計および品質保証の三つの観点から利用される。
・ コミュニケーション：大きなシステムと長期のプロジェクトを把握することは難しい。体系の複雑さ，機能，設計を踏まえて，整理して記述された要件は理解を容易にする。
・ 設計：要件と解決策の明確で適切な関係，さらに好ましい機能や特性に関する要件の構造は，設計者が最も重要な問題に対処することを容易にする。優先順位を明確にした要件は最適化の前提条件であり，リスク評価のためにも重要である。正しく整えられた要件およびその他の設計上の前提は変更を行なうことおよびそれらの影響関係に対する理解を容易にする。
・ 品質保証：適切に記述され配置された要件は品質保証の重要な一部である。プロセスと成果は要件により定量化され管理される。要件は外部要因，開発および（処分）システムの改良により断続的に変化する。要件および解決策の文書化はシステム開発における追跡可能性を与える。
（3） 要件の種類
図 3-1 に SKB が考える要件の種類を記載する。それらの異なる要件は問題領域および解決策領
8域という独立した領域に区分される。図 3-1 では要件が，Stakeholder requirements（ステークホルダ
ー要件），System requirements（システム要件），Design requirements（設計要件）の 3 種に分類されている。なお，後の記述では，これらのうち System（システム要件）がさらに Sub-system requirements（サブシステム要件）に階層化される。
・ ステークホルダー要件は，Problem domain（問題領域）に属し，システム要件および設計要件は，Solution domain（解決策領域）に属する。問題領域では，ステークホルダー要件は問
題の内容や対象範囲を規定する。SKB では，主要な上位のステークホルダー要件として，法令を考慮している。
・ 解決策領域に属するシステム要件および設計要件のうち，システム要件は地層処分システムの概念に対応する要件である。システム要件はどのように問題が解決されるかを示すためのものである。System concept（システム概念）は，ステークホルダーの要望を満足する機能や特性を定義する際に必要なものである。機能と特性は設計の基礎として必要である。
・ 設計要件は Specific solution（個別の要件の解決策）に対応する。これらの解決策に対応するものとして設計仕様が決定される。設計要件は機能を満足するための設計を特定するものである。

Problem domain

Solution domain

Problem definition- Needs- Scope

System concept

Specific solution

Stakeholder
Requirements

SystemRequirements

DesignRequirements

図 3-1 要件の種類（OECD/NEA，2004 より引用）（4） 要件の階層
図 3-2 に SKB が考える要件の階層と要件管理システムの構造を示す。V モデルは要件管理シス
テムのソフトウエア開発において利用されていたモデルであるが，要件管理の階層を説明するためにも利用可能である。図 3-2 左側の Need-problem（ニーズおよび問題）の側の設定に関しては，上部にステークホルダー要件を特定して位置付けることから出発する。これらのステークホルダー要
件はシステム要件，サブシステム要件，さらに設計要件に詳細化され階層化される。下層の要件がすべて満足されることによって，より上層の要件が満足されるという構造を考えている。一段階で9

の判断が難しい複雑な意思決定事項は，それを，下位のいくつかの意思決定事項に分割して，意思決定を進めることができる。設計要件について記述するためには，その機能が維持され満足される
条件や状態が知られていなければならない。
一方，図 3-2 右側の評価・運用側では，設計要件の対象となる Component test（施設構成要素のテスト）から出発する。なお，施設構成要素のテストを実施するためには，サブシステム機能が明らかになっている必要がある。それらの施設構成要素のテストを統合し，Subsystem test or assessment（サブシステムのテストおよび評価）を行い，さらに上層のテストへと統合していく。これらの結果として，ステークホルダー要件の解決を導く Acceptance test（受容テスト）が最上層に配置される。

V-modelNeed - problem

Evaluation - Operation

Stakeholder
requirements

Verifies

Solution

Acceptance test
Depends on

Satisfies

System testor assessment

Verifies

System

itio
mpos
Deco

Depends on

Satisfies

Sub-system
requirements

Verifies

Sub-systemsnDepends on

Satisfies

Designrequirements

Sub-system testor assessment

Integration

Systemrequirements

Verifies
Components

Componenttest5

図 3-2 要件の階層を含む V モデル（OECD/NEA，2004）より引用，一部修正（5） 要件管理システムの概要
SKB の要件管理システムは Doors®（IBM®）を基本として構築されている。SKB の要件管理シス
テムに使用している Doors®の長所でありかつ短所である部分は階層を跳び越した直接リンクの設定ができないことがあげられる。これにより，階層の体系が整合的となる。ただし，SKB でもすべて要件が階層的に整理できないケースもある可能性が指摘されている。Doors®は要件間のリンクを張ることが非常に容易であるが，Doors®にない機能を別途カスタマイズして製作している部分もある。
要件管理システムは，地層処分概念の設計の前提や設計の内容に関する透明性と追跡可能性を備えている。SKB の要件管理におけるリスク検討の際の，リスクの例としては湧水やモニタリング結果に関する事前予想との大幅な相違が挙げられる。
10

3.2.1.2 SKB の調査結果のまとめ
SKB の要件管理システムは，スウェーデンの法律および安全規制を設計仕様に展開する内容を要件管理システムとして構築している。調査を実施した範囲では，この要件管理システムは追跡可能性と透明性を維持することによって，意思決定の支援に役立てることも可能である。
3.2.2 フィンランド
3.2.2.1 要件管理と要件管理システムの内容（1） 要件の定義
POSIVAは使用済み核燃料最終処分を意図するサイトでの岩盤のキャラクタライゼーションのために地下調査施設（ONKALO）の掘削を始めた。2006 年に開発を始めた POSIVA の RMS は当初，人工バリアシステムと，輸送以外の技術的な処分場システムに関する要件を目的としていた。廃棄物の輸送に関連する施設の要件は後に含まれるようになった。
（2） 要件の利用要件の進捗状況，要件への適合を考慮した業務計画及び参照情報は RMS で維持保存される。そして，法律，規制，指針および POSIVA のドキュメント管理システムへのリンクがある。
特定の部分系統（例えば，キャニスター，緩衝材，埋戻し）に責任があるプロジェクト・マネー
ジャとスタッフには，RMS を維持してアップデートすることに対する責任がある。POSIVA には，
RMS のための変更管理プロセスがある。それは，専門家グループによる変更案のレビューに続いて，研究および技術開発グループにより要件の承認を必要とする。情報はこの承認の前に RMS に登録される可能性があるが，そのような情報はすべて未承認として識別される。
現時点では，POSIVA 以外の他の組織は，RMS にアクセスすることができない。要件関連情報の維持管理や要件関連情報の承認は，想定していた以上に時間を要する。
（3） 要件の種類
要件は，法律や内部レポートや調査結果から得られている。規制と利害関係者の双方から要件を得る。そして，設計決定に関連する要件も含んでいる。
POSIVA では要件に関連する情報として，要件のステータス，作業計画と要件の整合，参考文献を情報として取り込む。それらの要件に関する他の補足的な情報源としては，主として図書管理シ
ステムや規制文書がある。
（4） 要件の階層
SKB と同様に，POSIVA の RMS の要件は法律，規制，および規制の指導に由来している。ただし，関係者の要件として取り上げられるものもある。その意味で，上位の要件として法律もしくは規制情報が存在する。POSIVA の RMS は，これらの上位の必要条件を満たすために開発された地層処分システムに関する設計仕様から得られた要件を含んでいる。

11

（5） 要件管理システムの概要
POSIVA で開発を進めている要件管理システムは Doors®を利用して構築されており，VAHA とい
う名称である。SKB も同様の RMS に Doors®を利用しており，互換性があるという利点が，POSIVAの RMS 用のソフトウェア選択の際の評価に含まれていた。が，Doors®の選択は単に SKB との互換性を提供するためだけでなく，このシステムは他の候補となるシステムと比較評価した後に選択された。POSIVA の RMS では，要件に関して参考文献や規制文書とリンクを取っている。
3.2.2.2 POSIVA の要件管理に関する調査結果のまとめ
・ RMS の開発の目的は，POSIVA の職員および管理者が利用可能な事業関連情報を容易に検索，閲覧できること，および意思決定の参考情報を提供できることにある。
・ RMS は，要件の特定と開発に有用であり，要件に関する議論を行う上でも有用である。
3.2.3 スイス
3.2.3.1 要件管理と要件管理システムの内容（1） 要件の定義
スイスの放射性廃棄物実施主体である Nagra では，要件管理は定期的な事業計画の決定および見直しや地層処分事業の境界条件を決定するためのものであり，品質管理の一部の過程ともなる。こ
の要件管理の枠組みの中で要件とは，廃棄物管理計画・長期安全評価・工学的実現性に関連する原則や機能から特定される。また地層処分システムの構成要素に関する特性を定め，満たすべき内容も要件となる。さらに地層処分システムの構成要素に関する仕様を定めるものである。
（2） 要件の利用
Nagra は完全かつ概観的な要件の編集を目指している。これらの要件は，処分概念開発・意思決定・追跡性確保・情報更新を考慮して利用される。Nagra では，選定された要件に関連する情報として，要件の種類，実証性のレベル，要件達成時期などの付属情報を検討している。
Nagra では，要件管理を品質マネジメントシステムに含まれるプロセスとして位置付けている。
（Suzuki et al.，2010）（3） 要件の種類
要件の起源としては，法令，安全規制の指針，事業者や関係者の要望，科学および技術的知見，
専門家の推奨事項，科学分野の専門家や公衆の要望がある。要件の正式な基準（クライテリア）は，
スイスの規制当局により決定される。スイスの規制当局により決定される要件は，Nagra によりサイト選定における正式な要件として扱われる。
また，要件の指標と基準への適合確認方法の開発にも取り組んでいる。要件の用途としては，施設設計，人工バリア開発，調査計画，安全審査対応，技術開発計画，廃棄物管理計画の更新，経済性評価などである。

12

（4） 要件の階層
Nagra では，要件階層として廃棄物管理計画・処分概念などについて異なる要件階層を考慮している。これらの要件階層は現在も開発中である。
（5） 要件管理システムの概要
正式な専用ツールは選定していないが，いくつかのプロジェクトでは，すでに要件管理を実施している。
3.2.3.2 Nagra の要件管理に関する調査結果のまとめ
Nagra は処分事業の総合的な目的と内容を考慮することは重要であると考えおり，要件管理は，要件を導出して事業に適用するためのプロセスととらえている。要件管理は，処分事業の目的を特定し，それらの目的との適合性を評価するために有用である。要件管理は品質を追跡可能な方法で可視化する。そのために広範かつ適切な構造を有する RMS が重要と考えている。
3.2.4 ベルギー
3.2.4.1 要件管理と要件管理システムの内容（1） 要件の定義
ベルギーの実施主体である ONDRAF/NIRAS では，近い将来に，Safety and Feasibility Case （SFC）の構築を目指している。SFC の構築に関する境界条件は要件に言い換えられる可能性がある。
（2） 要件の利用要件は，SFC の開発を支援するとともに，安全な処分概念の開発や地層処分施設の設計に役立つ。
また，評価や検討を通じて要件に関する証拠を獲得し，提案する地層処分システムが安全で実現可能であることを示す。
要件は，安全上の影響の大きさと影響の信頼性の 2 つを考慮して分類され，それらの分類の結果として，各要件に関する技術開発の優先順位を決定できる。
（3） 要件の種類要件となる可能性のある考慮される境界条件の種類として以下がある。
・ 実施主体としての事業の前提（例えば，国内領土での処分，深地層堆積岩への処分）
・ 国際的枠組み（IAEA や ICRP の規定）
・ ベルギーの規制の枠組み（法令）・ 制度的政策（ベルギーの法令に未反映の原子力管理局（AFCN/FANC）の勧告など）
・ 他のステークホルダーの条件

要件は，トップダウンの方法で特定される。最上位の要件は，安定的であることが期待される。
要件は，ONDRAF/NIRAS が検討している以下の 4 種のステートメントのうち，安全ステートメン
トと実現可能性ステートメントが該当する。
13

・ システム定義ステートメント：
システム定義ステートメントは，熟考されるとともに合理的な段階的安全戦略として，地層処分システムの要素（例えば，廃棄体など）を適切に定義し，その開発を導くものとなる。
・ 安全ステートメント：
設計仕様どおりに施工される場合に，地層処分システムは長期安全性を有する。
・ 実現可能性ステートメント：
操業安全に関する課題を踏まえて，適切な費用で地層処分システムが建設・操業・閉鎖可能であることを意味する。
・ 不確実性ステートメント：
地層処分システムに関連して残存する工学的不確実性は，将来の事業段階（例えば結論や勧告として）で十分に取り扱うことができるようにする。
（4） 要件の階層要件はツリー構造で管理し，地層処分の制度的管理までのすべての活動を網羅する。
設計機能は，
実現可能性ステートメントの最下層の要件として特定され，基準によって特徴付けられる。
基準は，実現可能性との適合度合いや潜在的課題の特定を含む。
（5） 要件管理システムの概要
RMS は EXCEL®（マイクロソフト®）を利用したファイルにより構成されている。
3.2.4.2 ONDRAF/NIRAS の調査結果のまとめ
ONDRAF/NIRAS はこれまでに調査した国々とやや異なったアプローチを採用している。2009 年
時点では，要件管理システムは EXCEL®を利用して作成されている。要件はトップダウンの方法で特定されている。それらの要件は安全ステートメントと実現可能性ステートメントの構造に対応するように構築される。要件管理システムをセーフティケースの一部とする傾向が顕著である。

14

3.3 各国の要件管理のまとめ
3.1 および 3.2 の検討および調査内容をまとめると以下のようになる。事業期間が長期にわたる地層処分事業において，複数のステークホルダーの要求事項を多数の要件として，体系的に一般化して管理することにより，処分事業の各段階における意思決定の一貫性を確保するとともに，要件化した要求事項の管理を通じて品質マネジメントの基本的管理が可能となる。また， 要件や意思決定に関する情報を網羅的に管理することにより，NUMO 内部の知識の共有が可能となる。これにより
NUMO からステークホルダーに対して対外的に一貫した説明を行うことができる。さらに，これらの要件の達成度合いと達成時期の情報を活用することにより効率的かつ網羅的な工程管理や技術開発管理を行うことが可能となる。
長期の処分事業においては，前提条件の変更が生じる可能性があるが，そのような場合にも，これまでの意思決定の経緯と関連する要件の重要度の変化を把握することにより，的確な変更管理が可能となる。これらの変更管理の経緯や結果を含む要件や意思決定に関する情報を長期にわたり記録管理することにより，知識の伝承も可能となる。
上記のように地層処分事業に要件管理を適用する場合，多岐にわたる要件とそれらの関連情報や変更に関する記録を保存し，作業の意図に合わせて必要な情報のみを迅速に取り出すためには，IT技術を利用したソフトウエアによる情報管理が有用な手段となる。海外の地層処分実施主体でも同様の目的から，ソフトウエアとしての要件管理システムが開発されている。

15

4 NUMO における要件管理法の検討
4.1 要件管理の進め方
4.1.1 要件管理業務
段階的に進められる処分事業において，各段階で要件管理を適切に進めるために，業務を明らかにし，計画的に進めていく。具体的には，各段階の目標を考慮して意思決定や要件を設定し，またどの程度の要件の充足度を求めるのかを設定する。その後，設定された意思決定や要件を考慮しながら設計・評価などの業務を行い，要件充足の論拠を整備する。要件の充足状況や他の意思決定の結果との整合性を確認し，すべての要件の充足が確認できた項目について意思決定の結果を確定する。
そこで，要件管理業務を，以下に示すように４つのフェーズに分けて実施する（表 4-1）
。図 4-1には，要件管理業務での業務内容と流れを図化して示す。充足性確認フェーズで証拠などが不十分の場合は，業務実施フェーズに戻り再検討を行う。なお，「意思決定」という用語は一般的に「複数の代替案から，解を求めようとする行為のこと」の意味合いで用いられるが，要件を管理する対象は必ずしもそのような選択を伴わない決定事項もあるため，要件管理では「意思決定・業務」と表記することとした。
表 4-1 要件管理業務のフェーズの説明
フェーズ

フェーズの説明要件等定義フェーズ

意思決定・業務，要件および要件充足の方策を定義，設定し，前提条件を収集，整備するフェーズ

業務実施フェーズ

定義された要件などに基づいて，調査，設計，性能評
価などの業務を実施し，要件が充足されていることを支持する論拠や証拠を収集するフェーズ

充足性確認フェーズ

証拠や論拠が十分であるかの観点からの要件の充足状
況，他の意思決定との整合性を検証するフェーズ

意思決定フェーズ

すべての要件の充足が確認できた項目について，意思決定を行い，確定するフェーズ

16図 4-1 要件管理業務の各フェーズにおける業務内容と流れ
4.1.2 段階的な要件の定義
これまで述べてきたように，NUMO が事業を推進していく上で考慮すべき要件を設定するに当たっては，多様なステークホルダーの要求事項を考慮する必要がある。それらには，最終処分法などのすでに存在するものもあれば，サイト調査の対象となる地域の住民からの要求やステークホルダ
ーからの事業に対する理解を得るために必要な条件など，事業の進展に伴い，今後，明らかとなっていくものがある。安全審査指針を例に挙げると，閉鎖後長期安全性の評価にかかわる要件や要件の充足性を判断するための指標などが明らかとなるのは精密調査の段階と考えられる。それまではNUMO は自主基準を設定し，それに基づいて事業を実施し，また，指針が公表されてからも，指針に基づいて自主基準を設定し，事業に反映する。
一方，要件はサイト調査や技術開発の進展に伴ってより詳細に定義できる性質も持つ。例えば処分場の設計は，当面，サイトの地質環境条件に関する情報の蓄積や技術の進歩に合わせて柔軟に開発するため，設計に関連する要件は徐々に詳細に定義できる。
現時点において，NUMO では，すでに存在する法令や関連する指針などを参考に要件を定義するとともに，処分場概念の開発に関連する要件については，第２次取りまとめや NUMO で実施してきた処分場概念の試行検討の成果を取り入れ整備している。
今後，処分場概念が具体化するに伴い，施設設計に合わせて設計要件の具体化や判断の基準の具体化を進める予定である。

17

4.2 要件管理の要素，前提条件（C：conditions ま
NUMO では，要件管理の主要な情報を，意思決定1（D：decisions）
たは constraints），要件（R：requirements），論拠（A：arguments）の４つの要素と考え，意思決定の構造モデル（DCRA モデル）を開発した（NUMO, 2007）。ある一つの意思決定に着目した場合，意思決定・業務は，関係するすべての要件が充足されることが求められる。各要件充足に当たっては，論拠（A）ができるだけ具体的に示される形で整理されていることが必要となる。そのような意思決定・業務は，前述したようにその時点での外的情報を前提として実施されるものである（前提条件）。また，異なる意思決定・業務には決定の順序があり，ある意思決定・業務の検討結果が他の意
思決定・業務の前提となる（図 4-2 参照）。
以下には，これらの４つの要素を詳述する。

図 4-2 実務システム開発における DCRA モデルの構造
4.2.1 意思決定・業務「意思決定」という用語には，4.1.1 で述べたように，もともとは「選択」の意味合いがあるが，要件管理の対象とする決定事項には，評価など必ずしも選択を伴わない場合もある。また，処分場の設計のように許認可の段階で最終的に決定するが，それ以前の段階においてもその時点の地質環境に関する情報などをもとに検討するような業務もあり，要件管理ではそのような「業務」も取り扱う。
4.2.2 前提条件
段階的に進める処分事業では，その時点で入手可能なサイト環境に関する情報や技術に関連する

1 ここでいう「意思決定」とは，組織レベルの意思決定だけでなく，担当者のレベルで日々の作業

において行う業務における意思決定も含む形でモデル化している。したがって，以下では，意思決定・業務として表現した。
18

知見，関連する法令・規制，社会環境などを前提として決定を下すことになる。過去の判断結果を振り返る際，その時点での決定結果に影響を及ぼすこれらの前提条件を明示的に管理しておくことが重要となる。また，別の意思決定結果を考慮する場合，それらも決定の前提となる。
4.2.3 要件処分事業において満たさなければならない要件は，例えば最終処分法，国による安全規制のための指針・基準（安全審査指針や処分場の技術基準），労働安全衛生法など法令・指針類に定められた事項，社会的な要求事項に基づき設定されるものである。このほか，設計上の機能として必ず満たさなければならない要求機能などがある。NUMO の要件管理においては，これらを「必須の要件」
として扱う。
一方，必ずしも満たさなくてもよいが，できれば具備していた方がよいと考えられるものも存在する。安全性や工学的成立性に関連する必ず満足しなければならない要求事項は満足しているものの，それらをより向上させるような好ましい機能，あるいは経済性の観点から好ましいことなどがこれに該当する。このような「好ましい事項」についても，意思決定の際には考慮されるため，要件管理の対象となる。特に好ましい要件は，後述する選択の意思決定において用いられる。
4.2.4 論拠
上述した意思決定・業務は，関係する要件を充足することが求められ，要件を充足することを示
す情報を意思決定や要件と関係づけて管理する。論拠には，実験結果，解析結果，自然界や考古学分野における類似事例（ナチュラルアナログ事例）などの「証拠」，あるいは専門家の判断など多面的な要素が含まれる。これらの安全性に係る論拠は段階的に拡充していくものであるため，事業の段階によっては論拠が完全に揃っていない状況はやむを得ないことであり，要件管理においても事業の段階の特徴を考慮しつつ，論拠がこの段階で十分であるかを見極めることが重要となる。
要件等定義フェーズにおいて，事業の段階を考慮した上で，その段階においてはどのように要件を充足させるかといった計画を事前に立てる（要件充足の方策）。この方策としては，ある要件に対し，その要件が満足するように設計することで対応できるものもあれば，試験施設での実証や実験を必要とする場合もある。特に後者は，各調査段階においてどの程度まで示すことを目標とするかという方針を明確に提示する必要がある。
例えば，金属製オーバーパックの遠隔溶接技術の実現性は，工学的実現性の確保に関する技術要件であるが（NUMO，2011a），精密調査の段階に実証試験を実施するためには，概要調査の段階の終わりごろまでには，その技術を用いて将来，金属製オーバーパックを遠隔で溶接できることの技
術的な実現性の見通しを得る。その際，「要件充足の方策」に，実証試験を実施する技術として採用するために必要な技術開発の達成度を設定し，それに向けて技術開発計画を管理する。
このような技術開発を通じて論拠を整理する方法として，NUMO では論拠シートを準備している。
例として，人工バリアを構成する実規模オーバーパックの溶接技術の実現性について，要件充足方
策と論拠を整理した論拠シートを表 4-2 に示す。論拠シートは 1 つの要件について 1 つのフォーマットを準備し，要件名称，要件充足の方策，論拠および論拠の要約を記載する。

19

表 4-2 要件に関する論拠の整理の例（原子力環境整備促進・資金管理センター（2008）を引用しまとめた）

20

表 4－1（続き）

21

4.3 要件の定義と階層化の方法
3.1.2 で述べた安全確保の要件を対象に，要件の定義と階層化の方法を述べる。前述のように，地層処分事業における安全確保とは，｢閉鎖後長期の安全確保｣と｢事業期間中の安全確保」の二つの目標を達成することであり，これらの目標は安全確保上の最上位の要件となる。
閉鎖後長期の安全確保に関する基本的要件（最上位の要件）は，IAEA（2006）の国際基準での要求事項を参考に，「隔離」と「閉じ込め」とする。これらの最上位の要件を実現するために，安全上必要となる機能（安全機能）に細分化し，処分場の各バリアに機能を割り当てるなど，実現するための対応策を取る。例えば，「隔離」のために，処分場が地質の長期的変動からの影
響や人間の接近を受けないように抑制することと考え，それらを下位の要件として設定し，対応策として，処分深度の確保や自然現象の著しい影響の回避，鉱物資源の存在しないことが要件となる。一方「閉じ込め」は，まずガラス固化体に閉じ込められた核種が地下水に浸出するのを抑制し，次に浸出した核種が移行するのを抑制する機能が必要と考え，地層処分システムのいずれかの構成要素である，廃棄体，人工バリアおよび天然バリアの機能として割り当て，
その安全機能が満たされるように技術要件を設定する。閉鎖後長期安全性に関する安全機能を階層構造により整理した事例（NUMO, 2011b）に表 4-3 に示す。
表 4-3 高レベル放射性廃棄物の安全機能と構成要素の関係（NUMO，2011b）
基本概念

安全機能

構成要素

隔離

地質の長期的な変動からの防護
天然バリア

人の接近の抑制放射性物質の浸出抑制

ガラスマトリクスによる
浸出抑制

廃棄体

発熱が著しい期間の地下水接触の防止

オーバーパック

放射性物質の溶解度制限

天然バリア，人工バリア

閉鎖後閉じ込め

移流による移行の抑制
コロイド移行の防止・抑制

放射性物質の移行抑制

緩衝材

収着による放射性物質の移
行遅延
遅い地下水流動

天然バリア

分散による移行率の低減
アクセス坑道およびその周辺が卓越した移行経路となることの抑制22

閉鎖用埋め戻しなど

4.4 地層処分事業における要件管理システムの適用方法の検討
本節では，地層処分事業における要件管理の適用方法を具体的に検討した結果について述べる。
地層処分事業への要件管理方法の適用の観点と海外実施機関の開発事例の調査結果を踏まえて，要件管理の適用方法を以下にまとめる。
4.4.1 要件の体系的な管理
地層処分事業では多数の意思決定やそれらに関連する要件が存在する。また，事業期間が他の大規模土木建設事業と比較しても長いことから，それらの要件の網羅性や変遷についての管理がより困難となる。意思決定や要件は体系的に管理することにより，迅速に特定の意思決定や要件に関する情報とその変遷を把握することが可能となる。また，それらの特性や他の情報との相関関係を明らかにし易くなる。処分事業には情報の追跡性と透明性が求められるため，これらの要件管理は処分事業において特に有用である。
要件管理システムは，処分事業の一連の作業における意思決定や要件を体系的に整備し管理することを可能とする。また，要件管理システムを用いることにより，意思決定と要件間，あるいは複数の要件間の関連性を迅速に把握することができる。それらの情報を踏まえて，さらなる意思決定を行うことが可能となる。
4.4.2 スケジュール，技術開発計画の管理
事業計画に基づいてマイルストーンを設定し，最終的な意思決定に必要な情報や，より詳細な作業レベルでの意思決定を計画的に実施するためのスケジュールの管理が必要である。スケジュール
は，NUMO 内で共通的に使用するものであり，これに基づいてさらに詳細な業務のスケジュールを策定する。
また，地質調査技術や工学技術，性能評価技術の技術開発を進め，要件の充足のために必要な情報を収集するために，技術開発計画の管理も必要である。要件管理システムを利用して，意思決定や要件と照らし合わせて，技術開発の進捗や実施工程を管理することが可能となる。
4.4.3 文書などの記録管理
地層処分事業において，発行される膨大な図面類，資料などの図書類との関連や，特定分野の技術的知見に関する最新かつ正確な内容との連関を考慮した記録管理が重要となる。また，これらの最新の情報が NUMO 内部で共有され，対外的に一貫した説明を行うことができる。さらに，記録管理は NUMO 内部での職員間，さらには外部の関係者間の世代をまたぐ知識の伝承に役立つと考えている。要件管理システムは，処分事業の一連の作業における多数の意思決定や要件に関して，関連情報を含めて管理することができる。また，図書管理システム，知識管理システムとの連関を検討することにより，多くの関連情報の記録管理との連関も確保される。
4.4.4 品質マネジメント
長期にわたり膨大な品質マネジメント情報を保管する必要がある地層処分事業では，調査取得デ
23

ータの品質管理，設計や解析のためのソフトウエア，手法，使用データの品質管理，施設施工や設備製造の品質管理のように多様な情報に関する品質マネジメントが必要となる。これらの品質マネ
ジメントの結果として業務品質を確保することができる。特に処分事業の前半の調査および設計の段階では，基本的な品質マネジメントの一環として，検討内容が技術的に正確で妥当であること，
検討手順および項目が適切に整備されていることが重要である。
異なるステークホルダーを品質マネジメント上の顧客として定義し，顧客の要求事項を要件として整理することにより，要件管理システムでは，また，要件管理システムに入力する情報は，品質
マネジメントの一環としての，品質記録（作成者，日時，作成目的その他のデータ品質に関する情報，データの改訂に関する情報）を必然的に登録することとなり，それらの記録の体系的な保管を行うことが可能となる。
4.4.5 変更管理
地層処分では事業期間が長くさまざまなリスクや不確実性が考えられる。そのために，生じる外的条件の変化や要件の重要度の変化に対応して，必要な範囲で意思決定の結果を見直すといった変更管理が重要となる。
要件管理システムでは，多数の要件の充足の管理や，前提条件の変更により影響を受ける意思決定や要件を特定できることが変更管理の観点から有用である。外的条件の変化がトリガー（起因事象）となって，どのような意思決定事項の見直しにつながる影響伝播があるかを，迅速かつ体系的に追跡することにより既存の意思決定の変更の必要性や意思決定の変化の内容を適切に判断することが可能となる。

24

5 ソフトウエアの開発
第 4 章までに述べた要件管理の方法や要件管理システムの適用方法の検討に基づいて，要件管理システムの開発を進めている。
本章では，要件管理システムの主要なシステム機能について述べる。
5.1 システム開発要件（ソフトウエア要件）
NUMO は要件管理システムを，長期に亘る地層処分事業を通して行われるさまざまな意思決定および要件に関連する情報を，体系化して長期間記録するシステムとして定義する。さらに，記録された情報を活用し，意思決定作業を支援するシステムとして位置付けている（NUMO，2007）。従来の要件管理システムでは，要件のみを基本情報として記録・管理する。これらに加えて，意思決定に必要な情報についても，記録・管理し，さらに，重要な意思決定を行うことを支援することが，地層処分事業を支援するシステムに必要である。
本節では，上記を踏まえ，①意思決定や要件および関連情報の記録・管理，②重要な意思決定における要件と関連情報の利用の観点から，要件管理システムの開発要件について記す。また，システムの運用や製作に関する開発要件についても併せて記す。
5.1.1 情報の記録・管理に関するソフトウエア要件
要件管理システムが記録・管理する主要な情報として，意思決定・業務と要件が挙げられる。これらは，処分施設の設計や安全評価に関する分野，サイト調査に係る分野および処分事業全体の管理などに係る分野に分類される。また，個々の分野に着目すると，意思決定と要件は，総括的もしくは広義な記述から，より具体的もしくは狭義な記述となる階層構造を取る。また，1 つの意思決定に着目すると，その意思決定が他の意思決定の考慮事項や要件充足の論拠になるといった特徴も備えている。さらに，情報量に着目すると，地層処分は多岐にわたる技術的・社会的領域から構成されることから，膨大な量となる。このため，意思決定・業務階層や要件階層の全体を同時に俯瞰することは困難となり，情報を検索するためのキーワードを付加することが有効となる。
意思決定の方法に着目すると，複数の候補から最適なものを選択する場合があり，却下された候補も記録・管理することが追跡性の観点から必須となる。また，要件に関しては，処分場（サイト
環境）や事業の進展に伴い要件の見直しや詳細化による拡充がなされるが，実質的にはそれらに係らず事業の初期段階で要件が定義されるケースが大半を占めることも留意する必要がある。
次に，意思決定と要件に関連する情報に着目する。要件管理システムでは，情報の追跡可能性や信頼性確保のため，意思決定・業務や要件が参照しているさまざまな情報，例えば，機構内外の技術報告書や図面などの図書類も，関連情報として管理することが望まれる。また，品質マネジメン
トの観点からは，情報の作成者や作成日，承認情報，および，改訂履歴を管理することが必須となる。さらに，業務管理の観点からは，意思決定作業のスケジュールや充足の程度，担当者の管理を行うことも考えられる。
以上を纏めると，情報の記録・管理に関するソフトウエア要件としては，下記項目が挙げられる。
・ 意思決定・業務と要件，意思決定の考慮事項や論拠を構造化して記録できること。
・ 意志決定・業務および要件が階層構造で管理できること。
25

・ ある段階の意思決定が，その下部階層の意思決定や関連する他の意思決定の論拠として定義できること。
・ 意志決定・業務や要件の変遷に対応するため，改訂履歴を管理できること。
・ 事業の進展に伴う要件や意思決定・業務の構造の変化に柔軟に対応できること。
・ 意志決定や要件に関連する膨大な情報，例えば，報告書や図面などの図書類も，意思決定や要件との連関と共に管理できること。
・ 品質マネジメントを目的として，作成者や作成日，承認情報を管理すること。
・ 意志決定作業のスケジュールや充足の程度を管理できること。
5.1.2 情報活用に関するソフトウエア要件
・ 意志決定支援－情報の検索・閲覧
要件管理システムは，情報の記録・管理に加えて，記録された情報を活用して，意思決定を迅速かつ正確に行うことを支援する。このためには，システム利用者（意志決定者）が，意思決定・業務や要件を起点として，論拠や考慮事項，さらには，関連する図書などを容易に検索，閲覧できる
作業環境を提供することが必須となる。これにより，有用な情報を見落とすことなく効率的に意志決定作業を行えることになる。
・ 意志決定支援－影響評価
長期間にわたる処分事業を進める過程では，技術の進歩や社会的制約条件が変化していくことが考えられる。また，段階的な事業の進展に伴い，地質環境が徐々に明らかになり、サイト環境条件の変化が起こることもありうる。このような外的要因の変化は，意思決定や工程などに大きな影響を与える。このため，意思決定や関連情報（例えば，サイト環境条件）の変更が影響を及ぼす範囲を特定できる機能を有することする。
・ 技術課題の抽出
意志決定／業務の結果を記録・管理することにより，技術課題を抽出できるようにする。具体的には，意思決定結果に「条件付き」などのステータスを付与することにより，さらなる検討が必要とされる意志決定／業務を抽出できるようにする。
・ 品質マネジメント
要件管理システム上で記録情報の承認行為を行えるようにする。なお，承認時には，承認対象となる情報に加えて，関連情報も容易に閲覧できるようにする。
・ プロジェクト管理
意志決定作業の進捗管理を行えるようにする。なお，進捗管理は，要件管理システムでの作業の開始日や終了日の管理といった簡易なものから，本格的な工程管理ソフトウエアと連携して，日程だけでなく進捗率や人員配置も管理することが考えられる。

26

・ 教育
処分事業は，長期に亘ることから若手技術者に円滑に技術を伝承していくことが必須となる。要件管理システムでは，技術者の教育を目的として，さまざまな視点から意思決定や要件を検索，閲覧できるようにする。具体的には，意思決定や要件階層に加えて，キーワードとして用意された処
分場コンポーネント（オーバーパックなど）を用いて，関連する情報を検索・閲覧できるようにする。
5.1.3 システム形態および製作に関するソフトウエア要件
要件管理システムは，機構職員に限らず，外部機関や委託業者などが利用する。さらに，将来は，
ステークホルダーなども利用することが想定される。このため，WEB システムの形態をとり，ネットワークを介して利用できるようにする。さらに，海外機関も利用できるように，ユーザーイン
ターフェースとデータ（意志決定や要件など）と共に，日英の２ヶ国語に対応したシステムとする。
システム運用の観点では，処分事業が長期にわたる事業であることから，システムの柔軟性や拡張性，保守性などを十分に考慮することが重要である。このためには，ソフトウエアの開発手法や使用する開発用ツール（ミドルウエア）の選定は，ソフトウエア製作上，重要な要素となる。

27

5.2 システム機能
本節では，システム開発要件に基づき設計された要件管理システムの機能について述べる。要件
管理システムは，意思決定・業務や要件を登録・閲覧するための機能を中心に，意思決定作業を支援する機能として，さまざまな観点からの情報検索機能や情報の変更により影響を受ける他の情報を抽出する変更管理機能など，さまざまな機能を備える。図 5-1 に，システムの機能構成を示す。
なお，システム機能の詳細については付録に記述する。

登録機能• 要件の登録• 意思決定・前提条件・論拠の登録• 関連情報の登録

データ管理機能••••キーワードによる検索
作成者・登録日による検索
ステータスによる検索
参照情報による検索

変更管理機能前提条件
意思決定

検索・閲覧機能

要件

論拠

キーワード

パラメータ

参考文献

地域情報

• バージョン管理／履歴管理• 要件等の変更による影響評価• データ改訂指示

意思決定手順作成機能• 意思決定の依存関係や人員リソースを考慮した手順

スケジュール管理機能

承認機能• 意思決定作業の実施期間• 承認行為の支援

帳票作成機能ユーティリティ機能• Excel ファイル自動生成

入力ﾕｰｻﾞｲﾝﾀﾌｪｰｽ機能• 用語辞書による入力操作軽減

ユーザ管理機能
ログイン機能ポータル機能参照情報管理機能
キーワード管理機能
自動バックアップ機能

WEB ブラウザ

図 5-1 要件管理システムの機能構成

5.2.1 データ管理
データ管理機能は，要件管理システムで扱う要件や意思決定・業務，ならびに，これらデータが参照する情報をデータベースを用いて一括管理する。表 5-1 に本システムで扱う主要なデータの一
覧を示す。

28

表 5-1 主要データ一覧
データ
意思決定・業務内容
意思決定や業務の内容や結果を登録する。サイト（地質環境や処分場仕様）に依存しないデータとサイト固有のデータに区分する。

前提条件

意思決定を行う上での前提条件や制約などを登録する。

要件

処分場の要件を表す。全サイト共通のデータとして登録する。

論拠

要件充足の論拠として，方策やエビデンスを登録する。

意思決定手順意思決定の手順を示すフローを登録する。

参考情報

地質環境や緩衝材物性などのパラメータおよび論拠などに関する参考文献を登録する。

5.2.2 要件の登録機能
本機能は，意思決定・業務や要件，論拠，前提条件を登録するためのユーザーインターフェースを提供する。なお，登録に限らずすべてのユーザーインターフェースは，WEB ブラウザから利用することができる。
5.2.3 要件の検索・閲覧機能
検索・閲覧機能は，システムの利用目的に応じて，さまざまな観点から情報を検索し，表形式やツリー形式などで表示する。例えば，意思決定事項は，図 5-2 に示すように処分場の構成や意思決定作業の進捗（ステータス）などからも検索することができる。

29

処分場構成を用いた検索
名称や意思決定作業のステータスを用いた検索

図 5-2 検索・閲覧用ユーザーインターフェース
5.2.4 変更管理に関する機能
長期にわたる処分事業を進める過程では，要件の重要度や外的条件の変更に伴い，要件や意思決定の改訂が適宜行われる。変更管理に関する機能は，情報の変遷過程を追跡するため改訂日時や改訂内容を記録する。また，要件や外的条件の変更により影響を受ける意思決定の抽出を行う。これにより，意思決定の見直しの必要性や影響範囲を的確に判断することが可能になる。
5.2.5 工程管理に関する機能
意志決定階層構造は，意思決定対象となる項目（例えば，人工バリア）の構成に着目して体系化されており，作業順序を考慮したものではない。要件管理システムは，階層構造に加え，意思決定の依存関係（作業の流れ）に基づいた意思決定手順を作成する機能を備える。本機能は，マウス操
作を主体とした操作性の高いユーザーインターフェースを備え，図 5-3 に示すようなネットワーク
図を作成することができる。また，手順に加えて，個々の意思決定・業務の実施期間も管理することができる。

30

意思決定手順
ネットワーク

図 5-3 意思決定手順の作成
5.2.6 品質マネジメントに関する機能
地層処分事業では，要件や意思決定および関連する情報の品質管理を行うことが必須である。要件管理システムでは，基本的な品質マネジメントとして，データ作成者や日時，改訂履歴に加えて，承認情報を記録することができる。承認行為は，承認依頼から情報の確認，承認と言った一連の作業をソフトウエア上で行うことができる。また，業務管理に活用するため，承認状況を記載した一
覧表を自動作成する機能を備える。

31

6 おわりに
NUMO では，地層処分事業の要件，意思決定および関連する情報を記録・管理し，事業を着実に進めていくための手法として，要件管理技術の検討を進め，その支援システムである要件管理シス
テムを開発した。要件管理は，ソフトウエア開発を含む一般的な産業界ですでに導入されている手法であり，近年，地層処分の分野においても各国の実施主体で，要件管理技術の適用や要件管理シ
ステムの開発が進められている。地層処分事業というプロジェクトの特徴を踏まえると，要件管理に必要な項目としては，情報の追跡性の確保，長期間の記録管理，さらには重要な意思決定を要件に基づいて実施することなどがあげられる。そのため，NUMO では， NUMO の将来の業務に関する業務分析を行った上で，要件管理システムの機能について分析し，それらの分析結果に基づく，
ソフトウエアとしてのRMS の開発要件と機能についての検討成果と構築したRMS の機能について記述した。
今後は要件管理システムを活用し，まずは，地層処分場の設計・性能評価から要件の登録や意思決定事項の登録などを進め，合わせて技術開発成果などを登録し，今後のサイト選定業務を支援する予定である。

32

参考文献
IAEA （2006）：Geological Disposal of Radioactive Waste，IAEA Safety Standards Series No. WS-R-4.
JNC（核燃料サイクル開発機構）（1999）：わが国における高レベル放射性廃棄物地層処分の技術的信頼性－地層処分研究開発第 2 次とりまとめ－分冊 2 地層処分の工学的技術，JNC TN1400
99-022.
JNC（核燃料サイクル開発機構）（2005）：高レベル放射性廃棄物の地層処分技術に関する知識基盤の構築 －平成 17 年度取りまとめ－，地層処分技術の知識化と管理，JNC TN1400 2005-020.
日本規格協会（2009）：対訳 ISO9001：2008（JIS Q 9001:2008）品質マネジメントの国際規格，
原子力発電環境整備機構（NUMO）（2007）：段階的な事業推進における構造化アプローチと要件管理，NUMO-TR-07-01.
原子力発電環境整備機構（NUMO）（2011a）：処分場の安全機能と技術要件，NUMO TR-10-11.
原子力発電環境整備機構（NUMO）（2011b）：地層処分事業のための安全評価技術の開発（I）－シ
ナリオ構築技術の高度化－，NUMO TR-10-09.
原子力発電環境整備機構（NUMO）（2011c）： RMS2010 Requirements management systems （RMS）：
status and recent developments, information exchange meeting report，NUMO TR-10-07.
OECD/NEA（2004）：Engineered Barrier Systems（EBS）：Design Requirements and Constraints, Workshop
Proceedings，26-29 August 2003，Turku, Finland.
原子力環境整備促進・資金管理センター（2008）：平成 19 年度 地層処分技術調査等委託費 高レベ
ル放射性廃棄物処分関連 処分システム工学要素技術高度化開発 報告書（第 1 分冊）－遠隔操作技術高度化開発－（1/2）.,
Suzuki, S., Ueda, H., Sakabe, Y., Ishiguro, K., Kitayama, K., Oyamada, K., Yashio, S. （2008）: Developmentof the requirement management system for Japanese HLW program, the proceedings of 12th
International High-Level Radioactive Waste Management Conference （IHLRWM），Sept. 7-11，Las
Vegas，Nevada，631-636.
Suzuki, S., Ueda, H., Fujisaki, K., Ishiguro, K., Tsuchi, H., Vomvoris, S. and Gaus, I.（2010a）：Recent
developments and trends in requirements management systems, Proceedings of the 13th International
Conference on Environmental Remediation and Radioactive Waste Management, ICEM13, October
3-7，2010，Tsukuba，Japan.，ICEM2010-40280.
Suzuki, S., Ueda, H., Fujisaki, K., Ishiguro, K., Tsuchi, H., Oyamada, K., Yashio, S.（2010b）：Development of
requirements management system of NUMO and practical experience with development of thedatabase contents, Proceedings of the 13th International Conference on Environmental Remediation
and Radioactive Waste Management，ICEM13，October，3-7，2010，Tsukuba，Japan.,
ICEM2010-40228.

33

付録-1 要件管理システムの機能について
1 システムの要求機能
要件管理システムのソフトウエア要件を踏まえて検討した要求機能を付表 1 に示す。
付表 1 システムの要求機能一覧
分類
データ管理

データ管理

変更管理
承認
その他

要求機能
意思決定，要件，論拠，前提条件は，付図 1-1 に示す構造とする。
複数の意思決定を階層構造で取りまとめ，データセットとして管理する。
複数の要件を階層構造で取りまとめ，データセットとして管理する。
要件は，複数の意思決定から参照される共通データとして扱う。
意思決定は，名称，対象（HLW や TRU など），説明，意思決定結果，ステータス（未実施，意思決定など）および登録者や登録日などの属性を持つ。
意思決定や要件は，承認情報を設定する。
履歴管理を目的として，意思決定や要件には，名称に加えて，バージョンを付与する。
意思決定や要件，論拠，前提条件は，ファイルの添付や参考文献を登録できるようにする。
意思決定には，検索や分類を目的として処分場コンポーネントなどのキーワードを設定することができる。
意思決定事項を集約したワークパッケージを定義することができる。ワークパッ
ケージは，ワークパッケージに含まれるすべての意思決定事項が成立した場合に意思決定がなされるものと，いずれかの意思決定事項が成立した場合に意思決定がされるものに区分される。
要件は，名称（内容を簡潔に記載した文章），指標，基準値および登録者や登録日などの属性を持つ。
論拠は，方策，論拠，エビデンスおよびステータス（技術開発課題など）を属性データとして持つ。
ある意思決定の結果を，他の意思決定の論拠や条件とすることができる。
意思決定の順序を定義した手順を登録することができる。
（意思決定手順とは，意思決定事項の関係を有向グラフとして表現したネットワーク図とする。
）なお，
意思決定手順は，意思決定階層とは異なり，意思決定事項間の主従関係などに加え，人員リソースなどを考慮して作成される。
意思決定や要件の階層をツリー形式で表示することができる。
登録情報（登録日や登録者など），処分場コンポーネントを用いて意思決定事項や要件を検索することができる。
登録情報や処分場コンポーネントを用いて意思決定や要件を検索することができる。
意思決定は，ステータス（意思決定済みや条件付き意思決定など）を用いて検索することができる。
意思決定事項や要件の変更履歴として，変更者や変更日を記録することができる。
参考文献などが変更された場合に，影響を受ける要件や意思決定事項を抽出できる。
要件や意思決定事項の変更により影響を受ける意思決定事項を抽出できる。
一連の承認行為（承認依頼→承認）を行うことができる。
承認依頼後のデータの改定は禁止する。改訂する場合は，バージョンアップした
後に行うものとする。
ユーザーインターフェース，コンテンツ共に日本語，英語の 2 ヶ国語対応とする。
WEB システムの形態とし，ユーザーインターフェースには，WEB ブラウザを用いる。
ユーザー認証によりシステムの利用を制限することができる。
データ保護のため，自動的にバックアップを行う。

付-1

2 要件管理システムの機能
要件管理システムは，意思決定事項や要件を登録・閲覧するための機能を中心に，意思決定を支援する機能として，さまざまな観点からの検索・閲覧機能や情報の変更による影響を評価する機能など，さまざまな機能を備える。
(1) データ管理機能
データ管理機能は，要件管理システムで扱う要件や意思決定，ならびに，これらデータに関連する情報をデータベースを用いて管理する付図 1。付表 2 に本システムで扱う主要なデータの一覧を示す。
意思決定（D：Decision-making matter），前提条件（C：Condition），要件（R：Requirement）および論拠（A：Argument）は，サイト（（地質環境や処分場仕様））に依存せず全サイトに共通して利用されるテンプレートデータとサイトに依存するユーザーデータに区分される。
（以下，意思決定，
要件，論拠，前提条件を纏めて DCRA データと呼ぶ）
要件は，通常，テンプレートデータとして登録されるが，特定の地質環境などに特化した要件もユーザーデータとして登録することができる。意思決定に関しては，意思決定の方法などを記載した説明は，テンプレートデータとして登録され，その後，データとして，意思決定の結果が登録される。論拠に関しては，要件充足の方策のみがテンプレートデータとして登録され，論拠自体（エビデンス）は，ユーザーデータとして登録される。前提条件は，サイトに依存することからユーザ
ーデータとなる。ただし，法令などのサイトに依存しない条件は，テンプレートデータとして登録することができる。
意思決定階層
意思決定 A

要件階層
要件 B

要件 A

意思決定 B

要件 C

意思決定 C

前提条件

意思決定 C

要件 B

論拠

要件 C

論拠

前提条件

添付ファイル

意思決定は、前提条件、要件、論拠から構成される。

付図 1 主要データの構造

付-2（論拠シート等）

付表 2 主要データ一覧
データ
意思決定

内容
意思決定の内容や結果を表す。
テンプレートデータとユーザーデー
タに区分され，テンプレートデータでは，意思決定の内容などを持ち，一方，ユーザーデータは，意思決定の結果を持つ。

前提条件

意思決定の前提条件や制約などを表す。
サイト条件に依存しないテンプレートデータとサイト条件に依存するユーザーデータに区分
される。

要件

処分場の要件を表す。
一般にサイトに依存しない汎用的なデータとして登録される。

論拠

要件充足の論拠を表す。論拠は，通常，テンプレートデータとして方策が記載され，ユーザーデータでは，エビデンスが記載される。

ワークパッケージ

複数の意思決定事項を集約する。
意思決定事項と同様にワークパッ
ケージの内容や結果を持ち，テンプレートデータとユーザーデータに区分される。また，ワークパッケージは，その中に含まれる意思決定がすべて決定された（要件が満たされた）場合に意思決定がなされるものと，集約された意思決定のどれかが決定された場合に意思決定がなされるものが用意される。

フォルダ

意思決定や要件を分類する目的で使用する。

適合性評価結果

要件毎の適合性評価結果を表す。

WBS

複数の DCRA データやフォルダを階層構造に纏めたデータセットを表す。テンプレートデータとユーザーデータに区分される。

意思決定手順意思決定の手順を示すフローを表す。

設計因子「閉鎖後安全性」や「工学的信頼性」などの設計因子を表す。要件の分類や検索に用いる。

地域データ

サイトに関する情報を表す。

パラメータデータ

地質環境や緩衝材物性などのパラメータを表す。

参考文献

論拠などから参照される参考文献を表す。

キーワード

意思決定事項および要件を分類する処分場コンポーネントなどのキーワードを表す。キーワードは，階層構造を取ることができる。

ユーザー

本システムの利用者に関する情報を表す。
システムへのログインやデータ登録者の管理に用いる。

添付ファイル

意思決定事項，前提条件，要件，論拠に添付されるデータを表す。
図表などを記載した文書ファイルを格納する場合に用いる。

付-3

(2) 登録機能
本機能は，意思決定や要件，論拠，前提条件などを登録するための操作性の優れたユーザーイン
ターフェースを提供する。このユーザーインターフェースは，WEB ブラウザから利用することができる。付図 2 に DCRA データの典型的な登録手順を示す。

ＷＢＳ名入力あらかじめ登録されている地域を選択する。

地域選択

あらかじめ登録されているテンプレートデータを選択する。

WBS テンプレートデータ選択

WBS テンプレートデータ全体を使用するのではなく，一部のデータのみを使用する場合は，使用する意思決定を選択する。

D 個別選択モデル全体選択テンプレートデータ

意思決定事項選択(マスターデータ)

D –1
D –2

WP
D –3

D –4

D –5

全体選択
（すべての D 選択）

意思決定階層編集

ユーザーモデル

サイト固有 D 登録

ユーザーモデルD –1

意思決定登録D –2

D 個別選択（例：WP のみ選択）

WP
D –3

D –4

WP
D –5

D –4

要件・論拠追加
必要に応じてサイト固有の意思決定および要件・論拠を追加する。
意思決定事項閲覧

前提条件入力論拠入力

適合性評価作業
適合性評価結果入力

意思決定作業

意思決定結果入力

意思決定事項ごとに前提条件を入力する。

要件ごとに論拠を入力する。

（RMS 外で行う作業）
意思決定ごとに適合性評価結果（要件毎）を入力する。

（RMS 外で行う作業）

意思決定事項ごとに結果を入力する。

付図 2 意思決定データの登録手順

付-4

D –5

(3) 検索・閲覧機能
要件管理システムは，前述したように膨大な量のさまざまなデータを記録・管理する。検索・閲
覧機能は，システムの利用目的に応じて，さまざまな観点から情報を検索し，表形式やツリー形式などで表示する。例えば，要件は，以下の方法で検索・閲覧を行うことができる。
a) 要件階層を用いた閲覧要件の階層構造をツリー型式で表示する。ユーザーは，ツリーを展開することにより，要件を順次閲覧することができる。
b) キーワードからの検索・閲覧
キーワード階層（処分場コンポーネントなど）をツリー型式で表示し，かつ，ツリー中のノードに関連する要件を表示する。
c) 設計因子からの検索・閲覧
特定の設計因子に関係付けられている要件を検索し，リスト型式で表示する。
d) 登録情報からの検索・閲覧
要件名称，登録日，登録者を用いて要件を検索し，リスト型式で表示する。
e) 参照データからの検索・閲覧
特定の参考文献やパラメータデータに関係付けられている要件を検索し，リスト型式で表示する。
また，意思決定も要件と同様に以下に示す方法で検索・閲覧を行うことができる。
a)

意思決定階層を用いた閲覧
意思決定の階層構造をツリー型式で表示する。ユーザーは，ツリーを展開することにより，意思決定を順次閲覧することができる。さらに，意思決定を展開することにより，関連する要件を閲覧することができる。
b)

キーワードからの検索・閲覧
キーワード階層（処分場コンポーネントなど）をツリー型式で表示し，かつ，ツリー中のノードに関連する意思決定を表示する。

c)ステータスからの検索・閲覧
意思決定のステータス（未実施，ペンディング，意思決定など）や承認のステータスを用いて意思決定を検索し，リスト型式で表示する。

d)

登録情報からの検索・閲覧
名称，登録日，登録者を用いて意思決定を検索し，リスト型式で表示する。

e)参照データからの検索・閲覧
特定の参考文献やパラメータデータに関係付けられている意思決定事項を検索し，リスト型
式で表示する。

(4) 変更管理・影響評価機能処分事業を進める過程では，技術の進歩や社会的制約条件の変化や概要調査地区の選定から精密調査地区の選定といった事業段階の進展に伴い，適宜，要件や意思決定の修正が行われる。変更管付-5

理・影響評価機能は，以下に示すように，意思決定や要件の変更履歴管理および要件の変更により影響を受ける意思決定の抽出などを行う。
① 意思決定および要件に関する変更履歴ログとして変更日付と変更者を管理する。
② 要件が変更された場合に影響を受ける意思決定を抽出する。
③ 意思決定が変更された場合に，影響を受ける他の意思決定を抽出する。
④ パラメータデータなどの関連情報が変更された場合に，影響を受ける意思決定を抽出する。
⑤ 参考文献を引用している意思決定や要件，論拠などを抽出する。
なお，②から④については，付図 3 に示すように影響を受けるデータを抽出・表示すると共に，
該当データに影響の旨を示すマークを付けることにより，利用者に影響の確認やデータの改訂を促し，意思決定の整合性を確保する。

意思決定 A ver.1
論拠 B は，意思決定 A を参照

意思決定 B

要件 B

論拠 B

意思決定 A がバージョンアップ
意思決定 A ver.2
論拠B に意思決定A が変更されたことを示すトリガー

意思決定 Bが設定される。
要件 B

論拠 B

付図 3 意思決定の整合性確保(5) 意思決定手順作成機能
意志決定階層構造は，作業対象となる項目（例えば，緩衝材）の構成に着目して作成されており，時系列での作業順序を考慮したものではない。要件管理システムでは，階層構造とは別に，意思決定の依存関係（情報の流れ）や人員リソースなどを考慮して決定された作業順序を表現する意思決
定手順ネットワークを作成する機能を提供する。本機能は，マウス操作を主体とした操作性の高い
ユーザーインターフェースを備え，付図 4 に示すようなネットワーク図を作成することができる。

付-6

付図 4 意思決定手順ネットワーク(6) 承認機能
承認機能は，要件，意思決定を対象として，承認行為を支援する。具体的には，付図 5 に示すようにデータ作成者が，データの作成が完了した後，承認者を決定し，承認を依頼する。その後，承認者は，該当データの承認を行う。なお，承認依頼が行われたデータは編集不可とし，承認拒否により差し戻された場合は，バージョンアップの上，データを改訂し，再度，承認を依頼する。

承認者

データ作成者
データ入力完了

承認者設定
承認依頼後は、データ
改訂は不可

承認依頼

バージョンアップ

データ改訂のため、バージョンアップを実施

記載内容確認
承認拒否
承認

再承認依頼

承認済みデータ

データ改訂

付図 5 承認フロー

付-7

(7) 印刷機能
本機能は，意思決定や要件，論拠，条件を印刷するため，これらデータを EXCEL®ファイルに流し込み帳票を自動作成する。また，意思決定の進捗管理を目的として，意思決定の一覧表を自動作成する。

(8) 入力ユーザーインターフェース機能
入力ユーザーインターフェース機能は，要件などのデータ入力作業の軽減および表記のゆれ防止を行うため，ユーザーのキーボード入力に従い，あらかじめ専用の辞書に登録された専門用語や典型的な表現を提示する。

付-8