Web教材一覧システムの調達

システム開発技法

キーワード

ウォータフォール型、アジャイル開発技法、イテレーション型開発技法、インクリメンタル型開発技法、プロトタイピング型、スパイラル型、RAD、ラウンドトリップ・エンジニアリング、XP(エクストリーム・プログラミング)、5つの価値、XPのプラクティス、テスト駆動開発、ペアプログラミング、リファクタリング、ソースコードの共同所有、継続的インテグレーション、YAGNI、スクラム、スプリント、デイリースクラム、スプリントレビュー、レトロスペクティブ、KPT, DevOps、CLAMS、チーム組織文化、アジャイルソフトウェア開発宣言、マインドセット、4つの価値、12の原則、背後にある原則


ウォータフォール型開発技法

後工程になってから前工程の不備や誤りが見つかると、手戻りが発生して多大な費用や時間がかかります。それを防ぐために、各工程ごとに関係者の承認を得てから次工程に進む開発技法をウォータフォール型開発技法といいます。
 従来から広く採用されている技法で、環境変化が比較的少ない分野での大規模なシステムに適しています。

しかし、ウォータフォール型開発技法では、次のような欠点があります。
  前工程が完成しないと次工程に進めないので、開発に時間がかかる。
  外部設計後に環境変化が起こっても、手戻りするのが困難である。
  利用者は、移行実施段階になってから実物を見て、要求の手違いがわかる。
それで、環境変化が激しい分野のシステム開発には不向きです。

アジャイル開発技法

ウォータフォール型の欠点を回避するために、限られた時間や要員でシステム開発を行うための開発技法が出現しました。その総称をアジャイル開発技法といいます。
 いろいろな開発技法がありますが、システム全体を細分化あるいは簡素化により小規模なシステムにして、要求分析から実現までの期間を短縮すること、少数の開発者と利用者が一緒に作業することにより、互いに成果を確認・評価し、改善・拡大を繰り返すのが特徴です。

イテレーション型(反復型)モデル
イテレーションとは、要求分析から移行までの一連の活動です。ウォータフォール型開発技法では、イテレーションを1回しか行わないのに対して、短期間にイテレーションを行い繰り返す開発技法の総称です。それにより、利用者の要求と開発成果物の不一致の解消、要求変更への柔軟な対応、利用者のシステム理解の徹底などに効果があります。
インクリメンタル型(段階的)モデル
一挙にシステム全体を構築するのではなく、まず中核となる部分だけを構築し、逐次機能を追加したり、対象範囲を拡大する方法の総称です。ともかく短期間に最低限の機能を実現し、それから周辺機能の拡充や使い方の改善を図ろうとするものです。
進展的モデル
後述のスパイラルモデルは、部分毎にプロトタイプを作りバージョンアップとしながら全体を作っていくののに対して、、進展的モデルは、OS開発のように、システム全体のプロトタイプを最初に作り、それをバージョンアップしていく方法です。

ウォータフォール型開発技法以外の主な開発技法を示します。上記の区分は何に注目したかの視点によるものであり、以下の開発技法は複数の総称技法に属しています。

プロトタイピング開発技法
プロトタイプ(見本)を短期間に構築して利用者に見せ、要求を取り入れて逐次改善していく方法です。
スパイラル開発技法
プロトタイピング開発技法は、見方を変えれば、各工程をスパイラル(らせん)的に繰り返すことだともいえます。その意味では、スパイラル開発技法とプロトタイピング開発技法は、似たようなものだといえます。
しかし、スパイラル開発技法は中核を作ってからスパイラル的に対象を拡大することを重視しており、インクリメンタル型開発技法の一つだともいえます。
情報技術者試験問題では、後者の解釈が多いようです。「見本」ならばプロトタイピング、「繰返し」ならばスパイラル」と理解しておけばよいでしょう。

近年の開発技法

近年は、企業間競争が激しくなり、情報システムの企画から稼働までの時間短縮が重視されるようになりました。そのための開発方法論の総称をRAD(Rapid Application Development)といいます。
 比較的短期間の開発期間を決めておき、その間で開発する方法です。
 技法的には、プロトタイピング開発技法やスパイラル開発技法を発展させ、CASE技術を組み合わせています。
 体制的には、業務をよく知っているユーザと、能力の高い開発者がペアになって開発を行い、テストや文書化などの作業はまわりのスタッフが支援するような体制で行ないます。
 RADを行うための方法や体制について、多様なモデルが提案されています。

ラウンドトリップ・エンジニアリング
モデリング段階とコーディング段階を往復しながらソフトウェア開発を行う技術です。UMLのようなモデル図からソースプログラムを自動生成したり、ソースプログラムを修正するとモデル図が自動修正されるようなツールが使われます。
カンバン方式
トヨタによるジャストインタイム生産方式をシステム開発スケジューリングに応用して、何を、いつ、どれぐらいのコストで開発するかなどを管理するプロセス管理システムあるいはそれを活用した開発体制です。
フィーチャ駆動型開発
この場合のフィーチャ(feature)とは、利用者の視点での必要なソフトウェアやシステムの持つ機能(要件)のこと。
フィーチャ駆動型開発(Feanture-Driven Development:FDD)とは、フィーチャを単位として、実際に動作するソフトウェアを短期反復的に開発し、徐々に完成に近づけていくアジャイル開発の方法論です。
計画、設計、構築を繰り返す点では、スパイラル開発技法と似ているし、開発対象機能を逐次拡大する点では、インクリメンタル型開発技法と似ています。開発プロセスの特徴よりも、利用者のニーズを重視して対象にする機能を設定することが特徴だといえましょう。

XP(エクストリーム・プログラミング)

従来の開発技法は、ドキュメントが重視され、仕様が正しく定義され、正しい手順で開発すべきだとされてきました。XPの提唱者ケント・ベックらは、「変化を享受せよ」として、開発に伴う変化を当然あるべきものとして積極的に対応できることを目指しました。開発スピードの重視、ダウンサイジングなどの環境変化などにマッチし、急速に普及しました。

XPの5つの価値

開発チームが共有すべき5つの価値
 ・顧客と開発者、開発者間の円滑な「コミュニケーション」
 ・必要最小限の設計しか行わない「シンプルさ」
 ・頻繁なテストによる「フィードバック」
 ・大胆な設計変更に立ち向かう「勇気」
 ・関係者の意見や能力の「尊重」
19のプラクティス(抜粋)

XPのプラクティス

共同のプラクティス

開発のプラクティス

管理者のプラクティス

顧客のプラクティス

スクラム開発技法

システム開発でも、ラグビーのスクラムのように、各メンバーが協力し、全体が同じ目的を共有することが重要だとする、少人数によるアジャイル開発手法です。
比較的小規模なシステムを、利用者のニーズを柔軟に反映させながら、短期間で稼働させることを目的としています。

開発すべきシステムを細分化して1~4週程度で完結する開発の単位をスプリントといい、各スプリントを短期間で開発、まとめ、レビュー、調整の繰り返しで開発します。
・テスト駆動開発
・受け入れテスト駆動開発
・リファクタリング
・継続的インテグレーション

などの技法が用いられ、XPと似た特徴をもっています。

スクラム開発の組織

ユーザーストーリー

アジャイル開発における要件定義に相当するものです。
 ユーザーストーリーは、「誰の立場に立って、目的を達成したいのか」、また「それはどのような課題があり、どのような目的のために必要なのか」をできるだけ細分化して作成します。

3C
・Card(カード)ユーザーの要求内容など、ストーリーの要素を付箋紙やカードに書く
・Conversation(対話)ストーリーの背景など、カードに書かれていない部分は対話して引き出す
・Confirmation(確認)ストーリーごとにテストし、正しく実装されているかを確認する
INVEST原則
・Independent(独立)それぞれが重複のないよう独立したものであること
・Negotiable(交渉可能)ユーザーと開発者間で、話し合い交渉しながら作成すること
・Valuable(価値)ユーザーにとって価値あるものが記されていること
・Estimable(見積可能)ユーザーがスケジュールを立てたり、優先順位を付けたりできる
・Small(小さい)把握しやすく正確な見積もりできるサイズ感であること
・Testable(テスト可能)ユーザーストーリーが達成されているかどうか、チェックすること
ユーザーストーリーマッピング
・ユーザーストーリーを付箋紙などに書き出す。
・大分類・小分類、ストーリー間の関連などにより体系化する。
・時系列と優先度に沿ってマッピングする。

バックログ

バックログとは、解決すべき事項です。これがなくなったときがスクラムのプロジェクトの終了になります。

スプリントの流れ

スプリントとは1~4週程度で完結する開発の単位です。利用者も加わり開発、まとめ、レビュー、調整の繰り返しで行ないます。

KPT法

スプリント状況の「振り返り」のフレームワークです。

このフレームワークでスプリントを振り返ることにより、状況を関係者全員が状況を早期に共有して、課題と解決について合意することができます。

DevOps

開発担当者(Development)と運用担当者(Operations)が協調してシステム開発・運用します。Devは、システムに新しい機能を追加すること、Opsは、システムを安定稼働することであり、システムによるビジネスへの価値向上を確実かつ迅速にエンドユーザに届け続けること、その継続的改善を確実にすることが目的です。開発担当者とはベンダやIT部門、運用担当者とはユーザ企業あついは利用部門です。

アジャイル開発技法の一つではありますが、カイゼンやリーン生産方式を背景とした概念で、常にシステムに新しい機能を追加することを重視しています。組織文化の変化を伴うカイゼン運動としての要素もあります。

CLAMS

Devopsの特徴としてCLAMSを挙げています。
  Cluture(文化)
  Lean(リーン)
  Automation(自動化)
  Measurement(計測)
  Sharing(共有)

チーム組織文化

チーム組織文化として、次のルールを定めています。

支援ツール

「Devopsツール」というような特定のツールはなく、既存のツールあるいは手法の利用を推奨しています。
 特に重視しているのは自動化と情報共有です。次のようなツールを掲げています。


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

参照:IPA「アジャイルソフトウェア開発宣言の読みとき方」( https://www.ipa.go.jp/files/000065601.pdf

「アジャイルソフトウェア開発宣言」は、従来型のソフトウェア開発のやり方とは異なる手法を実践していた17名のソフトウェア開発者が、それぞれの主義や手法についての議論を行い、 2001年に公開されました。そこには、彼らがソフトウェア開発を行ううえで重視している「マインドセット」が書かれていました。その後、このマインドセットは、世界中のソフトウェア開発者達に支持され、”アジャイルソフトウェア開発” という名で世に広まりました。

アジャイルソフトウエア開発宣言では、4つの価値と12の原則を示しています。
 現在、いろいろな局面で「アジャイル」という言葉が使われていますが、この言葉の根本の考え方には、この「アジャイルソフトウエア開発宣言」があると考えて良いでしょう。

一方「アジャイル宣言の背後にある原則」は、「アジャイルソフトウェア開発宣言」で表明されているマインドセットを実現するために、従うことが望ましい原則、つまり根本的・根源的な取り組み姿勢について、書かれています。

4つの価値(マインドセット)

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

各項目において、前者にも価値はあるが、後者の価値をより重視する。

(注)IPA「アジャイルソフトウェア開発宣言の読みとき方」での説明

12の原則

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

アジャイル宣言の背後にある原則

私たちは以下の原則に従う:


CI/CD

CI/CDの構成

CI/CD(Continuous Integration / Continuous Delivery/Deployment)は、大規模なシステムを多数の開発者が改善を進めていくプロジェクトを対象にした管理の方法論です。

CI/CDの位置づけ

CD/CIの構成

継続的インテグレーション(Continuous Integration:CI)
ソフトウェア開発において、ビルド・テスト・統合を頻繁に繰り返し行なうことにより問題を早期に発見し、開発の効率化や省力化、納期の短縮などを図る手法。
  1. 現行システムは、細分化されたモジュール(オブジェクト指向言語ならクラス)からなり、その全体はCIサーバにマスタファイルとして登録されている。
  2. 開発者は、現状のマスタファイルから、変更対象となるモジュール(プログラム)を自分のファイル(ローカルファイル)にコピーする。
  3. 開発者がローカルファイルのモジュールを更新する。
  4. その変換されたプログラムをCIサーバが検知し自動で変換する。このコンパイル→リンケージ→実行プログラムの流れをビルドという。
  5. あらかじめ作っておいたテストコードを使って、CIサーバは自動でテストを行う。その結果は開発者に、フィードバックされる。
  6. 正しく更新されたモジュールは、マスタファイルに送られるが、この際、以前のモジュールは保持され、変更後のモジュールは新しいバージョンが付加され保管される。これを統合(インテグレーション)という。
継続的デリバリ(Continuous Delivery)
継続的デプロイメント(Continuous Deployment))
双方とも、ビルドされたモジュールを実行可能な環境に配置し、実行できるようにすることです。
継続的デプロイでは、明示的な承認が行われることはなく、自動的に本番環境になります。
継続的デリバリーは、運用環境への更新に人間による確認が行われた後に、システム全体をリリース(利用者に公開)します。

CD/CIの利点

継続的インテグレーションにおける更新バージョンの仕組みは、次のような利点があります。それで「分散型バージョン管理システム」の基礎になります。