部品構造
- 大部品: 玄霧藩国の治水事業（政策）（T23） RD:40 評価値:9
- 部品: 玄霧藩国の治水事業（政策）の概要
- 大部品: 玄霧藩国の基礎技術（藩国内汎用） RD:0 評価値:0
- 大部品: 治水事業（汎用） RD:39 評価値:9
- 大部品: 技術の用途（治水） RD:0 評価値:0
- 大部品: リスク対応事業（汎用） RD:39 評価値:9
- 部品: リスク対応事業（汎用）の概要
- 大部品: 事業計画 RD:4 評価値:3
- 部品: リスクの発見
- 部品: リスクの分析
- 部品: リスク対応
- 部品: リスク評価および対応リスクの選定
- 大部品: 藩国用開発プロジェクト（汎用） RD:34 評価値:8
- 部品: 概要
- 大部品: 要件定義 RD:4 評価値:3
- 部品: 要件定義とは
- 部品: ステークホルダの識別
- 部品: 要件および制約条件の抽出
- 部品: シナリオの定義および周辺環境への影響調査
- 大部品: システム設計 RD:4 評価値:3
- 部品: システム設計とは
- 部品: システムの検討・確立
- 部品: ユニットの識別
- 部品: システムテストの要件定義
- 大部品: ユニット設計 RD:4 評価値:3
- 部品: ユニット設計とは
- 部品: ユニットの詳細設計
- 部品: 共有ユニットへの反映
- 部品: ユニットテストの要件定義
- 大部品: 製造・構築 RD:4 評価値:3
- 部品: 製造・構築とは
- 部品: 段階的な詳細化
- 部品: 製造・構築の実施
- 部品: 確認
- 大部品: ユニットテスト RD:4 評価値:3
- 部品: ユニットテストとは
- 部品: ユニットテストの準備
- 部品: ユニットテストの実施
- 部品: 最も詳細なテスト
- 大部品: システムテスト RD:4 評価値:3
- 部品: システムテストとは
- 部品: システム結合
- 部品: システムテストの準備
- 部品: システムテストの実施
- 大部品: 運用テスト RD:3 評価値:3
- 部品: システムの導入
- 部品: 受入試験
- 部品: 教育訓練
- 大部品: 評価 RD:2 評価値:2
- 大部品: 管理 RD:4 評価値:3
- 部品: 管理とは
- 部品: 10の知識エリア
- 部品: 5つのプロセス
- 部品: ３つのパート
部品定義
部品: 玄霧藩国の治水事業（政策）の概要
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: リスク対応事業（汎用）の概要
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: リスクの発見
リスクについての検討を行うには、まず、どういったリスクがあるのかを洗い出さなければならない。
この時点では、リスクの大小、影響度合いなどを考慮せず、考えうる限りのリスクを列挙し、可能な限り起こりうるリスクを広くカバーすることが重要となる。
手法として、ブレーンストーミングなどを使用し、とにかく量を上げることが重要な作業といえる。
その他、思い込み等を排除するために、客観的な視点を入れることも重要といえる。
リスクを洗い出すメンバーが固定化されていると、その中で当たり前になってしまっていることなどは盲点として顧みられることなく見過ごされてしまうためである。
部品: リスクの分析
洗い出したリスクに対して、その発生確率と発生した際の影響の大きさをそれぞれ定量化して算出し、それぞれを乗算した値をリスクの重要度とする。
発生確率および影響の大きさは、定量化することが難しいことも多い。
そうした時には、どうしても定性的な評価から算出せざるを得ないが、そうした際には、なぜそうした値を算出したのか、後々検討、訂正が可能なように客観的な情報をもとに算出する必要がある。
部品: リスク対応
リスクそれぞれに対して、その発生確率と影響度に応じて、どのように対応するかを判定する。
対応は、下記の4種類に大別される。
また、それぞれの種類ごとに、情報セキュリティを事例として記載する。
この時、対応ごとに主に該当する発生確率と影響度の組み合わせを記載するが、大まかな分類であり、リスクの内容ごとに当てはあらないケースも存在することに留意すること。
1.リスクの低減
リスクの発生確率を下げる対応を指す。
例としては、PCやノートPCなどが紛失した際の情報漏洩の対策として、HDDの暗号化を行い、情報漏洩を起こりにくくすることなどが該当する。
主に、下記の条件を満たすリスクが該当する。
発生確率：中～高
影響度 ：低～高
2.リスクの回避
リスクの原因を停止、または別の方法に変更することにより、そもそもリスクが発生しなくなるようにする対応を指す。
情報セキュリティの事例では、外部からの不正アクセスを防ぐために、そもそも外部NWに接続しない環境にする、などがあげられる。
主に、下記の条件を満たすリスクが該当する。
発生確率：高
影響度 ：高
3.リスクの移転
リスクが顕在化した際の影響を他社に転嫁する対応。
情報セキュリティの事例では、リスク発生時に損害額を充当する保険を締結したり、リスクが発生する運用業務を他社に委託するなどの施策が該当する。
主に、下記の条件を満たすリスクが該当する。
発生確率：低
影響度 ：高
4.リスクの保有
リスクの存在を把握、管理するが、対策は行わない、という対応。
リスクの重要度（発生確率と影響度の積）が小さく、対策をとる必要性が少ないケースや、重要度が高いものの、とれる対策がないケースなどがこれに該当する。
主に、下記の条件を満たすリスクが該当する。
発生確率：低
影響度 ：低
※対応策が存在しない場合、発生確率や影響度に関係なく該当することがある。
部品: リスク評価および対応リスクの選定
これまで検討した結果および、与えられた予算、期間、人員などのリソースを考慮し、どのリスクの対応を行うかを選定する。
この時、必ずしも重要度の高い（リスクの影響の大きさと発生確率の積が大きい）リスクが優先されるとは限らない。リスクはすべてが独立しているとは限らないため、一つのリスクを対処してしまえば、関連して複数のリスクが解決することもある。その和が重要度の高いリスクの解決よりも大きいのであれば、優先度は前後する。
また、リスク対応にかかる時間的、金銭的、工数などの総合的なコストにも影響を受ける。
部品: 概要
■プロジェクトとはなにか
プロジェクトとは、なにかの目的を達成するための手段として、独自のモノやサービス、何らかの結果（資格取得等）を取得するための、期限が定められた業務のことをいう。
■前提条件
このアイドレスは、下記を前提とする。
- このプロジェクトは、藩国全域に影響を及ぼす。
- このプロジェクトを遂行することでどのような目的を達成するか、藩国の事業計画が明確に定められている。
- このプロジェクトを達成するための周辺技術は、このアイドレスの呼び出し元で作成されている。
■本アイドレスの構成について
本アイドレスは、開発プロジェクトにおける工程を基準として大部品を分割、構成している。
内部の大部品の規模については、おおむね、情報システム開発時の各工程ごとに、工数の標準比率に従っている。
■開発のV字モデル
製造・構築および管理を除く各工程は、設計もしくは計画と、それに対する試験とで対応している。
本アイドレスにおける対応は下記の通り。
下に記載されていればいるほど、より詳細なレベルの設計およびそれに対する試験を行う。
（事業計画については、前提条件を参照）
事業計画 ⇔ 評価
要件定義 ⇔ 運用テスト
システム設計 ⇔ システムテスト
ユニット設計 ⇔ ユニットテスト
■ユニットについて
本アイドレスでは、要件を達成するための全体をシステム、システムを構成する要素をユニットと記載する。
また、ユニットとユニットを連結する規格をインターフェースと記載する。
システムとユニットの関係は、アイドレスにおける大部品と部品の関係に近しい。
大部品の中に大部品が存在するように、ユニットはより詳細なレベルにおけるシステムであることもある。
これに関連して、製造・構築の工程においては、より詳細なレベルの開発プロジェクトが再帰的に遂行されることがある。
この時、アイドレスの評価としては再帰的に加算しないこと。
■各工程ごとに共通の要素について
複数の工程において繰り返し発生する作業について、下記に記載する。
- 前工程の成果物との紐づけの確認（要件定義～製造・構築）
- 利用者用文書の作成または更新
- 成果物の評価
部品: 要件定義とは
要件定義は、その環境において、ステークホルダが必要とするシステムの要件を定義することを目的とする。
要件とは、企画プロセスで検討した目的を達成するための基準と言い換えることもできる。
要件で定められた基準をすべて満たすことができれば、企画プロセスで策定した目的を満たすことができる、という構成要素の一覧ともいえる。
この時に重要なのは、企画で策定した目的を満たすための要件をすべて網羅していること、および、その達成が客観的に判定できること、という点である。
目的に対し、要件が網羅されていなければ、それ以降の作業をどれだけ完璧に進めることができたとしても、完成したシステムが目的を達成することはできない。
また、達成基準があいまいである場合には、発注者と受注者の間でのトラブルが発生しやすい。
情報システム開発のための資料ではあるが、要件定義について、17ヶ条の原理原則が存在するため参考として下記に記載する。
要件定義の成否はプロジェクト全体の成否に大きく影響するため、下記の原理原則はすべて順守することが望ましい。
原理原則［１］ユーザとベンダの想いは相反する
原理原則［２］取り決めは合意と承認によって成り立つ
原理原則［３］プロジェクトの成否を左右する要件確定の先送りは厳禁である
原理原則［４］ステークホルダ間の合意を得ないまま、次工程に入らない
原理原則［５］多段階の見積りは双方のリスクを低減する
原理原則［６］システム化実現の費用はソフトウェア開発だけではない
原理原則［７］ライフサイクルコストを重視する
原理原則［８］システム化方針・狙いの周知徹底が成功の鍵となる
原理原則［９］要件定義は発注者の責任である
原理原則［１０］要件定義書はバイブルであり、事あらばここへ立ち返るもの
原理原則［１１］優れた要件定義書とはシステム開発を精緻にあらわしたもの
原理原則［１２］表現されない要件はシステムとして実現されない
原理原則［１３］数値化されない要件は人によって基準が異なる
原理原則［１４］「今と同じ」という要件定義はありえない
原理原則［１５］要件定義は「使える」業務システムを定義すること
原理原則［１６］機能要求は膨張する。コスト、納期が抑制する
原理原則［１７］要件定義は説明責任を伴う
出典：IPA－SEC「超上流から攻める IT 化の原理原則１７ヶ条」
部品: ステークホルダの識別
要件定義では、システムのライフサイクル（開発から運用、廃棄までを通じた全期間）を通じた、システムに正当な利害関係を持つ利害関係者（ステークホルダ）、および利害関係者の種類を識別する必要がある。
これには、たとえば利用者、運用者、支援者、開発者、製作者、教育訓練者、保守者、廃棄者、取得者及び供給者の組織、外部に対して対応の責任を負う当事者、規制機関並びに社会の構成員などが含まれる。
これは、要件定義においては、要件はすべてのステークホルダの要望を満たしておく必要があるためである。
その前段階として、すべてのステークホルダを識別しなければならない。
部品: 要件および制約条件の抽出
識別したステークホルダごとの要件を引き出し、識別する必要がある。
このためには、まずステークホルダごとに、ニーズ、欲求、要望、期待、制約条件などを記述する。
これらは要件を識別するためのインプット、背景となる。
部品: シナリオの定義および周辺環境への影響調査
これらの背景をもとに、想定された一連の状況において、どのようにシステムを利用するかを定義したシナリオを網羅的に記載する。
この時、シナリオごとに、システムとステークホルダ、または外部システムとどのように相互にやり取りをするかを理解できるようにすることが目的となる。
これらのシナリオは、すべての利用状況を網羅的に用意する必要がある。
システムは、これらのシナリオをすべて想定通りに実施することができれば、要件を満たすといえるためである。
またこの時、健康、安全、セキュリティ、環境および他のステークホルダの要件、重大な品質に関係する機能について、知類の健康および安全に対する、システムの仕様が及ぼ悪影響の可能性に対処するよう検討する櫃王がある。
部品: システム設計とは
システム設計は、システムを設計する工程である。
では、システムとは何か。
システムとは、目標（要件）を達成するための設備（ハードウェア）であり、ソフトウェアであり、それを利用する手順であり、操作する知類であり、それらすべてを包含する業務である。
すなわち、システム設計とは要件で定められた目的を達成するためには、どのような業務を行うのが最適であるかを検討する工程であるといえる。
つまり、システム設計では、業務を構成するそれぞれの作業を担当すべきなのはハードウェアなのか、ソフトウェアなのか、知類なのかを適切に振り分け、それぞれの要素間で何を受け渡すのか（インターフェース）を設計、検討する工程である。
また、システム設計は業務を検討する工程であるため、この時点でシステムを利用する知類向けの文書の暫定版をあらかじめ用意しておくことが望ましい。
部品: システムの検討・確立
部品「システム設計とは」で定義した通り、要件を達成するためのシステム（≒業務）を検討する。
この時、要件および制約条件を満たした業務の流れを明記するために、業務フローなどの成果物を用意することが好ましい。
またこの時、業務を構成するそれぞれの作業に対する要件を整理しておく必要があるほか、予め要件定義で提示された要件に対し、抜け漏れがないことを確認しながら進めなくてはならない。
部品: ユニットの識別
部品「システムの検討・確立」を元に、システムを構成する要素（ハードウェア、ソフトウェア、知類等）を一覧化し、それぞれが満たさなければならない要件を整理する。
ここで定義した要件は、以降の工程（ユニット設計）における要件となる。
部品: システムテストの要件定義
部品「システムの検討・確立」で整理した業務内容をもとに、予めテストで確認しなければならない事項を整理、検討する。
実施はすべてのユニットの製造・構築が完了した後に実施されるが、それまでには長い時間がかかり、目的や要件を見失いやすく、また、途中で要件が変更になることも多い。
このため、予めテストの要件を定めておき、それを常に最新化できるための土台を用意しておくことは、次工程以降の混乱を防止するために極めて重要な作業といえる。
部品: ユニット設計とは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットの詳細設計
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 共有ユニットへの反映
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットテストの要件定義
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 製造・構築とは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 段階的な詳細化
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 製造・構築の実施
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 確認
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットテストとは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットテストの準備
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットテストの実施
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 最も詳細なテスト
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システムテストとは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システム結合
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システムテストの準備
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システムテストの実施
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システムの導入
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 受入試験
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 教育訓練
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 導入
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 効果測定・評価
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 管理とは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 10の知識エリア
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 5つのプロセス
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ３つのパート
ああああああああああああああああああああああああああああああああああああああああああああああああああ
提出書式
大部品: 玄霧藩国の治水事業（政策）（T23） RD:40 評価値:9
-部品: 玄霧藩国の治水事業（政策）の概要
-大部品: 玄霧藩国の基礎技術（藩国内汎用） RD:0 評価値:0
-大部品: 治水事業（汎用） RD:39 評価値:9
--大部品: 技術の用途（治水） RD:0 評価値:0
--大部品: リスク対応事業（汎用） RD:39 評価値:9
---部品: リスク対応事業（汎用）の概要
---大部品: 事業計画 RD:4 評価値:3
----部品: リスクの発見
----部品: リスクの分析
----部品: リスク対応
----部品: リスク評価および対応リスクの選定
---大部品: 藩国用開発プロジェクト（汎用） RD:34 評価値:8
----部品: 概要
----大部品: 要件定義 RD:4 評価値:3
-----部品: 要件定義とは
-----部品: ステークホルダの識別
-----部品: 要件および制約条件の抽出
-----部品: シナリオの定義および周辺環境への影響調査
----大部品: システム設計 RD:4 評価値:3
-----部品: システム設計とは
-----部品: システムの検討・確立
-----部品: ユニットの識別
-----部品: システムテストの要件定義
----大部品: ユニット設計 RD:4 評価値:3
-----部品: ユニット設計とは
-----部品: ユニットの詳細設計
-----部品: 共有ユニットへの反映
-----部品: ユニットテストの要件定義
----大部品: 製造・構築 RD:4 評価値:3
-----部品: 製造・構築とは
-----部品: 段階的な詳細化
-----部品: 製造・構築の実施
-----部品: 確認
----大部品: ユニットテスト RD:4 評価値:3
-----部品: ユニットテストとは
-----部品: ユニットテストの準備
-----部品: ユニットテストの実施
-----部品: 最も詳細なテスト
----大部品: システムテスト RD:4 評価値:3
-----部品: システムテストとは
-----部品: システム結合
-----部品: システムテストの準備
-----部品: システムテストの実施
----大部品: 運用テスト RD:3 評価値:3
-----部品: システムの導入
-----部品: 受入試験
-----部品: 教育訓練
----大部品: 評価 RD:2 評価値:2
-----部品: 導入
-----部品: 効果測定・評価
----大部品: 管理 RD:4 評価値:3
-----部品: 管理とは
-----部品: 10の知識エリア
-----部品: 5つのプロセス
-----部品: ３つのパート
部品: 玄霧藩国の治水事業（政策）の概要
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: リスク対応事業（汎用）の概要
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: リスクの発見
リスクについての検討を行うには、まず、どういったリスクがあるのかを洗い出さなければならない。
この時点では、リスクの大小、影響度合いなどを考慮せず、考えうる限りのリスクを列挙し、可能な限り起こりうるリスクを広くカバーすることが重要となる。
手法として、ブレーンストーミングなどを使用し、とにかく量を上げることが重要な作業といえる。
その他、思い込み等を排除するために、客観的な視点を入れることも重要といえる。
リスクを洗い出すメンバーが固定化されていると、その中で当たり前になってしまっていることなどは盲点として顧みられることなく見過ごされてしまうためである。
部品: リスクの分析
洗い出したリスクに対して、その発生確率と発生した際の影響の大きさをそれぞれ定量化して算出し、それぞれを乗算した値をリスクの重要度とする。
発生確率および影響の大きさは、定量化することが難しいことも多い。
そうした時には、どうしても定性的な評価から算出せざるを得ないが、そうした際には、なぜそうした値を算出したのか、後々検討、訂正が可能なように客観的な情報をもとに算出する必要がある。
部品: リスク対応
リスクそれぞれに対して、その発生確率と影響度に応じて、どのように対応するかを判定する。
対応は、下記の4種類に大別される。
また、それぞれの種類ごとに、情報セキュリティを事例として記載する。
この時、対応ごとに主に該当する発生確率と影響度の組み合わせを記載するが、大まかな分類であり、リスクの内容ごとに当てはあらないケースも存在することに留意すること。
1.リスクの低減
リスクの発生確率を下げる対応を指す。
例としては、PCやノートPCなどが紛失した際の情報漏洩の対策として、HDDの暗号化を行い、情報漏洩を起こりにくくすることなどが該当する。
主に、下記の条件を満たすリスクが該当する。
発生確率：中～高
影響度 ：低～高
2.リスクの回避
リスクの原因を停止、または別の方法に変更することにより、そもそもリスクが発生しなくなるようにする対応を指す。
情報セキュリティの事例では、外部からの不正アクセスを防ぐために、そもそも外部NWに接続しない環境にする、などがあげられる。
主に、下記の条件を満たすリスクが該当する。
発生確率：高
影響度 ：高
3.リスクの移転
リスクが顕在化した際の影響を他社に転嫁する対応。
情報セキュリティの事例では、リスク発生時に損害額を充当する保険を締結したり、リスクが発生する運用業務を他社に委託するなどの施策が該当する。
主に、下記の条件を満たすリスクが該当する。
発生確率：低
影響度 ：高
4.リスクの保有
リスクの存在を把握、管理するが、対策は行わない、という対応。
リスクの重要度（発生確率と影響度の積）が小さく、対策をとる必要性が少ないケースや、重要度が高いものの、とれる対策がないケースなどがこれに該当する。
主に、下記の条件を満たすリスクが該当する。
発生確率：低
影響度 ：低
※対応策が存在しない場合、発生確率や影響度に関係なく該当することがある。
部品: リスク評価および対応リスクの選定
これまで検討した結果および、与えられた予算、期間、人員などのリソースを考慮し、どのリスクの対応を行うかを選定する。
この時、必ずしも重要度の高い（リスクの影響の大きさと発生確率の積が大きい）リスクが優先されるとは限らない。リスクはすべてが独立しているとは限らないため、一つのリスクを対処してしまえば、関連して複数のリスクが解決することもある。その和が重要度の高いリスクの解決よりも大きいのであれば、優先度は前後する。
また、リスク対応にかかる時間的、金銭的、工数などの総合的なコストにも影響を受ける。
部品: 概要
■プロジェクトとはなにか
プロジェクトとは、なにかの目的を達成するための手段として、独自のモノやサービス、何らかの結果（資格取得等）を取得するための、期限が定められた業務のことをいう。
■前提条件
このアイドレスは、下記を前提とする。
・このプロジェクトは、藩国全域に影響を及ぼす。
・このプロジェクトを遂行することでどのような目的を達成するか、藩国の事業計画が明確に定められている。
・このプロジェクトを達成するための周辺技術は、このアイドレスの呼び出し元で作成されている。
■本アイドレスの構成について
本アイドレスは、開発プロジェクトにおける工程を基準として大部品を分割、構成している。
内部の大部品の規模については、おおむね、情報システム開発時の各工程ごとに、工数の標準比率に従っている。
■開発のV字モデル
製造・構築および管理を除く各工程は、設計もしくは計画と、それに対する試験とで対応している。
本アイドレスにおける対応は下記の通り。
下に記載されていればいるほど、より詳細なレベルの設計およびそれに対する試験を行う。
（事業計画については、前提条件を参照）
事業計画 ⇔ 評価
要件定義 ⇔ 運用テスト
システム設計 ⇔ システムテスト
ユニット設計 ⇔ ユニットテスト
■ユニットについて
本アイドレスでは、要件を達成するための全体をシステム、システムを構成する要素をユニットと記載する。
また、ユニットとユニットを連結する規格をインターフェースと記載する。
システムとユニットの関係は、アイドレスにおける大部品と部品の関係に近しい。
大部品の中に大部品が存在するように、ユニットはより詳細なレベルにおけるシステムであることもある。
これに関連して、製造・構築の工程においては、より詳細なレベルの開発プロジェクトが再帰的に遂行されることがある。
この時、アイドレスの評価としては再帰的に加算しないこと。
■各工程ごとに共通の要素について
複数の工程において繰り返し発生する作業について、下記に記載する。
・前工程の成果物との紐づけの確認（要件定義～製造・構築）
・利用者用文書の作成または更新
・成果物の評価
部品: 要件定義とは
要件定義は、その環境において、ステークホルダが必要とするシステムの要件を定義することを目的とする。
要件とは、企画プロセスで検討した目的を達成するための基準と言い換えることもできる。
要件で定められた基準をすべて満たすことができれば、企画プロセスで策定した目的を満たすことができる、という構成要素の一覧ともいえる。
この時に重要なのは、企画で策定した目的を満たすための要件をすべて網羅していること、および、その達成が客観的に判定できること、という点である。
目的に対し、要件が網羅されていなければ、それ以降の作業をどれだけ完璧に進めることができたとしても、完成したシステムが目的を達成することはできない。
また、達成基準があいまいである場合には、発注者と受注者の間でのトラブルが発生しやすい。
情報システム開発のための資料ではあるが、要件定義について、17ヶ条の原理原則が存在するため参考として下記に記載する。
要件定義の成否はプロジェクト全体の成否に大きく影響するため、下記の原理原則はすべて順守することが望ましい。
原理原則［１］ユーザとベンダの想いは相反する
原理原則［２］取り決めは合意と承認によって成り立つ
原理原則［３］プロジェクトの成否を左右する要件確定の先送りは厳禁である
原理原則［４］ステークホルダ間の合意を得ないまま、次工程に入らない
原理原則［５］多段階の見積りは双方のリスクを低減する
原理原則［６］システム化実現の費用はソフトウェア開発だけではない
原理原則［７］ライフサイクルコストを重視する
原理原則［８］システム化方針・狙いの周知徹底が成功の鍵となる
原理原則［９］要件定義は発注者の責任である
原理原則［１０］要件定義書はバイブルであり、事あらばここへ立ち返るもの
原理原則［１１］優れた要件定義書とはシステム開発を精緻にあらわしたもの
原理原則［１２］表現されない要件はシステムとして実現されない
原理原則［１３］数値化されない要件は人によって基準が異なる
原理原則［１４］「今と同じ」という要件定義はありえない
原理原則［１５］要件定義は「使える」業務システムを定義すること
原理原則［１６］機能要求は膨張する。コスト、納期が抑制する
原理原則［１７］要件定義は説明責任を伴う
出典：IPA－SEC「超上流から攻める IT 化の原理原則１７ヶ条」
詳細は下記URLを参照。
https://www.ipa.go.jp/files/000005109.pdf
部品: ステークホルダの識別
要件定義では、システムのライフサイクル（開発から運用、廃棄までを通じた全期間）を通じた、システムに正当な利害関係を持つ利害関係者（ステークホルダ）、および利害関係者の種類を識別する必要がある。
これには、たとえば利用者、運用者、支援者、開発者、製作者、教育訓練者、保守者、廃棄者、取得者及び供給者の組織、外部に対して対応の責任を負う当事者、規制機関並びに社会の構成員などが含まれる。
これは、要件定義においては、要件はすべてのステークホルダの要望を満たしておく必要があるためである。
その前段階として、すべてのステークホルダを識別しなければならない。
部品: 要件および制約条件の抽出
識別したステークホルダごとの要件を引き出し、識別する必要がある。
このためには、まずステークホルダごとに、ニーズ、欲求、要望、期待、制約条件などを記述する。
これらは要件を識別するためのインプット、背景となる。
部品: シナリオの定義および周辺環境への影響調査
これらの背景をもとに、想定された一連の状況において、どのようにシステムを利用するかを定義したシナリオを網羅的に記載する。
この時、シナリオごとに、システムとステークホルダ、または外部システムとどのように相互にやり取りをするかを理解できるようにすることが目的となる。
これらのシナリオは、すべての利用状況を網羅的に用意する必要がある。
システムは、これらのシナリオをすべて想定通りに実施することができれば、要件を満たすといえるためである。
またこの時、健康、安全、セキュリティ、環境および他のステークホルダの要件、重大な品質に関係する機能について、知類の健康および安全に対する、システムの仕様が及ぼ悪影響の可能性に対処するよう検討する櫃王がある。
部品: システム設計とは
システム設計は、システムを設計する工程である。
では、システムとは何か。
システムとは、目標（要件）を達成するための設備（ハードウェア）であり、ソフトウェアであり、それを利用する手順であり、操作する知類であり、それらすべてを包含する業務である。
すなわち、システム設計とは要件で定められた目的を達成するためには、どのような業務を行うのが最適であるかを検討する工程であるといえる。
つまり、システム設計では、業務を構成するそれぞれの作業を担当すべきなのはハードウェアなのか、ソフトウェアなのか、知類なのかを適切に振り分け、それぞれの要素間で何を受け渡すのか（インターフェース）を設計、検討する工程である。
また、システム設計は業務を検討する工程であるため、この時点でシステムを利用する知類向けの文書の暫定版をあらかじめ用意しておくことが望ましい。
部品: システムの検討・確立
部品「システム設計とは」で定義した通り、要件を達成するためのシステム（≒業務）を検討する。
この時、要件および制約条件を満たした業務の流れを明記するために、業務フローなどの成果物を用意することが好ましい。
またこの時、業務を構成するそれぞれの作業に対する要件を整理しておく必要があるほか、予め要件定義で提示された要件に対し、抜け漏れがないことを確認しながら進めなくてはならない。
部品: ユニットの識別
部品「システムの検討・確立」を元に、システムを構成する要素（ハードウェア、ソフトウェア、知類等）を一覧化し、それぞれが満たさなければならない要件を整理する。
ここで定義した要件は、以降の工程（ユニット設計）における要件となる。
部品: システムテストの要件定義
部品「システムの検討・確立」で整理した業務内容をもとに、予めテストで確認しなければならない事項を整理、検討する。
実施はすべてのユニットの製造・構築が完了した後に実施されるが、それまでには長い時間がかかり、目的や要件を見失いやすく、また、途中で要件が変更になることも多い。
このため、予めテストの要件を定めておき、それを常に最新化できるための土台を用意しておくことは、次工程以降の混乱を防止するために極めて重要な作業といえる。
部品: ユニット設計とは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットの詳細設計
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 共有ユニットへの反映
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットテストの要件定義
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 製造・構築とは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 段階的な詳細化
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 製造・構築の実施
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 確認
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットテストとは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットテストの準備
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ユニットテストの実施
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 最も詳細なテスト
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システムテストとは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システム結合
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システムテストの準備
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システムテストの実施
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: システムの導入
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 受入試験
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 教育訓練
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 導入
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 効果測定・評価
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 管理とは
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 10の知識エリア
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: 5つのプロセス
ああああああああああああああああああああああああああああああああああああああああああああああああああ
部品: ３つのパート
ああああああああああああああああああああああああああああああああああああああああああああああああああ
インポート用定義データ
[
{
"title": "玄霧藩国の治水事業（政策）（T23）",
"part_type": "group",
"children": [
{
"title": "玄霧藩国の治水事業（政策）の概要",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 1
},
{
"title": "玄霧藩国の基礎技術（藩国内汎用）",
"description": "",
"part_type": "group",
"children": [],
"localID": 2,
"expanded": true
},
{
"title": "治水事業（汎用）",
"description": "",
"part_type": "group",
"children": [
{
"title": "技術の用途（治水）",
"description": "",
"part_type": "group",
"children": [],
"localID": 4,
"expanded": true
},
{
"title": "リスク対応事業（汎用）",
"description": "",
"part_type": "group",
"children": [
{
"title": "リスク対応事業（汎用）の概要",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 6
},
{
"title": "事業計画",
"description": "",
"part_type": "group",
"children": [
{
"title": "リスクの発見",
"description": "リスクについての検討を行うには、まず、どういったリスクがあるのかを洗い出さなければならない。\nこの時点では、リスクの大小、影響度合いなどを考慮せず、考えうる限りのリスクを列挙し、可能な限り起こりうるリスクを広くカバーすることが重要となる。\n手法として、ブレーンストーミングなどを使用し、とにかく量を上げることが重要な作業といえる。\n\nその他、思い込み等を排除するために、客観的な視点を入れることも重要といえる。\nリスクを洗い出すメンバーが固定化されていると、その中で当たり前になってしまっていることなどは盲点として顧みられることなく見過ごされてしまうためである。",
"part_type": "part",
"localID": 8
},
{
"title": "リスクの分析",
"description": "洗い出したリスクに対して、その発生確率と発生した際の影響の大きさをそれぞれ定量化して算出し、それぞれを乗算した値をリスクの重要度とする。\n\n発生確率および影響の大きさは、定量化することが難しいことも多い。\nそうした時には、どうしても定性的な評価から算出せざるを得ないが、そうした際には、なぜそうした値を算出したのか、後々検討、訂正が可能なように客観的な情報をもとに算出する必要がある。",
"part_type": "part",
"localID": 9
},
{
"title": "リスク対応",
"description": "リスクそれぞれに対して、その発生確率と影響度に応じて、どのように対応するかを判定する。\n対応は、下記の4種類に大別される。\nまた、それぞれの種類ごとに、情報セキュリティを事例として記載する。\nこの時、対応ごとに主に該当する発生確率と影響度の組み合わせを記載するが、大まかな分類であり、リスクの内容ごとに当てはあらないケースも存在することに留意すること。\n\n1.リスクの低減\nリスクの発生確率を下げる対応を指す。\n例としては、PCやノートPCなどが紛失した際の情報漏洩の対策として、HDDの暗号化を行い、情報漏洩を起こりにくくすることなどが該当する。\n主に、下記の条件を満たすリスクが該当する。\n発生確率：中～高\n影響度 ：低～高\n\n2.リスクの回避\nリスクの原因を停止、または別の方法に変更することにより、そもそもリスクが発生しなくなるようにする対応を指す。\n情報セキュリティの事例では、外部からの不正アクセスを防ぐために、そもそも外部NWに接続しない環境にする、などがあげられる。\n主に、下記の条件を満たすリスクが該当する。\n発生確率：高\n影響度 ：高\n\n3.リスクの移転\nリスクが顕在化した際の影響を他社に転嫁する対応。\n情報セキュリティの事例では、リスク発生時に損害額を充当する保険を締結したり、リスクが発生する運用業務を他社に委託するなどの施策が該当する。\n主に、下記の条件を満たすリスクが該当する。\n発生確率：低\n影響度 ：高\n\n4.リスクの保有\nリスクの存在を把握、管理するが、対策は行わない、という対応。\nリスクの重要度（発生確率と影響度の積）が小さく、対策をとる必要性が少ないケースや、重要度が高いものの、とれる対策がないケースなどがこれに該当する。\n主に、下記の条件を満たすリスクが該当する。\n発生確率：低\n影響度 ：低\n※対応策が存在しない場合、発生確率や影響度に関係なく該当することがある。\n",
"part_type": "part",
"localID": 10
},
{
"title": "リスク評価および対応リスクの選定",
"description": "これまで検討した結果および、与えられた予算、期間、人員などのリソースを考慮し、どのリスクの対応を行うかを選定する。\n\nこの時、必ずしも重要度の高い（リスクの影響の大きさと発生確率の積が大きい）リスクが優先されるとは限らない。リスクはすべてが独立しているとは限らないため、一つのリスクを対処してしまえば、関連して複数のリスクが解決することもある。その和が重要度の高いリスクの解決よりも大きいのであれば、優先度は前後する。\nまた、リスク対応にかかる時間的、金銭的、工数などの総合的なコストにも影響を受ける。",
"part_type": "part",
"localID": 11
}
],
"localID": 7,
"expanded": true
},
{
"title": "藩国用開発プロジェクト（汎用）",
"description": "",
"part_type": "group",
"children": [
{
"title": "概要",
"description": "■プロジェクトとはなにか\nプロジェクトとは、なにかの目的を達成するための手段として、独自のモノやサービス、何らかの結果（資格取得等）を取得するための、期限が定められた業務のことをいう。\n\n\n■前提条件\nこのアイドレスは、下記を前提とする。\n\n・このプロジェクトは、藩国全域に影響を及ぼす。\n・このプロジェクトを遂行することでどのような目的を達成するか、藩国の事業計画が明確に定められている。\n・このプロジェクトを達成するための周辺技術は、このアイドレスの呼び出し元で作成されている。\n\n■本アイドレスの構成について\n本アイドレスは、開発プロジェクトにおける工程を基準として大部品を分割、構成している。\n内部の大部品の規模については、おおむね、情報システム開発時の各工程ごとに、工数の標準比率に従っている。\n\n■開発のV字モデル\n製造・構築および管理を除く各工程は、設計もしくは計画と、それに対する試験とで対応している。\n本アイドレスにおける対応は下記の通り。\n下に記載されていればいるほど、より詳細なレベルの設計およびそれに対する試験を行う。\n（事業計画については、前提条件を参照）\n\n事業計画 ⇔ 評価\n要件定義 ⇔ 運用テスト\nシステム設計 ⇔ システムテスト\nユニット設計 ⇔ ユニットテスト\n\n■ユニットについて\n本アイドレスでは、要件を達成するための全体をシステム、システムを構成する要素をユニットと記載する。\nまた、ユニットとユニットを連結する規格をインターフェースと記載する。\nシステムとユニットの関係は、アイドレスにおける大部品と部品の関係に近しい。\n大部品の中に大部品が存在するように、ユニットはより詳細なレベルにおけるシステムであることもある。\nこれに関連して、製造・構築の工程においては、より詳細なレベルの開発プロジェクトが再帰的に遂行されることがある。\nこの時、アイドレスの評価としては再帰的に加算しないこと。\n\n■各工程ごとに共通の要素について\n複数の工程において繰り返し発生する作業について、下記に記載する。\n・前工程の成果物との紐づけの確認（要件定義～製造・構築）\n・利用者用文書の作成または更新\n・成果物の評価",
"part_type": "part",
"localID": 13
},
{
"title": "要件定義",
"description": "",
"part_type": "group",
"children": [
{
"title": "要件定義とは",
"description": "要件定義は、その環境において、ステークホルダが必要とするシステムの要件を定義することを目的とする。\n要件とは、企画プロセスで検討した目的を達成するための基準と言い換えることもできる。\n要件で定められた基準をすべて満たすことができれば、企画プロセスで策定した目的を満たすことができる、という構成要素の一覧ともいえる。\n\nこの時に重要なのは、企画で策定した目的を満たすための要件をすべて網羅していること、および、その達成が客観的に判定できること、という点である。\n目的に対し、要件が網羅されていなければ、それ以降の作業をどれだけ完璧に進めることができたとしても、完成したシステムが目的を達成することはできない。\nまた、達成基準があいまいである場合には、発注者と受注者の間でのトラブルが発生しやすい。\n\n情報システム開発のための資料ではあるが、要件定義について、17ヶ条の原理原則が存在するため参考として下記に記載する。\n要件定義の成否はプロジェクト全体の成否に大きく影響するため、下記の原理原則はすべて順守することが望ましい。\n\n原理原則［１］ユーザとベンダの想いは相反する\n原理原則［２］取り決めは合意と承認によって成り立つ\n原理原則［３］プロジェクトの成否を左右する要件確定の先送りは厳禁である\n原理原則［４］ステークホルダ間の合意を得ないまま、次工程に入らない\n原理原則［５］多段階の見積りは双方のリスクを低減する\n原理原則［６］システム化実現の費用はソフトウェア開発だけではない\n原理原則［７］ライフサイクルコストを重視する\n原理原則［８］システム化方針・狙いの周知徹底が成功の鍵となる\n原理原則［９］要件定義は発注者の責任である\n原理原則［１０］要件定義書はバイブルであり、事あらばここへ立ち返るもの\n原理原則［１１］優れた要件定義書とはシステム開発を精緻にあらわしたもの\n原理原則［１２］表現されない要件はシステムとして実現されない\n原理原則［１３］数値化されない要件は人によって基準が異なる\n原理原則［１４］「今と同じ」という要件定義はありえない\n原理原則［１５］要件定義は「使える」業務システムを定義すること\n原理原則［１６］機能要求は膨張する。コスト、納期が抑制する\n原理原則［１７］要件定義は説明責任を伴う\n出典：IPA－SEC「超上流から攻める IT 化の原理原則１７ヶ条」\n\n詳細は下記URLを参照。\nhttps://www.ipa.go.jp/files/000005109.pdf",
"part_type": "part",
"localID": 15
},
{
"title": "ステークホルダの識別",
"description": "要件定義では、システムのライフサイクル（開発から運用、廃棄までを通じた全期間）を通じた、システムに正当な利害関係を持つ利害関係者（ステークホルダ）、および利害関係者の種類を識別する必要がある。\nこれには、たとえば利用者、運用者、支援者、開発者、製作者、教育訓練者、保守者、廃棄者、取得者及び供給者の組織、外部に対して対応の責任を負う当事者、規制機関並びに社会の構成員などが含まれる。\n\nこれは、要件定義においては、要件はすべてのステークホルダの要望を満たしておく必要があるためである。\nその前段階として、すべてのステークホルダを識別しなければならない。",
"part_type": "part",
"localID": 16
},
{
"title": "要件および制約条件の抽出",
"description": "識別したステークホルダごとの要件を引き出し、識別する必要がある。\nこのためには、まずステークホルダごとに、ニーズ、欲求、要望、期待、制約条件などを記述する。\nこれらは要件を識別するためのインプット、背景となる。\n",
"part_type": "part",
"localID": 17
},
{
"title": "シナリオの定義および周辺環境への影響調査",
"description": "これらの背景をもとに、想定された一連の状況において、どのようにシステムを利用するかを定義したシナリオを網羅的に記載する。\nこの時、シナリオごとに、システムとステークホルダ、または外部システムとどのように相互にやり取りをするかを理解できるようにすることが目的となる。\n\nこれらのシナリオは、すべての利用状況を網羅的に用意する必要がある。\nシステムは、これらのシナリオをすべて想定通りに実施することができれば、要件を満たすといえるためである。\n\nまたこの時、健康、安全、セキュリティ、環境および他のステークホルダの要件、重大な品質に関係する機能について、知類の健康および安全に対する、システムの仕様が及ぼ悪影響の可能性に対処するよう検討する櫃王がある。",
"part_type": "part",
"localID": 18
}
],
"localID": 14,
"expanded": true
},
{
"title": "システム設計",
"description": "",
"part_type": "group",
"children": [
{
"title": "システム設計とは",
"description": "システム設計は、システムを設計する工程である。\nでは、システムとは何か。\nシステムとは、目標（要件）を達成するための設備（ハードウェア）であり、ソフトウェアであり、それを利用する手順であり、操作する知類であり、それらすべてを包含する業務である。\nすなわち、システム設計とは要件で定められた目的を達成するためには、どのような業務を行うのが最適であるかを検討する工程であるといえる。\n\nつまり、システム設計では、業務を構成するそれぞれの作業を担当すべきなのはハードウェアなのか、ソフトウェアなのか、知類なのかを適切に振り分け、それぞれの要素間で何を受け渡すのか（インターフェース）を設計、検討する工程である。\n\nまた、システム設計は業務を検討する工程であるため、この時点でシステムを利用する知類向けの文書の暫定版をあらかじめ用意しておくことが望ましい。\n",
"part_type": "part",
"localID": 20
},
{
"title": "システムの検討・確立",
"description": "部品「システム設計とは」で定義した通り、要件を達成するためのシステム（≒業務）を検討する。\nこの時、要件および制約条件を満たした業務の流れを明記するために、業務フローなどの成果物を用意することが好ましい。\nまたこの時、業務を構成するそれぞれの作業に対する要件を整理しておく必要があるほか、予め要件定義で提示された要件に対し、抜け漏れがないことを確認しながら進めなくてはならない。",
"part_type": "part",
"localID": 21
},
{
"title": "ユニットの識別",
"description": "部品「システムの検討・確立」を元に、システムを構成する要素（ハードウェア、ソフトウェア、知類等）を一覧化し、それぞれが満たさなければならない要件を整理する。\nここで定義した要件は、以降の工程（ユニット設計）における要件となる。",
"part_type": "part",
"localID": 22
},
{
"title": "システムテストの要件定義",
"description": "部品「システムの検討・確立」で整理した業務内容をもとに、予めテストで確認しなければならない事項を整理、検討する。\n実施はすべてのユニットの製造・構築が完了した後に実施されるが、それまでには長い時間がかかり、目的や要件を見失いやすく、また、途中で要件が変更になることも多い。\nこのため、予めテストの要件を定めておき、それを常に最新化できるための土台を用意しておくことは、次工程以降の混乱を防止するために極めて重要な作業といえる。",
"part_type": "part",
"localID": 23
}
],
"localID": 19,
"expanded": true
},
{
"title": "ユニット設計",
"description": "",
"part_type": "group",
"children": [
{
"title": "ユニット設計とは",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 25
},
{
"title": "ユニットの詳細設計",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 26
},
{
"title": "共有ユニットへの反映",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 27
},
{
"title": "ユニットテストの要件定義",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 28
}
],
"localID": 24,
"expanded": true
},
{
"title": "製造・構築",
"description": "",
"part_type": "group",
"children": [
{
"title": "製造・構築とは",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 30
},
{
"title": "段階的な詳細化",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 31
},
{
"title": "製造・構築の実施",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 32
},
{
"title": "確認",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 33
}
],
"localID": 29,
"expanded": true
},
{
"title": "ユニットテスト",
"description": "",
"part_type": "group",
"children": [
{
"title": "ユニットテストとは",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 35
},
{
"title": "ユニットテストの準備",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 36
},
{
"title": "ユニットテストの実施",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 37
},
{
"title": "最も詳細なテスト",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 38
}
],
"localID": 34,
"expanded": true
},
{
"title": "システムテスト",
"description": "",
"part_type": "group",
"children": [
{
"title": "システムテストとは",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 40
},
{
"title": "システム結合",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 41
},
{
"title": "システムテストの準備",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 42
},
{
"title": "システムテストの実施",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 43
}
],
"localID": 39,
"expanded": true
},
{
"title": "運用テスト",
"description": "",
"part_type": "group",
"children": [
{
"title": "システムの導入",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 45
},
{
"title": "受入試験",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 46
},
{
"title": "教育訓練",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 47
}
],
"localID": 44,
"expanded": true
},
{
"title": "評価",
"description": "",
"part_type": "group",
"children": [
{
"title": "導入",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 49
},
{
"title": "効果測定・評価",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 50
}
],
"localID": 48,
"expanded": true
},
{
"title": "管理",
"description": "",
"part_type": "group",
"children": [
{
"title": "管理とは",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 52
},
{
"title": "10の知識エリア",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 53
},
{
"title": "5つのプロセス",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 54
},
{
"title": "３つのパート",
"description": "ああああああああああああああああああああああああああああああああああああああああああああああああああ",
"part_type": "part",
"localID": 55
}
],
"localID": 51,
"expanded": true
}
],
"localID": 12,
"expanded": true
}
],
"localID": 5,
"expanded": true
}
],
"localID": 3,
"expanded": true
}
],
"expanded": true,
"localID": 0,
"description": ""
}
]
最終更新：2020年03月04日 23:00
