ウォータフォール型開発技法
後工程になってから前工程の不備や誤りが見つかると、手戻りが発生して多大な費用や時間がかかります。それを防ぐために、各工程ごとに関係者の承認を得てから次工程に進む開発技法をウォータフォール型開発技法といいます。
従来から広く採用されている技法で、環境変化が比較的少ない分野での大規模なシステムに適しています。
しかし、ウォータフォール型開発技法では、次のような欠点があります。
前工程が完成しないと次工程に進めないので、開発に時間がかかる。
外部設計後に環境変化が起こっても、手戻りするのが困難である。
利用者は、移行実施段階になってから実物を見て、要求の手違いがわかる。
それで、環境変化が激しい分野のシステム開発には不向きです。
アジャイル開発技法
ウォータフォール型の欠点を回避するために、限られた時間や要員でシステム開発を行うための開発技法が出現しました。その総称をアジャイル開発技法といいます。
いろいろな開発技法がありますが、システム全体を細分化あるいは簡素化により小規模なシステムにして、要求分析から実現までの期間を短縮すること、少数の開発者と利用者が一緒に作業することにより、互いに成果を確認・評価し、改善・拡大を繰り返すのが特徴です。
- イテレーション型（反復型）モデル
- イテレーションとは、要求分析から移行までの一連の活動です。ウォータフォール型開発技法では、イテレーションを１回しか行わないのに対して、短期間にイテレーションを行い繰り返す開発技法の総称です。それにより、利用者の要求と開発成果物の不一致の解消、要求変更への柔軟な対応、利用者のシステム理解の徹底などに効果があります。
- インクリメンタル型（段階的）モデル
- 一挙にシステム全体を構築するのではなく、まず中核となる部分だけを構築し、逐次機能を追加したり、対象範囲を拡大する方法の総称です。ともかく短期間に最低限の機能を実現し、それから周辺機能の拡充や使い方の改善を図ろうとするものです。
- 進展的モデル
- 後述のスパイラルモデルは、部分毎にプロトタイプを作りバージョンアップとしながら全体を作っていくののに対して、、進展的モデルは、ＯＳ開発のように、システム全体のプロトタイプを最初に作り、それをバージョンアップしていく方法です。
ウォータフォール型開発技法以外の主な開発技法を示します。上記の区分は何に注目したかの視点によるものであり、以下の開発技法は複数の総称技法に属しています。
- プロトタイピング開発技法
- プロトタイプ（見本）を短期間に構築して利用者に見せ、要求を取り入れて逐次改善していく方法です。
- スパイラル開発技法
- プロトタイピング開発技法は、見方を変えれば、各工程をスパイラル（らせん）的に繰り返すことだともいえます。その意味では、スパイラル開発技法とプロトタイピング開発技法は、似たようなものだといえます。
しかし、スパイラル開発技法は中核を作ってからスパイラル的に対象を拡大することを重視しており、インクリメンタル型開発技法の一つだともいえます。
情報技術者試験問題では、後者の解釈が多いようです。「見本」ならばプロトタイピング、「繰返し」ならばスパイラル」と理解しておけばよいでしょう。
近年の開発技法
近年は、企業間競争が激しくなり、情報システムの企画から稼働までの時間短縮が重視されるようになりました。そのための開発方法論の総称をＲＡＤ（Rapid Application Development）といいます。
比較的短期間の開発期間を決めておき、その間で開発する方法です。
技法的には、プロトタイピング開発技法やスパイラル開発技法を発展させ、ＣＡＳＥ技術を組み合わせています。
体制的には、業務をよく知っているユーザと、能力の高い開発者がペアになって開発を行い、テストや文書化などの作業はまわりのスタッフが支援するような体制で行ないます。
ＲＡＤを行うための方法や体制について、多様なモデルが提案されています。
- ラウンドトリップ・エンジニアリング
- モデリング段階とコーディング段階を往復しながらソフトウェア開発を行う技術です。ＵＭＬのようなモデル図からソースプログラムを自動生成したり、ソースプログラムを修正するとモデル図が自動修正されるようなツールが使われます。
- カンバン方式
- トヨタによるジャストインタイム生産方式をシステム開発スケジューリングに応用して、何を、いつ、どれぐらいのコストで開発するかなどを管理するプロセス管理システムあるいはそれを活用した開発体制です。
- フィーチャ駆動型開発
- この場合のフィーチャ（feature）とは、利用者の視点での必要なソフトウェアやシステムの持つ機能（要件）のこと。
フィーチャ駆動型開発（Feanture-Driven Development：ＦＤＤ）とは、フィーチャを単位として、実際に動作するソフトウェアを短期反復的に開発し、徐々に完成に近づけていくアジャイル開発の方法論です。
計画、設計、構築を繰り返す点では、スパイラル開発技法と似ているし、開発対象機能を逐次拡大する点では、インクリメンタル型開発技法と似ています。開発プロセスの特徴よりも、利用者のニーズを重視して対象にする機能を設定することが特徴だといえましょう。
ＸＰ（エクストリーム・プログラミング）
従来の開発技法は、ドキュメントが重視され、仕様が正しく定義され、正しい手順で開発すべきだとされてきました。ＸＰの提唱者ケント・ベックらは、「変化を享受せよ」として、開発に伴う変化を当然あるべきものとして積極的に対応できることを目指しました。開発スピードの重視、ダウンサイジングなどの環境変化などにマッチし、急速に普及しました。
ＸＰの５つの価値
開発チームが共有すべき５つの価値
・顧客と開発者、開発者間の円滑な「コミュニケーション」
・必要最小限の設計しか行わない「シンプルさ」
・頻繁なテストによる「フィードバック」
・大胆な設計変更に立ち向かう「勇気」
・関係者の意見や能力の「尊重」
１９のプラクティス（抜粋）
ＸＰのプラクティス
共同のプラクティス
- 反復
開発期間を１，２週間の短いイテレーションに区切り「設計→実装→テスト→リリース」を繰り返す。 - 共通の用語
- 開けた作業空間
- 回顧（頻繁な振り返り）
開発のプラクティス
- テスト駆動開発
プログラムを作る段階でテストのためのプログラムも作り、テストを行いながらプログラムを完成させる。機能追加するたびにテストを行い、常に品質１００％の状態にしておく。 - ペアプログラミング
２人が一組になり、一人がキーボードをたたいてコードを作成し（ドライバ）、もう一人はコードのレビューや全体の設計などのサポートをする（ナビゲータ）。一定の時間でその役割を交互に交代するとか、パートナーを変えるのがよいとされています。 - リファクタリング
追加機能によりプログラムが複雑になったら、システムの動作を変えることなくシステムを再設計する。 - ソースコードの共同所有
誰が作ったソースコードであっても、開発チーム全員が断りなく修正を行うことができる。ただし、全てのコードに対する責任を、全員が担う。そのために、>コーディング基準が重視される。 - 継続的インテグレーション
単体テストをパスするコードが完成するたび、すぐに結合テストを行い、問題点や改善点を探す。 - ＹＡＧＮＩ
You Aren't Going to Need It.（必要なことだけ行う）。当初から全体を対象にするのではなく、その時点で必要最低限の仕様にして、非常に短期間でプログラムを作成する。追加機能が起こったときにフィードバックして変更すればよい（変化ヲ抱擁セヨ）。
管理者のプラクティス
- 責任の受け入れ
- 援護
- 四半期毎の見直し
- ミラー
今どういう状態かをチームに知らせる。 - 最適なペースの仕事
知的作業には、週40時間の労働時間が最適である。
顧客のプラクティス
- 計画ゲーム（ストーリ）
利用者と開発者で、実装予定機能を記したストーリーカードを作成し、優先順位を決め、イテレーションごとに必要最小限な機能だけを決定する。ストーリーカードは、最初は概要のみを記載しておき、必要に応じてに詳細を詰める。 - リリース計画
- 受け入れテスト
- 短期リリース
スクラム開発技法
システム開発でも、ラグビーのスクラムのように、各メンバーが協力し、全体が同じ目的を共有することが重要だとする、少人数によるアジャイル開発手法です。
比較的小規模なシステムを、利用者のニーズを柔軟に反映させながら、短期間で稼働させることを目的としています。
開発すべきシステムを細分化して１～４週程度で完結する開発の単位をスプリントといい、各スプリントを短期間で開発、まとめ、レビュー、調整の繰り返しで開発します。
・テスト駆動開発
・受け入れテスト駆動開発
・リファクタリング
・継続的インテグレーション
スクラム開発の組織
- スクラムチーム
５～９名程度で編成。各メンバーが協力し、全体として同じゴールを目指す。作業プロセスと作業結果の責任も持ち、自らチーム内の管理を行う。 - スクラムオーナー
総責任者。 顧客の要望（ユーザーストーリー）をプロダクトバックログに優先順位を付けて反映させ、ビジネスの視点においてプロジェクトに問題がないことを保障する役割を持つ。 - スクラムマスター
チーム内外の組織間調停( ファシリテーション )の役目です。スプリントの会合での司会（ファシリレータ）をします。
バックログ
バックログとは、解決すべき事項です。これがなくなったときがスクラムのプロジェクトの終了になります。
- プロダクトバックログ
プロジェクト全体のバックログ。環境変化によりバックログは絶えず変化します。チームが相対難易度（コスト）の見積もりを付けられ、プロダクトオーナーが顧客観点からの価値を見積もる。プロダクトバックログの見積りが非現実的と思われる場合、あるいは優先順位についての知見がある場合、プロダクトオーナーは、チームに強制するのではなく、チームに説明して合意べきだとされています。 これをリリース計画ミーティングといいます。 - スプリントバックログ
スプリントバックログはプロダクトバックログを管理可能な単位に細分化したものです。一つのスクリプトでこれから実現する事項のリストでもあります。
スプリントの流れ
スプリントとは１～４週程度で完結する開発の単位です。利用者も加わり開発、まとめ、レビュー、調整の繰り返しで行ないます。
- スプリントプランニング
立上げのプロセスです。スプリントで実現するバックログの項目を選択し、その実現のためのタスク化を行う。 チームが共同でタスク化する過程で、チーム内メンバーの認識差異がないことを最終確認します。 - デイリースクラム
毎日の開発作業の後、１５分以内のスクラム会議を開きます。スクラムマスターが司会（ファシリレータ）になり、前回以降の結果、次回までの作業について、チーム全体で確認します。 - プロダクトバックログリファインメント
スプリント期間中、必要に応じて開く会議です。通常はＩＮＶＥＳＴ形式で行われます。 - 振り返り
スプリントレビューとレトロスペクティブがあります。 - スプリントレビュー
スプリントの一巡ごとに関係者全員による会合で、チームの成果を振り返ります。スプリントバックログの追加や変更が行われ、顧客が満足するまでスプリントとスプリントレビューの繰り返しが行われます。 - レトロスペクティブ
振り返りのプロセスですが、「チーム自体」やチーム活動の「プロセス」を振り返る活動のことをいいます。
チームのメンバー全員で本音で話し合い、チームの問題点や良いところを探し、次の活動の改善や継続的に取り組む事項について合意します。スプリントゴールの達成度、スプリントで発生した問題、その問題に対する改善策などについて話し合い記録に残します。
ＫＰＴ法
スプリント状況の「振り返り」のフレームワークです。
- Keep（継続）
これでうまくいっているので、このまま続けていこうとする事柄です。 - Problem（課題）
改善を要する事柄です。 - Try（次の取組）
課題をどうやって解決・改善するのかです。
このフレームワークでスプリントを振り返ることにより、状況を関係者全員が状況を早期に共有して、課題と解決について合意することができます。
ＤｅｖＯｐｓ
開発担当者（Development）と運用担当者（Operations）が協調してシステム開発・運用します。Devは、システムに新しい機能を追加すること、Opsは、システムを安定稼働することであり、システムによるビジネスへの価値向上を確実かつ迅速にエンドユーザに届け続けること、その継続的改善を確実にすることが目的です。開発担当者とはベンダやＩＴ部門、運用担当者とはユーザ企業あついは利用部門です。
アジャイル開発技法の一つではありますが、カイゼンやリーン生産方式を背景とした概念で、常にシステムに新しい機能を追加することを重視しています。組織文化の変化を伴うカイゼン運動としての要素もあります。
ＣＬＡＭＳ
Devopsの特徴としてＣＬＡＭＳを挙げています。
Cluture（文化）
Lean（リーン）
Automation（自動化）
Measurement（計測）
Sharing（共有）
チーム組織文化
チーム組織文化として、次のルールを定めています。
- お互いを尊重する（Respect）
一緒に働く相手のことを心から思いやる、相手を一人の人間として扱い、能力や功績を評価する - お互いを信頼する（Trust）
自分以外の人は優秀で、正しいことをすると信じる。信じて仕事を任せる - 失敗に対して健全な態度を取る（Healthy attitude about failure）
新しいことに挑戦すれば自ずと失敗は起こってしまうもの。失敗は起こるものであり、相手のミスだと責めるものではない - 相手を非難しない（Avoiding Blame）
相手に非があると断じて言葉で責めるのではなく、次に同じ問題が起こらないように建設的な批判を行う
支援ツール
「Devopsツール」というような特定のツールはなく、既存のツールあるいは手法の利用を推奨しています。
特に重視しているのは自動化と情報共有です。次のようなツールを掲げています。
- Automated infrastructure（開発環境の自動化）；GitやMercurialなど
- One step build and deploy（開発・運用の一体化と自動化）：JenkinsやCapistranoなど
- Feature flags（機能の今後対処表）
- Shared metrics（実現尺度の共有）：New RelicやApplication Insightsなど
- IRC and IM robots（文字メッセージのリアルタイム交換やインスタントメッセンジャーの自動化）：SlackやHipChatなど
アジャイルソフトウェア開発宣言
参照：ＩＰＡ「アジャイルソフトウェア開発宣言の読みとき方」（ https://www.ipa.go.jp/files/000065601.pdf）
「アジャイルソフトウェア開発宣言」は、従来型のソフトウェア開発のやり方とは異なる手法を実践していた17名のソフトウェア開発者が、それぞれの主義や手法についての議論を行い、 2001年に公開されました。そこには、彼らがソフトウェア開発を行ううえで重視している「マインドセット」が書かれていました。その後、このマインドセットは、世界中のソフトウェア開発者達に支持され、”アジャイルソフトウェア開発” という名で世に広まりました。
アジャイルソフトウエア開発宣言では、４つの価値と１２の原則を示しています。
現在、いろいろな局面で「アジャイル」という言葉が使われていますが、この言葉の根本の考え方には、この「アジャイルソフトウエア開発宣言」があると考えて良いでしょう。
一方「アジャイル宣言の背後にある原則」は、「アジャイルソフトウェア開発宣言」で表明されているマインドセットを実現するために、従うことが望ましい原則、つまり根本的・根源的な取り組み姿勢について、書かれています。
４つの価値（マインドセット）
- プロセスやツールよりも、個人と相互作用
- 包括的なドキュメントよりも、動作するソフトウエア
- 契約交渉よりも、顧客との協調
- 計画の順守よりも、変化への対応
各項目において、前者にも価値はあるが、後者の価値をより重視する。
（注）ＩＰＡ「アジャイルソフトウェア開発宣言の読みとき方」での説明
- 「対面コミュニケーション」
個人同士の対話を通じて相互理解を深めることで、よりよいチームが作られる。 - 「実働検証」
動くソフトウェアを使って繰り返し素早く仮説検証をし、その結果から学ぶことがよりよい成果を生み出す。 - 「顧客とのWin-Win関係」
お互いの立場を超えて協働することにより、よりよい成果と仕事のやり方を作ることができる。 - 「変化を味方に」
顧客のニーズやビジネス市場の変化は事前計画を狂わす脅威ではなく、よりよい成果を生み出す機会と捉える。
１２の原則
- 最も重要なのは、顧客満足。初期段階から継続的に、価値あるソフトウエアをリリースすること。
- 終盤での要求変更も受け入れること。アジャイルプロセスは顧客の競争力を高めるためのもの。
- 数週間～数か月の単位で頻繁にリリースすること。リリース間隔は短い方が良い。
- プロジェクト中、毎日、顧客と開発者が一緒に働くこと。
- やる気を重視して開発チームを構成すること。顧客も開発チームの仕事遂行を信じサポートすること。
- 開発チーム内の情報伝達は、会話が一番。
- 最も重要な進ちょく尺度は、動くソフトウエア。
- アジャイルプロセスは、継続的な開発を促進する。顧客や開発者は一定のペースを保てる。
- 技術や設計をレベルアップさせる意識が、より俊敏（アジャイル）さを高める。
- 「手作業を行わないための工夫」が重要。
- 自律的なメンバーが協調して動くチームの方が、パフォーマンスが高い。
- 定期的な「ふり返り」により、開発チームのパフォーマンスをより高めるようにすること。
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。
- 変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。
- 環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル･プロセスは持続可能な開発を促進します。
- 一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
ＣＩ／ＣＤ
ＣＩ／ＣＤの構成
ＣＩ／ＣＤ（Continuous Integration / Continuous Delivery/Deployment）は、大規模なシステムを多数の開発者が改善を進めていくプロジェクトを対象にした管理の方法論です。
ＣＩ／ＣＤの位置づけ
- アジャイル開発との関係
アジャイル開発においては、利用者と開発者がペアになり、要求－開発－提示のプロセスを短期間に繰返すことが求められます。
ＣＩ／ＣＤは、そのための具体的な手段や自動化を行う手段を提供します。 - DevOpsとの関係
DevOpsとは、開発（Development）と運用（Operations）を組み合わせた造語で 開発担当と運用担当間が緊密に連携して、両者間にありがちな対立を解消し、協力して円滑な開発・運用を進めていこう」という考え方です。
ＣＩ／ＣＤは、DevOpsを推進するための主要な方法論だといえます。 - 分散型バージョン管理システムとの関係
大規模なシステムを多数の開発者が改善を進めていくプロジェクトを対象にした分散型バージョン管理システムを実行するためのプラットフォームにはＳＶＮ（Subversion）やGitHubがあります。
これにより、個々の開発者による変更を支援すること、その変更を全体で共有するだけでなく、変更前のバージョンと変更後のバージョンを共に利用可能な状況にして、円滑なバージョンアップができます。
ＣＩ／ＣＤは、これらのプラットフォーム実装のための考え方を提示しています。
ＣＤ／ＣＩの構成
- 継続的インテグレーション（Continuous Integration：ＣＩ）
- ソフトウェア開発において、ビルド・テスト・統合を頻繁に繰り返し行なうことにより問題を早期に発見し、開発の効率化や省力化、納期の短縮などを図る手法。
- 現行システムは、細分化されたモジュール（オブジェクト指向言語ならクラス）からなり、その全体はＣＩサーバにマスタファイルとして登録されている。
- 開発者は、現状のマスタファイルから、変更対象となるモジュール（プログラム）を自分のファイル（ローカルファイル）にコピーする。
- 開発者がローカルファイルのモジュールを更新する。
- その変換されたプログラムをＣＩサーバが検知し自動で変換する。このコンパイル→リンケージ→実行プログラムの流れをビルドという。
- あらかじめ作っておいたテストコードを使って、ＣＩサーバは自動でテストを行う。その結果は開発者に、フィードバックされる。
- 正しく更新されたモジュールは、マスタファイルに送られるが、この際、以前のモジュールは保持され、変更後のモジュールは新しいバージョンが付加され保管される。これを統合（インテグレーション）という。
- 継続的デリバリ（Continuous Delivery）
- 継続的デプロイメント（Continuous Deployment））
- 双方とも、ビルドされたモジュールを実行可能な環境に配置し、実行できるようにすることです。
継続的デプロイでは、明示的な承認が行われることはなく、自動的に本番環境になります。
継続的デリバリーは、運用環境への更新に人間による確認が行われた後に、システム全体をリリース（利用者に公開）します。
ＣＤ／ＣＩの利点
継続的インテグレーションにおける更新バージョンの仕組みは、次のような利点があります。それで「分散型バージョン管理システム」の基礎になります。
- 更新した内容は、開発者全員が知ることができる仕組みになっています。
- 更新版が不要だと評価されれば、そのバージョンは廃棄されます。
- 更新版が有効であり、他のモジュールに影響がないことが明らかならば、更新版のバージョンを正式バージョンとします。この際、旧版を廃棄し、更新版のバージョン番号を旧版のバージョン番号にするか、そのままにするかは管理の方針によります。
- 他のモジュールに影響する場合は、それらのモジュールの変更を行う必要がありますが、その間でも旧版はそのまま保存されているので、利用者は旧版を使い続けることができます。
- 影響を受ける他のモジュールの対処が困難あるいは不適切だと判明したときは、これに関するすべてのモジュールを廃棄すれば済みます。すなわち、開発者は失敗になってもシステム全体に影響がないことが保証されます。
- 変更があっても、上位互換が保たれているときは、影響するモジュールの変更を急ぐ必要はありません。このように、システム改訂の管理が容易になります。