【ITパスポート練習問題 6.3対応】(1) 主なソフトウェア開発手法

【解説】

正解: 2 システム全体の構造を階層的に整理する

この問題は、構造化手法が何を目的とした手法なのか、その本質を理解できているかを確認するものです。特に、「プロジェクト管理」や「性能向上」といった他の目的と区別しながら、構造化手法がシステム全体の構造整理に焦点を当てていることを押さえられているかが問われています。

選択肢2の「システム全体の構造を階層的に整理する」は、構造化手法の目的を正しく表した内容です。構造化手法では、システム全体を大まかな機能から細かな処理へと分解し、階層構造として整理します。これにより、システムの見通しが良くなり、設計内容の理解や変更、保守が行いやすくなります。

選択肢1の「プロジェクト管理の進捗を可視化する」は、ガントチャートなどプロジェクトマネジメントの手法の目的であり、構造化手法そのものの目的ではありません。選択肢3の「プログラムの実行速度を最適化する」は、チューニングや性能改善の領域の目的であり、構造化手法の主眼である「構造の整理」「見通しの向上」とは異なります。

【解説】

正解: 2 データフロー図

この問題は、構造化手法で代表的に用いられる技法を区別できているかを確認するものです。特に、「プロジェクト管理の図」と「オブジェクト指向の図」とを見分けながら、構造化手法と結び付けられるかがポイントです。

選択肢2の「データフロー図」は、構造化手法で用いられる代表的な図の一つです。データフロー図では、システム内でデータがどこから来て、どこへ流れ、どの処理で変換されるのかを矢印と箱で表現します。これにより、システム全体の処理構造やデータの流れが視覚的に把握しやすくなります。

選択肢1の「ガントチャート」は、作業の開始日・終了日や進捗を棒グラフ形式で表すプロジェクト管理のための図であり、構造化手法の技法ではありません。選択肢3の「ユースケース図」は、オブジェクト指向設計やUMLで用いられる図で、ユーザーとシステムの関わりを表現するものです。これも構造化手法の代表例とは言えません。

【解説】

正解: 3 開発コストの削減と短縮

この問題は、構造化手法を導入することで直接的に狙っている効果と、結果として「期待されるかもしれない副次的な効果」とを区別できるかを確認するものです。構造化手法の主な狙いがどこにあるのかを理解しているかが問われています。

選択肢3の「開発コストの削減と短縮」は、構造化手法が「直接目指す効果」としては不適切な内容です。構造化手法は、システムを分割・階層化して整理し、理解しやすく保守しやすい構造にすることが主な目的です。結果として、手戻りの低減や保守性の向上を通じてコスト削減につながる場合はありますが、それはあくまで間接的な効果です。

選択肢1の「システムの保守性の向上」は、構造化手法の重要な目的です。処理を分割・整理しておくことで、後から機能を変更・追加する際にも影響範囲が分かりやすくなり、保守がやりやすくなります。選択肢2の「プロセスの分割とモジュール化」も、構造化手法の中心的な考え方です。大きな処理を小さなモジュールに分割し、それぞれを独立して理解・実装できるようにすることが構造化の狙いと一致しています。

【解説】

正解: 1 データと処理を一つの単位にまとめる

この問題は、オブジェクト指向の特徴的な考え方を一言で説明できるかどうかを確認するものです。特に、「データ」と「それを扱う処理」をどのようにとらえるかが問われています。

選択肢1の「データと処理を一つの単位にまとめる」は、オブジェクト指向の核心的な特徴を表しています。オブジェクト指向では、データ（属性）と、そのデータに対する操作（メソッド）をまとめて「オブジェクト」として扱います。これにより、現実世界の「もの」や「概念」をプログラム上で自然に表現しやすくなり、再利用性や保守性の向上につながります。

選択肢2の「開発工程を厳密に定義する」は、開発プロセスや開発手法（ウォーターフォールなど）の話であり、オブジェクト指向の特徴ではありません。選択肢3の「データの流れを明確化する」は、データフロー図など構造化手法で重視される観点であり、オブジェクト指向の説明としては不適切です。

【解説】

正解: 2 モジュール分割

この問題は、オブジェクト指向で重要とされる「基本概念」を正しく言い分けられるかどうかを確認するものです。オブジェクト指向特有の用語と、より一般的な設計概念を区別できているかがポイントです。

選択肢2の「モジュール分割」は、オブジェクト指向に特有の概念名ではないため、オブジェクト指向の主要な概念には含まれません。モジュールに分割するという考え方自体は、構造化手法などさまざまな開発手法で用いられる一般的な設計の考え方です。

選択肢1の「継承」は、あるクラスの性質や振る舞いを別のクラスが引き継ぐオブジェクト指向の基本概念です。既存クラスを基に拡張したクラスを作ることで、再利用性や拡張性を高められます。選択肢3の「カプセル化」も、データと処理をオブジェクト内部に隠蔽し、外部からは決められたインタフェースだけを通じてアクセスさせる考え方で、オブジェクト指向の中心的な概念です。

【解説】

正解: 3 あるクラスの性質を別のクラスが引き継ぐ

この問題は、オブジェクト指向における「継承」という概念を具体的な説明に結びつけられるかを確認するものです。継承が何を引き継ぎ、どのような関係を表すのかを理解しているかが問われています。

選択肢3の「あるクラスの性質を別のクラスが引き継ぐ」は、継承の内容をそのまま説明したものです。親クラス（スーパークラス）の属性やメソッドを、子クラス（サブクラス）が受け継ぐことで、共通部分を再利用しながら、子クラス固有の機能を追加することができます。これにより、コードの重複を減らし、拡張しやすい設計が実現できます。

選択肢1の「オブジェクトを複数のクラスに分ける」は、オブジェクトとクラスの関係を誤って表現しており、継承とは関係がありません。オブジェクトはクラスの実体であり、「分ける」という表現は適切ではありません。選択肢2の「処理手順を階層化して整理する」は、構造化手法などで見られる考え方であり、処理の流れを階層的に整理する話であって、クラス間の継承関係を説明したものではありません。

【解説】

正解: 2 システムの機能要件をユーザー視点で明確にする

この問題は、ユースケースの役割を理解しているかを確認するものです。特に、「誰が」「何をするのか」という観点から、システムの機能をユーザー視点でとらえる手法であることを説明できるかが問われています。

選択肢2の「システムの機能要件をユーザー視点で明確にする」は、ユースケースの目的を正しく表現しています。ユースケースでは、「ユーザー（アクター）がシステムを使ってどのような目的を達成するか」をシナリオとして書き出すことで、利用者から見た機能要件を整理します。これにより、開発側と利用者側の認識合わせがしやすくなり、要件定義の土台となります。

選択肢1の「データの流れを可視化する」は、データフロー図など構造化手法の目的であり、ユースケースの役割とは異なります。選択肢3の「プログラムの構造を設計する」は、クラス図やパッケージ図など設計工程で用いられる成果物の目的であり、ユーザー視点の機能要件を整理するユースケースの目的とは一致しません。

【解説】

正解: 1 システムの構造を視覚的に分解する

この問題は、ユースケースが何を表現するための手法なのかを踏まえたうえで、「ユースケースの主な利用目的として適切でないもの」を選べるかどうかを確認するものです。ユースケースが得意とするのは「機能の整理」であって、「構造の分解」でないことを理解しているかがポイントです。

選択肢1の「システムの構造を視覚的に分解する」は、ユースケースの主な利用目的としては不適切です。システム構造の分解や構造の見える化は、クラス図やコンポーネント図、データフロー図など、他の図や手法が担う役割です。

選択肢2の「システムの機能をユーザーの視点で記述する」は、ユースケースの中心的な利用目的です。ユーザーがどのような目的でシステムを利用するのかを、シナリオを通じて具体的に記述します。選択肢3の「要件定義の具体化を支援する」も、ユースケースの重要な役割です。業務フローやヒアリング結果をユースケースとして整理することで、あいまいだった要件を具体的な機能要件に落とし込むことができます。

【解説】

正解: 2 システムとやり取りする外部の役割

この問題は、ユースケース図で使われる用語「アクター」の意味を正しく理解しているかを確認するものです。システム内部の要素なのか、外部の要素なのかを区別できているかがポイントです。

選択肢2の「システムとやり取りする外部の役割」は、アクターの定義を正しく表しています。アクターは、人間の利用者に限らず、他のシステムや外部サービスなど、対象システムとインタラクションを行う外部の存在・役割を指します。ユースケース図では、アクターとシステムの関係を図示することで、誰がどの機能を利用するかを明確にします。

選択肢1の「システムの中核機能」は、システム内部の機能そのものであり、アクターとは逆の立場にあります。選択肢3の「システム内部のデータ」も、システムの内側にある情報であり、外部からシステムを利用する主体を表すアクターの定義とは異なります。

【解説】

正解: 2 ソフトウェア開発の視覚的な仕様記述を支援する

この問題は、UML（Unified Modeling Language）の役割や位置付けを理解しているかを確認するものです。特に、UMLが「何専用の図」なのか、「どの工程を支援するものか」を押さえられているかが問われています。

選択肢2の「ソフトウェア開発の視覚的な仕様記述を支援する」は、UMLの主な特徴を正しく表しています。UMLは、クラス図やユースケース図、シーケンス図などの統一された記法を使って、システムの構造や振る舞い、相互作用を視覚的に表現し、仕様や設計を分かりやすく伝えるためのモデリング言語です。

選択肢1の「データの流れを図示する技法に限定される」は、UMLをデータフロー図のような一種類の図に限定してしまっている点で誤りです。UMLには多数の種類の図があり、構造・振る舞い・相互作用などさまざまな観点を扱います。選択肢3の「システムの動作テストを効率化する」は、テストツールやテスト設計技法の領域に近い内容であり、UMLの直接的な目的とは言えません。

【解説】

正解: 3 フローチャート

この問題は、UMLで規定されている代表的な図の種類を把握しているかを確認するものです。UMLに含まれる図と、一般的な図表表現を区別できるかが問われています。

選択肢3の「フローチャート」は、UMLの図としては定義されていないため、UMLの代表的な図には含まれません。フローチャートは、処理手順や業務手順を「開始」「条件分岐」「処理」などの記号で表す一般的な図であり、UMLとは別の記法です。

選択肢1の「ユースケース図」は、UMLで定義されている図の一つで、アクターとユースケースの関係を表し、システムの機能をユーザー視点で整理するために用いられます。選択肢2の「クラス図」もUMLの代表的な図であり、クラス間の関係や属性・操作を図示することで、システムの静的構造を表現します。

【解説】

正解: 1 システムの構造と動作を視覚的に表現する

この問題は、UMLがなぜソフトウェア開発の現場で利用されるのか、その主な目的を理解しているかを確認するものです。設計書の「見せ方」として、UMLが果たす役割を把握しているかがポイントです。

選択肢1の「システムの構造と動作を視覚的に表現する」は、UMLの利用目的を的確に表しています。UMLを使うことで、クラスの構造やオブジェクト間のメッセージのやり取り、状態の遷移などを図として表現し、関係者間で仕様や設計の内容を共有しやすくなります。

選択肢2の「開発スケジュールを管理する」は、ガントチャートなどプロジェクト管理の領域であり、UMLの役割ではありません。選択肢3の「システムのパフォーマンスを計測する」は、負荷試験ツールやモニタリングツールなどの仕事であり、UML自体は性能計測を行うための仕組みではありません。

【解説】

正解: 2 開発と運用の連携を深める

この問題は、DevOpsの基本的な考え方を理解しているかを確認するものです。特に、「開発（Development）」と「運用（Operations）」の関係をどう捉えるかが問われています。

選択肢2の「開発と運用の連携を深める」は、DevOpsの主な目的を端的に表した内容です。DevOpsでは、開発チームと運用チームが対立するのではなく、一体となって継続的なリリースやシステムの安定運用を目指します。自動化ツールや共有の仕組みを活用しながら、リリースサイクルの短縮と品質の維持を両立させることが狙いです。

選択肢1の「開発と運用の分離を徹底する」は、従来型の縦割り組織に近い発想であり、DevOpsの目指す方向とは逆です。DevOpsはまさに分断を乗り越えるための取り組みです。選択肢3の「データの流れを整理する」は、データモデリングや構造化手法の目的に近い内容であり、DevOpsの本来の目的とは異なります。

【解説】

正解: 3 システム構造の変更頻度の増加

この問題は、DevOpsにより得られるメリットの内容を正しく理解しているか、また「メリットではないもの」を見分けられるかを確認するものです。リリース頻度とシステム構造の変更を混同しないことがポイントです。

選択肢3の「システム構造の変更頻度の増加」は、DevOpsのメリットとしては適切ではありません。DevOpsによりリリース頻度が増えることはありますが、それは小さな変更や改善をこまめに反映しやすくなるという意味であり、システム構造そのものを頻繁に大きく変更することを目的としているわけではありません。

選択肢1の「リリースサイクルの短縮」は、DevOpsの代表的なメリットです。自動テストや自動デプロイの仕組みを整えることで、変更を早く安全に本番環境へ反映できるようになります。選択肢2の「コミュニケーションの改善」も、開発と運用の壁を低くするDevOpsの重要な効果です。チーム間で情報共有が進むことで、障害対応や改善活動がスムーズになります。

【解説】

正解: 1 継続的インテグレーション

この問題は、DevOpsの実践でよく使われる手法やプラクティスを理解しているかを確認するものです。DevOpsと関連の深いキーワードを選べるかがポイントです。

選択肢1の「継続的インテグレーション」は、DevOpsで広く採用されている手法です。開発者が変更したコードを頻繁に共通のリポジトリに統合し、そのたびに自動ビルドや自動テストを実行することで、統合時の不具合を早期に発見できます。これにより、品質を保ちながら素早いリリースにつなげることができます。

選択肢2の「データモデリング」は、データ構造やデータベース設計に関する技法であり、DevOps専用の手法ではありません。選択肢3の「アーキテクチャ設計」も、システム全体の構造や技術選定を行う設計活動のことで、DevOpsそのものの手法というより、より前工程の設計領域に属するものです。

【解説】

正解: 1 モデルの継続的な運用と管理を目的とする

この問題は、MLOpsが何を対象とし、どのような目的で導入される取り組みなのかを理解しているかを確認するものです。特に、通常のソフトウェア開発との違いとして「機械学習モデルの運用」に焦点があることを押さえられているかが問われています。

選択肢1の「モデルの継続的な運用と管理を目的とする」は、MLOpsの特徴を正しく表しています。MLOpsでは、学習済みモデルを本番環境で安定して動かし続けるために、学習・デプロイ・モニタリング・再学習といった一連のプロセスを継続的に回す仕組みを整えます。これにより、データの変化に合わせてモデルの精度を維持・改善し続けることができます。

選択肢2の「システム設計の効率化を目的とする」は、一般的な設計プロセスの改善を指す内容であり、機械学習モデルに特化したMLOpsの目的とは異なります。選択肢3の「モジュールの再利用性を高める」も、ソフトウェア設計全般での狙いとしてはあり得ますが、MLOps固有の目的を説明したものではありません。

【解説】

正解: 3 ソフトウェアのユーザインタフェース設計

この問題は、MLOpsが具体的にどのような領域をサポートするのか、逆にどの範囲は対象外なのかを区別できているかを確認するものです。機械学習モデルに関わるプロセスと、一般的なアプリケーション設計のプロセスを切り分けて考えられるかがポイントです。

選択肢3の「ソフトウェアのユーザインタフェース設計」は、MLOpsが直接サポートする領域ではないため、不適切な内容です。UI設計は画面レイアウトや操作性の検討など、フロントエンド寄りの設計活動であり、MLOpsの中心となる「モデルの学習・デプロイ・監視」とは別の領域です。

選択肢1の「機械学習モデルのモニタリング」は、MLOpsで重要な要素です。モデルの予測結果や精度、レスポンス時間などを継続的に監視し、性能劣化を早期に発見します。選択肢2の「モデルのトレーニングとデプロイ」も、MLOpsが支援する主要なプロセスであり、新しいデータで再学習を行い、そのモデルを本番環境に自動的にデプロイする仕組みづくりが重視されます。

【解説】

正解: 2 モデルの精度維持や改善のため

この問題は、MLOpsにおける「継続的なトレーニング」が何のために行われるのか、その目的を理解しているかを確認するものです。機械学習モデルが時間とともに劣化する可能性があることを前提に、その対処方法を把握しているかが問われています。

選択肢2の「モデルの精度維持や改善のため」は、継続的なトレーニングの目的を正しく表しています。実運用の中でデータの傾向が変化すると、最初に学習したモデルの予測精度が徐々に低下することがあります。そこで、新しいデータを取り込みながらモデルを再学習し、精度を維持・向上させ続けることが重要になります。

選択肢1の「データの流れを整理するため」は、データフロー設計やデータモデリングの目的に近い内容であり、継続的トレーニングの直接の目的ではありません。選択肢3の「モジュール分割を明確にするため」は、ソフトウェア構造の設計に関する話であり、機械学習モデルのトレーニングプロセスの目的とは異なります。