令和7年度 秋期 午前Ⅱ

解説

JIS Q 21500:2018 の 3.6（プロジェクトガバナンス）は，「一般に，プロジェクトの適切なガバナンスを維持する責任は，プロジェクトスポンサ又はプロジェクト運営委員会に対して割り当てられる」と規定している。エがこれに当たる。ガバナンスはプロジェクトを動かす側ではなく，プロジェクトを許可し方向付ける側の責任である。

アのプロジェクトマネジメントチームはプロジェクトマネージャを補佐して日々のマネジメント作業を担う集まり，イのプロジェクトマネージャはガバナンスの枠組みの中でプロジェクトを指揮する立場であり，どちらも枠組みそのものを維持する責任は負わない。ウの顧客は要求事項を出し成果を受け取る側のステークホルダである。

解説

JIS Q 21500:2018 のプロセス群は，立ち上げ，計画，実行，管理，終結の五つ。プロジェクトの作業を実際に行う実行のプロセス群から，管理のプロセス群へ変更要求が上がり，管理のプロセス群で承認された変更が実行のプロセス群へ戻される。よって a は実行のプロセス群。

アの計画のプロセス群は計画を作るプロセス群で，承認された変更を受けて計画を更新することはあるが，図の“変更要求”の出どころではない。ウの終結とエの立ち上げは，プロジェクトやフェーズの終わりと始まりを扱うプロセス群である。

解説

回帰分析は，結果に当たる値（アウトプット）と，それを説明する複数の要因（インプット変数）の組を多数集め，両者の統計的な関係を式の形で求める手法である。求めた式に要因の値を当てはめれば，まだ実績のない条件についても成果を予測できる。アがこの説明に当たる。

イは差異・欠陥・リスクを引き起こしている根源的な理由をたどる根本原因分析。ウはベースラインと実績の違いとその原因を判定する差異分析。エは差異の実績を基に将来の差異を見通す傾向分析（トレンド分析）で，いずれも予測や分析の手法ではあるが回帰分析ではない。

解説

スコープクリープは，変更管理の手続を経ないまま，小さな追加が積み重なってスコープがじりじりと膨らんでいく状態をいう。イは「軽微」と自己判断してコストも工数も見積もらずに設計を進めており，承認も記録も残らないままスコープが広がるので，スコープクリープの原因となり得る。

アとエはどちらも変更要求を正式な手続に乗せている。アは承認された正規のスコープ変更であり，エは却下されたのでスコープは広がらない。ウはスコープ自体は変わっておらず，見積りの精度が足りなかったという別の問題である。

解説

ホーソン効果は，自分たちが注目されている・見られていると意識することで行動が変わり，成果が上がる現象。米国のホーソン工場での実験で，作業環境をどう変えても生産性が上がり，注目されていること自体が効いていたと解釈されたことに由来する。アは成果物がプロダクトオーナーに注目されたことで士気と生産性が上がっており，これに当たる。

イは相手の一つの目立つ特徴（優秀なチームである）に引きずられて他の評価まで歪めるハロー効果。ウは自分の思い込みに合う情報だけを探してしまう確証バイアス。エは達成困難な目標によって動機付けが失われた例で，期待をかけると成果が上がるピグマリオン効果とは逆の向きの現象である。

解説

A は開始から 6 日で終わる。A→B は終了－開始関係でリードが 2 日なので，B は A の終了より 2 日前倒しでき，6−2＝4 日目から着手できる。B は 7 日かかるので終了は 4＋7＝11 日目。B→C は開始－開始関係でラグが 3 日なので，C は B の開始の 3 日後，4＋3＝7 日目から着手でき，5 日かかるので終了は 7＋5＝12 日目。全体の完了はこれらのうち最も遅い 12 日で，イが正しい。

リードは後続作業を前倒しできる日数，ラグは後続作業を待たせる日数である。アの 11 は C の終了を見落として B の終了だけを答えた値。ウの 13 はリード 2 日を見落とし，B を A の終了直後（6 日目）から始めたときの B の終了日。エの 14 は同じくリードを見落としたうえで C の終了まで数えた値である。

解説

図1で各結合点の最早開始日を左から求めると，A の先が 4，B の先が 4＋5＝9，C と D の合流点が max(4＋10, 9＋4)＝14，E と F の合流点が max(9＋2, 14＋4)＝18，G の先が 14＋7＝21，H と I の合流点が max(18＋6, 21＋4)＝25。ここに J の 8 日を足して当初計画の総所要日数は 33 日である。図2では C が 12 日に延び，G が G1（2 日）と G2（5 日）に分かれる。C と D の合流点が max(4＋12, 9＋4)＝16，E と F の合流点が max(9＋2, 16＋4)＝20，G1 の先が 16＋2＝18，H と I の合流点が max(20＋6, 18＋4, 18＋5＋0)＝26 となり，J を足して 34 日。33 日から 1 日増えるので，ウが正しい。

ファストトラッキングを適用せず C の遅れをそのまま受け止めると 35 日，すなわち 2 日増加になる。エはこの値であって計画変更の効果を織り込んでいない。アとイは総所要日数が減るとしているが，作業 I を前倒しできても遅れを完全には吸収できないので減少はしない。

解説

クリティカルチェーン法は，個々の作業の見積りに紛れ込んでいる余裕を取り上げてまとめ直し，資源の制約も織り込んだ最長経路（クリティカルチェーン）の末尾にプロジェクトバッファを，そこへ合流する経路の末尾に合流バッファを置く手法である。余裕を作業ごとに持たせず全体で共有する点が特徴で，アがこれに当たる。

イとウは，クリティカルパス上の作業に資源や道具を投入して期間を縮めるクラッシング。エは先行作業の完了を待たずに後続作業を並行させるファストトラッキング。いずれもスケジュール短縮技法ではあるが，バッファの置き方を扱うクリティカルチェーン法とは別のものである。

解説

開発生産性は，開発規模÷開発工数＝開発規模÷(3.0×開発規模^1.12)＝(1/3.0)×開発規模^−0.12 となる。指数が負なので，開発規模が大きくなるほど生産性は下がる。さらに指数の絶対値が 0.12 と小さいため，下がり方は最初が急で，その後は緩やかになって横軸に近づいていく。この形はエである。

実際に規模を 10 倍にしても生産性は 10^−0.12≒0.76 倍にしかならず，0 にはならない。アとイは規模が大きいほど生産性が上がる形で，指数が 1 より大きい（規模が大きいほど工数が割高になる）ことと矛盾する。ウは減り方がだんだん急になる形で，べき乗の減衰とは逆向きである。

解説

JIS Q 21500:2018 の表1（プロセス群及び対象群に関連するプロジェクトマネジメントのプロセス）では，リスク対象群のプロセスのうち「リスクの特定」（4.3.28）と「リスクの評価」（4.3.29）がいずれも計画のプロセス群に置かれている。どんなリスクがあるかを洗い出し，その大きさを評価するのは，対応を計画するための準備だからである。よってイ。

同じリスク対象群でも，「リスクへの対応」（4.3.30）は実行のプロセス群，「リスクの管理」（4.3.31）は管理のプロセス群に属する。終結のプロセス群にはリスク対象群のプロセスは置かれていない。

解説

5W1H は When（いつ）・Where（どこで）・Who（誰が）・What（何を）・Why（なぜ）・How（どのように）である。表の列を当てはめると，開催日が When，場所が Where，内容が What，目的が Why，形式が How に対応するが，Who に当たる列がない。誰が招集し誰が出席するのかが決まっていなければ会議体として成り立たないので，不足しているのはウの主催者及び参加者である。

アの会議室の利用料は費用に関する情報で，5W1H のどの観点にも当たらない。イの重要度とエの成果物は，会議体の運営上あってもよい項目ではあるが，5W1H の観点から欠けているものではない。

解説

JIS Q 21500:2018 の 4.3.38（コミュニケーションの計画）は，「コミュニケーションの計画の目的は，プロジェクトのステークホルダの情報及びコミュニケーションのニーズを決定することである」と規定している。エが原文どおりである。

アはステークホルダの特定，イは情報の配布，ウはコミュニケーションのマネジメントの目的で，いずれも別のプロセスの記述である。計画で「誰に何をどれだけ伝えるか」を決め，配布で実際に届け，マネジメントで過不足や問題に対処する，という役割分担になっている。

解説

INVEST は Independent（独立している），Negotiable（交渉の余地がある），Valuable（価値がある），Estimable（見積もれる），Small（小さい），Testable（テストできる）の頭文字で，Bill Wake が良いユーザーストーリーの条件として示した六つの観点である。よってエが正しい。

アのアクティビティ図は UML の振る舞い図，イのデータフロー図は構造化分析で使う図法で，いずれも INVEST とは関係がない。ウの再利用しやすさはソフトウェアパターンやモジュール設計を評価する観点であって，ユーザーストーリーの評価軸ではない。

解説

JIS X 0160:2021 は妥当性確認プロセスの目的を，「システムがその利用中に，意図された運用環境で意図された用途を達成することで，そのビジネス又はミッションの目標及び利害関係者要件を満たすという客観的証拠を提供すること」と規定している。アが原文どおりである。

イは検証プロセスの目的である。妥当性確認が「実際に使って役に立つか」を確かめるのに対し，検証は「決められた仕様どおりに作られているか」を確かめる点が違う。ウは測定プロセス，エは品質保証プロセスの目的で，どちらもテクニカルプロセスではなくテクニカル管理プロセスに属する。

解説

スプリントバックログは，スプリントゴールを達成するために開発チーム（開発者）が自分たちで立てた計画であり，作業の追加・削除・組替えをスプリント中に自分たちの判断で行える。日々の状況に合わせて計画を更新することが前提になっているので，イが正しい。

アのスプリントゴールはスプリント中は変えない（範囲の再交渉はプロダクトオーナーと行う）。ウの品質は「完成の定義」として合意された水準であり，スプリントの都合で下げてはならない。エのプロダクトバックログはプロダクトオーナーが責任をもち，内容と並び順の決定権はプロダクトオーナーにある。

解説

JIS X 33002:2017 は，プロセスアセスメントの結果が客観的・一貫的・再現可能・代表的であることを確実にするために，アセスメントの実施に求められる最小限の要求事項を定めた規格である。すなわち組織のプロセスの品質を客観的に診断するための要求事項であり，イが正しい。

アはプロセス改善の進め方そのものを扱う規格（JIS X 33014 など）の説明で，X 33002 が定めているのは改善の手順ではなくアセスメントの実施要件である。ウは JIS Q 21500（プロジェクトマネジメントの手引），エは JIS X 0160（ソフトウェアライフサイクルプロセス）の説明である。

解説

バグトラッキングシステムは，発見された不具合を1件ずつ登録し，内容・発生したバージョン・再現手順・担当者・状態などを記録して，起票から修正完了までを追跡するツールである。名前のとおり「バグを追跡する」ことが役割なので，エが正しい。

アはデバッガの説明で，バグを見つけて原因を突き止める段階の道具。イはテストケースやテストドライバの作成を助けるテスト支援ツール。ウはバグ密度などの品質メトリクスを算出するツールの説明で，いずれもバグの記録と追跡を目的とするものではない。

解説

逓減課金方式は，利用量が増えるほど1単位当たりの単価を安くする方式である。単価が下がっても利用した分の料金は積み上がるので，利用料金の総額は利用量とともに増え続けるが，その増え方（グラフの傾き）は右へ行くほど緩やかになる。この形はウである。

アは利用量が増えるほど料金の総額が減っており，課金方式として成り立たない。イは一定量を超えると料金が増えなくなる上限付きの方式で，単価が段階的に下がるのではなく 0 になっている。エは右へ行くほど傾きが急になる形で，単価が上がっていく逓増課金方式である。

解説

Redmine は，作業をチケットとして登録し，新規・進行中・解決・終了といった状態を遷移させながら進捗を追う OSS のプロジェクト管理ツールである。チケットの種別（トラッカ）と状態遷移（ワークフロー）を自由に定義できるので，プロジェクトの課題管理にもインシデント管理やサービス要求管理にも転用できる。イが正しい。

アの Jenkins はビルドやテストを自動実行する継続的インテグレーションのツール，ウの Selenium はブラウザ操作を自動化する Web アプリケーションのテストツール，エの Zabbix はサーバやネットワーク機器の稼働状況を監視するツールである。

解説

非機能要件は，システムが何をするか（機能）ではなく，どのように働くかを定める要件である。可用性・性能・拡張性・運用性・保守性・移行性・セキュリティなど，主にシステム基盤に関わる品質と制約が該当する。エがこれに当たる。

アは業務手順や組織・責任・権限を定める業務要件，イはシステムが備える機能とその実現範囲を定める機能要件である。ウはシステム化の目的や達成目標を示す経営上の要求で，要件を導く前提に当たる。いずれも非機能要件ではない。

解説

下請代金支払遅延等防止法は，下請代金の支払期日を「給付を受領した日から起算して60日以内」と定めている。下請事業者の責めに帰すべき理由でやり直しをさせた場合には，やり直した給付を改めて受領した日を新たな起算日にできる。本問はバグの原因が下請事業者側の事情なので，起算日は修正済プログラムが納品された日であり，ウが正しい。

起算日はあくまで「受領した日」であって検査が終わった日ではないので，アとエは誤り。イの返却した日は受領が行われた日ではないので起算日にならない。なお，親事業者側の都合でやり直させた場合は起算日を動かせず，当初の受領日から60日以内に支払わなければならない。

解説

公益通報者保護法に基づく指針は，事業者に対し，内部公益通報対応体制の仕組みや利用方法を労働者等へ教育・周知することを求めている。制度があっても知られていなければ使われず，通報が外部に流れてしまうので，アが適切である。

受付窓口は外部委託先や親会社など事業者の外部に置くこともでき，内部と外部の双方に置くこともできるのでイは誤り。窓口は個々の事業部門から独立した部署に置くべきで，所属組織の長が窓口では通報者が萎縮し，通報対象が上司自身のときに機能しないのでウも誤り。匿名の内部公益通報も受け付ける必要があるのでエも誤りである。

解説

多要素認証疲労攻撃（MFA fatigue attack）は，何らかの手段でパスワードを入手した攻撃者が，正規利用者の端末へ認証のプッシュ通知が届く操作を何度も繰り返し，通知に嫌気がさした利用者がうっかり承認してしまうのを狙う攻撃である。「疲労」させる対象は利用者であり，エがこれに当たる。

アは所有者の生体情報を本人の意思によらず使う不正利用で，選択肢の「疲労」は利用者が寝ている状況の説明にすぎない。イは偽サイトで複数の認証要素を詐取するフィッシング。ウは偽メールを繰り返す点は似ているが，狙いは利用者を偽サイトへ誘導することであって，正規システムへ認証要求を繰り返し送るものではない。

解説

オペレーショナルリスクは，日常の業務プロセス・人・システム・外的事象が原因で損失が生じるリスクをいう。誤入力などの人的過失，情報システムの障害，内部者による不正はいずれもその代表例なので，アが正しい。

イの固有リスクは，統制が働いていない状態でもともと存在するリスクの大きさを指す監査上の概念。ウの地政学的リスクは，紛争や規制の変更など国際情勢に起因するリスク。エのレピュテーションリスクは，評判が損なわれることで顧客や取引先を失うリスクである。

解説

デジタルフォレンジックスでは，消えやすいものから先に保全するのが原則である（RFC 3227 が示す証拠収集の順序）。d のルーティングテーブルはメモリ上の状態なので電源を切れば失われ，最も揮発性が高い。次が c のハードディスク上のファイルで，稼働中に上書きされ得る。a は別の機器である遠隔のログサーバにあるので調査対象サーバの操作では失われないが，世代管理でいずれ上書きされる。b の CD は書換えの起きない読取り専用媒体で最も揮発性が低い。よって d → c → a → b のエが正しい。

アは最も消えやすい d を3番目に置いており，先に a と c を保全している間にルーティングテーブルを失う。イは最も揮発性の低い b から始めていて順序が逆である。ウも c を先にして d を3番目に置いており，揮発性の高いものを後回しにしている。