システム開発とユーザーインタフェースのミニテスト（全40問）
作る前と作ったあとを問う40問。要件定義の誤りがなぜ高くつくのか、同値分割と限界値分析、条件網羅の落とし穴、スクラムマスターの役割、バーンダウンチャートの上下の意味、クラス図のひし形、CDの2つの使い分け、合流が止まるコンフリクト、決定を遅らせる理由、KPTでTryを後に決める理由、スプリント途中の割り込みの扱いを集めています。
この単元は、作る前に決めることと、作ったあとに確かめることが半分ずつです。
要件定義とテストは、一見すると離れた工程に見えますが、表と裏の関係にあります。要件定義で決めたことを確かめるのがブラックボックステスト、作ったものの中身を確かめるのがホワイトボックステスト。そのため、片方では見つからない誤りがあり、両方を使う必要があります。
出題される中では、条件網羅の問題だけが直感に反します。落ち着いて、判定式全体が真になっているかを確かめてください。
問1
要件定義の誤りは、後の工程で見つかるほど直す手間が大きくなる。その理由として最も適切なものはどれか。
正解は 4番：設計・プログラム・テストがすべて、その誤りを前提に作られてしまっているため
要件定義の段階なら文書を1行直せば済みますが、実装が終わってからだと、設計もプログラムもテストもすべて直すことになります。しかも、設計以降のテストは「決めたとおりに作れたか」を見る作業なので、決めた内容そのものが違っていても止まりません。出てくるのは、正しく作られた、欲しくなかったものです。気づけるのは、利用者が実際に使って確かめる受入テストの段階になってからになります。
ほかの選択肢は
人数や決まりごとの問題ではなく、誤りが後の工程すべてに運ばれていくことが理由です。
問2
要件定義で書かれる文として、適切なものはどれか。
正解は 3番：利用者が、在庫数を商品ごとに確認できること
要件定義は「何を作るか」を決める工程で、主語は利用者です。工程の名前を並べられて迷ったときは、その文の主語が誰かを見てください。利用者が〜したい、〜できること、と書かれていれば要件定義です。
ほかの選択肢は
どの表のどの列から取るか、どの部品で作るか、どの製品を使うかは、いずれも「どう作るか」の話なので設計にあたります。要件定義の文に、プログラムの作りや製品名は出てきません。出てきたら設計の話だと判断できます。
問3
ブラックボックステストにおける同値分割の説明として、適切なものはどれか。
正解は 4番：同じ結果になる入力を1つのまとまりと見て、そこから代表を1つだけ選ぶ
入力として考えられる値は膨大なので、全部を試すことはできません。同じ結果になる入力をまとまりと見て、代表を1つ選ぶことで数を減らします。1以上100以下の整数を受け付けるなら、0以下・1〜100・101以上の3つのまとまりができます。
ほかの選択肢は
境目の値を選ぶのは限界値分析のほうで、この2つは対立するものではなく、まとまりを決めてからその境目を突く、という順で組にして使います。分岐を通るように入力を選ぶのはホワイトボックステストの考え方です。
問4
ブラックボックステストでは見つけにくいものとして、最も適切なものはどれか。
正解は 1番：使われていない処理が、プログラムに残っていること
ブラックボックステストは、入力と出力が仕様どおりかを見ます。使われていない処理が残っていても、外から見た振る舞いが仕様どおりなら気づけません。
ほかの選択肢は
逆に、仕様書に書かれた機能の作り忘れは、仕様に沿ってテストを用意していれば見つかります。ここはホワイトボックステストと正反対で、あちらは既にあるプログラムを通るだけなので、そもそも足りていない機能を見つけられません。境目の受け付け方の誤りは、限界値分析でまさに狙うところです。
問5
「A かつ B」という判定を持つ処理に対し、(A が真, B が偽) と (A が偽, B が真) の2件でテストした。このとき満たしている網羅基準はどれか。
正解は 3番：条件網羅は満たすが、判定条件網羅は満たさない
条件網羅は「個々の条件が、それぞれ真と偽の両方を取る」という基準です。この2件では A も B も真と偽を取っているので満たします。ところが判定式（A かつ B）は、どちらの件でも偽です。真のときを1度も通っていないので、判定条件網羅は満たしません。つまり、条件網羅を満たしても判定条件網羅を満たすとは限らない。名前が似ていて直感にも反するので、ここは文として覚えてしまうのが確実です。
ほかの選択肢は
2つを入れ替えた選択肢、どちらも満たすとした選択肢は、いずれも判定式が偽のままである点を見落としています。複数条件網羅は、条件の組合せを4通りすべて通す基準なので、2件では足りません。なお判定式が真にならない以上、処理そのものも通っていないので、命令網羅も満たしていません。
問6
ホワイトボックステストで網羅率が100%になっても、見つけられないものはどれか。
正解は 1番：仕様書に書かれた機能が、そもそも作られていないこと
ホワイトボックステストは、既にあるプログラムの通り道を見るテストです。すべての分岐を通り、網羅率が100%であっても、書かれていない処理はテストのしようがありません。そのため、機能の作り忘れは見つかりません。
ほかの選択肢は
通らない分岐や実行されない命令は、まさに網羅率が教えてくれるものです。条件式の書き間違いも、両方の側を通してみれば気づける可能性があります。中の通り道はホワイトボックス、仕様との突き合わせはブラックボックス。この役割分担があるので、両方を使います。
問7
スクラムにおけるスクラムマスターの役割として、最も適切なものはどれか。
正解は 1番：チームが進められるように、妨げを取り除いて場を整える
スクラムマスターは管理者ではありません。指示を出して人を動かす役ではなく、チームが進めるように場を整え、妨げを取り除く役です。ここは選択肢でよく入れ替えられます。
ほかの選択肢は
何を作るかの優先順位を決めるのはプロダクトオーナー、実際に作るのは開発者で、役割は3つに分かれています。成果物を関係者に見てもらう場はスプリントレビューという別のイベントです。なお、進め方そのものを見直す場はふりかえりで、成果物を見るのか進め方を見るのかで分かれます。
問8
XP（エクストリームプログラミング）のプラクティスである、テスト駆動開発の説明として適切なものはどれか。
正解は 2番：テストを先に書き、それが通るように実装する
テスト駆動開発は、順番が逆であることが特徴です。実装してからテストを書くと説明されていれば誤りなので、選択肢の中でここを入れ替えてきます。
ほかの選択肢は
2人1組で書くのはペアプログラミング、外から見た動きを変えずに中身を整理し直すのはリファクタリングで、どちらもXPの別のプラクティスです。XPには、頻繁に統合してそのつどテストする継続的インテグレーションや、顧客と一緒に次に作るものを決める計画ゲームのように、進め方の実践も含まれます。
問9
ユーザビリティとアクセシビリティの違いとして、最も適切なものはどれか。
正解は 3番：ユーザビリティは決まった利用者にとっての使い心地、アクセシビリティは使える人の幅を測る
ユーザビリティは、決まった利用者が決まった目的を、どれだけ有効に・効率よく・満足して果たせるかの度合いです。アクセシビリティは、心身の条件や利用する環境によらず、そもそも使えるかどうかの度合いです。使える人の幅がアクセシビリティ、その人にとっての使い心地がユーザビリティ。この一文で選択肢は分けられます。建物でいえば、入口にスロープを付けて入れる人を増やすのがアクセシビリティ、入った人が目的の売場まで迷わずたどり着けるかがユーザビリティにあたります。
ほかの選択肢は
2つを入れ替えた選択肢が定番です。見た目や処理の速さを測るものでもありませんし、対象とする利用者の人数で分かれるものでもありません。測っているものそのものが違います。
問10
アクセシビリティが想定している利用者について、最も適切なものはどれか。
正解は 4番：腕を骨折している人や、明るい屋外にいる人のような、一時的な状態や環境も含む
アクセシビリティが想定しているのは、心身の条件や利用する環境によらず使えるかどうかです。腕を骨折していればマウスが使えませんし、明るい屋外では画面が見えにくく、電車の中では音が出せません。誰でも、いつでも当事者になりえます。そのため一部の人のための特別な配慮ではなく、使える人の幅を広げる設計として扱われます。
ほかの選択肢は
操作に慣れた人向けに情報量を増やすといった工夫は、使い心地の話であってアクセシビリティではありません。
問11
継続的デリバリ（CD）と継続的デプロイメントの違いとして、最も適切なものはどれか。
正解は 1番：継続的デリバリは本番へ出せる状態まで自動で用意し、継続的デプロイメントは本番への反映まで自動で行う
どちらも自動化する範囲の話ですが、止まる場所が違います。継続的デリバリは、テストを通ったものをいつでも本番へ出せる状態まで自動で用意するところまでで、出すかどうかの判断は人が持ちます。継続的デプロイメントはそこから先も自動で、本番への反映まで行います。出す判断を人が持つかどうかが分かれ目になります。
ほかの選択肢は
2つを入れ替えた選択肢が定番の誤答です。テストとビルドの自動化は、その前の段階にあたる継続的インテグレーション（CI）が受け持ちます。開発側と運用側で分ける見方も誤りで、DevOpsは両者の壁をなくす考え方なので、作業を担当で割る説明とは向きが逆になります。
問12
UI・ユーザビリティ・UXの関係として、最も適切なものはどれか。
正解は 3番：UIは利用者と機械の接点、ユーザビリティはその接点を使ったときの使い心地、UXは知る前から使い終えたあとまでの体験の全体を指す
UIは手段、ユーザビリティはその手段の出来、UXは結果として残るものです。この順に見ている範囲が大きくなります。ユーザビリティが測るのは操作している最中で、有効さ・効率・満足度という3つで表します。UXはその前後まで含み、申し込みの手間や、使い終えたあとにまた使いたいと思うかどうかも入ります。
ほかの選択肢は
UIを満足度、ユーザビリティを見た目の美しさとした選択肢は、3語の役割をまとめて入れ替えたものです。3つが同じものということもありません。UIを良くすれば必ずUXが良くなる、というのも誤りで、価格や届くまでの日数、問い合わせの返事の速さも体験に入るため、画面だけでは決まりません。
問13
Webページのアクセシビリティを高める取り組みとして、適切でないものはどれか。
正解は 1番：見出しや強調したい文言を、整った書体の画像にして掲載する
画像の中の文字は、読み上げソフトが読めず、拡大しても粗くなり、選択してコピーすることもできません。書体を整えたい場合は、文字のまま置いてCSSで見せ方を指定します。アクセシビリティの取り組みは、どれも「別の手段でも伝わるようにする」という考え方でつながっています。
ほかの選択肢は
代替テキストを付ければ、目で見られなくても読み上げで内容が伝わります。キーボードだけで操作できれば、マウスが使えない人も最後まで進めます。色だけに頼らなければ、色の見分けがつきにくい人にも伝わります。いずれも適切な取り組みです。
問14
DevOpsについての説明として、適切でないものはどれか。
正解は 1番：自動化ツールを導入すれば、それだけでDevOpsを実現したことになる
DevOpsは、開発と運用が同じ目標を持って動けるようにする考え方です。自動化の道具はその手段にすぎず、入れただけで目標が共有されるわけではありません。試験でも、ツールの導入を答えにした選択肢は誤りとして置かれます。
ほかの選択肢は
目標を共有して自動化で結び付けること、本番へ出してよいかの判断が残ること、運用部門をなくすのではなく分断を解消することは、いずれもDevOpsの説明として正しい内容です。手順が軽くなっても、管理の外に出るわけではありません。
問15
ユーザビリティを測るときに、はじめに決めておかなければならないこととして最も適切なものはどれか。
正解は 2番：どの利用者が、どの目的を果たす場合について測るのか
ユーザビリティは、特定の利用者が特定の目的を、有効に・効率よく・満足して果たせる度合いとして定義されます。誰が、何をする場合かを決めないと度合いを測れません。はじめて使う人には難しくても、毎日使う人には速い、ということが起こるためです。
ほかの選択肢は
機器の種類や解像度は測定の条件の一部にすぎません。他社製品との比較は必須ではなく、自社の中での改善でも測れます。予算や人数は改善を進めるときの制約であって、測るための前提ではありません。
問16
画面の操作そのものは速く迷いもないのに、UXとしては評価が低くなる例として最も適切なものはどれか。
正解は 4番：申し込みは画面上で完結するが、解約の窓口が電話しかない
UXは、使っている最中だけでなく、使う前と使ったあとまで含めた体験全体を指します。操作そのものが快適でも、解約に電話が要る、書類の郵送が必要といった事情があれば、残る印象は悪くなります。使っている間だけを良くしても全体は良くならない、というのがUXという言葉が置かれた理由です。
ほかの選択肢は
ボタンの位置が揃っていない、入力欄の名前が分かりにくい、処理が遅いといったものは、いずれも操作している最中の問題です。これらはユーザビリティの範囲で、画面の操作そのものに不満が出ている状態にあたります。
問17
バーンダウンチャートで、実績線が理想線より上を通っている。この状態が意味するものはどれか。
正解は 1番：予定より遅れている
縦軸は残っている作業量です。実績線が上にあるということは、同じ時点で残っている量が予定より多い、つまり遅れているということになります。
ほかの選択肢は
進んでいるのは、実績線が理想線より下にあるときです。グラフは上にあるほどよい、と読む習慣があるため、ここは取り違えやすいところになります。残りを描いている図なので、上下の意味が直感と逆になります。品質を表す図ではありません。
問18
UMLのクラス図で、線の端に黒く塗ったひし形が付いている。この表記が表すものはどれか。
正解は 2番：コンポジション
黒いひし形はコンポジションで、全体と部分の関係のうち、全体が消えると部分も存在できなくなる結び付きを表します。注文と注文明細がこの例にあたります。
ほかの選択肢は
白いひし形は集約で、部署と社員のように、全体が無くなっても部分は残る関係です。汎化は白い三角で、「〜の一種である」を表します。関連は飾りの無いただの線です。ひし形も三角も、全体または親の側に付きます。
問19
自動テストを用意しないまま継続的インテグレーションの仕組みだけを動かした場合、確かめられることはどれか。
正解は 3番：ビルドが通ること
ビルドが通るのは、文法の誤りが無いという意味でしかありません。自動テストが無ければ、計算結果が合っているかどうかは誰も見ていない状態になります。
ほかの選択肢は
計算結果が正しいかを確かめるのが自動テストの役目です。本番環境で動くかどうかは、さらに先の継続的デリバリや継続的デプロイメントで扱います。要求を満たしているかは、受入れの段階で人が確かめることです。CIを支える道具のうち、自動テストが本体にあたります。
問20
利用者に操作してもらいながら、そのとき考えていることを声に出して言ってもらう評価手法はどれか。
正解は 1番：思考発話法
思考発話法は、操作しながら考えを声に出してもらう方法です。観察するだけでは手が止まった理由までは分かりませんが、声に出してもらうと、何と何で迷ったのかまで見えます。そのかわり、しゃべりながらだとふだんどおりに操作できない、という弱さもあります。
ほかの選択肢は
回顧法は、操作が終わったあとに振り返って聞く方法で、思考発話法の弱さを避けられるかわりに忘れられてしまいます。ヒューリスティック評価は専門家が経験則に照らして問題点を洗い出す方法で、利用者を呼びません。アイトラッキングは、視線がどこを見ていたかを機器で記録する方法です。
問21
バージョン管理システムで、2人が同じ箇所を別々に書き換えたまま合流させようとしたところ、処理が止まって人に知らせてきた。この状態を何と呼ぶか。
正解は 1番：コンフリクト
コンフリクト（衝突）は、同じ場所への変更が食い違っていて、どちらを残すか道具には判断できない状態です。これは失敗ではありません。黙ってどちらかが消えるより、止めて人に知らせるほうが安全だからです。
ほかの選択肢は
コミットは変更をひとまとめにして履歴に記録する操作、ブランチは本線から分かれた作業用の枝、マージは枝を本線へ合流させる操作です。コンフリクトは、そのマージの途中で起きます。
問22
リーンソフトウェア開発の原則のうち、「決定を遅らせる」が意味することとして適切なものはどれか。
正解は 2番：取り返しのつく範囲で、判断に足る情報がそろうまで決めずに待つこと
ふつうは早く決めるほどよいとされます。リーンでは、決めたあとに分かることのほうが多いと考えます。情報が足りないまま決めると、あとでその決定を直すことになるためです。そこで、取り返しのつく範囲でぎりぎりまで待ち、材料がそろってから決めます。
ほかの選択肢は
判断を担当者に任せることは「人を尊重する」、分かったことを残すことは「知識を作り出す」に当たる原則で、どちらも決定を遅らせることとは別です。早い段階で確定させるのは、この原則とちょうど逆を向いた考え方になります。
問23
ノーコード開発とローコード開発に共通する注意点として、適切なものはどれか。
正解は 2番：現場で誰でも作れるため、把握されないアプリが社内に散らばりやすい
書く量が減るぶん、情報システム部門を通さずに現場が自分でアプリを作れます。手軽さの裏返しとして、誰が何を作ったのか分からないアプリが増えていきます。作った人が異動したあと、誰も直せないまま動き続ける、という形で表に出ます。
ほかの選択肢は
多くは事業者のクラウドの上で動くので、自社でサーバを用意するとは限りません。作ったものはその製品の仕組みに合わせて組み上がるため、ほかの製品へそのまま持ち出すことは難しく、特定の事業者から離れにくくなります。データを保存する仕組みも、ふつうは製品の側に用意されています。
問24
プラットフォーム開発で、土台を大きく取りすぎたときに起きることとして適切なものはどれか。
正解は 3番：特定の製品の事情が土台に入り込み、そこを直すとほかの製品が動かなくなる
土台は、すべての製品が共有しています。そこへ特定の製品の都合を取り込むと、その製品のために手を入れたときに、ほかの製品まで動かなくなります。影響の確認に時間がかかるようになり、やがて誰も土台に手を入れなくなります。
ほかの選択肢は
共通化の効果が出ないのは、土台が小さすぎる場合です。1つめの製品は、共通に使えるように作るぶん、むしろ時間がかかります。土台の不具合は、その土台を使っている製品すべてに出ます。大きすぎるほうが危険だ、という向きで覚えてください。
問25
プロトタイピングモデルが向かない場面として、最も適切なものはどれか。
正解は 2番：要求が最初から固まっていて、作る規模が大きい
試作を見せて反応をもらう進め方なので、見せるものを作る手間が毎回かかります。要求が固まっていれば、その手間は丸ごと無駄になります。規模が大きいほど試作の費用も大きくなるので、順に進める形のほうが合います。
ほかの選択肢は
言葉で説明しにくいとき、使い勝手を早く確かめたいとき、技術が使えるか試したいときは、いずれも動くものを見せたほうが速く決まります。プロトタイピングが向くのはこちら側です。
問26
KPTでふりかえりを行うとき、KeepとProblemを先に出し切ってからTryを決める理由として、最も適切なものはどれか。
正解は 4番：事実を出し切る前に対策を決めると、思いついた案に引きずられるため
順番に意味があります。先に対策を出すと、最初に出た案に話が寄ってしまい、ほかの問題が検討されないまま終わります。うまくいったことと困っていることを先に並べきってから、その中で何を試すかを選ぶ、という順で進めます。
ほかの選択肢は
会議を長くするための決まりではありません。KeepとProblemは担当者を決める欄ではなく、起きたことを並べる欄です。Tryは次のスプリントで実際に試すもので、やらない項目ではありません。
問27
スクラムで、スプリントバックログを作り、今回どれだけ引き受けるかを決めるのは誰か。
正解は 2番：開発者
作る量を決めるのは、作る本人たちです。割り当てられるのではなく自分たちで取る、というのがスクラムの要になる考え方で、毎日の進め方の調整も開発者が自分たちで行います。
ほかの選択肢は
プロダクトオーナーが決めるのは、何を作るかとその順番です。どう作るか、どれだけ取るかには口を出しません。スクラムマスターは進め方を支える役で、作業を割り当てる立場ではありません。ステークホルダは外から見る関係者です。
問28
OSのバージョンが上がったことに合わせて、既存のソフトウェアを動くように直した。この保守はどれか。
正解は 3番：適応保守
適応保守は、周りの環境が変わったことに合わせる保守です。OSやハードウェア、法律や制度の変更がきっかけになります。ソフトウェアそのものに欠陥があったわけではない、というところが見分けの手がかりです。
ほかの選択肢は
是正保守と予防保守は、どちらも欠陥が相手です。障害が起きてから直すのが是正保守、起きる前に直すのが予防保守になります。完全化保守は、性能や保守のしやすさを良くするために手を入れるもので、こちらも欠陥が相手ではありません。
問29
スプリントの途中で、新しくやってほしい項目が出てきた。スクラムでの扱いとして適切なものはどれか。
正解は 4番：プロダクトバックログへ入れて、次のスプリント以降で扱う
期間を固定して、その中で決めたぶんを作り切るのがスプリントの前提です。途中で割り込みを入れると、何がどこまでできるのかが読めなくなり、期間を区切った意味がなくなります。足したいものはプロダクトバックログへ入れ、次の回の候補にします。
ほかの選択肢は
今回のスプリントバックログへ足す、今回の項目と入れ替える、といった扱いは、いずれも割り込みにあたります。スプリントの中止は、目標そのものが意味を失ったときに限られる例外で、項目が1つ増えたことを理由には行いません。
問30
スタンドアップミーティング（デイリースクラム）の進め方として、適切なものはどれか。
正解は 3番：毎日同じ時刻に短時間で行い、開発者が自分たちの進め方を調整する
毎日、同じ時刻に、短い時間で行うのが決まりです。立ったまま行うのは、長引かせないための工夫です。目的は進め方の調整であって、報告ではありません。
ほかの選択肢は
できあがったものを関係者に見せるのはスプリントレビュー、管理者が進捗を確認して指示を出すのは、スクラムが避けている形です。この場は開発者のためのもので、報告会ではありません。問題を解決しきるのも、この場ではなく別の場で行います。
問31
アコーディオンとタブの違いとして、適切なものはどれか。
正解は 4番：アコーディオンは見出しが縦に並び、複数を同時に開ける作りにもできる
アコーディオンは見出しを縦に並べ、押したものの下に中身が開きます。複数を同時に開ける作りにすることもできます。タブは見出しを横に並べ、中身の出る場所は下の1か所だけなので、見られるのは1枚です。
ほかの選択肢は
同時に開けるかどうかの向きが逆の選択肢、前面にかぶせて後ろを止めるモーダルウィンドウの説明、横に送るカルーセルの説明が、それぞれ誤りとして並びます。どちらも比べて見るには向かない、という点は共通しています。
問32
ユースケース図で、あるユースケースが必ず別のユースケースを含むことを表す書き方はどれか。
正解は 4番：`<<include>>` を付けた破線
include は必ず含む、extend は場合によって加わる、という使い分けです。「本を借りる」が必ず「利用者を確認する」を含むなら include、延滞しているときだけ「延滞料を払う」が加わるなら extend になります。必ずか、場合によってか、で分かれます。
ほかの選択肢は
矢じりのない実線は、アクタとユースケースを結ぶ関連で、その人がそれを使うという意味です。白い三角の矢じりは汎化を表す書き方で、含む含まないの関係ではありません。
問33
ステートチャート図で、1つの状態から矢印が2本出ているとき、その読み方として適切なものはどれか。
正解は 1番：起きた出来事によって、どちらへ移るかが決まる
矢印には、何が起きたときに移るかが書かれています。2本出ているのは、起きる出来事が2通りあり、どちらが起きたかで行き先が変わるという意味です。注文であれば、入金されたときと取り消されたときで、進む先が分かれます。
ほかの選択肢は
同時に2つの状態になることはありません。1つのものが今どうなっているかを表す図なので、状態は常に1つです。描いた位置で優先順位が決まることもなく、優先したいときは角かっこの条件で書き分けます。分かれ道そのものは誤りではなく、図として正しい形です。
問34
SLCP（共通フレーム）の使い方として、適切なものはどれか。
正解は 4番：示された工程の中から、そのプロジェクトに必要なものを選んで使う
共通フレームは、取引の当事者が同じ言葉で話せるようにするための枠組みです。必要な工程を選び取って使うことが前提になっており、これをテーラリングと呼びます。小さな改修に全工程を当てはめる使い方は想定されていません。
ほかの選択肢は
すべて実施することを求める決まりではありません。認証を受ける制度でもなく、この点はPMBOKやITILと同じです。社外に公開しないという話ではなく、むしろ発注側と受注側が共通して参照することに意味があります。
問35
一覧から選ぶほかに、一覧に無い値を文字で入力させたい場合に使う画面部品はどれか。
正解は 2番：コンボボックス
コンボボックスは、押すと開く一覧からの選択に、文字の入力を足した部品です。一覧に無い値も入れられます。選ばせる形にできない項目で使いますが、入力を許す分だけ入力チェックが必要になります。
ほかの選択肢は
ドロップダウンリストとリストボックスは、どちらも一覧にあるものしか選べません。ラジオボタンは選択肢が最初から全部見えている形で、選べるのは1つだけ、かつ一覧に無い値は入れられません。
問36
操作を止めずに「保存しました」と短く知らせたい場合に使う部品として、最も適切なものはどれか。
正解は 2番：トーストメッセージ
トーストメッセージは画面の端に短く出て自動で消える部品で、答えてもらう必要のない知らせに向きます。保存の知らせのたびに操作を止めると、作業が進まなくなります。止める必要があるときだけ重ねて止める、という使い分けになります。
ほかの選択肢は
モーダルウィンドウは画面に重なって他の操作を止める部品で、消してよいかの確認のように答えてもらう必要があるものに使います。パンくずリストはいま居る場所を示す部品、ハンバーガーメニューは押すとメニューが開く部品です。
問37
V字モデルにおいて、要件定義の工程と対応するテストはどれか。
正解は 2番：運用テスト（受入テスト）
V字モデルは、設計の工程とテストの工程を対応させた見方です。要件定義で決めたことは運用テストで確かめ、外部設計はシステムテスト、内部設計は結合テスト、プログラミングは単体テストと対応します。何を決めた工程かで、確かめるテストが決まります。
ほかの選択肢は
単体テストはプログラミング、結合テストは内部設計、システムテストは外部設計に対応します。対応を1つずらして覚えていると、どの不備をどのテストで見つけるべきかの判断もずれます。
問38
リファクタリングを機能の追加や不具合の修正と同時に行わないほうがよい理由として、最も適切なものはどれか。
正解は 3番：動きが変わったときに、構造の整理が原因なのか別の変更が原因なのか切り分けられなくなるため
リファクタリングは、外から見た動きを変えずに構造を整える作業です。整理だけの変更であれば、テストの結果は変わらないはずだという形で確かめられます。機能の変更を混ぜると、この確かめ方が使えなくなります。
ほかの選択肢は
行数が必ず増えるわけではなく、重複をまとめれば減ることもあります。整理を先に行わなければ効果が出ない、という順序の決まりもありません。同時に行ってもテストの実行そのものは可能で、問題は結果の読み取りのほうです。
問39
例外を使って異常を知らせる方式が、戻り値で異常を返す方式より優れている点はどれか。
正解は 3番：呼出し元が受け取らなかった場合、そのまま進まずに上位へ伝わること
戻り値で返す方式では、呼出し元が判定を書き忘れると、誤った状態のまま先へ進みます。例外は受け取る相手がいなければ上位へ伝わり、最後まで受け取られなければ処理が止まるので、見落としに気づけます。
ほかの選択肢は
例外は処理を中断する仕組みで、続けるためのものではありません。画面への表示は別に書く必要があり、コンパイル時に異常の箇所を特定できるわけでもありません。
問40
アスペクト指向プログラミングを導入する際に、あわせて必要になることとして最も適切なものはどれか。
正解は 4番：適用する場所をルールで選べるように、クラス名やメソッド名の命名規則を定めること
ルールの条件には、クラス名やメソッド名に含まれる文字列のパターンが使えます。対象のメソッド名には決めた文字列を含め、対象外には含めない、という命名規則を定めることで、実装する側の負担を小さく保てます。
ほかの選択肢は
1行ずつ書き加えるのは、まとめて書けるようにするという目的と逆になります。クラスを統合することも、処理をデータベース側へ移すことも、この考え方とは関係がありません。
この結果の使い方
間違えた用語は復習リストに自動でたまります。 用語ページのミニクイズで正解し直すと、リストから消えます。 記録は自分のブラウザ内（localStorage）にのみ保存され、サーバーには送信していません。