APITT
「開発手法」

1. 開発手法の種類を説明できるようになる。
2. 開発手法の特徴を説明できるようになる。
3. 各種開発案件に適した開発手法を選択できるようになる。

1. 1日目:座学、開発手法の種類と特徴
2. 2日目:実習、作業リストを時系列で作成し、各作業をどの開発手法で進めるかを決定する

開発を進める手順のこと。

• いつ設計をするのか?
• いつ実装をするのか?
• いつテストをするのか?
• いつ検収をするのか?
• いつレビューをするのか?

「ウォーターフォールモデル」「プロトタイプモデル」「スパイラルモデル」「インクリメンタルモデル」「アジャイル」がある。

開発を取り巻く環境

• システムが複雑化し管理が難しい:PMによる集中管理には限界がある。
• 短納期:生産性を上げるか残業するか。
• 変更はつきもの:変更は基本的に対応すべきもの。
• トレンドや要求はめまぐるしく変わる:長期開発が終わるころには時代遅れの可能性あり。

これから各種開発手法を見ていくが、どれが良くて、どれが悪いということではありません。 開発の内容、要求の確定具合、組織が持っているノウハウによって適した開発手法が異なってきます。 本講座では、各種開発手法の特徴を知り、特定の開発案件に対して適した開発手法を選択できるようになることが目的です。

IPA ｢共通フレーム2007 第2版｣の発行

　「共通フレーム2007」とは、ソフトウェア、システム、サービスへの従事者が、言葉の意味（範囲）の解釈の違いによるトラブルを予防する（誤解を招かぬようにする）ため“同じ言葉を話す“ことができるよう共通の枠組みを提供し、ソフトウェアの構想から開発、運用、保守、廃棄にいたるまでのライフサイクルを通して必要な作業内容を包括的に規定したものです。

• 分析・設計・実装・テスト・運用
• 後行程には戻らないことを前提としている

メリット

• 見積りが出しやすい
• 進捗管理が行いやすい
• 人員計画が立てやすく、分業しやすい

• 顧客要求の把握が早期にできない、事業環境の変化に追随できない
• 終盤にならなければ動作しているところを確認することができない

課題は?

• ウォーターフォールモデルを2回まわす
• 初期にプロトタイプを作成し、それをユーザに評価してもらうことで、設計•実装の妥当性を検証。手戻りを減らす。
• ウォーターフォールモデルの行程を一度回してみないと分からない。

メリット

• 1周目で課題が明かになる
• プロトタイプをユーザに見てもらうことで、要求が出しやすくなるし、解釈のズレも起きにくい
• 1周目を元に見積りを出すと精度が高い

• 1周目の成果物は破棄する
• プロトタイプを高速に作らなければコストが増える

課題は?

• 分析・設計・実装・テスト を細かく繰り返す
• プロトタイプを作成して評価し、その評価を受けながらウォーターフォールモデルの行程を再度行う

メリット

• 動作を確認しながら開発ができる。

• 徐々に完成へ向かうため、先行きが管理しずらい。

課題は?

• 独立性の高いサブシステムに分割して開発

メリット

• サブシステムに分けることで規模が小さくなり、管理しやすい

• サブシステム間で協調して開発を進める必要がある

課題は?

システムの規模が拡大し、管理が難しくなったために考え出されたのがこれまでの開発モデル。 大規模なシステム開発が由来であるため「重量開発手法」と呼ばれることがある。

Webの普及により大規模なシステムよりも小規模なシステムを複数開発するという考え方が広まってきた。 小規模なシステムの方が管理がしやすく開発が容易だからである。 そういった小規模なシステムに対して重量開発手法は向かない。 そこで考え出されたのがアジャイルモデルである。 そのためアジャイルは「軽量開発手法」と呼ばれる。

「アジャイルソフトウェア開発宣言」

アジャイルソフトウェア開発手法とは、一群のソフトウェア開発手法の総体を意味する言葉であり、単一の開発手法を指す言葉ではない。 2001年に、アジャイルソフトウェア開発手法 (当時は軽量ソフトウェア開発手法と呼ばれていた) の分野において名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法の重要な部分を統合することについて議論した。 そして、彼らは「アジャイルソフトウェア開発宣言」(Manifesto for Agile Software Development) という文書にまとめた。

特徴

• 重量開発手法は「手続き中心」、アジャイルは「個人と相互作用」
• 重量開発手法は「計画中心」、アジャイルは「変化への対応」
• 決められた短い期間で動くアプリケーションを作成する
• スパイラルモデルモデルよりも短期間で区切る

4つの価値

• プロセスやツールよりも、個人と相互作用
• 包括的なドキュメントよりも、動作するソフトウエア
• 契約交渉よりも、顧客との協調
• 計画の順守よりも、変化への対応

12の原則

• 最も重要なのは、顧客満足。初期段階から継続的に、価値あるソフトウエアをリリースすること
• 終盤での要求変更も受け入れること。アジャイルプロセスは顧客の競争力を高めるためのもの。
• 数週間～数か月の単位で頻繁にリリースすること。リリース間隔は短い方が良い。
• プロジェクト中、毎日、顧客と開発者が一緒に働くこと。
• やる気を重視して開発チームを構成すること。顧客も開発チームの仕事遂行を信じサポートすること。
• 開発チーム内の情報伝達は、会話が一番。
• 最も重要な進ちょく尺度は、動くソフトウエア。
• アジャイルプロセスは、継続的な開発を促進する。顧客や開発者は一定のペースを保てる。
• 技術や設計をレベルアップさせる意識が、より俊敏（アジャイル）さを高める。
• 「手作業を行わないための工夫」が重要。
• 自律的なメンバーが協調して動くチームの方が、パフォーマンスが高い。
• 定期的な「ふり返り」により、開発チームのパフォーマンスをより高めるようにすること。

• 要求の変化に強い

• 従来との契約、見積り、マネジメントが適応しづらい

課題は?

• 反復型全般に言えるが、簡単なタスクに着手し、簡単なことをグルグル開発してしまうことがある。
• 見積りが出せない。顧客に理解してもらうのが難しく、契約形態も難しい。ポイントは受注側と発注側のリスクを均等にすること。
• 経営者層にどうやって説明するのか?

重量開発手法とアジャイルの比較

	重量開発手法	アジャイル
重点事項	手続き	個人と相互作用
重点事項	計画	変化への対応
活用しやすい開発の種類	クリティカルなシステム	非クリティカルなシステム
活用しやすい開発の規模	大規模	小規模
開発チーム	誰でも参加できること前提	アジャイルの経験がある方が有利
マネジメント	従来のマネジメント手法がそのまま適応できる	従来のマネジメント手法をそのままでは適応できない
契約	従来の契約方法が適応できる	従来の契約方法をそのままでは適応できない

使用する技法

• テスト駆動開発
• リファクタリング
• 継続的インテグレーション

Scrumの方法論

• ストーリーカード:システムの動作シナリオ。顧客が作成する。これを元に工数を見積もる。


• スプリント:開発の区切り。開発、まとめ、レビュー、調整の繰り返し。通常1〜4週間と短く区切るのでsprint(短距離走)と呼ばれる。


• スクラム会議:毎日15分以内で開催。「前回の会議以降何をしたか」「問題はあるか」「次回の会議までに何をするか」をスクラムマスターが質問する。


• プロダクトバックログ:製品に必要な要素の一覧。顧客の要求の一覧と言える。
• スプリントバックログ:スプリントで実現する仕様をまとめたもの。開発に必要な仕様。


• チーム:少人数(5〜9人)でスポーツのチームのように機能する。作業プロセスと成果に責任を持ち、自ら管理を行う。
• スクラムマスター:Scrumプロセスが正しく機能しているかの確認と管理、コーチング、外部阻害要因を取りはぶきチームを保護する。
• プロダクトオーナー:製品の総責任者。顧客の要望をチームに伝える。バックログの優先順位付けをする。


• 制御:バックログから工数を見積もる。完了したバックログから進捗状況を見積もる。

5つの価値

• コミュニケーション
• シンプル
• フィードバック
• 勇気
• 尊重

各役割毎のプラクティス

共同のプラクティス

• 反復:期間を1～2週間の短い期間(イテレーションと呼ぶ)に区切り、部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返す。徐々に完全なシステムを構築していく手法を取る。
• 共通の用語:用語集を作成し
• 開けた作業空間:会話しやすく、作業に打ち込める雰囲気を作る。
• 回顧:現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境、体制を構築しておく。

開発のプラクティス

• テスト駆動開発
• ペアプログラミング:二人一組で実装を行い、一人が実際のコードを書き、もう一人はそれをチェックしながらナビゲートする。
• リファクタリング:完成済みのコードでも、随時、改善処置を行う。
• ソースコードの共同所有:誰が作ったソースコードであっても、開発チーム全員が断り無く修正を行うことができる。ただし、全てのコードに対する責任を、全員が担う。
• 継続的インテグレーション
• YAGNI:You Aren't Going to Need It（今必要なことだけ行う）。先の事を考えて、前払い的に機能を増やし、実装を複雑化させる事は避ける。

管理者のプラクティス

• 責任の受け入れ
• 援護
• 四半期毎の見直し
• ミラー:今どういう状態かをチームに知らせる。
• 最適なペースの仕事:知的作業には週40時間の労働時間が最適である。特にXPでは、集中力を高めて効果を生む事を重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適さない。そのため、計画的に開発スピードの調整を行う。

顧客のプラクティス

• ストーリーの作成:求める機能のコンセプトを短い文章で記したストーリーカードを作成する。そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、詳細を決定する。
• リリース計画:どのストーリーをどのイテレーションの対象とするか、チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。
• 受け入れテスト:イテレーションごとに顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。もし満足できない場合は、それを指摘する。
• 短期リリース:リリースの期間はできるだけ短くする。顧客側と開発側の認識のズレを大きくしないため。

1. 目的
2. 日程
3. 開発手法とは
4. 開発手法の良し悪し
5. 共通フレーム2007
6. ウォーターフォールモデル
7. プロトタイプモデル
8. スパイラルモデル
9. インクリメンタルモデル
10. アジャイル
11. アジャイルに分類される開発手法(Scrum)
12. アジャイルに分類される開発手法(XP)
13. 開発手法の選定
14. まとめ