【ITパスポート練習問題 6.3対応】(1) システム開発のプロセス – 1

【解説】

正解: 2 ユーザー認証機能の提供

この問題は、システム開発における「機能要件」と「非機能要件」の違いを正しく理解しているかを確認するものです。要件定義には、システムが「何をすべきか（機能）」と「どのような品質であるべきか（非機能）」の2つの側面があります。

機能要件とは、ユーザーが業務を行うためにシステムが必ず実装していなければならない機能のことです。「ユーザー認証機能の提供」は、ユーザーがシステムにログインして利用するという具体的な動作（機能）を指しているため、機能要件に該当します。

一方、選択肢1の「データの処理速度」は性能に関する要件、選択肢3の「サーバーの可用性」はシステムの稼働率や信頼性に関する要件であり、これらは機能そのものではなく品質や性能を定義する「非機能要件」に分類されます。

【解説】

正解: 1 ユーザーがレポートを出力できる機能

この問題は、具体的なシステムの要求事項を見て、それが「機能要件」にあたるかどうかを判断できるかを確認するものです。

機能要件は、入力、出力、演算、登録など、システムが実行する具体的な処理を指します。「ユーザーがレポートを出力できる機能」は、システムが提供すべき具体的なサービスそのものであるため、機能要件の正しい例です。

選択肢2の「一定時間以内に結果を表示する」はレスポンスタイムという「性能」に関する要件であり、非機能要件です。選択肢3の「システムの障害発生頻度の抑制」はシステムの「信頼性」に関する要件であり、これも非機能要件に含まれます。

【解説】

正解: 3 データのバックアップ処理の方法

この問題は、提示された要件の中から「機能要件ではないもの（非機能要件）」を見分けられるかを確認するものです。

機能要件が「何ができるか」を定義するのに対し、非機能要件は「どのように運用・維持されるか」などの品質面を定義します。「データのバックアップ処理の方法」は、データの保全性や復旧性に関わる運用・保守の観点（信頼性や運用性）で決定されるものであり、一般的に非機能要件として扱われます。

選択肢1の「システム内でデータの整合性が保たれる機能」や、選択肢2の「エラーメッセージをユーザーに表示する機能」は、システムが実行する具体的な処理や挙動であるため、機能要件に含まれます。

【解説】

正解: 2 システムのレスポンス時間の短縮

この問題は、「非機能要件」の定義を理解し、具体的な例を選び出せるかを確認するものです。

非機能要件とは、機能以外のすべての要件を指し、性能、信頼性、セキュリティ、保守性などが含まれます。「システムのレスポンス時間の短縮」は、システムがいかに速く応答するかという「性能（パフォーマンス）」に関する要件であるため、非機能要件として正しい選択肢です。

選択肢1の「ユーザー認証機能の提供」や選択肢3の「データの集計処理機能」は、システムが提供する具体的な「機能」そのものであるため、機能要件に分類されます。

【解説】

正解: 3 商品検索機能

この問題は、非機能要件の範囲を理解し、それに該当しない「機能要件」を識別できるかを確認するものです。

「商品検索機能」は、ユーザーが商品を検索するという具体的なシステムの働き（機能）ですので、これは機能要件です。したがって、非機能要件には含まれないため、これが正解となります。

選択肢1の「サーバーの稼働率」は信頼性や可用性に関する指標、選択肢2の「ユーザーインターフェースのデザイン（使いやすさ）」は使用性に関する指標であり、これらはいずれもシステムの品質に関わる非機能要件です。

【解説】

正解: 3 業務プロセスの自動化機能

この問題は、非機能要件の特徴を理解し、機能要件との違いを明確に区別できるかを確認するものです。

「業務プロセスの自動化機能」は、これまで手動で行っていた業務をシステムが代行するという「機能」そのものの提供を意味します。これはシステムが「何をするか」にあたるため、機能要件です。非機能要件の特徴としては誤りとなります。

選択肢1の「システムの拡張性」は将来の変更のしやすさ（保守性・移植性）、選択肢2の「データベースへのアクセス権限」はセキュリティに関する要件であり、これらはシステムの品質や制約を定義する非機能要件の特徴です。

【解説】

正解: 2 設計やコードの問題を早期に発見し改善する

この問題は、システム開発における「レビュー（共同レビュー）」を行う主な目的を理解しているかを確認するものです。

共同レビュー（ピアレビュー）は、作成された成果物（設計書やプログラムコード）を複数のメンバーでチェックする活動です。主な目的は、テスト工程に入る前の早い段階で誤りや不具合を見つけ出し、手戻りを減らして品質を向上させることにあります。

選択肢1の「システムの稼働率向上」や選択肢3の「プログラムの処理速度向上」は、適切な設計や実装の結果として得られる効果や非機能要件の目標値であり、レビュー活動そのものの直接的な目的（活動の狙い）とは異なります。

【解説】

正解: 1 チーム内での知識共有と品質向上が図れる

この問題は、レビューを実施することによる組織的なメリットを理解しているかを確認するものです。

レビューを通じて他者のコードや設計を見ると、技術的な学びや業務知識の共有が進みます。また、ベテランが若手の成果物をチェックすることでノウハウが継承され、属人化の防止やチーム全体のスキルアップ、そして成果物の品質向上につながります。これが推奨される大きな理由です。

選択肢2の「進捗状況の報告」は進捗会議の目的であり、レビューの主目的ではありません。選択肢3の「納期が早くなる」については、長期的には手戻りが減って早くなる可能性がありますが、レビュー実施自体には時間がかかるため、単純に納期短縮を理由とするのは不適切です。

【解説】

正解: 3 バグ修正の進捗確認

この問題は、共同レビューという「技術的な品質確認の場」と、プロジェクト管理における「進捗確認の場」を区別できているかを問うものです。

共同レビューは、成果物の中身（設計書やコード）に誤りがないかを技術的に検証する場です。「バグ修正の進捗確認」は、いつまでに終わるか、どれくらい完了したかというスケジュールの管理活動であり、レビューの場で行う内容としては適していません。

選択肢1の「設計やコードの問題点」や、選択肢2の「ドキュメントの内容確認」は、誤りや曖昧さを排除するためにレビューで重点的に確認すべき項目です。

【解説】

正解: 2 システムの効率性

この問題は、ソフトウェアの品質を評価する基準である「品質特性（ISO/IEC 25010など）」についての知識を確認するものです。

品質特性とは、機能適合性、信頼性、使用性、効率性（性能効率性）、保守性、移植性などを指します。「システムの効率性」は、リソースをどれだけ有効に使っているか、応答時間は適切かなどを評価する品質特性の一つです。

選択肢1の「システムの開発コスト」や選択肢3の「テストの実施回数」は、プロジェクト管理上の指標（コスト、プロセス品質）であり、ソフトウェア製品そのものが持つ品質特性とは異なります。

【解説】

正解: 2 システムの継続稼働が重要な場合

この問題は、品質特性の一つである「信頼性」が、具体的にどのような場面で重視されるかを理解しているかを確認するものです。

信頼性とは、システムが故障せずに安定して動き続ける能力のことです。銀行のシステムやインフラ設備など、「システムの継続稼働が重要」であり、停止することが許されないシステムにおいて特に重視されます。

選択肢1の「デザイン変更が頻繁に発生する場合」に求められるのは、修正のしやすさである「保守性」です。選択肢3の「処理速度の速さが優先される場合」に求められるのは、「性能効率性」です。

【解説】

正解: 1 操作が簡単でユーザーにとって分かりやすい

この問題は、品質特性の一つである「使用性（ユーザビリティ）」の意味を正しく理解しているかを確認するものです。

使用性とは、ユーザーにとっての使いやすさ、理解しやすさ、習得しやすさなどを指します。「操作が簡単でユーザーにとって分かりやすい」ことは、使用性の高いシステムの特徴そのものです。

選択肢2の「データの処理が高速である」は性能効率性、選択肢3の「システムのエラー頻度が低い」は信頼性に関する特徴です。

【解説】

正解: 2 ユーザーが使用する具体的な機能の詳細化

この問題は、開発工程における「基本設計（機能設計）」の役割を理解しているかを確認するものです。

機能設計（外部設計とも呼ばれます）は、ユーザーからの要件をもとに、ユーザーの視点から見たシステムの振る舞いを決定する工程です。ここでは、「ユーザーが使用する具体的な機能」や画面、帳票のレイアウトなどを詳細化し、ユーザーと合意形成を行います。

選択肢1の「システムの処理速度の決定」は要件定義で決めるべき非機能要件の目標値です。選択肢3の「プログラムのバグ修正」は、もっと後の工程であるテスト段階で行う作業です。

【解説】

正解: 1 画面遷移やデータの流れの設計

この問題は、機能設計（外部設計）で具体的に何を決めるのか、その成果物のイメージを持っているかを確認するものです。

機能設計では、ユーザーがシステムをどう操作するかというインターフェース部分が重要になります。したがって、どの画面からどの画面へ移動するかという「画面遷移」や、入力されたデータがどう処理されて出力されるかという「データの流れ」の設計が中心的な作業となります。

選択肢2の「サーバーのハードウェア仕様」はインフラ設計などの技術的な設計に含まれます。選択肢3の「プロジェクトの進捗管理方法」はプロジェクトマネジメント計画の一部であり、システムの設計とは異なります。

【解説】

正解: 3 サーバーの負荷テスト実施

この問題は、設計工程とテスト工程の作業内容を明確に区別できているかを確認するものです。

「サーバーの負荷テスト実施」は、システム構築後のテスト工程（システムテストや運用テスト）で行う検証作業です。設計段階である機能設計では、まだ動くシステムが存在しないため、負荷テストを実施することはできません。

選択肢1の「データのやり取りの方法の検討」や選択肢2の「ユーザー操作に合わせた画面設計」は、システムが外部（ユーザーや他システム）とどう関わるかを決めるものであり、機能設計の主要な作業内容です。

【解説】

正解: 1 各機能を実現するためのモジュール構成やデータベース設計

この問題は、「詳細設計（内部設計）」がシステムのどの部分を定義する工程かを理解しているかを確認するものです。

詳細設計は、開発者（プログラマ）に向けた設計図を作成する工程です。機能設計で決まった機能をプログラムとしてどう実装するかを考え、プログラムを部品（モジュール）に分割したり、データベースのテーブル構造（物理設計）を決めたりします。

選択肢2の「システムの必要な機能のリスト」は要件定義や基本設計で作成されるものです。選択肢3の「ユーザーからのフィードバックの収集」は、設計後のレビューやテスト段階での活動です。

【解説】

正解: 2 各モジュールやデータベースの具体的な構成の決定

この問題は、詳細設計の成果物が具体的になんであるかを理解しているかを確認するものです。

詳細設計の目的は、コーディング（プログラミング）ができるレベルまで仕様を落とし込むことです。そのため、プログラム内部の「各モジュール（関数やクラスなど）の役割や処理内容」、およびデータを格納する「データベースの具体的な構成（型や桁数など）」を決定します。

選択肢1の「各画面のデザインイメージ作成」は、ユーザーの目に触れる部分であり、基本設計（外部設計）で行う作業です。選択肢3の「システム全体の要件の決定」は最上流の要件定義工程で行います。

【解説】

正解: 3 デバッグを行い不具合を修正する

この問題は、設計工程と製造（プログラミング・テスト）工程の境界線を理解しているかを確認するものです。

「デバッグを行い不具合を修正する」作業は、実際にプログラムコードを書いた後（コーディング工程やテスト工程）に発生するものです。詳細設計の段階ではまだプログラムが存在しないため、デバッグ作業は含まれません。

選択肢1の「画面の操作手順を設計する」は基本設計の内容とも言えますが、詳細設計でより細かく詰めることもあります。選択肢2の「プログラムのモジュール構成を決める」は詳細設計の核心的な作業です。選択肢3が明らかに工程が異なるため、正解となります。

【解説】

正解: 2 詳細設計をもとにした正確な実装

この問題は、コーディング（プログラミング）工程において技術者が最も意識すべき規律を理解しているかを確認するものです。

コーディング工程の役割は、前工程で作成された「詳細設計書」の内容を、コンピュータが実行可能なプログラム言語に翻訳することです。勝手な機能追加や変更を行わず、設計書通りに「正確に実装」することが最も重視されます。

選択肢1の「プログラムの動作速度の確認」は後のテスト工程で行う性能検証です。選択肢3の「ユーザーインターフェースのデザイン」は設計工程で決定済みであり、コーディング段階で新たにデザインを考えるわけではありません。

【解説】

正解: 2 プログラムが正常に機能するように設計内容をコードにする

この問題は、コーディングという作業の定義そのものを理解しているかを確認するものです。

コーディングとは、人間が理解できる設計書の内容を、コンピュータが理解できるプログラミング言語（ソースコード）に変換し、記述する作業のことです。目的は、設計された通りの機能が正常に動作するプログラムを作成することです。

選択肢1の「ユーザーの要件を満たすインターフェースの構築」は設計段階の目的です。選択肢3の「プログラム全体のエラーを解消する」はデバッグやテストの目的であり、コーディングはその前段階の「作成」に主眼があります。

【解説】

正解: 1 プログラムの実行速度の確認

この問題は、コーディング作業とテスト・検証作業の違いを理解しているかを確認するものです。

コーディングはプログラムを「書く」作業です。一方、「プログラムの実行速度の確認」は、書かれたプログラムを動かして性能を測定する作業であり、これはパフォーマンス（性能）テストの一部です。通常、コーディングとは別のタスクとして扱われます。

選択肢2の「プログラムの実装」はコーディングそのものです。選択肢3の「変数や関数名の命名」は、コードを書く際にプログラマが行う重要な作業の一つです。

【解説】

正解: 3 プログラムの内部処理やロジックの誤りを発見する

この問題は、テスト技法の一つである「ホワイトボックステスト」の特徴と目的を理解しているかを確認するものです。

ホワイトボックステストは、プログラムの内部構造（ソースコードの論理）が見えている状態で実施するテストです。条件分岐や繰り返し処理などの「内部処理やロジック」が、設計通りに正しく記述されているかを確認し、誤りを発見することを目的としています。

選択肢1の「システム全体の動作を確認する」や選択肢2の「ユーザーインターフェースの使いやすさを評価する」は、内部構造を考慮せずに行うブラックボックステストやユーザビリティテストの目的です。

【解説】

正解: 2 各分岐やループが正しく動作するかの確認

この問題は、ホワイトボックステストで具体的に何をチェックするのかを理解しているかを確認するものです。

ホワイトボックステストでは、プログラム内のすべての命令文や条件分岐（if文など）、ループ処理（for文など）を網羅的に実行し、論理的な漏れや誤りがないかを検証します。したがって、「各分岐やループの動作確認」が含まれます。

選択肢1の「外部仕様に基づく機能の確認」は、入力と出力の関係だけに注目するブラックボックステストの内容です。選択肢3の「システムの使用感の確認」も内部ロジックとは無関係な評価項目です。

【解説】

正解: 1 外部からの動作結果のみを確認する

この問題は、ホワイトボックステストとブラックボックステストの視点の違いを明確に理解しているかを確認するものです。

ホワイトボックステストは「内部構造」に着目するテストです。一方、「外部からの動作結果（入力に対する出力）のみを確認」し、内部でどう処理されているかを気にしないのは「ブラックボックステスト」の特徴です。したがって、1がホワイトボックステストの説明として誤りです。

選択肢2の「プログラムの内部構造を考慮してテストする」や、選択肢3の「ロジックに関するエラーを検出しやすい」は、ホワイトボックステストの正しい特徴です。

【解説】

正解: 3 プログラムの不具合を発見し修正する

この問題は、「デバッグ」という用語の基本的な意味と目的を理解しているかを確認するものです。

デバッグ（Debug）とは、プログラムに含まれる誤りや欠陥（バグ）を見つけ出し、それを取り除く（修正する）作業のことです。開発において、意図通りに動かない原因を突き止めて直すプロセス全体を指します。

選択肢1の「新しい機能を追加する」は機能拡張や仕様変更にあたります。選択肢2の「システム全体の性能を測定する」はパフォーマンステストであり、デバッグとは目的が異なります。

【解説】

正解: 2 エラー発生の原因を特定し、適切な修正を加える

この問題は、効率的かつ効果的なデバッグの手順を理解しているかを確認するものです。

デバッグで最も重要なのは、現象（エラー）から「真の原因」を特定することです。原因を突き止めずに場当たり的な修正を行うと、別のバグを生む可能性があります。原因を特定し、論理的に正しい「適切な修正を加える」ことが不可欠です。

選択肢1の「プログラムをテストせずにコードのレビューを行う」だけでは動的なエラーは見つけにくく、デバッグプロセスとしては不十分です。選択肢3の「コード全体を新しく書き直す」は最終手段であり、通常のデバッグ作業としては効率が悪すぎます。

【解説】

正解: 3 開発する機能を要件定義に基づいて再確認する

この問題は、デバッグという作業の範囲と、上流工程（要件定義など）の作業を区別できているかを問うものです。

デバッグは、作成されたプログラムが設計通りに動かない場合に、そのバグを取り除く作業です。「要件定義に基づいて機能を再確認する」作業は、そもそも何を作るべきかを確認する行為であり、デバッグの段階で行うべきことではありません（もしここに戻るなら、それはデバッグではなく手戻りや仕様変更です）。

選択肢1の「コードのエラー箇所を特定する」や、選択肢2の「不具合を修正した後にテストを行う（回帰テスト）」は、デバッグ作業の中心的なプロセスです。

【解説】

正解: 2 コードの品質と可読性を高める

この問題は、「コードレビュー」を実施する主な狙い（品質特性への貢献）を理解しているかを確認するものです。

コードレビューは、他の開発者がソースコードを読み、記述規約違反や論理的な誤り、わかりにくい記述などを指摘する活動です。これにより、バグの混入を防ぐだけでなく、誰にとっても読みやすく修正しやすいコードにすることで「品質と可読性を高める」ことが主な目的です。

選択肢1の「プログラムの動作速度を向上させる」ことはありますが、主目的ではありません。選択肢3の「ユーザーインターフェースを確認する」には、コードを見るよりも実際の画面を操作するテストの方が適しています。

【解説】

正解: 3 システム全体の設計を決定する

この問題は、コードレビューの役割と限界（何をする場で、何をしない場か）を理解しているかを確認するものです。

コードレビューは、すでに決定された設計に基づいて書かれたコードをチェックする場です。この段階で「システム全体の設計を決定する」ことはありません。設計はもっと前の工程（基本設計や詳細設計）で完了しているべきものです。

選択肢1の「他のメンバーの意見を取り入れてコードを改善する」や、選択肢2の「コードに潜むエラーを早期に発見する」は、コードレビューを行う正しい理由です。

【解説】

正解: 1 コードの可読性や適切な命名規則を確認する

この問題は、コードレビューの現場で具体的にどのようなポイントをチェックすべきかを知っているかを確認するものです。

コードレビューでは、バグの可能性だけでなく、「変数の名前はわかりやすいか（命名規則）」「インデントやコメントは適切か（可読性）」といった保守性に関わる部分も重点的に確認します。これらは機械的なテストでは発見しにくい部分だからです。

選択肢2の「プログラムの動作速度の調整」はチューニング作業であり、レビュー指摘を受けて行うことはあっても、レビューそのものの作業ではありません。選択肢3の「システムのインフラ設定を決定する」はインフラ設計や構築のタスクです。