【応用情報技術者試験】システム開発技術を学ぼう！　　　　　　~第1章~システム開発プロセス/開発モデル

システム開発技術とは、企業や組織の「業務課題を解決し、効率化する仕組み（システム）」をIT技術を用いて、企画・設計・プログラミング・テスト・運用するまでの一連の技術とプロセスの総称で、具体的には、要件定義、設計、コーディング、テスト、運用・保守などの工程があり、ウォーターフォールやアジャイルといった様々な開発手法が存在します。 

画像参照：https://www.co-well.jp/blog/system_dev_flow

共通フレーム

システム開発を行う上で、ソフトウェアの開発者と発注者の間で開発の段取りに対する共通の概念が必要となります。共通フレームでは、共通の概念が整理されています。その中でも代表的なプロセスを下記に整理しています。

プロセス	概要
企画プロセス	経営目標達成のために必要なシステムを導入する際、その構想を立て、開発・導入するための全体計画（方針・スケジュール・コストなど）を策定する、システム開発の最上流工程です。
要件定義プロセス	システム開発の初期段階で「何を作るか（機能）」「どう作るか（性能・制約）」を顧客やユーザーの要望から具体化し、開発者と合意形成して文書化する工程です。
開発プロセス	要件を詳細化して設計を進め、ソフトウェアを作成しテストする工程です。
運用プロセス	システムを導入し、ユーザ教育などをオコニアながら継続的に運用する工程です。
保守プロセス	システムやソフトウェアが本番稼働した後、その品質を維持・向上させる工程です。
管理プロセス	開発、運用、保守などの各プロセスの管理・支援を行う工程です。

開発プロセスの活動内容を下記に整理します。

ウォータフォールモデル

ウォーターフォールモデルとは、ソフトウェア開発などで使われる「滝」のように上流から下流へと、要件定義→設計→開発→テスト→保守といった工程を順番に進めていく古典的な開発手法です。各工程が完了してから次へ進み、後戻りは原則しないのが特徴で、大規模開発や要件が明確な場合に用いられますが、仕様変更に弱いという側面もあります。 

画像参照：https://www.alobridge.com/blog/893/

主な工程

1. 要件定義: システムに必要な機能や性能を顧客と決定します。
2. 設計: 要件に基づき、システムの全体設計（外部設計）と詳細設計（内部設計）を行います。
3. 開発（実装）: 設計書に従ってプログラミング（コーディング）を行います。
4. テスト: 開発されたシステムが設計通りに動作するか、バグがないかを確認します。
5. 導入（リリース）: システムを本番環境に展開し、ユーザーに提供します。
6. 保守: 運用中の問題修正や改善を行います。 

特徴とメリット・デメリット

• メリット:
  • 工程が明確で分かりやすく、進捗管理やスケジュール・予算の見積もりがしやすい。
  • 各工程で品質チェックが行われるため、品質を担保しやすい。
  • 手順が標準的で、多くの開発ベンダーが対応可能。
• デメリット:
  • 原則として後戻りしないため、途中で仕様変更が発生すると手戻りが大きく、困難になる。
  • テストは開発の後工程で行われるため、動作確認までに時間がかかり、初期の仕様の誤りに気づきにくい。 

どんな時に使う？

• 要件が最初から明確で、途中で仕様が変わる可能性が低いプロジェクト。
• 大規模なシステム開発で、確実性や品質が重視される場合。 

スパイラルモデル

スパイラルモデルは、リスク分析を重視し、計画・分析・開発・評価のサイクル（スパイラル）を繰り返しながら、システムを段階的に作り上げていく反復型の開発モデルです。システムを小さな機能単位（サブシステム）に分割し、プロトタイプを作り、顧客からのフィードバックを受けて改善を重ねることで、要件が不明確な大規模・高リスクなプロジェクトで柔軟に対応し、品質を高めながら開発を進められるのが特徴です。 

画像参照：https://medium-company.com/%E3%82%B9%E3%83%91%E3%82%A4%E3%83%A9%E3%83%AB%E3%83%A2%E3%83%87%E3%83%AB/

主な特徴

• 反復的・段階的開発: 全体を一度に開発せず、小さな部分から開発と評価を繰り返して徐々に大きくします。
• リスク管理重視: 各サイクルでリスク分析を行い、早期に問題を発見し対処します。
• 柔軟な対応: 顧客の要望や仕様変更に、プロトタイプを通じて柔軟に対応し、品質向上とイメージ共有を図ります。
• トップダウンとボトムアップの融合: 全体を見ながら（トップダウン）、部分を詳細に作り込む（ボトムアップ）長所を活かします。 

メリット

• 品質向上: 顧客と開発者のイメージ共有がしやすく、手戻りが少なくなる。
• 柔軟性: 仕様変更や追加要件に強い。
• リスク低減: リスクの早期発見と対応が可能。
• 段階的導入: 段階的なリリースや稼働が可能で、エンドユーザーの負担を軽減できる場合も。 

デメリット・注意点

• 管理の複雑さ: 全体像が見えにくく、分割や連携ミスでコスト増・遅延の可能性。
• 初期段階での不透明性: 全体設計が初期段階では不明確な場合がある。
• 効率の問題: プロトタイプ作成に時間がかかり、開発効率が落ちる場合も。 

向いているプロジェクト

• 大規模で複雑なシステム。
• 要件が不明確で、開発途中で変更が発生しやすいプロジェクト。
• 技術的なリスクが高いプロジェクト（例：航空機開発など）。 

プロトタイプモデル

プロトタイプモデルとは、システム開発の初期段階で試作品（プロトタイプ）を素早く作り、ユーザーからのフィードバックを繰り返しながら、認識のズレを防ぎ、要件を明確化・具体化していく開発手法です。これにより、開発終盤での手戻りを減らし、顧客満足度の高い製品を効率的に開発できるのが特徴で、アジャイル開発などでも活用されます。 

画像参照：https://www.kagoya.jp/howto/it-glossary/develop/developmentmodel/

主な特徴

• 早期のフィードバック: 実際に動く試作品を早期に提示することで、顧客は具体的な操作感やイメージを掴み、言葉では伝えにくい要望を引き出せます。
• 認識のズレの防止: 開発者と顧客（利用者）の間で完成イメージの認識を共有し、仕様確定段階での食い違いを防ぎます。
• 手戻りの削減: 開発の早い段階で問題点や改善点を発見し、後工程での大規模な手戻りやコスト増を回避します。
• 反復的な改善: プロトタイプ作成と評価・改善を繰り返すことで、徐々に製品の品質を高めていきます。 

メリット

• 顧客が求める機能や使いやすさを的確に把握できる。
• 開発の早い段階でリスクを発見・低減できる。
• 開発期間の短縮とコスト削減に繋がる場合がある。
• 顧客との信頼関係（ロイヤリティ）を構築しやすい。 

デメリット・注意点

• プロトタイプの作成・修正に負荷がかかる場合がある。
• 方向性が定まらないまま、プロトタイプ作成に終始してしまうリスクも。
• 専門的な知識や経験がないと、有効な検証が難しいこともある。 

種類

• ローファイプロトタイピング: 紙やワイヤーフレームなど、簡易的なプロトタイプで素早く検証する。
• ハイファイプロトタイピング: 完成品に近いデザインや機能を持つプロトタイプで、より詳細な検証を行う。 

プロトタイプモデルは、要件が不明確なプロジェクトや、ユーザー視点が重要な製品開発において非常に有効なアプローチです。 

アジャイル開発

アジャイル開発とは、システム開発手法の一つで、「素早く」「柔軟に」をモットーに、短い開発サイクル（イテレーション）を繰り返しながら、機能単位で設計・実装・テストを行い、動作するソフトウェアを継続的に提供する手法です。顧客の要求変化に素早く対応し、実際に動くものを見せながらフィードバックを得ることで、顧客価値を最大化します。スクラムやXPなど様々な種類があり、ビジネスの変化が激しい現代において、ソフトウェア開発だけでなく様々な分野で活用が進んでいます。 

特徴

• 短い反復サイクル: 計画・設計・実装・テストの工程を短い期間で繰り返します。
• 機能単位での開発: システム全体を機能の集合体とみなし、優先度の高いものから開発します。
• 柔軟な対応: 仕様変更や追加要求に途中からでも対応しやすいです。
• 密なコミュニケーション: 顧客を含む関係者全員で密にコミュニケーションを取り、現物を確認しながら進めます。 

メリット

• 迅速な価値提供: 短期間で動くものを提供し、早期に価値を提供できます。
• 変化への適応: 市場や顧客のニーズ変化に柔軟に対応できます。
• 認識のズレの早期発見: 実際に動くものを確認するため、初期段階での認識齟齬を発見しやすいです。 

デメリット・課題

• 全体像が見えにくい: 短期サイクルが中心のため、プロジェクト全体のスケジュールやコスト管理が難しくなる場合があります。
• 顧客の継続的な参加: 動作確認やフィードバックのために顧客の継続的な参加が求められます。
• 大規模開発での難しさ: 全体管理やチーム間の連携に工夫が必要です。 

アジャイル開発に関する用語

アジャイル開発に関する用語を下記に整理します。

開発に関する用語

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

リバースエンジニアリングとは、既存のプログラムを解析し、その内部構造、動作原理、設計、ソースコードなどを明らかにすることで、逆アセンブルや逆コンパイルなどの手法が使われ、保守、互換性確保、セキュリティ分析、競合分析などに活用されますが、知的財産権侵害にならないよう注意が必要です。 

主な目的と活用例

• ドキュメントの作成・更新: 仕様書がない古いシステムを解析し、現状の動作を理解してドキュメント化する。
• 互換性の確保: 異なるソフトウェア間や、古いシステムと新しいシステムを連携させるために、仕様を解析して互換性を持たせる。
• セキュリティ対策: マルウェア解析で挙動を特定したり、自社製品の脆弱性を発見・修正したりする。
• 機能追加・改良: 既存のコードを解析し、新しい機能を追加したり、リファクタリングして品質を向上させたりする。
• 競合製品の分析: 競合製品の技術を分析し、自社製品開発の参考にしたり、改良点を見つけたりする。 

主な手法

• 逆アセンブル: 機械語（バイナリコード）をアセンブリ言語に変換して解析する。
• 逆コンパイル: 機械語を高級言語（C言語など）に近い形に変換して解析する。
• 動的解析: 実際にプログラムを実行させながら、その振る舞いやメモリの状態などを監視・分析する。
• 静的解析: プログラムを実行せずにコード（バイナリ）自体を解析する。 

注意点（違法性と倫理）

• 知的財産権の侵害: 改良版を販売する際、特許や著作権を侵害しないか確認が必要。
• ライセンス契約: ソフトウェアの利用規約（EULAなど）でリバースエンジニアリングが禁止されている場合がある。
• セキュリティリスク: 解析した情報を悪用されるリスクもあるため、自社製品の保護も重要。 

まとめ

リバースエンジニアリングは、ソフトウェア開発・保守・セキュリティ分野で強力なツールですが、その手法は専門的であり、法的な側面や倫理的な側面を十分に考慮しながら行う必要があります。 

リエンジニアリング

既存のソフトウェアシステムの構造や実装を抜本的に見直し、再構築するプロセスです。これは、システムの効率、保守性、柔軟性、またはパフォーマンスを大幅に向上させることを目的としています。 

目的とメリット

主な目的

• 保守性の向上: 長年使用されてきた古い（レガシー）システムは、コードが複雑化したり、文書が不足したりして保守が困難になることがあります。リエンジニアリングにより、コードの品質と構造を改善し、保守を容易にします。
• パフォーマンスの最適化: 新しい技術やアルゴリズムを導入することで、システムの処理速度や効率を向上させます。
• 互換性の確保: 古いアプリケーションを新しいオペレーティングシステムや環境で動作するように修正し、互換性を確保します。
• 技術的負債の解消: システムの進化の過程で蓄積された技術的負債を削減し、将来の機能拡張に備えます。
• 属人化の解消: システムの仕様や設計の意図を再構築・文書化することで、特定の開発者に依存する状況を解消します。 

プロセスと手法

リエンジニアリングの一般的なプロセスには、いくつかの主要なフェーズがあります。 

1. 分析（リバースエンジニアリング）: 既存のソフトウェアの内部構造、動作、ソースコードなどを分析し、設計情報や仕様を明らかにします。
2. 設計: 特定された改善領域に基づき、新しい構造やアーキテクチャの設計案を作成します。
3. 再構築（フォワードエンジニアリング）: 新しい設計に基づいてコードを書き直し、システムを再構築します。
4. テストと導入: 再構築されたシステムが正しく機能することを検証し、新しい環境に展開します。
5. 監視と評価: 導入後のシステムを監視し、期待される改善が達成されているかを評価します。 

プロセス中心設計

プロセス中心設計（POA: Process Oriented Approach）とは、システム開発手法の一つで、「業務の流れ（プロセス）」を最重要視し、その手順や機能を中心にシステムを設計する考え方です。具体的には、DFD（データフローダイアグラム）などを使って「何を（データ）」よりも「どのように処理するか」を先に考え、業務の入・処理・出の流れをコンピュータシステムに置き換えていく手法で、初期のシステム開発で一般的でしたが、データ管理の複雑化でデータ中心設計（DOA）などに進化しました。 

プロセス中心設計の特徴

• 着眼点: 業務の「機能」や「処理の流れ（プロセス）」に注目します。
• 具体例: 「Aという業務は、まずBをして、次にCをして、最後にDをする」という手順をシステム化します。
• 利点: 業務の現実の手順に基づいているため分かりやすく、設計を迅速に進めやすいです。
• 欠点: 特定の業務プロセスに特化するため、部署をまたぐデータ連携や再利用が難しく、データが重複・散在しがちで、業務変更に弱いという課題があります。 

他の手法との比較

• データ中心設計（DOA）: データを中心に設計し、データ構造の変更に強いのが特徴です。プロセス中心設計の課題を改善するために登場しました。
• オブジェクト指向設計（OOA）: データと処理を一体化した「オブジェクト」に着目し、部品化と変化への対応力を高めた設計手法です。 

現在の使われ方

• システム開発はプロセス中心設計から始まり、データ中心設計、そしてオブジェクト指向設計へと進化しました。
• 現在でも、特定の業務プロセスの可視化や、要件定義の前段階での業務整理などに活用されることがあります。 

データ中心設計

データ中心設計（Data Oriented Approach: DOA）とは、業務プロセスよりも先に「データ」そのものの構造や関係性を中心に据えてシステムを設計する手法で、データの一貫性、再利用性、堅牢性を高め、変化に強いシステム構築を目指します。業務で扱う「何の情報が欲しいか、それがどう関係するか」を定義するデータモデリングを最初に行い、それを基にデータベースを設計し、最後に機能（プログラム）を開発する流れが特徴です。 

特徴

• データ中心: 業務プロセスは変化しやすいがデータは安定しているという考えに基づき、データを共有資源と捉えます。
• データモデリング: E-R図などを用いて、業務で扱うデータの種類、属性、関連性を最初に詳細に定義します。
• 機能はデータに従属: データモデルに基づいてデータベースを設計し、その上で各機能（プログラム）がデータを効率的に利用するように設計します。
• 一元管理: データの重複を防ぎ、一元的に管理することで、システム全体のデータ整合性を保ちます。 

メリット

• データの一貫性・整合性の向上: 複数のシステム間でデータが統一され、信頼性が高まります。
• 再利用性の向上: 定義されたデータモデルを複数のアプリケーションで再利用でき、開発効率が上がります。
• 変更への柔軟性: 業務プロセスの変更があってもデータモデルは安定しているため、影響範囲が限定され対応が容易です。
• 保守性の向上: 中心となるデータモデルが明確なため、メンテナンスが効率的になります。 

どんな場合に有効か

• 複数のシステム間でデータを共有・連携する場合（部門横断システムなど）。
• 長期的にデータ資産を活用したい大規模システム。
• ビッグデータ分析やAI活用など、データ活用が鍵となる現代のシステム開発。 

従来のプロセス中心設計との違い

• プロセス中心設計 (POA): 「何を（What）」「どうする（How）」という業務の流れや手順を先に設計します。
• データ中心設計 (DOA): 「何の情報（What Data）」が必要かを先に考え、データ構造を中心に設計します。