🚀 現場で使えるシステム開発の共通言語。SLCからスクラム、CMMIまでプロが押さえるべき全知識
ITプロフェッショナルを目指すなら必須の知識、ソフトウェアライフサイクル(SLC)から最新のアジャイル、CMMIまでを徹底的に深掘りします。
🎓 午後試験攻略へのプロローグ
応用情報技術者試験において、「システム開発」は戦略的な得点源です。しかし、近年の午後試験では単なる用語の暗記だけでは太刀打ちできません。 「なぜこのプロジェクトでアジャイルを採用したのか?」「リファクタリングを行う真の目的は何か?」といった、実務に即した判断力が問われます。
🔑 本記事でマスターする重要キーワード:
- SLCP(共通フレーム)
- テスト駆動開発(TDD)
- 継続的インテグレーション
- コデザイン(協調設計)
- CMMIの成熟度レベル
- リバースエンジニアリング
【午後試験の出題傾向】
近年は「DX推進に伴うアジャイル開発への移行」や「レガシーシステムのリエンジニアリング」を題材にした事例問題が頻出しています。本稿では、テキストの知識を「実戦で使える武器」へと昇華させるための解説を展開します。
1. ソフトウェアライフサイクル (SLC) と開発モデル
システムには「誕生」から「終焉」までのサイクルがあります。これをSLC(計画・開発・運用・保守)と呼びます。
📌 代表的な開発モデル一覧
| モデル名 | 特徴と利点 | 欠点・リスク |
|---|---|---|
| ウォータフォール | 滝のように工程(要件→設計→構築→テスト)を順に進める。一貫性が高い。 | 手戻りが許されない。下流での仕様変更に極めて弱い。 |
| プロトタイプ | 早期に試作品(プロトタイプ)を作り、ユーザ評価を受ける。 | 調整に手間取るとコストと時間が肥大化する。 |
| スパイラル | システムを分割し、独立部分ごとに設計・開発・評価を繰り返す。 | 管理が複雑。開発を繰り返しながらコスト評価まで行うのが特徴。 |
| インクリメンタル | 機能を分割し、順次リリースする。コア部分から段階的に提供。 | 全体の整合性を保つのが難しい。 |
| 進化的モデル | 要求変更を前提とし、サイクルごとに要求を洗練させる。 | 終わりが見えにくくなるリスクがある。 |
銀行の基幹システムのように「絶対にミスが許されず、仕様が明確」な場合はウォータフォール。逆に、SNSアプリのように「市場の反応を見ながら機能追加したい」場合はインクリメンタル/アジャイルが採用されます。
2. アジャイル型開発とモダンな手法
短い反復(イテレーション)を繰り返し、変化に迅速に対応するスタイルです。
🏃♂️ スクラム (Scrum)
チーム運営のフレームワーク。反復単位をスプリント(1〜4週間)と呼びます。
- スプリントプランニング:今回取り組む「スプリントバックログ」を決定。
- デイリースクラム:毎日15分の朝会で状況共有。
- スプリントレビュー:成果物のデモ。
- スプリントレトロスペクティブ:次への「ふりかえり」。
🛠 XP (エクストリームプログラミング)
「プラクティス(実践)」を重視する開発者向け手法。
- ペアプログラミング:ドライバとナビゲータの2人1組で開発。
- テスト駆動開発 (TDD):実装より先にテストコードを書く。
- リファクタリング:外からの動作を変えず、内部コードを綺麗にする。
- YAGNI:今必要なことだけする(You Aren't Going to Need It)。
3. 組込みシステムと高度な再利用技術
📱 組込み開発のキーワード
- プラットフォーム開発:共通土台を先に作り、機種ごとの差分を開発。
- コンカレントエンジニアリング:ハードとソフトを同時並行で開発。これを実現するのがコデザイン(協調設計)です。
♻️ リエンジニアリングとローコード
- リバースエンジニアリング:既存ソフトを解析して仕様を導き出す。
- ドメインエンジニアリング:特定業務分野(ドメイン)の資産を体系化し再利用する。
- ローコード開発:視覚的なGUI操作で部品を組み合わせ、最小限のコードで開発。
4. 共通フレームとV字モデルの対応
応用情報試験で最も重要な、設計とテストの対応関係です。
| 開発アクティビティ | 対応するテスト内容 |
|---|---|
| システム要件定義 | システム適格性確認テスト(全体の機能・性能確認) |
| システム方式設計 | システム結合テスト(ハード/ソフト間の連携) |
| ソフトウェア要件定義 | ソフトウェア適格性確認テスト |
| ソフトウェア方式設計 | ソフトウェア結合テスト(コンポーネント間連携) |
| ソフトウェア詳細設計 | ソフトウェアユニットテスト(単体テスト) |
5. 組織の能力評価:CMMI(能力成熟度モデル統合)
組織がどれくらい「まともな」開発プロセスを持っているかを5段階で評価します。
- レベル1:初期 - 属人的。英雄(スーパーマン)に頼っている。
- レベル2:管理された - プロジェクト管理ができ、似た案件を再現できる。
- レベル3:定義された - 組織として標準プロセスが確立されている。
- レベル4:定量的に管理された - 数値で品質や進捗を予測・制御できる。
- レベル5:最適化している - 継続的にプロセスを改善し続けている。
✅ まとめ:重要ポイント総チェック
- 💎 SLCはPlan-Do-Seeのサイクル。
- 💎 ウォータフォールは一貫性重視、アジャイルは変化対応重視。
- 💎 XPは技術(ペアプロ、TDD)、スクラムはチーム管理(スプリント)。
- 💎 リバースエンジニアリングは「プログラム → 設計書」への解析。
- 💎 CMMIはレベル3(標準化)とレベル4(数値管理)の差が試験に出やすい。
この内容をマスターすれば、応用情報のシステム開発分野は完璧です!✨
📝 編集後記:知識を「実戦の武器」に変えるために
ここまで、ソフトウェア開発のプロセスと手法を網羅的に解説してきました。応用情報技術者試験(AP)の合格、そしてその先のエンジニア実務において、これらの知識を定着させるための「背景」と「傾向」を整理しておきます。
かつて主流だったウォータフォールから、なぜアジャイルへシフトしているのか? その背景には「不確実性の増大」があります。DX(デジタルトランスフォーメーション)が叫ばれる今、ITは「コスト」ではなく「ビジネスの核」となり、より早い試行錯誤(プロトタイピング)が求められています。
午後試験では、単に手法の名前を答えさせるのではなく、「既存の負の遺産(技術的負債)」をリエンジニアリングによってどう解消するか、あるいはCI/CD(継続的インテグレーション/デリバリー)を導入して開発速度をどう上げるか、といった戦略的な問いが増えています。
💡 学習のアドバイス:
「共通フレーム」や「CMMI」は一見無機質な用語の羅列に見えますが、それは先人たちが積み上げた「失敗しないための知恵」の結晶です。プロジェクトマネジメント(PM)分野との親和性も高いため、併せて学習することで理解が飛躍的に深まります。
—— システム開発の「地図」を手に入れたあなたなら、どんな複雑なプロジェクトも攻略できるはずです。
✍️ 【午後試験対策】そのまま使える!記述解答定型文リスト
午後試験の記述問題で、正解(加点対象)になりやすい「模範的な言い回し」を整理しました。これらをそのまま覚えるだけで、得点力が大幅にアップします。
リファクタリングの目的は?💡 解答例: 外部から見た振る舞いを変更せずに、保守性の高い内部構造に書き換えるため。
プロトタイプモデルの利点は?💡 解答例: 開発の早期段階で、ユーザとの認識の乖離や要求仕様の曖昧さを排除できる。
回帰テスト(レグレッションテスト)の目的は?💡 解答例: システム修正により、それまで正常に動作していた箇所に予期せぬ悪影響が出ていないか確認するため。
CMMIレベル4(定量的に管理された)の状態とは?💡 解答例: プロセスの実績を統計的に把握し、品質目標に対する達成状況を定量的に予測・制御できる状態。
YAGNI原則を導入する理由は?💡 解答例: 将来を見越した過剰な作り込みを避け、現在必要な機能のみに集中することで、後の仕様変更に対応しやすくするため。
コデザイン(協調設計)を採用する効果は?💡 解答例: ハードウェアとソフトウェアを並行して開発・検証することで、開発期間の短縮と品質向上を図る。
⚠️ ワンポイントアドバイス:
「保守性」「認識の乖離」「定量的」「並行開発」といった専門キーワードを盛り込むことが、採点官への強いアピールになります。
🗂️ 仕上げの暗記!重要用語フラッシュカード(20選)
カードを触ると裏面が表示されます。試験直前の最終チェックに最適!
📚 徹底網羅:システム開発用語 完全解説事典
テキストに登場する全ての用語を一つ残らず網羅しました。試験直前の最終確認や、記述問題の語彙力強化に活用してください。
■ ソフトウェアライフサイクルと全体指針
- ・ソフトウェアライフサイクル (SLC)
- 計画(Plan)・開発(Do)・運用保守(See)の3フェーズを軸とした、システムの誕生から廃棄までの全過程。
- ・DevOps (デブオプス)
- 開発(Development)と運用(Operations)が連携し、迅速かつ柔軟にシステム改善を行う取組や文化。
- ・共通フレーム (SLCP)
- ソフトウェアのライフサイクル全般にわたる作業内容を包括的に規定したガイドライン。取引の明確化に寄与する。
■ 多様なソフトウェア開発モデル
- ・ウォータフォールモデル
- 上流から下流へ滝のように進む。工程ごとの成果物を重視し、一貫性を保証するが、仕様変更には極めて弱い。 [Image of waterfall model development process]
- ・プロトタイプモデル
- 早期に試作品を作り、ユーザ評価を繰り返す。要求の曖昧さを排除できるが、調整コストが増大するリスクがある。
- ┗ モックアップ
- プロトタイプの一種で、動作ではなく「見た目・デザイン」の確認に特化した試作品。
- ・スパイラルモデル
- 独立性の高い部分ごとに開発・評価を繰り返す。最大の特徴は、反復ごとに「コストやリスクの評価」を行う点。
- ・インクリメンタルモデル (段階的モデル)
- 全要件を一度に作らず、機能を分割して段階的にリリースする。早期に動作確認ができるメリットがある。
- ・進化的モデル
- 要求変更が高いことを前提とし、サイクルごとに要求を洗練させる。変更を「新しいサイクル」で吸収するのが特徴。
■ アジャイル開発の核心
- ・スクラム / スプリント
- アジャイルの枠組み。反復単位をスプリント(1〜4週間)と呼び、期間は固定(タイムボックス)される。 [Image of scrum process diagram]
- ┗ スプリントの4イベント
- ①プランニング(計画) ②デイリースクラム(15分朝会) ③レビュー(成果デモ) ④レトロスペクティブ(ふりかえり)。
- ・プロダクトバックログ / リファインメント
- 実装機能の優先順位リスト。項目の見直しや詳細化を行う作業をリファインメントと呼ぶ。
- ・ユーザストーリー / INVEST
- 簡潔な要求記述。品質基準INVEST(独立・交渉・価値・見積・小規模・テスト可能)で評価する。
- ・XP (eXtreme Programming) の主要プラクティス
- ペアプログラミング:ドライバとナビゲータの2人1組で開発。
テスト駆動開発 (TDD):テストを先に書き、最小限の実装後にリファクタリングする。
コードの共同所有:チーム全員がどのコードでも改善・再利用できる権利を持つ。
YAGNI:「You Aren't Going to Need It」。将来の予測で機能を作らない。 - ・リーンソフトウェア開発 (7原則)
- ①ムダをなくす ②品質を作り込む ③知識を作り出す ④決定を遅らせる ⑤早く提供する ⑥人を尊重する ⑦全体を最適化する。
■ 組込み・再利用・次世代開発
- ・プラットフォーム開発 / MDA
- 共通基盤を先に設計する。MDAはプラットフォーム依存・非依存を分けてモデル化する手法。
- ・コンカレントエンジニアリング / コデザイン
- ハードとソフトの並行開発。協調設計(コデザイン)や同時検証(コベリフィケーション)を駆使する。
- ・リエンジニアリング (リバース & フォワード)
- 既存ソフトを解析(リバース)し、仕様を修正して新ソフトを構築(フォワード)する技術。
- ・ドメインエンジニアリング
- 特定分野(ドメイン)の知識や部品を体系化し、再利用を促進して開発効率を上げる活動。
- ・ローコード開発
- GUIベースの視覚的操作で部品を組み合わせ、ソースコード記述を最小限に抑える迅速な開発手法。
■ プロセス評価と共通フレームのアクティビティ
- ・V字モデル (設計 vs テスト)
- システム要件定義⇔システム適格性確認、詳細設計⇔ユニットテストといった対応関係を示すモデル。
- ・ソフトウェア構築
- 共通フレームにおける、コーディングと単体テスト(ユニットテスト)を行うアクティビティ。
- ・CMMI / SPA
- プロセスの成熟度を5段階(初期、管理された、定義された、定量的に管理された、最適化している)で評価。評価活動はSPAと呼ばれる。
この記事へのコメント