システム開発手法の種類を調査してみた

#システム開発手法
システム開発の手法とは、業務システムの開発工程を構造化し、計画・制御するための枠組みのことです。 そうしたシステム開発手法は、今日までにさまざまなものが考案されてきましたが、それぞれに長所/短所があり、プロジェクトの種類や状況に応じて最適な開発手法を選択する必要があると言えるでしょう。

##オブジェクト指向
オブジェクト指向（オブジェクトしこう、英: object-oriented）は、ソフトウェア開発とコンピュータプログラミングのために用いられる考え方である。元々は特定のプログラミングパラダイムを説明するために考案された言葉だった。明確な用語としては1970年代に誕生し、1980年代前半に知名度を得て、考案者の手を離れた自由で曖昧な定義のまま発展を続けた後に、1990年代に入るとソフトウェア工学の様々な分野にも応用されるようになった。ソフトウェア開発における一つの標語のような扱い方もされている。

##ウォーターフォール
プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、主として以下のような工程で行われる。


1.要求定義（要求仕様）

2.外部設計（概要設計）

3.内部設計（詳細設計）

4.開発（プログラミング）

5.テスト（ソフトウェア）

6.運用（システム）


上記のように作業工程（局面、フェーズ）にトップダウンで分割する。線表（ガントチャート）を使用してこれらの工程を一度で終わらせる計画を立て進捗管理をする。原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を確保し、前工程への後戻り（手戻り）を最小限にする。ウォーターフォール・モデルの利点は、工程の進捗管理がしやすいことである。


##アジャイル

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。例えばオブジェクト指向開発において、設計とプログラミングを何度か行き来し、トライアンドエラーで改良していく手法を指す。 特に「アジャイルソフトウェア開発宣言」が出された2000年代以降、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) やスクラム開発などがある。 非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している。

##スクラム

スクラム（英: Scrum）は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」[要出典]とされる。この方法論は、製品開発における伝統的な、シーケンシャルなアプローチとは大きく異なる。この方法論は、チームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ることである。

##ペアプロ
ペアプログラミング（英: pair programming）はソフトウェア開発の手法の一つで、2人のプログラマが１台のマシンを操作してプログラミングを行う手法。

当初は、２人が１台のワークステーションに向かって作業するものだったが、現在では一人で複数台を同時に使ったり、一台に複数台のディスプレイを使うことも多くなり、具体的なやり方は変わっている。

実際にキーボードを操作してコードを書く人を「ドライバ」、もう1人を「ナビゲータ」と呼ぶ。30分ごとか、単体テストを1つ完成させる度に役割を交替するのがよいとされる。また、1日に一度の頻度でパートナーを変えるのがよいともされている。


##テスト駆動開発
テスト駆動開発 (てすとくどうかいはつ、英: test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行なった後、コードを洗練させる、という短い工程を繰り返すスタイルである。多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。近年[いつ?]はビヘイビア駆動開発へと発展を遂げている。

##チケット駆動開発
チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル[1]。細かな修正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高い[2]ことから、エクストリーム・プログラミングをはじめとするアジャイル開発でも実践されている。

##ドメイン駆動設計
ドメイン駆動設計（英: domain-driven design, DDD）とはソフトウェアの設計手法であり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソフトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」であるとする[1]。この名称は、 Eric Evans が同名の著作で用いた[2]。

書籍 Domain-Driven Design[2]では、たとえば ubiquitous language といった高位の概念と実践について多数述べられている。これは、ドメインモデルがシステムの要求を記述するためにドメインの専門家が提供し、業務上のユーザーやスポンサー、開発者みなにとってうまく働くような common language(共通言語)を形成するべきである、という考えである。同書は多層アーキテクチャを持つオブジェクト指向システムにおいて、一般的なレイヤ構造におけるドメイン層を記述することに重点を置いている。


##プロトタイピング

プロトタイピング（Prototyping）とは、実働するモデル（プロトタイプ）を早期に製作する手法およびその過程を意味する。その目的は、設計を様々な観点から検証する、機能やアイデアを形にすることでユーザーから早めにフィードバックを得るなど、様々である。プロトタイピングはシステム設計工程の一部として組み込まれることも多く、それによってプロジェクトのリスクと費用を低減させると考えられている。反復型開発では1つ以上のプロトタイプが作られ、欠陥や問題が徐々に解決されていく。プロトタイプの改善が十分なされ、機能/堅牢性/製造の容易さといった設計目標に達したとき、製品としての製造が可能となる。

##コーディング規約あり
プログラミング作法（en:Programming style）の記事では、コンピュータ・プログラミング及びプログラムのスタイル（書法）についての話題を述べる。この分野の古典は、1970年代の書籍『プログラム書法』（The Elements of Programming Style）である。古典であるゆえにプログラミング言語も古く、例がもっぱらFORTRANであるため言語の設計の古さによる制限に由来する記述も多いが、本質（Elements）は不変・普遍である。

なお、『プログラミング作法』は "The Practice of Programming" という書籍の邦題、『ソフトウェア作法』[1]は "Software Tools" という書籍の邦題である。

あるプロダクトに見られるスタイルは、単にその作者の好みの問題という場合もあるし、何らかの「コーディング標準」や「コーディング規約」などと呼ばれるものによるものという場合もある。PythonのPEP-8、PHPのPEARのように、言語のメンテナらによる、標準的なガイドラインがある言語もある。


##グローバルチーム（多国籍メンバー）
多国籍企業（たこくせききぎょう、英語：Multinational Corporation、略称：MNC）とは、活動拠点を一つの国家だけに限らず複数の国にわたって世界的に活動している大規模な企業のことである。