HEAVEN INSITE's Blog

　最近気が向いて順調に攻略中のシステム設計。残る必修課題は12個。なんとか今月中にいけそうだ！やれば出来る子！！

参考文献：内山俊郎著『わかりやすい情報システムの設計――UML/Javaを用いた演習』

開発プロセス
情報システムの開発プロセスには、大きく二つの方法がある。
順番に手順を完了させるウォーターフォール型と、部分的なリリースを繰り返して完成度を上げていく反復型である。
この二大派閥は、どちらが優れていて、どちらが劣っていると、決めつけることはできず、また、仮に反復型が優れていたとしても、明日から反復型にします！と簡単に切り替えられない現実的な問題もある。

ウォーターフォール型
要件定義→設計→実装と、滝が流れるように順次処理をする。
滝の水が逆流しないように、プロセスは後戻りしない。
そのため、事前に綿密な計画（いつまでに何を作るか、コストの見積はいくらか）を立てる。基本的に手順のルールがしっかりと決まっている。
開発期間は数ヶ月～数年で、もちろん最終目標（スコープ＝何を作るか）は変わらない。

メリット
生産性が高い。要件定義を終えれば設計を一気に進められる（中断が少ない）。
全体的な予算見積もりが早期に出る。

デメリット
対応力が低い。プロセスの初期で要件定義を終えているので、その後変更が必要になっても路線変更が難しい。実際は手順を戻ることになるが、それもできずに手遅れになることもある。
工程によってメンバーが替わるため（バトンタッチする）、引き継ぎ業務（ドキュメント作成など）が必要。

反復（イテレーション）型
非ウォーターフォール型とも呼ばれる。
システムを機能面などで小分けにし、それぞれに開発期間（１～４週間ほどの短いもの）を設ける。つまり、各開発期間で分割されたシステムの開発（全アクティビティの実行）を行う。
全体の計画は概略的。開発規模の見積もりが固まり出すのは、プロジェクト期間の10～20％が終わるくらい。つまり、定額契約が難しい。
ルールよりもエンジニアの経験がものをいうため、開発の進め方は彼らの経験とともに変わり、常に向上していく。
2000年頃普及しだしたイメージがあるが、古くには、50年代のX15極超音速ジェット機の開発、60年代のNASAにおけるマーキュリー計画、72年のトライデント潜水艦命令制御システムの開発、77～80年のスペースシャトルの第１航空電子ソフトウェアシステムの開発などの例がある。
その後、アメリカ国防省はウォーターフォール型の開発を推奨したが、失敗事例（先端技術開発では開発要求がリアルタイムで進化していってしまうため）を見て、87年の勧告では早くも反復型の推奨に戻している。

メリット
対応力が高い。いつでも軌道修正が可能。
例えば、ある機能をせっかく開発したのに結局使わなかったというような開発の無駄をなくせる。
システムを小単位ごとに分割するため開発期間が短縮できる。
工程が変わってもメンバーが替わらないため引き継ぎが不要で、また前行程での経験がチームのノウハウとして蓄積していく。

デメリット
生産性が低い（作業を途中で中断することが容易なため）。
全体的な予算の見積もりが不明確な状態でスタートするため、請負型契約（完成した仕事に報酬を支払う契約）が困難。同様に、企業の規模が大きいと予算管理部門が反復開発を採用しない。

アジャイル開発
アジャイルとは俊敏という意味（・・・もしかしてアジャコングって俊敏なゴリラっていう意味！？）。
アジャイルソフトウェア開発宣言（01年にユタ州に集まった17人のプログラマーやエンジニアが行なった宣言）と、全12項目のアジャイル原則を指針とする、反復型開発プロセスである。

アジャイル宣言
プロセスやツールよりも・・・個人と相互作用
包括的なドキュメントよりも・・・動くソフトウェア
契約交渉よりも・・・顧客との協調
計画に従うよりも・・・変化に対応すること

これは、左側の言い分にも価値はあるが、それよりも右側を重視するということである。
「個人と相互作用」からは、まず開発者が満足することが持続可能な開発において必要であることが、「顧客との協調」「変化に対応すること」からは、顧客やエンドユーザからのフィードバックを受け入れることや、コミュニケーションを重視している（スクラム開発）ことがわかる。
また、アジャイル開発には上手くいく方法の中で最もシンプルなものを選べという考え方も盛り込まれている。

スクラム（Scrum）
人命に関わるシステムの設計にも用いられているアジャイル開発の中で最も有名な手法。
ラグビーのスクラムのように、開発チームのメンバー（なぜかブタと呼ばれる）同士がコミュニケーションをよく取り合い、足並みをそろえて開発を行なう。

例えば、毎朝立ちながら20分程度のミーティング（スクラムミーティング）をするなど、反復ごとに自分たちで立案した計画を自分たちで精査する。
そのため、チームの人数は３～10人くらいに抑える（人数が多いとコミュニケーションが難しくなり、チームとしての一体感も希薄化するため）。

ちなみに、反復の途中ではメンバー以外の利害関係者が作業を追加してはならない。つまり、部外者（なぜかニワトリと呼ばれる）は口をはさまない。チームの自律性を重んじるのである。

スクラムミーティングの内容としては以下のものがある。
①前回のスクラム以降何を行ったか？
②今から次のスクラムまでに何を行うか？
③反復の目的を達成する上での障害は何か？
④スプリントバックログ（チームが当たるタスクの待ち行列のこと）に追加するタスクはあるか？
⑤チームメンバーから刺激を得て、何か新しく学んだことはあったか？

エクストリーム・プログラミング（XP）
小規模プロジェクトを素早く成功させることに特化した方法（反復期間は１～２週間）。
開発途中の仕様変更や設定変更にも勇気をもって柔軟に対応する。
プログラマー中心主義と言ってもよく、バディムービーのようにタッグを組んでプログラミングをするペアプログラミングなど面白い考え方がある。
XPが独特な点は、プログラムコードとテスト以外には成果物を要求しない点である。
他のアジャイル開発では、目前の反復の計画くらいは立てるが、XPではドキュメント作成を極力減らすため、そういったものすら作らない（ただし、ホワイトボードにタスクリストくらいは書く）。