これまでの開発方法論との違い
当社では、大企業が採用することの多いウォーターフォール型開発（基本設計～詳細設計～開発～内部テスト～受入テストを、個別に分離した工程として独立させた開発方法論）とは違う「アジャイル開発」という開発方法論、その中でも特に「スクラム」という手法を採用しています。
これにより、次のような問題を発生させません。
- ①開発フェーズに入ってから問題に気付いても、既に仕様凍結後であるため要件に反映されない。
もしくは、反映しようとすると大きなコストが発生する。 - ②受け入れテスト段階で、初めて動くものを見せてもらえ、その時初めて思っていたものと違うことに気づくが、もうすでに修正はできない。
- ③1年前に話した内容が、やっと出来上がってきたけど、もうすでに1年前とは違う業務運用形態となっているため、システムが出来上がっても、システムが業務にマッチしない。
アジャイル開発手法「スクラム」
概要
アジャイル開発手法「スクラム」では、基本設計～詳細設計～開発～内部テスト～受入テストを、個別に分離した工程として独立させるのではなく、全行程を2週間毎に繰り返しながら、開発対象を段階的に充実させます。「スクラム」は下図の工程により構成されます。
| 用語 | 説明 |
|---|---|
| プロダクトバックログ | 製品に必要な要素を項目に起こした一覧。バックログを整理して項目の上下関係で優先順位を表します。各項目はチームによって相対難易度（コスト）の見積もりを付けられ、プロダクトオーナーが顧客観点からの価値を見積もります。スクラムチームによって上位項目は、1～2日で開発可能な機能レベルまで詳細化されます。 |
| スプリント | スプリントは実際にソフトウェア開発が行われる工程。スプリントは、開発、まとめ、レビュー、調整の繰り返しにより構成され、スプリント内では決まった順序は存在しません。必要に応じてバックログの項目を開発し、まとめ、レビューを行います。また、項目によっては単にレビューと調整だけですむ場合もあります。どのように開発されるかはそのバックログ項目の内容によって決まります。 |
| スプリントバックログ | スプリントの開始時、そのスプリントで実現する仕様をまとめたもの。スプリント完了時に、コーディング／テストが完全に完了していることを要求されます。スプリントバックログはスプリントで実現する仕様を管理可能な単位に細分化したものです。 |
| デイリースクラム ミーティング |
いわゆる朝会。現在のプロジェクトを見える化（現在の状況を示すタスクボードや、かんばん、バーンダウンチャートなどを利用）した物の前で、メンバー一人一人が、「昨日やったこと」、「今日やること」、「障害となっていること」を共有し、チーム全体の意思統一と次の行動を全体共有します。 |
| 製品 | 常に動く状態（出荷可能な状態）で管理されている成果物 |
アジャイル開発手法「スクラム」では、優先度の高い順番に、常に動く状態のシステムとしてシステムを作り上げていくため、次のようなメリットがあります。
- ①仕様の追加／変更などに柔軟に対応できる
- ②動くものを見て意識合わせをしながら開発を進める事が出来る
- ③受け入れテスト時点の品質がある程度担保されている
標準開発サイクルと役割
スクラムの標準開発サイクルと、スクラムを実施するために必要となる各役割は次の通りです。
| 役割名称 | 担当 | 役割 |
|---|---|---|
| プロダクトオーナー | システムを構想している人 | プロダクトに責任を持ち、仕様に関する決定権を持つ。スプリント終了時に受入確認を行う。 |
| スクラムマスター | 当社の担当者 | スプリントがうまく回るよう、チームを助けプロジェクトの阻害要因を排除 |
| 開発チーム | 2週間のスプリントを通して機能追加を行い、動作するソフトウェアをオーナーに届ける |
特徴的な「テスト工程」
スクラムでは、2～4週間を1つの作業期間（スプリント）として納品を続けるため、要件定義～基本設計～開発～テスト～受入までの開発サイクルを、スプリント単位で繰り返すこととなります。当社では、単体テストは基本的にテストプログラムで実施するため、仕様書＝テストプログラム、結果＝自動テスト実行レポートとしています。この自動テストの仕組みにより、前回のスプリント終了時点までに作り上げてきた仕組みが、今回のスプリントで勝手に仕様変更やデグレーションになっていないことを担保します。また、このテストプログラムが、確定仕様の資産となり、仕様変更があった場合は確実に変更されるため、紙の仕様書のように、プログラムと同一性を保証できないということは起こりえません。
このような活動により、最後にまとめてテストを行うウォーターフォール型開発に比べ、認識の齟齬や品質の低下に気付けるタイミングが早く、また、開発の遅れからテストスケジュールを確保できず、テストがおろそかになって品質事故が起こるという事を回避できます。
最後にまとめて沢山の工数を掛けて受入テストを行うのではなく、定期的に受入テストを行って頂くことで、次のメリットを享受することが可能です。
- ①膨大な受入テストを実施するという作業プレッシャーからの開放
- ②膨大な受入テストをまとめて実施するために発生するテスト漏れからの開放
- ③「受入テストのコツ」を受入側においても経験的に学習するので、最終納品物の品質を、「受入テスト」という観点からも高めることができる。