令和7年春期試験 午後試験【問1】についての投稿を受け付けるスレッドです。

問題点答えさせる問題、cは問題なしで合ってますか？

どれだっけ…。開発に関するセキュリティ確認云々だっけ。
あれ問題なしじゃなかったらキレるね

自分も問題点見つけられなかったので問題無しにしましたが、果たして問題無しを記述させるのかどうか……

@カフェ様・ku様
インシデント対応手順書の作成がプロセスに入っているかを答えさせる問題ですね。
何が問題なのか分からず、穴埋まっていないところを見て、問題なしでもいいのか！となりました

ごめんなさい。そっちか。
S銀行の管理者に連絡してなくね？だめじゃんって書いてた

インシデントの手順書でしたっけ？
私も問題なしにしました。

インシデント対応手順の内容が不足してる気がしました。（なんの内容かは分からなかったですが）

1.アカウント共用
2.3問題なし(不明
項番それぞれ1つ(2つのやつありました？
→値は覚えていない

設問3
ア10
イ4
ウ5
エ12

a 共用アカウントを使用しており、利用者に必要な分のアカウントを要していない。
b問題なし
c問題なし

cはシステムSの担当者がハンドリングするの部分とセキュリティ監視はN社委託なので間違ってる‥ようなことを書いた気が。
逆にbを問題無しと書いてしまった。

3つ目は問題なしにしました
一応理由も書いときました

問題なしじゃなくて丁寧に不要な機能やセキュリティ上の欠陥がないことを確認しているって確認結果を丸々書いてしまった。。。
一応合ってるし大丈夫なのかな。

Bは設計段階で設計書の確認はしてるけど、開発してからは設計書の確認はしてないのが問題と書きました

対応手順があるかないかだから、あるので問題なしにしました
適切な記載かどうかは知りません

1 アカウント共用
2 開発時に見るのが要件定義時に作ったものだと最新版ではないのでは？（更新あった場合）
3 連絡手順は確立してるけど、その後の対応が担当者の脳内手順になってるのでは？

無理やり粗探しして書きました笑

私もbは開発段階の設計書確認してないにしました。

2-3の外部のスクリプトの把握って一覧化すべき情報資産に追加するで良いんですかね？

1は、利用者の追跡ができるかの観点から、ログが取れないサーバでかつ利用者名簿をなりすまされたら真の追跡は不可能ってのも書いたんだけどダメかねぇ
もちろんアカウント共用も書いてるけどプラスアルファで

こんな感じで回答しました

設問1
（1）セキュリティ事項を組み込むことを前提としたシステム設計の考え方
（2）委託契約先と同等かそれ以上の要件を契約にいれる
設問2
（1）Webブラウザのプラグインとして配置
（2）スクリプトPをWebブラウザが都度読み取るように変更
（3）1 外部スクリプトを追加
設問3
（1）ア10 イ4 ウ5 エ11
（2）a共用アカウントこと
        b要件定義段階でしか欠陥の確認してないこと
        cインデント対応の全体フローがないこと
設問4
 システムSのソフトウェアの構成要素まで管理できるため
設問5
（1）踏み台サーバ
（2）あ、アップロード前にソースコードを検査できる
    い、コンパイルエラーがなく検査できる

2-3、9にしちゃったよ。1とめっっちゃ悩んだ結果。
たしかに普通で1でいいという気がするな。。。

9にしたうえで、外部スクリプトを読み込むような処理がないか確認する、みたいにしちゃった

回答晒します

設問１
（１）セキュリティに係る要件も後回しにせず
設計する時点で要件に盛り込む考え方
（２）L社がガイドラインに定める水準と同等以上を担保すること

設問２
（１）スクリプトPをシステムQと同じ場所に置く方法
（２）利用者のウェブブラウザのバージョンが古いものであった場合、サポート終了の旨を伝える
（３）一覧にして管理すべき情報資産の中にはシステムに関連する外部のソースコードも含めること

設問３
１０，４，５，１１ それぞれ1個ずつ順番
a 共用アカウントを使用しており、システムからは利用者を特定できない。またアクセスログを取れないサーバーもある
b 不要な機能やセキュリティ上の結果がないことを確認しているよって問題なし
c 一部に問題があり。担当者に連絡するまでの業務フローは定められているものの、インシデント自体への対応方針が不明

設問４ 
システムで利用する各ソフトウェアなど情報資産の名称やバージョン情報その他の情報から脆弱性が公開された時に、影響範囲を迅速に特定できるようになるため

設問５
あ→ソースコード単体でチェックできるので、妥当性の確認を素早く行える

い→他の開発者によるソースコード変更の影響による手戻りが小さく済む

すみません、忘れ。
設問５ （１） 踏み台サーバ

設問5(2)の「い」は「GitのCI/CDで自動的にチェックが出来る」が利点やね

担当者に連絡するまでの初期対応手順が定められていないと書きました。

自動的なチェックも利点だと思ったけどコンパイルエラーが出ないからチェックが正常に検査しやすいことも利点だと思ったんだよなぁ。
結局文字数足りなくて自動的なチェックの利点は削除してしまった

No.26
コンパイルエラーが出ないのは（あ）の時点でも同じだから（い）特有の利点にはなり得ないと思う

6割は取れているはず…

設問1
（1）システムライフサイクルの上流からセキュリティを取り入れることで、システム全体のセキュリティを向上する考え方
（2）再委託先がある場合は、セキュリティ管理に関する要件を再委託先との契約にも含める
設問2
（1）都度読み込むのではなく、安全確認ができているバージョンをあらかじめ端末に配置しておく
（2）UserAgentを確認して、古いブラウザの場合は、サポート終了している旨をブラウザに表示する
（3）1 外部スクリプトを一覧に追加する
設問3
（1）ア10 イ4 ウ5 エ11
（2）a 会社ごとに発行した共用アカウントを利用しており、一部の製品ではアクセスログが取れない
        b 問題なし
        c S銀行に連絡するフローになっていない
設問4
 パッケージ・ライブラリ等が一覧ができ、脆弱性との紐付けが容易になる
設問5
（1）踏み台サーバ
（2）・開発者によるテストの手戻りが減らせる
   ・ツールFのバージョンを統一でき、リポジトリサーバで一括して漏れなく検査できる

問５（２） 一般論はそうかもですが 注記１の内容に引っ張られました、、単独ではエラーでなくても複数を考慮したら依存関係でエラーかなんかでないかなっていう路線です

No.27さん
ご丁寧に(い)のコンパイルの実行だけにコンパイルエラーの注釈が書いてあったから惑わされてしまった…

同じくです笑

私も恥を忍んで回答を晒します

1(1)商品やサービスの企画段階から要件定義、調達、開発（コーディング）、リリース・デプロイ、運用までの全工程にセキュリティに関する要件を組み込み、セキュアなシステム開発を行う考え方
(2)L社が再委託先権限を有し、再委託先に対してセキュリティ要件を遵守させ、モニタリングできる事項
（図1の4と金融庁「金融分野におけるサイバーセキュリティにおけるガイドライン」の2.6サードパーティあたりを参考）
2
(1)スクリプトPをT社が運営するサーバではなく、別の場所、例えば自社のオンプレ環境内のサーバに配置する
（わかりませんでした）
(2)
QシステムがスクリプトPを都度読み込まないようJavascriptから別の言語に修正
（わかりませんでした）
(3)
4
以下の内容を追加する
「コーディングを再委託先等に外部委託したり、コーディングされているものが組み込まれているパッケージシステムを開発で利用する場合は、L社に報告する」
（これだと限定的なので項番1に外部のソースコードも含めるのが後々良いかと思いました）
3
あ10
い4
う5
え11
a共用アカウントが利用され、必要な利用者だけにアカウントが発行できていない。また、ログが取れないサーバーかつ利用者名簿のなりすましがあった場合にアカウントの利用者を特定できない
bシステムの仕様、機能について精査していない
（8の前半部分）
c問題なし
（15はインシデント対応手順書を作成することとだけあるため、詳細内容についてのチェックは不要と判断）
4
入手した脆弱性情報の対象ソフトウェアが一覧化されるとともに、ソフトウェア同士の依存関係がわかり、パッチ適用の影響がわかる
5
(1)踏み台サーバ
(2)
あ
コンパイルエラーの有無がわかり、Fツールの利用条件を満たすか早期に確認できるから
い
開発リーダーの承認前に再度Fツールを入れることで、開発リーダーの人的チェックさえあれば承認できるから

図5(1)は
図1の10で開発LAN上のサーバには製品使用上、アクセスログが取れないものもある
といあ内容が書いてあったのでL3SW-2にしちゃったんですが踏み台サーバが答えでしたか

突貫勉強すぎて自信の有無すら分からんけど、自分の回答

1-1 デザインによってセキュリティを向上させる考え方（知らないのでまんま和訳してみた
1-2 再委託先にも再帰的にセキュリティ要件を適用する
2-1スクリプトPをDLしてシステムQに組み込み
2-2 スクリプトP周りのソースコードを削除
2-3 1項の一覧に外部スクリプトを追加
3-1 10 4 5 11
3-2 アカウントが利用者事じゃなくて会社ごと
設計段階以降の設計書確認がない
L社のS担当が用いる手順書が定められていない
4 ライブラリの脆弱性が発覚した時、すぐ発見できる
5-1 踏み台さーば
5-2 開発者テストの工数削減
プラットフォームの機能で自動化できる

この投稿は投稿者により削除されました。(2025.04.20 17:00)

なぜか回答が晒せない。・・

3-2 cはシステムSの担当者に連絡が付かない場合の手順がない みたいなこと書いたかな
そんなことある？？とは思ったけど

ログを取得するのはL3SW-1は間違いなんでしょうかね。 
踏み台サーバでログ取得だと、L3SW-1より内部側からアクセスしてきた全IPアドレスが
L3SW-1のIPアドレスに変換されて、誰がアクセスしたか特定できないのではと思い
L3SW-1にしてしまいました。。。

設問3のb,cは深掘りして考えるべきだったのか、、、b,cともにガイドラインに一致した内容だから問題なしにしたよ。。

それでだめならガイドライン自体直すべき！笑

No.40
＞L3SW-1のIPアドレスに変換されて、誰がアクセスしたか特定できないのではと思い
その機能はNATじゃないかな、たしか

bとcは問題なしで合ってると思うよ。
シンプルに読み直せば問題無いことが分かる。

踏み台のところFWだと間違いですか？

cの部分はここまで回答が割れてる時点で悪問だということがよくわかりますね。
インシデント対応手順と称する何かあった時の現場指揮、ハンドリングを丸投げってインシデント対応手順書としてゴミ以下では？
これを問題なしとするのが正解ならIPAの問題作成者の価値観が歪んでいるとしか

>その機能はNATじゃないかな、たしか
おっしゃる通りで、L3SWにはないんですね。。。
踏み台サーバですねここは。。。

No.45
> インシデント対応手順と称する何かあった時の現場指揮、ハンドリングを丸投げってインシデント対応手順書としてゴミ以下では？

それはちょっと分かるｗ

インシデント対応手順について、ここではどの会社のメンバーが指揮系統かを指摘した人が多いっぽいですね。
自分はエスカレーション以降の調査や対処の手順が無さそうなところを書きました。
経験談で書くなって言われますが、トラフィック調査のコマンドを打つことすら手順書がないと禁じられる環境で働いてきたモンで…
体制如何より内部不正や更なるインシデントを起こさないための手順書かと考えました。

ガイドラインを用いた点検なのでガイドラインが神様で、ガイドラインにはインシデント対応手順書を作成すること、としか記載が無いのでインシデント対応手順書があればクリア。
インシデント対応手順書そのもののクオリティについてはガイドラインでは明記されていないので、cは「問題なし。」かと。

おやじさん
自分もそう思います。。(そうであってほしい)

 でもでもでも、インシデント発生時に「L社のシステムSの担当者」「だけ」にしか連絡を取る手順は問題があるのではーと思い、自分は関係各社の責任者への連絡も行うというような感じで書きました。
 L社のシステSの担当者が休みだった場合、インシデント対応はどうするの？？？

1-1 プロジェクトを立ち上げる段階からセキュリティを考慮する考え方
1-2 再委託先にも再帰的にセキュリティ要件を適用する(ような原文を改変したもの)
2-1スクリプトPをシステムQの内部サーバに配置する
2-2 スクリプトP周りのソースコードを削除および古いブラウザからのアクセスだと利用者に新しいブラウザを使用する旨を通知する機能の追加
2-3 1項の一覧に外部スクリプトを追加
3-1 10 4 5 11
3-2 共有アカウントだから特定できてない
システムの仕様、機能について精査していない
問題なし
4 各ソフトウェアのバージョンが分かるため
5-1 踏み台サーバ
5-2  手戻り修正が発生しにくい
プラットフォームの機能で自動化できる

3の(2)(3)はわからない
4はたぶん半分足りない

2個も問題なしにするの怖かったから「スナップショットの取得や戻しの手順まで誰が見ても分かるように記載」みたいに無理矢理いちゃもんつけちゃった

スクリプトPは古いWEBブラウザをサポートするために使用していたから
古いWEBブラウザのサポートを終了するに伴い必要ないのかと思いました。
なので２－２はスクリプトPを使わない 的な解答にしました

問題なしのところは意見が分かれているけれども、すでに埋まっている共通1とか調達5,リリースデプロイ10は、ガイドラインに即して「確認結果又は問題点」の欄をガイドラインに沿っているかいないかでやってるやってないということしか書いてないから、それ以上の踏み込んだ内容は既出の例文と平仄を合わせると不要かな・・・？と思ったり。

確認結果「又は」問題点 なので、両方書くような記述、例えば「ガイドライン上は問題ないけれども、内容についてクオリティが～～～なのでXXXとすることが望ましい。」みたいなものは「又は」に反するからNGで、以上2点から淡々とガイドラインに即したほうがいいかな～派です

設問３ですよね・・・
ウは５だとして、ｂは「要件定義段階での」そして「設計段階での」ということです。
それ以前、それ以下は？という点が気になりました。
そのため、開発をする段階を追うごとに確認するというのが私の答えです。

他の人の意見見てたら問題なしが解答かなって思い直した。
まあ、これで問題ないと答える支援士をIPAは求めてんのかよ…と思いはするが

ガイドラインに、
インシデント管理手順が存在しユーザへの連絡手段が明記され、複数の連絡経路が定義されること
って合ってcに問題点書くのが実務的には正しいんでしょうかね。ただ公式の回答例待つしかないですが。。

問題なしのところは正直問題が悪いとは思う
IPAの意図が伝わらなさすぎる

解釈が色々できる場所があって難しかったです…

設問1
(1) システムデザイン (企画設計) の段階からセキュリティの視点を組み込む考え方
(2) 再委託をする場合、セキュリティ管理に関する要件と同等の要件を契約に含め、それを監督・報告すること

設問2
(1) スクリプトPをサーバTからではなく、システムQを提供するサーバに配置して提供する
(2) HTTPリクエストに含まれるUser-Agentを確認し、サポート対象外のブラウザであればメッセージを出して処理を終了する
(3) 項番1、一覧化すべき情報資産に外部より読み込むライブラリを追加する

設問3
(1) 10、4、5、11
(2)
a: 共有アカウントを利用しており、アカウントの利用者を特定することができない
b: 問題なし
c: インシデント対応手順書に連絡のためのフローのみが記載され、具体的な対応の手順が記載されていない。

設問4
システムを構成するソフトウェアの存在とバージョンが一覧できるため、脆弱性が公表された際に影響の有無をすばやく判断できる

設問5
(1) 踏み台サーバ
(2) 
(あ): 開発者による作業中にチェックできるので、他の開発者に影響せず効率よく修正できる
(い): 複数の開発者による変更の影響をチェックでき、レビュー時の手戻りを減らせる

まったく自信ないですが投稿します。文章はメモしてなかったのでこんな感じで書いたというのを思い出しながらなので文字数はすこしおかしいかもです


問１-(1) あらかじめ情報セキュリティを意識した開発工程での取り組みを定義すること
問１-(2) 再委託を行う場合には、L社と業務委託先と同水準のセキュリティ基準を結ぶこと



問２-(1) システムQがあるサーバ内にスクリプトPを配置する
問２-(2) システムQのサーバ側で、クライアントからのHTTP要求のブラウザバージョンを判定し、使用不可なものであればエラーを返す
問２-(3) 項番１ 情報資産の一覧化すべきの対象に社外製品を追加する

問３-(1) 10,4,5,11
問３-(2)  a 踏み台サーバへのログインが各社ごとの共有アカウントとなっており、利用者の特定ができない
     b,c 問題なし）

問４   将来の機能追加で新たな脆弱性が発生していないかを既存SBOMを利用することで容易に発見できる（←自信なし。適当）

問５-(1) d 踏み台サーバ
問５-(2) （あ）プログラム単体での脆弱性の評価が実施できる
     （い）Sシステム全体での脆弱性評価が実施できる

5-1は踏み台サーバへのログインは共有アカウントを利用することにより、個人が特定できないため、FWにしたのですが、FWではいけませんかね？
利用記録簿はシステム的な拘束力が無さそうですし。

lsなんちゃらの1か2かで迷ってた自分にとってはどっちにしろアウトでしたね…笑

りんごさん
社内のログが取れてないのが根本なので、FWにしてしまうと、社内→開発LANにいったときにはFWは通らなくなるのでは？と思い、踏み台サーバにしました

FWから踏み台サーバ行くのってオフショア拠点だけで、社内LAN使った開発者はFW通過しないので踏み台サーバになるのかなと思いました

あ、すみません重複しましたね。。

トムたろうさん、15/25さん
ご教授くださりありがとうございます！
なるほどです、、勝手にパートナーLANと従業員LANはFWのルールで通信制御しているのかと勘違いしておりました、、、
ありがとうございます！！！

こんにちは。
今回真剣にやりだして三度目です。
設問4は
ソフトウェアのサポート期限管理が一元管理でかかきるから
と書きました
Bさんが 将来 と頭につけたのが引っ掛かりました
問１は構成図もざっくりしすぎてて、
個人的には情報処理技術者試験という感じがしませんでした。

基本的に（的な）です
設問１
(1) セキュリティ設計や構成を最優先にした考え方にすること（的な）
(2) L社と業務委託契約書を契約した際の契約と同等のものとすると共に、勝手な内容改変や著作権等も変更しないこと（的な）
設問２ 自信なし(的なです)
(1)システムQにアクセスしたスクリプトPがその都度Pを読み込むことをせず、必要に応じて読み込むように変更し、リダイレクトの際には利用者にクッションページを表示する。
(2)システムＱにアクセスするとスクリプトＰを読込むことを変更する。読込やリダイレクト前に画面遷移について利用者に確認を行う。
(3)忘れて乙
設問３ 的な回答ですよ
ア.10  イ.4  ウ.5  エ.11
これだけ回答欄があれば「問題なし、は無いでしょう」ということから回答しました
a 会社ごとに発行された共通アカウントであるため、責任追及性が確保できない
b 要件定義段階や設計段階だけではなく、各開発段階の進行に応じて確認を実施すること
c L社のシステム担当者だけではなく、本件に関係した全ての会社の責任者に連絡を行い、インシデント対応に当たること
設問４ 同じく的な。
（忘れましたが）SBOMの利用によりシステムの構成や利用しているソフトウェアの名称やバージョン情報の管理が見やすくなり、なんだかんだで管理がよくなる的な回答。
設問５(同じく的な) 
(1) 踏み台サーバ 
(2)(あ）開発者端末でテストを行っているため、仮にエラーが出たとしても修正が容易である
    (い) プラットフォーム上でテストを行っているため、エラーが出たとしてもそこまでの過程が信頼できる

僕もFWにしました。利用記録簿を勘違い。

会社ごとに発行された共通アカウントのところ、実際問題サーバ側に各会社の個人アカウントまで作るかなと気になって利用記録簿を厳守に留めて記述しちゃいました。
やろうと思えばADなり構築して管理できると思いますが、「そこまで求めてるのかな」という感じで問題の趣意が難しいですね…。

解答速報が時に採点しやすいように受験記念にコメントしておきます。
問1
(1)
システムの仕様、機能を精査し、不要な機能やセキュリティ上の欠陥がないことを設計書から確認すること。
(2)
ソースコードや設計書といった納品物の著作権は、L社が持つこと。
問2
(1)
スクリプトPをWebサイトと同一ドメインに配置する。
(2)
古いWebブラウザで表示した場合、
新しいWebブラウザで表示することをすすめる内容を表示する。
(3)
1
一覧化すべき情報資産に外部スクリプトを追加する。
問3
(1)
ア 10
イ 4
ウ 5
エ 11
(2)
a 開発LAN上のサーバには製品仕様上、アクセスログが取れないものがある。
b システムの仕様、機能を精査していない。
c システムSの担当者がインシデントのハンドリングを行うといった作業をしている。
問4
SBOMに書かれた製品のバージョンの一覧から脆弱性の情報を調べやすくなる。（調べられるって書いたかも）
問5
(1)
踏み台サーバ
(2)
(あ)
開発者がテストを行う前にツールFによるチェックができる。
(い)
プラットフォームG上でツールFによるチェックができる。

最近ちょうどGit CI/CD任されてたからラッキーだったぜ

試験から1日経って、ようやく過去問を振り返れる精神状態になってきました。
午後1問目は、見直せば見直すほど、
私の上司が日々セキュリティチェックしている内容そのものです。
私もそのセキュリティ判断を日々一緒に見聞きしているので、
問題に対する回答も、まさにそのまま回答として出てきました。
社外サーバにあるソースコードが勝手に書き換えられるリスクは
社内のCISO室が日々注意を払っている箇所でもありますし、
スクリプトを書き換える前にレビューするのは必須なので、納得の設問です。

この投稿は投稿者により削除されました。(2025.04.22 11:55)

設問3
（２）
a：開発LAN上のサーバにはアクセスログが取れないものがある。
踏み台サーバには共有アカウントを利用しているが、ログインごとに利用記録簿に記載することがルール化されているため、それは守られる（共有アカウントでは勝手にログインできない）前提。

b：問題なし
図1の5で「設計段階での設計書の確認を行い不要な機能～欠陥が無いこと」とあるので問題なしにしました。

c：インシデント対応手順書にインシデントのハンドリングについての記載がない。
インシデント対応手順書の内容が「担当者へ連絡」だけで肝心のハンドリングの部分が対応手順に書かれていないのはNGかと思い、その旨書きました。

補足：設問3（２）のbに対応する表1のガイドラインの項番9で、「不要な機能やセキュリティ上の欠陥が無いことを設計書から確認すること」
対応する図1の5（（1）ウの解答）で「設計書の確認を行い～欠陥が無いことを確認する」が含まれているため、bは問題なしと判断しました。

インシデント対応手順書とは何か？
IPAに
「中小企業のためのセキュリティインシデント対応手引き」
がありました。（リンクは貼ってません）
よろしければご参照下さい。

ITEC出ましたね。3のCは納得いかないです。それかくならbもそうやって書くべきでは？と
どの程度信頼できますか？

なんか、ITECの回答も微妙な気がする、、、どこがだめなのか指摘じゃないし、、、

やっぱり、共有アカウントが会社ごとだから、設問3 (2) aは「共有アカウントを使用しており、必要な利用者にだけ発行されていない」みたいなのが正解っぽい？
利用簿を作っているから、事前に登録しないとアクセスできないルールで運用してる？＋アカウント利用者は特定（利用簿とログ）する手段があるけど、そもそもログがないと特定のしようがないからそっちが問題かと思ったけど、アカウントを「会社ごとに発行」だから、その時点でだめか
どっちも書いてたらどうなっただろう。。。

設問3（２）ｃは、ITECさん解答の「インシデント対応手順書は作成されている」は読んだらわかるので、それが「インシデント対応手順書」足る（と言える）のかを問うている問題の認識  
なので、ITECさんの解答は微妙？？？

3-cに本文見直したけど 連絡フローのみ定義されてるって書かれてるわけでもないんだよな。
実はめちゃくちゃ分厚い対応手順かもしれない。

と考えてもとわからないのでIPA本丸の発表までここは待ちます、、

散々意見が割れている３ｃなんだけど、もし問題なしが解答だとして
IPA「３Cは正答率が低かった。インシデント対応手順書以外について言及している回答が多く見られた。確かにインシデントハンドリングまで全てを明確に定めることが理想ではあるがシステムライフサイクルの各工程は企業によって異なり、理想的な対策が取れないことも往々にしてある。情報セキュリティ対策リスクとコストはトレード関係にあることをしっかり認識し、場面に応じて適切な対応を取れる力を培ってほしい。」
とか書いてたら面白いですよね（戯言）

まあ、実務やってる人なら散々に苦慮していることだと思うけど、実際、問題情報セキュリティ対策は色々な意味でのコストとトレードオフがあるから理想論に行かないのはその通り。ここは机上の勉強だけだとなかなかピンとこない
設問２の（２）もだね。SEとか開発やってる人にとっちゃ至極当然の話で脳内反射的に答えかけると思うんだけどやってない人からしたら何のこっちゃって話。
社内で運用さんやってる人に聞いてみたら全く答えられませんでした。やっぱり各々のやっている実務経験の背景が色濃く出るようになりましたね、、

3bって問題なしなんですか？
設計段階から開発フェーズに移行したあとは、仕様書と付き合わせて確認とかってしないものなんでしょうか？(実務経験ないので教えていただきたいです)

速報出揃ってきましたが、この意見の割れっぷりを見る感じどうにもならないので、合格発表までおとなしく待ちますｗ
設問5（2）はわざわざコンパイルの注釈やプラットフォームが移っている図になっているので、問題作成した人は、ツールＦの特徴であるコンパイルエラー解消が動作の条件であることとプラットフォームＧ上で自動化ができることをそれぞれ回答させたかったのかなと思っています。

TACも回答でたけどやはり3cが納得できないよ。。他に書いてあるか確認してないのは評価者の力量不足じゃないか、、、

まぁただ回答が2つともそうなら諦めるしかないか、、、

PM観点だと、3bは問題なしとしたいです。
アジャイルで無い限り設計段階で仕様凍結させるのが普通なので、、永遠に設計書を書き換えることになる(設計工程がFIXしない)ので、開発工程以降の変更管理のためにSBOMがあると思ってます

回答をさらしている人たちは、結構自信がありそう

正直bcは作問者のお気持ち読み取り問題過ぎる。

「問題なし」は他の診断結果にあったから、BCどちらかは問題なしになるとメタ的に解釈した
そうするとどっちが問題なしかわからなかったので両方問題なしにするしかなくなった

解答速報見ると問3(2)はbが問題なしでcは回答が必要だったみたいですね
南~無~

moonさん
それって公式のものではないですよね？