BDB-08013C 一般 フェーズ移行審査ガイドライン（その 1） 宇宙航空研究開発機構 チーフエンジニア・オフィス １. 目的 フェーズ移行審査（以下、「審査」という）を過不足なく効果的に進めることを目的に、「JAXA 技術プロセ スガイドライン」の一環として、審査に関する心得、ポイント等をガイドラインとして示す。本ガイドライン（その １）では、ミッション定義審査（MDR）からプロジェクト移行審査に至るプロジェクト・ライフサイクルの初期段階 の審査を対象範囲とする。 ２. 準拠文書 本ガイドラインは、以下の文書に準拠している。本ガイドラインは、これらの文書と合わせて活用いただきた い（ガイドラインが全てを網羅しているものではないため）。 (ア) プロジェクトマネジメント規程（規程第 19-29 号） (イ) プロジェクトマネジメント実施要領（システムズエンジニアリング推進室長通達第 19-1 号） ３. 審査の心得 「大規模で複雑なシステムを確実かつ効率的に開発するため、プロジェクトは、フェーズに区分して進める ものとし、プロジェクトマネージャは、各フェーズで行うべき作業内容を定義した上で、フェーズ移行審査におけ る次フェーズへの移行可否判断を踏まえ、順次これを進めるものとする。」（規程第 8 条） 「機構における審査は、ミッションを定義するため及び定義されたミッションを達成するための検討対象の適 切性、妥当性及び有効性を判定するために行うとともに、多面的な評価を通じた課題の共有とその解決の 促進をその目的に含む。審査は、プロジェクトチームの自己点検活動を基礎として、関連各分野の有識者 の参画を得て実施するものとする。」（要領第 19 条） 言い換えれば、「審査員」は、審査がミッションを成功に導くための活動であるとの認識に立ち、厳格な視 点により、根拠とともに解決策またはその方向性を示した上で意見を述べるべきである。また、「被審査者」 及び「上位のプログラムを司る者」は、審査の目的や背景を十分に理解し、審査がミッションを成功に導くた めの活動であるとの認識に立ち、審査に必要な情報（審査対象文書や基準文書等）を適切に提示するこ とが期待される。 ４. チェックゲートとしての審査 フェーズ移行にあたっては、チェックゲートとしてプロジェクトに対し独立的に審査が行われる。審査において は、審査委員長が審査委員の意見を尊重し、プロジェクトの次フェーズへの移行について「可否を判定」す る。 1 判定経緯と結果は、文書化され理事会議に報告される。特に、経営審査については、審査委員長が審 査の結果を理事会議に報告し、これを受け理事長が、フェーズ移行の可否を承認或いは否認する。 (ア) 審査結果が「移行不可」となった場合及び理事長が移行を否認した場合 次フェーズへの移行は留保される。審査委員長は「移行不可」の理由及び必要な是正措置案（期限、 責任者を含む）についても理事会議に報告し、必要措置に関し理事長が意思決定を行う。（例：再審査 に向けた措置等）。 (イ) 審査結果が「移行可」となり、かつ理事長が移行を承認した場合 プロジェクトが設定される。以降、プロジェクトの開発・品質保証に関する責任と権限はプロジェクトマネ ージャ（あるいは相当者）にある。また、「プロジェクトに対する評価とその対応（要領第 6 章）」の一環として、 「プロジェクト進捗報告会による確認」と「日常的な確認」（以下参照）を受ける。 担当本部等の長による、プロジェクトを含む本部等の業務の掌理 安全・信頼性推進部及び担当本部等の品質保証部門による、プロジェクトの活動への要求・ 評価・支援 チーフエンジニアによる独立的技術評価 なお、審査結果が「条件付きで移行可」となった場合には、審査委員長はその理由及び必要な是正 措置案（期限、責任者を含む）についても理事会議に報告し、必要措置に関し理事長が意思決定を行 う。 ５. 各審査に関するガイドライン 添付 1 に各審査における目的、審査員の構成、審査文書、審査後にベースライン化される資料などを 示す。なお、これらはあくまで目安であり、個々のミッションの特質を勘案し、意義及び合理的な必要性をプ ロジェクトと事務局が協議・判断した上で、審査計画として設定することが肝要である。 ６. 審査の基本事項 ６．１ 認識の共有 (1) 被審査者、審査員及び事務局は、審査の目的とそれに応じた審査の視点を共有し、審査の目的と 審査範囲に合致した審査とすること（例：フェーズ移行審査は、プログラムの審査の場ではない）。 (ア) 被審査者：審査項目に対応した審査文書を準備（プロジェクトの本来活動としてコンフィギュレー ション管理・維持すべき文書を積極的に活用）。 (イ) 審査員：あらかじめ審査の目的と審査項目を確認（審査の冒頭で、事務局から具体的に説 明）。 (2) 審査員は、質疑や指摘にあたり、具体的な解決案や方向性を提示すること（例：指摘の回答は、指 摘者と被審査者が協同して作成）。 ６．２ 上位要求の識別と分掌 (1) プロジェクトの裁量を超えるプログラム要求、プログラム方針等については、プログラムとプロジェクト間で 協議した結果を示す。審査においては、これらの説明及び質疑応答は要求元（=文書維持者）である 2 プログラムが対応する。 ６．３ 審査説明資料とプレゼンテーションのポイント (1) 「論理的・具体的・定量的・網羅的」であること。 ミッション要求やシステム要求などの各種設定や前提に対して、設定した背景となる考え方や 根拠を示す。 ミッション実現可能性や技術課題と解決策などには、必ず根拠を示す 仕様適合表において「仕様と同じ」という記述は不可とし、仕様に対する考慮事項を明確にす る 何を、どのようにしたいのかがわかるキーワードを明らかにする（問題点、検討結果、支援/決定 してほしい事項） 5w1h を基本として、簡潔かつ曖昧さを避ける (2) トレードオフ内容と意思決定の根拠を示すこと。 アーキテクチャレベルや上位のシステムレベルのトレードオフは、ミッションそのものの成否に大きな 影響を及ぼす。このため、トレードオフの内容及び決定の根拠・プロセス（どのように決めたか？） を具体的に示す。 (3) 前フェーズの審査からの連続性を考慮し、つながりが分かるようにすること（特に、課題の解決状況な ど）。 (4) 審査が階層化されている場合（契約に基づくメーカでの審査等）や専門家による技術審査（ピアレビュ ー）に対して、それぞれの審査の目的と関係を明らかにする。また、相互に議論や資料の重複は避けつ つ、決定や結論に至ったプロセスと根拠を合理的に記述する。 (5) 網羅性を確保しながらも、審査の目的・背景を十分理解した上で、審査のポイントとなる点を前面に 出す。 未決事項への対応状況の詳細 過去の実績との対比 支援/決定してほしい事項 (6) リスク識別・リスク管理について、「問題ない」という説明ではなく、存在するリスク及び予測されるリスクと その対応策を積極的かつ具体的（こう対処するので、ここまでは回避できる、等）に説明する。 3 ６．４ 審査の準備と運営 (1) 審査の内容に応じ、審査員を構成（必要に応じ know-who データを活用）する。合わせて審査項目 定めた上で審査実施要領として制定する。審査の視点としてプロジェクトマネジメントチェックリスト （BDB-07006）を準備する。 なお、本部レベル審査（ミッション定義審査、システム要求審査、システム定義審査）における審査員 は、主に以下の視点をもって審査会に参加する。 ・ミッションのユーザー・研究コミュニティ代表者 ミッションの受取り手の視点から計画が妥当か？ ・信頼性統括 安全性や信頼性の観点で計画が妥当か？ ・統括チーフエンジニア、チーフエンジニア システムズエンジニアリング及び専門分野に関する有識者としての助言 ・チーフエンジニア室長、各本部等の SE 推進室長、 C システムズエンジニアリングに関する有識者としての助言 システムズエンジニアリング活動が漏れなく十分行われているか？ （チーフエンジニア室長は全 JAXA 的な視点、SE 推進室長は本部としての視点） C ・類似ミッションのプロジェクトマネージャ・システムズエンジニア 過去の知見・経験に基づく助言 ・専門分野毎のエキスパート 専門分野に関する技術有識者としての助言 (2) 経営審査に先立ち、経営企画部及びチーフエンジニアオフィスによる事前評価が行われるため、予め 評価事項に対応した資料を準備のこと（詳細は、「コスト評価ガイドライン」 BDB-08006 による）。 (3) 審査に先立ち、キックオフ会議を開催し、審査実施要領などにより｢審査の目的、審査項目、審査の 視点｣等を審査員へ説明し、プロジェクトとともに審査の意義・方法について予め意識共有を図る。この 際、資料の説明と質疑応答時間を確保することも有効である。 (4) 本審査会に至る一連の審査には、必要十分な時間を確保（資料の事前配布、審査期間、審議時 間）する。 (5) 重要な指摘については、全体審議に先立ち必要に応じて専門家による分科会を設け、判定・要処置 事項・全体審議に付すか否かなどの評価を行う。事務局は審査委員長の意向を確認しつつ分科会 の設置を行う。 (6) 審査においての要処置事項フォローの全体責任者とプロセスを定義する（例：本部会議等への状況報 告をあらかじめ計画する等）。 以 上 4 フェーズ移行審査ガイドライン（本部レベルの審査） ミッション定義審査 システム要求審査 システム定義審査 プロジェクトマネジメント規程（規程第 19-29 号）及び同実施要領（システムズエンジニアリング推進室長通達第 19-1 号）に拠る プロジェクトマネジメントチェックリスト（BDB-07006）を参照 プロジェクトマネジメント規程（規程第 19-29 号）及び同実施要領（システムズエンジニアリング推進室長通達第 19-1 号）に拠る ミッションのユーザ・研究コミュニティ代表者 ミッションのユーザ・研究コミュニティ代表者 ミッションのユーザ・研究コミュニティ代表者 信頼性統括、統括チーフエンジニア、チーフエンジニア、チーフエン 信頼性統括、統括チーフエンジニア、チーフエンジニア、チーフエン 信頼性統括、統括チーフエンジニア、チーフエンジニア、チーフエン ジニア室長など ジニア室長など、専門分野毎のエキスパート ジニア室長など、専門分野毎のエキスパート 類似ミッションのプロジェクトマネージャ 類似ミッションのプロジェクトマネージャ・システムズエンジニア 類似ミッションのプロジェクトマネージャ・システムズエンジニア (5) 審査文書 A) 基準文書 A) 基準文書 A) 基準文書 《プロジェクト活動 中期計画/長期計画 ミッション要求書 ミッション要求書 に必要な文書》 ユーザからの要求文書 B) 審査対象文書 システム要求書 プログラム等上位からの要求文書 システム要求書【SR-1】 利用・運用コンセプト B) 審査対象文書 運用コンセプト【SR-2】 システムズエンジニアリングマネジメント計画書 ミッション要求書（サクセスクライテリアを含む）【MD-1】 システム要求の設定根拠（ミッション要求からのトレーサビリティを含 B) 審査対象文書 ミッション要求の設定根拠【MD-2】 む）【SR-3】 システム仕様書【SD-1】 リスク識別書【MD-3】 リスク識別書【SR-4】 システム仕様の設定根拠（ミッション要求、システム要求からのトレ C) 参考文書 システムズエンジニアリングマネジメント計画書【SR-5】 ーサビリティを含む）【SD-2】 概念検討結果報告書【MD-4】 技術開発項目一覧【SR-6】 リスク識別書【SD-3】 C) 参考文書 プロジェクト計画書【SD-4】 概念設計結果報告書【SR-７】 C) 参考文書 システム設計結果報告書【SD-5】 (6) 審査後に ミッション要求書（案） システム要求書 システム仕様書 ベースライン化 運用コンセプト プロジェクト計画書（案） される文書 システムズエンジニアリングマネジメント計画書 (7) 審査事項 ① ミッション要求【MD-1】 ① ミッション要求【MD-1】 ① ミッション要求【MD-1】 【】は、(5)審査文 客観的事実に基づくミッションの意義・目的・目標（プロジェクト準 MDR からのミッション要求変更部分とインパクト評価 SRR からのミッション要求/システム要求変更部分とインパクト評価 書の識別番号 備審査の審査事項①に相当） ② システム要求【SR-1】 ② システム要求【SR-1】 ミッション達成時に予測されるインパクト（技術、社会、科学的） 前提となる利用・運用コンセプト【SR-2】 SRR からのミッション要求/システム要求変更部分とインパクト評価 要 求 元 の 確 実 性 の 設 定 根 拠 と ス テ ー ク ホ ル ダ 分 析 結 果 各システム要求の設定根拠・上位要求（プログラムからの要求等） ③ システム仕様要求（開発仕様）【SD-1】【SD-5】 （CVCA,VOC 一覧等） や制約（国産コンポーネントの使用などの技術的制約を含む）との 前提となる利用・運用コンセプト 各ミッション要求の根拠・上位要求（プログラムからの要求等）や制 関連付け【SR-3】 システム設計結果に基づく設計コンセプト（システム仕様設定にあ 約との関連付け【MD-2】 システム要求記載事項毎の検証方針（何を、いつ、どのように） たっての考え方） 要求の優先度 ③ システムの実現可能性【SR-７】 各システム仕様の設定根拠【SD-2】 ミッションロードマップにおける位置付け 概念設計結果に基づく設計コンセプト 主要なトレードオフ事項と検討内容 プログラム等上位からの要求文書との関連 主要なトレードオフ事項と検討内容 ミッション要求、システム要求からシステム仕様に至る一貫性（非 ミッションサクセスクライテリア（BDB-08012 による） キー技術並びに方式の検討に基づく実現レベルと課題 適合事項） ② システムの実現可能性【MD-4】 技術ロードマップとの対応関係 サブシステムへの機能配分と設定根拠 概念検討結果に基づくシステムコンセプト システム及び主要コンポーネント候補の諸元比較表（概要） キー技術並びに方式の検討に基づく実現レベルと課題 開発基本方針（ドラフト） ④ シ ス テ ム ズ エ ン ジ ニ ア リ ン グ マ ネ ジ メ ン ト 計 画 （ 案 ） 【 SR-5 】 システム仕様記載事項毎の検証計画（何を、いつ、どのように） 主要なトレードオフ事項と検討内容 【SR-6】 過去の不具合のレビューと対応状況 キー技術並びに方式の検討に基づく実現レベルと課題 開発基本方針（検証方針を含む） ④ システムズエンジニアリングマネジメント計画【SR-5】 技術ロードマップとの対応関係 上位 WBS の定義 SRR からの変更/追加部分とインパクト評価 想定される主要サブシステムの TRL 及び変更度の考え方（BDB- システムズエンジニアリング方針 ⑤ リスクマネジメント【SD-3】 06005 による） 想定される主要サブシステムの TRL 及び変更度の考え方 未確定事項一覧と確定予定時期・方法 検証戦略（スケジュールを含む） 主要開発スケジュール（TRL のレベルアップ計画、WBS ベース） リスク識別・定量化の考え方と識別結果・対応策（プログラムリス 利用・運用コンセプト（イメージレベル） ⑤ リスクマネジメント【SR-4】 ク、プロジェクトリスク、技術リスク及上記実現レベルとの関連） ③ リスクマネジメント【MD-3】 未確定事項一覧と確定予定時期・方法 ⑥ プロジェクト計画【SD-4】 未確定事項一覧と確定予定時期・方法 リスク識別・定量化の考え方と識別結果・対応策（プログラムリス プロジェクト目標及び方針 リスク識別・定量化の考え方とリスク識別結果・対応策（プログラム ク、プロジェクトリスク、技術リスク及上記実現レベルとの関連） 詳細化された WBS リスク、プロジェクトリスク、技術リスク及び実現レベルとの関連） ⑥ レッスンズラーンドの取り込み状況 WBS に基づくスケジュールとステータス ④ 資金規模上限値設定のための推算 ⑦ 前フェーズからの懸案事項及びアクションアイテム 体制と責任分担 資金マージンの考え方 プロジェクト資金設定のための内訳及び積算根拠 ブレークダウンされた資金計画と根拠（プリプロジェクトフェーズの具 資金及びスケジュールマージンの考え方 体的内容） ⑦ レッスンズラーンドの取り込み状況 ⑤ レッスンズラーンドの取り込み状況 ⑧ 前フェーズからの懸案事項及びアクションアイテム 5 ⑥ プリプロジェクトフェーズの体制 (1) 審査の目的 (2) 審査の視点 (3) 審査委員長 (4) 審査員構成 C フェーズ移行審査ガイドライン（経営レベルの審査） (1) 審査の目的 (2) 審査の視点 (3) 審査委員長 (4) 審査員構成 (5) 審査文書 《プロジェクト活動 に必要な文書》 プロジェクト準備審査 プロジェクト移行審査 プロジェクトマネジメント規程（規程第 19-29 号）及び同実施要領（システムズエンジニアリング推進室長通達第 19-1 号）に拠る プロジェクトマネジメントチェックリスト（BDB-07006）を参照 プロジェクトマネジメント規程（規程第 19-29 号）及び同実施要領（システムズエンジニアリング推進室長通達第 19-1 号）に拠る 理事・執行役・技術参与から委員長が指名 理事・執行役・技術参与から委員長が指名 A) 基準文書 A) 基準文書 中期計画/長期計画事業実施方針 中期計画/長期計画 プログラム等からの要求文書 プログラム等からの要求文書 B) 審査対象文書 ミッション要求書 ミッション要求書（サクセスクライテリアを含む） B) 審査対象文書 リスク識別書 プロジェクト計画書（案） ミッションの目的・目標の妥当性【経営企画部】 プロジェクトリスク管理計画書 開発全体計画の妥当性【経営企画部、チーフエンジニアオフィス】 プロジェクトリスク識別書 プロジェクト全体資金総額（上限値）の推算の妥当性【経営企画部、チーフエンジニアオフィス】 リスク識別書資金/リスク評価結果 【チーフエンジニアオフィス】 プロジェクト準備段階の計画の妥当性【経営企画部、チーフエンジニアオフィス】 JAXA 長期資金計画へ与える影響評価結果【経営企画部】 技術的成熟度(リスクの識別、対処方針、低減策) 【経営企画部、チーフエンジニアオフィス】 人員計画評価結果【人事部】 ミッション要求書 プロジェクト計画書 (6) 審査後に ベースライン化 される文書 (7) 審査事項 ① ミッションの目的・目標の妥当性 【】は、(5)審査文 ミッションの目的が、国の政策※、 JAXA 理念、中期計画等と整合していること。 ※ 書の識別番号 「我が国における宇宙開発利用の基本戦略」、「宇宙開発に関する長期的な計画」等 ミッションの目的・目標において以下の点が具体的に示され、その達成に向けて機構が果たす役割 の重要性が認められること。 a) 成果の受け手（ユーザ） b) 社会からの要請内容（ユーザニーズ） c) 学術的成果の価値 d) 国際協力の意義 等 ミッションの目的に技術開発を含む場合、以下の点で、その達成に向けて機構が果たす役割の重 要性が認められること。 a) 他国の追随を許さない強みを有するか b) 今後の日本の成長を支え得るか 等 ミッションの目的・目標が、中期計画等、機構全体の長期的な計画の成立性（事業・人員・資金 を含む）を考慮して妥当であること。 ミッションサクセスクライテリアが BDB-08001 に従い適切に設定されていること。 ② 開発全体計画の妥当性 開発全体計画のベースライン（プロジェクトの範囲、基本的な考え方ないし方針）が設定された目 標に照らして的確であること。 計画着手時期あるいは成果創出（プロジェクト完了）の時期が、ミッションの目的に照らして適切で あること。（スケジュール遅延による影響を含む） ③ プロジェクト全体の資金総額（上限値）の推算の妥当性 プロジェクト全体の資金総額が、ミッションの目的・意義に照らして妥当であること。 プロジェクト全体の資金総額は、検討未了であることによる不確定性を勘案した上限値を設定し ていること。 ④ プロジェクト準備段階に必要なリソース（資金計画、人員計画）の妥当性 プロジェクト準備段階で必要な人的、資金的リソースを投入する人員計画、資金計画が設定され ていること。 ⑤ 技術的成熟度（リスクの識別、対処方針、低減策） ミッション実現可能性の見通しが立っていること。 プロジェクト全体のリスクが識別され、プロジェクト準備段階において対処すべきリスクと開発移行後 に対処すべきリスクが明確になっていること。 プロジェクト準備段階において対処の必要なリスクについて、対処方針と低減策が示されているこ と。 ① プロジェクト目標（ミッション要求、成功基準の再確認を含む）、プロジェクト範囲が適切かつ明確 に設定されていること。 プロジェクト準備審査時に確認された、ミッション要求書記載の下記項目を再確認する。（プロジェ クト準備審査時から目標や意義が失われたり、陳腐化していないかという視点でも再確認のこと） a) プロジェクトの目的 b) プロジェクトの成功基準 プロジェクト計画書（案）に記載の下記項目が適切であるかを確認する。 a) プロジェクトの範囲 b) プロジェクトの前提条件・制約条件（例：打上げ年度、打上げ手段） c) プロジェクトの遂行方針 ② 実施体制（含む、他機関、メーカ）が妥当であること。 プロジェクト計画書（案）に記載の下記項目が適切であることを確認する。 a) プロジェクトの構成（業務体系）、WBS b) プロジェクトの実施体制（組織体制） c) 外部機関とのインタフェース（担当メーカ、共同開発機関、利用機関、海外協力機関など） ③ 資金計画が妥当であること（機構レベルの長期資金計画への影響評価を含む）。 下記の観点からプロジェクト計画書（案）に記載されるプロジェクト総資金の妥当性を確認する。 a) 実施項目ごとのコスト見積りが適切であるか。 b) JAXA 全体の長期資金計画への影響を考慮し、成立しうる資金計画であるか。 c) 資金マージンが適切に確保されているか。 ④ 人員計画が妥当であること。 下記の観点からプロジェクト計画書（案）に記載されるプロジェクト人員計画の妥当性を確認する。 a) 開発フェーズごとの人員数の見積りが適切であるか。 b) 限られた人的リソースの中で人員を最大限に活用するものとなっているか。 c) プロジェクト体制の各役割に対して、必要な能力を持つ人材が配置される計画となっている か。 d) 新規人員要求については、確保方法も含め調整確認がなされているか。 ⑤ 開発スケジュールが妥当であること。 下記の観点からプロジェクト計画書（案）に記載されるスケジュールの妥当性を確認する。 ・ ミッション要求、プロジェクトの前提・制約条件等と整合が取れたスケジュールとなっているか。 ・ 開発工程上、無理のないスケジュール設定となっているか。 ⑥ プロジェクト遂行上のリスク・課題が識別され、その対応策が妥当であること。 プロジェクトリスク管理計画書（案）およびリスク識別情報（案）に、プロジェクト遂行上のリスク・課題 6 が識別され、かつ対応策が適切に示されているかを確認する。
© Copyright 2024 Paperzz
