ｿﾌﾄｳｪｱ開発手法(ｳｫｰﾀｰﾌｫｰﾙ型,ｱｼﾞｬｲﾙ開発,XP,ｽｸﾗﾑ開発,ﾌﾟﾛﾄﾀｲﾋﾟﾝｸﾞ,ｽﾊﾟｲﾗﾙﾓﾃﾞﾙ,RAD,ﾘﾊﾞｰｽｴﾝｼﾞﾆｱﾘﾝｸﾞ,DevOps)
◆ソフトウェア開発手法
代表的なものは以下。
「ウォーターフォール型」「アジャイル開発」「XP」「スクラム開発」「プロトタイピング」「スパイラスモデル」「RAD」「リバースエンジニアリング」「DevOps」
◆ウォーターフォール型
開発工程を上位工程から順番に進めていく開発手法のこと。
開発工程ごとの実施すべき作業が全て完了してから次の工程に進む。
おおまかにな流れは以下。
「要件定義」→「設計」→「開発」→「テスト」
・利点
全体スケジュールがたてやすい
各工程間にはドキュメント（定義書・設計書 等）を引き継いでいくため、進捗把握がしやすい。
・欠点
手戻りが発生しないように、各工程が終了する際に綿密なチェックが必要
開発の初期段階で、利用者の要件を確定してしまうため、開発途中での利用者の要件を取り入れにくい
利用者が完成品を見るのは最終段階になってからなので、利用者の要件と異なっていれば、開発の初期段階レベルへの手戻りが必要
◆アジャイル開発
短期間で「動作するアプリケーションを開発する」という作業の反復により、利用者の要件を随時取り入れながら、段階的にシステム全体を完成させていく開発手法。
アジャイル開発の厳密な定義や要件は決まっていないが「XP」「スクラム」「クリスタル」「FDD：フィーチャー駆動型開発」「ASD：適応的ソフトウェア開発」「LSD：リーンソフトウェア開発」等の手法が良く知られている。
少人数のチームがコミュニケーションをとり協力しながら作業を進めることに重点を置いている。
システムを迅速に開発するための軽量なソフトウェア開発手法で、小規模なシステム開発に向いている。
「agile」は「機敏な」「しなやかな」「素早い」という意味。
適用範囲：
一か所に集まった10人程度までのに少人数の開発チームが、ネットワーク関連 等の変化の早い分野や、最初から明快な要件定義が難しい案件のソフトウェアを開発する際に最も適しているとされる。
開発途上での要件変更がほぼ無いことが分かっている場合、大人数で大規模なプロジェクト、不具合が致命的（人命・財産に大きく関わるような）社会的に重要なシステム開発には適さないとされる。
・利点
ドキュメント（仕様書 等の書類）の作成よりも、ソフトウェア作成を優先する。
変化する利用者の要件を素早く取り入れられる。
仕様変更に柔軟に対応でき、手戻り作業による影響も小さい。
・欠点
スケジュールが立てにくく、進捗管理も難しい。
開発の方向性がブレやすい。
◆XP（アジャイル開発手法のひとつ）
eXtreme Programming。
アジャイル開発の先駆け。
開発を始めた後でも変更・修正・使用の明確化が行われることを前提として、小規模な設計・実装・テストを何度も繰り返して、段階的に完成度を高めていく反復型開発。
最も重視する原理を「5つの価値」として定めている。また開発者が行うべき具体的な実践や守るべき原則を「４つの領域」にわけた「１２のプラクティス」としてまとめている。
5つの価値：「コミュニケーション」「シンプルさ」「フィードバック」「勇気」「尊重」
4つの領域：「細かいフィードバック」「継続的なプロセス」「共通理解」「プログラマの厚生」
12のプラクティス：「ペアプログラミング」「計画ゲーム」「TDD：テスト駆動開発」「オンサイト顧客」「継続的インテグレーション」「リファクタリング」「小規模リリース」「コーディング規約」「コードの共同所有」「シンプル設計」「比喩」「持続可能なペース」
代表的なプラクティス（実践）の例な以下。
・イテレーション（短いサイクル：1～2週間）で、動作するプログラムを作ることを繰り返す。
・ペアプログラミングする
・リファクタリングする
・テストファーストで行う（TDD：Test-Driven Developmentを行う）
◆ペアプログラミング
2人1組になってプログラミングすること。
片方がコード打ち込み・もう片方がコードチェック。また、相互に役割を交代する。
コミュニケーションを円滑にし、良質なプログラムを作成する。
◆リファクタリング
プログラムの動作や振舞いを変更せず、プログラムの内部構造を見直し、開発者にとって理解のしやすい構造や設計に、コードを書き替えたり書き直したりすること。
急な仕様変更や機能追加で、その場しのぎの継ぎ接ぎが行われた箇所や、柔軟性・拡張性に乏しい設計や構造、無駄な重複、意図の読み取りにくい難解・煩雑な箇所が増えてくる。
そのような場合、一度立ち止まって既存のコードを見直し、開発者にとって理解のしやすい構造や設計に改める作業のこと。
リファクタリングによって開発の進捗そのものは変わらないため、工数自体は増える。ただし、内部がひどく混乱したプログラムの場合、そのままコードの追加・修正を続けるより、見通しを良くして作業を再開する方が開発効率・開発速度が向上しする。
それにより、プログラムの品質・保守性の向上、バグの抑制に繋がる。
◆TDD（テストファースト）
Test-Driven Development。テスト駆動開発。
テストケースを先に設定してからプログラムをコーディングする。
「テストファースト」と呼ばれる原則に従って開発を進めていく手法で、まずはプログラムの機能・仕様に基づいて、そのプログラムが通るべきテスト条件やテストコードを記述していく。
テストができたら、とにかく最低限のコードで構成されるプログラムを作る。動作すればよい（必要な処理を書かない定数のみの記述、コードの重複 等 なんでもよい）
テストに通ることを確認しながら、最終的に明快で洗練されたコードに書き換えていく（リファクタリング）
何度も繰り返し大量のテストを実施する必要があるため、テストツール・フレームワーク等 何らかのテスト自動化環境を用意してから開発に取り掛かるのが一般的。
セキュリティソフト・GUI操作のソフト、並列処理を行うプログラム、開発ツールが自動生成するコード 等には適用しにくい。
◆スクラム（アジャイル開発手法のひとつ）
チームが一丸となって仕事に取り組むための方法論を中心にまとめられた方式。
ラグビーの「スクラム」が語源。
以下のような特徴がある。
「スプリント」とよばれる固定した短いサイクル（１～４週間）で、動作するプログラムをつくることを繰り返す。
取り組むべき作業・事柄を「バックログ」とよばれるリストに、優先順位準に掲載し、これをチームメンバーがこなしていく。
毎日ミーティングを重ねることで、早期問題解決に努める。
チームにはリーダーや管理者は存在せず、チーム内外の調整や外部の窓口となるスクラムマスターと呼ばれる役職が置かれる。
全てのメンバーが主体性を持って行動し、チームに貢献することが期待される。
バックログ：2種類ある。「プロダクトバックログ」「スプリントバックログ」
プロダクトバックログ：開発している製品に必要となる項目を列挙したリスト。
スプリントバックログ：スプリントで実施すべき項目を列挙したリスト。
◆プロトタイピング
システム開発の早い段階から、実際に稼働する製品モデル・試作品（プロトタイプ）を作成し、利用者の確認を得ながら開発を進めていく手法。
利用者と開発者の間で、システム要求についての解釈の違いを早い段階で確認できる。
大規模で複雑な製品だと、プロトタイプ作成・修正が大きな負担となるため、小規模なシステム開発に向いている。
◆スパイラルモデル
システムを、更に独立性の高いサブシステムに分割し、サブシステムごとに要件定義・設計・開発・テストを繰り返しながら段階的にシステムを完成させていく開発手法。
サブシステムごとにウォーターフォール型で開発し、完成したサブシステムをプロトタイプとし利用者に見せることができる。
仕様の修正・再設計が行いやすく、顧客の満足度は高めやすいが、プロセスを何周で終わらせるのか、どのような基準で完成と見なすか、等について十分な議論・合意がなければ、工期・予算の目算が大きく狂う場合もある。
◆RAD
Rapid Application Development。
高速アプリケーション開発。
利用者の参画・少人数による開発・開発ツールの活用によって、短期間にシステムを完成させていく開発手法。
特に、専用の開発ツール（RADツール）を用い、あらかじめ用意された半製品や部品（モジュール）、雛形（テンプレート）を活用したり、プログラムコードの入力支援や自動生成 等の機能を活用して、ゼロからコードを記述していくよりも少ない手順で開発する手法を指すことが多い。
GUIを持つソフトウェア開発を特に高速化することができ、開発期間の短縮・開発コストの削減が可能となる。
ただし、出来合いの部品 等を繋ぎ合わせる手法は、実行速度低下・ファイルサイズの増大を招きやすいと言われる。
◆リバースエンジニアリング
出荷された製品を入手して分解・解析 等を行い、その動作原理・製造方法・設計・構造・仕様の詳細・構成要素 等を明らかにすること。
他社製品のリバースエンジニアリングによって得られた情報は、類似製品や互換製品の開発、同等の機能の実現、自社特許の侵害有無の確認、マルウェアの動作の調査、ソフトウェアの脆弱性調査 等のために利用される。
ソフトウェアの場合は、実行可能形式のプログラムから逆アセンブル・逆コンパイル等を行って（不完全な）ソースコードを取得、動作解析することが多い。
◆DevOps
Development + Operations を合わせた造語。
開発部門(Dev)と運用部門(Ops)が緊密に連携してシステムの改善を進めようという考え方。
組織が分断されていることも多く、考え方や利害が対立することもあるため、コミュニケーションや情報共有を改善し、開発と運用のサイクルを統合することで、ソフトウェアの迅速な開発・導入、頻繁な改善・更新を可能にする方法論。
DevOpsの導入には、ソフトウェアの頻繁な更新が必要となるため、アジャイル方式の反復型杯初手法が採用される。
この記事が気に入ったらサポートをしてみませんか？