主なソフトウェア開発手法

ソフトウェア開発手法とは

ソフトウェアを作るとき、プログラムをいきなり書き始めるわけではありません。「どのような考え方でソフトウェアを設計・開発するか」という基本的なアプローチを決める必要があります。このアプローチのことをソフトウェア開発手法と呼びます。

ここでは、ITパスポート試験で問われる代表的な開発手法として、構造化手法とオブジェクト指向の2つを中心に学びます。さらに、近年注目されているDevOpsやMLOpsといった開発・運用の連携手法についても押さえていきましょう。

構造化手法

構造化手法とは、プログラムの処理を「順番に実行する」「条件で分岐する」「繰り返す」という3つの基本構造だけで組み立てる考え方です。

たとえば、料理のレシピを考えてみてください。「材料を切る → 鍋に入れる → 火にかける → 味付けする」のように、処理の手順を上から順に整理していきます。構造化手法では、このように処理の手順（手続き）を中心にプログラムを設計します。

構造化手法の特徴は、大きな問題を小さな部品（モジュール）に分割して、一つずつ解決していく点にあります。プログラムの流れが明確になるため、初学者にもわかりやすい手法です。

オブジェクト指向

オブジェクト指向は、構造化手法とは異なるアプローチでソフトウェアを設計する手法です。処理の手順ではなく、「モノ（オブジェクト）」を中心に考えます。

オブジェクトとは、データ（属性）とそのデータに対する操作（メソッド）をひとまとめにしたものです。たとえば「自動車」というオブジェクトは、「色」「速度」といったデータと、「走る」「止まる」といった操作をセットで持っています。

現実世界のモノを直感的にプログラムに表現できるため、大規模なソフトウェア開発で広く使われています。また、一度作ったオブジェクトを別のシステムでも再利用しやすいという利点があります。

構造化手法とオブジェクト指向の比較

2つの手法の違いを整理しておきましょう。

項目	構造化手法	オブジェクト指向
設計の中心	処理の手順（手続き）	モノ（オブジェクト）
考え方	処理を順番に並べて整理する	データと操作をひとまとめにする
適した規模	比較的小規模なプログラム	大規模・複雑なシステム
再利用性	低い	高い（オブジェクトを再利用できる）

試験で出るポイント

構造化手法は「手続き中心」、オブジェクト指向は「オブジェクト（モノ）中心」という対比を押さえておきましょう。選択肢で両者を入れ替えた引っかけが出ることがあります。

ユースケースとUML

オブジェクト指向でソフトウェアを開発するとき、設計内容をチームで共有するための「共通の書き方」が必要になります。そこで使われるのがUML（Unified Modeling Language：統一モデリング言語）です。

UMLは、ソフトウェアの構造や動きを図で表現するための世界共通の表記法です。文章だけでは伝えにくい設計内容を、図を使って視覚的に表現できるため、開発メンバー同士の認識のズレを減らすことができます。

UMLで使われる図にはさまざまな種類がありますが、ITパスポート試験では特にユースケースという考え方が重要です。ユースケースとは、システムを「利用者（ユーザー）がどのように使うか」という視点で整理したものです。たとえば、ネットショッピングのシステムであれば「商品を検索する」「カートに入れる」「注文する」といった使い方がユースケースにあたります。

ユースケースを図にまとめたものをユースケース図と呼び、システムの機能と利用者の関係をひと目で把握できます。

graph LR
  Actor["🧑 利用者"]:::primary
  subgraph sys["ネットショッピングシステム"]
    UC1(["商品を検索する"]):::base
    UC2(["カートに入れる"]):::base
    UC3(["注文する"]):::base
  end
  Actor --- UC1
  Actor --- UC2
  Actor --- UC3

  classDef base fill:#f8fafc,stroke:#94a3b8,stroke-width:1px,color:#333;
  classDef primary fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e40af;
  classDef alert fill:#fef2f2,stroke:#dc2626,stroke-width:2px,color:#991b1b;

試験で出るポイント

UMLは「ソフトウェアの設計を図で表す統一的な表記法」、ユースケースは「利用者がシステムをどう使うかを整理したもの」と理解しておきましょう。

DevOps ── 開発と運用の連携

ソフトウェアは、作って終わりではありません。リリース後も、不具合の修正や新機能の追加、サーバーの監視など、継続的な運用が必要です。従来、ソフトウェアの開発側（Development）と運用側（Operations）は別々のチームとして活動することが一般的でした。しかし、この体制では「開発チームは新機能を早くリリースしたい」「運用チームは安定稼働を優先したい」という対立が生まれがちでした。

DevOps（デブオプス）は、開発側と運用側が密接に連携し、ソフトウェアの開発からリリース、運用までを一体的に進める取り組みです。「Development（開発）」と「Operations（運用）」を組み合わせた造語です。

DevOpsの大きな特徴は、自動化ツールを活用して、テスト・ビルド・リリースなどの作業を効率化する点にあります。これにより、高品質なソフトウェアを迅速かつ頻繁にリリースできるようになります。

graph LR
  subgraph Dev["開発 Dev"]
    Plan["計画"]:::primary
    Code["コード作成"]:::primary
    Build["ビルド"]:::primary
    Test["テスト"]:::primary
  end

  subgraph Ops["運用 Ops"]
    Release["リリース"]:::alert
    Deploy["デプロイ"]:::alert
    Operate["運用"]:::alert
    Monitor["監視"]:::alert
  end

  Plan --> Code --> Build --> Test
  Test --> Release --> Deploy --> Operate --> Monitor
  Monitor -->|"フィードバック"| Plan

  classDef base fill:#f8fafc,stroke:#94a3b8,stroke-width:1px,color:#333;
  classDef primary fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e40af;
  classDef alert fill:#fef2f2,stroke:#dc2626,stroke-width:2px,color:#991b1b;

継続的インテグレーション（CI）と継続的デリバリー（CD）

DevOpsを実現するための重要な仕組みとして、継続的インテグレーション（CI：Continuous Integration）と継続的デリバリー（CD：Continuous Delivery）があります。

継続的インテグレーション（CI）とは、開発者がプログラムの変更を行うたびに、自動的にビルド（プログラムの組み立て）やテストを実行する仕組みです。たとえば、チームの誰かがプログラムを修正したら、すぐに自動テストが走り、問題があればその場で検出されます。これにより、不具合を早期に発見でき、品質を保ちながら開発を進められます。

継続的デリバリー（CD）とは、CIで品質が確認されたソフトウェアを、いつでもリリースできる状態に保つ仕組みです。リリース作業も自動化されているため、必要なタイミングで迅速にユーザーへ届けることができます。

CIとCDを組み合わせることで、「コードの変更 → テスト → リリース」という一連の流れが自動化され、DevOpsの目指す迅速なソフトウェア提供が実現します。

試験で出るポイント

DevOpsの問題は毎年のように出題されています。「開発側と運用側が密接に連携し、自動化ツールを活用して迅速に機能を導入・更新する」という定義を正確に押さえましょう。ウォーターフォール型の説明やプロトタイピングの説明と混同させる選択肢に注意してください。

MLOps ── 機械学習の開発と運用

MLOps（エムエルオプス）は、DevOpsの考え方を機械学習（ML：Machine Learning）の分野に応用したものです。「Machine Learning」と「Operations」を組み合わせた造語です。

機械学習では、データを使ってモデル（予測や判断を行う仕組み）を作りますが、一度作ったモデルも時間が経つと精度が落ちることがあります。たとえば、商品の売上を予測するモデルは、消費者の好みが変われば予測が外れるようになります。

MLOpsは、機械学習モデルの開発・テスト・運用・改善を継続的に行う取り組みです。DevOpsと同様に、自動化ツールを活用してモデルの品質を維持し、常に最新のデータに基づいた予測ができるようにします。

用語	対象	目的
DevOps	ソフトウェア全般	開発と運用の連携による迅速なリリース
MLOps	機械学習モデル	モデルの開発・運用の継続的な改善

試験で出るポイント

MLOpsは「DevOpsの機械学習版」と理解しておけば十分です。機械学習モデルの開発・運用を継続的に改善する取り組みであることを押さえましょう。

過去問で実力チェック

過去問に挑戦

Q. ソフトウェア開発におけるDevOpsに関する記述として，最も適切なものはどれか。

ア開発側が重要な機能のプロトタイプを作成し，顧客とともにその性能を実測して妥当性を評価する。
イ開発側と運用側が密接に連携し，自動化ツールなどを活用して機能などの導入や更新を迅速に進める。
ウ開発側のプロジェクトマネージャが，開発の各工程でその工程の完了を判断した上で次工程に進む方式で，ソフトウェアの開発を行う。
エ利用者のニーズの変化に柔軟に対応するために，開発側がソフトウェアを小さな単位に分割し，固定した期間で繰り返しながら開発する。

解答（令和元年）

正解: イ

Q. 開発担当者と運用担当者がお互いに協調し合い，バージョン管理や本番移行に関する自動化のツールなどを積極的に取り入れることによって，仕様変更要求などに対して迅速かつ柔軟に対応できるようにする取組を表す用語として，最も適切なものはどれか。

ア DevOps
イ WBS
ウプロトタイピング
エペアプログラミング

解答（令和2年）

正解: ア

Q. システムの開発側と運用側がお互いに連携し合い，運用や本番移行を自動化する仕組みなどを積極的に取り入れ，新機能をリリースしてサービスの改善を行う取組を表す用語として，最も適切なものはどれか。

ア DevOps
イ RAD
ウオブジェクト指向開発
エテスト駆動開発

解答（令和4年）

正解: ア

Q. ソフトウェア開発におけるDevOpsに関する記述として，最も適切なものはどれか。

ア運用側で利用する画面のイメージを明確にするために，開発側が要件定義段階でプロトタイプを作成する。
イ開発側が，設計・開発・テストの工程を順に実施して，システムに必要な全ての機能及び品質を揃えてから運用側に引き渡す。
ウ開発側と運用側が密接に連携し，自動化ツールなどを取り入れることによって，仕様変更要求などに対して迅速かつ柔軟に対応する。
エ一つのプログラムを2人の開発者が共同で開発することによって，生産性と信頼性を向上させる。

解答（令和5年）

正解: ウ

Q. ソフトウェアの開発におけるDevOpsに関する記述として，最も適切なものはどれか。

ア開発側が重要な機能のプロトタイプを作成し，顧客とともにその性能を実測して妥当性を評価する。
イ開発側では，開発の各工程でその工程の完了を判断した上で次工程に進み，総合テストで利用者が参加して操作性の確認を実施した後に運用側に引き渡す。
ウ開発側と運用側が密接に連携し,自動化ツールなどを活用して機能の導入や更新などを迅速に進める。
エシステム開発において，機能の拡張を図るために，固定された短期間のサイクルを繰り返しながらプログラムを順次追加する。

解答（令和6年）

正解: ウ

もっと過去問を解きたい方へ

フライトパスアプリなら、詳しい解説や分野別の過去問演習、SRS（間隔反復）学習ができます。

App Store Google Play