コンテンツにスキップ

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

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

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

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

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

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

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

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

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

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

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

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

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

試験で出るポイント

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

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

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

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

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

[ユースケース図の例を挿入]

試験で出るポイント

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

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

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

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

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

Section titled “継続的インテグレーション(CI)と継続的デリバリー(CD)”

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

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

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

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

試験で出るポイント

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

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

Section titled “MLOps ── 機械学習の開発と運用”

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

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

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

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

試験で出るポイント

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

アプリで問題を解こう!