応用情報技術者 ― システム開発技術 問題一覧・解説

📝 解説

ウォーターフォールモデルは「水が高いところから低いところへ流れる（滝）」ように各工程を順番に進める開発モデルです。建物の設計・建築に例えると非常にわかりやすいです。まず「この建物に何が必要か？」（要件定義）、次に「全体の間取りと構造は？」（基本設計）、「各部屋の詳細な仕様は？」（詳細設計）、「実際に建築する」（プログラミング・製造）、「完成後に検査する」（テスト）、「引き渡し後の管理」（運用・保守）という流れです。最初に行うのは「要件定義」で、ユーザーのニーズ・業務要件・システムに必要な機能を明確にする最も重要な工程です。要件定義が曖昧だと後工程で設計をやり直す「手戻り」コストが非常に大きくなります。ウォーターフォールは計画通りに進めやすく大規模開発に向きますが、要件が変わると上流に戻る手戻りコストが高いという弱点があります。誤答の「基本設計」「詳細設計」はいずれも要件定義の後工程です。「ウォーターフォールの最初＝要件定義」を確実に覚えましょう！',["要件定義"

📝 解説

アジャイル（Agile：機敏な）開発は「短い反復サイクル（イテレーション・スプリント）を繰り返しながら開発を進める」手法です。レストランの料理提供に例えると、ウォーターフォールが「全メニューの仕込みを完全に終えてから一斉に提供する」なら、アジャイルは「まず3品提供してお客様の反応を見ながら次の料理を調整して提供する」イメージです。スクラム（Scrum）は2〜4週間のスプリントを繰り返す代表的なアジャイルフレームワークです。各スプリントで動作するソフトウェアを作り、顧客・ステークホルダーのフィードバックを次スプリントに活かします。これにより要件の変化に柔軟に対応できます。ウォーターフォールと比べると「最初に全仕様を決定しない」「変化を歓迎する（ウォーターフォールは変化に弱い）」「顧客との継続的なコミュニケーション」「動くソフトウェアを頻繁にリリース」が特徴です。誤答の「工程を厳密に分け後戻りしない」「最初に全仕様を決定」はウォーターフォールの特徴です。「短サイクルの繰り返し・変化に柔軟＝アジャイル」と覚えましょう！',["短い期間で開発とリリースを繰り返し、変化に柔軟に対応する。"

📝 解説

ブラックボックステストは「中身が見えない箱（プログラム）に対して、外から入力を与えて期待通りの出力が得られるか確認する」テスト手法です。自動販売機を例にするとわかりやすいです。内部の回路や機械がどうなっているかを知らなくても「100円入れてコーラのボタンを押したらコーラが出てくるか」を確認できますよね。これがブラックボックステストの発想です。仕様書（入力と期待される出力の定義）だけを使ってテストケースを設計します。代表的な技法として「同値分割（有効・無効な値のグループに分けてそれぞれの代表値でテスト）」と「境界値分析（境界の値に近いところに欠陥が多いためその値をテスト）」があります。一方ホワイトボックステストは「中身が見える状態」でプログラムの命令・分岐・ループを網羅的に検証します。「外から見た動作確認＝ブラックボックス」「内部構造の検証＝ホワイトボックス」という違いを整理しましょう。誤答の「論理構造を検証する」はホワイトボックステストの説明で、「性能や負荷耐性を検証する」は性能テストの説明です！',["内部構造を意識せず、入力に対して期待される出力が得られるかを確認する。"

📝 解説

ホワイトボックステストは「プログラムの内部構造（ソースコード）を完全に把握した状態」で行うテスト手法です。建物の配管・電気配線の施工検査に例えると、外側から問題なく見えても内部の配管や配線が正しく接続されているか直接確認するようなものです。ホワイトボックステストでは命令網羅（C0：全ての命令文を1度は実行する）・分岐網羅（C1：全ての条件分岐の真・偽両方を実行する）・条件網羅（C2：全ての条件式の組み合わせを実行する）などのカバレッジ基準を満たすようにテストケースを設計します。「条件分岐を網羅する」という表現があればホワイトボックステストのC1（分岐網羅）を指します。主に単体テスト（ユニットテスト）の段階で開発者が実施します。誤答のブラックボックステストは内部構造を意識せず仕様に基づいてテストする方法（自動販売機の外から動作確認するイメージ）です。受入テストはユーザが実施する最終確認テスト、リグレッションテストは変更後に既存機能が壊れていないかを確認するテストです。「条件分岐網羅・内部構造検証＝ホワイトボックステスト」と覚えましょう！',["ホワイトボックステスト"

📝 解説

リファクタリングは「家を建て替えずに内装をリノベーションする」ような作業です。外側から見た機能（住む・調理する・眠るなど）は変わらないのに、内部の間取りを使いやすく整理したり古くなった配管を交換したりして将来の改修を容易にします。プログラムでも同様に、ユーザーから見た動作（入力→出力の結果）は変えずに、コードの重複を排除する・長すぎるメソッドを分割する・わかりにくい変数名をわかりやすく変える・複雑な条件式を簡潔にするなどの改善を行います。目的は「保守性・可読性・拡張性の向上」です。単体テストを用意してリファクタリング前後で動作が同じであることを確認するのが鉄則です。XP（エクストリームプログラミング）でも継続的なリファクタリングが重視されています。誤答の「デバッグ」はバグの発見・修正で外部動作が変わります、「リバースエンジニアリング」は完成品から設計情報を逆に取り出す行為、「ポーティング」は別の環境（OSやプラットフォーム）で動くように移植することです。「外部動作を変えずに内部を整理＝リファクタリング」と確実に覚えましょう！',["リファクタリング"

📝 解説

UML（Unified Modeling Language：統一モデリング言語）はシステムの設計図を描くための標準言語で、用途に応じた様々な種類の図があります。ユースケース図は「誰が（アクター）・何をする（ユースケース）」をシステムの外側から見た視点で描く図です。映画館のシステムで例えると、「お客様（アクター）→チケットを購入する（ユースケース）」「映写担当者（アクター）→上映スケジュールを管理する（ユースケース）」というように、システムへの外部からの要求（機能）を整理します。要件定義の段階で「このシステムは誰のために何ができるか」を関係者と合意形成するために使われます。UMLの他の図との違いを整理すると、クラス図は「システムの静的な構造（クラス・属性・メソッドと関係）」を表現します。シーケンス図は「オブジェクト間のメッセージのやり取りを時系列で表現」します。ステートマシン図は「オブジェクトの状態変化と遷移トリガー」を表現します。「ユーザの視点からシステムの機能を描く＝ユースケース図」と確実に覚えましょう！',["ユースケース図"

📝 解説

ソフトウェアの保守（メンテナンス）は4種類に分類されます。建物の管理に例えると理解しやすいです。是正保守は「雨漏りを修理する（バグ修正）」で既存の欠陥を直す作業です。適応保守は「法改正で耐震基準が変わったため補強工事をする」もので環境変化（OSのアップデート・法律改正・ハードウェア変更等）に対応するための修正です。完全化保守は「より快適にするためリフォームする」で機能追加・性能改善など新たな要求に応える改修です。予防保守は「将来のリスクに備えて老朽配管を交換する」で将来の保守性を高めるための改善です。「OSのアップデートなどの環境変化に対応する」のは適応保守です。是正保守（バグ修正）と混同しやすいですが、是正保守は「動作に問題がある（バグがある）」ときの修正、適応保守は「動作には問題はないが環境が変わった」ための修正という違いがあります。「4種類の保守：是正（バグ修正）・適応（環境変化）・完全化（機能追加）・予防（将来対策）」をまとめて覚えましょう！',["適応保守"

📝 解説

ペアプログラミングはXP（エクストリームプログラミング）の代表的な実践プラクティスで、「2人1組でプログラムを書く」手法です。料理番組で例えると、一方のシェフ（ドライバー）が実際に調理（コードを入力）しながら、もう一方のシェフ（ナビゲーター）がレシピと工程を確認しながら助言する形です。ドライバーがコードを入力し、ナビゲーターがリアルタイムでレビューして設計上の誤りやバグを即座に指摘します。この役割は定期的に交代します。一見「2人がかりで非効率では？」と思われますが、リアルタイムコードレビューにより品質が向上し後工程でのバグ修正コストが大幅に減ります。また知識の共有・若手育成の効果もあります。誤答の「コードインスペクション（フォーマルレビュー）」は会議形式で複数人がコードを検査する手法で、事前にコードを読んで会議で指摘する形式です。「ウォークスルー」は非公式なレビューで作成者が参加者に説明します。「2人がリアルタイムでコードを書きながらレビュー＝ペアプログラミング」と覚えましょう！',["ペアプログラミング"

📝 解説

DevOpsは「Development（開発）＋Operations（運用）」を合わせた概念で、開発チームと運用チームが壁を作らずに協力し合う文化・手法・ツールの総称です。従来の開発では「開発チームは新機能を素早く作りたい」「運用チームはシステムの安定稼働を優先したい（変更は怖い）」という相反する目標があり、リリースのたびに調整が大変でした。DevOpsではこの壁を取り除き、CI（継続的インテグレーション：コードのビルド・テストを自動化）とCD（継続的デリバリー/デプロイ：リリースを自動化）を通じて品質を保ちながら高頻度でリリースできる体制を作ります。電鉄会社に例えると、車両設計チームと運行管理チームが緊密に連携することで新型車両の投入をスムーズに行いながら日常の安定運行も維持するようなイメージです。誤答の「開発工程を全て自動化しプログラマを不要にする」「全インフラをクラウド化」「セキュリティを最終工程に集中」はいずれもDevOpsの定義と異なります。「開発と運用の連携強化・迅速かつ継続的なシステム価値提供＝DevOps」と覚えましょう！',["開発チームと運用チームが連携し、システムの価値を迅速かつ継続的に提供する。"

📝 解説

ソフトウェアのテスト工程は「単体テスト→結合テスト→システムテスト→受入テスト」という順番で進みます。建物の完成検査に例えると理解しやすいです。単体テストは「各部屋の設備・建具をそれぞれ単体でチェック」、結合テストは「各部屋をつないだときのドア・水道・電気の連携確認」、システムテストは「建物全体として問題ないかの完成検査」、そして受入テストは「施主（発注者）が実際に建物を使ってみて要望通りに仕上がっているか確認する引き渡し前の最終確認」です。受入テスト（ユーザ受入テスト：UAT）は開発者・テスト担当者ではなく実際にシステムを使う発注者・エンドユーザが実施し、「実際の業務でシステムが使えるか」を確認して本番稼働への承認を行います。「誰がテストするか」で判断すると確実です。システムテストは開発ベンダーが実施し、受入テストは発注者・ユーザが実施します。誤答の「システムテスト」は開発側が行う最終確認、「結合テスト」はモジュール間連携の確認、「運用テスト」は受入テストの別称として使われる場合もあります。「発注者・ユーザが実施する最終テスト＝受入テスト（UAT）」と覚えましょう！',["受入テスト"

📝 解説

ウォーターフォールモデルは「滝が上から下へ一方向に流れるように、各工程を順番に進める」開発モデルです。建物の建設に例えると、設計図が完成しないと基礎工事を始められない、基礎工事が終わらないと柱を立てられない、という「前工程が完了したら次工程へ」という一方向の流れと同じです。要件定義→基本設計→詳細設計→実装→テスト→運用という工程を順番に進め、前の工程に戻らないことを原則とします。メリットは「進捗が明確」「ドキュメントが充実」「大規模・要件固定型プロジェクトに向く」こと。デメリットは「要件変更に弱い」「後工程まで動くものが見えない」「手戻りのコストが大きい」ことです。誤答の「短い反復サイクル」はアジャイル開発（スクラム・XP等）、「プロトタイプを繰り返し作成」はプロトタイプモデル、「スパイラル状に繰り返す」はスパイラルモデルの特徴です。「ウォーターフォール＝一方向・工程順・大規模・要件固定向き」を押さえましょう！

📝 解説

アジャイル開発は「短い反復サイクル（イテレーション/スプリント）で開発と改善を繰り返し、変化する要件に柔軟に対応する」手法です。大きな橋を一気に設計・建設するのではなく、まず仮橋を作って渡ってみて問題があれば改良し、それを繰り返して完成に近づけるイメージです。アジャイル宣言（2001年）の4つの価値として「プロセスよりも個人と対話」「包括的なドキュメントより動くソフトウェア」「契約交渉より顧客との協調」「計画遵守より変化への対応」が掲げられています。スクラム・XP・カンバンなどが代表的な手法です。2〜4週間のスプリントを繰り返し、各スプリント終了時に動作するソフトウェアをレビューして方向性を調整します。変化する要件に強く、早期に価値を提供できるのが強みですが、要件が頻繁に変わるため「ドキュメント重視」や「一方向の工程進行」とは対極にあります。「アジャイル＝短い反復サイクル＋顧客との継続コミュニケーション＋変化への対応力」が核心です！

📝 解説

テストには大きく2種類あります。ブラックボックステストは「プログラムの内部構造（ソースコード）を見ずに、入力と出力の関係だけを確認する」テスト手法です。電化製品のテストに例えると、テレビのリモコンを押したら正しいチャンネルに変わるか確認するのがブラックボックスで、テレビの内部回路の動作を検証するのがホワイトボックスです。ブラックボックステストの代表的な技法として、同値分割（有効・無効な入力値グループに分けてテスト）、境界値分析（境界の前後の値を重点的にテスト）、デシジョンテーブルテスト（条件の組み合わせを表形式で整理）などがあります。主にシステムテストや受け入れテストで使われます。一方ホワイトボックステストは内部構造（コードのパス）を検証するテストで単体テストで使われます。誤答の「内部構造を詳細に検証する」はホワイトボックステスト、「セキュリティの脆弱性を検証する」はセキュリティテスト・ペネトレーションテスト、「負荷をかけてシステムの限界を確認する」は負荷テスト・ストレステストの説明です。