開発技術

1. システム開発のプロセス

システムが企画から運用・保守までどんな順番で作られるのか、工程ごとの役割をつかめます。

業務で使うシステムは、いきなりプログラムを書き始めるわけではありません。まず「何が必要か」を決め、次に「どう作るか」を決め、それから作って、確かめて、使い始めます。この一連の流れをシステム開発のプロセスといい、要件定義 → システム設計 → プログラミング → テスト → ソフトウェア受入れ → 運用・保守 の順に進みます。

最初の要件定義（ソフトウェア要件定義）では、利用者の業務を調べ、システムに必要な機能（機能要件）と、応答速度や稼働率などの品質・性能（非機能要件）を文書にまとめます。ここでの取り違えは後工程で大きな手戻りになるため、利用者と開発者が内容に合意することが何より大切です。

システム設計は二段構えです。外部設計（基本設計）では、画面のレイアウト、印刷する帳票、他システムとやり取りするデータの形式など、利用者から見える部分を決めます。内部設計（詳細設計）では、その仕様を実現するためにプログラムをどんな部品（モジュール）に分け、どんな手順で処理するかという内部の構造を決めます。機能を適切に分割し、部品どうしの結び付きを弱く、部品の中のまとまりを強くしておくと、修正やテストがしやすくなります。

設計が固まったらプログラミングで実際のプログラムを作り、テストで誤りを取り除きます。完成したソフトウェアは発注者が確認したうえで受け取り（ソフトウェア受入れ）、本番稼働後は障害対応や法改正・業務変更への対応として運用・保守が続きます。システムは作って終わりではなく、使われている間ずっと手入れが必要です。

用語

要件定義

利用者の業務を調べて、システムに必要な機能や性能を決め、文書にまとめる最初の工程。ここで決めた内容が以降すべての工程の基準になる。

機能要件

システムが「何をできるか」を表す要求。例えば受注データを登録できる、月次の売上を集計できる、といった業務上の働きそのものを指す。

非機能要件

システムが「どのくらいの品質か」を表す要求。応答時間、同時に使える人数、稼働率、セキュリティ、保守のしやすさなど、機能以外の条件をいう。

外部設計（基本設計）

利用者から見える部分を決める設計工程。画面のレイアウト、帳票の様式、他システムとやり取りするデータの形式などを決め、利用者と確認する。

内部設計（詳細設計）

外部設計で決めた仕様を実現するために、プログラムの内部をどう作るかを決める設計工程。モジュールの分け方や処理手順を決める。利用者には直接見えない。

モジュール

プログラムを機能ごとに分けた部品のこと。小さくまとまった部品にしておくと、修正したときの影響が狭い範囲で済み、テストや他システムへの再利用もしやすくなる。

ユーザビリティ

使いやすさのこと。利用者が迷わず、少ない手間で目的を達成できるかを表す。分かりやすい表示や、入力ミスをその場で知らせる仕組みなどで高められる。

ソフトウェア受入れ

発注者が納入されたソフトウェアを運用テストなどで確認し、要求を満たしていれば正式に受け取る工程。検収ともいう。ここで合格すると本番稼働に移る。

運用・保守

本番稼働させて日々使えるようにするのが運用。障害の修正や、法改正・業務変更に合わせてソフトウェアを直すのが保守。開発費用より長い期間の費用がかかることも多い。

例題

出典・根拠：IPA「ITパスポート試験」シラバス Ver.6.5 大分類4：開発技術　中分類8：システム開発技術

2. テスト工程とレビュー

テストの4段階とV字モデル、ホワイトボックス／ブラックボックスの違い、レビューの種類を整理できます。

テストは小さい単位から大きい単位へ段階的に進めます。まずモジュール1本ごとに確かめる単体テスト、次に組み合わせてつなぎ目を確かめる結合テスト、続いて本番に近い環境でシステム全体を確かめるシステムテスト（総合テスト）、最後に利用者が実際の業務の流れで使えるかを確かめる運用テスト（受入テスト）です。前の段階を合格してから次に進むのが原則です。

この段階は開発の工程と1対1で対応しています。左側に要件定義 → 外部設計 → 内部設計 → プログラミングを下ろし、右側に単体テスト → 結合テスト → システムテスト → 運用テストを上げると、アルファベットのVの字になるのでV字モデルと呼びます。各テストは、向かい合う設計工程で決めたことが実現できているかを確かめる、という関係になっています。

テストケースの作り方には二つの立場があります。ホワイトボックステストはプログラムの内部構造を見て、命令や分岐がもれなく実行されるように経路を選ぶ方法で、主に単体テストで使います。ブラックボックステストは内部を見ずに仕様だけを頼りにする方法で、入力を意味のまとまりごとに分けて代表値を選ぶ同値分割や、条件の境目の値を選ぶ境界値分析が代表的です。

プログラムを修正すると、直していないところが壊れることがあります。これを見つけるため、修正後に既存の機能をもう一度確認するのが回帰テスト（リグレッションテスト）です。またテストの前に、成果物を人の目で確かめるレビューも欠かせません。作成者が説明して関係者が非公式に指摘し合うウォークスルー、進行役（モデレータ）を置き役割と手順を定めて行う公式なインスペクション、設計内容を関係者で検討するデザインレビュー、ソースコードを対象とするコードレビューなどがあります。

用語

単体テスト

モジュールやプログラム1本ごとに、内部の処理が正しく動くかを確かめるテスト。ふつう作った本人（開発者）が行い、テストの最初の段階にあたる。

結合テスト

単体テストを終えたモジュールを組み合わせ、モジュールどうしのデータの受渡し（インタフェース）が正しいかを確かめるテスト。

システムテスト（総合テスト）

開発側が行う最終段階のテスト。本番に近い環境でシステム全体を対象に、機能だけでなく性能や大量アクセスへの耐性なども確かめる。

運用テスト（受入テスト）

利用者（発注者）が主体となり、実際の業務手順に沿って使ってみて、要求を満たしているかを確かめる最終テスト。合格すると受入れ（検収）となる。

V字モデル

開発工程とテスト工程の対応を表した図。要件定義↔運用テスト、外部設計↔システムテスト、内部設計↔結合テスト、プログラミング↔単体テストが向かい合う。

ホワイトボックステスト

プログラムの内部構造に着目し、命令や分岐が実行されるように経路を網羅してテストする方法。中身が見える箱にたとえた呼び名で、主に単体テストで使う。

ブラックボックステスト

内部構造は見ずに、仕様書の入力と出力の関係だけに着目してテストする方法。中身が見えない箱にたとえた呼び名で、結合テスト以降でよく使う。

同値分割・境界値分析

ブラックボックステストでテストケースを選ぶ考え方。同じ結果になる入力のまとまりから代表値を選ぶのが同値分割、条件の境目とその前後を選ぶのが境界値分析。

回帰テスト（リグレッションテスト）

プログラムを修正したあとに、修正前は正しく動いていた部分に不具合が生じていないかを確かめるテスト。修正の副作用を見つけるために行う。

ウォークスルー

作成者が中心となって関係者に成果物を説明し、その場で誤りを指摘し合う非公式なレビュー。少人数で気軽に行え、早い段階で欠陥を見つけられる。

インスペクション

進行役（モデレータ）が主催し、参加者の役割と手順をあらかじめ定めて行う公式なレビュー。記録を残し、欠陥の検出と対処の確認まで行う。

デザインレビュー／コードレビュー

デザインレビューは設計書の内容を関係者で検討して問題を早期に見つける活動。コードレビューは書かれたソースコードを他の人が読んで誤りや改善点を指摘する活動。

例題

出典・根拠：IPA「ITパスポート試験」シラバス Ver.6.5 大分類4：開発技術　中分類8：システム開発技術

3. 開発モデル（ウォーターフォールとアジャイル）

代表的な開発の進め方を比べ、案件に合ったモデルを選ぶ目を養います。

同じシステムでも、どういう手順で作るかにはいくつかの型があります。これを開発モデルといいます。もっとも古典的なウォーターフォールモデルは、要件定義から順に工程を進め、原則として前の工程には戻りません。各工程の成果物を承認してから次へ進むため進捗が管理しやすい反面、後の工程で仕様変更が出ると手戻りが大きくなります。

早い段階で認識のずれをなくす工夫がプロトタイピングモデルです。試作品（プロトタイプ）を作って利用者に操作してもらい、その評価をもとに要求を固めていきます。スパイラルモデルは、システムを部分に分け、設計・開発・評価という一連の作業を繰り返しながら、らせん状に完成度を高めていく考え方で、リスクの大きい部分から先に確かめられます。

アジャイル開発は、1〜4週間程度の短い反復（イテレーション、スクラムではスプリント）を繰り返し、反復ごとに動くソフトウェアを提供する進め方です。詳しい文書をそろえることより、動くものを早く出して利用者の意見を取り入れ、変化に対応することを重視します。要求が変わりやすい案件や、早く小さく出して試したい案件に向きます。

どちらが優れているというものではありません。要求が固まっていて品質の証跡が厳しく求められる大規模案件ではウォーターフォールが選ばれ、要求が定まらず素早く形にしたい案件ではアジャイルが選ばれます。そのほか、少人数のチームと開発支援ツールを活用して短期間で作り上げるRAD（Rapid Application Development）という手法もあります。

用語

ウォーターフォールモデル

水が上から下へ落ちるように、工程を順番に1回ずつ進める開発モデル。前工程には戻らない前提で、各工程の成果物を承認して次へ進む。

プロトタイピングモデル

早い段階で試作品を作り、利用者に操作してもらった評価を要求に反映する開発モデル。認識のずれによる大きな手戻りを防げる。

スパイラルモデル

システムを部分に分け、設計・開発・評価の作業を繰り返しながら、らせんを描くように完成度を高めていく開発モデル。リスクの大きい部分から確かめられる。

アジャイル開発

短い反復を繰り返し、反復ごとに動くソフトウェアを提供する開発の考え方。アジャイルは「素早い」という意味で、変化への対応と利用者との協調を重んじる。

イテレーション

アジャイル開発で繰り返す一定期間の反復のこと。日本語では「反復」。1回の中で設計・実装・テストまで行い、動くソフトウェアを作り上げる。

RAD

Rapid Application Developmentの略で「高速アプリケーション開発」。少人数のチームと開発支援ツールを使い、短期間でシステムを作り上げる手法。

例題

出典・根拠：IPA「ITパスポート試験」シラバス Ver.6.5 大分類4：開発技術　中分類9：ソフトウェア開発管理技術

4. アジャイルの実践とDevOps

スクラムの役割とイベント、XPの実践、DevOpsやCI/CDなど現場で使われる言葉を押さえます。

アジャイル開発を実際に進めるための代表的な進め方がスクラムです。スクラムでは役割を三つに分けます。プロダクトオーナーは、実現したい要求を優先順位を付けて並べたプロダクトバックログに責任を持ち、成果物の価値を最大にします。スクラムマスターは、スクラムが正しく実践されるよう支援し、チームの妨げになる問題を取り除きます（指揮命令する管理者ではありません）。開発チームは、スプリントで動くソフトウェアを作り、作業の分担を自分たちで決めます。

スクラムは1〜4週間程度の固定期間であるスプリントを繰り返します。スプリントの始めに何を作るかを決めるスプリントプランニング、毎日15分程度で進捗と問題を共有するデイリースクラム、終わりに成果物を関係者に見せて評価を受けるスプリントレビュー、進め方そのものを振り返るスプリントレトロスペクティブというイベントがあります。期間は延ばさず、間に合わない機能は次のスプリントに回すのが原則です。なお、スクラムの成果物は三つあり、実現したい要求を優先順位付きで並べたプロダクトバックログ、そのスプリントで実現する項目と作業計画をまとめたスプリントバックログ、スプリントの終わりに出来上がる動く成果物であるインクリメントをいいます。

XP（エクストリームプログラミング）はアジャイル開発の代表的な手法で、具体的な実践が定められています。2人1組で1台の端末を使い、一方が書き他方が確認するペアプログラミング、先にテストを書いてからそれを通す実装を行うテスト駆動開発、外から見た動作を変えずに内部構造を整理して読みやすくするリファクタリングなどです。

開発したものを素早く安全に届けるための考え方も広がっています。DevOpsは開発（Development）担当と運用（Operations）担当が協力し、自動化と継続的な改善によってリリースを速める文化・取組みです。CI/CDは、変更したソースコードを頻繁に統合してビルドとテストを自動実行する継続的インテグレーションと、その先のリリースまでを自動化する継続的デリバリを指します。このほか、既存のプログラムを解析して仕様や設計情報を導き出すリバースエンジニアリング、公開されている複数のサービスを組み合わせて新しいサービスを作るマッシュアップ、ソースコードをほとんど書かずにアプリを作るノーコード／ローコード開発も押さえておきましょう。

用語

スクラム

アジャイル開発の代表的な進め方。短い期間（スプリント）の反復と、決められた役割・イベントによってチームで開発を進める枠組み。ラグビーの組み合いに由来する。

プロダクトオーナー

スクラムの役割の一つ。プロダクトバックログの中身と優先順位に責任を持ち、「何を作るか」を決めて成果物の価値を最大にする。

スクラムマスター

スクラムの役割の一つ。スクラムが正しく実践されるようチームを支援し、開発の妨げとなる問題を取り除く。作業を指示する管理者ではない。

開発チーム

スクラムの役割の一つ。スプリントの中で実際に動くソフトウェアを作る少人数のチーム。誰が何をするかは自分たちで決める（自己組織化）。シラバスや近年のスクラムガイドでは「開発者」とも呼ぶ。

スプリント

スクラムで繰り返す1〜4週間程度の固定期間の反復。期間は延長せず、終わりには動くソフトウェアができている状態を目指す。

プロダクトバックログ

実現したい要求や機能を優先順位を付けて並べた一覧。プロダクトオーナーが管理し、開発が進む中で随時見直される。

スプリントバックログ

そのスプリントで実現するプロダクトバックログ項目と、それを実現するための作業計画をまとめた一覧。開発チームが自分たちで作り、スプリントの途中でも見直す。

インクリメント

スプリントの終わりに出来上がる、実際に動く状態の成果物。過去のスプリントの成果に今回の成果を積み上げたものを指し、いつでも使える品質であることが求められる。

デイリースクラム

開発チームが毎日決まった時刻に15分程度行う短い会議。進捗と当日の予定、妨げになっている問題を共有し、遅れを早く見つける。

スプリントレビュー

スプリントの終わりに、できあがった成果物を関係者に見せて評価や意見をもらうイベント。得られた意見は次のスプリントの計画に反映する。

ペアプログラミング

XPの実践の一つ。2人1組で1台の端末を使い、一方がコードを書き、他方がその場で確認・助言する。書きながらレビューするので誤りを早く見つけられる。

テスト駆動開発（TDD）

先にテストコードを書き、それが通るように最小限の実装をしてから改善する、という短い流れを繰り返す開発手法。テストが仕様書の役割も果たす。

リファクタリング

外から見た動作を変えないまま、プログラムの内部構造を整理して読みやすく直すこと。機能追加ではなく、後の修正をしやすくするために行う。

DevOps

開発担当と運用担当が壁を作らず協力し、自動化と継続的な改善によって安全かつ迅速にリリースを繰り返す考え方・取組み。DevelopmentとOperationsを組み合わせた語。

CI/CD

継続的インテグレーション／継続的デリバリ。変更したコードを頻繁に統合してビルドとテストを自動実行し、さらにリリースまでの手順も自動化する仕組み。

リバースエンジニアリング

既存のソフトウェアや製品を解析して、その仕様や設計情報を導き出すこと。設計書が残っていない古いシステムを作り直すときなどに使われる。

マッシュアップ

公開されている複数のサービスやデータを組み合わせて、新しい一つのサービスを作ること。地図サービスと店舗情報を組み合わせた案内サイトなどが例。

ノーコード／ローコード

ソースコードをまったく書かずに（ノーコード）、またはごく少ないコードで（ローコード）、画面上で部品を組み合わせてアプリを作れる開発手法・ツール。

例題

出典・根拠：IPA「ITパスポート試験」シラバス Ver.6.5 大分類4：開発技術　中分類9：ソフトウェア開発管理技術

演習：この章の問題を解く

ランダム出題の演習ツールです（JavaScript が有効な場合に動きます）。上の「確認問題」はそのままでもすべて読めます。