システム開発技術
システム開発は要件定義・設計・プログラミング・統合テスト・導入受入れ・保守という工程で進みます。要件定義では機能要件と非機能要件を区別し、プログラミングの工程では単体テストとホワイトボックステストを、統合・テストの工程では統合テストとブラックボックステストを行います。
システム開発が要件定義から保守までどのような工程で進むのかを説明できるようになります。また、機能要件と非機能要件の違いや、テスト工程の種類、開発規模の見積り方法を区別できるようになります。
システム開発技術はマネジメント系の中でも出題頻度が高い分野です。工程の順番や各工程の成果物、テストの種類(単体・統合・受入れ)を問う問題や、ファンクションポイント法など見積りの考え方を問う問題が繰り返し出題されるため、流れを一本の線として理解しておくことが得点への近道になります。
要件定義と設計の工程
システム開発は、家を建てる手順によく似ています。家を建てるとき、いきなり柱を組み始める人はいません。まず施主と工務店が「どんな家に住みたいか」を話し合い、部屋数や間取りの希望を固めます。システム開発でこれにあたるのが、システム要件定義とソフトウェア要件定義です。依頼主が「何をしたいか」を明確にし、システムやソフトウェアに求められる機能や性能を文書としてまとめていきます。
この工程で欠かせないのが、機能要件と非機能要件の区別です。機能要件は「見積金額を自動で計算する」のように、システムが実際に行う処理そのものを指します。一方の非機能要件は「1秒以内に応答する」「深夜も止まらずに動く」のように、処理そのものではなく、性能や信頼性など質に関わる条件を指します。この2つを取り違えないことが試験でよく問われます。
要件が固まったら、次は家の図面にあたる設計の工程に進みます。設計には、画面や帳票などシステムの外から見える部分を決める機能設計と、内部のデータの持ち方や処理の流れを決める詳細設計があります。決めた内容は開発者だけで確認するのではなく、関係者が集まって内容を確認し合う共同レビューによってチェックします。ここで見落としを減らしておくほど、あとの工程が楽になります。
また、システムに求められる質のよさは、機能性・効率性・使用性・信頼性といった複数の側面に分けて考えられ、これらをまとめて品質特性と呼びます。使いやすさだけでなく、壊れにくさや反応の速さも、システムの質を測る物差しになっています。
家づくりでも、柱を組んだあとで間取りを変えようとすると、大きな手間とお金がかかります。システム開発も同じで、要件定義や設計の段階で見落としがあると、後の工程で気づいたときには関係する部分すべてを作り直す手戻りが発生します。共同レビューで早い段階から関係者の目を通しておくことが、結果として開発全体のコストと期間を抑えることにつながります。要件定義と設計は、地味に見えても開発全体の土台を決める重要な工程だと捉えておきましょう。
開発からテスト・保守まで
設計が終わると、家づくりでいえば大工が実際に建築を始める段階、つまりプログラミングの工程に入ります。設計書どおりにコードを書く作業をコーディングと呼びます。書いたプログラムに誤り(バグ)がないかを、作成した本人以外の目でチェックするコードレビューを行いながら、誤りを見つけたらデバッグで修正していきます。プログラムの最小単位ごとに仕様どおり動くかを確認する単体テストもこの工程に含まれ、内部構造を見ながらテストケースを作るホワイトボックステストが中心になります。
単体テストを終えたプログラムは、次に統合・テストの工程で組み合わされます。モジュールどうしをつなぎ合わせる統合テストでは、内部構造を見ずに入力と出力の関係だけでテストケースを作るブラックボックステストが中心です。大量のアクセスに耐えられるかを確認する負荷テスト、処理速度を確認する性能テスト、修正した箇所が別の場所に悪影響を与えていないかを確認する回帰テスト(リグレッションテスト)なども、この工程で行われます。モジュールをすべてつなぎ終えたら、システムテストでシステム全体が要求どおりに動くかを確認します。ここで見るのは個々の機能ではなく、業務の流れをひととおり通したときに最後まで動ききるかどうかです。
最後の関門が導入・受入れです。家づくりでいえば、蛇口をひねって実際に水が出るかを施主が確認する場面にあたります。取得者(依頼した側)が、供給者(開発した側)の支援を受けながら実際の環境でシステムを使い、意図した用途を達成できているかを確認する受入れテスト(妥当性確認テスト)を行い、問題がなければ納入です。あわせて利用者マニュアルによる教育訓練や、新システムへの移行も行われます。納入後は、安定稼働やIT環境の変化に対応するために修正や改善を続ける保守の工程に入ります。
このように、テストは「単体テスト→統合テスト→システムテスト→受入れテスト」という順番で、確認する範囲を少しずつ広げながら進んでいきます。単体テストが個々の部屋の設備を確認する作業だとすれば、統合テストは部屋どうしのつながりを、システムテストは家全体が設計どおりに仕上がっているかを、受入れテストは施主が実際に暮らせるかを確認する作業にあたります。範囲が広がるほど、内部の仕組みよりも実際の使い勝手が重視されるようになる点も、あわせて押さえておきましょう。
開発規模の見積り
システム開発を始める前には、どれくらいの費用と期間がかかるかを見積もる必要があります。家を建てる前に、床面積や仕様からおおよその工事費の見積書を出してもらうのと同じ考え方です。ソフトウェアの見積りでは、開発規模や開発環境などの情報をもとに、開発工数(作業量)や開発期間を計算していきます。
代表的な見積り手法の一つがファンクションポイント法(FP法)です。これは、画面の数や入力項目、外部とのデータのやり取りなど、システムが持つ機能の数と複雑さを点数化し、その合計点から開発規模を見積もる方法です。プログラムのコード量ではなく、利用者からみた機能の量をもとに数値化するため、開発言語や技術者の経験に左右されにくいという特徴があります。
これに対して類推見積法は、過去に行った似たようなシステム開発の実績を参考にして、今回の開発規模を推測する方法です。過去の経験というものさしを使うため、初期段階でおおまかな金額感をつかみたいときに向いています。相対見積は、複数の作業項目どうしを比べて「Aの作業はBの作業のおよそ2倍」というように、絶対的な数値ではなく相対的な大きさで見積もる考え方です。
どの手法も、開発の初期段階で使うほど不確実性が大きくなります。試験では、ファンクションポイント法が「機能の数をもとにした見積り」であるという特徴を問う問題がよく出題されます。他の見積り手法と区別できるようにしておきましょう。
見積りの精度は、開発が進むにつれて上がっていきます。要件定義の段階では大まかな金額感しかつかめませんが、設計が進んで作業内容が具体的になるほど、見積りも実際の工数に近づいていきます。見積りは一度出して終わりではなく、工程が進むたびに見直していくものだと理解しておくと、試験問題の文脈も読み取りやすくなります。契約や予算の確保は初期の見積りをもとに行われることが多いため、見積りの精度が低い段階での数値を過信しすぎないことも、プロジェクトを進めるうえで大切な心構えです。見積り手法を複数使い分け、数値を突き合わせながら精度を高めていく進め方も実務ではよく行われます。
この単元の確認問題
答えを見る前に、まず自分の言葉で答えてみてください。言葉にできないところが、そのまま本試験で止まるところです。
Q. 「1秒以内に応答する」「深夜も止まらずに動く」といった、処理そのものではなく性能や信頼性に関わる要件を何と呼びますか。
A. 非機能要件です。
システムが実際に行う処理を指す機能要件に対して、非機能要件は性能や信頼性など質に関わる条件を指すためです。
Q. 取得者が実際の運用環境でシステムを使用し、意図した用途を達成しているかを確認するテストを何と呼びますか。
A. 受入れテスト(妥当性確認テスト)です。
開発側が行う統合テストとは異なり、依頼した側が実際の使い方に沿って最終確認を行うテストだからです。
Q. 画面の数や入力項目など、システムが持つ機能の数と複雑さを点数化して開発規模を見積もる手法を何と呼びますか。
A. ファンクションポイント法(FP法)です。
コード量ではなく、利用者からみた機能の量をもとに数値化する点が、この見積り手法の特徴だからです。
システム開発技術は、読んで分かることと、本番で点になることが別です。点にするための材料はこちらにまとめてあります。
- この単元の問題 24問（どこをどう間違えたかまで解説）
- この単元のひっかけ（本試験がどう引っかけてくるか）
- この単元をそのままITパスポート専用AIチューターに質問できます
- 間違えた問題だけを自動で拾い直す復習リスト
「第4章 開発技術」の他の単元
この単元を、手を動かして確かめる
ITパスポートAIチューターでは、いま読んだ単元の四択問題をその場で解いて、 どこで間違えたかまで解説付きで確かめられます。 わからないところはITパスポート専用のAIチューターに訊けます。
この単元をアプリで開く 登録は無料。メールアドレスだけで始められます。